UNIT-V

Recovery and Atomicity

When a system crashes, it may have several transactions being executed and various files opened for them
to modify the data items. Transactions are made of various operations, which are atomic in nature. But
according to ACID properties of DBMS, atomicity of transactions as a whole must be maintained, that is,
either all the operations are executed or none.

When a DBMS recovers from a crash, it should maintain the following −

 It should check the states of all the transactions, which were being executed.

 A transaction may be in the middle of some operation; the DBMS must ensure the atomicity of the
transaction in this case.

 It should check whether the transaction can be completed now or it needs to be rolled back.

 No transactions would be allowed to leave the DBMS in an inconsistent state.

There are two types of techniques, which can help a DBMS in recovering as well as maintaining the
atomicity of a transaction −

 Maintaining the logs of each transaction, and writing them onto some stable storage before actually
modifying the database.

 Maintaining shadow paging, where the changes are done on a volatile memory, and later, the actual
database is updated.

Log-based Recovery

Log is a sequence of records, which maintains the records of actions performed by a transaction. It is
important that the logs are written prior to the actual modification and stored on a stable storage media,
which is failsafe.

Log-based recovery works as follows −

 The log file is kept on a stable storage media.

 When a transaction enters the system and starts execution, it writes a log about it.

<Tn, Start>

 When the transaction modifies an item X, it write logs as follows −

<Tn, X, V1, V2>

It reads Tn has changed the value of X, from V1 to V2.

[Database Management System] Page 63

  When the transaction finishes, it logs −

<Tn, commit>

The database can be modified using two approaches −

 Deferred database modification − All logs are written on to the stable storage and the database is
updated when a transaction commits.

 Immediate database modification − Each log follows an actual database modification. That is, the
database is modified immediately after every operation.

Recovery with Concurrent Transactions

When more than one transaction are being executed in parallel, the logs are interleaved. At the time of
recovery, it would become hard for the recovery system to backtrack all logs, and then start recovering. To
ease this situation, most modern DBMS use the concept of 'checkpoints'.

Checkpoint

Keeping and maintaining logs in real time and in real environment may fill out all the memory space
available in the system. As time passes, the log file may grow too big to be handled at all. 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.

Recovery

When a system with concurrent transactions crashes and recovers, it behaves in the following manner −

 The recovery system reads the logs backwards from the end to the last checkpoint.

 It maintains two lists, an undo-list and a redo-list.

[Database Management System] Page 64

  If the recovery system sees a log with <Tn, Start> and <Tn, Commit> or just <Tn, Commit>, it puts
the transaction in the redo-list.

 If the recovery system sees a log with <Tn, Start> but no commit or abort log found, it puts the
transaction in undo-list.

All the transactions in the undo-list are then undone and their logs are removed. All the transactions in the
redo-list and their previous logs are removed and then redone before saving their logs.

BUFFER MANAGEMENT
The buffer manager is the software layer that is responsible for bringing pages from physical disk to main
memory as needed. The buffer manages the available main memory by dividing the main memory into a
collection of pages, which we called as buffer pool. The main memory pages in the buffer pool are
called frames.
Page Requests from Higher Level

Buffer Management in a DBMS

o Data must be in RAM for DBMS to operate on it!

o Buffer manager hides the fact that not all data is in RAM.

Buffer Manager
o A Buffer Manager is responsible for allocating space to the buffer in order to store data into the
buffer.

o If a user request a particular block and the block is available in the buffer, the buffer manager
provides the block address in the main memory.

o If the block is not available in the buffer, the buffer manager allocates the block in the buffer.
o If free space is not available, it throws out some existing blocks from the buffer to allocate the
required space for the new block.

o The blocks which are thrown are written back to the disk only if they are recently modified when
writing on the disk.

[Database Management System] Page 65

 o If the user requests such thrown-out blocks, the buffer manager reads the requested block from the
disk to the buffer and then passes the address of the requested block to the user in the main memory.

o However, the internal actions of the buffer manager are not visible to the programs that may create
any problem in disk-block requests. The buffer manager is just like a virtual machine.

Failure with Loss of Nonvolatile Storage

Until now, we have considered only the case where a failure results in the loss of information residing in
volatile storage while the content of the nonvolatile storage remains intact. Although failures in which the
content of nonvolatile storage is lost are rare, we nevertheless need to be prepared to deal with this type of
failure. In this section, we discuss only disk storage. Our discussions apply as well to other nonvolatile
storage types.

The basic scheme is to dump the entire content of the database to stable storage periodically—say, once per
day. For example, we may dump the database to one or more magnetic tapes. If a failure occurs that results
in the loss of physical database blocks, the system uses the most recent dump in restoring the database to a
previous consistent state. Once this restoration has been accomplished, the system uses the log to bring the
database system to the most recent consistent state.

More precisely, no transaction may be active during the dump procedure, and a procedure similar to
checkpointing must take place:

1. Output all log records currently residing in main memory onto stable storage.

2. Output all buffer blocks onto the disk.

3. Copy the contents of the database to stable storage.

4. Output a log record <dump> onto the stable storage.

Database Recovery Techniques in DBMS

Database systems, like any other computer system, are subject to failures but the data stored in it must be
available as and when required. When a database fails it must possess the facilities for fast recovery. It must
also have atomicity i.e. either transactions are completed successfully and committed (the effect is recorded
permanently in the database) or the transaction should have no effect on the database.
There are both automatic and non-automatic ways for both, backing up of data and recovery from any failure
situations. The techniques used to recover the lost data due to system crash, transaction errors, viruses,
catastrophic failure, incorrect commands execution etc. are database recovery techniques. So to prevent data
loss recovery techniques based on deferred update and immediate update or backing up data can be used.

[Database Management System] Page 66

Recovery techniques are heavily dependent upon the existence of a special file known as a system log. It
contains information about the start and end of each transaction and any updates which occur in
the transaction. The log keeps track of all transaction operations that affect the values of database items.
This information is needed to recover from transaction failure.
 The log is kept on disk start_transaction(T): This log entry records that transaction T starts the
execution.
 read_item(T, X): This log entry records that transaction T reads the value of database item X.
 write_item(T, X, old_value, new_value): This log entry records that transaction T changes the value
of the database item X from old_value to new_value. The old value is sometimes known as a before
an image of X, and the new value is known as an afterimage of X.
 commit(T): This log entry records that transaction T has completed all accesses to the database
successfully and its effect can be committed (recorded permanently) to the database.
 abort(T): This records that transaction T has been aborted.
 checkpoint: 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.
o uced as a result of insert, update or delete.

[Database Management System] Page 67