Exit Exam Tutorial

Part 2: Fundamental Database Management Systems

Episode 9: Database Recovery and Security
2.9 Database Recovery and
Security
2.9.1 Database Recovery
- To bring the database into the last consistent state, which
existed prior to the failure.
- To preserve transaction properties (Atomicity and
Durability).
- The recovery manager of a DBMS is responsible to ensure
atomicity by undoing the action of transaction that do not
commit.
- Durability by making sure that all actions of committed
transaction survive system crash.
2.9 Database Recovery and
Security
2.9.2 Types of Failure
 The database may become unavailable for use due to:
- Transaction failure: Transactions may fail because of
incorrect input, deadlock.
- System failure: System may fail because of addressing error,
application error, operating system fault, RAM failure, etc.
- Media failure: Disk head crash, power disruption, etc.
2.9 Database Recovery and
Security
2.9.3 Transaction and Recovery
 Why recovery is needed:
- Whenever a transaction is submitted to the DBMS for execution, the
system is responsible for making sure that either all operations in the
transaction to be completed successfully or the transaction has no
effect on the database or any other transaction.
- What causes a Transaction to fail:

1. A computer failure (system crash): A hardware or software error

occurs in the computer system during transaction execution. If the
hardware crashes, the contents of the computer’s internal memory may
be lost.
2. A transaction or system error: Some operation in the transaction may
cause it to fail, such as integer overflow or division by zero.
 Transaction failure may also occur because of erroneous parameter
values or because of a logical programming error. In addition, the user
may interrupt the transaction during its execution.
2.9 Database Recovery and
Security
3. Exception conditions detected by the transaction: Certain
conditions forces cancellation of the transaction.
4. Concurrency control enforcement: The concurrency
control method may decide to abort the transaction, to be
restarted later, because it violates serializability or because
several transactions are in a state of deadlock.
5. Disk failure: Some disk blocks may lose their data because
of a read or write malfunction or because of a disk read/write
head crash.
 This may happen during a read or a write operation of the
transaction.
6. Physical problems and catastrophes: This refers to an
endless list of problems that includes power or air-
conditioning failure, fire, theft, overwriting disks or tapes by
mistake.
2.9 Database Recovery and
Security
Transaction Manager: Accepts transaction commands from
an application, which tell the transaction manager when
transactions begin and end, as well as information about the
expectations of the application.
 The transaction processor performs the following tasks:
- Logging: In order to assure durability, every change in the
database is logged separately on disk.
- Log manager initially writes the log in buffers and
negotiates with the buffer manager to make sure that
buffers are written to disk at appropriate times.
- Recovery Manager: will be able to examine the log of
changes and restore the database to some consistent state.
2.9 Database Recovery and
Security
Recovery techniques and facilities
- Recovery algorithms are techniques to ensure database
consistency and transaction atomicity and durability despite
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.
 Storage Structure
- Volatile storage: does not survive system crashes.
- Nonvolatile storage: survives system crashes.
- Stable storage: a mythical form of storage that survives all
failures approximated by maintaining multiple copies on
distinct nonvolatile media.
2.9 Database Recovery and
Security
 Maintain multiple copies of each block on separate disks
- Copies can be at remote sites to protect against disasters
such as fire or flooding.
- Failure during data transfer can still result in inconsistent
copies: Block transfer can result in
- Successful completion.
- Partial failure: destination block has incorrect information.
- Total failure: destination block was never updated.
2.9 Database Recovery and
Security
 Copies of a block may differ due to failure during output
operation. To recover from failure:
 First find inconsistent blocks:
1. Expensive solution: Compare the two copies of every disk
block.
2. Better solution: Record in-progress disk writes on non-
volatile storage (Nonvolatile RAM or special area of disk).
 Use this information during recovery to find blocks that
may be inconsistent, and only compare copies of these.
 Used in hardware RAID systems
 If either copy of an inconsistent block is detected to have an
error (bad checksum), overwrite it by the other copy.
 If both have no error, but are different, overwrite the
second block by the first block.
2.9 Database Recovery and
Security
Data Access
 Physical blocks are those blocks residing on the disk.
 Buffer blocks are the blocks residing temporarily in main
memory.
 Block movements between disk and main memory are
initiated through the following two operations:
- input(B) transfers the physical block B to main memory.
- output(B) transfers the buffer block B to the disk, and
replaces the appropriate physical block there.
 Each transaction Ti has its private work-area in which local
copies of all data items accessed and updated by it are kept.
2.9 Database Recovery and
Security
Recovery and Atomicity
- Modifying the database without ensuring that the
transaction will commit may leave the database in an
inconsistent state.
- Several output operations may be required for Ti (to output
A and B).
- A failure may occur after one of these modifications have
been made but before all of them are made.
- To ensure atomicity despite failures, we first output
information describing the modifications to stable storage
without modifying the database itself.
- We study two approaches: log-based recovery, and
shadow-paging.
2.9 Database Recovery and
Security
System log
- To recover from system failure , the system keeps information
about the change in the system log
- Strategy for recovery may be summarized as :
 Recovery from catastrophic.
