Review Lecture 30
-
Upload
parmida-bahram -
Category
Documents
-
view
16 -
download
1
description
Transcript of Review Lecture 30
![Page 1: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/1.jpg)
ReviewLecture 30
![Page 2: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/2.jpg)
Administrivia• Office hours 1:30 – 2:15 today• Final Exam May 16 8-11 a.m.• Location: 22 Warren• Topics since Midterm 2
– Transactions, concurrency control, locking, recovery
– Logical design, ER Modeling, Functional Dependencies, Normalization, Data Mining
– Guest lectures• Cumulative questions from semester
Review today
Review Tuesday
![Page 3: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/3.jpg)
• Concurrent users introduce anomalies– Dirty reads (WR): T2 reads a value A that T1 wrote
but didn’t commit– Unrepeatable Reads (RW): T1 reads a value A that is
then written by T2– Lost Updates (WW): T2 overwrites a write by T1
• Serializable schedules: – A schedule that is equivalent to some serial execution of
the transactions.• Definition: Two operations conflict if:
– They are by different transactions, – they are on the same object, – and at least one of them is a write.
Concurrency
R(A) R(B)W(A) W(B)
R(A) R(B) W(B)
T1:
T2: W(A)
![Page 4: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/4.jpg)
Conflict Serializability – Intuition• A schedule S is conflict serializable if:
– You are able to transform S into a serial schedule by swapping consecutive non-conflicting operations of different transactions.
• Example:
R(A) R(B)W(A) W(B)
R(A) W(A) R(B)W(B) W(A)
R(B)R(B)
R(A)
W(B)
W(A)
W(B)
R(A)
R(A) R(B)W(A) W(B)
R(A) W(A) R(B) W(B)
T1:
T2:
T1:T2:
![Page 5: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/5.jpg)
Dependency Graph
• Dependency graph: – One node per Xact– Edge from Ti to Tj if:
• An operation Oi of Ti conflicts with an operation Oj of Tj and
• Oi appears earlier in the schedule than Oj.
• Theorem: Schedule is conflict serializable if and only if its dependency graph is acyclic.
Ti Tj
![Page 6: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/6.jpg)
• A schedule that is not conflict serializable:
• The cycle in the graph reveals the problem. • The output of T2 depends on T1’s value of A,
and the output of T1 depends on T2’s value of B.
Another Example
T1 T2A
B
Dependency graph
T1: R(A), W(A), R(B), W(B)T2: T1: R(A), W(A), R(B), W(B)T2: R(A), W(A), R(B), W(B)T1: R(A), W(A), R(B), W(B)T2: R(A), W(A), R(B), W(B)T1: R(A), W(A), R(B), W(B)T2: R(A), W(A), R(B), W(B)T1: R(A), W(A), R(B), W(B)T2: R(A), W(A), R(B), W(B)
![Page 7: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/7.jpg)
Review: Lock-Based Concurrency Control
Two-phase Locking (2PL) Protocol:– Each Xact must obtain:
• a S (shared) lock on object before reading, and • an X (exclusive) lock on object before writing.
– If an Xact holds an X lock on an object, no other Xact can get a lock (S or X) on that object.
– System can obtain these locks automatically– Two phases: acquiring locks, and releasing them
• No lock is ever acquired after one has been released• “Growing phase” followed by “shrinking phase”.
•Ensures acyclic dependency graphs•Allows only conflict serializable schedules
![Page 8: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/8.jpg)
Review: Strict 2 Phase Locking
• Advantage: no other transaction reads anything you write until you commit.– e.g a transaction will only read committed data.
• Disadvantage: transactions end up waiting.
• Strict Two-phase Locking (Strict 2PL) Protocol:– Same as 2PL, except All locks held are released only
when the transaction completes
•Ensures acyclic dependency graphs•Allows only conflict serializable schedules•Allows only strict schedules
No values written by an Xact T can be read or overwritten until T commits or aborts.
![Page 9: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/9.jpg)
Deadlocks• Deadlock: Cycle of transactions waiting for locks
to be released by each other.• Two ways of dealing with deadlocks:
– Deadlock prevention• Wait-die: new transactions aren’t allowed to wait• Wound-wait: old transactions don’t have to wait
• Deadlock detection– Create a waits-for graph:– There is an edge from Ti to Tj if Ti is waiting for Tj to
release a lock• Periodically check for cycles in the waits-for
graph
![Page 10: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/10.jpg)
Deadlock Detection (Continued)
Example:
T1: S(A), S(D), S(B)T2: X(B) X(C)T3: S(D), S(C), X(A)T4: X(B)
T1 T2
T4 T3
S(A)S(D)
X(B)S(B)
S(D)S(C)
X(C)X(B)
X(A)
![Page 11: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/11.jpg)
• Multi-granularity locking– Use database containment hierarchy to vary
granularity of locks • Full table insert: lock table vs read 1 row: lock
record
• Locking in indexes– don’t want to lock a B-tree root for a whole
transaction!– actually do non-2PL “latches” in B-trees
• CC w/out locking– “optimistic” concurrency control
Lock Management
Tuples
Tables
Pages
Databasecontains
![Page 12: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/12.jpg)
Multiple Granularity Lock Protocol
• Each Xact starts from the root of the hierarchy.
• Special SIX lock used when reading many records, and updating a few. – SIX lock conflicts are all S and IX conflicts
(e.g. only compatible with IS locks).• To get S or IS lock on a node, must hold
IS or IX on parent node.• To get X or IX or SIX on a node, must
hold IX or SIX on parent node.• Must release locks in bottom-up order.
![Page 13: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/13.jpg)
Multi-Granularity Example• Rules
– Each Xact starts from the root of the hierarchy.– To get S or IS lock, must hold IS or IX on parent.– To get X or IX or SIX, must hold IX or SIX on
parent.– Must release locks in bottom-up order.
Tuple 1
Sailor Table
Page 1
Database
Page 2
Tuple 2 Tuple 4Tuple 3
T1 wants to read & change tuple 2
T2 wants to read all of Page 1
•T1 gets IX lock on DBMS, Sailor, Page 1
•T1 gets X lock on Tuple 2 & changes it
•T2 gets IS lock on DBMS, Sailor
•T2 tries to get S lock on Page 1, but S conflicts with IX lock. T2 blocks.
What if T2 had started first?
IS IX SIX
IS
IXSIX
S X
S
X
T1:IX
T1:IX
T1:IX
T1:X
T2:IS
T2:IS
T2:wait
![Page 14: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/14.jpg)
Multi-Granularity Example• Rules
– Each Xact starts from the root of the hierarchy.– To get S or IS lock, must hold IS or IX on parent.– To get X or IX or SIX, must hold IX or SIX on
parent.– Must release locks in bottom-up order.
Tuple 1
Sailor Table
Page 1
Database
Page 2
Tuple 2 Tuple 4Tuple 3
T1 wants to read & change tuple 2
T2 wants to read all of Page 1
•T2 gets IS lock on DBMS, Sailor
•T2 gets S lock on Page 1
•T1 gets IX lock on DBMS, Sailor
•T1 tries to get IX lock on Page 1, waits
IS IX SIX
IS
IXSIX
S X
S
X
T1:IX
T1:IX
T1:waits
T2:IS
T2:IS
T2:S
![Page 15: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/15.jpg)
Locking in B+ Trees
24 30
7 9 14 15
13
20
1. Higher levels of the tree only direct searches for leaf pages.
2. For inserts:– a node must be X locked only
if a split can propagate up to it from the modified leaf.
– Example:insert 9vs insert 15
16
15
16
• We can exploit these observations to design efficient locking protocols that guarantee serializability even though they violate 2PL.
![Page 16: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/16.jpg)
Simple Locking in B+ Trees• Search: Start at root and go down;
– S lock node.– Unlock its parent.
• Insert/Delete: Start at root and go down, – X lock node. – If node is safe, release all locks on ancestors.
• Safe node: Node such that changes will not propagate up beyond this node.– Inserts: Node is not full.– Deletes: Node is not half-empty.
![Page 17: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/17.jpg)
Example
ROOT
A
B
C
D E
F
G H I
20
35
20*
38 44
22* 23* 24* 35* 36* 38* 41* 44*
T1: Search 38T2: Insert 45T3: Insert 25
23
T1:S
T1:S
T1:S
T1:S
T2:X
T2:X
T2:X
T2:X
• Search: – S lock node.– Unlock its
parent.• Insert/Delete:
– X lock node. – If node is
safe, release all locks on ancestors.
T3:X
T3:X
T3:X
T3:X T3:X
![Page 18: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/18.jpg)
Optimistic CC (Kung-Robinson)
• Locking is a conservative approach in which conflicts are prevented. Disadvantages:
– Lock management overhead.– Deadlock detection/resolution.– Lock contention for heavily used objects.
• If conflicts are rare, we might be able to gain concurrency by not locking, and instead checking for conflicts before Xacts commit.
![Page 19: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/19.jpg)
Kung-Robinson Model• Xacts have three phases:
– READ: Xacts read from the database, but make changes to private copies of objects.
– VALIDATE: Check for conflicts.
– WRITE: Make local copies of changes public.
Tj
R V W
14
Buffer Pool
23 27
14 23Tj private copies
Read
s fro
m
Writes to
Writes back
• Validation, and Write phase are done inside a critical section!– i.e., Nothing else goes on concurrently.
![Page 20: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/20.jpg)
Validation Phase
• Tests conditions that are sufficient to ensure that no conflict occurred.– If conflict did occur, restart transaction.
• Each Xact is assigned a timestamp at end of READ phase, just before validation begins. – Also keep track of xact phase begin & end
times
• Compute – ReadSet(Tj): Set of objects read by Xact Tj.– WriteSet(Tj): Set of objects modified by Tj.
![Page 21: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/21.jpg)
Validation Test 1 for Tj: no overlap• For all i and j such that Ti < Tj, check that Ti
completes write phase before Tj begins read phase.
Ti
TjR V W
R V W
Implies a serial order for Ti and Tj; Ti came first.
![Page 22: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/22.jpg)
Validation Test 2 for Tj: Overlapping read phase
• For all i and j such that Ti < Tj, check that:
– Ti completes before Tj begins its Write phase +– WriteSet(Ti) ReadSet(Tj) is empty.
Ti
TjR V W
R V W Ensures Tj does not read any object written by Ti. Implies a serial order; Tj might write same set of objects,
but writes are in a serial order; Ti’s writes come first.
![Page 23: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/23.jpg)
Validation Test 3 for Tj: Overlapping write phase
• For all i and j such that Ti < Tj, check that:
– Ti completes Read phase before Tj does +– WriteSet(Ti) ReadSet(Tj) is empty +– WriteSet(Ti) WriteSet(Tj) is empty.
Ti
TjR V W
R V W Ensures Tj does not read or write any object written by Ti. Implies a serial order; Tj reads and writes are to different
objects than those written by Ti.
![Page 24: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/24.jpg)
Optimistic CC Overhead• Must record read/write activity in ReadSet
and WriteSet per Xact.– Must create and destroy these sets as needed.
• Must check for conflicts during validation, and must make validated writes ``global’’.– Critical section can reduce concurrency.– Scheme for making writes global can reduce
clustering of objects.
• Optimistic CC restarts Xacts that fail validation.– Work done so far is wasted; requires clean-up.
![Page 25: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/25.jpg)
Write-Ahead Logging (WAL)
• The Write-Ahead Logging Protocol: Must force the log record for an update before
the corresponding data page gets to disk. Must force all log records for a Xact before
commit. (or, a transaction is not committed until all of its log records including its “commit” record are on the stable log.)
• #1 (with UNDO info) helps guarantee Atomicity.
• #2 (with REDO info) helps guarantee Durability.
• This allows us to implement Steal/No-Force buffer management policy
![Page 26: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/26.jpg)
Buffer Management summary
Force
No Force
No Steal Steal
No REDO
No UNDO UNDO
No REDO
UNDOREDO
No UNDOREDO
Force
No Force
No Steal Steal
Slowest
Fastest
PerformanceImplications
Logging/RecoveryImplications
![Page 27: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/27.jpg)
WAL & the Log
• Each log record has a unique Log Sequence Number (LSN). – LSNs always increasing.
• Each data page contains a pageLSN.– The LSN of the most recent log record
for an update to that page.• System keeps track of flushedLSN.
– The max LSN flushed so far.• WAL: Before page i is written to DB
log must satisfy:
pageLSNi flushedLSN
LSNs pageLSNs
RAM
flushedLSN
pageLSN
Log recordsflushed to disk
“Log tail” in RAM
flushedLSN
DB
![Page 28: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/28.jpg)
Log Records prevLSN is the LSN of the previous log record written by this Xact (so records of an Xact form a linked list backwards in time)
Possible log record types:• Update, Commit, Abort• Checkpoint (for log
maintenance)• Compensation Log
Records (CLRs) – for UNDO actions
• End (end of commit or abort)
LSNprevLSNXIDtype
lengthpageID
offsetbefore-imageafter-image
LogRecord fields:
updaterecordsonly
![Page 29: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/29.jpg)
Other Log-Related State• Two in-memory tables:• Transaction Table
– One entry per currently active Xact.• entry removed when Xact commits or aborts
– Contains XID, status (running/committing/aborting), and lastLSN (most recent LSN written by Xact).
• Dirty Page Table:– One entry per dirty page currently in buffer pool.– Contains recLSN -- the LSN of the log record
which first caused the page to be dirty.
![Page 30: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/30.jpg)
The Big Picture: What’s Stored Where
DB
Data pageseachwith apageLSN
Xact TablelastLSNstatus
Dirty Page TablerecLSN
flushedLSN
RAM
LSNprevLSNXIDtype
lengthpageID
offsetbefore-imageafter-image
LogRecords
LOG
Master record
![Page 31: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/31.jpg)
Example
GDE
Page 1 LSN:2
ABC
Page 2 LSN:4
HIJ
Page 3 LSN:6
OPQ
Page 4 LSN:8
Buffer Frame 1 Buffer Frame 2 Buffer Frame 3
1. T1 update 2 (DEF)(assume written to disk)2. T2 update 3 (KLM)3. T2 update 1 (QRS)4. T1 update 2 (WXY)5. T2 commit6. T1 update 4 (RST)7. SYSTEM CRASH
LSN Prev XactID Type pageID Before After
11 null T1 update 2 ABC DEF 12 null T2 update 3 HIJ KLM
ABC
Page 2 LSN:4
DEF
Page 2 LSN:11
13 12 T2 update 1 GDE QRS 14 11 T1 update 2 DEF WXY 15 13 T2 commit and end
16 14 T1 update 4 OPQ RST SYSTEM CRASH
KLM
Page 3 LSN:12
WXY
Page 2 LSN:14
To disk
GDE
Page 1 LSN:2
HIJ
Page 3 LSN:6
KLM
Page 3 LSN:12
QRS
Page 1 LSN:13
OPQ
Page 4 LSN:8
RST
Page 4 LSN:16
BEGIN_CHKPT
END_CHKPT
DEF
Page 2 LSN:11
![Page 32: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/32.jpg)
Crash Recovery: Big Picture
Start from a checkpoint (found via master record).
Three phases. Need to do:– Analysis - Figure out which
Xacts committed since checkpoint, which failed.
– REDO all actions.(repeat history)
– UNDO effects of failed Xacts.
Oldest log rec. of Xact active at crash
Smallest recLSN in dirty page table after Analysis
Last chkpt
CRASH
A R U
![Page 33: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/33.jpg)
End result – goal of recovery
GDE
Page 1 LSN:2
ABC
Page 2 LSN:4
HIJ
Page 3 LSN:6
OPQ
Page 4 LSN:8
1. T1 update 2 (DEF)2. T2 update 3 (KLM)3. T2 update 1 (QRS)4. T1 update 2 (WXY)5. T2 commit6. T1 update 4 (RST)7. SYSTEM CRASH
KLM
Page 3 LSN:12
QRS
Page 1 LSN:2
• T1 aborts• Roll back
updates if they made it to disk.
• T2 commits• Re-apply
updates if needed
![Page 34: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/34.jpg)
Recovery: The Analysis Phase• Re-establish knowledge of state at checkpoint.
– via transaction table and dirty page table stored in the checkpoint
• Scan log forward from checkpoint.– End record: Remove Xact from Xact table.– All Other records: Add Xact to Xact table, set lastLSN=LSN,
change Xact status on commit.– also, for Update records: If page P not in Dirty Page Table,
Add P to DPT, set its recLSN=LSN.
• At end of Analysis…– transaction table says which xacts were active at time of
crash.– DPT says which dirty pages might not have made it to disk
![Page 35: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/35.jpg)
Analysis
GDE
Page 1 LSN:2
DEF
Page 2 LSN:11
HIJ
Page 3 LSN:6
OPQ
Page 4 LSN:8
Buffer Frame 1 Buffer Frame 2 Buffer Frame 3
Xact ID
Last LSN
State
T1 11 U
ABC
Page 2 LSN:4
DEF
Page 2 LSN:11
KLM
Page 3 LSN:12
WXY
Page 2 LSN:14
GDE
Page 1 LSN:2
HIJ
Page 3 LSN:6
KLM
Page 3 LSN:12
QRS
Page 1 LSN:13
OPQ
Page 4 LSN:8
RST
Page 4 LSN:16
LSN Prev XactID Type pageID Before After
11 null T1 update 2 ABC DEF 12 null T2 update 3 HIJ KLM 13 12 T2 update 1 GDE QRS 14 11 T1 update 2 DEF WXY 15 13 T2 commit and end
BEGIN_CHKPT
END_CHKPTXact Table
T2 12 U T2 13 U
T1 14 U T2 15 C
1. Create entries the Xact table with xacts active at time of crash.
![Page 36: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/36.jpg)
Analysis
GDE
Page 1 LSN:2
DEF
Page 2 LSN:11
HIJ
Page 3 LSN:6
OPQ
Page 4 LSN:8
Buffer Frame 1 Buffer Frame 2 Buffer Frame 3
Xact ID
Last LSN
State
ABC
Page 2 LSN:4
DEF
Page 2 LSN:11
KLM
Page 3 LSN:12
WXY
Page 2 LSN:14
GDE
Page 1 LSN:2
HIJ
Page 3 LSN:6
KLM
Page 3 LSN:12
QRS
Page 1 LSN:13
OPQ
Page 4 LSN:8
RST
Page 4 LSN:16
Page ID rec LSN
LSN Prev XactID Type pageID Before After
11 null T1 update 2 ABC DEF 12 null T2 update 3 HIJ KLM 13 12 T2 update 1 GDE QRS 14 11 T1 update 2 DEF WXY 15 13 T2 commit and end
BEGIN_CHKPT
END_CHKPTXact Table
Dirty Page Table
T1 14 U
2 11
3 12
1 13
2. Create entries in the Dirty Page table with pages that might not have made it to disk.
![Page 37: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/37.jpg)
Phase 2: The REDO Phase
• We Repeat History to reconstruct state at crash:– Reapply all updates (even of aborted Xacts!), redo CLRs.
• Scan forward from log rec containing smallest recLSN in DPT. Q: why start here?
• For each update log record or CLR with a given LSN, REDO the action unless: – Affected page is not in the Dirty Page Table, or– Affected page is in D.P.T., but has recLSN > LSN, or– pageLSN (in DB) LSN. (this last case requires I/O)
• To REDO an action:– Reapply logged action.– Set pageLSN to LSN. No additional logging, no forcing!
![Page 38: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/38.jpg)
Redo
GDE
Page 1 LSN:2
DEF
Page 2 LSN:11
HIJ
Page 3 LSN:6
OPQ
Page 4 LSN:8
Buffer Frame 1 Buffer Frame 2 Buffer Frame 3
Xact ID
Last LSN
State
ABC
Page 2 LSN:4
DEF
Page 2 LSN:11
KLM
Page 3 LSN:12
WXY
Page 2 LSN:14
GDE
Page 1 LSN:2
HIJ
Page 3 LSN:6
KLM
Page 3 LSN:12
QRS
Page 1 LSN:13
OPQ
Page 4 LSN:8
RST
Page 4 LSN:16
Page ID rec LSN
LSN Prev XactID Type pageID Before After
11 null T1 update 2 ABC DEF 12 null T2 update 3 HIJ KLM 13 12 T2 update 1 GDE QRS 14 11 T1 update 2 DEF WXY 15 13 T2 commit and end
BEGIN_CHKPT
END_CHKPTXact Table
Dirty Page Table
T1 14 U
2 11
3 12
1 13
Step 1. Find lowest rec LSN in Dirty Page Table.
![Page 39: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/39.jpg)
Redo
GDE
Page 1 LSN:2
DEF
Page 2 LSN:11
HIJ
Page 3 LSN:6
OPQ
Page 4 LSN:8
Buffer Frame 1 Buffer Frame 2 Buffer Frame 3
Xact ID
Last LSN
State
ABC
Page 2 LSN:4
DEF
Page 2 LSN:11
KLM
Page 3 LSN:12
WXY
Page 2 LSN:14
GDE
Page 1 LSN:2
HIJ
Page 3 LSN:6
KLM
Page 3 LSN:12
QRS
Page 1 LSN:13
OPQ
Page 4 LSN:8
RST
Page 4 LSN:16
Page ID rec LSN
LSN Prev XactID Type pageID Before After
11 null T1 update 2 ABC DEF 12 null T2 update 3 HIJ KLM 13 12 T2 update 1 GDE QRS 14 11 T1 update 2 DEF WXY 15 13 T2 commit and end
BEGIN_CHKPT
END_CHKPTXact Table
Dirty Page Table
T1 14 U
2 11
3 12
1 13
Step 2. Scan forward and redo all redoable log records.
![Page 40: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/40.jpg)
Redo
GDE
Page 1 LSN:2
DEF
Page 2 LSN:11
HIJ
Page 3 LSN:6
OPQ
Page 4 LSN:8
Buffer Frame 1 Buffer Frame 2 Buffer Frame 3
Xact ID
Last LSN
State
ABC
Page 2 LSN:4
DEF
Page 2 LSN:11
KLM
Page 3 LSN:12
WXY
Page 2 LSN:14
GDE
Page 1 LSN:2
HIJ
Page 3 LSN:6
KLM
Page 3 LSN:12
QRS
Page 1 LSN:13
OPQ
Page 4 LSN:8
RST
Page 4 LSN:16
Page ID rec LSN
LSN Prev XactID Type pageID Before After
11 null T1 update 2 ABC DEF 12 null T2 update 3 HIJ KLM 13 12 T2 update 1 GDE QRS 14 11 T1 update 2 DEF WXY 15 13 T2 commit and end
BEGIN_CHKPT
END_CHKPTXact Table
Dirty Page Table
T1 14 U
2 11
3 12
1 13
1. Reapply LSN 11 T1 update 2 (DEF)
DEF
Page 2 LSN:11
KLM
Page 3 LSN:12
2. Reapply LSN 12 T2 update 3 (KLM)
![Page 41: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/41.jpg)
Redo
GDE
Page 1 LSN:2
DEF
Page 2 LSN:11
HIJ
Page 3 LSN:6
OPQ
Page 4 LSN:8
Buffer Frame 1 Buffer Frame 2 Buffer Frame 3
Xact ID
Last LSN
State
ABC
Page 2 LSN:4
DEF
Page 2 LSN:11
KLM
Page 3 LSN:12
WXY
Page 2 LSN:14
GDE
Page 1 LSN:2
HIJ
Page 3 LSN:6
KLM
Page 3 LSN:12
QRS
Page 1 LSN:13
OPQ
Page 4 LSN:8
RST
Page 4 LSN:16
Page ID rec LSN
LSN Prev XactID Type pageID Before After
11 null T1 update 2 ABC DEF 12 null T2 update 3 HIJ KLM 13 12 T2 update 1 GDE QRS 14 11 T1 update 2 DEF WXY 15 13 T2 commit and end
BEGIN_CHKPT
END_CHKPTXact Table
Dirty Page Table
T1 14 U
2 11
3 12
1 13
3. Reapply LSN 13 T2 update 1 (QRS)
DEF
Page 2 LSN:11
KLM
Page 3 LSN:12
4. Reapply LSN 14 T1 update 2 (WXY)
GDE
Page 1 LSN:2
QRS
Page 1 LSN:13
WXY
Page 2 LSN:14
![Page 42: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/42.jpg)
Redo
GDE
Page 1 LSN:2
DEF
Page 2 LSN:11
HIJ
Page 3 LSN:6
OPQ
Page 4 LSN:8
Buffer Frame 1 Buffer Frame 2 Buffer Frame 3
Xact ID
Last LSN
State
ABC
Page 2 LSN:4
DEF
Page 2 LSN:11
KLM
Page 3 LSN:12
WXY
Page 2 LSN:14
GDE
Page 1 LSN:2
HIJ
Page 3 LSN:6
KLM
Page 3 LSN:12
OPQ
Page 4 LSN:8
RST
Page 4 LSN:16
Page ID rec LSN
LSN Prev XactID Type pageID Before After
11 null T1 update 2 ABC DEF 12 null T2 update 3 HIJ KLM 13 12 T2 update 1 GDE QRS 14 11 T1 update 2 DEF WXY 15 13 T2 commit and end
BEGIN_CHKPT
END_CHKPTXact Table
Dirty Page Table
T1 14 U
2 11
3 12
1 13
5. Reapply T2 commit (and we’ll write dirty pages to disk.)
DEF
Page 2 LSN:11
KLM
Page 3 LSN:12
WXY
Page 2 LSN:14
QRS
Page 1 LSN:13
QRS
Page 1 LSN:13
![Page 43: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/43.jpg)
Phase 3: The UNDO PhaseWe undo actions of all active but not
committed xacts at the time of the crash.– May even need to undo some of what we did
in REDO phase!
ToUndo={lastLSNs of all Xacts in the Trans Table} a.k.a. “losers”
Repeat:– Choose (and remove) largest LSN among ToUndo.– If this LSN is a CLR and undonextLSN==NULL
• Write an End record for this Xact.– If this LSN is a CLR, and undonextLSN != NULL
• Add undonextLSN to ToUndo – Else this LSN is an update. Undo the update, write a CLR,
add prevLSN to ToUndo.Until ToUndo is empty.
CLRs will help us remember where we are in case of system crash during recovery.
![Page 44: Review Lecture 30](https://reader035.fdocuments.net/reader035/viewer/2022062719/56813155550346895d97ce6f/html5/thumbnails/44.jpg)
Undo
GDE
Page 1 LSN:2
DEF
Page 2 LSN:11
HIJ
Page 3 LSN:6
OPQ
Page 4 LSN:8
Buffer Frame 1 Buffer Frame 2 Buffer Frame 3
Xact ID
Last LSN
State
ABC
Page 2 LSN:4
DEF
Page 2 LSN:11
KLM
Page 3 LSN:12
WXY
Page 2 LSN:14
HIJ
Page 3 LSN:6
KLM
Page 3 LSN:12
OPQ
Page 4 LSN:8
RST
Page 4 LSN:16
Last LSN
LSN Prev XactID Type pageID Before After
11 null T1 update 2 ABC DEF 12 null T2 update 3 HIJ KLM 13 12 T2 update 1 GDE QRS 14 11 T1 update 2 DEF WXY 15 13 T2 commit and end
BEGIN_CHKPT
END_CHKPTXact Table
ToUndo
T1 14 U
14 11
1. Add last LSN for all transactions in Xact table
QRS
Page 1 LSN:13
2. Recursively Process each last LSN in To Undo table.
DEF
Page 2 LSN:11
16 undoNextLSN=null T1 CLR 2 DEF ABC
ABC
Page 2 LSN:16
ABC
Page 2 LSN:4