Subject | RE: [firebird-support] GBak. Memory use |
---|---|
Author | Leyne, Sean |
Post date | 2004-11-18T01:10:39Z |
Michael,
There was a reported problem in restoring databases with a large number
of inter-related SP which operate on a large number of tables.
I can report that GBak under v2.0 runs much faster than 1.x for both
backup and restore.
RAID ensures reliability in the case of drive failure, but may sacrifice
pure I/O performance to ensure that data is written correctly to all
disks in RAID set. A good RAID controller **with Battery Backup** helps
a lot -- by allowing for the use of 'write-through' operations.
Further, is your disk defragmented on a regular basis, under Windows
this makes a big difference. Also, do you have the temporary sort files
(used by the index rebuilder) sorted on a different drive from the DB?
Sean
> When restoring, I never comes below 300 - 400 Mbs of physical memoryWhat FB version you running?
> available.
There was a reported problem in restoring databases with a large number
of inter-related SP which operate on a large number of tables.
I can report that GBak under v2.0 runs much faster than 1.x for both
backup and restore.
> The server is running Windows 2000 server with a RAID system.You are aware that RAID is often not faster than IDE?
>
> I can restore this DB on the labtop within 30 minuts.
> On the server it takes between 60 and 90 minutes!
> It really slows down, when creating all the index.....
RAID ensures reliability in the case of drive failure, but may sacrifice
pure I/O performance to ensure that data is written correctly to all
disks in RAID set. A good RAID controller **with Battery Backup** helps
a lot -- by allowing for the use of 'write-through' operations.
Further, is your disk defragmented on a regular basis, under Windows
this makes a big difference. Also, do you have the temporary sort files
(used by the index rebuilder) sorted on a different drive from the DB?
Sean