- If there is extensive damage to the wide portion of the
database.
- This method restore a past copy of the database from the
backup storage and reconstructs operation of a committed
transaction from the back up log up to the time of failure.
 Recovery from non-catastrophic failure
- When the database is not physically damaged but has be come
in consistent.
- The strategy uses undoing and redoing some operations in
order to restore to a consistent state.
2.9 Database Recovery and
Security
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 brining back the
system to a stable state after a system crash.
2.9 Database Recovery and
Security
Data Caching
- 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.
- If the cache is already full, some buffer replacement policy
can be used. Like Least recent used (LRU), FIFO.
- While replacing buffers , first of all the updated value on
that buffer should be saved on the appropriate block in the
database.
2.9 Database Recovery and
Security
Write-Ahead Logging
- When in-place update (immediate or deferred) is used then
log is necessary for recovery.
- This log must be available to recovery manager.
- This is achieved by Write-Ahead Logging (WAL) protocol.
WAL states that:
- For Undo: Before a data item’s AFIM is flushed to the
database disk (overwriting the BFIM) its BFIM must be
written to the log and the log must be saved on a stable
store (log disk).
- For Redo: Before a transaction executes its commit
operation, all its AFIMs must be written to the log and the
log must be saved on a stable store.
2.9 Database Recovery and
Security
Standard Recovery Terminology
- Possible ways for flushing database cache to database disk:
i. No-Steal: Cache cannot be flushed before transaction
commit.
ii. Steal: Cache can be flushed before transaction commits.
iii. Force: if all Cache updates are immediately flushed
(forced) to disk when a transaction commits and then the
force writing.
iv. No-Force: if Cached are flushed to a disk when the need
arise after a committed transaction.
2.9 Database Recovery and
Security
 These give rise to four different ways for handling recovery:
- Steal/No-Force (Undo/Redo)
- Steal/Force (Undo/No-redo)
- No-Steal/No-Force (No-undo/Redo)
- No-Steal/Force (No-undo/No-redo)
2.9 Database Recovery and
Security
Check pointing
- Log file is used to recover failed database but we may not
know how far back in the log to search.
- Checkpoint is a Point of synchronization between database
and log file.
- Time to time (randomly or under some criteria) the
database flushes its buffer to database disk to minimize the
task of recovery.
- When failure occurs, redo all transactions that committed
since the checkpoint and undo all transactions active at
time of crash.
2.9 Database Recovery and
Security
Transaction Roll-back (Undo) and Roll-Forward (Redo)
- If transaction fails for what so ever reason after updating
the data base it must be necessary to roll back
- If a transaction T is roll back , any transaction that has read
the value of some data item X written by T must be also be
roll back
- Similarly once S is roll back, any transaction R that has read
the values of some data item Y written by S must also be roll
back, and so on.
2.9 Database Recovery and
Security
 To maintain such cases, a transaction’s operations are
redone or undone.
- Undo: Restore all BFIMs on to disk (Remove all AFIMs).
- Redo: Restore all AFIMs on to disk.
- Database recovery is achieved either by performing only
Undos or only Redos or by a combination of the two.
- These operations are recorded in the log as they happen.
2.9 Database Recovery and
Security
2.9.4 Data Update and Recovery Schemes
i. Deferred Update (No Undo/Redo)
- A set of transactions records their updates in the log.
- At commit point under WAL scheme these updates are
saved on database disk.
- No undo is required because no AFIM is flushed to the disk
before a transaction commits.
2.9 Database Recovery and
Security
- After reboot from a failure the log is used to redo all the
transactions affected by this failure.
- Limitation: out of buffer space may be happened because
transaction changes must be held in the cache buffer until
the commit point.
- Type of deferred updated recovery environment: Single
User and Multiple user environment.
2.9 Database Recovery and
Security
ii. Deferred Update in a single-user system
- There is no concurrent data sharing in a single user system.
- The data update goes as follows:
- A set of transactions records their updates in the log.
- At commit point under WAL scheme these updates are
saved on database disk.
2.9 Database Recovery and
Security
Deferred Update with concurrent users
- This environment requires some concurrency control
mechanism to guarantee isolation property of transactions.
- In a system recovery, transactions which were recorded in
the log after the last checkpoint were redone.
- The recovery manager may scan some of the transactions
recorded before the checkpoint to get the AFIMs.
- Two tables are required for implementing this protocol:
 Active table: All active transactions are entered in this
table.
 Commit table: Transactions to be committed are entered in
