recoveryass - Database Recovery Techniques Presentation by:...

Info iconThis preview shows pages 1–8. Sign up to view the full content.

View Full Document Right Arrow Icon
Database Recovery Techniques Presentation by: P.Mirunalini A.P/ CSE SSNCE B.E. IV Semester B
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Database Recovery Purpose of Database Recovery b To bring the database into the last consistent state, which existed prior to the failure. b To preserve transaction properties (Atomicity, Consistency, Isolation and Durability).
Background image of page 2
Types of Failure The database may become unavailable for use due to b Transaction failure : Transactions may fail because of incorrect input, deadlock, incorrect synchronization. b System failure : System may fail because of addressing error, application error, operating system fault, RAM failure, etc. b Media failure : Disk head crash, power disruption, etc.
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
System Recovery b Local failure – an overflow exception within an individual transaction – affects only the transaction in which the failure has actually occured. b Global failure – power outage – affects all of the transactions in progress at the time of the failure. b Two categories of global failures: s System failures – affect all transactions currently in progress but do not physically damage the database soft crash – power outage s Media failures – do cause damage to the database or some portion thereof, and affect at least those transactions currently using that portion – hard crash – head crash on the disk
Background image of page 4
Transaction Log b For recovery from any type of failure data values prior to modification ( BFIM - BeFore Image ) and the new value after modification ( AFIM – AFter Image ) are required. b These values and other information is stored in a sequential file called Transaction log. A sample log is given below. b Back P and Next P point to the previous and next log records of the same transaction. T ID Back P Next P Operation Data item BFIM AFIM T1 0 1 T1 1 4 T2 0 8 T1 2 5 T1 4 7 T3 0 9 T1 5 nil Begin Write W R R End Begin X Y M N X = 200 Y = 100 M = 200 N = 400 X = 100 Y = 50 M = 200 N = 400
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Database Recovery b Transaction Roll-back (Undo) and Roll-Forward (Redo) b To maintain atomicity, a transaction’s operations are redone or undone . b Undo : Restore all BFIMs on to disk (Remove all AFIMs). b Redo : Restore all AFIMs on to disk. b Database recovery is achieved either by performing only Undos or only Redos or by a combination of the two. These operations are recorded in the log as they happen.
Background image of page 6
Transactions b If failure occurs before the transaction reaches its planned termination, then those updates will be undone .
Background image of page 7

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 8
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 36

recoveryass - Database Recovery Techniques Presentation by:...

This preview shows document pages 1 - 8. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online