SlideShare a Scribd company logo

215-Database-Recovery presentation document

Download as PPT, PDF
••
A
AshokRachapalli1

ppt

Education
1 of 38
Download to read offline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
What is Concurrent Process (CP)? What is Concurrent Process (CP)? • Multiple users access databases and use computer systems Multiple users access databases and use computer systems simultaneously. simultaneously. • Example: Airline reservation system. Example: Airline reservation system. – An airline reservation system is used by hundreds of travel agents An airline reservation system is used by hundreds of travel agents and reservation clerks concurrently. and reservation clerks concurrently. Why Concurrent Process? Why Concurrent Process? • Better transaction throughput and response time Better transaction throughput and response time • Better utilization of resource Better utilization of resource Introduction Introduction
Transaction Transaction • What is Transaction? What is Transaction? • A sequence of many actions which are considered to be one A sequence of many actions which are considered to be one atomic unit of work. atomic unit of work. • Basic operations a transaction can include “actions”: Basic operations a transaction can include “actions”: – Reads, writes Reads, writes – Special actions: commit, abort Special actions: commit, abort • ACID properties of transaction ACID properties of transaction • A Atomicity tomicity: : Transaction is either performed in its entirety or not performed at all, Transaction is either performed in its entirety or not performed at all, this should be DBMS’ responsibility this should be DBMS’ responsibility • C Consistency onsistency: : Transaction must take the database from one consistent state to Transaction must take the database from one consistent state to another. It is user’s responsibility to insure consistency another. It is user’s responsibility to insure consistency • I Isolation solation: : Transaction should appear as though it is being executed in isolation from Transaction should appear as though it is being executed in isolation from other transactionss other transactionss • D Durability urability: : Changes applied to the database by a committed transaction must persist, Changes applied to the database by a committed transaction must persist, even if the system fail before all changes reflected on disk even if the system fail before all changes reflected on disk
Concurrent Transactions Concurrent Transactions interleaved processing parallel processing t1 t2 t1 t2 time CPU1 CPU2 A B A B CPU1
Schedules Schedules • What is Schedules What is Schedules – A schedule S of n transactions T1,T2,…Tn is an ordering of the operations of A schedule S of n transactions T1,T2,…Tn is an ordering of the operations of the transactions subject to the constraint that, for each transaction Ti that the transactions subject to the constraint that, for each transaction Ti that participates in S, the operations of Ti in S must appear in the same order in participates in S, the operations of Ti in S must appear in the same order in which they occur in Ti. which they occur in Ti. – Example: S Example: Sa a: r1(A),r2(A),w1(A),w2(A), a1,c2; : r1(A),r2(A),w1(A),w2(A), a1,c2; T1 T1 T2 T2 Read(A) Read(A) Write(A) Write(A) Abort T1 Abort T1 Read(A) Read(A) Write(A) Write(A) Commit T2 Commit T2
Oops, something’s wrong Oops, something’s wrong • Reserving a seat for a flight Reserving a seat for a flight • If concurrent access to data in DBMS, two users may try to book the same seat If concurrent access to data in DBMS, two users may try to book the same seat simultaneously simultaneously Agent 1 finds seat 35G empty Agent 2 finds seat 35G empty time Agent 1 sets seat 35G occupied Agent 2 sets seat 35G occupied
Another example Another example • Problems can occur when concurrent transactions execute in an uncontrolled Problems can occur when concurrent transactions execute in an uncontrolled manner. manner. • Examples of one problem. Examples of one problem. – A original equals to 100, after execute T1 and T2, A is supposed to be 100+10- A original equals to 100, after execute T1 and T2, A is supposed to be 100+10- 8=102 8=102 Add 10 To A Add 10 To A Minus 8 from A Minus 8 from A T1 T1 T2 T2 Read(A) Read(A) A=A+10 A=A+10 Write(A) Write(A) Read(A) Read(A) A=A-8 A=A-8 Write(A) Write(A) Value of A Value of A on the disk on the disk 100 100 100 100 100 100 100 100 110 110 92 92
What Can Go Wrong? What Can Go Wrong? • Concurrent process may end up violating Isolation property of Concurrent process may end up violating Isolation property of transaction if not carefully scheduled transaction if not carefully scheduled • Transaction may be aborted before committed Transaction may be aborted before committed - undo the uncommitted transactions - undo the uncommitted transactions - undo transactions that sees the uncommitted change before the crash - undo transactions that sees the uncommitted change before the crash
Conflict operations Conflict operations • Two operations in a schedule are said to be Two operations in a schedule are said to be conflict conflict if they satisfy if they satisfy all three of the following conditions: all three of the following conditions: (1) (1) They belong to different transactions They belong to different transactions (2) (2) They access the same item A; They access the same item A; (3) (3) at least one of the operations is a write(A) at least one of the operations is a write(A) Example in Sa: r1(A),r2(A),w1(A),w2(A), a1,c2; Example in Sa: r1(A),r2(A),w1(A),w2(A), a1,c2; – r1(A),w2(A) conflict, so do r2(A),w1(A), r1(A),w2(A) conflict, so do r2(A),w1(A), – r1(A), w1(A) do not conflict because they belong to the same r1(A), w1(A) do not conflict because they belong to the same transaction, transaction, – r1(A),r2(A) do not conflict because they are both read operations. r1(A),r2(A) do not conflict because they are both read operations.
Serializability of schedules Serializability of schedules • Serial Serial – A schedule S is A schedule S is serial serial if, for every transaction T participating in the schedule, all if, for every transaction T participating in the schedule, all the operations of T are executed consecutively in the schedule.( No interleaving the operations of T are executed consecutively in the schedule.( No interleaving occurs in a serial schedule) occurs in a serial schedule) • Serializable Serializable – A schedule S of n transactions is A schedule S of n transactions is serializable serializable if it is if it is equivalent equivalent to some to some serial serial schedule of the same n transactions. schedule of the same n transactions. • schedules are conflict equivalent if: schedules are conflict equivalent if: – they have the same sets of actions, and they have the same sets of actions, and – each pair of conflicting actions is ordered in the same way each pair of conflicting actions is ordered in the same way • schedules are conflict equivalent if: schedules are conflict equivalent if: – they have the same sets of actions, and they have the same sets of actions, and – each pair of conflicting actions is ordered in the same way each pair of conflicting actions is ordered in the same way • Conflict Serializable Conflict Serializable – A schedule is said to be conflict serializable if it is conflict equivalent to a serial A schedule is said to be conflict serializable if it is conflict equivalent to a serial schedule schedule
Characterizing Characterizing Schedules Schedules 1. Avoid cascading abort(ACA) 1. Avoid cascading abort(ACA) • Aborting T1 requires aborting T2! Aborting T1 requires aborting T2! – Cascading Abort Cascading Abort • An ACA (avoids cascading abort) An ACA (avoids cascading abort) – A X act only reads data from A X act only reads data from committed X acts. committed X acts. 2. 2. recoverable recoverable • Aborting T1 requires aborting T2! Aborting T1 requires aborting T2! – – But T2 has already committed! But T2 has already committed! • A recoverable schedule is one in A recoverable schedule is one in which this cannot happen. which this cannot happen. – – i.e. a X act commits only after all the i.e. a X act commits only after all the X acts it “depends on” (i.e. it reads X acts it “depends on” (i.e. it reads from) commit. from) commit. – – ACA implies recoverable (but not ACA implies recoverable (but not vice-versa!). vice-versa!). 3. strict schedule 3. strict schedule T1 T1 T2 T2 Read(A) Read(A) Write(A Write(A ) ) Abort Abort Read(A) Read(A) Write(A Write(A ) ) T1 T1 T2 T2 Read(A) Read(A) Write(A Write(A ) ) commit commit Read(A) Read(A) Write(A Write(A ) ) T1 T1 T2 T2 Read(A) Read(A) Write(A Write(A ) ) Abort Abort Read(A) Read(A) Write(A Write(A ) ) Commi Commi t t T1 T1 T2 T2 Read(A) Read(A) Write(A Write(A ) ) Commit Commit Read(A) Read(A) Write(A Write(A ) ) Commit Commit T1 T1 T2 T2 Read(A) Read(A) Write(A Write(A ) ) Commit Commit Read(A) Read(A) Write(A Write(A ) ) Commit Commit No No Yes Yes
Venn Diagram for Schedules Venn Diagram for Schedules Serial Strict ACA Recoverable View Serializable All Schedules Conflict Serializable
Example Example T1:W(X), T2:R(Y), T1:R(Y), T2:R(X), C2, C1 T1:W(X), T2:R(Y), T1:R(Y), T2:R(X), C2, C1 • serializable: Yes, equivalent to T1,T2 serializable: Yes, equivalent to T1,T2 • conflict-serializable: Yes, conflict- conflict-serializable: Yes, conflict- equivalent to T1,T2 equivalent to T1,T2 • recoverable: No. Yes, if C1 and C2 are recoverable: No. Yes, if C1 and C2 are switched. switched. • ACA: No. Yes, if T1 commits before T2 ACA: No. Yes, if T1 commits before T2 writes X. writes X.
Sample Transaction (informal) Sample Transaction (informal) • Example: Move $40 from checking to Example: Move $40 from checking to savings account savings account • To user, appears as one activity To user, appears as one activity • To database: To database: – Read balance of checking account: read( X) Read balance of checking account: read( X) – Read balance of savings account: read (Y) Read balance of savings account: read (Y) – Subtract $40 from X Subtract $40 from X – Add $40 to Y Add $40 to Y – Write new value of X back to disk Write new value of X back to disk – Write new value of Y back to disk Write new value of Y back to disk
Sample Transaction (Formal) Sample Transaction (Formal) T1 T1 read_item(X); read_item(X); read_item(Y); read_item(Y); X:=X-40; X:=X-40; Y:=Y+40; Y:=Y+40; write _item(X); write _item(X); write_item(Y); write_item(Y); t0 tk
Focus on concurrency control Focus on concurrency control • Real DBMS does not test for serializability Real DBMS does not test for serializability – Very inefficient since transactions are continuously Very inefficient since transactions are continuously arriving arriving – Would require a lot of undoing Would require a lot of undoing • Solution: concurrency protocols Solution: concurrency protocols • If followed by every transaction, and enforced If followed by every transaction, and enforced by transaction processing system, guarantee by transaction processing system, guarantee serializability of schedules serializability of schedules
Concurrency Control Through Concurrency Control Through Locks Locks • Lock: Lock: variable associated with each data variable associated with each data item item – Describes status of item wrt operations that can Describes status of item wrt operations that can be performed on it be performed on it • Binary locks: Locked/unlocked Binary locks: Locked/unlocked • Multiple-mode locks: Read/write Multiple-mode locks: Read/write • Three operations Three operations – read_lock(X) read_lock(X) – write_lock(X) write_lock(X) – unlock(X) unlock(X) • Each data item can be in one of three lock Each data item can be in one of three lock states states
Two Transactions Two Transactions T1 T1 read_lock(Y); read_lock(Y); read_item(Y); read_item(Y); unlock(Y); unlock(Y); write_lock(X); write_lock(X); read_item(X); read_item(X); X:=X+Y; X:=X+Y; write_item(X); write_item(X); unlock(X); unlock(X); T2 T2 read_lock(X); read_lock(X); read_item(X); read_item(X); unlock(X); unlock(X); write_lock(Y); write_lock(Y); read_item(Y); read_item(Y); Y:=X+Y; Y:=X+Y; write_item(Y); write_item(Y); unlock(Y); unlock(Y); Let’s assume serial schedule S1: T1;T2 Let’s assume serial schedule S1: T1;T2 Initial values: X=20, Y=30 Initial values: X=20, Y=30   Result: X=50, Y=80 Result: X=50, Y=80
Locks Alone Don’t Do the Locks Alone Don’t Do the Trick! Trick! T1 T1 read_lock(Y); read_lock(Y); read_item(Y); read_item(Y); unlock(Y); unlock(Y); write_lock(X); write_lock(X); read_item(X); read_item(X); X:=X+Y; X:=X+Y; write_item(X); write_item(X); unlock(X); unlock(X); T2 T2 read_lock(X); read_lock(X); read_item(X); read_item(X); unlock(X); unlock(X); write_lock(Y); write_lock(Y); read_item(Y); read_item(Y); Y:=X+Y; Y:=X+Y; write_item(Y); write_item(Y); unlock(Y); unlock(Y); Non-serializable! Non-serializable! Result: X=50, Y=50 Result: X=50, Y=50 unlocked too early! Let’s run T1 and T2 in interleafed fashion Let’s run T1 and T2 in interleafed fashion Schedule S
Two-Phase Locking (2PL) Two-Phase Locking (2PL) • Def.: Transaction is said to follow the Def.: Transaction is said to follow the two-phase-locking protocol two-phase-locking protocol if all if all locking operations precede the locking operations precede the first first unlock operation unlock operation
Example Example T1’ T1’ read_lock(Y); read_lock(Y); read_item(Y); read_item(Y); write_lock(X); write_lock(X); unlock(Y); unlock(Y); read_item(X); read_item(X); X:=X+Y; X:=X+Y; write_item(X); write_item(X); unlock(X); unlock(X); T2’ T2’ read_lock(X); read_lock(X); read_item(X); read_item(X); write_lock(Y); write_lock(Y); unlock(X); unlock(X); read_item(Y); read_item(Y); Y:=X+Y; Y:=X+Y; write_item(Y); write_item(Y); unlock(Y); unlock(Y); • Both T1’ and T2’ follow the 2PL protocol Both T1’ and T2’ follow the 2PL protocol • Any schedule including T1’ and T2’ is guaranteed to be serializable Any schedule including T1’ and T2’ is guaranteed to be serializable • Limits the amount of concurrency Limits the amount of concurrency
Variations to the Basic Variations to the Basic Protocol Protocol • Previous technique knows as Previous technique knows as basic 2PL basic 2PL • Conservative Conservative 2PL (static) 2PL: Lock all 2PL (static) 2PL: Lock all items needed BEFORE execution items needed BEFORE execution begins by predeclaring its read and begins by predeclaring its read and write set write set – If any of the items in read or write set is If any of the items in read or write set is already locked (by other transactions), already locked (by other transactions), transaction waits (does not acquire any transaction waits (does not acquire any locks) locks) – Deadlock free but not very realistic Deadlock free but not very realistic
Variations to the Basic Variations to the Basic Protocol Protocol • Strict Strict 2PL: Transaction does not 2PL: Transaction does not release its write locks until AFTER it release its write locks until AFTER it aborts/commits aborts/commits – Not deadlock free but guarantees Not deadlock free but guarantees recoverable schedules (strict schedule: recoverable schedules (strict schedule: transaction can neither read/write X transaction can neither read/write X until last transaction that wrote X has until last transaction that wrote X has committed/aborted) committed/aborted) – Most popular variation of 2PL Most popular variation of 2PL
Concluding Remarks Concluding Remarks • Concurrency control subsystem is responsible Concurrency control subsystem is responsible for inserting locks at right places into your for inserting locks at right places into your transaction transaction – Strict 2PL is widely used Strict 2PL is widely used – Requires use of waiting queue Requires use of waiting queue • All 2PL locking protocols guarantee All 2PL locking protocols guarantee serializability serializability • Does not permit all possible serial schedules Does not permit all possible serial schedules
Why “Database Recovery Techniques”? Why “Database Recovery Techniques”? • A ACI CID D properties of Transaction properties of Transaction Time T1 T2 T3 Crash Database system should guarantee Database system should guarantee - D Durability : Applied changes by transactions urability : Applied changes by transactions must not be lost. ~ T3 must not be lost. ~ T3 - A Atomicity : Transactions can be aborted. tomicity : Transactions can be aborted. ~ T1, T2 ~ T1, T2 System crash Transaction error System error Local error Disk failure Catastrophe
Basic Idea : “Logging” Basic Idea : “Logging” • Undo/Redo by the Log Undo/Redo by the Log   recover Non-catastrophic failure recover Non-catastrophic failure Time T1 T2 T3 Crash System Log System Log - keeps info of changes - keeps info of changes applied by transactions applied by transactions Checkpoint Backup • Full DB Backup Full DB Backup > Differential Backup > Differential Backup > > (Transaction) Log (Transaction) Log Catastrophic failure Catastrophic failure
Physical View Physical View - How they work - - How they work - (1) (1) Action : Action : 1) 1) Check Check the directory the directory whether whether in the cache in the cache 2) If none, copy from 2) If none, copy from disk pages disk pages to to the cache the cache Disk Memory DBMS cache (buffers) Disk pages/blocks (address:A,a,1) (address:B,b,0) A B a b Director y copy flush 3) For the copy, old buffers needs to be 3) For the copy, old buffers needs to be flushed flushed from from the cache the cache to to the disk pages the disk pages B’
Physical View Physical View - How they work - - How they work - (2) (2) Disk Memory DBMS cache (buffers) Disk pages/blocks (address:A,a,1) (address:B,b,0) A B a b Director y copy flush 4) Flush only if 4) Flush only if a dirty bit a dirty bit is 1 is 1 Dirty bit : (in the directory) whether there is Dirty bit : (in the directory) whether there is a change after copy to the cache a change after copy to the cache 1 – updated in the cache 1 – updated in the cache 0 – not updated in the cache (no need to flush) 0 – not updated in the cache (no need to flush) updat e B’
Physical View Physical View - How they work - - How they work - (3) (3) Disk Memory DBMS cache (buffers) Disk pages/blocks A B a b copy flush A-a : A-a : “in-place updating” “in-place updating” - when flushing, overwrite at the same - when flushing, overwrite at the same location location - - logging logging is required is required B-b : B-b : “shadowing” “shadowing” B’
Physical View Physical View - How they work - - How they work - (4) (4) Disk Memory DBMS cache Data blocks B b (1) copy (from the disk to the cache) (2) update the cached data, record it in the log (3) flush the log and the data (from the cache to the disk) copy flush Log blocks update B’ Log blocks Data blocks update
WAL : Write-Ahead Logging (1) WAL : Write-Ahead Logging (1) • in-place updating in-place updating   A log A log is necessary is necessary BFIM (BeFore IMage) BFIM (BeFore IMage) – overwrite – – overwrite – AFIM (AFter) AFIM (AFter) Disk Memory DBMS cache Data blocks copy 2) flush Log blocks update Log blocks Data blocks update A a BFIM BFIM AFIM BFIM • WAL (Write-Ahead Logging) WAL (Write-Ahead Logging) Log entries flushed Log entries flushed before overwriting before overwriting main data main data 1) flush UNDO-type log record
WAL : Write-Ahead Logging (2) WAL : Write-Ahead Logging (2) • WAL protocol requires WAL protocol requires UNDO UNDO and and REDO REDO Time T commit Log Log - BFIM cannot be overwritten by AFIM on disk BFIM cannot be overwritten by AFIM on disk until all until all UNDO-type log UNDO-type log have force-written to disk. have force-written to disk. - The commit operation cannot be completed The commit operation cannot be completed until all until all UNDO/REDO-type log UNDO/REDO-type log have force-written. have force-written. UNDO REDO
Steal & No-Force (1) Steal & No-Force (1) • Typical DB Typical DB employs employs a a steal/no-force steal/no-force strategy strategy Time T1 T2 T3 commit commit cache Updated data by T2 cache Can be Used for other transactions (T3) before T2 commits • Steal Steal strategy : a transaction strategy : a transaction can can be written to disk be written to disk before it commits before it commits Advantage : Advantage : buffer space saving buffer space saving
Steal & No-Force (2) Steal & No-Force (2) Time T1 T2 T3 commit commit cache Updated data by T2 cache If T3 needs the same data, it must be copied again when T2 commits • No-Force No-Force strategy : a transaction strategy : a transaction need not need not to be to be written to disk written to disk immediately immediately when it commits when it commits Advantage : Advantage : I/O operations saving I/O operations saving   Force strategy Force strategy
Checkpointing Checkpointing • Checkpoint Checkpoint - All DMBS buffers modified are wrote out to disk. - All DMBS buffers modified are wrote out to disk. - A record is written into the log. ( - A record is written into the log. ([checkpoint] [checkpoint]) ) - Periodically done - Periodically done (e.g. every n min. or every n transaction (e.g. every n min. or every n transaction Time T1 T2 T3 Crash Checkpoint
Transaction Rollback (1) Transaction Rollback (1) • Rollback / Roll foward Rollback / Roll foward Time T1 T2 T3 Crash T4 T5 1 : Not necesary 2 : Roll foward 3 : Rollback 4 : Roll forward 5 : Roll back Checkpoint - Steal : transaction may be written on disk Steal : transaction may be written on disk before it commits before it commits Recovery method
• example : example : Nam Nam e e Accoun Accoun t t Mr.A Mr.A $10 $10 Mr.B Mr.B $2,000 $2,000 Mr.C Mr.C $30,00 $30,00 0 0 Transaction Rollback (2) Transaction Rollback (2) Time T2 Checkpoint Crash T1 : A company pays salary to employees i) transfer $2,000 to Mr. A’s account ii) transfer $2,500 to Mr B’s account … write(A) read(A) T1 read(B) read(A) write(B) write(C) read(C) write(A) T2 : Mr.A pays the monthly rent. i) withdraw $1,500 from Mr.A’s account ii) transfer $1,500 to Mr.C’s account
• Cascading Rollback Cascading Rollback Transaction Rollback (3) Transaction Rollback (3) System Log System Log [checkpoint] [checkpoint] [start_transaction, T1] [start_transaction, T1] [read_item, T1, A] [read_item, T1, A] [write_item, T1, A, 10, 2010] [write_item, T1, A, 10, 2010] [start_transaction, T2] [start_transaction, T2] [read_item, T2, A] [read_item, T2, A] [write_item, T2, A, 2010, 510] [write_item, T2, A, 2010, 510] [read_item, T1, B] [read_item, T1, B] [read_item, T2, C] [read_item, T2, C] [write_item, T2, C, 1500, 31500] [write_item, T2, C, 1500, 31500] ~~~ CRASH ~~~~ ~~~ CRASH ~~~~ T2 Checkpoint Crash w(A) r(A) T1 r (B) r(A) w(C) r(C) w(A) A A $10 $10 $10 $10 $2,010 $2,010 $2,010 $2,010 $510 $510 C C $30,000 $30,000 $30,000 $30,000 $31,500 $31,500 -T1 is interrupted (needs rollback) -T2 uses value modified by T1 (also needs rollback)
Categorization of Recovery Algorithm Categorization of Recovery Algorithm • Deferred update – the No-UNDO/REDO algorithm Deferred update – the No-UNDO/REDO algorithm • Immediate update – the UNDO/REDO algorithm Immediate update – the UNDO/REDO algorithm

