Chapter 5

Database Recovery System

1
 Outline
Cause of Failure

Recovery schemes

Recovery techniques (RT)

Backup mechanisms

Log-based recovery

Deferred update

Immediate update

Shadow paging

Checkpoints

Recover form Catastrophic failure

2
5.1 Causes of Failures
 All electronic devices are subject to failure in one or another.
 Computer system also an electronic device and hence subject
to failures of various forms
 Types of failures
1. System crash
o Refers to the loss of main memory due to media
failures.
2. Media failure
o Refers to a hardware, software, or network errors
3. Transaction failure
 Erroneous operation and parameter values
 System error like integer overflow, division by zero
 Local error like “data not found”

3
Cont…
4. User error
 Interruption of transaction
 Carelessness (dropping table or deleting records)
5. Application software
 Logical programming error in accessing the database
6. Disk failure
 Some disk blocks may lose their data because of
read/write malfunction (write/read head crash)
7. Physical and Natural disasters
 Also called catastrophic failure
 Refers to number of problem including power or air
condition, fire, theft, flood, earth quake etc.

4
5.2 Recovery Schemes
 Database recovery
Refers to the various strategies and procedures involved in protecting
the database against data loss and reconstructing the datum.
The process of restoring or rolling forward and rolling back the database
to the most recent consistent state that existed just before the failure.
 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
 Database recovery condition
Pre-condition: At any given point in time the database is in a consistent
state.
Condition: Some kind of system failure occurs
Post-condition --- Restore the database to the consistent state that
existed before the failure
5
Cont…
 Recovery Facilities
DBMS should provide the following facilities to assist with the
recovery
Backup mechanism
o That makes periodic copies of the database

Logging facilities
o That keep track of the current state of transaction

Checkpoint facility
o That enables updates to the DB that are in progress to be made
permanent

Recovery manager
o That allow the system to restore the DB to a consistent state
following failure
6
Cont…

Backup
Database
Media
checkpoints failure

Restored Recovere
Databas d
e Recovery Database

7
5.3 Recovery Techniques
 The extent of damage that has occurred to the database plays a significant
role in the choice of recovery techniques.
 Example:
If the database has been damage heavily(physically), the last backup
copy will have to be restored.

Other hand if database has not been damaged physically, but has
become inconsistent, then it is enough to undo the changes that
caused the inconsistency.

 Generally the following are basic recovery techniques.

Taking Backup (Copies of the database)
Log-Based Recovery
Shadow Paging
Checkpoint

8
5.3.1 Database Backups
 What is Backup:
It is a copy of data
The copy can include all important parts of database like control file
and data files.
Various backup methods exist today
Database Administrator needs to determine what kind of backup
procedures is required for his/her site.

 Importance of Backup
It is similar to buying insurance on your properties (like car, house, …)
Useful in recovery strategies
Type and frequency of your backups determine the speed and success of
the recovery.

9
Cont…
 Type of Backup
Physical Backup
Where the actual physical database files are copied from one
location to other (usually from disk to magnetic tape).
Are the primary concern in backup and recovery strategy
You may make it either with recovery manger utility of DBMS
or Operating system utilities.
Logical Backup
A backup that extracts the data using in SQL from the database
and store the in the binary files.
It contains logical data(example, tables and stored procedures)
Used to restore these particular object and can supplement
physical backups.

10
5.3.2 Log-Based Recovery
 DBMS maintains a special files called log-file(journals) that keep
a track of information (records) about all updates activities on the
database.
 This record is called log records.
 Log-file contains information such as:
Transaction identifier
Type of log record (update, insert, delete etc.)
Identifier of data item affected by the database action
Checkpoints records
 Earlier a log-file is kept on stable storage (like magnetic tape).
 Now a day kept on-line on a fast Direct Access Storage
Devices(DASD) because DBMS are expected to recover from
minor failures.
 Since online log files are also prone to failure, it to be archived
periodically and stored in off-line storage.
11
Cont…
When transaction T starts, it registers itself by writing a
i
<Ti start> log record.
Before T executes write(X) operation, a log record write
i

<Ti, X, V1, V2> to log file,

