Bernard Cleary wrote:

I have a situation I just cannot understand and I don't think I have read about.

Oldest transaction   3822
Oldest active        3816
Oldest snapshot      3816
Next transaction     3823

The bit I don't understand is how the Oldest Transaction can be greater than the Oldest Active. This information was taken when there was no connections to a database and a manual sweep had been done.

Vlad Horsun answers:

This is usual picture if you look at header page just after the sweep performed in exclusive mode (or if there was no transaction started during the sweep).

When any transaction starts it:

  1. calculated new transaction number as follows :
    1. fetched header page
    2. incremented Next transaction
    3. update header page with transaction numbers stored in memory variables (actually members of dbb)
    4. writes header page on disk
  2. calculated new OIT, OAT and OST numbers and :
    1. stored OIT, OAT and OST in dbb members (dbb_oldest_transaction, dbb_oldest_active, dbb_oldest_snapshot respectively)
    2. stored OIT and OST in transaction members (tra_oldest and tra_oldest_active respectively)

When sweep transaction successfully ends it assigns OIT = tra_oldest_active - 1 and writes this new OIT number at header page. Sweep transaction do not update OAT and OST at header page at this moment thus they leave with old values

If there are no concurrent transactions at time when our transaction starts then our transaction always calculated OAT = OST = Next

This is not a bug, i think. Must note that OAT and OST have sense (for engine) only if there are active transactions. It our case there are no transactions after the sweep ends. When new transaction started they wil recalculate all numbers but write on disk only new Next value. If second transaction started in the same engine process they will update all numbers on disk while bumping Next value.

Like this post? Share on: TwitterFacebookEmail

Related Articles


Firebird Community



Gems from Firebird Support list