Slideshow:
Performing log checkpointing
without stopping
database processing operation
Remember that the goal of "log checkpointing" is:
|
Each type of log file (UNDO/REDO/etc) has a different log checkpointing algorithm
When is an
UNDO log record no longer
necessary ???
When is an
UNDO log record no longer
necessary ???
-
Explanation
Why:
- Non-quiescent
checkpointing:
- Non-quiescent
checkpointing =
performaining
the log checkpointing procedure
without
having to
stop the
database system
I.e.:
- We perform the log checkpointing procedure while transactions are active !!!
- Non-quiescent
checkpointing =
performaining
the log checkpointing procedure
without
having to
stop the
database system
- Observation:
- When you find a <COMMIT T>
record for
transaction T, then:
- The undo log records written on behalf of the transaction T are now unnecessary !!!
Graphically:
- Reason:
- The undo log records is
used to
roll back the
updates made by
transaction T in case
transaction T did
not write all its updates
to disk
due to
system failure
(These log records is like an insurance policy for an accident)
- The log record <COMMIT T>
is proof (= evidence) that
transaction T has
writte all its updates
onto the disk !!!
(This is enforced by UNDO log update rule #2)
- The log records
(insurance policy) are
therefore
no longer needed !!!
(And can be removed/truncated !!)
- The log records
(insurance policy) are
therefore
no longer needed !!!
- The undo log records is
used to
roll back the
updates made by
transaction T in case
transaction T did
not write all its updates
to disk
due to
system failure
- When you find a <COMMIT T>
record for
transaction T, then:
- How to to
truncate an
UNDO log:
- Find the
first uncommitted transaction
in the (undo) log:
- You can remove
everything before
this
<START Tk>
record, because:
- All log records above the first uncommitted transaction belongs to a committed transaction !!!
- Find the
first uncommitted transaction
in the (undo) log: