Chapter Five

Database Recovery Techniques

5.1. Backup and Recovery Concepts

5.2. Recovery Concepts Based on Deferred Update

5.3. Recovery Concepts Based on Immediate Update

5.4. Shadow Paging

5.5. Recovery in Multi-database Systems

5.6. The ARIES Recovery Algorithm

 Database backup and Recovery
❖A DBMS can provide backup and recovery:

❖Backup: snapshots of the data particular times.

❖Database recovery is the rebuilding of a database or table space after a

problem such as media or storage failure, power interruption, or application
failure.

❖Database recovery should protect the database and associated users from
unnecessary problems and avoid or reduce the possibility of having to
duplicate work manually.

❖A major responsibility of the database administrator (DBA) is to prepare for

the possibility of hardware, software, network, process, or system failure.

❖If such a failure affects the operation of a database system, he/she must
usually recover the database and return to normal operation as quickly as
possible.
 Cont’d
❖Recovery processes vary depending on the type of failure that
occurred, the structures affected, and the type of recovery that you
perform.

❖If no files are lost or damaged, recovery may amount to no more than
restarting an instance.

❖If data has been lost, recovery requires additional steps.

❖3 states of DB recovery:
❖ Pre-condition: in a consistent state.

❖ Condition: occurs some kinds of system failure.

❖ Post-condition: restore DB to the consistent state existed
before the failure.
 Recovery Facilities
Every DBMS should offer the following facilities to help out with the
recovery mechanism:

• Backup mechanism makes backup copies at a specific interval for the

database.

• Logging facilities keep tracing the current state of transactions and any
changes made to the database.

• Checkpoint facility allows updates to the database for getting the latest
patches (requirements) to be made permanent and keep secure from
vulnerability.

• Recovery manager allows the database system for restoring the database
to a reliable and steady state after any failure occurs.
 Transaction Manager:
A transaction manager is a part of an application that controls the
coordination of transactions over one or more resources. The transaction
manager is responsible for creating transaction objects
and managing their durability and atomicity.
Transaction Request

Query Transaction Log

Processor Manager Manager

Buffer Recovery
Manager Manager

Data
------------
Log
 Cont’d

• Transaction Manager: in DBMS coordinates transactions on behalf of

application programs.
• Communicates with scheduler (lock manager) which is responsible for
implementing a strategy for concurrency control.
• The Scheduler: in the DBMS ensures that the individual steps of different
transactions preserve consistency.
• Recovery Manager: Ensures that database is restored to the original state
in case failure occurs.
• Buffer Manager: responsible for transfer of data between disk storage and
main memory, with Buffer Management policy.
 Cont’d
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.
Types of failures
1. Transaction failure:
• Logical errors: transaction cannot complete due to some internal
error condition such as bad input, data not found, resource limit,
overflow, . . .
• System errors: the database system must terminate an active
transaction due to an error condition (e.g., deadlock)
• Can be re-executed at a later time.
2. System crash (Failure): a power failure or other hardware or
software failure causes the system to crash, causes loss of data in
volatile storage(RAM).
• Example: OS failure, RAM failure, ROM failure
3. Disk failure: a disk head crash or similar disk failure but destroys all
or part of disk storage-fixed block units; due to the fire, or fluctuating
of voltage, etc.
NB: To increase the availability of data and reduce the probability of
the data loss we have to have many remote interconnected backups,
same data in many locations.
Causes of failure Cont’d

❖System crashes due to hardware or software errors, resulting in loss of

main memory;

❖Media failures, such as head crashes or unreadable media, resulting in

the loss of parts of secondary storage;

❖Application software errors, such as logical errors in the program that is

accessing the database, which cause one or more transactions to fail;

❖Natural physical disasters, such as fires, floods, earthquakes, or power

failures;

❖Carelessness or unintentional destruction of data or facilities by operators

or users;

❖Sabotage, or intentional corruption or destruction of data, hardware, or

software facilities.
 Transaction Log
❖The transaction log is an integral (vital) part of SQL Server.
❖Every database has a transaction log that is stored within the log file that is
separate from the data file.
❖ A transaction log basically records all database modifications.
❖When a user issues an INSERT, for example, it is logged in the 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
(appended file) called Transaction log.
❖These log files becomes very useful in returning back the system to a
stable state after a system crash.
 Recovery Algorithms

❖Recovery algorithms are techniques to ensure database

consistency and transaction atomicity and durability
regardless of failures.
❖Recovery algorithms have two parts:
❖ Actions taken during normal transaction processing to
ensure enough information exists to recover from
failures.
❖ Actions taken after a failure to recover the database
contents to a state that ensures atomicity, consistency
and durability.

11
 Data Update- Recovery Concepts
