Subject | Re: [firebird-support] Oldest transaction far behind... |
---|---|
Author | Ann Harrison |
Post date | 2011-03-22T15:31:55Z |
Kjell,
is the oldest transaction that is not committed. It may be active, it may
be rolled back, or it may be in limbo - prepared as part of a two-phase
commit and not committed.
It's not active, since you said only one transaction was running on
the system.
If it is rolled back, a sweep will fix it. Firebird undoes the changes of a
transaction that issues a roll back, but if there was a server, operating
system, or hardware crash, transactions will be stuck in a rolled back
state until a sweep.
If it's in limbo, you can resolve it with gfix.
Back when InterBase had only classic mode, and when memory was
a very limited resource, keeping a bitmap of the state of all transactions
between the oldest non-committed and current used a serious amount
of memory and keeping the oldest transaction relatively current was
important. Now, not so much.
Good luck
Ann
> Oldest transaction 25545713If this isn't in an FAQ somewhere, it should be. The "Oldest transaction"
> Oldest active 26347481
> Oldest snapshot 26347481
> Next transaction 26347482
>
is the oldest transaction that is not committed. It may be active, it may
be rolled back, or it may be in limbo - prepared as part of a two-phase
commit and not committed.
It's not active, since you said only one transaction was running on
the system.
If it is rolled back, a sweep will fix it. Firebird undoes the changes of a
transaction that issues a roll back, but if there was a server, operating
system, or hardware crash, transactions will be stuck in a rolled back
state until a sweep.
If it's in limbo, you can resolve it with gfix.
Back when InterBase had only classic mode, and when memory was
a very limited resource, keeping a bitmap of the state of all transactions
between the oldest non-committed and current used a serious amount
of memory and keeping the oldest transaction relatively current was
important. Now, not so much.
Good luck
Ann