Subject | Re: [firebird-support] Re: OAT stuck after backup |
---|---|
Author | Helen Borrie |
Post date | 2006-03-23T23:59:02Z |
At 09:36 AM 24/03/2006, you wrote:
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
>--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:I don't know what you mean by "the OAT is fine before the process
> >
> > 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?
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