Lecture plan Transaction processing Concurrency control

Slides:



Advertisements
Similar presentations
Data recovery 1. 2 Recovery - introduction recovery restoring a system, after an error or failure, to a state that was previously known as correct have.
Advertisements

Concurrency control 1. 2 Introduction concurrency more than one transaction have access to data simultaneously part of transaction processing.
1 Term 2, 2004, Lecture 6, TransactionsMarian Ursu, Department of Computing, Goldsmiths College Transactions 3.
Concurrency Control Techniques
Indra Budi Transaction Indra Budi
Chapters 15-17: Transaction Management
What is Concurrent Process (CP)? Multiple users access databases and use computer systems Multiple users access databases and use computer systems simultaneously.
Database Systems (資料庫系統)
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Transaction Management Overview Chapter 16.
Chapter 16 Concurrency. Topics in this Chapter Three Concurrency Problems Locking Deadlock Serializability Isolation Levels Intent Locking Dropping ACID.
1 Concurrency Control Chapter Conflict Serializable Schedules  Two actions are in conflict if  they operate on the same DB item,  they belong.
1 Lecture 11: Transactions: Concurrency. 2 Overview Transactions Concurrency Control Locking Transactions in SQL.
1 Integrity Ioan Despi Transactions: transaction concept, transaction state implementation of atomicity and durability concurrent executions serializability,
Transaction Management: Concurrency Control CS634 Class 17, Apr 7, 2014 Slides based on “Database Management Systems” 3 rd ed, Ramakrishnan and Gehrke.
IDA / ADIT Lecture 10: Database recovery Jose M. Peña
TRANSACTION PROCESSING SYSTEM ROHIT KHOKHER. TRANSACTION RECOVERY TRANSACTION RECOVERY TRANSACTION STATES SERIALIZABILITY CONFLICT SERIALIZABILITY VIEW.
Principles of Transaction Management. Outline Transaction concepts & protocols Performance impact of concurrency control Performance tuning.
Concurrency Control II
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Concurrency Control Chapter 17 Sections
CSC271 Database Systems Lecture # 32.
Lock-Based Concurrency Control
Transaction Management Transparencies
Lecture 11 Recoverability. 2 Serializability identifies schedules that maintain database consistency, assuming no transaction fails. Could also examine.
Sekolah Tinggi Ilmu Statistik (STIS) 1 Dr. Said Mirza Pahlevi, M.Eng.
Database Systems, 8 th Edition Concurrency Control with Time Stamping Methods Assigns global unique time stamp to each transaction Produces explicit.
Quick Review of Apr 29 material
Quick Review of May 1 material Concurrent Execution and Serializability –inconsistent concurrent schedules –transaction conflicts serializable == conflict.
Transaction Management and Concurrency Control
Chapter 17: Transaction Management
What is a Transaction? Logical unit of work
Transaction Management
1 Transaction Management Database recovery Concurrency control.
1 Minggu 8, Pertemuan 15 Transaction Management Matakuliah: T0206-Sistem Basisdata Tahun: 2005 Versi: 1.0/0.0.
©Silberschatz, Korth and Sudarshan16.1Database System Concepts 3 rd Edition Chapter 16: Concurrency Control Lock-Based Protocols Timestamp-Based Protocols.
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 10 Transaction Management and Concurrency Control.
System Catalogue v Stores data that describes each database v meta-data: – conceptual, logical, physical schema – mapping between schemata – info for query.
1 Chapter 6 : Transaction Management Pearson Education © 2009.
Security and Transaction Nhi Tran CS 157B - Dr. Lee Fall, 2003.
BIS Database Systems School of Management, Business Information Systems, Assumption University A.Thanop Somprasong Chapter # 10 Transaction Management.
Chapterb19 Transaction Management Transaction: An action, or series of actions, carried out by a single user or application program, which reads or updates.
Transaction Processing Concepts. 1. Introduction To transaction Processing 1.1 Single User VS Multi User Systems One criteria to classify Database is.
Databases Illuminated
Transaction Management, Concurrency Control and Recovery Chapter 20 1.
1 Chapter 20 Transaction Management Transparencies Last Updated: 17 th March 2011 By M. Arief
Transactions CPSC 356 Database Ellen Walker Hiram College (Includes figures from Database Systems by Connolly & Begg, © Addison Wesley 2002)
TRANSACTION MANAGEMENT R.SARAVANAKUAMR. S.NAVEEN..
II.I Selected Database Issues: 2 - Transaction ManagementSlide 1/20 1 II. Selected Database Issues Part 2: Transaction Management Lecture 4 Lecturer: Chris.
1 CSE 480: Database Systems Lecture 24: Concurrency Control.
Transaction Management Transparencies. ©Pearson Education 2009 Chapter 14 - Objectives Function and importance of transactions. Properties of transactions.
9 1 Chapter 9_B Concurrency Control Database Systems: Design, Implementation, and Management, Rob and Coronel.
NOEA/IT - FEN: Databases/Transactions1 Transactions ACID Concurrency Control.
10 1 Chapter 10_B Concurrency Control Database Systems: Design, Implementation, and Management, Rob and Coronel.
Chapter 13 Managing Transactions and Concurrency Database Principles: Fundamentals of Design, Implementation, and Management Tenth Edition.
SYSTEMS IMPLEMENTATION TECHNIQUES TRANSACTION PROCESSING DATABASE RECOVERY DATABASE SECURITY CONCURRENCY CONTROL.
Transaction Management
Lecture 3 Concurrency control techniques
Concurrency Control Techniques
Concurrency Control.
Part- A Transaction Management
Transaction Management Transparencies
Transaction Properties
4. Concurrency control techniques
Chapter 10 Transaction Management and Concurrency Control
Chapter 15 : Concurrency Control
Transaction Management, Concurrency Control and Recovery
Introduction of Week 13 Return assignment 11-1 and 3-1-5
Transaction management
Transaction Management
CONCURRENCY Concurrency is the tendency for different tasks to happen at the same time in a system ( mostly interacting with each other ) .   Parallel.
Transactions, Properties of Transactions
Presentation transcript:

