Subject | Re: [firebird-support] Re: Gbak Restore - SuperServer vs. SuperClassic |
---|---|
Author | Thomas Steinmaurer |
Post date | 2014-11-17T13:26:29Z |
Hello Michael,
So, your original restore call:
GBak -C -User %1 -Pas %2 G:\FBDump\OCCEasyPos.fbk "LocalHost:F:\DB\Kaufmann\Uddannelse\OCCEasyPos.fdb" -v -rep -o -FIX_FSS_METADATA ISO8859_1 -fix_fss_data ISO8859_1 -y "G:\FBDump\RestoreEasyPos.txt"
Could be transformed to something like:
gbak -C -User %1 -Pas %2 -service localhost:service_mgr G:\FBDump\OCCEasyPos.fbk F:\DB\Kaufmann\Uddannelse\OCCEasyPos.fdb -v -o -y "G:\FBDump\RestoreEasyPos.txt"
So the difference is that you don't provide the host name (localhost) in the resulting database path but through the -service option. If both, the backup and the restored database file is on the same server, using the -service option is the fastest way. The same goes for a backup as well.
From your origingal gbak restore call, I have also removed the -rep option, because a faulty restore will trash the overwritten restored database and the FIX* options as well.
Regards,
Thomas
> Beside your gbak restore issue, your counters here show some interestingBy using the Firebird services manager you basically tell the server to initiate and run the restore on the server which results in bypassing the TCP stack.
> throughput numbers, when taking the creation date of the database into account:
>
> ~ 170 transactions / sec
> ~ 9 connections / sec
>
>
>
>
> We have a external connection from a WEBStore.
> Whatever they do, they connect and disconnect every second, do a start
> transaction and commit.
> I have a case with them, where I would like them to stop this, but so far
> without success.
>
>
>
>
>
>
>
>
>
>
> - Any special reason that you use both -FIX* options everytime for the restore?
> Left over from restoring from 1.5 to 2.1 - havn't deleted them yet :)
>
>
>
>
>
> - Where is the restore process stuck? Probably while creating indexes?
> No - both times I have seen this, its during ordinary restore and before index.
>
> I am still trying to find out why this is.
>
>
>
>
>
> - I would seriously look into running gbak for both, backup and restore through
> the Services Manager. Check out the -se option
>
> Hmm - whats this?
So, your original restore call:
GBak -C -User %1 -Pas %2 G:\FBDump\OCCEasyPos.fbk "LocalHost:F:\DB\Kaufmann\Uddannelse\OCCEasyPos.fdb" -v -rep -o -FIX_FSS_METADATA ISO8859_1 -fix_fss_data ISO8859_1 -y "G:\FBDump\RestoreEasyPos.txt"
Could be transformed to something like:
gbak -C -User %1 -Pas %2 -service localhost:service_mgr G:\FBDump\OCCEasyPos.fbk F:\DB\Kaufmann\Uddannelse\OCCEasyPos.fdb -v -o -y "G:\FBDump\RestoreEasyPos.txt"
So the difference is that you don't provide the host name (localhost) in the resulting database path but through the -service option. If both, the backup and the restored database file is on the same server, using the -service option is the fastest way. The same goes for a backup as well.
From your origingal gbak restore call, I have also removed the -rep option, because a faulty restore will trash the overwritten restored database and the FIX* options as well.
Regards,
Thomas