7.

Recovery and Transaction

• Failure Classification
• Storage Operation
• Transaction
Characteristic
Banking Example
Transaction States
• Log-Based Recovery
Deferred Update
Immediate Update
• Shadow Paging
• Recovery of Disk

7-1 7. Recovery and Transaction

 Failure Classification
• Recovery ?
- When Failure is happened, recover consistent state of
loss of information.
- consistent state : non-error state
• Failure Types
(1) Transaction failure : Transaction can no longer continue with
its normal execution owing to some internal condition such
as bad input, data not found, overflow, or resource limit
exceeded.
(2) System failure : The system has entered an undesirable state
(e.g. deadlock, main memory error), as a result of which the
transaction cannot continue with its normal execution.
(3) Media Failure : Nonvolatile storage error such as disk head
crash.
7-2 7. Recovery and Transaction
 Failure Recovery Idea
backup Failure
• Basic Recovery Idea ? delta part
- Redundancy of data
- Two Types of Redundancy
(1) Dump : Copy all database into another storage device
(disk or tape) periodically.
(2) Log : Store updated data and time into log file whenever
data are changed.
• Recovery operation
- Redo : When all database are failed, we recover the most recent
backup database and update delta part between backup
database and failed database using the log file.
- Undo : if current transaction have an error, we cancel the current
work.
7-3 7. Recovery and Transaction
 Storage Hierarchy
• Block
- unit of both storage allocation and data transfer
- Physical block : residing on disk
Buffer block : residing temporarily in main memory
- fixed-length storage unit (0.5K, 1K, 2K, 4K in UNIX)

• Storage Hierarchy of DBMS

- See  p. 362
- Database Buffer
Log Buffer
* overhead ?? => FLASH memory for log

7-4 7. Recovery and Transaction

 Storage Operations
• Block Movement Operations
Input(X) : transfers the physical block in which data item X
resides to main memory.
Output(X) : transfers buffer block on which X resides to the disk
and replaces the appropriate physical block there.
• Data Transfer Operations
Read(X, x) : assigns the value of data item X to local variable x.
a) If X 's block is not in main memory, execute input(X)
b) Assign to x the value of X from buffer block.
Write(X, x) : assigns the value of local variable x to data item X
in the buffer block.
a) If X 's block is not in main memory, execute input(X)
b) Assign the value of x to X in the block.
7-5 7. Recovery and Transaction
 Transaction
• Concepts
- single logical unit of work
e.g. funds transfer (which one account is debited and another
is credited)
- it is essential to database consistency
e. g. either both the credit and debit occur, or that neither occur.
"all or none" => atomicity
- Begin_Trans, End_Trans
• Characteristics (ACID)
• atomicity : all or none
• consistency : database is consistent after transaction operation
• isolation : no concurrent access
• durability : 영속성 , 지속성
7-6 7. Recovery and Transaction
 Banking Example
• Example
- Let T be a transaction that transfers 100 won from account A
to account B. This transaction may be defined as :
T : Begin_Trans
Read(A, a)
a = a - 100 A : 디스크상의 계정
Write(A, a) a : 메모리상의 계정
Read(B, b)
b = b + 100
Write(B, b)
End_Trans
* After transaction is executed, the sum of A and B account is
the same.identical.