Lecture plan Transaction processing Concurrency control Recovery techniques Jane Reid, BSc/IT DB, QMUL, 11/3/02

Transaction processing A transaction is a logical unit of DB processing, consisting of one or more DB access operations Transaction boundaries may be specified implicitly or explicitly Transactions are recorded in system log, kept on disk Jane Reid, BSc/IT DB, QMUL, 11/3/02

Example transactions T1 (successful) T2 (unsuccessful) Begin_transaction; Read_item(X); X := X - 10; Write_item(X); Read_item(Y); Y := Y + N; Write_item(Y); End_transaction; Commit(T1); T2 (unsuccessful) Begin_transaction; Read_item(X); X := X - 10; Write_item(X); Read_item(Y); [transaction fails] Abort(T2); [possible rollback] Jane Reid, BSc/IT DB, QMUL, 11/3/02

Transaction properties [1] Must hold for every transaction for the DB to remain stable ACID properties Atomicity A transaction should be treated as an indivisible unit Managed by transaction recovery subsystem Consistency preservation A transaction must transform the database from one consistent state to another consistent state Managed by programmers / DBMS module Jane Reid, BSc/IT DB, QMUL, 11/3/02

Transaction properties [2] Isolation Transactions should execute independently of each other Managed by concurrency control subsystem Durability Effects of a successful transaction must be permanently recorded in the DB Managed by recovery subsystem Jane Reid, BSc/IT DB, QMUL, 11/3/02

Transaction schedules [1] Ordering of operations of all transactions Potential multiple users Potential multiple processors Two operations conflict if They belong to different transactions They access the same item At least one of the operations is a write_item(X) Jane Reid, BSc/IT DB, QMUL, 11/3/02

Transaction schedules [2] Complete schedule All operations from all transactions present Commit or abort operation must be last in each transaction Any pair of operations from same transaction appear in correct order For any pair of conflicting operations, one must occur first in schedule Partial order of operations Two non-conflicting operations may occur simultaneously Committed projection of schedule Only operations from committed transactions Jane Reid, BSc/IT DB, QMUL, 11/3/02

Schedule criteria Recoverability Avoidance of cascading rollback Should not be necessary to rollback, i.e. undo write operations to DB, after commit point Transaction only commits when all other transactions writing to common data item have committed Other transactions writing to common data items should not abort before transaction reads Avoidance of cascading rollback All transactions only read items written by committed transactions Strictness Transactions cannot read or write items until last transaction to write item has committed or aborted Jane Reid, BSc/IT DB, QMUL, 11/3/02

Serial and serializable schedules Serial schedules Operations of each transaction executed consecutively without interleaved operations Serializable schedules Protocol based on committed projection being equivalent to some serial schedule Serializability guaranteed by concurrency control protocol Jane Reid, BSc/IT DB, QMUL, 11/3/02

