CHAPTER 3 RECOVERY & CONCURRENCY€¦ · A DBMS uses a transaction log to keep track of all...

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


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.


4

Transactions

A single bank money transaction:

Transfer $100 from one account to another.


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.


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.


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).


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.


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.


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.


11

Transaction Log


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


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.


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.


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.


16

PART 2

CONCURRENCY


17

Topics

Introduction

Three Concurrency Problems

Locking

Deadlock

Isolation Levels


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.


19


In the absence of a control mechanism, some problems can occur.

1. Lost update problem

2. Uncommitted dependency problem

3. Inconsistent analysis problem


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).


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.


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.


23



24



25



26



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.


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.


29

Deadlock

A deadlock occurs when two transactions wait indefinitely for each other to unlock data.


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.


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.


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)


33

Isolation Levels


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.


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.


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.


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.


38

Isolation Levels

SET TRANSACTION ISOLATION LEVEL

{ READ UNCOMMITTED

| READ COMMITTED

| REPEATABLE READ

| SERIALIZABLE

}


39

Date post:	15-May-2020
Category:	Documents
Upload:	others
View:	9 times
Download:	0 times

CHAPTER 3 RECOVERY & CONCURRENCY€¦ · A DBMS uses a transaction log to keep track of all...

Documents