At 03:30 AM 9/03/2006, you wrote:

>Hi All,
>
>I'm having a recurring issue where the Firebird (v1.5.2.4731) backup
>is hanging up. I'm using a TIBOBackupService component to backup
>database_name.fdb and create a database_name.fbk. On rare occasions,
>the backup is failing and leaving the fbk open. This open file causes
>future attempts at a backup to also fail. The only solution we've
>found is to stop/start the service.
>
>Is there something I've missed in my implementation? Has anyone else
>seen this and is there a solution?

You say the backup "fails", yet your subject says "Backups
hanging". Which is it?

If the backup is really failing, you should get an exception and gbak
will close the file properly. If it's being caused because you're
backing up to a share, then you'll need to find out what's happening
to cause the network breakdown.

If a backup seems to "hang" it usually means there is a lot of
garbage that gbak has to collect along the way. GBak runs in a
single concurrency transaction and you can't just stop it because it
happens to be slow. The backup file stays open until the the Service
Manager closes it. And it won't close it until the process either
finishes the backup or aborts it because of errors.

So it looks like one thing leading to another.

Some things I would do here, if you're periodically getting these
heavy GC ops occurring during backup and it's enough to be causing a nuisance:

1. Add a button to enable the user to run the backup without GC. On
these occasions, you could follow up with a routine to restore the
database under a different filename, connect to it and run a simple
query. If it returns something, you know the backup is OK. Then you
can return a message dialog to the user recommending that the
database (not the server!!) be shut down; if it is accepted,
disconnect the app from both databases; then run a batch file to
first rename the old db file, then rename the restored file, then zip
up the old file.

2. You could do something smart like run statistics first and check
the difference between the Oldest Interesting and the Next
Transaction. If it's higher than a few hundred, send a dialog to the
user warning that the backup may take a long time and recommend that
the database (not the server!) be shut down. If it is accepted, work
out some way to get all the users off and defer the backup so you can
do the housekeeping, run the backup without GC and overwrite it (as in 1)

3. Another thing is not to make repeated backups using the same file
name for the backup file. I always generate a filename based on
current server date and time, e.g. MyDb.603090905.gbk if I was
running it right now. (That's year 6 month 03 time day 09 time
0905). That way, if you get an orphan backup file, you're not going
to be prevented from repeating the backup if a user wrecks the backup.

4. Since you're getting this big buildup of garbage, you should be
running sweeps in shutdown mode as part of your regular housekeeping.

5. For the long haul, you'll need to find out why you're getting
such a buildup of garbage and try to fix the problem in your app.

Helen