More Related Content

PPT
DBMS UNIT 5 46 CONTAINS NOTES FOR THE STUDENTS
SnehalVinod
 
PPT
transaction_processing.ppt
NikhilKumarAgarwalK
 
PPTX
Transactions
Ketaki_Pattani
 
PDF
Advance_DBMS-Lecture_notesssssssssssssssss.pdf
ssuser0c24d5
 
PPTX
Unit 5 Transcationrelationaldatabases.pptx
artipunia12
 
PPT
Concurrent Transactions.ppt
Karthick Panneerselvam
 
PPTX
Chapter-10 Transaction Processing and Error Recovery
Kunal Anand
 
PPTX
DBMS_Unit-4 data bas management (1).pptx
cherukuriyuvaraju9
 
DBMS UNIT 5 46 CONTAINS NOTES FOR THE STUDENTS
SnehalVinod
 
transaction_processing.ppt
NikhilKumarAgarwalK
 
Transactions
Ketaki_Pattani
 
Advance_DBMS-Lecture_notesssssssssssssssss.pdf
ssuser0c24d5
 
Unit 5 Transcationrelationaldatabases.pptx
artipunia12
 
Concurrent Transactions.ppt
Karthick Panneerselvam
 
Chapter-10 Transaction Processing and Error Recovery
Kunal Anand
 
