Subject Re: GBak. Memory use
Author Michael Vilhelmsen
--- In, "Leyne, Sean" <Sean@B...> wrote:
> Michael,
> > When restoring, I never comes below 300 - 400 Mbs of physical memory
> > available.
> What FB version you running?

FB 1.5.0
I am pretty sure, that I have experienced the sme with 1.5.1 (but I
have to double check this).

> 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.

Which means, that when the next version of Firebird is released
(version 2.0) the GBak will be faster !
Or can I use it now ?

> > The server is running Windows 2000 server with a RAID system.
> >
> > 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.....
> You are aware that RAID is often not faster than IDE?

But growing from 20+ minuttes to 90+ minuttes...... ?
Besides - shouldn't the server release some memory when doing the
create index rutines (as my labtop does).

> 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?

No, they are on the same drive.
As they are on my labtop.

Also - I have just defragmented prior to running this GBak restore
As of now - I have contact with 3 different servers (1 is 2½ years
old, another is 9 months old and the last is brand new).

All of these does the same.

But as I see it, the problem will only come, when the actual size of
the DB is larger than the amount of physical memory.
Last night I did some test on some smaller DB's but the just finished
as I suspected (whcih means fast).

> Sean