Subject | Re: Can stopping the Firebird Server damage database if a sweep is being performed - Email found in subject |
---|---|
Author | hvlad |
Post date | 2010-05-15T07:08:38Z |
--- In firebird-support@yahoogroups.com, Michael Ludwig <milu71@...> wrote:
When Firebird performs ROLLBACK it have to choose between two ways :
a) mark transaction as dead in TIP, or
b) undo all changes by transaction and mark transaction as committed in TIP.
What to choose is dependent on size of internal undo-log of this tansaction and urgency of rollback (when engine is shutted down, active transactions should be rolled back as fast as possible).
Case (a) means stuck OIT and additional job for cleaning dead versions for next transactions.
Case (b) means slower rollback but without any impact on next transactions.
As sweep cleans backversions from all relations it have ability to move forward stuck OIT - this is the most important difference from regular gc.
Note, if application have good transaction control and there is no very long running transactions, then regular gc (background and\or cooperative) usually cleans almost all unneeded recors versions and sweep have almost nothing to do, except of reading whole database (or not whole - in FB3) and moving OIT forward.
Regards,
Vlad
>TIP is Transaction Inventory Pages. Here Firebird tracks state of all transactions.
> hvlad schrieb am 14.05.2010 um 21:28:50 (-0000):
>
> > > > Sweep interval is not a "number of transactions since the last
> > > > sweep".
>
> > > So, in the case of a SuperServer install, where garbage collection
> > > is turned off, the above definition will be true when the number of
> > > transactions since the last sweep reaches the threshold.
> >
> > OIT can move forward without a sweep. There is two possible reasons
> > for OIT to stuck :
> > a) rollback via TIP
> > b) limbo transaction
>
> OIT, that's the "Oldest Interesting Transaction". But what does "TIP"
> stand for? Simply "Transaction in progress"?
When Firebird performs ROLLBACK it have to choose between two ways :
a) mark transaction as dead in TIP, or
b) undo all changes by transaction and mark transaction as committed in TIP.
What to choose is dependent on size of internal undo-log of this tansaction and urgency of rollback (when engine is shutted down, active transactions should be rolled back as fast as possible).
Case (a) means stuck OIT and additional job for cleaning dead versions for next transactions.
Case (b) means slower rollback but without any impact on next transactions.
> Back versions and garbage collectionAlmost correct. Note, garbage collection (gc) could run not only in background but also as part of regular read activity. This is coperative gc.
>
> > else OIT will move forward without a sweep for years despite of number
> > of transactions.
>
> Very nice :-)
>
> > Also, OIT have no relation with background garbage collection in SS.
>
> So what I understood is that garbage collection is a reqular background
> activity that removes disposable versions of records, also termed "back
> versions". Nobody needs those any more, nobody (i.e. no transaction) is
> interested in them.
> Sweeping, on the other hand, occurs as a protecting measure to preventSweep is total garbage collection. I.e. it cleans whole database. While background and cooperative gc cleans only parts of database.
> the database from drowning in garbage, which is the result of old
> transactions (that were neither committed nor aborted) still lurking
> around and clinging on to those old versions of records.
As sweep cleans backversions from all relations it have ability to move forward stuck OIT - this is the most important difference from regular gc.
Note, if application have good transaction control and there is no very long running transactions, then regular gc (background and\or cooperative) usually cleans almost all unneeded recors versions and sweep have almost nothing to do, except of reading whole database (or not whole - in FB3) and moving OIT forward.
> If such an oldThis is wrong. Hope it explained above.
> transaction is very old (in the example, older than 20,000 transactions
> than the newest transaction), a decision is brought about to simply
> discard those age-old back versions despite the age-old transaction
> maintaining an interest in them - because otherwise that could go on
> forever.
> Is that about correct?Of course not.
>
> And what about that age-old transaction? Is it forcibly aborted?
Regards,
Vlad