>> From: [email protected] > [mailto:[email protected]] On Behalf Of Dmitry Kuzmenko >> Sent: Saturday, October 12, 2013 12:36 AM >> To: [email protected] >> Subject: Re[2]: [firebird-support] Restore error during unique index > creation >> >> >> TS> * Running th restore through the Services API/Manager >> >> right, this is the fastest way. >> >> TS> * Provide a larger page cache upon restore, because especially the > index >> TS> creation step loves RAM. Don't forget to set the page buffers value > back >> TS> again at database-level after the restore via e.g. gstat. I've seen >> TS> restore improvements of > 300% for largish indexes this way. >> >> This idea is useless. We have done complex restore >> test, including specifying -bu nnn option, and found no difference >> for cache size from 1024 to 16384 pages (classic and superserver), >> for data only (-i) or full restore (data+indices). > > Dmitry - > > Do you have any other tips for getting the best performance during backup > and restore? Our current situation is a backup of the production database > on server1 intiated on server2, with the backup file residing on server2.
I would create the backup file on the same server as the production database with the -se switch, ideally on a different physical disk. After backing up, move it to another redundant backup server if you wish. Also -g for suppressing garbage collection in the production database might be an option if it is all about backup speed. You probably do that already. > Server2 initiates the restore (using service manager), with the database > being stored on the same disk array as the backup file. As said. Increasing -buffers while restoring isn't totally useless, but worth to be tested in your environment, although for a start, possible not on the 100GB database. ;-) You could also serve the restore via a dedicated Firebird instance with increased temporary storage module settings in firebird.conf to suppress putting fb_sort* files while index creation onto disk and serve most of the sorting requests via RAM, but as said in a previous post, index creation is getting CPU bound on a single physical core pretty quickly. So for that case, you'd better have better single core throughput than e.g. scaleing up in regard to number of cores, but still, increasing the page cache and temporary storage module settings are viable options. > A 113GB production database produces a backup file of 99GB, and a newly > restored database of 108GB. This entire process takes almost 48 hours. -- With regards, Thomas Steinmaurer http://www.upscene.com/ Professional Tools and Services for Firebird FB TraceManager, IB LogManager, Database Health Check, Tuning etc.
