Information Technology Reference
In-Depth Information
redo logs.
Logging concurrent transactions. Although the previous example
shows a single transaction, multiple transactions may be executing at once.
In these cases, each record in the log must identify the transaction to which
it belongs.
Asynchronous write-back. Step 3 of a transaction (write-back) can be
asynchronous|once the updates and commit are in the log, the writeback
can be delayed until it is convenient or ecient to perform it.
This flexibility yields two advantages. First, the latency from when a
transaction calls commit() to when the call returns is minimized: as soon
as the commit is appended to the sequential log, the call can return.
Second, the throughput for writeback can be improved because the disk
scheduler gets to operate on large batches of updates.
Two things limit the maximum write-back delay, but both are relatively
loose constraints. First, larger write-back delays mean that crash recovery
may take longer because there may be more updates to read and apply
from the log. Second, the log takes space in persistent storage, which may
in some cases be constrained.
Repeated write-backs are OK. Some of the updates written back dur-
ing recovery may already have been written back before the crash occurred.
For example, in Figure 14.3 all of the records from the persistent log-head
pointer to the volatile one have already been written back, and some of
the records between the volatile log-head pointer may have been writen
back.
It is OK to reapply an from a redo log multiple times because these up-
dates are (and must be) idempotent |they have the same eect whether
Definition: idempotent
executed once or multiple times. For example, if a log record says \write
'hello' do the start of sector 74" then it doesn't matter whether that value
is written once, twice, or a hundred times to sector 74.
Conversely, redo log systems cannot permit non-idempotent records such
as \add 42 to each byte in sector 74."
Restarting recovery is OK. What happens if another crash occurs
during recovery? When the system restarts, it simply begins recovery
again. The same sequence of updates to committed transactions will be
discovered in the log, and the same write-backs will be issued. Some of
the write-backs may already have finished before the first crash or during
some previous, but repeating them causes no problems.
Garbage collection constraints. Once write-back completes and is
persistently stored for a committed transaction, its space in the log can
be reclaimed.
 
Search WWH ::




Custom Search