DBMS_Unit-4 data bas management (1).pptx
cherukuriyuvaraju9
 

Similar to 215-Database-Recovery presentation document (20)

PDF
Unit 5 - PPT.pdf DBMS SRM university chennai
PriyanshuJha69
 
PPTX
Question answer
vishal choudhary
 
PPT
Ch15 3717
Kumbala Sushanth Cool
 
PPT
Ch15 3717
Vinoth Kumar
 
PPT
15. Transactions in DBMS
koolkampus
 
PDF
DBMS 4.pdf
NithishReddy90
 
PPTX
TRANSACTION MANAGEMENT PROCESSING DBMS(5)
Karthik Rohan
 
PPTX
10497_31714437622.pptxbsznsnznsnznxbxxbbdnxn
YogeshChauhan661032
 
PPT
concurrencycontrol_databasemanagement_system
DeepaliKonety
 
PPTX
Unit 4 dbms
Sweta Singh
 
PPT
Transaction management
renuka_a
 
PPT
Transaction unit1 topic 2
avniS
 
PPT
Chapter17
gourab87
 
DOCX
UNIT-IV: Transaction Processing Concepts
Raj vardhan
 
PPT
24904 lecture11
Universitas Bina Darma Palembang
 
PPT
20.SCHEDULES.ppt
AkhilNameirakpam
 