Schedule equivalence [1] Result equivalent Produces same final DB state View equivalent Two schedules have Same set of transactions and operations Equivalent conditions on same operations Same last operation to write an item So a schedule whose committed projection is view equivalent to some serial schedule is said to be view serializable Jane Reid, BSc/IT DB, QMUL, 11/3/02

Schedule equivalence [2] Conflict equivalent Order of any two conflicting operations is the same in both schedules So a schedule whose committed projection is conflict equivalent to some serial schedule is said to be conflict serializable Jane Reid, BSc/IT DB, QMUL, 11/3/02

Concurrency control Concurrency control necessary because Lost update Temporary update (dirty read) Incorrect summary Unrepeatable read Jane Reid, BSc/IT DB, QMUL, 11/3/02

Lost update Transaction 1 Transaction 2 Read_item(X); X := X - N; Write_item(X); Read_item(Y); Y := Y + N; Write_item(Y); Transaction 2 Read_item(X); X := X + M; Write_item(X); Jane Reid, BSc/IT DB, QMUL, 11/3/02

Temporary update Transaction 1 Transaction 2 Read_item(X); X := X - N; Write_item(X); Read_item(Y); Transaction fails Transaction 2 Read_item(X); X := X + M; Write_item(X); Jane Reid, BSc/IT DB, QMUL, 11/3/02

Incorrect summary Transaction 1 Transaction 2 Sum := 0; Read_item(A); Read_item(X); X := X - N; Write_item(X); Read_item(Y); Y := Y + N; Write_item(Y); Transaction 2 Sum := 0; Read_item(A); Sum := Sum + A; Read_item(X); Sum := Sum + X; Read_item(Y); Sum := Sum + Y; Jane Reid, BSc/IT DB, QMUL, 11/3/02

Unrepeatable read Transaction 1 Transaction 2 Read_item(Y); Read_item(X); Y := Y + X; Write_item(Y); Read_item(Z); Z := Z + X; Write_item(Z); Transaction 2 Read_item(X); X := X + 1; Write_item(X); Jane Reid, BSc/IT DB, QMUL, 11/3/02

Concurrency control techniques Locking Timestamp ordering Multi-version timestamp ordering Validation / certification (optimistic) Jane Reid, BSc/IT DB, QMUL, 11/3/02

Locking [1] Lock Danger of deadlock Variable describing status of data item Information held in a lock table Danger of deadlock Each transaction in a set of transactions is waiting for an item locked by another transaction in the same set Jane Reid, BSc/IT DB, QMUL, 11/3/02

Locking [2] Types of locks Binary Shared / exclusive Two possible states: locked or unlocked Two operations: Lock_item(X), Unlock_item(X) Shared / exclusive Multiple states Three operations: Read_lock(X), Write_lock(X), Unlock(X) Jane Reid, BSc/IT DB, QMUL, 11/3/02

Binary locks Transaction must lock data item before read_item or write_item operations Transaction must unlock data item after finishing with it No two transactions can access same data item concurrently Jane Reid, BSc/IT DB, QMUL, 11/3/02

Shared / exclusive locks Read-locked items are share-locked Write-locked items are exclusive-locked Two types of lock conversion: Read_lock(X) -> write_lock(X) Write_lock(X) -> read_lock(X) Jane Reid, BSc/IT DB, QMUL, 11/3/02

Two-phase locking [1] Guarantees serializability All locking operations precede first unlock operation in the transaction Two phases: Expanding / growing Shrinking Jane Reid, BSc/IT DB, QMUL, 11/3/02

Two-phase locking [2] Types of 2PL Basic 2PL Conservative (static) 2PL Predeclaration of read- and write-sets Transaction waits until all items available Deadlock-free, but impractical Strict 2PL Write locks not released until commit / abort Guarantees strict schedules Not deadlock-free Rigorous 2PL (variant of strict 2PL) No locks released until commit / abort Jane Reid, BSc/IT DB, QMUL, 11/3/02

Deadlock avoidance Deadlock can be avoided by Prevention by deadlock prevention protocols Detection once it has happened Conflicting transactions can be rolled back, or aborted and restarted Jane Reid, BSc/IT DB, QMUL, 11/3/02

