-----Original Message----- > From: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com] On Behalf Of Dmitry Kuzmenko > Sent: Saturday, October 12, 2013 12:36 AM > To: firebird-support@yahoogroups.com > 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. Server2 initiates the restore (using service manager), with the database being stored on the same disk array as the backup file. A 113GB production database produces a backup file of 99GB, and a newly restored database of 108GB. This entire process takes almost 48 hours. Thank you, Bob M..
