Concurrency Control Dr. Tariq Ahamad 1. Who needs ‘control’? large databases are usually shared – by many users, and resources it is efficient to allow.

Slides:



Advertisements
Similar presentations
Concurrency Control Alexandra Cristea and Steve Russ 1.
Advertisements

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Transaction Management Overview Chapter 16.
TRANSACTION PROCESSING SYSTEM ROHIT KHOKHER. TRANSACTION RECOVERY TRANSACTION RECOVERY TRANSACTION STATES SERIALIZABILITY CONFLICT SERIALIZABILITY VIEW.
Database Systems, 8 th Edition Concurrency Control with Time Stamping Methods Assigns global unique time stamp to each transaction Produces explicit.
Jan. 2014Dr. Yangjun Chen ACS Database recovery techniques (Ch. 21, 3 rd ed. – Ch. 19, 4 th and 5 th ed. – Ch. 23, 6 th ed.)
Monday, 08 June 2015Dr. Mohamed Osman1 What is Database Administration A high level function (technical Function) that is responsible for ► physical DB.
10 1 Chapter 10 Transaction Management and Concurrency Control Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel.
Transaction Management and Concurrency Control
Transaction Management and Concurrency Control
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 10 Transaction Management and Concurrency Control.
What is a Transaction? Logical unit of work
Chapter 8 : Transaction Management. u Function and importance of transactions. u Properties of transactions. u Concurrency Control – Meaning of serializability.
Transaction Management
1 Transaction Management Database recovery Concurrency control.
DBMS Functions Data, Storage, Retrieval, and Update
Dec 15, 2003Murali Mani Transactions and Security B term 2004: lecture 17.
9 Chapter 9 Transaction Management and Concurrency Control Hachim Haddouti.
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 10 Transaction Management and Concurrency Control.
Transaction Management WXES 2103 Database. Content What is transaction Transaction properties Transaction management with SQL Transaction log DBMS Transaction.
Transaction Management and Concurrency Control
Transactions and Recovery
Transaction Management Chapter 9. What is a Transaction? A logical unit of work on a database A logical unit of work on a database An entire program An.
Academic Year 2014 Spring. MODULE CC3005NI: Advanced Database Systems “DATABASE RECOVERY” (PART – 1) Academic Year 2014 Spring.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Transaction Management Overview Chapter 16.
1 Transaction Management Overview Chapter Transactions  Concurrent execution of user programs is essential for good DBMS performance.  Because.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Transaction Management Overview Chapter 16.
1 Transaction Management Overview Chapter Transactions  A transaction is the DBMS’s abstract view of a user program: a sequence of reads and writes.
Database Management Systems, 2 nd Edition. R. Ramakrishnan and J. Gehrke1 Transaction Management Overview Chapter 18.
1 Database Systems CS204 Lecture 21 Transaction Processing I Asma Ahmad FAST-NU April 7, 2011.
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.
Database Management Systems, 2 nd Edition. R. Ramakrishnan and J. Gehrke1 Transaction Management Overview Lecture 21 Ramakrishnan - Chapter 18.
PMIT-6102 Advanced Database Systems
Chapter 15 Recovery. Topics in this Chapter Transactions Transaction Recovery System Recovery Media Recovery Two-Phase Commit SQL Facilities.
Database Systems/COMP4910/Spring05/Melikyan1 Transaction Management Overview Unit 2 Chapter 16.
1 IRU Concurrency, Reliability and Integrity issues Geoff Leese October 2007 updated August 2008, October 2009.
1 Transaction Management Overview Chapter Transactions  Concurrent execution of user programs is essential for good DBMS performance.  Because.
Concurrency Control in Database Operating Systems.
11/7/2012ISC329 Isabelle Bichindaritz1 Transaction Management & Concurrency Control.
Concurrency Control. Objectives Management of Databases Concurrency Control Database Recovery Database Security Database Administration.
Chapter 15 Recovery. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.15-2 Topics in this Chapter Transactions Transaction Recovery System.
Transactions and Locks A Quick Reference and Summary BIT 275.
II.I Selected Database Issues: 2 - Transaction ManagementSlide 1/20 1 II. Selected Database Issues Part 2: Transaction Management Lecture 4 Lecturer: Chris.
The Relational Model1 Transaction Processing Units of Work.
Database Systems Recovery & Concurrency Lecture # 20 1 st April, 2011.
Chapter 10 Recovery System. ACID Properties  Atomicity. Either all operations of the transaction are properly reflected in the database or none are.
Section 06 (a)RDBMS (a) Supplement RDBMS Issues 2 HSQ - DATABASES & SQL And Franchise Colleges By MANSHA NAWAZ.
Academic Year 2014 Spring. MODULE CC3005NI: Advanced Database Systems “DATABASE RECOVERY” (PART – 2) Academic Year 2014 Spring.
Transaction Management Transparencies. ©Pearson Education 2009 Chapter 14 - Objectives Function and importance of transactions. Properties of transactions.
Transactions.
1 Advanced Database Concepts Transaction Management and Concurrency Control.
Transaction Management and Recovery, 2 nd Edition. R. Ramakrishnan and J. Gehrke1 Transaction Management Overview Chapter 18.
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.
10 1 Chapter 10 - A Transaction Management Database Systems: Design, Implementation, and Management, Rob and Coronel.
CREATE THE DIFFERENCE Back ups and Recovery. CREATE THE DIFFERENCE Aims This lecture aims to cover –Back ups –Transaction logging –Security threats.
18 September 2008CIS 340 # 1 Last Covered (almost)(almost) Variety of middleware mechanisms Gain? Enable n-tier architectures while not necessarily using.
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 and Concurrency Control
Transaction Management and Concurrency Control
Transaction Management Overview
Concurrency Control Dr. Tariq Ahamad.
Concurrency.
Chapter 10 Transaction Management and Concurrency Control
Introduction of Week 13 Return assignment 11-1 and 3-1-5
STRUCTURE OF PRESENTATION :
Transaction Management Overview
Presentation transcript:

Concurrency Control Dr. Tariq Ahamad 1

Who needs ‘control’? large databases are usually shared – by many users, and resources it is efficient to allow concurrent access. 2

Relevant Concepts for Concurrency Control integrity : consistency and correctness security : ensuring users only do what they are allowed recovery : return after an error to a known correct state ISSUE: Concurrent access endangers each of these !!! 3

Integrity 4

Database Integrity Domains Constraints Entity/referential integrity Assertions 5

Four Types of Integrity Rule Domain Rules: Give legal values for domains. Attribute Rules: Give legal values for attributes. Relation Rules: Rules governing single relations (e.g., Primary keys must be unique and Non-NULL) Database Rules: Rules governing interrelationships between relations (e.g., Foreign Keys must be Primary keys - and therefore Non-NULL). SQL provides ways of defining these Rules or Constraints. 6

Domains and Constraints Defining constrains outside the CREATE TABLE data definition: CREATE DOMAIN domain_name [AS] data_type [DEFAULT default_option] [CHECK (search_condition)] CREATE DOMAIN sex_type AS CHAR CHECK (VALUE IN (‘M’, ‘F’)) Names of types are reusable. 7

Entity Integrity Entity integrity enforced by naming PRIMARY KEY (i.e., attribute or set of attributes which should be NOT NULL and UNIQUE). E.g.: CREATE TABLE staff( staff# number (3), name char(30), PRIMARY KEY staff#); For alternate keys can use NOT NULL and UNIQUE qualifiers after column attribute name. E.g.: CREATE TABLE fruit( name char(30) PRIMARY KEY, supplier char(20) NOT NULL, country char(20) NOT NULL, UNIQUE (supplier, country)); 8

Referential Integrity defined by FOREIGN KEY or REFERENCES. Referential action must allow cascading of updates from parent to child table (+deletes, NULL value, DEFAULT). E.g.: CREATE TABLE emps( emp# number(2), name char(30), dept# number(2) REFERENCES dept ON UPDATE CASCADE); 9

Assertions CREATE ASSERTION assertion_name CHECK (search condition) CREATE ASSERTION daycheck CHECK ( (day>0) and (day<= (select DM.day from daysinmonth DM where DM.month=month)) Named rules like this are database/ enterprise wide. 10

Oracle SQL Limitations Note that Oracle 10g 2 does not implement all ISO SQL Integrity Enhancement Features (IEF). – Domains cannot be defined outside CREATE TABLE. – Referential action restricted to ON DELETE CASCADE or NO ACTION. – Table check constraints can only refer to attributes within a table. – Named assertions cannot be defined. 11

Note: Integrity is not Security. Integrity ensures that the things the users are trying to do are correct. Security ensures that things users are doing are only what they are allowed to do. 12

Security 13

Security vs. Integrity Integrity: Ensuring what users are trying to do is correct. Security: Ensuring users are allowed to do things they are trying to do. Both require rules that users must not violate. 14

Database Security Approaches 1.Discretionary Control: Named users, Privileges or access rights to data objects. Distributed control. 2.Mandatory Control: Users have Clearance, Objects have classification levels. Central control. 15

Security Mechanisms Security sub-systems which checks IDs against security rules. 16

17 SQL Syntax for Security Rules GRANT [privilege-commalist | ALL PRIVILEGES] ON object-name TO [authorisation_id_list | PUBLIC] [WITH GRANT OPTION] Each privilege is one of the following: SELECT DELETE INSERT [ (attribute-commalist)] UPDATE [ (attribute-commalist) ] REFERENCES [ (attribute-commalist) ] The REFERENCES allows privileges to be granted on named table(s) in integrity constraints of CREATE TABLE. The GRANT OPTION allows the named users to pass the privileges on to other users.

Audit Trails We can’t assume that security will be perfect, i.e. someone might gain unauthorised access. Audit Trails area logs which can track down the infiltrators. Audit trails will contain entries of the form: request (source text) location (physical e.g. terminal id) user id date/ time relations affected (base, tuple, attribute) old-values new-values Knowing that there is an audit trail may deter security hacks. 18

19 Grant and Revoke If a user A grants privileges to user B, then they can also revoke them e.g. REVOKE ALL PRIVILEGES ON STATS FROM John; SQL REVOKE syntax REVOKE [GRANT OPTION FOR] [privilege_list | ALL PRIVILEGES] ON object_name FROM [authorisation_list|PUBLIC] [RESTRICT|CASCADE] If RESTRICT option is given then the command is not executed if any dependent rules exist i.e. those created by other users through the WITH GRANT OPTION. CASCADE will force a REVOKE on any dependent rules.

Security Summary A DBMS security-subsystem enforces security Access is checked against security rules Discretionary control rules have a users, privileges and objects Mandatory controls have clearance and classification levels Audit trails are used to record attempted security breaches GRANT/ REVOKE syntax in SQL We have not dealt with data-encryption, which deals with the storing and transmission of sensitive data. 20

Recovery 21

Recovery Restoring a database to a known correct state after some failure. Database recovery is based on redundancy at the physical level. – Any piece of information can be recovered from some other stored information, somewhere else. 22

Transactions A transaction is a logical unit of work, as well as unit of recovery. It is broken down into a sequence of atomic operations, which if any fail, the whole transaction is undone. SELECT | INSERT | … … … work … … COMMIT | ROLLBACK 23

Transactions series of database commands w clear semantics – e.g. transfer of funds from one account to another Commit: If nothing fails commit point where the DB should be consistent. All updates are tentative until committed. Rollback: If any command fails => whole series is undone. Any DBMS support these (and lang. e.g. SQL) 24

Transaction Example BEGIN TRANSACTION UPDATE ACC123 {BALANCE := BALANCE - £100} IF any error occurred THEN GO TO UNDO; END IF; UPDATE ACC456 {BALANCE := BALANCE + £100} IF any error occurred THEN GO TO UNDO; END IF; COMMIT; GO TO FINISH;/*successful end*/ UNDO: ROLLBACK;/*unsuccessful end*/ FINISH: RETURN; 25

Transaction Properties Atomicity: all or nothing (any error => Rollback, as if nothing happened) Consistency: a consistent state always leads to another consistent state Isolation: a transaction’s updates are hidden until it Commits Durability: after a Commit, updates persist These are the ACID properties of transactions. 26

System Recovery How does the system recover after a system failure (e.g., power failure) or media failure (e.g., disk crash)? In the event of a crash … – Contents of main memory are lost. – Transaction log persists. – At failure, certain transactions will be complete while others part complete. Note that updates are held in memory buffers and written out periodically. 27

Recovery To recover the state of the database we can use: A log file recording every database operation. Checkpoints recording the state of all active transactions. – Then: develop an algorithm for transactions to UNDO, – and those that we need to REDO, to effect recovery. – at intervals, the system will: Flush its buffers Write out a checkpoint record to log indicating which transactions are in progress. 28

Five Transaction categories The most recent check point record was taken at time tc. Time tc tf Transactions T1 T2 T3 T4 T5 System failure (time tf) Checkpoint (time tc) 29

CompletedUn-Finished Cached Written T2 T1 T4 T3 T5 30

CHECKPOINT RECORD: – T3, T5 : undone (rollback possible) – T2, T4 : re-done DBMS creates REDO/UNDO list from checkpoint record + system log. isolation => – order of recovery not crucial, – only DB should be consistent near tf. 31

Concurrency 32

Concurrency Many transactions - at the same time. Databases shared! So: Transactions must be isolated => need of concurrency control to ensure no interference. We will look at: – 3 classic problems on concurrent access – Locking mechanism – Deadlock resolution 33

Three classic problems PB: two (more) transactions read / write on the same part of the db. Although transactions execute correctly, results may interleave in diff ways => 3 classic problems. Lost Update Uncommitted Dependency Inconsistent Analysis 34

Lost Update problem Time User 1 (Trans A) User2 (Trans B) 1Retrieve t 2 3Update t t : tuple in a table. Trans A loses an update at t4. The update at t3 is lost (overwritten) at t4 by B. 35

Uncommitted Dependency TimeUser 1 (Trans A)User 2 (Trans B) 1Update t 2Retrieve t 3Rollback 4 5 6Update t 7 8Rollback 2 PBs (T1-3 ; T6-8). One trans is allowed to retrieve/update) a tuple updated by another, but not yet committed. Trans A is dependent at time t2 on an uncommitted change made by Trans B, which is lost on Rollback. 36

Inconsistent Analysis TimeUser 1 (Trans A)User 2 (Trans B) 1Retrieve Acc 1 : Sum = 40 2Retrieve Acc2 : Sum = 90 3Retrieve Acc3 : 4Update Acc3: 30 → 20 5Retrieve Acc1: 6Update Acc1: 40 → 50 7commit 8Retrieve Acc3: Sum = 110 (not 120) Initially: Acc 1 = 40; Acc2 = 50; Acc3 = 30; Trans A sees inconsistent DB state after B updated Accumulator => performs inconsistent analysis. 37

Why these problems? Retrieve : ‘read’ (R) Update : ‘write’ (W). interleaving two transactions => 3 PBS: RR – no problem WW – lost update WR – uncommitted dependency RW – inconsistent analysis 38

How to prevent such problems? locking protocol – Other approaches : serializability, time-stamping, and shadow-paging. See books. IF risk of interference = low => two-phase locking ~ common approach – although it requires deadlock avoidance!! Lock applies to a tuple : – exclusive (write; X) or – shared(read; S). 39

Lost Update ‘solved’ Time User 1 (Trans A) User2 (Trans B) 1Retrieve t (get S-lock on t) 2 3Update t (request X-lock on t) 4waitUpdate t (request X-lock on t) 5wait 6 7 No update lost but => deadlock 40

Uncommitted Dependency solved TimeUser 1 (Trans A)User 2 (Trans B) 1Update t (get X-lock on t) 2Retrieve t (request S-lock on t)- 3wait Commit / Rollback (releases X-lock on t) 6Resume: Retrieve t (get S-lock on t)

Inconsistent Analysis ‘solved’ TimeUser 1 (Trans A)User 2 (Trans B) 1Retrieve Acc1 : (get S-lock) Sum = 40 2Retrieve Acc2 : (get S-lock) Sum = 90 3Retrieve Acc3: (get S-lock) 4Update Acc3: (get X-lock) 30 → 20 5Retrieve Acc1: (get S-lock) 6Update Acc1: (request X-lock) wait 7Retrieve Acc3: (request S-lock) wait 42

Deadlock Deadlock occurs when 2 or more transaction are in a simultaneous wait state. It is desirable to conceal deadlocks from the user. 43

Deadlock Resolution The system must detect and break deadlocks by: 1.Choosing one trans as a victim and rolling it back. 2.Timing out the trans and returning an error. 3.automatically restarting the transaction hoping not to get deadlock again. 4.Return an error code back to the victim and leaving it up to program to handle situation.. 44

Topics covered: Integrity – Domains, Constraints, Entity/referential integrity, assertions Security – Discretionary, mandatory, audit trails Recovery – Transactions, ACID properties Concurrency Control – Lost update, uncommitted dependency, inconsistent analysis, deadlock 45

Questions? 46