[firebird-support] Gbak Restore - SuperServer vs. SuperClassic
Hi Does GBak behave different on a Classic Server than on a SuperServer regarding restore speed? I ask this, because around 1 year ago I installed Firebird 2.5 SS on a Windows environment. Here I did a restore of a 90 Gb DB. This took around 8 hours. Since then we have switched from SS to Classic due to some performance issues. The setup runs good. Now I have 2 times tried to restore the dayly dump file on another folder on this very same system. Both times I have had to cancel this after 9+ hours where the restore was approximatly half way. I would have expected it to be a little more than 9 hours, since the DB is now 96 GB. Michael My system is: - Windows Server 2012 R2 (64 bit) - 4 Core CPU - 32 Gb RAM - Firebird 2.5.2.26540 Classic
Re: [firebird-support] Gbak Restore - SuperServer vs. SuperClassic
Michael, Does GBak behave different on a Classic Server than on a SuperServer regarding restore speed? I ask this, because around 1 year ago I installed Firebird 2.5 SS on a Windows environment. Here I did a restore of a 90 Gb DB. This took around 8 hours. Since then we have switched from SS to Classic due to some performance issues. The setup runs good. Now I have 2 times tried to restore the dayly dump file on another folder on this very same system. Both times I have had to cancel this after 9+ hours where the restore was approximatly half way. I would have expected it to be a little more than 9 hours, since the DB is now 96 GB. * What is the page buffers value at database level? (gstat -h) * How does your gbak restore call look like? -- With regards, Thomas Steinmaurer http://www.upscene.com Professional Tools and Services for Firebird FB TraceManager, IB LogManager, Database Health Check, Tuning etc.
[firebird-support] Re: Cross database update
Dear Thomas, thank you for your answer. I have experienced that pssing by the trigger is functioning well. The only thing wrong is that the loop has no effect on the data of the records. And I hoped that someone could check the statement syntaxwise. Maybe I am doing something wrong in my logic. Is the use of the for select do loop correct as stated? Maybe I have to use an update or insert statement except? Thanks again for any input. Kind regards Christian
[firebird-support] Re: Gbak Restore - SuperServer vs. SuperClassic
* What is the page buffers value at database level? (gstat -h) E:\DB\Kaufmannc:\Program Files\Firebird\Firebird_2_5\bin\gstat.exe localhost: e:\db\Kaufmann\OCCEasyPos.FDB -h Database e:\db\Kaufmann\OCCEasyPos.FDB Database header page information: Flags 0 Checksum12345 Generation 101077117 Page size 4096 ODS version 11.2 Oldest transaction 96356704 Oldest active 96356705 Oldest snapshot 96356705 Next transaction96384172 Bumped transaction 1 Sequence number 0 Next attachment ID 4930121 Implementation ID 26 Shadow count0 Page buffers2048 Next header page0 Database dialect1 Creation date Nov 11, 2013 23:47:15 Attributes force write Variable header data: Sweep interval: 0 *END* E:\DB\Kaufmann * How does your gbak restore call look like? 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
RE: [firebird-support] Re: Cross database update
Dear Thomas, thank you for your answer. I have experienced that pssing by the trigger is functioning well. The only thing wrong is that the loop has no effect on the data of the records. And I hoped that someone could check the statement syntaxwise. Maybe I am doing something wrong in my logic. Is the use of the for select do loop correct as stated? Maybe I have to use an update or insert statement except? Your FOR..SELECT seems fine, what’s unknown to us (proprietary to IB Expert) is the ibeblock and the use of two separate connections (Firebird does support transactions spanning several connections as well as ON EXTERNAL, but not treating two connections as something you can mix inside a stored procedure). I think your error is in your execute block and that you either have to explicitly pass values or declare variables as input parameters in your execute block. Take a look at http://www.firebirdsql.org/refdocs/langrefupd20-execblock.html. Moreover, I’d recommend trying to get some kind of error message rather than having no code in the EXCEPT block (hiding things from the user may be OK, it is normally not what you want when you have a problem puzzling you). HTH, Set
Re: [firebird-support] Re: Gbak Restore - SuperServer vs. SuperClassic
Hello Michael, * What is the page buffers value at database level? (gstat -h) E:\DB\Kaufmannc:\Program Files\Firebird\Firebird_2_5\bin\gstat.exe localhost: e:\db\Kaufmann\OCCEasyPos.FDB -h Database e:\db\Kaufmann\OCCEasyPos.FDB Database header page information: Flags 0 Checksum12345 Generation 101077117 Page size 4096 ODS version 11.2 Oldest transaction 96356704 Oldest active 96356705 Oldest snapshot 96356705 Next transaction96384172 Bumped transaction 1 Sequence number 0 Next attachment ID 4930121 Implementation ID 26 Shadow count0 Page buffers2048 Next header page0 Database dialect1 Creation date Nov 11, 2013 23:47:15 Attributes force write Variable header data: Sweep interval: 0 *END* Ok, so at least you are not running with a page buffers value of 0 which maps to a default value in firebird.conf of 75 for CS/SC. Beside your gbak restore issue, your counters here show some interesting throughput numbers, when taking the creation date of the database into account: ~ 170 transactions / sec ~ 9 connections / sec Especially opening 9 physical connections per second sounds a bit like a design flaw adding unnecessary overhead. And a 96GB database with a page size of 4K might result in index depth 3 for larger tables. E:\DB\Kaufmann * How does your gbak restore call look like? 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 - Any special reason that you use both -FIX* options everytime for the restore? - Where is the restore process stuck? Probably while creating indexes? - I would seriously look into running gbak for both, backup and restore through the Services Manager. Check out the -se option Just some hints, but I don't have a real answer for your SS vs. SC issue. -- With regards, Thomas Steinmaurer http://www.upscene.com Professional Tools and Services for Firebird FB TraceManager, IB LogManager, Database Health Check, Tuning etc.
Re: [firebird-support] Re: Gbak Restore - SuperServer vs. SuperClassic
Beside your gbak restore issue, your counters here show some interesting 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?
[firebird-support] Re: Cross database update
Hi Set, thank you very much for the input. I will rework the block part and reply afterwards. Kind regards Christian
Re: [firebird-support] Re: Gbak Restore - SuperServer vs. SuperClassic
Isnt the transaction per second wrongly calculated? Oops, sorry!!! I have been one year off by using 2014 instead of 2013. -- With regards, Thomas Steinmaurer http://www.upscene.com Professional Tools and Services for Firebird FB TraceManager, IB LogManager, Database Health Check, Tuning etc. DB is created november 2013. Approcimatly 365 days ago. Transaction is at 96.356.705. Per day is approx: 263.990 Per hour: 10.999 Per minut: 183. Per second: 3
Re: [firebird-support] Re: Gbak Restore - SuperServer vs. SuperClassic
Hmmm, database dialect is 1. No issues with that? Greetings. Walter. On Mon, Nov 17, 2014 at 7:41 AM, 'Thomas Steinmaurer' t...@iblogmanager.com [firebird-support] firebird-support@yahoogroups.com wrote: Isnt the transaction per second wrongly calculated? Oops, sorry!!! I have been one year off by using 2014 instead of 2013. -- With regards, Thomas Steinmaurer http://www.upscene.com Professional Tools and Services for Firebird FB TraceManager, IB LogManager, Database Health Check, Tuning etc. DB is created november 2013. Approcimatly 365 days ago. Transaction is at 96.356.705. Per day is approx: 263.990 Per hour: 10.999 Per minut: 183. Per second: 3
Re: [firebird-support] Re: Gbak Restore - SuperServer vs. SuperClassic
Hmmm, database dialect is 1. No, not really. It was originally created as Dialect 1 back in 1998. It has never been changed, it works and as a matter of fact I'm not sure what happens if the dialect is changed...
[firebird-support] Re: Firebird on Mac
Le 14/11/14 21:04, 'William, David' david.will...@espn.com [firebird-support] a écrit : The installation process runs ok. But whenever I try to start the server Firebird should start at every boot some informations : http://paulbeachsblog.blogspot.fr/2008/03/where-is-libfbclientdylib-on-macosx.html http://paulbeachsblog.blogspot.fr/2008/02/firebird-and-macosx-uninstalls.html you can also disable or enable Firebird classic using launchctl $sudo launchctl unload /Library/LaunchDemons/org.firebird.gds.plist $sudo launchctl load /Library/LaunchDemons/org.firebird.gds.plist and for Superserver : /Library/StartupItems/Firebird/Firebird start /Library/StartupItems/Firebird/Firebird stop
Re: [firebird-support] Re: Gbak Restore - SuperServer vs. SuperClassic
Hello Michael, Beside your gbak restore issue, your counters here show some interesting 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? By 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. 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
Re: [firebird-support] Re: Gbak Restore - SuperServer vs. SuperClassic
i * How does your gbak restore call look like? 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 Have you tried it with the -G flag. This disables garbage collection, which can make backups run much faster. Obviously if you need / want to do the garbage collection this isn't an option but if it works much faster it gives you a hit as to what the issue might be :) Cheers Rob
Re: [firebird-support] Re: Gbak Restore - SuperServer vs. SuperClassic
i * How does your gbak restore call look like? 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 At 09:03 a.m. 18/11/2014, Robert martin r...@chreos.com [firebird-support] wrote: Have you tried it with the -G flag. This disables garbage collection, which can make backups run much faster. Obviously if you need / want to do the garbage collection this isn't an option but if it works much faster it gives you a hit as to what the issue might be :) OP is complaining of a slow restore. It makes no difference to the restore, whether the backup was made with or without the -g flag. But it's good advice to use the -g flag for a BACKUP that is going to be restored right away, since the original database is going to be dropped, anyway, garbage-and-all. Helen Borrie, Support Consultant, IBPhoenix (Pacific) Author of The Firebird Book and The Firebird Book Second Edition http://www.firebird-books.net __
