APEX INSTITUTE OF TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

Database Management System (21CST-232)

Faculty: Mr. Pramod Vishwakarma (E9758)

Database Recovery DISCOVER . LEARN . EMPOWER

1
DBMS: Course Objectives
COURSE OBJECTIVES
The Course aims to:
•Understand database system concepts and design databases for different
applications and to acquire the knowledge on DBMS and RDBMS.
•Implement and understand different types of DDL, DML and DCL statements.
•Understand transaction concepts related to databases and recovery/backup
techniques required for the proper storage of data.

By: Pramod Vishwakarma (E9758) 2

COURSE OUTCOMES

On completion of this course, the students shall be able to:-

Understand the database concept, system architecture and role of database
CO1
administrator
CO2 Design database for an organization using relational model
Apply relational algebra and relational calculus to query the database of
CO3
organization
CO4 Implement the package, procedures and triggers
CO5 Understand the concept of transaction processing and concurrency  control

By: Pramod Vishwakarma (E9758) 3

Database Recovery of database
What Makes Transaction Processing (TP) Hard?
•Atomicity - no partial results
•Isolation – appears to run transactions serially
•Durability – results aren’t lost by a failure
•Availability - system must be up all the time
•Reliability - system should rarely fail
•Response time - within 1-2 seconds
•Throughput - thousands of transactions/second
•Scalability - start small, ramp up to Internet-scale
•Configurability - for above requirements + low cost
•Distribution - of users and data
 Database Recovery of database
System crash
T1 Crash Transaction
T2 error
T3 System error
Time Local error
• ACID properties of Transaction Disk failure
Catastrophe
Database system should guarantee

- Durability : Applied changes by transactions must not be lost. ~

T3
- Atomicity : Transactions can be aborted. ~ T1, T2
 Database Recovery of database
Checkpoint
System Log
- keeps info of changes applied
by transactions
Backup
T1
T2 Crash
T3
Time
• Undo/Redo by the Log
 recover Non-catastrophic failure
• Full DB Backup
Catastrophic failure
> Differential Backup
> (Transaction) Log
Database Recovery
Database recovery is the process of restoring the database to the most recent
consistent state that existed just before the failure.
 Three states of database recovery:
• Pre-condition: At any given point in time the database is in a consistent
state.
• Condition: Occurs some kind of system failure.
• Post-condition: Restore the database to the consistent state that existed
before the failure
• Example:
• If the system crashes before a fund transfer transaction completes its
execution, then either one or both accounts may have incorrect value.
Thus, the database must be restored to the state before the transaction
modified any of the accounts.
 Outline
Databases Recovery
1 Purpose of Database Recovery
2 Types of Failure
3 Transaction Log
4 Data Updates
5 Data Caching
6 Transaction Roll-back (Undo) and Roll-Forward
7 Checkpointing
8 Recovery schemes
9 ARIES Recovery Scheme
10 Recovery in Multidatabase System

Chapter 19-8
Database Recovery

1 Purpose of Database Recovery

• To bring the database into the last consistent state, which existed prior to the failure.
• To preserve transaction properties (Atomicity, Consistency, Isolation and Durability).

Example: If the system crashes before a fund transfer

transaction completes its execution, then either one or
both accounts may have incorrect value. Thus, the
database must be restored to the state before the
transaction modified any of the accounts.

Chapter 19-9
Database Recovery

2 Types of Failure
The database may become unavailable for use due to
• Transaction failure: Transactions may fail because of
incorrect input, deadlock, incorrect synchronization.
• System failure: System may fail because of addressing
error, application error, operating system fault, RAM
failure, etc.
• Media failure: Disk head crash, power disruption, etc.

Chapter 19-10
 Database Recovery
3 Transaction Log
For recovery from any type of failure data values prior to
modification (BFIM - BeFore Image) and the new value after
modification (AFIM – AFter Image) are required. These values and
other information is stored in a sequential file called Transaction
log. A sample log is given below. Back P and Next P point to the
T ID next
previous and Backlog
P Next P Operation
records of the Data
sameitemtransaction.
BFIM AFIM
T1 0 1 Begin
T1 1 4 Write X X = 100 X = 200
T2 0 8 Begin
T1 2 5 W Y Y = 50 Y = 100
T1 4 7 R M M = 200 M = 200
T3 0 9 R N N = 400 N = 400
T1 5 nil End

