Wachemo University

(Durame Campus)

College of Engineering and Technology

Department of: Computer Science
Course Title: Advanced Database System
Course code: cosc2042
Name Daniel Temesgne ID 1403298

Table of Contents

Page
1.1 Backup and Recovery Concepts ____________________________________________2
1.2. Backup and Recovery Operations___________________________________________2
2.1. Recovery Concepts Based on Deferred Update________________________________4
2.2 Deferred update in a single-user environment_________________________________5
2.3 Deferred update in a multi-user environment_________________________________ 7
3.1 Recovery Concepts Based on Immediate Update_______________________________8
4.1 Shadow Paging__________________________________________________________9
5.1 The ARIES Recovery Algorithm______________________________________________9
6.1. Recovery in Multi-database Systems________________________________________1

1
1.1 Backup and Recovery Concepts
Backup and recovery are essential techniques in database
management to ensure data availability and integrity. Backup
involves creating copies of the database at specific points in
time, serving as a restore point in case of data loss or
corruption. It involves strategies such as full backups (copying
the entire database), incremental backups (copying only the
changes since the last backup), and differential backups
(copying the changes since the last full backup). Recovery, on
the other hand, focuses on restoring the database to a
consistent state after a failure or system crash. This involves
restoring the database from a backup and applying transaction
logs to recover any lost or incomplete transactions.

1.2 Backup and Recovery Operations

A physical backup is a snapshot of a datafile,

tablespace, or database at a certain time. If you make
periodic backups of a database, then should you lose
some of the data on your original database, you can
perform media recovery using the backups. During
media recovery, you apply redo records or
incremental backups to your latest backup to make
the database current again. If the backup was
a consistent backup, then you can also restore the
backup without performing recovery.

2
Which Data Structures Are Important for
Backup and Recovery
Before you can begin thinking seriously about backup and recovery
strategy, you need to understand the physical data structures that are
relevant for backup and recovery operations. In this section we will
briefly discuss:

The Use of Datafiles.

 Oracle reads the data in a datafile during normal operation and stores it
in the in-memory buffer cache. For example, assume that a user wants to
access some data in a table. If the requested information is not already in
the buffer cache, Oracle reads it from the appropriate datafiles and stores
it in memory.

Control Files

Every Oracle database has a control file. A control file is an extremely important
binary file that contains the operating system filenames of all other files constituting
the database. It also contains consistency information that is used during recovery,
such as:

The database name.

The timestamp of database creation.

Why Are Backups Important?

Imagine the magnitude of lost revenue--not to mention the degree of

customer dissatisfaction--if the production database of a catalog company,
express delivery service, bank, or airline suddenly became unavailable, even

3
for just 5 or 10 minutes. Alternatively, imagine that you lose important
payroll datafiles due to a hard disk crash and cannot restore or recover them
because you do not have a backup. Depending on the size and value of the
lost information, the results can be devastating

1.2. Recovery Concepts Based on Deferred Update

Recovery concepts based on deferred update defer the
application of transaction modifications until after the
transaction is committed. In this approach, the original
database remains unmodified, and the changes made by
transactions are recorded in a transaction log. During recovery,
the transaction log is analyzed to determine the state of
transactions at the time of failure. Undo operations reverse the
effects of uncommitted transactions, while redo operations
reapply the effects of committed transactions. This ensures that
the database remains in a consistent state even after failures.
Deferred update recovery provides durability and consistency
by carefully managing the application of transaction changes
A typical deferred update protocol can be described as follows −

 A transaction is not allowed to modify the database on disk until it

reaches its commit point.

 A transaction reaches its commit point only when all REDO-type log
entries are recorded in the log, and the log buffer is forcefully written
to disk.

Advantages and disadvantages

If a transaction is aborted, regardless of the reason (such as deadlock
detection), it can simply be resubmitted since it has not made any

4
changes to the database on disk. However, the method described here has
certain limitations and considerations. One drawback is that it restricts the
concurrent execution of transactions because write-locked items remain
locked until the transaction reaches its commit point. Moreover, it may
require a significant amount of buffer space to hold all updated items until
the transactions are committed. Despite these limitations, the method
offers two main advantages

2.2 Deferred update in a single-user environment

We first discuss recovery based on deferred update in single-user systems, where no
concurrency control is needed, so that we can understand the recovery process
independently of any concurrency control method. In such an environment, the recovery
algorithm can be rather simple. It works as follows.
Use two lists to maintain the transactions: the committed transactions list, which contains
all the committed transactions since the last checkpoint, and the active transactions list
(at most one transaction falls in this category, because the system is a single-user one).
Apply the REDO operation to all the write_item operations of the committed transactions
from the log in the order in which they were written to the log. Restart the active
transactions.

The REDO procedure is defined as follows:

Redoing a write_item operation consists of examining its log entry write_item(T, x,
old_value, new_value) and setting the value of item x in the database to new_value. The
REDO operation is required to be idempotent, as discussed before.

Notice that the transaction in the active list will have no effect on the database because
of the deferred update protocol, and is ignored completely by the recovery process. It is

5
implicitly rolled back, because none of its operations were reflected in the database.
However, the transaction must now be restarted, either automatically by the recovery
process or manually by the user.
The method’s main benefit is that any transaction operation need never be undone,
as a transaction does not record its changes in the database until it reaches its commit
point.
The protocol is summarised in the diagram below:

