Louis Werth wrote

>I've got a client with a DB size of 1.4Gig, they run a backup and takes
>them about 15 min, but when they run the restore it takes 4 and a half
>hours. They've got a P3, 1GRAM, 50GB, 1.4GHZ Compact Proline, OS = Win2K
>Server.
>The performance on the db is also very slow(appart from backup).
>To Sweep this DB also takes about 4 hours.
>I made sure all Anti Virus Software is disabled.

and

>To add to my previous mail, they send us the db and restored it locally
>and the restore took about 45 min(Seems correct).
>I vaguely remember something amount some W2k serveice also making use of
>.gdb file and it had a impact on IB/FB but cannot recall the exact
>details.

I'm rather surprised that they can gbak 1.4GB in 15 minutes.
IIRC, my 1.2GB database need about a couple of hours to restore on a ca.
900MHz (Xeon) Dell PE4400 with mirrored 15000rpm disks (I don't remember
backup times at the moment). Most of the time (of the restore) is used for
recreating indexes. gbak runs on one processor and ibserver (Fb, in
reality) runs on the other, using Win2k.

What type of precessor do you use (on the 45-min computer), and what about
speed of
the disks and (RAID-) controllers.

The problem with *.gdb is specific to WinXP, I think.

The 4-hour sweep indicates that transactions are not handled properly,
which is a cause for general (increasing) slowness as well. Do they do
'hard commits' whenever appropriate? CommitRetaining doesn't count
here. Do check the statistics on the header page when the database is
slow, and let us see it.
You'll some lines like the following:
Oldest transaction 213
Oldest active 214
Oldest snapshot 214
Next transaction 216
The difference between 'Oldest' and 'Next' should not
be too big. A big difference usually means you have some very long running
transactions. After a restore the difference will be close to zero. Also,
a sweep (with no one connected) should achieve this.


--
Aage J.