0% found this document useful (0 votes)
32 views17 pages

Multilevel Indexing

The document outlines the recovery system for databases, detailing failure classifications such as transaction failures, system crashes, and disk failures. It describes recovery algorithms that ensure data integrity through actions during normal processing and after failures, including log-based recovery mechanisms for maintaining atomicity, consistency, and durability. Additionally, it covers data access methods, storage structures, and the processes of undoing and redoing transactions in the event of failures.

Uploaded by

Vivek Yadav
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
32 views17 pages

Multilevel Indexing

The document outlines the recovery system for databases, detailing failure classifications such as transaction failures, system crashes, and disk failures. It describes recovery algorithms that ensure data integrity through actions during normal processing and after failures, including log-based recovery mechanisms for maintaining atomicity, consistency, and durability. Additionally, it covers data access methods, storage structures, and the processes of undoing and redoing transactions in the event of failures.

Uploaded by

Vivek Yadav
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 17

Recovery System

Failure Classification:
1. 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).

2. System crash: There is a hardware malfunction, or a bug in


the database software or the operating system, that causes the
loss of the content of volatile storage and brings transaction
processing to halt.

3. Disk failure: a head crash or similar disk failure destroys


all or part of disk storage.
Recovery Algorithms
Recovery algorithms have two parts
1. Actions taken during normal transaction processing to
ensure enough information exists to recover from
failures
2. 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
– examples: main memory, cache memory
• Nonvolatile storage:
– survives system crashes
– examples: disk, tape and flash memory,
• Stable storage:
– a mythical form of storage that survives all failures
– approximated by maintaining multiple copies on distinct
nonvolatile media
Data Access
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.
– Ti's local copy of a data item X is called xi.
• Transferring data items between system buffer blocks and its private work-area done by:
– 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.
– Note: output(BX) need not immediately follow write(X). System can perform the output
operation when it deems fit.
Example of Data Access
buffer
input(A)
Buffer Block A X A
Buffer Block B Y B
output(B)

read(X) write(Y)

x2
x1
y1

work area work area


of T1 of T2

memory disk
Recovery and Atomicity
• To ensure atomicity despite failures, we first output information
describing the modifications to stable storage without modifying
the database itself.
• We study log-based recovery mechanisms in detail
Log-Based Recovery
• A log is kept on stable storage.
– The log is a sequence of log records, and maintains a record of
update activities on the database.
• When transaction Ti starts, it registers itself by writing a
<Ti start> log record
• Before Ti executes write(X), a log record
<Ti, X, V1, V2> is written,
where V1 is the value of X before the write (the old Value), and V2 is the
value to be written to X (the new value).
• When Ti finishes it’s last statement, the log record
<Ti commit> is written.
• Two approaches using logs
– Deferred database modification
– Immediate database modification
Undo and Redo Operations
• Undo of a log record <Ti, X, V1, V2> writes the old
value V1 to X
• Redo of a log record <Ti, X, V1, V2> writes the new
value V2 to X
• Undo and Redo of Transactions
– undo(Ti) restores the value of all data items updated
by Ti to their old values, going backwards from the
last log record for Ti
• each time a data item X is restored to its old value
V a special log record <Ti , X, V> is written out
• when undo of a transaction is complete, a log
record <Ti abort> is written out.
– redo(Ti) sets the value of all data items updated by Ti
to the new values, going forward from the first log
record for Ti
• No logging is done in this case
Undo and Redo on Recovering from Failure
• When recovering after failure:
– Transaction Ti needs to be undone if the log
• contains the record <Ti start>, but does not contain
either the record <Ti commit> or <Ti abort>.
– Transaction Ti needs to be redone if the log
• contains the records <Ti start> and contains the record
<Ti commit> or <Ti abort>
• Note that If transaction Ti was undone earlier and the
<Ti abort> record written to the log, and then a failure
occurs, on recovery from failure Ti is redone
– such a redo redoes all the original actions including the
steps that restored old values
• Known as repeating history
• Seems wasteful, but simplifies recovery greatly
Immediate Database Modification
The immediate database modification scheme allows database updates of an 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
We assume that the log record is output directly to stable storage
Can be extended to postpone log record output, so long as prior to execution of an output(B)
operation for a data block B, all log records corresponding to items B must be flushed to
stable storage
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.
Immediate Database Modification Example
Log Write Output
T0: read (A)
<T0 start>
<T0, A, 1000, 950>
A: - A - 50
A = 950 Write (A)
<To, B, 2000, 2050> read (B)
B = 2050
<T0 commit> B:- B + 50
<T1 start> write (B)
<T1, C, 700, 600>
C = 600 T1 : read (C)
BB, BC
C:- C- 100
<T1 commit>
BA write (C)
Note: BX denotes block containing X.
• example transactions

T0: read (A)


A: - A - 50
Write (A)
read (B)
B:- B + 50
write (B)

T1 : read (C)
C:- C- 100
write (C)
NPTEL Question:
Q. Before transaction Ti executes write (X) operation, a log record REDO <Ti, X, V1, V2> is
written. [CRPQ-1]
Identify the correct option about that log record.
(a) Ti updates the value of X from old value V2 to new value V1
(b) Ti updates the value of X from old value V1 to new value V2
(c) Ti updates the value of X to any value in the range (V1,V2)
(d) Ti sets the value of X that toggles between V1 and V2
Practice Question:
Q: Consider the log of a transaction below. [MSQ]

< T1,start >


< T1,X,100,300 >
< T1,Y,300,400 >

Identify the correct statement from the following, which are


part of the Undo(T1)

a) X is restored to 300.
b) X is restored to 100.
c) Y is set to 400.
d) < T1,Y,300 > log record is written out.
NPTEL Question:
Q. Assume an immediate database modification scheme. Consider the
following log consisting transactions T0, T1 and T2 [CRPQ-3]
Steps Details of log

1 <T0 start> For the above transaction schedule, if a crash occurs


2 <T0, A, 100, 200> just after step 9. Which of the following is the
3 <T0, A, 200, 300>
correct way for recovery?
4 <T1 start>
(a) undo (T1) then redo (T0) then redo (T2)
5 <T0 commit>
6 <T1, B, 500, 400> (b) undo (T2) then redo (T0) then redo (T1)
7 <T1 commit> (c) undo (T0) then redo (T1) then redo (T2)
8 <T2 start>
(d) undo (T2) then undo (T0) then undo (T1)
9 <T2, A, 300, 1500>
NPTEL Question:
Q. Consider the following example of a log of two transactions,
where immediate database modification scheme is used [CRPQ-4]

Steps Details of log If a crash occurs just after step 7 and the recovery
1 <T0 start> of the system is successfully completed, which of
2 <T0, A, 600, 500> the following action is true?
3 <T0, B, 800, 300> (a) T0: redo and T1: redo
4 <T1 start> (b) T0: undo and T1: undo
5 <T1, C, 700, 200>
(c) T0: undo and T1: redo
6 <T1, D, 500, 100>
(d) T0: No action and T1: No action
7 <T1 commit>

You might also like