Recovery: Write-Ahead Logging

(1)

Department of Computer Science, Johns Hopkins University

Recovery: Write-Ahead Logging

EN 600.316/416

Instructor: Randal Burns

(2)

Overview

 Log-based recovery –  Undo logging –  Redo logging  Restart recovery  Checkpoints

(3)

Goals

 Provide high-availability (fast repair) and consistency

in the presence of failures

 

Transaction failures

–  logical error: internal condition, bad input, data not found, resource problems, etc. Correspond to software faults.

–  system error: deadlock or other system problem that prevents this execution of a transaction

–  rollback: explicit call to fail this transaction by application

 

System crash

–  bug in OS or DB –  hardware problems

–  environmental reasons: power –  implement the failstop property

(4)

The Database Log

 Whatʼs a log? A sequential file that contains a record

of actions taken by an entity

–  Entity is the DBMS, actions are data writes

 Whatʼs a log look like? A contiguous region of

storage, preferably a whole disk

–  Why contiguous? –  Why a whole disk?

(5)

The Database Log

 Whatʼs a log? A sequential file that contains a record

of actions taken by an entity

–  Entity is the DBMS, actions are data writes

 Whatʼs a log look like? A contiguous region of

storage, preferably a whole disk

–  Why contiguous? So that sequential log writes are written

sequentially to storage. Writing sequentially on storage is very important, as opposed to seeking

–  Why a whole disk? The storage is not important. The arm is the

valuable resource. So that no other workload shares the disk (arm) resource and interferes with sequential writing.

(6)

Memory/Storage View of Log

  Updates are made in memory

–  Log may be inconsistent with on disk log –  Flush the log to make consistent

(7)

Physical/Logical View of Log

  Logically infinite

–  Complete history of all

modifications to the DB   Implemented in finite storage   Tail = present   Head = meaningful past

(8)

What does the log contain?

 Log records (Duh!): an update record describes a single

database writes and consists of:

–  Transaction ID

–  Data-item identifier (typically physical, disk location, rather than

logical, tuple)

–  Old value

–  New value

–  < TID, Disk Block, Old, New >

 There are other types of entries

(9)

The Logging Principle

 Logically, the log only grows, nothing is ever deleted

–  If you want to undo some update < TID, Block, Old, New >

place an equivalent undo in the log < TID(rollback), Block, New, Old >

 How do we implement a log in a fixed amount of space?

–  Transactions that are resolved (aborted or committed) can be

written to the main database, shrinking the log from its head.

–  We never delete from the tail and we remove records for

unresolved transactions

 Problem: long running transactions can overflow the log

(10)

Whatʼs What

 

The log: non-volatile storage

–  Writes to the log are I/O

 

The DB: non-volatile storage

–  Writes to the DB are I/O

 

In-memory pages of the DB

–  Updates (not writes) are made to an in-memory copy

of blocks of the DB.

–  Pages and blocks are the same-ish thing. Pages in

(11)

13-11

Database Cache Log Buffer Stable Database Stable Log Volatile Memory Stable Storage page q page p page p page q 3155 3155 2788 4219 4215 page z 4217 write(b,t

...

₁₇) page z 4158 4208 4216 write(q,t₁₉) 4199 4217 write(z,t₁₇) 4215 4218 commit(t₁₉) 4216 4219 write(q,t₁₇) 4217 4220 begin(t₂₀) nil page b 4215 page b 4215 (page/log) sequence numbers

(12)

Deferred Modification (Redo)

  Log entries allow operations to be redone <TID, Block, New>

  Updates are written only to the log

–  By written, we mean I/O to the DB image. The updates are applied

to an in-memory copy of the database page

  Once a transaction commits, i.e. it has written a commit record in

(13)

Restart Recovery

 No volatile information, just a database and log. No

idea what transactions were active.

 General form of recovery

–  Analysis, take a forward pass over the log constructing lists

of committed and aborted/active transaction

  transactions active when a failure occurred are aborted

(14)

Redo Recovery

  Log can be used to restore committed updates that did

not make it to the database

(15)

Redo Recovery

  Log can be used to restore committed updates that did

not make it to the database

  After a failure   After recovery

(16)

Immediate Modification (Undo)

 The log contains update entries that allow operations to

be undone <TID, Block, Old>

(17)

Undo Recovery

  Log can be used to undone updates to DB from

uncommitted transactions

(18)

Undo Recovery

  After a failure

(19)

Undo Recovery

  After a failure

(20)

Steal and Force

 Steal, the ability to write an uncommitted update to

disk

–  This is called stealing a page

–  Frees up system resources

–  Requires undo logging

 Force, the requirement that all pages dirtied by a

transaction are on disk when a transaction commits

(21)

Steal

(22)

Undo and Redo Redux

  Undo logging is steal/force

  Redo is no-steal/no-force

(23)

Undo and Redo Redux

  Undo logging is steal/force

  Redo is no-steal/no-force

  What workloads are these good for?

  Redo

–  Small memory footprint (canʼt steal pages) –  High txn rates (commit only to log)

–  OLTP, E-Commerce

  Undo

–  Can handle memory overflow (steal) –  Flush at commit expensive

(24)

Undo/Redo

  The best of both worlds

–  Steal from undo and no-force from redo   At the expense of

(25)

Undo/Redo Recovery

  Cʼ doesnʼt need to get hardened to disk –  Why not?