At 05:00 AM 18/09/2006, you wrote:

> > Nothing has changed. Gbak still does GC unless you tell it not to.
>
>OK. No problem.
>But is the hanging of gbak with GC considered a bug?

It doesn't hang. It just takes a long time to get to the point, when
it is performing GC on every table it reads. And it is as designed.

>And if so, is anyone working on this issue?

Fb 2.0 has a new backup facility called NBackup, which provides a
different approach to backing up. However, I'm not suggesting this
is the "solution" to your "problem". As I commented earlier, if you
are doing massive deletes, the GC chicken has to come to roost somewhere.

>
> > Fb 2.0 *does* make cooperative GC available to Superserver, which
> > might help you to plan your post-delete cleanups a bit more
> > easily. But you do have to get rid of the garbage by some means.
>
>Could you please explain "cooperative GC"?

It's fairly well explained in the Fb 2.0 release notes.

>And is it already available in FB 1.5 classic?

Yes; it is the *only* way Classic does GC. Broadly put, the first
user transaction to hit the table after the deletes will trigger off the GC.

> > To turn that around - if you are planning to restore the DB after
> > backing it up, don't do GC in the backup! Disable GC using the -g
>switch.
>
>Sounds... uh... strange.
>What's a backup's use if never being restored ;-)
>
>But seriously, what is the suggested way to do a massive delete on a
>(fairly large = 8 GB) database?

It depends. If the intention is to delete *all* records in the
table, then dropping and recreating the table would be the
recommended way. Dropped tables don't leave garbage. If not, then
possibly performing the deletes in a string of transactions, rather
than in one huge one, would (potentially, at least) release the
record stubs for regular GC to handle.

>Obviously you have to do something because it might corrupt the
>database otherwise.

Why would deleting records corrupt the database?

>One of our customers corrupted their database twice. And each time
>they did a massive delete before without a backup/restore. So that's
>what I suggested to do, a backup without GC and a restore afterwards.

Isn't that like shutting the stable door after the horse has
bolted? I'd be more concerned to discover why the delete operation
corrupted the database, and ensure that I'd fixed that.

./heLen