Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Database Transaction Recovery: Atomicity, Durability, and Logging, Slides of Introduction to Database Management Systems

The importance of maintaining atomicity and durability properties of transactions in databases. It covers different types of failures and their recovery management, including in-place and out-of-place updates, logging, and write-ahead log protocol. The document also explains the role of the recovery manager and buffer manager in managing database transactions.

Typology: Slides

2011/2012

Uploaded on 02/13/2012

richiey
richiey 🇨🇦

32 documents

1 / 10

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
10-1
Problem:
How to maintain
atomicity
durability
properties of transactions
Database Reliability
10-2
Types of Failures
nTransaction failures
lTransaction aborts (unilaterally or due to deadlock)
lAvg. 3% of transactions abort abnormally
nSystem (site) failures
lFailure of processor, main memory, power supply, …
lMain memory contents are lost, but secondary storage contents are
safe
lPartial vs. total failure
nMedia failures
lFailure of secondary storage devices such that the stored data is
lost
lHead crash/controller failure
pf3
pf4
pf5
pf8
pf9
pfa

Partial preview of the text

Download Database Transaction Recovery: Atomicity, Durability, and Logging and more Slides Introduction to Database Management Systems in PDF only on Docsity!

10-

Problem:

How to maintain

atomicity

durability

properties of transactions

Database Reliability

Types of Failures

n Transaction failures

l Transaction aborts (unilaterally or due to deadlock) l Avg. 3% of transactions abort abnormally

n System (site) failures

l Failure of processor, main memory, power supply, … l Main memory contents are lost, but secondary storage contents are safe l Partial vs. total failure

n Media failures

l Failure of secondary storage devices such that the stored data is lost l Head crash/controller failure

10-

Recovery Management -Architecture

n Volatile storage l Consists of the main memory of the computer system (RAM). n Stable storage l Resilient to failures and loses its contents only in the presence of media failures (e.g., head crashes on disks). l Implemented via a combination of hardware (non-volatile storage) and software (stable-write, stable-read, clean-up) components.

Secondary storage

Stable database

Read (^) Write Write Read

Recovery^ Main memory Manager

Database Buffer Manager

Fetch, Flush (^) Database buffers (Volatile database)

Transaction commands

Update Strategies

n In-place update

l Each update causes a change in one or more data values on pages in the database buffers

n Out-of-place update

l Each update causes the new value(s) of data item(s) to be stored separate from the old value(s). l Shadowing ‡ When an update occurs, don't change the old page, but create a shadow page with the new values and write it into the stable database. ‡ Update the access paths so that subsequent accesses are to the new shadow page. ‡ The old page retained for recovery.

10-

Log Example

T 1 , begin T 1 , x , 99, 100 T 2 , begin T 2 , y , 199, 200 T 3 , begin T 3 , z , 51, 50 T 2 , w , 1000, 10 T 2 , commit T 4 , begin T 3 , abort T 4 , y , 200, 50 T 5 , begin T 5 , w , 10, 100 T 4 , commit

Log head

Log tail

Why Logging?

Upon recovery:

l all of T 1 's effects should be reflected in the database (REDO if necessary due to a failure) l none of T 2 's effects should be reflected in the database (UNDO if necessary)

0 t time

system crash Begin^ T 1 End Begin T 2

10-

REDO Protocol

n REDO'ing an action means performing it again.

n The REDO operation uses the log information and performs the action that might have already executed or interrupted due to failures.

n The REDO operation generates the new image.

Database Log

REDO

Old stable database state

New stable database state

n UNDO'ing an action means to restore the object to its before image. n The UNDO operation uses the log information and restores the old value of the object.

UNDO Protocol

New stable database state

Database Log

UNDO

Old stable database state

10-

Write–Ahead Log Protocol

n Notice:

l If a system crashes before a transaction is committed, then all the operations must be undone. Only need the before images ( undo portion of the log).

l Once a transaction is committed, some of its actions might have to be redone. Need the after images ( redo portion of the log).

n WAL protocol :

∂ Before a stable database is updated, the undo portion of the log should be written to the stable log ∑ When a transaction commits, the redo portion of the log must be written to stable log prior to the updating of the stable database.

n Can the Buffer Manager (BM) decide to write some of the buffer pages being accessed by a transaction into stable storage or does it wait for Recovery Manager (RM) to instruct it? l steal/no-steal decision l no-steal means RM “pins” (or “fixes”) pages in the buffer n Does the RM force the BM to write certain buffer pages into stable database at the end of a transaction's execution? l force/no-force decision n Possible execution strategies: l steal/no-force l steal/force l no-steal/no-force l no-steal/force

Recovery Manager/Buffer Manager

Interaction

10-

n Abort

l BM may have written some of the updated pages into stable database l RM performs transaction undo (or partial undo)

n Commit

l RM writes an “commit” record into the log.

n Recover

l For those transactions that have both a “begin” and an “commit” record in the log, a partial redo is initiated by RM l For those transactions that only have a “begin” record in the log, a global undo is executed by RM

Steal/No-Force

n Abort

l BM may have written some of the updated pages into stable database l RM performs transaction undo (or partial undo)

n Commit

l RM issues a flush command to the buffer manager for all updated pages l RM writes a “commit” record into the log.

n Recover

l No need to perform redo l Perform global undo

Steal/Force

10-

n Shortens the amount of log that need to be

undone or redone when a failure occurs.

n A checkpoint record contains a list of active

transactions.

n Steps:

∂ Write a begin_checkpoint record into the log ∑ Collect the checkpoint data into the stable storage ∏ Write an end_checkpoint record into the log

Checkpoints

Media Failures –

Full Architecture

Read Write Write

Read

Main memory Local Recovery Manager

Database Buffer Manager

Fetch, Flush

Archive log

Archive database

Secondary storage

Stable log

Stable database

Database buffers (Volatile database)

Log buffers

Write (^) Write

Write

Read