PPTX
Transaction and serializability
Yogita Jain
 
PPTX
Transaction of program execution updates
kumari36
 
PPTX
7. CSEN3101-MIV-TransactionProcessing-SolvedProblems-06.11.2023.pptx
quantumiq448
 
PPTX
UNIT-4-Transactionstates and processing ppt.pptx
Uma Kakarlapudi
 
Unit 5 - PPT.pdf DBMS SRM university chennai
PriyanshuJha69
 
Question answer
vishal choudhary
 
Ch15 3717
Kumbala Sushanth Cool
 
Ch15 3717
Vinoth Kumar
 
15. Transactions in DBMS
koolkampus
 
DBMS 4.pdf
NithishReddy90
 
TRANSACTION MANAGEMENT PROCESSING DBMS(5)
Karthik Rohan
 
10497_31714437622.pptxbsznsnznsnznxbxxbbdnxn
YogeshChauhan661032
 
concurrencycontrol_databasemanagement_system
DeepaliKonety
 
Unit 4 dbms
Sweta Singh
 
Transaction management
renuka_a
 
Transaction unit1 topic 2
avniS
 
Chapter17
gourab87
 
UNIT-IV: Transaction Processing Concepts
Raj vardhan
 
24904 lecture11
Universitas Bina Darma Palembang
 
20.SCHEDULES.ppt
AkhilNameirakpam
 
Transaction and serializability
Yogita Jain
 
Transaction of program execution updates
kumari36
 
7. CSEN3101-MIV-TransactionProcessing-SolvedProblems-06.11.2023.pptx
quantumiq448
 
UNIT-4-Transactionstates and processing ppt.pptx
Uma Kakarlapudi
 
Ad

More from AshokRachapalli1 (20)

PPTX
transactionprocessing-220423112118 (1).pptx
AshokRachapalli1
 
PPTX
unit-1 lecture 7 Types of system calls.pptx
AshokRachapalli1
 
PPTX
DATA MODEL Power point presentation for dbms
AshokRachapalli1
 
PPTX
WEEK-2 DML and operators power point presentation
AshokRachapalli1
 
PPTX
Relational Algebra in DBMS 2025 power point
AshokRachapalli1
 
PPTX
CLOSURE OF AN ATTRIBUTE powerpontpresentatio
AshokRachapalli1
 
PPT
Relational algebra in database management system
AshokRachapalli1
 
PPT
DBMS-3.1 Normalization upto boyscodd normal form
AshokRachapalli1
 
PPTX
Data base Users and Administrator pptx
AshokRachapalli1
 
PPTX
Database Languages power point presentation
AshokRachapalli1
 
PPTX
Relational Algebra in DBMS power ppoint pesenetation
AshokRachapalli1
 
