CHAPTER 3 RECOVERY & CONCURRENCY ADVANCED DATABASE SYSTEMS
Assist. Prof. Dr. Volkan TUNALI
PART 1
RECOVERY
Advanced Database Systems © Volkan TUNALI
2
Topics
Introduction
Transactions
Transaction Log
System Recovery
Media Recovery
Advanced Database Systems © Volkan TUNALI
3
Introduction
Recovery in a database system means recovering the database itself
Restoring the database to a correct state after some failure has rendered the current state incorrect, or at least suspect.
Recovery is based on a simple principle: redundancy.
Any piece of information the database contains can be reconstructed from some other information stored redundantly somewhere else in the system.
Advanced Database Systems © Volkan TUNALI
4
Transactions
A single bank money transaction:
Transfer $100 from one account to another.
Advanced Database Systems © Volkan TUNALI
5
UPDATE ACCOUNT
SET BALANCE = BALANCE – 100
WHERE ACC_ID = 123
UPDATE ACCOUNT
SET BALANCE = BALANCE + 100
WHERE ACC_ID = 456
Transactions
Single bank money transfer transaction requires two database updates.
What if some system failure happens between the two updates?
Database is left in an incorrect state!
We have to make sure that
Both updates are execute together successfully.
Or, all are undone.
Via a mechanism of DBMS.
Advanced Database Systems © Volkan TUNALI
6
Transactions
A transaction is a logical unit of work. Begins with a BEGIN TRANSACTION operation. Ends with either COMMIT or ROLLBACK operation.
A transaction usually involves a sequence of database operations that need to be executed together to transform the correct state of the database to another correct state.
If the transaction executes some updates and then a failure (error) occurs before the transaction reaches its planned termination (COMMIT), then those updates will be undone. The transaction either executes in its entirety or is totally
cancelled (i.e., made as if it never executed at all). Atomicity.
Advanced Database Systems © Volkan TUNALI
7
Transactions
COMMIT: successful end-of-transaction
All of the updates made by that unit-of-work can be committed (recorded permanently in the database).
ROLLBACK: unsuccessful end-of-transaction
All of the updates made by that unit-of-work must be rolled-back (e.i., undone).
Advanced Database Systems © Volkan TUNALI
8
Transaction Properties – ACID
Each individual transaction must display atomicity, consistency, isolation, and durability – ACID.
Atomicity: Transactions are atomic (all or nothing). Correctness (Consistency): Transactions transform a
correct state of the database into another correct state, without necessarily preserving correctness at all intermediate points.
Isolation: Transactions are isolated from each other. Any transaction’s updates are concealed from all the rest, until that transaction commits.
Durability: Once a transaction commits, its updates persist in the database (they cannot be undone or lost), even in the event of a subsequent system failure.
Advanced Database Systems © Volkan TUNALI
9
Transaction Log
A DBMS uses a transaction log to keep track of all transactions that update the database.
Information stored in this log is used by the DBMS for a recovery requirement triggered by a ROLLBACK statement, a program’s abnormal termination, or a system failure such as a network discrepancy or a disk crash.
Some DBMSs use the transaction log to recover a database forward to a currently consistent state. After a server failure DBMS automatically rolls back uncommitted transactions,
rolls forward transactions that were committed but not yet written to the physical database.
Advanced Database Systems © Volkan TUNALI
10
Transaction Log
Transaction log stores:
A record for the beginning of the transaction.
For each transaction component (SQL statement):
The type of operation being performed (update, delete, insert).
The names of the objects affected by the transaction (the name of the table).
The “before” and “after” values for the fields being updated.
Pointers to the previous and next transaction log entries for the same transaction.
The ending (COMMIT) of the transaction.
Although using a transaction log increases the processing overhead of a DBMS, the ability to restore a corrupted database is worth the price.
Advanced Database Systems © Volkan TUNALI
11
Transaction Log
Advanced Database Systems © Volkan TUNALI
12
Failures
Local failures
Errors within an individual transaction.
Global failures
Failures like power outages, which affect all of the transactions in progress.
Global failures usually fall in two categories:
System failures
Media failures
Advanced Database Systems © Volkan TUNALI
13
System Recovery
System failures affect all transactions currently in progress do no pysically damage the database called soft crash
Key point is that contents of main memory are lost. Some transactions must be undone (rolled-back) Some transactions must be redone (rolled-forward)
How does the system know at restart time which transactions to undo and which to redo? At certain intervals (typically whenever some number of
records have been written to the log) system automatically takes a checkpoint.
Advanced Database Systems © Volkan TUNALI
14
Checkpoint
Forcing the contents of the main memory buffers out to the pyhsical database
Forcing a special chekpoint record out to the pysical log contains a list of all transactions that were in progress when the
checkpoint was taken.
Advanced Database Systems © Volkan TUNALI
15
Media Recovery
Media failures
causes pysical damage to the database
like head crash on the disk
called hard crash
Recovery from media failures usually involve restoring the database from a backup copy or dump.
MS SQL Server has BACKUP and RESTORE commands.
Advanced Database Systems © Volkan TUNALI
16
PART 2
CONCURRENCY
Advanced Database Systems © Volkan TUNALI
17
Topics
Introduction
Three Concurrency Problems
Locking
Deadlock
Isolation Levels
Advanced Database Systems © Volkan TUNALI
18
Introduction
DBMSs typically allow many transactions to access the same database at the same time.
A kind of control mechanism is needed to ensure that concurrent transactions do not interfere with each other.
Advanced Database Systems © Volkan TUNALI
19
Three Concurrency Problems
In the absence of a control mechanism, some problems can occur.
1. Lost update problem
2. Uncommitted dependency problem
3. Inconsistent analysis problem
Advanced Database Systems © Volkan TUNALI
20
Lost Update Problem
The lost update problem occurs when two concurrent transactions, T1 and T2, are updating the same data element and one of the updates is lost (overwritten by the other transaction).
Advanced Database Systems © Volkan TUNALI
21
Uncommitted Dependency Problem
The phenomenon of uncommitted data occurs when two transactions, T1 and T2, are executed concurrently and the first transaction (T1) is rolled back after the second transaction (T2) has already accessed the uncommitted data.
Advanced Database Systems © Volkan TUNALI
22
Inconsistent Analysis Problem
Inconsistent retrievals occur when a transaction accesses data before and after another transaction(s) finish working with such data.
For example, an inconsistent retrieval would occur if transaction T1 calculated some summary (aggregate) function over a set of data while another transaction (T2) was updating the same data.
The problem is that the transaction might read some data before they are changed and other data after they are changed, thereby yielding inconsistent results.
Advanced Database Systems © Volkan TUNALI
23
Inconsistent Analysis Problem
Advanced Database Systems © Volkan TUNALI
24
Inconsistent Analysis Problem
Advanced Database Systems © Volkan TUNALI
25
Inconsistent Analysis Problem
Advanced Database Systems © Volkan TUNALI
26
Three Concurrency Problems
Advanced Database Systems © Volkan TUNALI
27
Locking
A lock guarantees exclusive use of a data item to a current transaction. In other words, transaction T2 does not have access to a data item that is currently being used by transaction T1.
A transaction acquires a lock prior to data access; the lock is released (unlocked) when the transaction is completed so that another transaction can lock the data item for its exclusive use.
Advanced Database Systems © Volkan TUNALI
28
Locking
Two types of locks: Shared Lock (S): Read lock
Exclusive Lock (X): Write lock
A shared lock is issued when a transaction wants to read data from the database and no exclusive lock is held on that data item.
An exclusive lock is issued when a transaction wants to update (write) a data item and no locks are currently held on that data item by any other transaction.
Advanced Database Systems © Volkan TUNALI
29
Deadlock
A deadlock occurs when two transactions wait indefinitely for each other to unlock data.
Advanced Database Systems © Volkan TUNALI
30
Deadlock
If a deadlock occurs, it is desirable that system detect it and break it.
System chooses one of the deadlocked transactions as the victim and rolls it back.
Deadlock prevention is expensive, so systems usually perform deadlock detection and breaking.
Advanced Database Systems © Volkan TUNALI
31
Isolation Levels
Transactions specify an isolation level that defines the degree to which one transaction must be isolated from resource or data modifications made by other transactions.
Transaction isolation levels control: Whether locks are taken when data is read, and what type of
locks are requested. How long the read locks are held. Whether a read operation referencing rows modified by another
transaction: Blocks until the exclusive lock on the row is freed. Retrieves the committed version of the row that existed at the time
the statement or transaction started. Reads the uncommitted data modification.
Advanced Database Systems © Volkan TUNALI
32
Isolation Levels
The ISO standard defines the following isolation levels, all of which are supported by the SQL Server Database Engine:
Read uncommitted (the lowest level where transactions are isolated only enough to ensure that physically corrupt data is not read)
Read committed (Database Engine default level)
Repeatable read
Serializable (the highest level, where transactions are completely isolated from one another)
Advanced Database Systems © Volkan TUNALI
33
Isolation Levels
Advanced Database Systems © Volkan TUNALI
34
Isolation level Dirty read Nonrepeatable
read Phantom
Read uncommitted Yes Yes Yes
Read committed No Yes Yes
Repeatable read No No Yes
Serializable No No No
Isolation Levels
READ UNCOMMITTED Statements can read rows that have been modified by
other transactions but not yet committed.
Transactions running at the READ UNCOMMITTED level do not issue shared locks to prevent other transactions from modifying data read by the current transaction.
READ UNCOMMITTED transactions are also not blocked by exclusive locks that would prevent the current transaction from reading rows that have been modified but not committed by other transactions.
It is possible to read uncommitted modifications, which are called dirty reads.
Advanced Database Systems © Volkan TUNALI
35
Isolation Levels
READ COMMITTED
Statements cannot read data that has been modified but not committed by other transactions.
This prevents dirty reads.
Data can be changed by other transactions between individual statements within the current transaction, resulting in nonrepeatable reads or phantom data.
This option is the SQL Server default.
Advanced Database Systems © Volkan TUNALI
36
Isolation Levels
REPEATABLE READ Statements cannot read data that has been modified but not yet
committed by other transactions and that no other transactions can modify data that has been read by the current transaction until the current transaction completes.
Shared locks are placed on all data read by each statement in the transaction and are held until the transaction completes. This prevents other transactions from modifying any rows that have
been read by the current transaction.
Other transactions can insert new rows that match the search conditions of statements issued by the current transaction. If the current transaction then retries the statement it will retrieve
the new rows, which results in phantom reads.
Advanced Database Systems © Volkan TUNALI
37
Isolation Levels
SERIALIZABLE
Statements cannot read data that has been modified but not yet committed by other transactions.
No other transactions can modify data that has been read by the current transaction until the current transaction completes.
Other transactions cannot insert new rows with key values that would fall in the range of keys read by any statements in the current transaction until the current transaction completes.
Advanced Database Systems © Volkan TUNALI
38
Isolation Levels
SET TRANSACTION ISOLATION LEVEL
{ READ UNCOMMITTED
| READ COMMITTED
| REPEATABLE READ
| SERIALIZABLE
}
Advanced Database Systems © Volkan TUNALI
39