CHAPTER 3 RECOVERY & CONCURRENCY ADVANCED DATABASE SYSTEMS. Assist. Prof. Dr. Volkan TUNALI

Size: px

Start display at page:

Download "CHAPTER 3 RECOVERY & CONCURRENCY ADVANCED DATABASE SYSTEMS. Assist. Prof. Dr. Volkan TUNALI"

Berenice Hunter
5 years ago
Views:

1 CHAPTER 3 RECOVERY & CONCURRENCY ADVANCED DATABASE SYSTEMS Assist. Prof. Dr. Volkan TUNALI

2 PART 1 2 RECOVERY

3 Topics 3 Introduction Transactions Transaction Log System Recovery Media Recovery

4 Introduction 4 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.

5 Transactions 5 A single bank money transaction: Transfer $100 from one account to another. UPDATE ACCOUNT SET BALANCE = BALANCE 100 WHERE ACC_ID = 123 UPDATE ACCOUNT SET BALANCE = BALANCE WHERE ACC_ID = 456

6 Transactions 6 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.

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

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

9 Transaction Properties ACID 9 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.

10 Transaction Log 10 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.

11 Transaction Log 11 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.

12 Transaction Log 12

13 Failures 13 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

14 System Recovery 14 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.

15 Checkpoint 15 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.

16 Media Recovery 16 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.

17 PART 2 17 CONCURRENCY

18 Topics 18 Introduction Three Concurrency Problems Locking Deadlock Isolation Levels

19 Introduction 19 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.

20 Three Concurrency Problems 20 In the absence of a control mechanism, some problems can occur. 1. Lost update problem 2. Uncommitted dependency problem 3. Inconsistent analysis problem

21 Lost Update Problem 21 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).

22 Uncommitted Dependency Problem 22 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.

23 Inconsistent Analysis Problem 23 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.

24 Inconsistent Analysis Problem 24

25 Inconsistent Analysis Problem 25

26 Inconsistent Analysis Problem 26

27 Three Concurrency Problems 27

28 Locking 28 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.

29 Locking 29 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.

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

31 Deadlock 31 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.

32 Isolation Levels 32 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.

33 Isolation Levels 33 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)

34 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

35 Isolation Levels 35 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.

36 Isolation Levels 36 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.

37 Isolation Levels 37 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.

38 Isolation Levels 38 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.

39 Isolation Levels 39 SET TRANSACTION ISOLATION LEVEL { READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE }

TRANSACTION PROPERTIES

TRANSACTION PROPERTIES Transaction Is any action that reads from and/or writes to a database. A transaction may consist of a simple SELECT statement to generate a list of table contents; it may consist of series of INSERT statements