TDDC94
Fall 2007
Rehash from last time: 2PL Examples
TDDC94—Database Recovery
based on Chapter 19
Almut Herzog
Attentec AB
almhe@attentec.se
almhe@ida.liu.se
September 28,
2007
Static 2PL:
Strict 2PL:
Rigorous 2PL:
read_lock(X)
read(X)
read_lock(Y)
read(Y)
write_lock(X)
write(X)
read_lock(Z)
unlock(X)
unlock(Y)
read(Z)
unlock(Z)
commit
write_lock(X)
read_lock(Y)
read_lock(Z)
read(X)
read(Y)
unlock(Y)
write(X)
unlock(X)
read(Z)
unlock(Z)
commit
read_lock(X)
read(X)
read_lock(Y)
read(Y)
write_lock(X)
write(X)
read_lock(Z)
unlock(Y)
read(Z)
unlock(Z)
commit
unlock(X)
read_lock(X)
read(X)
read_lock(Y)
read(Y)
write_lock(X)
write(X)
read_lock(Z)
read(Z)
commit
unlock(X)
unlock(Y)
unlock(Z)
TDDC94—Recovery
Lecture Overview
User 4
Updates
Answers
UserQueries
3
Updates
Answers
UserQueries
2
UserQueries
1
Updates
Answers
Updates Queries Answers
„
„
Database
2
Types of failures
Model
Real World
Basic 2PL:
Processing of
queries and updates
Database
management
system
Failures are generally classified in transaction, instance
or media failures
Media failures can usually be addressed by restoring
from back-up only.
‰
‰
„
Access to stored data
„
cold back-up
hot back-up
For instance failures, only the last clean state must be
restored = all committed transactions must be restored.
Non-committed transactions must be rolled back.
Transactions failures: …
Physical
database
TDDC94—Recovery
3
Transaction Rollback
„
„
„
‰
cascadeless: T reads only items that were written by
committed transactions
strict:: T only accesses (read or write) items that are
committed (= not written in an active transaction)
Strict schedules ensure that transaction rollback is
usually not triggered by regular actions from other
transactions.
TDDC94—Recovery
Author: Almut Herzog
4
Writing back cached disk blocks
When does transaction rollback occur?
different ways of transaction handling in the last lecture
commonly DBMSs guarantee at least cascadeless, more
often strict schedules:
‰
TDDC94—Recovery
5
„
„
„
„
Cached disk blocks are only written back to disk if the
dirty bit is set.
In-place updating: writes the buffer back to the same
location (overwrites old data)
Shadow paging: writes to a different location, so the
before-image can be kept.
We look at in-place updating first. This requires a log file
(or typically two…).
‰
TDDC94—Recovery
Log file entries appear in time order:
[write_item, T, X, old_value, new_value]
6
1
TDDC94
Fall 2007
Checkpoints in the System Log and Fuzzy
Checkpointing
„
„
checkpoint: a periodically occurring point in time when all
DBMS pages are written back to the data file,
also: a type of log entry:
„
‰
Checkpoint:
‰
2.
3.
4.
suspend execution of transactions temporarily
force-write all main memory buffers that have been modified
to the data file
write a checkpoint record to the logs, force logs to disk
resume execution
„
„
fuzzy checkpointing
TDDC94—Recovery
7
Deferred Update
„
„
„
a redo log for committed actions since the last checkpoint
an undo or rollback log for currently active, uncommitted
actions
no-steal: an uncommitted transaction’s changes cannot
be written to the data file (page must remain cached) due
to pin-bit;
steal: uncommitted changes are flushed to the data file
force: committed changes are forced to disk by flushing
the page; no-force: committed changes are not
necessarily in the data file yet
TDDC94—Recovery
8
Deferred Update
deferred update = data files are not updated until a
transaction commits
or more precise
‰
[write_item, T, X, old_value, new_value]
typically the DBMS maintains two logs:
„
„
„
write-ahead logging: before the data file is overwritten
with the after image, the before and after images are in a
log file
[checkpoint]
1.
„
Write-Ahead Logging, Steal/No-Steal, and
Force/No-Force
T1
T2
data files are not updated until a transaction reaches its
commit point
T3
commit point: all write operations are recorded in the
redo log file and the redo log file is flushed to disk
Known as the NO-UNDO/REDO recovery algorithm.
T4
T5
system crash
[checkpoint]
TDDC94—Recovery
9
Immediate Update
„
„
1.
2.
TDDC94—Recovery
10
Immediate Update: UNDO/NO-REDO
When T issues a write command, the data file can be
updated immediately.
The log files are written with write-ahead logging in case
of failure during data file writing.
All write operations are recorded in the data file before
the transaction commits Æ UNDO/NO-REDO
Transaction can commit before changes are in the data
file Æ UNDO/REDO
T1
T2
T3
T4
T5
system crash
[checkpoint]
TDDC94—Recovery
Author: Almut Herzog
11
TDDC94—Recovery
12
2
TDDC94
Fall 2007
Immediate Update: UNDO/REDO
Shadow Paging
T1
„
„
T2
T3
„
T4
„
Not in-place updating but writing cached, modified disk
blocks to a different portion of the data file.
When a transaction begins executing, the current
directory of disk pointers is copied into a shadow
directory.
The shadow directory is not modified during the
transaction.
When a write operation is issued, the write is done in a
new disk space and the current directory is updated.
T5
system crash
[checkpoint]
TDDC94—Recovery
TDDC94—Recovery
13
Shadow Paging
14
Shadow Paging: New Transaction starts
Current Directory
1
2
2
1
1
2
1
3
4
Shadow Directory
Current Directory
1
3
6
5
6
5
4
5
4
6
5
4
6
2
2
3
TDDC94—Recovery
TDDC94—Recovery
15
16
Shadow Paging
Shadow Directory
Current Directory
„
1
1
2
2
1
3
Advantages:
‰
„
3
New 5
‰
4
no log files for single-user systems
Disadvantages
‰
6
5
5
6
6
3
Shadow Paging: New Transaction updates
an item on page 5
4
3
5
4
‰
locations change on disk, difficult to keep disk blocks
together
large directories are not handled well
at commit time there is garbage collection overhead
5
4
2
6
3
TDDC94—Recovery
Author: Almut Herzog
17
TDDC94—Recovery
18
3