where V1 is the value of X before the write, and
V2 is the value to be written to X.
Log record notes that T has performed a write on data item X
i j
while Xj had value V1 before the write, and will have value V2
after the write.
When T finishes it last statement, the log record write
i
<Ti commit>.
There are 2 recovery techniques that based on the log-file
Deferred database modification
12
Immediate database modification
Deferred Database Modification
This techniques do not physically update the database on the
disk until after a transaction reaches its commit point.
Before reaching commit, all transactions updates are recorded in
the buffers.
Records all modifications to the log, and defers writes to after
partial commit.
Transaction starts by writing <Ti start> record to log.
A write(X) operation results in a log record <Ti, X, V> being
written, where V is the new value for X (old value is not needed).
The write is not performed on X at this time, but is deferred.
When Ti partially commits, <Ti commit> is written to the log
After that, the log records are read and used to actually execute
13 the previously deferred writes (performs actual update).
Cont…
 If transaction aborts, the log records for the transaction are ignored
and the write to the database is not performed.
 During recovery after a crash, a transaction needs to be redone if
and only if both <Ti start> and <Ti commit> are there in the log.
 If transaction fails before reaching its commit point, it will not have
change the database and so undo is not needed.
 It also called No-UNDO/REDO algorithm.
 Redoing a transaction Ti ( redo Ti) sets the value of all data items
updated by the transaction to the new values.
 Log record are written to the disk before the transaction is actually
committed.
 So, even if a system failure occurs while the actual database update
are in progress, the log records will survive and the updates can be
14 applied later on.
Immediate Database Modification
 This scheme allows database updates of an uncommitted transaction
to be made as the writes are issued.
 However, these operations are typically recorded in the log on disk
by force-writing before they are applied to the database.
It also called UNDO/REDO algorithm because both undo (roll
back the transaction) and redo (roll forward the transaction).
Undoing may be needed, since update logs must have both old
value and new value
We assume that the log record is output directly to stable
storage
 Order in which blocks are output can be different from the order in
which they are written.

15
Cont…
 Recovery procedure has two operations instead of one:
 undo(T ) restores the value of all data items updated by T to
i i
their old values, going backwards from the last log record for Ti
redo(T ) sets the value of all data items updated by T to the new
i i
values, going forward from the first log record for Ti
 Both operations must be idempotent
That is, even if the operation is executed multiple times the effect
is the same as if it is executed once
Needed since operations may get re-executed during recovery
 When recovering after failure:
Transaction T needs to be undone if the log contains the record
i
<Ti start>, but does not contain the record <Ti commit>.
Transaction T needs to be redone if the log contains both the
i
record <Ti start> and the record <Ti commit>.

16 Undo operations are performed first, then redo operations.
5.3.4 Shadow paging
Shadow paging is an alternative to log-based recovery; this
scheme is useful if transactions execute serially
Ideology:
Maintain two page tables during the lifetime of a transaction
The current page table and
The shadow page table
The shadow page table are stored in nonvolatile storage, such
that state of the database prior to transaction execution may be
recovered.
Shadow page table is never modified during execution
The shadow directory will be always pointing to the old
unmodified disk block as it is not updated.
17
Cont…
At the time start, both page tables are identical (similar).
Only current page table is used for data item accesses during
execution of the transaction.
Whenever any page is about to be written for the first time
A copy of this page is made onto an unused page.
The current page table is then made to point to the copy and
the update is performed on the copy
Committing a transaction is done by discarding the shadow
directory. Thus current directory is used to record all update to
the database.
Recovery is faster since there is no need for Undo/Redo
operations.
But its drawback is it is difficult to keep related database page
18 close together without complex storage management strategies.
Cont…

Curren Shadow
t Page Disk Page Page

Fig. Shadow and current directories and disk page before

19 execution of the transaction.
5.3.5 Checkpointing (Streamline recovery)
 Problems in log-based recovery procedure:
1. Searching the entire log is time-consuming because we may
not know how far back in the log search.
2. One might unnecessarily redo transactions which have
already output their updates to the database.
 Streamline recovery procedure by periodically performing
check pointing
1. Output all log records currently residing in main memory
onto stable storage.
2. Output all modified buffer blocks to the disk.
3. Write a log record < checkpoint> onto stable storage.
 When failures occur we need only to redo the transaction that
