| Subject | Re: Stop tracking through redo log (was: Batch insert performance) |
|---|---|
| Author | Adam |
| Post date | 2006-08-25T06:49:01Z |
--- In firebird-support@yahoogroups.com, "PenWin" <penwin@...> wrote:
Firebird does not require an undo log to rollback information. Because
it is natively MGA, the record versions are stored on the data pages
alongside the transaction that wrote that record version.
The status of each transaction is stored in the TIP. When a
transaction encounters a record version from a rolled back
transaction, it does the cleanup work (or flags it so the garbage
collection does, not 100% sure of the mechanism). In fact, that is how
it used to work for a long time before the undo log was implemented in
Firebird.
So why use the log at all? When a client explicitly calls rollback,
without the undo log the garbage was left behind for someone else to
deal with. This means that later on, someone else is experiencing
slowness. With the undo log, the client transaction reverses out all
the work it did, then commits. This means there is no garbage penalty.
It also allows for nested transactions (savepoints).
The problem of course with undo logs is that if your transaction
consists of lots of operations, it gets large, and may starve the
server of resources.
I am not sure about specific parameters, or whether it is
configurable, but I believe it is around 5000 operations before the
undo log is abandoned.
As Rick says, there is the ability (at the API level anyway) to
explicitly tell Firebird to not keep the redo log at all.
But Atomicity is never compromised, Firebird doesn't turn into an
AutoCommit pumpkin at midnight or anything like that.
Adam
>going to
> Pardon my ignorance, but what exactly does "Firebird is eventually
> stoplog is
> tracking it through its redo log" mean? Does it mean that when the
> full, Firebird will not be able to rollback any more updates (itwill behave
> as if it was commiting them right away) or does it mean that it will"filling up
> dropthose extra updates? Also, what is the critical factor for
> the redo log"? Number of INSERTs? Number of queries? Number of changedLots of questions, one response, don't panic.
> records? Total size of the changed records?
Firebird does not require an undo log to rollback information. Because
it is natively MGA, the record versions are stored on the data pages
alongside the transaction that wrote that record version.
The status of each transaction is stored in the TIP. When a
transaction encounters a record version from a rolled back
transaction, it does the cleanup work (or flags it so the garbage
collection does, not 100% sure of the mechanism). In fact, that is how
it used to work for a long time before the undo log was implemented in
Firebird.
So why use the log at all? When a client explicitly calls rollback,
without the undo log the garbage was left behind for someone else to
deal with. This means that later on, someone else is experiencing
slowness. With the undo log, the client transaction reverses out all
the work it did, then commits. This means there is no garbage penalty.
It also allows for nested transactions (savepoints).
The problem of course with undo logs is that if your transaction
consists of lots of operations, it gets large, and may starve the
server of resources.
I am not sure about specific parameters, or whether it is
configurable, but I believe it is around 5000 operations before the
undo log is abandoned.
As Rick says, there is the ability (at the API level anyway) to
explicitly tell Firebird to not keep the redo log at all.
But Atomicity is never compromised, Firebird doesn't turn into an
AutoCommit pumpkin at midnight or anything like that.
Adam