hvlad schrieb am 15.05.2010 um 07:08:38 (-0000):

> > > > > Sweep interval is not a "number of transactions since the
> > > > > last sweep".

According to the book (p.518), it is the maximum size of the gap between
the OIT and the OAT before automatic sweep will kick in.

> > > OIT can move forward without a sweep. There is two possible
> > > reasons for OIT to stuck :
> > > a) rollback via TIP
> > > b) limbo transaction

According to the book, again (p.515), a limbo transaction is the result
of a failed two-phase commit involving multiple databases. So that's too
advanced for me right now. :)

What does "rollback via TIP" (Transaction Inventory Page) mean? Just a
ROLLBACK, like, via ISQL?

> 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.

> > 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.
>
> Almost correct. Note, garbage collection (gc) could run not only in
> background but also as part of regular read activity. This is
> coperative gc.

Seems that cooperative GC is what happens on CS (book, p.517), whereas
SS works by tagging obsolete versions and relying on the background
thread to clean them up. But maybe both tactics have been combined to
work on both architectures since the book was published.

> > Sweeping, on the other hand, occurs as a protecting measure to
> > prevent 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.
>
> Sweep is total garbage collection. I.e. it cleans whole database.
> While background and cooperative gc cleans only parts of database. As
> sweep cleans backversions from all relations it have ability to move
> forward stuck OIT - this is the most important difference from regular
> gc.

And it has this ability because it finds back versions belonging to a
rolled-back or limbo transaction that are disposable but have not been
removed because no other transaction has encountered those corners of
the database during its activity?

And those back versions are only left over because when the transaction
was rolled back, its changes weren't cleaned up immediately and it was
not marked as committed in the TIP, so case (b) in your explanation? But
marked as dead instead, and the work left to be done later, so case (a)?

> 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.

Which it can do because after having done the sweep the engine knows
that there are no versions belonging to that transaction hanging around
any more?

--
Michael Ludwig