Database Systems

COURSE WORK 02 (Report)

Question: Describe what is meant by forward and backward recovery by
explaining how the log file is used in forward and backward recovery. What is
the significance of the write-ahead log protocol?

Module ID: CO623HZ

Student Name: Fathima Noora Hameed

FATHIMA NOORA HAMEED 21417918

1. Introduction
Database Management System (DBMS) is complex software that assists in maintaining a
large amount of data that undergoes frequent changes with many transactions being executed every
single second. A transaction is a sequence of operations performed as a single logical unit of work. It
must represent four properties, called the atomicity, consistency, isolation, and durability (ACID)
properties to qualify as a transaction. (TechNet, 2014)
Since transactions tend to alter the data stored in the database, it should ensure that after
every modification it makes to the database, the database remains consistent and coherent.
Therefore each transaction is preferred to pass the ACID test. ACID properties explained:

Atomicity refers to the ability of rejecting the entire unit of a transaction of database, if one part
of it fails to commit.

Consistency ensures consistence state of a database before the start of the transaction and
after the transaction is over, whether successful or not (Lightwolf, 2009).

Isolation refers to the ability of being able to view an operation of a transaction isolated and it
determines the integrity of a transaction within several users of a system.

Durability refers to the guarantee that once a transaction is successfully committed, it remains
persistent even after a database crash. These are considered as transactions that have been
written to the log and incase of a failure, can be retrieved to generate the database to its former
state before the failure. (Doctrine, 2012).

If a database crashes amid transaction being executed there should be some techniques or
mechanism to rectify the database to its former state from the failure or crash, from which point the
database can be brought back to function. There can be many reasons due to which a database can
fail or crash such as transaction failure, system crash or media failure.
The recovery manager which is a hardest component of DBMS is called during system
failures. It ensures two properties of any transactions namely atomicity and durability.
Atomicity is ensured by undoing the uncommitted actions of transactions and durability by
ensuring that all the actions of committed transactions are persistent and survive system
crashes (Ramakrishnan & Gerke 2003).
2. ARIES recovery algorithm
ARIES is a recovery algorithm based on Write-Ahead Log (WAL) protocol, which records
every update operation into the log. Ramakrishnan & Gerke (2003) suggests that ARIES is
conceptually simple and compatible with a wide range of concurrency control mechanisms and also
designed to work with a steal, no-force approach. When the recovery manager is invoked following a
database crash, restart should proceed in three phases:

Page 1 of 5

FATHIMA NOORA HAMEED 21417918

Analysis phase: Determines the earliest log record from which point to start the next phase
i.e. Redo. It identifies the dirty pages in the buffer pool and active transactions at the time of
the crash.

Redo phase: Repeats all actions where actions should be undone, starting from the point in
the log determined in the analysis phase, and restores the database to its former state,
what it was at the time of crash.

Undo phase: Undoes the actions of transactions which were active and did not commit at
the time of the system crash as determined by the analysis phase, so that the database
results only the committed transactions.

One of the main three principles behind the Aries algorithm is Write-Ahead Protocol.
3. Write-Ahead Logging
WAL (Write-Ahead logging) is method that ensures the data integrity of a database. Every
update log record that requests a change to a page must be recorded in a stable storage before the
actual alteration is written in the particular page. WAL protocol ensures two of the ACID properties
in a database system, namely atomicity and durability. WAL is used to flush log records to the
persistent log file before data pages are written (Website Hosting Blog, 2012).
A significance of WAL is that it ensures the availability of the records of every change to the
Database, while attempting to recover from a database failure or crash. Without WAL there
wouldnt be a method to ensure that the changes of a committed transaction survive crashes.
Committed transaction refers to a transaction whose log records including log record have all been
written to the stable storage (Ramakrishnan & Gerke, 2003).
There is no necessity to flush data pages after every transaction commit, because of the
assurance from the WAL protocol that at an event of a crash the database can be recovered using
the log. Any transactions that have not been applied to the data pages can be redone from the log
record. This process is called as forward recovery. Using WAL reduces the number of disk writes
since only need to guarantee a transaction to be committed is to flush the log file to the disk rather
than every data file changed by the transaction (PostgreSQL, 2014).
Further all the writes to the log file are sequential writes because the log is maintained in a
sequential file. When a transaction is committed the log tail (the most resent part of the log record)
is forced to stable storage where in contrast if a force approach is used, instead of a portion of the
log all the pages modified by transaction must be forced to disk following each transaction commits.
Therefore, compared to the cost of writing all changed pages to the disk, forcing only the log tail is
much smaller (Ramakrishnan & Gerke, 2003).
WAL also facilitates to support on-line backup and point-in-time recovery. By archiving the
WAL data it is possible to support reverting to any time instant covered by the available WAL data by
simply installing a prior physical backup of the database and replaying the WAL log to desired time

