database systems recovery & concurrency lecture # 20 1 st april, 2011

15
Database Systems Database Systems Recovery & Concurrency Lecture # 20 1 st April, 2011

Upload: aron-johns

Post on 17-Jan-2016

218 views

Category:

Documents


4 download

TRANSCRIPT

Page 1: Database Systems Recovery & Concurrency Lecture # 20 1 st April, 2011

Database SystemsDatabase SystemsRecovery & ConcurrencyLecture # 201st April, 2011

Page 2: Database Systems Recovery & Concurrency Lecture # 20 1 st April, 2011

Topics Topics OverviewRecovery (System vs. Media &

Backward vs. Forward)TransactionTransaction ManagementACID property for transactionsTransaction recoverySQL support

Page 3: Database Systems Recovery & Concurrency Lecture # 20 1 st April, 2011

Recovery Recovery Recovery in database system means

recovering the database itself, i.e., restoring the database to a state that is known to be correct after some failure has rendered the correct state incorrect, or at least suspect

Relationship with redundancy:: To make sure that the database is indeed recoverable is to make sure that any piece of information it contains can be reconstructed from some other information stored, redundantly some where else in the system

Page 4: Database Systems Recovery & Concurrency Lecture # 20 1 st April, 2011

Single-User vs. Multi-UserSingle-User vs. Multi-UserSingle-User System: At any given time, at

most one user can use the system

Multi-User System: Many users can access the system concurrently

Concurrency:

◦ Interleaved Processing: concurrent execution of processes is interleaved in a single CPU

◦ Parallel Processing: Processes are concurrently executed in multiple CPUs

Page 5: Database Systems Recovery & Concurrency Lecture # 20 1 st April, 2011

Transaction Transaction A Transaction: logical unit of database processing

that includes one or more access operations (read – retrieval, write – insert/update, delete)

A Transaction (Set of operations) may be stand-alone specified in a high-level language like SQL submitted interactively, or may be embedded in the program

Transaction Boundaries: Begin and End transaction

An application program may contain several transactions separated by Begin and End transaction boundaries

Page 6: Database Systems Recovery & Concurrency Lecture # 20 1 st April, 2011

Transaction RecoveryTransaction RecoveryRecovering the database after some

individual transaction has failed for some reason

System Recovery: Recovering after some kind of system crash has caused all the currently running transactions to fail simultaneously

Media Recovery: Recovering after the database has been physically damaged in some way, e.g., by head crash on disk

Page 7: Database Systems Recovery & Concurrency Lecture # 20 1 st April, 2011

Backward vs. Forward Backward vs. Forward RecoveryRecoveryRestoring the database to a

correct state by undoing work is sometimes called backward recovery

Restoring the database to a correct state by redoing work is sometimes called forward recovery

Page 8: Database Systems Recovery & Concurrency Lecture # 20 1 st April, 2011

Transaction ManagementTransaction ManagementTransaction management is a task of

supervising the execution of transactions in such a way that they can indeed be guaranteed to possess some of the important properties called ACID properties

◦ Atomicity

◦ Consistency

◦ Isolation

◦ Durability

Page 9: Database Systems Recovery & Concurrency Lecture # 20 1 st April, 2011

ACID PropertiesACID PropertiesAtomicity: A transaction is an atomic unit

of processing; it is either performed in its entirety or not performed at all. (All or Nothing)

Consistency Preservation: Transformations preserves database consistency. A correct execution of the transaction must take the database from one consistent state to another consistent state, without necessarily preserving consistency at all intermediate points

Page 10: Database Systems Recovery & Concurrency Lecture # 20 1 st April, 2011

ACID Properties (…Cont)ACID Properties (…Cont) Isolation: Transactions are isolated from

one another. A transaction should not make its update visible to other transactions until it is committed; this property, when enforced strictly, solves the temporary update problem and makes cascading rollbacks of transactions unnecessary

Durability (Or Permanency): Once a transaction changes the database and the changes are committed, its update survive, i.e., these changes must never be lost because of subsequent failures (System Crash)

Page 11: Database Systems Recovery & Concurrency Lecture # 20 1 st April, 2011

Transaction ManagerTransaction ManagerThe system component that provides the

atomicity is known as “transaction manager” and the operations “Commit” and “Rollback” are the key to the way it works.

Transactions are initiated by BEGIN TRANSACTION and terminated either by Commit or Rollback

Commit establishes a commit point (updates are made permanent) while Rollback rolls the database back to the previous commit point (updates are undone)

Page 12: Database Systems Recovery & Concurrency Lecture # 20 1 st April, 2011

COMMIT & ROLLBACKCOMMIT & ROLLBACKCOMMIT TRANSACTION: It signals

successful end of transaction; it tells the transaction manager (TM) that a logical unit of work has been successfully completed, the database is in consistent state again, and all of the updates made by the unit of work can now be committed or made permanent

ROLLBACK TRANSACTION: It signals unsuccessful end of transaction; it tells the TM that something has gone wrong, the database might be in an inconsistent state, and all of the updates made by the logical unit of work so far must be rollback or undone

Page 13: Database Systems Recovery & Concurrency Lecture # 20 1 st April, 2011

Recovery LogRecovery LogIf a transaction does not reach its

planned termination, the system will force a ROLLBACK for it (transaction recovery). In order to be able to undo updates, the system maintains a recovery log

The log records for a given transaction must be written to a physical log before COMMIT processing for that transaction can complete: this is a write-ahead log rule

Page 14: Database Systems Recovery & Concurrency Lecture # 20 1 st April, 2011

REDO & UNDO OperationsREDO & UNDO OperationsThe system also guarantees the ACID

properties of the transaction in the case of a system crash. To provide such guarantee, the system must:

◦ REDO all the work done by transaction that completed successfully prior to the crash

◦ UNDO all the work done by the transaction that started but didn’t complete prior to crash

Page 15: Database Systems Recovery & Concurrency Lecture # 20 1 st April, 2011

System RecoverySystem RecoveryThe system recovery activity is

carried out as part of the system’s restart procedure (sometimes known as the restart/recovery procedure)

The system discovers what work has to be re-done and what undone by examining the most recent check point record

Check point records are written to the log at prescribed intervals