Chapter 19-11
 Database Recovery
4 Data Update
• Immediate Update: As soon as a data item is modified in
cache, the disk copy is updated.
• Deferred Update: All modified data items in the cache is
written either after a transaction ends its execution or
after a fixed number of transactions have completed their
execution.
• Shadow update: The modified version of a data item
does not overwrite its disk copy but is written at a
separate disk location.
• In-place update: The disk version of the data item is
overwritten by the cache version.

Chapter 19-12
 Database Recovery
5 Data Caching
Data items to be modified are first stored into database
cache by the Cache Manager (CM) and after
modification they are flushed (written) to the disk. The
flushing is controlled by Modified and Pin-Unpin bits.
Pin-Unpin: Instructs the operating system not to flush
the data item.
Modified: Indicates the AFIM of the data item.

Chapter 19-13
 Database Recovery
6 Transaction Roll-back (Undo) and Roll-Forward (Redo)
To maintain atomicity, a transaction’s operations are redone
or undone.
Undo: Restore all BFIMs on to disk (Remove all AFIMs).
Redo: Restore all AFIMs on to disk.
Database recovery is achieved either by performing only
Undos or only Redos or by a combination of the two. These
operations are recorded in the log as they happen.

Chapter 19-14
 Database Recovery
Roll-back

We show the process of roll-back with the help of the following three transactions T1, and T2 and T3.

T1 T2 T3
read_item (A) read_item (B) read_item (C)
read_item (D) write_item (B) write_item (B)
write_item (D) read_item (D) read_item (A)
write_item (A) write_item (A)

Chapter 19-15
 Database Recovery
Roll-back: One execution of T1, T2 and T3 as recorded in the log.
A B C D
30 15 40 20

[start_transaction, T3]
[read_item, T3, C]
* [write_item, T3, B, 15, 12] 12
[start_transaction,T2]
[read_item, T2, B]
** [write_item, T2, B, 12, 18] 18
[start_transaction,T1]
[read_item, T1, A]
[read_item, T1, D]
[write_item, T1, D, 20, 25] 25
[read_item, T2, D]
** [write_item, T2, D, 25, 26] 26
[read_item, T3, A]
---- system crash ----
* T3 is rolled back because it did not reach its commit point.
** T2 is rolled back because it reads the value of item B written by T3.
Chapter 19-16
 Database Recovery
Roll-back: One execution of T1, T2 and T3 as recorded in the log.

T3 READ(C) WRITE(B) READ(A)

BEGIN READ(B) WRITE(B) READ(D) WRITE(D)
T2
BEGIN READ(A) READ(D) WRITE(D)
T1
BEGIN
Time
system crash

Illustrating cascading roll-back

Chapter 19-17
 Database Recovery
Write-Ahead Logging
When in-place update (immediate or deferred) is used then
log is necessary for recovery and it must be available to
recovery manager. This is achieved by Write-Ahead Logging
(WAL) protocol. WAL states that
For Undo: Before a data item’s AFIM is flushed to the
database disk (overwriting the BFIM) its BFIM must be written
to the log and the log must be saved on a stable store (log
disk).
For Redo: Before a transaction executes its commit operation,
all its AFIMs must be written to the log and the log must be
saved on a stable store.
Chapter 19-18
 Database Recovery
7 Checkpointing
Time to time (randomly or under some criteria) the database
flushes its buffer to database disk to minimize the task of recovery.
The following steps defines a checkpoint operation:
1. Suspend execution of transactions temporarily.
2. Force write modified buffer data to disk.
3. Write a [checkpoint] record to the log, save the log to disk.
4. Resume normal transaction execution.
During recovery redo or undo is required to transactions appearing
after [checkpoint] record.

Chapter 19-19
References
• RamezElmasri and Shamkant B. Navathe, “Fundamentals of Database System”, The
Benjamin / Cummings Publishing Co.
• Korth and Silberschatz Abraham, “Database System Concepts”, McGraw Hall.
• C.J.Date, “An Introduction to Database Systems”, Addison Wesley.
• Thomas M. Connolly, Carolyn & E. Begg, “Database Systems: A Practical Approach to
Design, Implementation and Management”, 5/E, University of Paisley, Addison-
Wesley.

By: Pramod Vishwakarma (E9758) 20

THANK YOU

For queries
Email: [email protected]
By: Pramod Vishwakarma (E9758) 21