You are correct Helen, there really isn't a problem, there just
appears to be until the database is put into use. What is happening
is every time a backup is ran, the next transaction increases by one,
but the OAT does not. But once the database is put into use, the OAT
will start moving again.

I thought that if the backup process moved the next transaction up by
one, that the OAT would advance too if nobody else was connected to
the database. It does not advance with TIBOBackupService but does with
IBOConsole and running GBak from the command line (how I don't know)
so I thought there was a problem. I guess the question I really have
is how/why do they move the OAT, but TIBOBackupService does not. If I
perform a sweep after running a backup with TIBOBackupService, the OAT
will advance as I expected it to. Yes I know this seems odd, but it
does, try it.

What seems even more odd, and this would be very unlikely for anyone
to do, but if I run X number of consecutive backups with
TIBOBackupService, the difference between the OAT and the next
transaction will be X. The OAT will not move again until the database
is put into use.

Thanks for your insight. By the way, your book is excellent. Thanks
again.

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 09:36 AM 24/03/2006, you wrote:
> >--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@> wrote:
> > >
> > > At 08:10 AM 24/03/2006, you wrote:
> > > >My apologies, it should say that the "next transaction"
increases by 1
> > > >and the OAT will never move afterwards. To summarize, after a
backup
> > > >the next transaction goes up by 1
> > >
> > > Of course it does. Backup runs in a transaction.
> >
> > Yes, I understand there must be a transaction. Sorry, I didn't make
> >that clear. But the OAT is stuck after a backup and will not move.
> >
> > >
> > > >and the oldest active transaction freezes.
> > >
> > > The oldest transaction *stays* frozen?
> > >
> > > This could be from one of two causes:
> > >
> > > 1. You have set NoGarbageCollect in your backup options.
> > > 2. NoGarbageCollect was off, but GC had nothing to work on during
> > > gbak, i.e. there is already a stuck transaction.
> > >
> > > Consider also the possibility that you're looking at the stats
before
> > > the backup is finished. If gbak is able to collect any garbage, it
> > > won't show up until gbak's transaction commits.
> >
> >
> >I can wait for an hour and it won't clear up. I originally suspected
> >the same thing. NoGarbageCollection is set to False. I do a sweep
> >everytime before the backup so the OAT is fine before the process
> >starts. Any other ideas?
>
> I don't know what you mean by "the OAT is fine before the process
> starts". The OAT is the oldest transaction that is still active at
> the point at which gstat reads the statistics. It is neither "fine"
> nor "not fine", it's just a fact about the database.
>
> What's more, if you do a sweep before the backup, as you say here,
> then what garbage could be left for GC afterwards that sweep didn't
> already deal with?
>
> Neither sweep nor GC will commit/roll back active
> transactions. Neither of them will "move the OAT forward", which
> seems to be your assumption.
>
> So - have you really got a problem at all with your backups? If the
> OAT is remaining stuck for long periods, then you've got a problem
> with your application's handling of transactions or you've got users
> abandoning sessions. No amount of sweeping and backing up is going
> to fix that.
>
> ./heLen
>