Deadlock prevention [1] Conservative 2PL Lock all data items in advance Transaction timestamp Older transaction has smaller timestamp value Wait-die algorithm If waiting transaction older than locking transaction, continue to wait Otherwise, abort and restart later Wound-wait algorithm If waiting transaction older than locking transaction, locking transaction is aborted and restarted later with same timestamp Otherwise, wait Jane Reid, BSc/IT DB, QMUL, 11/3/02

Deadlock prevention [2] No waiting algorithm If transaction unable to obtain lock, it is aborted and restarted after delay Cautious waiting algorithm If locking transaction is not blocked, wait Otherwise, transaction is aborted Jane Reid, BSc/IT DB, QMUL, 11/3/02

Deadlock detection [1] More practical than prevention if Transactions are big Each transaction uses many data items Transaction load is heavy Automatic (system) method uses time-outs Deadlock assumed if transaction waits too long Jane Reid, BSc/IT DB, QMUL, 11/3/02

Deadlock detection [2] Manual detection uses wait-for graph One node created for each transaction executing Directed edge created for transaction waiting to lock item currently locked by another transaction Deadlock if graph has cycle Victim selection necessary Jane Reid, BSc/IT DB, QMUL, 11/3/02

Starvation One transaction cannot proceed for an indefinite amount of time Can be solved by: Better waiting scheme E.g. first-come-first-served Higher priorities for transactions that have been aborted multiple times Jane Reid, BSc/IT DB, QMUL, 11/3/02

Timestamp ordering Transactions ordered by timestamp Equivalent serial schedule in timestamp order Data items accessed by conflicting operations in serializability order No locks, and therefore no deadlock, BUT risk of long waiting time Jane Reid, BSc/IT DB, QMUL, 11/3/02

Multi-version timestamp ordering Based on basic timestamp ordering Maintain multiple copies of data items: Keep multiple copies of current data items Keep old values of data items on update Appropriate version and copy of item chosen to maintain (conflict or view) serializability Old values deleted once all transactions using that item have completed Jane Reid, BSc/IT DB, QMUL, 11/3/02

Validation Three stages Transaction executed Updates made to local copy of data Transaction validated Checks for serializability violations Transaction committed or aborted If validation OK, DB is updated Otherwise transaction is aborted and restarted Jane Reid, BSc/IT DB, QMUL, 11/3/02

DB recovery [1] DB recovery necessary if failure caused by: Transaction System Media DB restored to most recent consistent state before failure by rollback mechanism Jane Reid, BSc/IT DB, QMUL, 11/3/02

DB recovery [2] Types of failure: Catastrophic (loss of DB on disk) Restore past copy of DB from archival storage Redo operations of committed transactions from log backup Non-catastrophic (consistency failure) Use lists of committed and active transactions Reverse changes by undoing inconsistent operations May also be necessary to redo some operations from system log Jane Reid, BSc/IT DB, QMUL, 11/3/02

Non-catastrophic failure Two types of algorithm: Deferred update DB updated only when transaction commits Immediate update DB may be updated before transaction commits Jane Reid, BSc/IT DB, QMUL, 11/3/02

Deferred update Transaction commits only when: All update operations have been recorded in log Log has been force-written to disk A type of NO-UNDO/REDO algorithm Undo not needed Any changes made to the DB result from completed, committed transactions Redo operations perhaps necessary Some transactions may have committed, but the changes not yet been saved to the DB Jane Reid, BSc/IT DB, QMUL, 11/3/02

Single-user deferred update Apply REDO to all write_item operations of committed transactions in log order Restart active transactions Jane Reid, BSc/IT DB, QMUL, 11/3/02

Multi-user deferred update Apply REDO to all write_item operations of committed transactions in log order If data item updated more than once, then only last update need be redone Active transactions that had not committed are cancelled and must be resubmitted Jane Reid, BSc/IT DB, QMUL, 11/3/02

Immediate update Assume that schedules are strict Update operations recorded in disk log at intervals by force-writing Transaction may commit before all changes saved to DB A type of UNDO/REDO algorithm Undo needed Some active transactions may already have had changes saved to DB Redo needed Some committed transactions may not yet have had changes saved to DB Jane Reid, BSc/IT DB, QMUL, 11/3/02

Single-user immediate update UNDO write_item operations of active transaction in reverse log order REDO write_item operations from committed transactions in log order Jane Reid, BSc/IT DB, QMUL, 11/3/02

Multi-user immediate update UNDO write_item operations of active (uncommitted) transactions in reverse log order REDO write_item operations from committed transactions in log order If data item updated more than once, then only last update need be redone Jane Reid, BSc/IT DB, QMUL, 11/3/02