❖ 1. Deferred Update: (REDO/NO-UNDO ALGORITHM)
❖All transaction updates are recorded in the local workspace (cache).
❖All modified data items in the cache is then written after a transaction ends its
execution or after a fixed number of transactions have completed their
execution.
❖During commit the updates are first recorded on the log and then on the
database.
❖If a transaction fails before reaching its commit point, undo is not needed
because it didn’t change the database yet.
❖If a transaction fails after commit (writing on the log) but before finishing
saving to the data base redoing is needed from the log.
❖During transaction execution, the updates are recorded only in the log and in
the transaction workspace.
 Summary of Deferred Database Modification
• It is called NO-UNDO/REDO algorithm.
• These techniques defer or postpone any actual updates to
the database until the transaction reaches it commit point.
• During transaction execution, the updates are written to
log-file.
• After the transaction reaches its commit point, the log-file
is force-written to disk, then the updates are recorded in the
database.
• Thus, the deferred database modification scheme records
all modifications to the log.

13
Cont…example
 2. Immediate Update: (UNDO/NO-REDO ALGORITHM)
❖DB is immediately updated by the transaction operations during the
executions of transactions, even before it reaches commit point.
❖These update are first recorded on the log and on the disk by force
writing, before the database is updated.
❖If the transaction fails before reaching its commit point, there is no need
to undo any operation because the transaction has not affected the
database on disk in any way.
 3. Shadow update:
❖ The modified version of a data item does not overwrite its disk copy but is
written at a separate disk location.
❖Multiple version of the same data item can be maintained.
❖Thus the old value ( before image BFIM) and the new value (AFIM) are
kept in the disk.
❖No need of Log for recovery.
❖To manage access of data items by concurrent transactions two
directories (current and shadow) are used.
 Cont’d

• Advantages:
• Log-record overhead is removed
• No UNDO / No REDO algorithm
• Faster recovery

• Disadvantages:
• Data fragmentation (locality property loss, i.e. because shadow
paging causes database pages to change location).
• Garbage collection: when the transaction commits, database
containing old version of data changed by transaction become
inaccessible.
 Checkpointing
❖ Checkpoint is a mechanism where all the previous logs are removed
from the system and stored permanently in a storage
disk. Checkpoint declares a point before which the DBMS was in
consistent state, and all the transactions were committed.
❖The checkpoint is like a bookmark. While the execution of the transaction,
such checkpoints are marked, and the transaction is executed then using the
steps of the transaction, the log files will be created.
❖When it reaches to the checkpoint, then the transaction will be updated into
the database, and till that point, the entire log file will be removed from the
file.
❖Then the log file is updated with the new step of transaction till next
checkpoint and so on.
❖The checkpoint is used to declare a point before which the DBMS was in the
consistent state, and all transactions were committed.
 Data Caching
❖Data caching can be one of the most effective strategies to improve your
overall application performance and to reduce your database costs.

❖Caching is a buffering technique that stores frequently-queried data in a

temporary memory. It makes data easier to be accessed and reduces
workloads for databases.

❖ 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.

❖ When DBMS request for read /write operation on some item:

❖ It check the requested data item is in the cache or not

❖ If it is not, the appropriate disk block are copied to the cache

19
 4. Recovery in multi-database system
❖A multi-database system is a special distributed database system
where one node may be running relational database system under
UNIX, another may be running object-oriented system under Windows
and so on.
❖Needs access to multiple DBs stored in d/t places accessed by local
and global recovery managers.
❖A transaction may run in a distributed fashion at multiple nodes.
❖In this execution scenario, the transaction commits only when all these
multiple nodes agree to commit individually the part of the transaction
they were executing.
❖This commit scheme is referred to as “two-phase commit” (2PC).
❖If any one of these nodes fails or cannot commit the part of the
transaction, then the transaction is aborted.
❖Each node recovers the transaction under its own recovery protocol.
 5. The ARIES Recovery Algorithm (Reading Assignment)
❖ARIES: stands for Algorithm for Recovery and Isolation
Exploiting Semantics.
❖ARIES algorithm widely used recovery algorithm used in disk-based
database systems.
❖A well-known technique used in database systems to ensure
transactional consistency and recover from system failures.
❖It is used in many relational database-related products of IBM to
reduce the time taken for recovery and to reduce the overhead of
checkpointing.
❖ARIES uses a no-force approach for writing, and it is based on three
concepts:
❖WAL (Write Ahead Logging)
❖which means that all modifications to the database must be logged
before they are applied to the actual data.
❖Repeating history during redo:
❖Logging changes during undo:
 Cont’d
❖The ARIES recovery algorithm consists of three steps:
1. Analysis: step identifies the dirty (updated) pages in the buffer
and the set of transactions active at the time of crash. The
appropriate point in the log where redo is to start is also
determined.
2. Redo: necessary redo operations are applied.
3. Undo: log is scanned backwards and the operations of
transactions active at the time of crash are undone in reverse
order.