Hello, Bob!

Sunday, October 13, 2013, 8:21:12 AM, you wrote:

BM> Do you have any other tips for getting the best performance during backup
BM> and restore? Our current situation is a backup of the production database
BM> on server1 intiated on server2, with the backup file residing on server2.
BM> Server2 initiates the restore (using service manager), with the database
BM> being stored on the same disk array as the backup file.

BM> A 113GB production database produces a backup file of 99GB, and a newly
BM> restored database of 108GB. This entire process takes almost 48 hours.

oops. As I know (from our test), backup and restore are disk bound,
and does not depend on Firebird cache size or db page size, etc.

First, yes, the fastest way to backup and restore is to use Services
API (gbak -se ...). On Linux same results will be using local protocol
(db name and path without server name).
Second, you need to have all timings to understand how much time these
processes takes. I mean
backup
restore
restore with -i.

Usually restore takes 3-5 times longer than backup.

Third, when making backup over network (as I understood), you need to
be sure that network is faster than making backup to disk. Otherwise
you are wasting time.

restore with -i option is needed to understand:
- how fast data is being restored. I can't find data right now, but
seems that this must be close to the backup time.
- how fast/slow indices are being created during restore.
Here maybe you need to reconfigure TEMP settings (point it to fast
disk), to check (and maybe delete) indices with very bad selectivity,
etc.

And, the last one - to compare this with other results.
For example, one system I have data right now makes backup
30 minutes and restore 4 hours on 36gb database.
These numbers are for single-user mode, and worse for "online" -
backup takes 2 hours.

Something like this. :-)

--
Dmitry Kuzmenko, www.ib-aid.com