At 07:04 AM 10-05-02 +0000, stevelw wrote:

> > No reason to do the garabge collection if you're going to turn
> > around and immediately restore the backup.


>That's exactly what I'm going to do. Given the large number of
>deletions I thought some tidying-up would be necessary for optimum
>performance.
>
>I obviously don't fully understand the garbage collection option -
>why is it not needed in these conditions?

gbak isn't a file-copy utility. What it does is literally dissect a
database into metadata and data and save the whole lot to a file format
that it can later read and use to reconstruct the database new, pure and
pristine. Restore resets everything and rebuilds indexes from ground zero.

In the course of performing this miracle, its default behaviour is to tidy
up old record versions and other garbage in the existing database, on the
assumption that life will just go on, with the gbk tucked safely away
somewhere for the next rainy day. Remember, in Firebird you can perform a
backup whilst users are logged in and working. The gbk won't contain any
changes that occurred after the backup started, however.

Now, if your main intention is to get a backup, restore it and then carry
on with the restored database, the housecleaning of the existing database
isn't necessary, since you are going to ditch it anyway. So use the -g
switch to disable garbage collection.

Just DON'T restore the gbk over the top of your existing,
about-to-be-trashed version. Restore in some safely remote place first, as
a precaution; and, rather than overwrite, zip up the old database onto
CDs, as another precaution. (Just make sure you do this when NOBODY is
logged in, not even SYSDBA.)

...or, live dangerously... <g>

cheers,
Helen


All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________