this table.
- During recovery, all transactions of the commit table are
redone and all transactions of active tables are ignored
since none of their AFIMs reached the database.
2.9 Database Recovery and
Security
iii. Recovery Techniques Based on Immediate Update
- Undo/No-redo Algorithm: In this algorithm AFIMs of a
transaction are flushed to the database disk under WAL
before it commits.
- For this reason the recovery manager undoes all
transactions during recovery.
- No transaction is redone.
- It is possible that a transaction might have completed
execution and ready to commit but this transaction is also
undone.
2.9 Database Recovery and
Security
iv. Shadow Paging
- Maintain two page tables during life of a transaction:
current page and shadow page table.
- When transaction starts, two pages are the same.
- Shadow page table is never changed thereafter and is used
to restore database in event of failure.
- During transaction, current page table records all updates
to database.
- When transaction completes, current page table becomes
shadow page table.
2.9 Database Recovery and
Security
2.9.5 The ARIES Recovery Algorithm
- It is designed to work with a steal , no- force approach.
- It is based on: three principles
 WAL (Write Ahead Logging)
- Any change to the database object is first recorded in the
log
- The record on the log must first be save on the disk and then
- The database object is written to disk
 Repeating history during redo:
- ARIES will retrace all actions of the database system prior
to the crash to reconstruct the database state when the
crash occurred.
- Transaction that were un committed at the time of crash
are undone.
2.9 Database Recovery and
Security
 Logging changes during undo:
- It will prevent ARIES from repeating the completed undo
operations if a failure occurs during recovery, which causes
a restart of the recovery process.
2.9 Database Recovery and
Security
 Data Update : Four types
Deferred Update:
- 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.
2.9 Database Recovery and
Security
Immediate Update:
- As soon as a data item is modified in cache, the disk copy is
updated.
- These update are first recorded on the log and on the disk by
force writing, before the database is updated.
- If a transaction fails after recording some change to the
database but before reaching its commit point , this will be
rolled back.
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
2.9 Database Recovery and
Security
In-place update:
- The disk version of the data item is overwritten by the
cache version.
- Information for ARIES to accomplish recovery procedures
includes: Log, Transaction Table & Dirty page table.
2.9 Database Recovery and
Security
i. The Log and Log Sequence Number (LSN)
- The log is a history of actions executed by the DBMS in
terms of a file of records stored in disk for recovery purpose
- A unique LSN is associated with every log record
- LSN increases monotonically and indicates the disk address
of the log record it is associated with.
- In addition, each data page stores the LSN of the latest log
record corresponding to a change for that page.
- A log record is written for each of the following actions:
 Updating a page
i. After modifying the page , an update record is appended
to the log tail.
ii. The LSN of the page is then set to the LSN of the update
log record.
2.9 Database Recovery and
Security
- Commit: when a transaction decides to commit , it force
writes a commit type log record containing the transaction
id.
- Abort: when a transaction is aborted , an abort type log
containing the transaction id is appended to the log.
- End: when a transaction is aborted or committed , an end
type log record containing transaction id is appended to the
log.
- Undo update: when transaction is roll back its updates are
undone.
- A log record stores the previous LSN of that transaction, the
transaction ID and the type of log record.
2.9 Database Recovery and
Security
ii. The Transaction table and the Dirty Page table
 For efficient recovery following tables are also stored in the
log during checkpointing:
- Transaction table: Contains an entry for each active
transaction, with information such as transaction ID,
transaction status (in progresses, committed or aborted)
and the LSN of the most recent log record for the
transaction.
- Dirty Page table: Contains an entry for each dirty page in
the buffer, which includes the page ID and the LSN
corresponding to the earliest update to that page.
2.9 Database Recovery and
Security
iii. Check pointing
 A checkpointing does the following:
- Writes a begin_checkpoint record in the log
- Writes an end_checkpoint record in the log. With this
record the contents of transaction table and dirty page
table are appended to the end of the log.
- Writes the LSN of the begin_checkpoint record to a
special file. This special file is accessed during recovery to
locate the last checkpoint information.
- To reduce the cost of checkpointing and allow the system to
continue to execute transactions, ARIES uses “fuzzy check
pointing”.
2.9 Database Recovery and
Security
Special Thanks to the publisher and author with:
2.9 Database Recovery and
Security
 TOPICS AND THE CONCEPTS:
Database Recovery Concepts
Shadow Paging
Deferred Update
Immediate Update
Checkpointing
The ARIES Recovery Algorithm

REFERENCES:
Fundamental Database Management Systems (6th Edition) by Ramez Elmasri, Shamkant B. Navaathe
Database Systems: A Practical Approach to Design, Implementation, and Management (6th Edition) by
Thomas Connolly, Carolyn Begg

PRESENTED BY:
Mohammed Nebil

HISTORY OF THE PROGRAMMING:

Boyce Codd

SPECIAL THANKS:
Digital Library of Educations
Federal Democratic Republic of Ethiopia, Ministry of Educations
Ethiopian Education Short Note