was active at the checkpoint and any subsequent transaction for
20 which both the start and commit record appear in the log.
5.4 Recover form Catastrophic failure
As discussed before Catastrophic failure is a type of failure
that occur as a result of Natural phenomena.
For example:
o Earth quake, flood, fire etc.
Solution:
Database backup in which the whole database and log files
are periodically copied onto an off-line nonvolatile storage
medium (like magnetic tape or optical disk).
It is necessary to backup the log file (smaller in size than
actual DB) more frequently to prevent losing of all effects
of transactions that have been executed.
The database is first recreated from the backup copy
And the effects of all committed transactions whose
21 operations have been copied to the tape are reconstructed.
Cont…
Recovery procedure consists of three main steps

Analysis:
Identify the dirty (updated pages) in the buffer and set of
active transactions at the time of failure
Redo:
Reapply updates from the log to the database. It will be
done for the committed transactions.
Undo:
Scan the log backward and undo the actions of the active
transactions in the reverse order.

22
Cont…
Reading Assignment

 Why Database Plan?

 Recovery in Multi-Database System

 Hardware Protection and Redundancy

 Data Storage

23
 THE END!
Do you have QUESTION’S ???
24
 Transaction Definition in SQL
 Data manipulation language must include a construct for specifying
the set of actions that comprise a transaction.
 In SQL, a transaction begins implicitly, after previous transaction.
 A transaction in SQL ends by:
Commit work commits current transaction and begins a new
one.
Rollback work causes current transaction to abort.
 In almost all database systems, by default, every SQL statement
also commits implicitly if it executes successfully
Implicit commit can be turned off by a database directive
E.g. in JDBC, connection.setAutoCommit(false);
 Four levels of (weak) consistency, cf. before.

25
Transaction management in Oracle
 Transaction beginning and ending as in SQL
Explicit commit work and rollback work
Implicit commit on session end, and implicit rollback on failure
 Log-based deferred recovery using rollback segment
 Checkpoints (inside transactions) can be handled explicitly
savepoint <name>
rollback to <name>

 Concurrency control is made by (a variant of) multiversion rigorous two-

phase locking
 Deadlock are detected using a wait-graph
Upon deadlock detection, the last transaction that detects the deadlock
is rolled back
26
Levels of Consistency in Oracle
 Oracle implements 2 of the 4 of levels of SQL
Read committed, by default in Oracle and with
set transaction isolation level read committed
Serializable, with
set transaction isolation level serializable
Appropriate for large databases with only few updates, and usually
with not many conflicts. Otherwise it is too costly.
 Further, it supports a level similar to repeatable read:
Read only mode, only allow reads on committed data, and further
doesn’t allow INSERT, UPDATE or DELETE on that data. (without
unrepeatable reads!)
set transaction isolation level read only

27
Granularity in Oracle
 By default Oracle performs row level locking.
 Command
select … for update
locks the selected rows so that other users cannot lock or update the rows
until you end your transaction. Restriction:
Only at top-level select (not in sub-queries)
Not possible with DISTINCT operator, CURSOR expression, set
operators, group by clause, or aggregate functions.
 Explicit locking of tables is possible in several modes, with
lock table <name> in
row share mode
row exclusive mode
share mode
share row exclusive mode
exclusive mode
28
Lock modes in Oracle
 Row share mode
The least restrictive mode (with highest degree of concurrency)
Allows other transactions to query, insert, update, delete, or lock rows
concurrently in the same table, except for exclusive mode
 Row exclusive mode
As before, but doesn’t allow setting other modes except for row share.
Acquired automatically after a insert, update or delete command on a
table
 Exclusive mode
Only allows queries to records of the locked table
No modifications are allowed
No other transaction can lock the table in any other mode

 See manual for details of other (intermediate) modes

29
Consistency tests in Oracle
 By default, in Oracle all consistency tests are made immediately after each
DML command (insert, delete or update).
 However, it is possible to defer consistency checking of constraints (primary
keys, candidate keys, foreign keys, and check conditions) to the end of
transactions.
Only this makes it possible e.g. to insert tuples in relation with circular
dependencies in foreign keys
 For this:
each constraints that may possibly be deferred must be declared as
deferrable:
At the definition of the constraint add deferrable immediately
afterwards
at the transaction in which one wants to defer the verification of the
constraints, add command:
set constraints all deferred
In this command, instead of all it is possible to specify which
constraints are to be deferred, by giving their names separated by
30
commas