Dear Helen,

Thanks for your response

>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.

My gbak process is still running ie close to 72Hrs later 3 days and everything still appears the same. Maybe this is normal after a 70 Million record delete, however is there anything I can check via a command to make sure something IS happening?

Eventhough I did a standard delete, what is happening in the database that could cause the gbak to take so long to complete? Don't forget, I normally do a monthly (probably 3-4 weeks) sweep, backup, restore in less than 3 hrs?

What other options do I have?

If I was to copy the DATABASENAME.FDB (while it is in the process of doing the gbak) to another filename, then do the gbak on the new database file with the -g switch, followed by a restore to a temporary name, should that complete in approx 3 hrs? Remember the purpose of the backup/restore is to eliminate garbage transactions? If it is possible to do this in another cmd window, I will let the currently active gbak process to continue until it does complete.

Please advise.

Thank you for your help.

Theodore



[Non-text portions of this message have been removed]