PPTX
using Java Exception Handling in Java.pptx
AshokRachapalli1
 
PPTX
Multi-Threading in Java power point presenetation
AshokRachapalli1
 
PPT
ARRAYS in java with in details presentation.ppt
AshokRachapalli1
 
PPT
lecture-a-java-review .. this review ppt will help to the lectureres
AshokRachapalli1
 
PPTX
17.INTRODUCTION TO SCHEMA REFINEMENT.pptx
AshokRachapalli1
 
PPTX
joins in dbms its describes about how joins are important and necessity in d...
AshokRachapalli1
 
PPTX
6.Database Languages lab-1.pptx
AshokRachapalli1
 
PPT
Chapter5 (1).ppt
AshokRachapalli1
 
PPTX
Cache Memory.pptx
AshokRachapalli1
 
transactionprocessing-220423112118 (1).pptx
AshokRachapalli1
 
unit-1 lecture 7 Types of system calls.pptx
AshokRachapalli1
 
DATA MODEL Power point presentation for dbms
AshokRachapalli1
 
WEEK-2 DML and operators power point presentation
AshokRachapalli1
 
Relational Algebra in DBMS 2025 power point
AshokRachapalli1
 
CLOSURE OF AN ATTRIBUTE powerpontpresentatio
AshokRachapalli1
 
Relational algebra in database management system
AshokRachapalli1
 
DBMS-3.1 Normalization upto boyscodd normal form
AshokRachapalli1
 
Data base Users and Administrator pptx
AshokRachapalli1
 
Database Languages power point presentation
AshokRachapalli1
 
Relational Algebra in DBMS power ppoint pesenetation
AshokRachapalli1
 
using Java Exception Handling in Java.pptx
AshokRachapalli1
 
Multi-Threading in Java power point presenetation
AshokRachapalli1
 
ARRAYS in java with in details presentation.ppt
AshokRachapalli1
 
lecture-a-java-review .. this review ppt will help to the lectureres
AshokRachapalli1
 
17.INTRODUCTION TO SCHEMA REFINEMENT.pptx
AshokRachapalli1
 
joins in dbms its describes about how joins are important and necessity in d...
AshokRachapalli1
 
6.Database Languages lab-1.pptx
AshokRachapalli1
 
Chapter5 (1).ppt
AshokRachapalli1
 
Cache Memory.pptx
AshokRachapalli1
 
Ad

Recently uploaded (20)

PPTX
Applications of matrices In Real Life_20250724_091307_0000.pptx
gehlotkrish03
 
PPTX
How to Apply for a Job From Odoo 18 Website
Celine George
 
PDF
Virat Kohli- the Pride of Indian cricket
kushpar147
 
PPTX
Measures_of_location_-_Averages_and__percentiles_by_DR SURYA K.pptx
Surya Ganesh
 
DOCX
Modul Ajar Deep Learning Bahasa Inggris Kelas 11 Terbaru 2025
wahyurestu63
 
PDF
The-Invisible-Living-World-Beyond-Our-Naked-Eye chapter 2.pdf/8th science cur...
Sandeep Swamy
 
PPTX
An introduction to Prepositions for beginners.pptx
drsiddhantnagine
 
PDF
BÀI TẬP TEST BỔ TRỢ THEO TỪNG CHỦ ĐỀ CỦA TỪNG UNIT KÈM BÀI TẬP NGHE - TIẾNG A...
Nguyen Thanh Tu Collection
 
PPTX
INTESTINALPARASITES OR WORM INFESTATIONS.pptx
PRADEEP ABOTHU
 
PPTX
CARE OF UNCONSCIOUS PATIENTS .pptx
AneetaSharma15
 
PPTX
Dakar Framework Education For All- 2000(Act)
santoshmohalik1
 
PPTX
Artificial Intelligence in Gastroentrology: Advancements and Future Presprec...
AyanHossain
 
PPTX
A Smarter Way to Think About Choosing a College
Cyndy McDonald
 
PPTX
Introduction to pediatric nursing in 5th Sem..pptx
AneetaSharma15
 
PPTX
CONCEPT OF CHILD CARE. pptx
AneetaSharma15
 
PDF
The Minister of Tourism, Culture and Creative Arts, Abla Dzifa Gomashie has e...
nservice241
 
DOCX
Action Plan_ARAL PROGRAM_ STAND ALONE SHS.docx
Levenmartlacuna1
 
DOCX
SAROCES Action-Plan FOR ARAL PROGRAM IN DEPED
Levenmartlacuna1
 
PPTX
Tips Management in Odoo 18 POS - Odoo Slides
Celine George
 
PDF
What is CFA?? Complete Guide to the Chartered Financial Analyst Program
sp4989653
 
Applications of matrices In Real Life_20250724_091307_0000.pptx
gehlotkrish03
 
How to Apply for a Job From Odoo 18 Website
Celine George
 
Virat Kohli- the Pride of Indian cricket
kushpar147
 
Measures_of_location_-_Averages_and__percentiles_by_DR SURYA K.pptx
Surya Ganesh
 
Modul Ajar Deep Learning Bahasa Inggris Kelas 11 Terbaru 2025
wahyurestu63
 
The-Invisible-Living-World-Beyond-Our-Naked-Eye chapter 2.pdf/8th science cur...
Sandeep Swamy
 
An introduction to Prepositions for beginners.pptx
drsiddhantnagine
 
BÀI TẬP TEST BỔ TRỢ THEO TỪNG CHỦ ĐỀ CỦA TỪNG UNIT KÈM BÀI TẬP NGHE - TIẾNG A...
Nguyen Thanh Tu Collection
 
INTESTINALPARASITES OR WORM INFESTATIONS.pptx
PRADEEP ABOTHU
 
CARE OF UNCONSCIOUS PATIENTS .pptx
AneetaSharma15
 
Dakar Framework Education For All- 2000(Act)
santoshmohalik1
 
Artificial Intelligence in Gastroentrology: Advancements and Future Presprec...
AyanHossain
 
A Smarter Way to Think About Choosing a College
Cyndy McDonald
 
Introduction to pediatric nursing in 5th Sem..pptx
AneetaSharma15
 
CONCEPT OF CHILD CARE. pptx
AneetaSharma15
 
The Minister of Tourism, Culture and Creative Arts, Abla Dzifa Gomashie has e...
nservice241
 
Action Plan_ARAL PROGRAM_ STAND ALONE SHS.docx
Levenmartlacuna1
 
SAROCES Action-Plan FOR ARAL PROGRAM IN DEPED
Levenmartlacuna1
 
Tips Management in Odoo 18 POS - Odoo Slides
Celine George
 
What is CFA?? Complete Guide to the Chartered Financial Analyst Program
sp4989653
 