7-7 7. Recovery and Transaction

 Banking Example (cont'd)

block of A A = 1000
A = 1000 B = 2000

Main Memory Disk

< Prior to execution of T >

block of A A = 900
A = 1000 B = 2000

Main Memory Disk

< After execution of Write(A, a) >

7-8 7. Recovery and Transaction

 Banking Example (cont'd)
block of A A = 900
A = 1000 B = 2000
block of B B = 2000

Main Memory Disk

< After execution of Read(B, b) >

block of A A = 900
A = 1000 B = 2000
block of B B = 2100

Main Memory Disk

< After execution of Write(B, b) > committed

디스크에 저장되었다는 보장 없다
7-9 7. Recovery and Transaction
 Banking Example (cont'd)
block of A A = 900
A = 900 B = 2000
block of B B = 2100

Main Memory Disk

< After execution of Output(A) >
 Failure occurred!?
 Aborted!
block of A A = 900
A = 1000 B = 2100
block of B B = 2100

Main Memory
Disk
< After execution of Output(B) >
이때 발생하는 모든 문제는 log 책임
7 - 10 7. Recovery and Transaction
 Transaction States
• Active :
execution transaction operations
• Partially Committed :
after the last statement has been executed.
(Output 수행 전 )
• Failed :
normal execution can no longer proceed.
• Aborted : after the transaction has been rolled back and database
restored to its state prior to the start of the transaction.
• Committed :
after "successful" completion.
( 로그에 변경된 부분이 저장 )

7 - 11 7. Recovery and Transaction

 Transaction States Diagram
log update
Partially
Committed Committed
proper operation

destroyed memory contents

Active

transaction error
system error Failed Aborted
Rollback

7 - 12 7. Recovery and Transaction

 Log-Based Recovery
• Log
- Most widely used structure for recording database
- Log record describes a single database write
• Log Record Type
<Ti , start> : Transaction Ti has started.
<Ti , Xj , V1, V2> : Transaction Ti has performed a write on
data item Xj. Xj had value V1 before the write and will have
value V2 after the write.
<Ti , commit> : Transaction Ti has committed.
* Ti : Transaction name Xj : data item name (account-name)
V1 : old value V2 : new value

7 - 13 7. Recovery and Transaction

 Log-Based Recovery (cont'd)
• Operation
- Whenever a transaction performs a write, it is essential that the
log record is created.
- The log record must be created before the database is modified.
- Once a log record exists we can output (write to disk physically)
the modification to the database.
- If we have some problem, we also have the ability to undo
a modification that has already been output to the database.
- The log must reside in stable storage.

7 - 14 7. Recovery and Transaction

 Deferred Database Modification
• What?
- Ensures transaction atomicity by recording all database
modification in the log, but deferring the execution of all write
operations of a transaction until the transaction partially commits.
- Not use undo :
If system crashes or the transaction aborts, then the information
on the log is simply ignored.
- Operation :
<Ti , start> : Before starts its execution, log record is written to the log.
<Ti , Xj , V2> : The write operation by Ti results in the writing of new record
to the log.
<Ti , commit> : When Ti partially commis, this record is written to the log

7 - 15 7. Recovery and Transaction

 Deferred Database Modification (Example)
• Example
- Let T1 be a transaction that transfers 100 won from account A
to account B. This transaction may be defined as :
T1 : Read(A, a)
a = a - 100
Write(A, a)
Read(B, b)
b = b + 100
Write(B, b)
Let T2 be a transaction that withdraws 200 won from account C.
This transaction can be defined as :
T2 : Read(C, c)
c = c - 200
Write(C, c)
7 - 16 7. Recovery and Transaction
 Deferred Database Modification (Example)
• State of log and database
- A result of the execution T1 and T2, Note that the value of A is
changed in database only after the record <T1, A, 900> :
Log Database Sequence of Time
<T1, start> (Buffer)
<T1, A , 900>
<T1, B , 2100>
<T1, commit>
A = 900
B = 2100
<T2, start> We don't know the value A, B are
stored in disk physically, Because
<T2, C , 2800> the system decides it (output).
<T2, commit>

7 - 17 C = 2800 7. Recovery and Transaction

 Deferred Database Modification (Example)
• Redo(Ti)
which sets the value of all data items updated by transaction Ti
to the new values in the order of log records.
• Determine which transactions need to redo (Failure 발생시 )
(1) redo :
The log contains both the record <T1, start > and the record
< T1, commit >.
This transaction may be or may not be stored disk physically.
(2) Reexecute transaction :
Other case.

7 - 18 7. Recovery and Transaction

 Deferred Database Modification (Example)
• Example of the System Crash before the Completion of the Transactions
<T1, start> <T1, start> <T1, start>
<T1, A , 900> <T1, A , 900> <T1, A , 900>
<T1, B , 2100> <T1, B , 2100> <T1, B , 2100>
<T1, commit> <T1, commit>
<T2, start> <T2, start>
<T2, C , 2800> <T2, C , 2800>
<T2, commit>
(a) (b) (c)

(a) Clash occurs just after write(B, b) :

- No recovery action need be taken, since no commit record
appears in the log.
- A = 1000, B = 2000, C = 3000 remain in disk.
7 - 19 7. Recovery and Transaction
 Deferred Database Modification (Example)
(b) Clash occurs just after write(C, c) :
- Recovery : redo(T1) is performed since the record < T1, commit >
appears in the log.
T1 의 결과가 디스크에
- Result : A = 900, B = 2100 come backup. 반영되었는지 알 수 없다 .
* T2 transaction must be reexecuted. Redo 하여 conform.

(c) Clash occurs just after < T2 , commit> :

- Recovery : redo(T1) and redo(T2) is performed since the
record < T1, commit > and the record < T2, commit > appears
in the log.
- Result : A = 900, B = 2100, C = 2800 come backup.

7 - 20 7. Recovery and Transaction

 Deferred Database Modification (Example)
(d) Crash occurs during Recovery Action :
- Some transaction may recover and other transaction may not
recover.
- Recovery actions are restarted from beginning.

7 - 21 7. Recovery and Transaction

 Immediate Database Modification
• What?
- Uncommitted modifications : Allows database modifications to
be output to database while the transaction is still in the
active state.
- Use undo :
If system crashes or the transaction aborts, then the old-value
field of log record is used to restore.
• Log Record Format :
<Ti , Xj , Vold ,Vnew>

• Undo(Ti)
which restores the value of all data items updated by transaction
Ti to the old values.
7 - 22 7. Recovery and Transaction
 Immediate Database Modification (Example)
• State of log and database
- A result of the execution T1 and T2, Note that the value of A is
changed in database before partially committed :
Log Database
<T1, start>
<T1, A , 1000, 900>
A = 900
<T1, B , 2000, 2100>
B = 2100 uncommitted update,
<T1, commit> if transaction is aborted,
<T2, start> new values must be recovered
<T1, C , 3000, 2800> old values.
C = 2800
<T2, commit>
7 - 23 7. Recovery and Transaction
 Immediate Database Modification (Example)
• Two Recovery Schemes :
(1) Undo(Ti) :
If the log contains the record <Ti, start > but does not contain
the record < Ti, commit >.
 This transaction is crashed during execution. Thus transaction Ti
needs to be undone.
(2) Redo(Ti) :
If the log contains both the record <Ti, start > and the record
< Ti, commit >.
 This transaction is crashed just after partially committed.
Thus transaction Ti needs to be undone.

7 - 24 7. Recovery and Transaction

 Immediate Database Modification (Example)
• Example of the System Crash before the Completion of the Transactions
<T1, start> <T1, start> <T1, start>
<T1, A , 1000, 900> <T1, A , 1000, 900> <T1, A , 1000, 900>
<T1, B , 2000, 2100> <T1, B , 2000, 2100> <T1, B , 2000, 2100>
<T1, commit> <T1, commit>
<T2, start> <T2, start>
<T1, C , 3000, 2800> <T1, C , 3000, 2800>
<T2, commit>
(a) (b) (c)

(a) Clash occurs just after write(B, b) :

- Recovery : Undo(T1), this means transaction T1 must be undone.
- A = 1000, B = 2000, C = 3000 remain in disk.
7 - 25 7. Recovery and Transaction
 Immediate Database Modification (Example)
(b) Clash occurs just after write(C, c) :
- Recovery : redo(T1) is performed since the record < T1, commit >
appears in the log. And undo(T2) .
- Result : A = 900, B = 2100 come backup.
* T2 transaction must be reexecuted.

(c) Clash occurs just after < T2 , commit> :

- Recovery : redo(T1) and redo(T2) is performed since the
record < T1, commit > and the record < T2, commit > appears
in the log.
- Result : A = 900, B = 2100, C = 2800 come backup.

7 - 26 7. Recovery and Transaction

 Checkpoints
• Neccessity
- When system failure occurs, it is necessary to determine at the
point of time for redo or undo action.
- The searching entire log is time-consuming.
- The system periodically performs checkpoints.
• Tasks in Checkpoint
(1) Output all log records currently residing in main memory
onto stable storage.
(2) Output all modified buffer block to the disk.
(3) Output a log record <checkpoint> onto stable storage.

7 - 27 7. Recovery and Transaction

 Checkpoints (cont'd)
• Recovery Method by Each Transaction Type
c (checkpoint) f (failure)
Time
T1
T2
T3
T4
Disk T5
Memory
• T1 : committed prior to the checkpoint.
• T2 : started prior to the checkpoint and committed prior to the f.
• T3 : started prior to the checkpoint but did not committed until f.
• T4 : started after checkpoint and committed prior to the f.
• T5 : started after checkpoint but did not committed until f.

7 - 28 7. Recovery and Transaction

 Checkpoints (cont'd)
• Recovery Procedure (immediate case)
T 1 : Already written on the disk at the checkpoint c
T 3 : Since failed on active state, T3 must execute undo operation

from c to f. Especially, part of prior c must be included the

undo operation.
 T5 : Undo operation
 T4 : Redo operation
 T2 : Especially, part of after c need to
execute redo operation
RULE :
1. < Ti, start > and < Ti, commit > : redo
2. < Ti, start > : undo
7 - 29
* written on disk checkpoint reside on memory
7. Recovery and Transaction
 Shadow Paging
• Two Types of Recovery Concepts
(1) In-place updating :
- Writes the data item in the same disk location,
thus overwriting the old value of the data item on disk.
- Single copy of each data item is maintained on disk.
- Log-based recovery
(2) shadowing :
- Write a new data item at a different disk location
- Multiple copies of a data item can be maintain.
- Shadow paging

7 - 30 7. Recovery and Transaction

 Shadow Paging (cont'd)
• Operation of Shadow Paging (See p. 380, Fig 18-16)
(1) Environment :
- Shadow paging considers the database to be made up of
a number of fixed-size disk pages.
- Page table (directory) points to the i-th database page on disk.
- All references (read or write) to database pages on disk
go through the page table.
(2) Operation :
a) Copy current page table into shadow page table and save
shadow page table on disk.
b) During transaction execution, a new copy of the modified
database page is created, but old page is not overwritten.

7 - 31 7. Recovery and Transaction

 Shadow Paging (cont'd)
c) New page is written on unused block. Current page table
entry is modified to point to the new disk block. But
shadow page table is not modified.
d) To recover from failure, it discard the current page table.
• Advantages :
- Not require the use of a log, thus no-undo/redo technique.
=> recovering is simple
• Disadvantages :
- It difficult to keep related database pages close together
on disk
- Overhead of writing shadow page tables to disk
- Garbage collection
- Not suitable multi-user environment
7 - 32 7. Recovery and Transaction
 Recovery of Disk
Until now, we have considered only the case where a failure results
in loss of information residing in volatile storage while the content
of the nonvolatile storage remains intact.

• To recover from the loss of nonvolatile storage :

(1) The database is restored to disk using the most recent dump.
(2) The log is consulted and all the transactions that have
committed since the last dump occurred are done.

7 - 33 7. Recovery and Transaction

 연습문제
1. DB 에서 회복 기능이 왜 필요한가 ?

2. 즉시 갱신 방법과 지연 갱신 방법의 차이점은 무엇인가 ?

3. 검사점 기법이란 ?

4. 디스크 붕괴가 일어났을 때 회복 절차를 설명하라 .

5. 그림자 페이징 기법과 로그 이용 회복 기법을 비교 설명하라 .

7 - 34 7. Recovery and Transaction