The document outlines various types of failures in database systems, including transaction failures, system crashes, and disk failures, as well as storage types like volatile and non-volatile storage. It discusses transaction management, detailing operations such as reading and writing in a transaction's private work-area and the use of transaction logs for recovery processes like undoing and redoing changes. Additionally, it introduces checkpointing as a method to manage database updates and recovery efficiency.

1. prepared by Visakh V,Assistant Professor,
LBSITW

2. Types of failure
1. Transaction failure
•Logical error
• System error
: (due to internal
condition) bad input, data
not found, resource limit
exceed.
:entered an undesirable
state (ex:deadlock)
prepared by Visakh V,Assistant Professor,
LBSITW

3. 2. System crash
: h/w malfunction , or a bug in the database
s/w or OS
: loss of content in volatile
3. Disk failure
: head crash or failure during data
transfer operation.
prepared by Visakh V,Assistant Professor,
LBSITW

4. •Volatile storage:
•does not survive system crashes
•examples: main memory, cache memory
•Nonvolatile storage:
•survives system crashes
•examples: disk, tape, flash memory,
non-volatile (battery backed up) RAM
•but may still fail, losing data
•Stable storage:
•a mythical form of storage that survives all failures
•approximated by maintaining multiple copies on
distinct nonvolatile mediaprepared by Visakh V,Assistant Professor,
LBSITW

5. prepared by Visakh V,Assistant Professor,
LBSITW

6. prepared by Visakh V,Assistant Professor,
LBSITW

7. Blocks : Fixed length storage units
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.
prepared by Visakh V,Assistant Professor,
LBSITW

8. Example of Data Access
X
Y
A
B
x1
y1
buffer
Buffer Block A
Buffer Block B
input(A)
output(B)
read(X)
write(Y)
disk
work area
of T1
work area
of T2
memory
x2
prepared by Visakh V,Assistant Professor,
LBSITW

9. • 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.
• Transactions
– Must perform read(X) before accessing X for the first time
(subsequent reads can be from local copy)
– write(X) can be executed at any time before the transaction
commits prepared by Visakh V,Assistant Professor,
LBSITW

10. Transaction Log
• also know as journal log / redo-log
• It is a physical file
• It usually contain
• transaction identifier
• data –item identifier(or time stamp)
• old value
• new value
prepared by Visakh V,Assistant Professor,
LBSITW

11. prepared by Visakh V,Assistant Professor,
LBSITW

12. 1.<Ti start> : transaction Ti starts
2. <Ti, X, V1, V2> : Before Ti executes write(X)
3.<Ti commit> : Ti finishes it last statement
4. <Ti abort>
We denote various type of log record as
prepared by Visakh V,Assistant Professor,
LBSITW

13. <T0 start>
<T0, A, 1000, 950>
<To, B, 2000, 2050>
<T0 commit>
<T1 start>
<T1, C, 700, 600>
<T1 commit>
prepared by Visakh V,Assistant Professor,
LBSITW

14. prepared by Visakh V,Assistant Professor,
LBSITW

15. •Also known as NO UNDO/REDO
• Algorithm to support O/S, application, power,
memory and machine failures
• During transaction run changes recorded only in the
log files not in database
• On commit changes made from
Log  database
• this process is called “Re-doing”(redo(Ti)),sometimes
known as ROLLFORWARD.
• on rollback ,just discard the log files
• on commit, just copy the log files to databaseprepared by Visakh V,Assistant Professor,
LBSITW

16. prepared by Visakh V,Assistant Professor,
LBSITW

17. prepared by Visakh V,Assistant Professor,
LBSITW

18. •Disadvantage
•Increased time of recovery in case of
system failure.
prepared by Visakh V,Assistant Professor,
LBSITW

19. •Also known as UNDO/REDO
• Algorithm to support O/S,
application, power, memory and
machine failures
•Transaction updates/alternation
prepared by Visakh V,Assistant Professor,
LBSITW

20. •On commit all the changes to the db are made
permanent and log files discarded
• On rollback , using the log entries old values are
restored. All the changes in the database are discarded.
•This process is called un-doing(undo(Ti)).
• original values are restored using the log files for
uncommitted transaction.
prepared by Visakh V,Assistant Professor,
LBSITW

21. prepared by Visakh V,Assistant Professor,
LBSITW

22. Log Write Output
<T0 start>
<T0, A, 1000, 950>
<To, B, 2000, 2050
A = 950
B = 2050
<T0 commit>
<T1 start>
<T1, C, 700, 600>
C = 600
BB , BC
<T1 commit>
BA
• Note: BX denotes block containing X.
BC output before T1
commits
BA output after T0
commits
prepared by Visakh V,Assistant Professor,
LBSITW

23. prepared by Visakh V,Assistant Professor,
LBSITW

24. • The process of undoing changes using log files is
frequently referred to as rollback
•Disadvantage
•Frequent I/O operations while the
transaction Is active .
prepared by Visakh V,Assistant Professor,
LBSITW

25. •Commercial RDMS is neither deferred nor immediate
• Database updated at fixed interval of time
•Irrespective of transaction commit/un-commit state.
•Check pointing : updating transaction at fixed intervals of
time is called check-pointing.
• @ check point time log files changes applied to the
database.
•
prepared by Visakh V,Assistant Professor,
LBSITW

26. prepared by Visakh V,Assistant Professor,
LBSITW

27. prepared by Visakh V,Assistant Professor,
LBSITW

28. prepared by Visakh V,Assistant Professor,
LBSITW

29. • During recovery we need to consider only the most recent
transaction Ti that started before the checkpoint, and
transactions that started after Ti.
1. Scan backwards from end of log to find the most recent
<checkpoint L> record
– Only transactions that are in L or started after the
checkpoint need to be redone or undone
– Transactions that committed or aborted before the
checkpoint already have all their updates output to stable
storage.
• Some earlier part of the log may be needed for undo
operations
1. Continue scanning backwards till a record <Ti start> is
found for every transaction Ti in L.
– Parts of log prior to earliest <Ti start> record above are not
needed for recovery, and can be erased whenever desired.
prepared by Visakh V,Assistant Professor,
LBSITW

30. prepared by Visakh V,Assistant Professor,
LBSITW

31. prepared by Visakh V,Assistant Professor,
LBSITW

32. prepared by Visakh V,Assistant Professor,
LBSITW

33. •Alternative to log-based crash-recovery techniques.
•Advantage: require few disk access than log-based.
• pages : fixed length portioned block in database.
• page table :
•The page table has n entries—one for each
database page.
•Each entry contains a pointer to a page on
disk .
prepared by Visakh V,Assistant Professor,
LBSITW