At 12:32 PM 1/08/2010, you wrote:

>Dear Alan and friends,
>
>Thank you for your response.
>
>The gbak has now been going for >24Hrs and still in exactly the same state ie no change at all to the message displayed from the gbak cmd of
>
>gbak: writing data for table SMDR
>
>and the backup file is exactly the same size as when I earlier sent the query.
>
>Does this still appear normal?

Yes. If you deleted 70 million records then it is busy processing all the garbage left behind.

>Normally, the sweep, gbak and restore takes about 3 Hrs (if no mass delete of 70Million records was performed).
>
>You mentioned running the gbak with the -g switch. What would happen if I was to cancel this backup and then recommence the gbak with the -g switch ie
>
>gbak -v -t -g -user SYSDBA -password "masterkey" DATABASENAME.FDB DATABASENAME.FBK
>
>will that corrupt the database if I stop during the original gbak?

No, it shouldn't corrupt the database. Gbak will request for the transaction to be rolled back, causing 21+ hrs of garbage collection to be undone. But what you do depends on whether you intend to restore the database from the backup. If so, then use the -g switch to perform the backup with [no_]g[arbage_collection]. Then, restore the database using the -c[reate_database] switch with a temporary name, verify it by connecting to it after the restore is complete and, if all is well, replace the old database with the new.

>And, would I expect the gbak with the -g option to be less than 3 Hrs (which is the normal Sweep/Backup/Restore duration with no delete).
>
>Anybody else experience this?

Let's say it's not an unexpected experience after a massive mass delete. In future, if you have to do operations like this, you'll be keen to plan the timing. There's an argument here - for today - for just allowing the GC to continue, just so that you have a handle on how long it would take if you ever needed to do it again.

./heLen