Slideshow:
Review of the simplifying assumption on logging
Truncating a log file:
log checkpointing
Removing log records physically
and logically
Log checkpointing
in practice
- Previously we made the following
assumption:
- The log is never truncated
This assumption simplifies the discuss on recovery
- We can examine all transactions and determine which ones have committed
- Problem with append-only
log:
- Too large
We need to truncate the log from time to time....
- In log checkpointing, we
shorten the
log file by
"removing" the
log records from
completed transactions:
- Committed transactions (= completed successfull), and
- Aborted transactions (= completely unsuccessfully)
- Comment:
- I put "remove"
on quotes because
log checkpointing will
remove log records
logically:
- We will write a
LOG CHECK POINT
log record into
the log file
- Some log records before this LOG CHECK POINT record will not be examined in the recovery procedure
- We will write a
LOG CHECK POINT
log record into
the log file
See next item of discussion
- I put "remove"
on quotes because
log checkpointing will
remove log records
logically:
- 2 ways to
delete
records from a
log file:
- Physically:
- The log records are actually deleted from the log file
- Logically:
- The log file is
marked with a
special
"check point" record
- Some portion of the log file will be discarded (= ignored when we use it in recovery
- The log file is
marked with a
special
"check point" record
- Physically:
- In practice,
all log records are
kept for the
purpose of:
- accounting !!!
(Especially in banking transactions !!!)
- accounting !!!
- Log checkpointing
in practice:
- A special
check point (log) record is
written into
the log file
- Recovery operations will
mostly use the
portion of the
log file that is
written
after the
check point record
(I wrote "mostly use" because you will see later that we will also need to use a (small) portion of the log file before the CHCK POINT record in recovery)
- A special
check point (log) record is
written into
the log file