215-Database-Recovery presentation document

  • 1. What is Concurrent Process (CP)? What is Concurrent Process (CP)? • Multiple users access databases and use computer systems Multiple users access databases and use computer systems simultaneously. simultaneously. • Example: Airline reservation system. Example: Airline reservation system. – An airline reservation system is used by hundreds of travel agents An airline reservation system is used by hundreds of travel agents and reservation clerks concurrently. and reservation clerks concurrently. Why Concurrent Process? Why Concurrent Process? • Better transaction throughput and response time Better transaction throughput and response time • Better utilization of resource Better utilization of resource Introduction Introduction
  • 2. Transaction Transaction • What is Transaction? What is Transaction? • A sequence of many actions which are considered to be one A sequence of many actions which are considered to be one atomic unit of work. atomic unit of work. • Basic operations a transaction can include “actions”: Basic operations a transaction can include “actions”: – Reads, writes Reads, writes – Special actions: commit, abort Special actions: commit, abort • ACID properties of transaction ACID properties of transaction • A Atomicity tomicity: : Transaction is either performed in its entirety or not performed at all, Transaction is either performed in its entirety or not performed at all, this should be DBMS’ responsibility this should be DBMS’ responsibility • C Consistency onsistency: : Transaction must take the database from one consistent state to Transaction must take the database from one consistent state to another. It is user’s responsibility to insure consistency another. It is user’s responsibility to insure consistency • I Isolation solation: : Transaction should appear as though it is being executed in isolation from Transaction should appear as though it is being executed in isolation from other transactionss other transactionss • D Durability urability: : Changes applied to the database by a committed transaction must persist, Changes applied to the database by a committed transaction must persist, even if the system fail before all changes reflected on disk even if the system fail before all changes reflected on disk
  • 3. Concurrent Transactions Concurrent Transactions interleaved processing parallel processing t1 t2 t1 t2 time CPU1 CPU2 A B A B CPU1
  • 4. Schedules Schedules • What is Schedules What is Schedules – A schedule S of n transactions T1,T2,…Tn is an ordering of the operations of A schedule S of n transactions T1,T2,…Tn is an ordering of the operations of the transactions subject to the constraint that, for each transaction Ti that the transactions subject to the constraint that, for each transaction Ti that participates in S, the operations of Ti in S must appear in the same order in participates in S, the operations of Ti in S must appear in the same order in which they occur in Ti. which they occur in Ti. – Example: S Example: Sa a: r1(A),r2(A),w1(A),w2(A), a1,c2; : r1(A),r2(A),w1(A),w2(A), a1,c2; T1 T1 T2 T2 Read(A) Read(A) Write(A) Write(A) Abort T1 Abort T1 Read(A) Read(A) Write(A) Write(A) Commit T2 Commit T2
  • 5. Oops, something’s wrong Oops, something’s wrong • Reserving a seat for a flight Reserving a seat for a flight • If concurrent access to data in DBMS, two users may try to book the same seat If concurrent access to data in DBMS, two users may try to book the same seat simultaneously simultaneously Agent 1 finds seat 35G empty Agent 2 finds seat 35G empty time Agent 1 sets seat 35G occupied Agent 2 sets seat 35G occupied
  • 6. Another example Another example • Problems can occur when concurrent transactions execute in an uncontrolled Problems can occur when concurrent transactions execute in an uncontrolled manner. manner. • Examples of one problem. Examples of one problem. – A original equals to 100, after execute T1 and T2, A is supposed to be 100+10- A original equals to 100, after execute T1 and T2, A is supposed to be 100+10- 8=102 8=102 Add 10 To A Add 10 To A Minus 8 from A Minus 8 from A T1 T1 T2 T2 Read(A) Read(A) A=A+10 A=A+10 Write(A) Write(A) Read(A) Read(A) A=A-8 A=A-8 Write(A) Write(A) Value of A Value of A on the disk on the disk 100 100 100 100 100 100 100 100 110 110 92 92
  • 7. What Can Go Wrong? What Can Go Wrong? • Concurrent process may end up violating Isolation property of Concurrent process may end up violating Isolation property of transaction if not carefully scheduled transaction if not carefully scheduled • Transaction may be aborted before committed Transaction may be aborted before committed - undo the uncommitted transactions - undo the uncommitted transactions - undo transactions that sees the uncommitted change before the crash - undo transactions that sees the uncommitted change before the crash
  • 8. Conflict operations Conflict operations • Two operations in a schedule are said to be Two operations in a schedule are said to be conflict conflict if they satisfy if they satisfy all three of the following conditions: all three of the following conditions: (1) (1) They belong to different transactions They belong to different transactions (2) (2) They access the same item A; They access the same item A; (3) (3) at least one of the operations is a write(A) at least one of the operations is a write(A) Example in Sa: r1(A),r2(A),w1(A),w2(A), a1,c2; Example in Sa: r1(A),r2(A),w1(A),w2(A), a1,c2; – r1(A),w2(A) conflict, so do r2(A),w1(A), r1(A),w2(A) conflict, so do r2(A),w1(A), – r1(A), w1(A) do not conflict because they belong to the same r1(A), w1(A) do not conflict because they belong to the same transaction, transaction, – r1(A),r2(A) do not conflict because they are both read operations. r1(A),r2(A) do not conflict because they are both read operations.
  • 9. Serializability of schedules Serializability of schedules • Serial Serial – A schedule S is A schedule S is serial serial if, for every transaction T participating in the schedule, all if, for every transaction T participating in the schedule, all the operations of T are executed consecutively in the schedule.( No interleaving the operations of T are executed consecutively in the schedule.( No interleaving occurs in a serial schedule) occurs in a serial schedule) • Serializable Serializable – A schedule S of n transactions is A schedule S of n transactions is serializable serializable if it is if it is equivalent equivalent to some to some serial serial schedule of the same n transactions. schedule of the same n transactions. • schedules are conflict equivalent if: schedules are conflict equivalent if: – they have the same sets of actions, and they have the same sets of actions, and – each pair of conflicting actions is ordered in the same way each pair of conflicting actions is ordered in the same way • schedules are conflict equivalent if: schedules are conflict equivalent if: – they have the same sets of actions, and they have the same sets of actions, and – each pair of conflicting actions is ordered in the same way each pair of conflicting actions is ordered in the same way • Conflict Serializable Conflict Serializable – A schedule is said to be conflict serializable if it is conflict equivalent to a serial A schedule is said to be conflict serializable if it is conflict equivalent to a serial schedule schedule
  • 10. Characterizing Characterizing Schedules Schedules 1. Avoid cascading abort(ACA) 1. Avoid cascading abort(ACA) • Aborting T1 requires aborting T2! Aborting T1 requires aborting T2! – Cascading Abort Cascading Abort • An ACA (avoids cascading abort) An ACA (avoids cascading abort) – A X act only reads data from A X act only reads data from committed X acts. committed X acts. 2. 2. recoverable recoverable • Aborting T1 requires aborting T2! Aborting T1 requires aborting T2! – – But T2 has already committed! But T2 has already committed! • A recoverable schedule is one in A recoverable schedule is one in which this cannot happen. which this cannot happen. – – i.e. a X act commits only after all the i.e. a X act commits only after all the X acts it “depends on” (i.e. it reads X acts it “depends on” (i.e. it reads from) commit. from) commit. – – ACA implies recoverable (but not ACA implies recoverable (but not vice-versa!). vice-versa!). 3. strict schedule 3. strict schedule T1 T1 T2 T2 Read(A) Read(A) Write(A Write(A ) ) Abort Abort Read(A) Read(A) Write(A Write(A ) ) T1 T1 T2 T2 Read(A) Read(A) Write(A Write(A ) ) commit commit Read(A) Read(A) Write(A Write(A ) ) T1 T1 T2 T2 Read(A) Read(A) Write(A Write(A ) ) Abort Abort Read(A) Read(A) Write(A Write(A ) ) Commi Commi t t T1 T1 T2 T2 Read(A) Read(A) Write(A Write(A ) ) Commit Commit Read(A) Read(A) Write(A Write(A ) ) Commit Commit T1 T1 T2 T2 Read(A) Read(A) Write(A Write(A ) ) Commit Commit Read(A) Read(A) Write(A Write(A ) ) Commit Commit No No Yes Yes
  • 11. Venn Diagram for Schedules Venn Diagram for Schedules Serial Strict ACA Recoverable View Serializable All Schedules Conflict Serializable
  • 12. Example Example T1:W(X), T2:R(Y), T1:R(Y), T2:R(X), C2, C1 T1:W(X), T2:R(Y), T1:R(Y), T2:R(X), C2, C1 • serializable: Yes, equivalent to T1,T2 serializable: Yes, equivalent to T1,T2 • conflict-serializable: Yes, conflict- conflict-serializable: Yes, conflict- equivalent to T1,T2 equivalent to T1,T2 • recoverable: No. Yes, if C1 and C2 are recoverable: No. Yes, if C1 and C2 are switched. switched. • ACA: No. Yes, if T1 commits before T2 ACA: No. Yes, if T1 commits before T2 writes X. writes X.
  • 13. Sample Transaction (informal) Sample Transaction (informal) • Example: Move $40 from checking to Example: Move $40 from checking to savings account savings account • To user, appears as one activity To user, appears as one activity • To database: To database: – Read balance of checking account: read( X) Read balance of checking account: read( X) – Read balance of savings account: read (Y) Read balance of savings account: read (Y) – Subtract $40 from X Subtract $40 from X – Add $40 to Y Add $40 to Y – Write new value of X back to disk Write new value of X back to disk – Write new value of Y back to disk Write new value of Y back to disk
  • 14. Sample Transaction (Formal) Sample Transaction (Formal) T1 T1 read_item(X); read_item(X); read_item(Y); read_item(Y); X:=X-40; X:=X-40; Y:=Y+40; Y:=Y+40; write _item(X); write _item(X); write_item(Y); write_item(Y); t0 tk
  • 15. Focus on concurrency control Focus on concurrency control • Real DBMS does not test for serializability Real DBMS does not test for serializability – Very inefficient since transactions are continuously Very inefficient since transactions are continuously arriving arriving – Would require a lot of undoing Would require a lot of undoing • Solution: concurrency protocols Solution: concurrency protocols • If followed by every transaction, and enforced If followed by every transaction, and enforced by transaction processing system, guarantee by transaction processing system, guarantee serializability of schedules serializability of schedules
  • 16. Concurrency Control Through Concurrency Control Through Locks Locks • Lock: Lock: variable associated with each data variable associated with each data item item – Describes status of item wrt operations that can Describes status of item wrt operations that can be performed on it be performed on it • Binary locks: Locked/unlocked Binary locks: Locked/unlocked • Multiple-mode locks: Read/write Multiple-mode locks: Read/write • Three operations Three operations – read_lock(X) read_lock(X) – write_lock(X) write_lock(X) – unlock(X) unlock(X) • Each data item can be in one of three lock Each data item can be in one of three lock states states
  • 18. Locks Alone Don’t Do the Locks Alone Don’t Do the Trick! Trick! T1 T1 read_lock(Y); read_lock(Y); read_item(Y); read_item(Y); unlock(Y); unlock(Y); write_lock(X); write_lock(X); read_item(X); read_item(X); X:=X+Y; X:=X+Y; write_item(X); write_item(X); unlock(X); unlock(X); T2 T2 read_lock(X); read_lock(X); read_item(X); read_item(X); unlock(X); unlock(X); write_lock(Y); write_lock(Y); read_item(Y); read_item(Y); Y:=X+Y; Y:=X+Y; write_item(Y); write_item(Y); unlock(Y); unlock(Y); Non-serializable! Non-serializable! Result: X=50, Y=50 Result: X=50, Y=50 unlocked too early! Let’s run T1 and T2 in interleafed fashion Let’s run T1 and T2 in interleafed fashion Schedule S
  • 19. Two-Phase Locking (2PL) Two-Phase Locking (2PL) • Def.: Transaction is said to follow the Def.: Transaction is said to follow the two-phase-locking protocol two-phase-locking protocol if all if all locking operations precede the locking operations precede the first first unlock operation unlock operation
  • 21. Variations to the Basic Variations to the Basic Protocol Protocol • Previous technique knows as Previous technique knows as basic 2PL basic 2PL • Conservative Conservative 2PL (static) 2PL: Lock all 2PL (static) 2PL: Lock all items needed BEFORE execution items needed BEFORE execution begins by predeclaring its read and begins by predeclaring its read and write set write set – If any of the items in read or write set is If any of the items in read or write set is already locked (by other transactions), already locked (by other transactions), transaction waits (does not acquire any transaction waits (does not acquire any locks) locks) – Deadlock free but not very realistic Deadlock free but not very realistic
  • 22. Variations to the Basic Variations to the Basic Protocol Protocol • Strict Strict 2PL: Transaction does not 2PL: Transaction does not release its write locks until AFTER it release its write locks until AFTER it aborts/commits aborts/commits – Not deadlock free but guarantees Not deadlock free but guarantees recoverable schedules (strict schedule: recoverable schedules (strict schedule: transaction can neither read/write X transaction can neither read/write X until last transaction that wrote X has until last transaction that wrote X has committed/aborted) committed/aborted) – Most popular variation of 2PL Most popular variation of 2PL
  • 23. Concluding Remarks Concluding Remarks • Concurrency control subsystem is responsible Concurrency control subsystem is responsible for inserting locks at right places into your for inserting locks at right places into your transaction transaction – Strict 2PL is widely used Strict 2PL is widely used – Requires use of waiting queue Requires use of waiting queue • All 2PL locking protocols guarantee All 2PL locking protocols guarantee serializability serializability • Does not permit all possible serial schedules Does not permit all possible serial schedules
  • 24. Why “Database Recovery Techniques”? Why “Database Recovery Techniques”? • A ACI CID D properties of Transaction properties of Transaction Time T1 T2 T3 Crash Database system should guarantee Database system should guarantee - D Durability : Applied changes by transactions urability : Applied changes by transactions must not be lost. ~ T3 must not be lost. ~ T3 - A Atomicity : Transactions can be aborted. tomicity : Transactions can be aborted. ~ T1, T2 ~ T1, T2 System crash Transaction error System error Local error Disk failure Catastrophe
  • 25. Basic Idea : “Logging” Basic Idea : “Logging” • Undo/Redo by the Log Undo/Redo by the Log   recover Non-catastrophic failure recover Non-catastrophic failure Time T1 T2 T3 Crash System Log System Log - keeps info of changes - keeps info of changes applied by transactions applied by transactions Checkpoint Backup • Full DB Backup Full DB Backup > Differential Backup > Differential Backup > > (Transaction) Log (Transaction) Log Catastrophic failure Catastrophic failure
  • 26. Physical View Physical View - How they work - - How they work - (1) (1) Action : Action : 1) 1) Check Check the directory the directory whether whether in the cache in the cache 2) If none, copy from 2) If none, copy from disk pages disk pages to to the cache the cache Disk Memory DBMS cache (buffers) Disk pages/blocks (address:A,a,1) (address:B,b,0) A B a b Director y copy flush 3) For the copy, old buffers needs to be 3) For the copy, old buffers needs to be flushed flushed from from the cache the cache to to the disk pages the disk pages B’
  • 27. Physical View Physical View - How they work - - How they work - (2) (2) Disk Memory DBMS cache (buffers) Disk pages/blocks (address:A,a,1) (address:B,b,0) A B a b Director y copy flush 4) Flush only if 4) Flush only if a dirty bit a dirty bit is 1 is 1 Dirty bit : (in the directory) whether there is Dirty bit : (in the directory) whether there is a change after copy to the cache a change after copy to the cache 1 – updated in the cache 1 – updated in the cache 0 – not updated in the cache (no need to flush) 0 – not updated in the cache (no need to flush) updat e B’
  • 28. Physical View Physical View - How they work - - How they work - (3) (3) Disk Memory DBMS cache (buffers) Disk pages/blocks A B a b copy flush A-a : A-a : “in-place updating” “in-place updating” - when flushing, overwrite at the same - when flushing, overwrite at the same location location - - logging logging is required is required B-b : B-b : “shadowing” “shadowing” B’
  • 29. Physical View Physical View - How they work - - How they work - (4) (4) Disk Memory DBMS cache Data blocks B b (1) copy (from the disk to the cache) (2) update the cached data, record it in the log (3) flush the log and the data (from the cache to the disk) copy flush Log blocks update B’ Log blocks Data blocks update
  • 30. WAL : Write-Ahead Logging (1) WAL : Write-Ahead Logging (1) • in-place updating in-place updating   A log A log is necessary is necessary BFIM (BeFore IMage) BFIM (BeFore IMage) – overwrite – – overwrite – AFIM (AFter) AFIM (AFter) Disk Memory DBMS cache Data blocks copy 2) flush Log blocks update Log blocks Data blocks update A a BFIM BFIM AFIM BFIM • WAL (Write-Ahead Logging) WAL (Write-Ahead Logging) Log entries flushed Log entries flushed before overwriting before overwriting main data main data 1) flush UNDO-type log record
  • 31. WAL : Write-Ahead Logging (2) WAL : Write-Ahead Logging (2) • WAL protocol requires WAL protocol requires UNDO UNDO and and REDO REDO Time T commit Log Log - BFIM cannot be overwritten by AFIM on disk BFIM cannot be overwritten by AFIM on disk until all until all UNDO-type log UNDO-type log have force-written to disk. have force-written to disk. - The commit operation cannot be completed The commit operation cannot be completed until all until all UNDO/REDO-type log UNDO/REDO-type log have force-written. have force-written. UNDO REDO
  • 32. Steal & No-Force (1) Steal & No-Force (1) • Typical DB Typical DB employs employs a a steal/no-force steal/no-force strategy strategy Time T1 T2 T3 commit commit cache Updated data by T2 cache Can be Used for other transactions (T3) before T2 commits • Steal Steal strategy : a transaction strategy : a transaction can can be written to disk be written to disk before it commits before it commits Advantage : Advantage : buffer space saving buffer space saving
  • 33. Steal & No-Force (2) Steal & No-Force (2) Time T1 T2 T3 commit commit cache Updated data by T2 cache If T3 needs the same data, it must be copied again when T2 commits • No-Force No-Force strategy : a transaction strategy : a transaction need not need not to be to be written to disk written to disk immediately immediately when it commits when it commits Advantage : Advantage : I/O operations saving I/O operations saving   Force strategy Force strategy
  • 34. Checkpointing Checkpointing • Checkpoint Checkpoint - All DMBS buffers modified are wrote out to disk. - All DMBS buffers modified are wrote out to disk. - A record is written into the log. ( - A record is written into the log. ([checkpoint] [checkpoint]) ) - Periodically done - Periodically done (e.g. every n min. or every n transaction (e.g. every n min. or every n transaction Time T1 T2 T3 Crash Checkpoint
  • 35. Transaction Rollback (1) Transaction Rollback (1) • Rollback / Roll foward Rollback / Roll foward Time T1 T2 T3 Crash T4 T5 1 : Not necesary 2 : Roll foward 3 : Rollback 4 : Roll forward 5 : Roll back Checkpoint - Steal : transaction may be written on disk Steal : transaction may be written on disk before it commits before it commits Recovery method
  • 36. • example : example : Nam Nam e e Accoun Accoun t t Mr.A Mr.A $10 $10 Mr.B Mr.B $2,000 $2,000 Mr.C Mr.C $30,00 $30,00 0 0 Transaction Rollback (2) Transaction Rollback (2) Time T2 Checkpoint Crash T1 : A company pays salary to employees i) transfer $2,000 to Mr. A’s account ii) transfer $2,500 to Mr B’s account … write(A) read(A) T1 read(B) read(A) write(B) write(C) read(C) write(A) T2 : Mr.A pays the monthly rent. i) withdraw $1,500 from Mr.A’s account ii) transfer $1,500 to Mr.C’s account
  • 37. • Cascading Rollback Cascading Rollback Transaction Rollback (3) Transaction Rollback (3) System Log System Log [checkpoint] [checkpoint] [start_transaction, T1] [start_transaction, T1] [read_item, T1, A] [read_item, T1, A] [write_item, T1, A, 10, 2010] [write_item, T1, A, 10, 2010] [start_transaction, T2] [start_transaction, T2] [read_item, T2, A] [read_item, T2, A] [write_item, T2, A, 2010, 510] [write_item, T2, A, 2010, 510] [read_item, T1, B] [read_item, T1, B] [read_item, T2, C] [read_item, T2, C] [write_item, T2, C, 1500, 31500] [write_item, T2, C, 1500, 31500] ~~~ CRASH ~~~~ ~~~ CRASH ~~~~ T2 Checkpoint Crash w(A) r(A) T1 r (B) r(A) w(C) r(C) w(A) A A $10 $10 $10 $10 $2,010 $2,010 $2,010 $2,010 $510 $510 C C $30,000 $30,000 $30,000 $30,000 $31,500 $31,500 -T1 is interrupted (needs rollback) -T2 uses value modified by T1 (also needs rollback)
  • 38. Categorization of Recovery Algorithm Categorization of Recovery Algorithm • Deferred update – the No-UNDO/REDO algorithm Deferred update – the No-UNDO/REDO algorithm • Immediate update – the UNDO/REDO algorithm Immediate update – the UNDO/REDO algorithm