2. 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.
There are both automatic and non-automatic ways for
both, backing up of data and recovery from any
failure situations.
3. 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.
4. Undoing – If a transaction crashes, then the recovery
manager may undo transactions i.e. reverse the
operations of a transaction.
Deferred update – This technique does not physically
update the database on disk until a transaction has
reached its commit point.
Immediate update – In the immediate update, the
database may be updated by some operations of a
transaction before the transaction reaches its commit
point.
5. Failure Classification
Storage Structure
Recovery and Atomicity
Log-Based Recovery
Shadow Paging
Recovery With Concurrent Transactions
Buffer Management
Failure with Loss of Nonvolatile Storage
Advanced Recovery Techniques
6. Transaction failure:
Logical errors- Transaction cannot complete
due to some internal error condition.
System errors-the database system must
terminate an active transaction due to an error
condition(e.g. Deadlock)
System crash- A power failure or other
hardware or software failure causes the system to crash. It
is assumed that non-volatiles torage contents are not
corrupted.
7. Volatile storage: – does not survive system crashes
– examples: main memory,cachememory
Nonvolatile storage: – survives system crashes
– examples: disk, tape
Stable storage: – A mythical form of storage that
survives all failures
– approximated by maintaining multiple copies on
distinct nonvolatile media
8. 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 result in inconsistent copies .
Protecting storage media from failure during data transfer(one
solution).
– Execute output operation as follows(assuming two copies of
each block):
1.Writetheinformationontothefirstphysicalblock.
2.Whenthefirstwritesuccessfullycompletes,writethe same
information on to the second physical block.
3.Theoutputiscompletedonlyafterthesecondwrite successfully
completes.
9. 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.
10. Each transaction Ti has its private work-area in which
local copies of all data items accessed and updated by it
are kept.
Ti ’s local copy of a data item X is called xi .
We assume, for simplicity, that each data item fits in,
and is stored inside, a single block.
11. Transaction transfers data items between system buffer
blocks and its private work-area using the following
operations: –read( X ) assigns the value of data item X
to the local variable xi . –write( X ) assigns the value of
local variable xi to data item X in the buffer block.
Both these commands may necessitate the issue of an
input( BX )instruction before the assignment ,if the
block BX in which X resides is not already in memory.
12. Transactions perform read( X )while accessing X for
the first time; all sub sequent accesses are to the local
copy .After last access, transaction executes write( X ).
output( BX )need not immediately follow write( X
).System can perform the output operation when it
deems fit.
13. Consider transaction Ti that transfers $50 from account
A to account ;go allies it her to perform all database
modifications made by Ti or none at all.
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.
14. We study two approaches: –log-based recovery , and –
shadow-paging
We assume(initially) that transactions run serially , that
is , one after the other.
Log-Based Recovery:
• A log is kept on stable storage . The log is a
sequence of log records ,and maintains are cord of update
activities on the database.
• When transaction T starts, it registers itself by
writing a < Ti start > log record.
15. Before Ti executes write( X ),a log record < Ti ,X,V 1 ,V
2 > is written , where V 1 is the value of X before the
write , and V 2 is the value to be written to X .
•When Ti finishes it last statement , the log record < Ti
commit > is written.
•We assume for now that log record are written directly to
stable storage(that is , they are not buffered).
16. This scheme ensures atomicity despite failures by
recording all modifications to log, but deferring all the
writes to after partial commit.
Assume that transactions execute serially
Transaction starts by writing < Ti start > record to log.
17. A write( X )operation results in a log record < Ti ,X,V>
being written , where V Is the new value for X .The
write is not Performed on X
At this time , but is deferred. When Ti Partially
commits, < Ti commit > is written to the log
Finally , log records are used to actually execute the
previously deferred writes.
18. This scheme ensures atomicity despite failures by
recording all modifications to log , but deferring all the
writes to after partial commit.
Assume that transactions execute serially
Transaction starts by writing < Ti start > record to log.
A write( X ) operation results in a log record < Ti ,X,V
> being written , where V is the new value for X .The
write is not performed on X at this time , but is
deferred.
19. This scheme allows database update so fan
uncommitted transaction to be made as the writes are
issued ; since undoing may be needed , update logs
must have both old value and new value.
Update log record must be written before database
item is written .
Output of updated blocks can take place at any time
before or after transaction commit.
Order in which blocks are output can be different from
the order in which they are written.