Page 2 of 5

FATHIMA NOORA HAMEED 21417918

even if the physical backup isnt an instantaneous snapshot of the database state, fixing any internal
inconsistencies for a period of time if it is made over some period of time (PostgreSQL, 2014).
A system that crashes amid transactions being executed can determine whether the
operations were successfully committed, partial succeeded or failed using a WAL which checks the
log comparing what has been done and what has to be done therefore the undo the partial
committed transactions and redoing again and keeping the committed transactions as they are.
4. The log
The log which is also called the trail or journal is a record of actions performed by the DBMS.
It is physically stored in a stable storage, and can be used in times of system crashes. Log tail is
referred as the most resent part of the log record. Every log record has an id called Log Sequence
Number (LSN) which used to uniquely identify each log record. A log record is written for each of
the following actions (Ramakrishnan & Gerke, 2003).

Update
Commit
Abort
End
Undoing and update
A database log record contains:

LSN: An Id to uniquely identify a log record.

prevLSN: A link to its last log record.
transID: A reference to the database transaction generating the log file.
Type: Describes the type of the log record.

There are also various types of log records which have the above attributes in common and may
have additional attributes depending on the type of the log.

Update Log Record records changes to the database.

Compensation Log Record records all the roll backs of a transaction.
Commit record records decision to commit a transaction.
Abort Record records decision to abort a transaction.
Checkpoint Record records the checkpoints that have been made.
Completion Record records all the transactions that have been fully committed or aborted.

5. Backward recovery
Also called as roll-back or Undo, a Forward Recovery procedure contributes to rectify a
database to the former state before a crash which is consistent enough, to proceed with the
transactions again. It uses the log file of before images to the crashed database to undo all the
uncommitted transactions that failed to commit due to system failure or crash. Any transaction
which failed or were active at the time of the crash can be rolled back to give a consistent state to

Page 3 of 5

FATHIMA NOORA HAMEED 21417918

the database that includes all the committed transactions which are successfully written to the
pages. After the backward recovery process the database is identified to be coherent.
E.g. Customer A wants to transfer $1000 from his account to Customer B. Program reads the
records and deducts $1000 from Customer As account balance. Program writes the updated record
of Customer A to the database. When attempting to write for Customer B the program fails due to
a system crash and is unsuccessful. The Undo command of backward recovery restores the before
image of the Customer As account balance to its original value prior to deducting $1000.
Fig 5.1

6. Forward recovery
The Forward recovery which is also known to be roll-forward or redo is a recovery procedure
that re-does all the transactions that did not successfully commit at the time of the crash. The log file
of after image is used to achieve this process. Starting from the earlier copy of the database when
after images are applied, the database is moved to a later state, committing again all the
uncommitted transactions at the time of the crash. Only the most resent after image is applied.
Fig 6.1

Page 4 of 5

FATHIMA NOORA HAMEED 21417918

7. Reference

Doctrine 2012, Transactions, accessed on 23/September/2014,

<http://doctrine.readthedocs.org/en/latest/en/manual/transactions.html>

Lightwolf technologies 2009, Database ACID Properties, accessed on 23/September/2014,

<http://www.lightwolftech.com/index.php?page=backgrounders>

PostgreSQL, 2014, Write-Ahead Logging, accessed on 25/September/2014,

<http://www.postgresql.org/docs/9.0/static/wal-intro.html>

Ramakrishnan, R. & Gerke, J (2003) Database Management Systems: Crash recovery. Third
Edition. McGraw-Hill Companies, Inc., New York NY 10020.

TechNet, Microsoft SQL Server 2014, Transactions, accessed on 24/September/2014,

<http://technet.microsoft.com/en-us/library/aa213068(v=sql.80).aspx>

Website Hosting Blog 2012, DBMS: WAL Protocol, accessed on 24/September/2014,

<http://www.hostitwise.com/hosting-blog/dbms-wal-protocol/>

Page 5 of 5