Figure 14.7
The diagram below shows an example of recovery in a single-user environment, where
the first failure occurs during execution of transaction T2. The recovery process will redo
the write_item(T1, D, 20) entry in the log by resetting the value of item D to 20 (its new
value). The write(T2, …) entries in the log are ignored by the recovery process because
T2 is not committed. If a second failure occurs during recovery from the first failure, the
same recovery process is repeated from start to finish, with identical results.

Figure 14.8

Figure 14.9

2.3Deferred update in a multi-user environment

For a multi-user system with concurrency control, the recovery process may be more
complex, depending on the protocols used for concurrency control. In many cases, the
concurrency control and recovery processes are interrelated. In general, the greater the
degree of concurrency we wish to achieve, the more difficult the task of recovery
becomes.

6
Consider a system in which concurrency control uses two-phase locking (basic 2PL) and
prevents deadlock by pre-assigning all locks to items needed by a transaction before the
transaction starts execution. To combine the deferred update methods for recovery with
this concurrency control technique, we can keep all the locks on items in effect until the
transaction reaches its commit point. After that, the locks can be released. This ensures
strict and serialisable schedules. Assuming that checkpoint entries are included in the
log, a possible recovery algorithm for this case is given below.
Use two lists of transactions maintained by the system: the committed transactions list
which contains all committed transactions since the last checkpoint, and the active
transactions list. REDO all the write operations of the committed transactions from the
log, in the order in which they were written into the log. The transactions in the active list
that are active and did not commit are effectively cancelled and must be resubmitted.
The REDO procedure is the same as defined earlier in the deferred update in the single-
user environment.
The diagram below shows an example schedule of executing transactions. When the
checkpoint was taken at time t1, transaction T1 had committed, whereas transaction T3
and T4 had not. Before the system crash at time t2, T3 and T2 were committed but not
T4 and T5. According to the deferred update method, there is no need to redo the write
operations of transaction T1 or any transactions committed before the last checkpoint
time t1. Write operations of T2 and T3 must be redone, however, because both
transactions reached their commit points after the last checkpoint. Recall that the log is
force-written before committing a transaction. Transaction T4 and T5 are ignored: they
are effectively cancelled and rolled back because none of their write operations were
recorded in the database under the deferred update protocol.

Figure 14.10

3.1. Recovery Concepts Based on Immediate Update

Recovery concepts based on immediate update involve
applying modifications to the database immediately, without
deferring them until after a transaction is committed. In this
approach, changes made by transactions are immediately
written to the database, making them visible to other
transactions. During recovery, the transaction log is analyzed to
determine the state of committed and uncommitted
transactions at the time of failure. Committed transactions'
changes are reapplied to the database, while uncommitted
transactions' changes are undone. Immediate update recovery

7
ensures that the database remains consistent by appropriately
handling transaction modifications.

In these techniques, when a transaction issues an update command, the

database on disk can be updated immediately, without any need to wait
for the transaction to reach its commit point. Notice that it is not a
requirement that every update be

4.1 Shadow Paging

Shadow paging is a database recovery technique that works by
maintaining a shadow or snapshot copy of the database during
transaction execution. Instead of directly modifying the original
database pages, changes are written to new pages or a
separate area called the shadow copy. The shadow page table
is used to maintain a consistent view of the database. During
recovery, the shadow copy is discarded, and the original
database is restored to its previous state by reverting to the
original page table. Shadow paging simplifies recovery by
avoiding complex log analysis and undo/redo operations,
offering a straightforward approach to database recovery.

8
5.1 The ARIES Recovery Algorithm
 is relies on logging of all database operations with ascending
Sequence Numbers.
 The ARIES (Algorithm for Recovery and Isolation Exploiting
Semantics) recovery algorithm is a widely used technique
for database recovery. ARIES follows the write-ahead
logging (WAL) principle, where changes to the database are
recorded in a transaction log before being applied to the
actual data. It combines the concepts of redo and undo
operations to ensure consistent recovery.

During recovery, ARIES analyzes the transaction log to identify

the most recent checkpoint and determine the transactions
that need to be redone or undone. Redo operations reapply the
changes made by committed transactions, while undo
operations reverse the changes made by uncommitted or
aborted transactions. ARIES also incorporates checkpoints to
minimize recovery time by starting from a stable state in the
transaction log.

9
6.1. Recovery in Multi-database Systems
Recovery in multi-database systems involves restoring the
consistency and integrity of interconnected databases in the
event of failures or system crashes. In a multi-database
environment, where databases are distributed across different
systems or locations, recovery becomes more complex. It
requires distributed transaction management protocols to
coordinate and synchronize transactions across multiple
databases. Recovery in multi-database systems includes
techniques such as distributed checkpoints, distributed logging,
and global commit or abort decisions. Data replication and
backup strategies are crucial for ensuring data availability and
providing recovery options. Recovery in multi-database systems
ensures the consistency and durability of data across the
distributed environment.

10
11
 References

1. Database System Concepts" by Abraham Silberschatz”

2. Database Management Systems" by Raghu Ramakrishnan and Johannes Gehrke”
3. Database Design for Mere Mortals" by Michael J. Hernandez”
4. google

12