> -----Original Message-----
> From: Ann W. Harrison [mailto:aharrison@...]
> Sent: Saturday, November 25, 2006 3:27 PM
>
> The major variable in backup time is the amount and type of garbage
> collection. With the -g switch, your backups will be much faster,
> but your databases will not be cleaned up. If you plan to restore
> the backup and replace the database, always use the -g switch.
> There's no point in cleaning up your house before you burn it down.

Understood. Does 2.5 hours seem reasonable for a backup with garbage
collection of a 35GB database? I thought so previously, until I heard
the other poster was only seeing 15 minutes on his 25GB db. He did
mention that he does a sweep before backup, but that the total elapsed
time is still only 20 - 35 minutes.

> The second issue is the type of garbage collection. Removing

entries

> from indexes with long duplicate chains is expensive in Firebird
> versions before 2.0. Making the indexes more nearly unique can
> save backup time when doing garbage collection.

I'll take another look at our indexing. We typicallly include the PK
as the last column in indexes that do not have much uniqueness without
it.

> > while restores have taken between 5 hours and 9 hours.
>
> A major cost of restoring a database is recreating the indexes.

That

> is done bu sorting each table once for each index, then building the
> index from the bottom up. That's a fast way to build indexes, but
> still an expensive operation. Especially if you use the
> default memory settings for sort in the configuration file. Try

giving the sort

> much larger runs and larger total memory.

I modified the configuration file from it's defaults to the following:

SortMemBlockSize = 2097152
SortMemUpperLimit = 33554432

I definitely see the per-process memory usage increase for each
connection (FB 1.5 classic). I'm not sure of the effect yet. The
last two restores were somewhat faster than the two or three prior
cycles, but no outside the normal deviation that I've encountered.


Bob M..