20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile...
Transcript of 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile...
![Page 1: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/1.jpg)
Intro to Database Systems
15-445/15-645
Fall 2019
Andy PavloComputer Science Carnegie Mellon UniversityAP
20 Logging Schemes
![Page 2: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/2.jpg)
CMU 15-445/645 (Fall 2019)
ADMINISTRIVIA
Homework #4 is due Wed Nov 13th @ 11:59pm.
Project #3 is due Sun Nov 17th @ 11:59pm.
Extra Credit Checkpoint is due Sun Nov 24th.
2
![Page 3: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/3.jpg)
CMU 15-445/645 (Fall 2019)
TIM
E
Schedule
MOTIVATION
6
BEGINR(A)W(A)⋮
COMMIT
Buffer Pool
A=1
Pag
e
A=1A=2
T1
![Page 4: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/4.jpg)
CMU 15-445/645 (Fall 2019)
CRASH RECOVERY
Recovery algorithms are techniques to ensure database consistency, transaction atomicity, and durability despite failures.
Recovery algorithms have two parts:→ Actions during normal txn processing to ensure that the
DBMS can recover from a failure.→ Actions after a failure to recover the database to a state
that ensures atomicity, consistency, and durability.
7
Today
![Page 5: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/5.jpg)
CMU 15-445/645 (Fall 2019)
Failure Classification
Buffer Pool Policies
Shadow Paging
Write-Ahead Log
Logging Schemes
Checkpoints
8
![Page 6: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/6.jpg)
CMU 15-445/645 (Fall 2019)
CRASH RECOVERY
DBMS is divided into different components based on the underlying storage device.
We must also classify the different types of failures that the DBMS needs to handle.
9
![Page 7: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/7.jpg)
CMU 15-445/645 (Fall 2019)
FAILURE CL ASSIFICATION
Type #1 – Transaction Failures
Type #2 – System Failures
Type #3 – Storage Media Failures
11
![Page 8: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/8.jpg)
CMU 15-445/645 (Fall 2019)
TRANSACTION FAILURES
Logical Errors:→ Transaction cannot complete due to some internal error
condition (e.g., integrity constraint violation).
Internal State Errors:→ DBMS must terminate an active transaction due to an
error condition (e.g., deadlock).
12
![Page 9: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/9.jpg)
CMU 15-445/645 (Fall 2019)
SYSTEM FAILURES
Software Failure:→ Problem with the DBMS implementation (e.g., uncaught
divide-by-zero exception).
Hardware Failure:→ The computer hosting the DBMS crashes (e.g., power
plug gets pulled).→ Fail-stop Assumption: Non-volatile storage contents are
assumed to not be corrupted by system crash.
13
![Page 10: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/10.jpg)
CMU 15-445/645 (Fall 2019)
STORAGE MEDIA FAILURE
Non-Repairable Hardware Failure:→ A head crash or similar disk failure destroys all or part of
non-volatile storage.→ Destruction is assumed to be detectable (e.g., disk
controller use checksums to detect failures).
No DBMS can recover from this! Database must be restored from archived version.
14
![Page 11: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/11.jpg)
CMU 15-445/645 (Fall 2019)
OBSERVATION
The primary storage location of the database is on non-volatile storage, but this is much slower than volatile storage.
Use volatile memory for faster access:→ First copy target record into memory.→ Perform the writes in memory.→ Write dirty records back to disk.
15
![Page 12: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/12.jpg)
CMU 15-445/645 (Fall 2019)
OBSERVATION
The DBMS needs to ensure the following guarantees:→ The changes for any txn are durable once the DBMS has
told somebody that it committed.→ No partial changes are durable if the txn aborted.
16
![Page 13: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/13.jpg)
CMU 15-445/645 (Fall 2019)
UNDO VS. REDO
Undo: The process of removing the effects of an incomplete or aborted txn.
Redo: The process of re-instating the effects of a committed txn for durability.
How the DBMS supports this functionality depends on how it manages the buffer pool…
17
![Page 14: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/14.jpg)
CMU 15-445/645 (Fall 2019)
Buffer Pool
TIM
E
Schedule
T1 T2
BUFFER POOL
18
A=1 B=9 C=7
A=1 B=9 C=7B=8
BEGINR(A)W(A)
⋮ABORT
BEGINR(B)W(B)COMMIT
A=3
Do we force T2’s changes to be written to disk?Is T1 allowed to overwrite A even
though it has not committed?
What happens when we need to rollback T1?
B=8A=3
![Page 15: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/15.jpg)
CMU 15-445/645 (Fall 2019)
STEAL POLICY
Whether the DBMS allows an uncommitted txn to overwrite the most recent committed value of an object in non-volatile storage.
STEAL: Is allowed.
NO-STEAL: Is not allowed.
19
![Page 16: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/16.jpg)
CMU 15-445/645 (Fall 2019)
FORCE POLICY
Whether the DBMS requires that all updates made by a txn are reflected on non-volatile storage before the txn is allowed to commit.
FORCE: Is required.
NO-FORCE: Is not required.
20
![Page 17: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/17.jpg)
CMU 15-445/645 (Fall 2019)
Buffer Pool
TIM
E
Schedule
T1 T2
NO-STEAL + FORCE
21
A=1 B=9 C=7
A=1 B=9 C=7B=8
BEGINR(A)W(A)
⋮ABORT
BEGINR(B)W(B)COMMIT
A=3
FORCE means that T2 changes must be written to disk at this point.
NO-STEAL means that T1 changes cannot be written to disk yet.
Now it’s trivial to rollback T1
B=8
A=1 B=8 C=7
Copy
![Page 18: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/18.jpg)
CMU 15-445/645 (Fall 2019)
NO-STEAL + FORCE
This approach is the easiest to implement:→ Never have to undo changes of an aborted txn because
the changes were not written to disk.→ Never have to redo changes of a committed txn because
all the changes are guaranteed to be written to disk at commit time (assuming atomic hardware writes).
Previous example cannot support write sets that exceed the amount of physical memory available.
22
![Page 19: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/19.jpg)
CMU 15-445/645 (Fall 2019)
SHADOW PAGING
Maintain two separate copies of the database:→ Master: Contains only changes from committed txns.→ Shadow: Temporary database with changes made from
uncommitted txns.
Txns only make updates in the shadow copy.
When a txn commits, atomically switch the shadow to become the new master.
Buffer Pool Policy: NO-STEAL + FORCE
23
![Page 20: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/20.jpg)
CMU 15-445/645 (Fall 2019)
SHADOW PAGING
Instead of copying the entire database, the DBMS copies pages on write.
Organize the database pages in a tree structure where the root is a single disk page.
There are two copies of the tree, the master and shadow→ The root points to the master copy.→ Updates are applied to the shadow copy.
24
![Page 21: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/21.jpg)
CMU 15-445/645 (Fall 2019)
DiskMemory
SHADOW PAGING EXAMPLE
25
MasterPage Table
1234
DB Root
Database Root
![Page 22: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/22.jpg)
CMU 15-445/645 (Fall 2019)
SHADOW PAGING
To install the updates, overwrite the root so it points to the shadow, thereby swapping the master and shadow:→ Before overwriting the root, none of the txn's updates are
part of the disk-resident database → After overwriting the root, all the txn's updates are part
of the disk-resident database.
26
Source: The Great Phil Bernstein
![Page 23: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/23.jpg)
CMU 15-445/645 (Fall 2019)
COMMIT
DiskMemory
SHADOW PAGING EXAMPLE
27
MasterPage Table
1234
DB Root
ShadowPage Table
1234
Read-only txns access the current master.
Active modifying txnupdates shadow pages.
X XX
XUpdate
Database RootUpdate
![Page 24: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/24.jpg)
CMU 15-445/645 (Fall 2019)
SHADOW PAGING UNDO/REDO
Supporting rollbacks and recovery is easy.
Undo: Remove the shadow pages. Leave the master and the DB root pointer alone.
Redo: Not needed at all.
28
![Page 25: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/25.jpg)
CMU 15-445/645 (Fall 2019)
SHADOW PAGING DISADVANTAGES
Copying the entire page table is expensive:→ Use a page table structured like a B+tree.→ No need to copy entire tree, only need to copy paths in
the tree that lead to updated leaf nodes.
Commit overhead is high:→ Flush every updated page, page table, and root.→ Data gets fragmented.→ Need garbage collection.→ Only supports one writer txn at a time or txns in a batch.
29
![Page 26: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/26.jpg)
CMU 15-445/645 (Fall 2019)
SQLITE (PRE-2010)
When a txn modifies a page, the DBMS copies the original page to a separate journal file before overwriting master version.
After restarting, if a journal file exists, then the DBMS restores it to undo changes from uncommitted txns.
30
Memory
Disk
Page 2Page 2
Page 1
Page 3
Page 5
Page 4
Page 6
Journal File
Page 1 Page 2 Page 3Page 2'
Page 3
Page 3'
Page 2'
![Page 27: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/27.jpg)
CMU 15-445/645 (Fall 2019)
OBSERVATION
Shadowing page requires the DBMS to perform writes to random non-contiguous pages on disk.
We need a way for the DBMS convert random writes into sequential writes.
31
![Page 28: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/28.jpg)
CMU 15-445/645 (Fall 2019)
WRITE-AHEAD LOG
Maintain a log file separate from data files that contains the changes that txns make to database.→ Assume that the log is on stable storage.→ Log contains enough information to perform the
necessary undo and redo actions to restore the database.
DBMS must write to disk the log file records that correspond to changes made to a database object before it can flush that object to disk.
Buffer Pool Policy: STEAL + NO-FORCE
32
![Page 29: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/29.jpg)
CMU 15-445/645 (Fall 2019)
WAL PROTOCOL
The DBMS stages all a txn's log records in volatile storage (usually backed by buffer pool).
All log records pertaining to an updated page are written to non-volatile storage before the page itself is over-written in non-volatile storage.
A txn is not considered committed until all its log records have been written to stable storage.
33
![Page 30: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/30.jpg)
CMU 15-445/645 (Fall 2019)
WAL PROTOCOL
Write a <BEGIN> record to the log for each txn to mark its starting point.
When a txn finishes, the DBMS will:→ Write a <COMMIT> record on the log→ Make sure that all log records are flushed before it
returns an acknowledgement to application.
34
![Page 31: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/31.jpg)
CMU 15-445/645 (Fall 2019)
WAL PROTOCOL
Each log entry contains information about the change to a single object:→ Transaction Id→ Object Id→ Before Value (UNDO)→ After Value (REDO)
35
![Page 32: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/32.jpg)
CMU 15-445/645 (Fall 2019)
Buffer Pool
A=1 B=5 C=7A=8
TIM
E
Schedule
BEGINW(A)W(B)⋮
COMMIT
T1WAL Buffer
WAL EXAMPLE
36
<T1 BEGIN><T1, A, 1, 8><T1, B, 5, 9><T1 COMMIT>
⋮
Txn result is now safe to return to application.
B=9
A=1 B=5 C=7
<T1 BEGIN><T1, A, 1, 8><T1, B, 5, 9><T1 COMMIT>
1
2X
X
Everything we need to restore T1 is in the log!
![Page 33: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/33.jpg)
CMU 15-445/645 (Fall 2019)
WAL IMPLEMENTATION
When should the DBMS write log entries to disk?→ When the transaction commits.→ Can use group commit to batch multiple log flushes
together to amortize overhead.
37
![Page 34: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/34.jpg)
CMU 15-445/645 (Fall 2019)
WAL Buffers
WAL GROUP COMMIT
38
<T1 BEGIN><T1, A, 1, 8><T1, B, 5, 9><T2 BEGIN><T2, C, 1, 2>
<T1 BEGIN><T1, A, 1, 8><T1, B, 5, 9><T2 BEGIN><T2, C, 1, 2>
TIM
E
Schedule
T1 T2BEGINW(A)W(B)
⋮
COMMIT
BEGINW(C)W(D)
⋮
COMMIT
<T2, D, 3, 4>
<T2, D, 3, 4>
Flush the buffer when it is full.
Flush after an elapsed amount of time.
![Page 35: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/35.jpg)
CMU 15-445/645 (Fall 2019)
WAL IMPLEMENTATION
When should the DBMS write log entries to disk?→ When the transaction commits.→ Can use group commit to batch multiple log flushes
together to amortize overhead.
When should the DBMS write dirty records to disk?→ Every time the txn executes an update?→ Once when the txn commits?
39
![Page 36: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/36.jpg)
CMU 15-445/645 (Fall 2019)
BUFFER POOL POLICIES
Almost every DBMS uses NO-FORCE + STEAL
42
NO-STEAL STEAL
NO-FORCE Fastest
FORCE Slowest
Runtime Performance
NO-STEAL STEAL
NO-FORCE Slowest
FORCE Fastest
Recovery PerformanceUndo + Redo
No Undo + No Redo
![Page 37: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/37.jpg)
CMU 15-445/645 (Fall 2019)
LOGGING SCHEMES
Physical Logging→ Record the changes made to a specific location in the
database.→ Example: git diff
Logical Logging→ Record the high-level operations executed by txns.→ Not necessarily restricted to single page.→ Example: The UPDATE, DELETE, and INSERT queries
invoked by a txn.
43
![Page 38: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/38.jpg)
CMU 15-445/645 (Fall 2019)
PHYSICAL VS. LOGICAL LOGGING
Logical logging requires less data written in each log record than physical logging.
Difficult to implement recovery with logical logging if you have concurrent txns.→ Hard to determine which parts of the database may have
been modified by a query before crash.→ Also takes longer to recover because you must re-execute
every txn all over again.
44
![Page 39: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/39.jpg)
CMU 15-445/645 (Fall 2019)
PHYSIOLOGICAL LOGGING
Hybrid approach where log records target a single page but do not specify data organization of the page.
This is the most popular approach.
45
![Page 40: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/40.jpg)
CMU 15-445/645 (Fall 2019)
LOGGING SCHEMES
46
UPDATE foo SET val = XYZ WHERE id = 1;
Physical
<T1,Table=X,Page=99,Offset=4,Before=ABC,After=XYZ>
<T1,Index=X_PKEY,Page=45,Offset=9,Key=(1,Record1)>
Logical
<T1,Query="UPDATE foo
SET val=XYZWHERE id=1">
Physiological
<T1,Table=X,Page=99,ObjectId=1,Before=ABC,After=XYZ>
<T1,Index=X_PKEY,IndexPage=45,Key=(1,Record1)>
![Page 41: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/41.jpg)
CMU 15-445/645 (Fall 2019)
CHECKPOINTS
The WAL will grow forever.
After a crash, the DBMS has to replay the entire log which will take a long time.
The DBMS periodically takes a checkpoint where it flushes all buffers out to disk.
47
![Page 42: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/42.jpg)
CMU 15-445/645 (Fall 2019)
CHECKPOINTS
Output onto stable storage all log records currently residing in main memory.
Output to the disk all modified blocks.
Write a <CHECKPOINT> entry to the log and flush to stable storage.
48
![Page 43: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/43.jpg)
CMU 15-445/645 (Fall 2019)
WAL
<T1 BEGIN><T1, A, 1, 2><T1 COMMIT><T2 BEGIN><T2, A, 2, 3><T3 BEGIN><CHECKPOINT><T2 COMMIT><T3, A, 3, 4>
⋮CRASH!
CHECKPOINTS
Any txn that committed before the checkpoint is ignored (T1).
T2 + T3 did not commit before the last checkpoint.→ Need to redo T2 because it committed after
checkpoint.→ Need to undo T3 because it did not commit
before the crash.
49
![Page 44: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/44.jpg)
CMU 15-445/645 (Fall 2019)
CHECKPOINTS CHALLENGES
We have to stall all txns when take a checkpoint to ensure a consistent snapshot.
Scanning the log to find uncommitted txns can take a long time.
Not obvious how often the DBMS should take a checkpoint…
50
![Page 45: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/45.jpg)
CMU 15-445/645 (Fall 2019)
CHECKPOINTS FREQUENCY
Checkpointing too often causes the runtime performance to degrade.→ System spends too much time flushing buffers.
But waiting a long time is just as bad:→ The checkpoint will be large and slow.→ Makes recovery time much longer.
51
![Page 46: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/46.jpg)
CMU 15-445/645 (Fall 2019)
CONCLUSION
Write-Ahead Logging is (almost) always the best approach to handle loss of volatile storage.→ Use incremental updates (STEAL + NO-FORCE) with
checkpoints.→ On recovery: undo uncommitted txns + redo committed
txns.
52
![Page 47: 20 Logging Schemes - CMU 15-445/645 · non-volatile storage, but this is much slower than volatile storage. Use volatile memory for faster access: →First copy target record into](https://reader036.fdocuments.us/reader036/viewer/2022090607/605dd1389ca1ab3be726901e/html5/thumbnails/47.jpg)
CMU 15-445/645 (Fall 2019)
NEXT CL ASS
Recovery with ARIES.
53