KT24503

DATABASE

Lecture 11: Data

Backup and Recovery
DATA BACKUP AND RECOVERY
• Failure Classification
• Recovery Algorithm
• Storage Structure
• Data Backup
• Database Backup and Recovery
• DB2 Transaction Logs
• Log Files States
• Stable-Storage Implementation
• Logging Strategies
• Database Backup
• Database Recovery
FAILURE
CLASSIFICATION
Transaction failure:
• Logical errors: transaction cannot complete due to some internal error
condition (Semantic Error, Incomplete Command)
• System errors: the database system must terminate an active transaction due
to an error condition (e.g., deadlock)
System crash: a power failure or other hardware or software failure causes the system to
crash.
• Fail-stop assumption: non-volatile storage (disk, tape) contents are assumed to
not be corrupted by system crash
• Database systems have numerous integrity checks to prevent corruption of disk data
Disk failure: a head crash or similar disk failure destroys all or part of disk storage
• Destruction is assumed to be detectable: disk drives use checksums to detect
failures
 4

RECOVERY ALGORITHMS
Recovery algorithms are techniques to ensure database consistency and
transaction atomicity and durability despite failures.
• Focus of this chapter
Recovery algorithms have two parts:
1. Actions taken during normal transaction processing to
ensure enough information exists to recover from failures.
2. Actions taken after a failure to recover the database contents
to a state that ensures atomicity, consistency and durability.
 5

STORAGE STRUCTURE

• does not survive system crashes

Volatile storage: • examples: main memory, cache memory

Nonvolatile • survives system crashes

• examples: disk, tape, flash memory,
storage: non-volatile (battery backed up) RAM

• a mythical form of storage that survives all failures

Stable storage: • approximated by maintaining multiple copies on distinct nonvolatile
media
DATA BACKUP
6
DATABASE BACKUP AND RECOVERY
7
 DB2 TRANSACTION LOGS
• A transaction is a sequence of one or more SQL operations grouped together as a single unit. Transaction
logging is a process used to keep track of changes made to a database as they occur.
• When an update or a delete operation is performed, the page containing the record to be updated/deleted is
retrieved from storage and copied to the appropriate buffer pool, where it is then modified by the
update/delete operation (A)

(A)
 DB2 TRANSACTION LOGS
• Once the record has been modified or inserted, a record reflecting the change is written to the log buffer,
which is another storage area in memory (B)
• DB2 constantly checks to see if the log buffer is full, if MINCOMMIT commits have been performed, or if one
second has lapsed. If any of these factors have occurred, the information in the log buffers is written to the log
file on disk. (C)
• During a data recovery process, DB2 uses the log files to decide what changes to redo or undo.
(B)

(A) (C)
LOG FILE STATES 10
 LOG FILE STATES
There are three states for a log file.

Active Logs: A log is considered active if:

q It contains transactions that have not been committed or rolled back. Or,
q It contains transactions that have been committed but whose changes have not been externalized to
disk. Or.
q It contains transactions that have been rolled back but whose changes have not been externalized to
disk
Active logs are used in crash recovery. Active logs are located in the database log path directory.
 LOG FILE STATES
Online archive logs only contain committed and externalized
transactions. In other words, they are no longer active, and therefore no longer needed for crash
recovery. Online archive logs are still kept in the active log directory.

Offline archive logs are similar to online archive logs, except they are stored in a separate repository.
This is to save file system and disk drive space. Like the online archive logs, offline archive logs are used
in roll forward
recovery.
 STABLE-STORAGE
IMPLEMENTATION
• Maintain multiple copies of each block on separate disks
• copies can be at remote sites to protect against disasters such as fire or flooding.
• Failure during data transfer can still result in inconsistent copies: Block transfer can result in
• Successful completion
• Partial failure: destination block has incorrect information
• Total failure: destination block was never updated
• Protecting storage media from failure during data transfer (one solution):
• Execute output operation as follows (assuming two copies of each block):
1. Write the information onto the first physical block.
2. When the first write successfully completes, write the same information onto the second physical block.
3. The output is completed only after the second write successfully completes.
LOGGING STRATEGIES 14
LOGGING STRATEGIES 15
LOGGING STRATEGIES
16
DATABASE BACKUP
 18

DATABASE BACKUP
 19

DATABASE BACKUP
 20

DATABASE BACKUP
DATABASE BACKUP
21
 22

DATABASE BACKUP
DATABASE BACKUP
23
 24

DATABASE BACKUP
 25

DATABASE RECOVERY
 26

DATABASE RECOVERY
 27

DATABASE RECOVERY
 28

DATABASE RECOVERY
REFERENCES
Database System Concepts - 6th Edition
©Silberschatz, Korth and Sudarshan
DB2 Example
END OF
LECTURE 11