Understanding Isolation Levels and Locking

Transcription

1 Platform: DB2 UDB for Linux, UNIX, and Windows Understanding Isolation Levels and Locking Roger E. Sanders Network Appliance, Inc. Global Systems Engineer Session: G10 Wednesday, 26 October :00 AM to 12:00 PM Title: Understanding Isolation Levels and Locking Abstract: Individuals who have taken the DB2 Family Fundamentals (700) exam often tell me they received their lowest scores on the section that covers isolation levels and locking. This implies that these two concepts remain a mystery to a large number of DB2 users. This presentation is designed to take away the mystery and replace it with a solid understanding of the components DB2 UDB uses to make database concurrency possible. Roger E. Sanders Global Systems Engineer Network Appliance, Inc. 627 Davis Drive, Suite 200 Morrisville, NC Phone: (919) rsanders@netapp.com 1

2 Topics To Be Discussed... Data consistency and database concurrency What isolation levels are and how they are used What locks are and how they are used Locks and performance Designing databases and applications with locking in mind 2 Presentation Outline: I. Data consistency and database concurrency A. Understanding data consistency B. Transactions C. Phenomena seen when transactions run concurrently D. Designing for concurrency II. Isolation levels A. Repeatable Read (RR) B. Read Stability (RS) C. Cursor Stability (CS) D. Uncommitted Read (UR) E. Choosing the proper isolation level F. Specifying the isolation level to use III. Locks A. What is a lock? B. Lock attributes C. Lock states D. How locks are acquired IV. Locks and performance A. Lock compatibility B. Lock waits and timeouts C. Lock conversion D. Lock escalation E. Deadlocks F. Lock granularity 2

3 Data Consistency And Database Concurrency Allowing multiple users to access a database simultaneously without compromising data integrity. 3 Let s get started by taking a look at what can happen when several different users attempt to access a database at the same time. 3

4 Understanding Data Consistency RESTAURANT A RESTAURANT B BEFORE UPDATE: Actual - 4 bottles; Database - 4 bottles AFTER UPDATE: Actual - 4 bottles; Database - 5 bottles 4 What Is Data Consistency? The best way to define data consistency is by example. Suppose your company owns a chain of restaurants, and you have a database that is designed to keep track of supplies stored at each of those restaurants. This database contains an inventory table for each restaurant in the chain and whenever supplies are received or used by a restaurant, the inventory table for that particular restaurant is updated. Now, suppose some bottles of catsup are physically moved from one restaurant to another. The catsup bottle count value stored in the receiving restaurant s table needs to be raised and the catsup bottle count value stored in the donating restaurant s table needs to be lowered in order to accurately represent this inventory move. If a user raises the catsup bottle count in the receiving restaurant s inventory table, but fails to lower the catsup bottle count in the donating restaurant s inventory table, the data will become inconsistent. Now, the total catsup bottle inventory for the chain of restaurants is no longer accurate. A database can become inconsistent if the database user forgets to make all the necessary changes (as in the previous example), if the system crashes when the user is in the middle of making changes, or if a database application, for some reason, stops prematurely. Inconsistency can also occur when several users are accessing the same database tables at the same time. For example, one user might read another user s changes before all tables have been properly updated and make an inappropriate change based on the premature data values read. Note: This slide looks a little confusing in a printout because of the way it has been constructed for animation. Refer to the slide shown in the presentation for clarity. 4

5 Transactions A transaction (or unit of work) is a recoverable sequence of one or more SQL operations that are grouped together as a single unit, usually within an application process. Transaction types: Interleaved or Parallel Serializable* *Ideally, all transactions should be serializable 5 One of the mechanisms DB2 UDB uses to keep data consistent is the transaction. A transaction or (otherwise known as a unit of work) is a recoverable sequence of one or more SQL operations that are grouped together as a single unit, usually within an application process. The initiation and termination of a single transaction defines points of data consistency within a database; either the effects of all SQL operations performed within a transaction are applied to the database and made permanent (committed), or the effects of all SQL operations performed are completely "undone" and thrown away (rolled back). In single-user environments, each transaction runs serially and does not have to contend with interference from other transactions. However, in multi-user environments, transactions can run simultaneously and each transaction has the potential to interfere with any other active transaction. Transactions that have the potential of interfering with one another are said to be interleaved or parallel transactions while transactions that run isolated from each other are said to be serializable, which means that the results of running them simultaneously will be no different from the results of running them one right after another (serially). Ideally, every transaction should be serializable. Why is it important that transactions be serializable? Consider the following: Suppose a salesperson is entering orders into a database system at the same time an accountant is using the system to generate bills. Now, suppose the salesperson enters an order for Company X (to get a price quote) but does not commit the entry. While the salesperson is relaying the price quote information to an individual from Company X, the accountant queries the database for a list of all unpaid orders, sees an unpaid order for Company X, and generates a bill. Now, suppose the individual from Company X decides not to place the order because the quoted price is higher than expected. The salesperson rolls back the transaction because no order was placed, and the order information used to produce the price quote is removed from 5

6 Phenomena Seen When Transactions Run Concurrently Lost Updates Dirty Reads Non-repeatable Reads Phantoms 6 When transactions are not isolated from each other in multi-user environments, four types of events, or phenomena, can occur: Lost Updates Dirty Reads Non-repeatable Reads Phantoms 6

7 Lost Updates Occurs when two transactions read the same data, both attempt to update the data read, and one of the updates is lost Never occurs with DB2 UDB 7 Lost Updates This event occurs when two transactions read the same data, both then attempt to update that data, and one of the updates is lost. For example: Transaction 1 and Transaction 2 read the same row of data and both calculate new values for that row based upon the original values read. If Transaction 1 updates the row with its new value and Transaction 2 then updates the same row, the update operation performed by Transaction 1 is lost. Fortunately, DB2 UDB has been designed in such a way that this type of event cannot occur. 7

8 Dirty Reads Occurs when a transaction reads data that has not yet been committed Only happens in special cases with DB2 UDB (specifically, when a transaction is running under the Uncommitted Read isolation level) 8 Dirty Reads This event occurs when a transaction reads data that has not yet been committed. For example: Transaction 1 changes a row of data and Transaction 2 reads the changed row before Transaction 1 commits the change. If Transaction 1 rolls back the change, Transaction 2 will have read data that theoretically, never existed. 8

9 Non-Repeatable Reads Occurs when a transaction executes the same query multiple times and gets different results with each execution Only happens in special cases with DB2 UDB (specifically, when a transaction is running under the Read Stability or Cursor Stability isolation level) 9 Non-Repeatable Reads This event occurs when a transaction reads the same row of data twice, but gets different results each time. For example: Transaction 1 reads a row of data, then Transaction 2 modifies or deletes that row and commits the change. When Transaction 1 attempts to reread the row, it will retrieve different data values (if the row was updated) or discover that the row no longer exists (if the row was deleted). 9

10 Phantoms Occurs when a row of data that matches some search criteria is not seen initially Can happen often with DB2 UDB (specifically, anytime a transaction is running under any isolation level other than the Repeatable Read isolation level) 10 Phantoms This event occurs when a row of data matches some search criteria, but initially is not seen. For example: Transaction 1 retrieves a set of rows that satisfy some search criteria, then Transaction 2 inserts a new row that contains matching search criteria for Transaction 1 s query. If Transaction 1 re-executes the query that produced the original set of rows, a different set of rows will be retrieved the new row added by Transaction 2 will now be included in the set of rows returned. 10

11 Things To Consider When Designing For Concurrency How can data consistency be maintained when you do not know what actions a user wants to perform? How can you keep an application from accidentally destroying data consistency? How can you ensure that applications working with a database simultaneously will not inadvertently destroy data consistency? 11 Maintaining data consistency and integrity, while allowing multiple transactions to access the same data at the same time, is known as concurrency. When designing for concurrency, database product developers must consider the following: How can you maintain data consistency at all times when you do not know what action each individual database owner/user wants to perform? How can you keep a single application from accidentally destroying data consistency? How can you ensure that multiple applications, accessing the same data at the same time, will not destroy data consistency? 11

12 DB2 UDB s Concurrency Support Mechanisms Isolation levels Locks 12 In response to these questions, two different data consistency support mechanisms were incorporated into DB2 Universal Database s design. These two mechanisms are known as isolation levels and locks. We ll look at each in the following sections. 12

13 Isolation Levels How transactions are isolated from each other in multi-user environments. 13 Now that you know what database concurrency is and are familiar with what can happen when two or more transactions attempt to work with the same data resource at the same time, let s look at how the first mechanism DB2 UDB uses to provide concurrency support isolation levels works. 13

14 Isolation Levels Available Repeatable Read (RR) Read Stability (RS) Cursor Stability (CS) Uncommitted Read (UR) Most Restrictive Least Restrictive 14 One of the ways DB2 Universal Database attempts to enforce concurrency is through the use of isolation levels, which determine how a data resource used in one transaction is isolated from other transactions while it is being accessed. DB2 Universal Database recognizes and supports the following isolation levels: Repeatable Read Read Stability Cursor Stability Uncommitted Read 14

15 Repeatable Read Completely isolates one transaction from the effects of other transactions Prevents lost updates, dirty reads, non-repeatable reads, and phantoms Locks all rows accessed by the transaction (often acquires table-level locks when an index scan is performed) (If a transaction using RR scans the same table two or more times, the results will always be the same.) 15 Repeatable Read The Repeatable Read isolation level completely isolates one transaction from the effects of other, concurrent transactions. When this isolation level is used, every row that is referenced in any manner by the isolated transaction is locked for the duration of that transaction. As a result, if the same SELECT statement is issued two or more times within the same transaction, the result data set produced will always be the same; lost updates, dirty reads, non-repeatable reads, and phantoms cannot occur. Transactions using the Repeatable Read isolation level can retrieve the same set of rows multiple times and perform any number of operations on them until terminated, either by a commit or a rollback operation. However, no other transaction is allowed to perform an insert, update, or delete operation that would affect the set of rows being accessed by the isolating transaction while that transaction remains active. To ensure that the data being accessed by a transaction running under the Repeatable Read isolation level is not adversely affected by other transactions, each row referenced by the isolating transaction is locked -- not just the rows that are actually retrieved and/or modified. Thus, if a transaction scans 1000 rows in order to retrieve 10, locks are acquired and held on all 1000 rows scanned -- not just on the 10 rows retrieved. 15

16 Repeatable Read (Continued) 16 So how does this isolation level work in a real-world situation? Suppose you own a large hotel and you have a web site that allows individuals to reserve rooms on a first-come, first-served basis. If your hotel reservation application runs under the Repeatable Read isolation level, whenever a customer retrieves a list of all rooms available for a given range of dates, you will not be able to change the room rate for those rooms during the date range specified, nor will other customers be able to make or cancel reservations that would cause the list to change if it were generated again -- as long as the transaction that produced the list is active. (However, you can change room rates for any room that was not scanned in response to the first customer's query. Likewise, other customers can make or cancel room reservations for any room that was not scanned in response to the first customer's query.) 16

17 Read Stability Does not completely isolate transactions from each other Prevents lost updates, dirty reads, and non-repeatable reads; allows phantoms Only locks rows returned to a result data set in response to a query (If a transaction using RS scans the same table two or more times, the results may reflect changes made by other transactions.) 17 Read Stability The Read Stability isolation level does not completely isolate one transaction from the effects of other, concurrent transactions. That s because when the Read Stability isolation level is used, only rows that are actually retrieved by a single transaction are locked for the duration of that transaction. Thus, when this isolation level is used, if the same SELECT statement is issued two or more times (within the same transaction), the result data set produced may not always be the same. (Lost updates, dirty reads, and non-repeatable reads cannot occur; phantoms, however, can and may be seen.). Transactions using the Read Stability isolation level can retrieve a set of rows and perform any number of operations on them until terminated, either by a commit or a rollback operation. However, no other transaction is allowed to perform an update, or delete operation that would affect the set of rows that were retrieved by the isolating transaction as long as that transaction exists. (However, other transactions can perform insert operations and if the transaction running under the Read Stability isolation level executes the same query multiple times, rows inserted by other, concurrent transactions may appear in subsequent result data sets produced.) Changes made to other rows by other transactions will not be seen by a transaction running under the Read Stability isolation level until they have been committed. Unlike the Repeatable Read isolation level where every row that is referenced in any way by the isolating transaction is locked, when the Read Stability isolation level is used, only the rows that are actually retrieved and/or modified by the isolating transaction are locked. Thus, if a transaction scans 1000 rows in order to retrieve 10, locks are only acquired and held on the 10 rows retrieved -- not on all 1000 rows scanned. 17

18 Read Stability (Continued) 18 So how does this isolation level change the way our hotel reservation application works? Now, when a customer retrieves a list of rooms available for a given range of dates, you will be able to change the room rate for any room in the hotel that does not appear on the list and other customers will be able to cancel room reservations for rooms that had been reserved for the date range specified by the first customer's query. Therefore, if the customer generates the list of available rooms again (before the transaction that submitted the query terminates), the list produced may contain new room rates and/or rooms that were not available the first time the list was generated. 18

19 Cursor Stability Limited in the way it isolates transactions from each other Prevents lost updates and dirty reads; allows non-repeatable reads and phantoms Locks one row at a time the row that is currently being accessed by an open cursor Isolation level used by default (If a transaction using CS scans the same table two or more times, the results can reflect changes made by other transactions.) 19 Cursor Stability The Cursor Stability isolation level is even more relaxed in the way it isolates one transaction from the effects of other, concurrent transactions. When this isolation level is used, only the row that is currently being referenced by a cursor that has been declared and opened by the isolating transaction is locked. The lock acquired remains in effect either until the cursor is repositioned (usually by executing the FETCH SQL statement) or until the isolating transaction terminates. (If the cursor is repositioned, the lock being held on the last row read is released and a new lock is acquired for the row the cursor is now positioned on.). When a transaction using the Cursor Stability isolation level retrieves a row from a table using a cursor, no other transaction can update or delete that row while the cursor is positioned on it. However, other transactions can add new rows to the table as well as perform update and/or delete operations on rows positioned on either side of the locked row, provided the locked row itself was not accessed using an index. Furthermore, if the isolating transaction modifies any row it retrieves, no other transaction can update or delete that row until the isolating transaction is terminated, even when the cursor is no longer positioned on the modified row. When the Cursor Stability isolation level is used, if the same SELECT statement is issued multiple times within the same transaction, the results returned may not always be the same. (Lost updates and dirty reads cannot occur; non-repeatable reads and phantoms, on the other hand, can and may be seen.) In addition, transactions using the Cursor Stability isolation level will not see changes made to other rows by other transactions until those changes have been committed. 19

20 Cursor Stability (Continued) 20 So how does this isolation level change the way our hotel reservation application works? Now, when a customer retrieves a list of rooms available for a given range of dates, then views information about each room on the list produced (one room at a time), you will be able to change the room rate for any room in the hotel, over any date range, except for the room the customer is currently looking at. Likewise, other customers will be able to make or cancel reservations for any room in the hotel, over any date range; however, they will not be able to do anything with the room the first customer is currently looking at. When the first customer views information about another room in the list, the same holds true for the new room the customer is looking at. 20

21 Uncommitted Read Does not isolate a transaction from the effects of other transactions Prevents lost updates; allows dirty reads, non-repeatable reads, and phantoms Usually does not acquire locks during processing (A transaction using UR can access uncommitted changes made by other transactions.) 21 Uncommitted Read The Uncommitted Read isolation level is the least intrusive isolation level provided. In fact, when the Uncommitted Read isolation level is used, rows that are retrieved by one transaction are only locked if another transaction attempts to drop or alter the table the rows were retrieved from. Because rows often remain unlocked when this isolation level is used, dirty reads, non-repeatable reads, and phantoms can occur. Because of this, this isolation level is commonly used for transactions that access read-only tables/views or transactions that execute SELECT statements of which uncommitted data from other transactions will have no adverse affect. In most cases, transactions using the Uncommitted Read isolation level can read changes made to rows by other transactions before those changes have been committed. However, such transactions can neither see nor access tables, views, or indexes that are created by other transactions until those transactions themselves have been terminated. The same applies to existing tables, views, or indexes that have been dropped transactions using the Uncommitted Read isolation level will only learn that these objects no longer exist when the transaction that dropped them is terminated. There is one exception to this behavior: when a transaction running under the Uncommitted Read isolation level uses an updatable cursor; in this particular case, the transaction using the updatable cursor will behave as if it is running under the Cursor Stability isolation level and the constraints of the Cursor Stability isolation level will apply. 21

22 Uncommitted Read (Continued) 22 So how does the Uncommitted Read isolation level affect our hotel reservation application? Now, when a customer retrieves a list of rooms available for a given range of dates, you will be able to change the room rate for any room in the hotel and other customers will be able to make or cancel reservations for any room, over any date range. Furthermore, the list produced for the first customer may contain rooms that other customers have chosen to make reservations for, but whose reservations have not yet been committed. 22

23 Choosing The Proper Isolation Level Use Repeatable Read when preventing phenomena is more important than concurrency Use Read Stability when concurrency is desired, but qualified rows need to remain stable for the life of a transaction Use Cursor Stability when you need maximum concurrency, yet do not want to see uncommitted data Use Uncommitted Read when working with read-only tables/databases 23 Choosing the appropriate isolation level to use is very important because not only does the isolation level used influence how well the database supports concurrency, it also controls how well all applications running concurrently perform. Typically, whenever a more restrictive isolation level is used, less concurrency is available. So how do you determine which isolation level to use for a given application? The best way is to determine which types of concurrency phenomena that might arise is unacceptable; then, select an isolation level that will prevent those types of phenomena from occurring. For example: Use the Repeatable Read isolation level if you are executing queries and you do not want other, concurrent transactions to have the ability to make changes that could cause the same query to return different results if ran more than once. Use the Read Stability isolation level when you want some level of concurrency between applications, yet you also want qualified rows to remain stable for the duration of an individual transaction. Use the Cursor Stability isolation level when you want maximum concurrency between applications, yet you do not want queries to return uncommitted data values. Use the Uncommitted Read isolation level if you are executing queries on readonly tables/databases, or if you do not care if a query returns uncommitted data values. 23

24 Specifying the Isolation Level to Use The ISOLATION option of the PRECOMPILE and BIND commands (Embedded SQL) The SQL_ATTR_TXN_ISOLATION ODBC/CLI connection attribute (ODBC/CLI) The settransactionisolation()jdbc method (JDBC) The CHANGE ISOLATION command (CLP Scripts) The WITH [RR RS CS UR] option of a SELECT statement 24 Although isolation levels control concurrency at the transaction level, they are actually set at the application level. Therefore, in most cases, the isolation level specified for a particular application is applicable to every transaction that is initiated by that application. (An application can be constructed in several different parts and each part can be assigned a different isolation level, in which case, the isolation level specified for a particular part is applicable to every transaction that is created within that part.) For embedded SQL applications, the isolation level to be used is specified at precompile time or when the application is bound to a database (if deferred binding is used). The isolation level for embedded SQL applications is set through the ISOLATION option of the PRECOMPILE and BIND commands. The isolation level for Open Database Connectivity (ODBC) and Call Level Interface (CLI) applications is set at application run time by calling the SQLSetConnectAttr() function with the SQL_ATTR_TXN_ISOLATION connection attribute specified. Alternatively, the isolation level for ODBC/CLI applications can be set by assigning a value to the TXNISOLATION keyword in the db2cli.ini configuration file; however, this approach does not provide the flexibility of changing isolation levels for different transactions within the application that the first approach does. The isolation level for JDBC and SQLJ applications is set at application run time by calling the settransactionisolation() method that resides within DB2 Universal Database s java.sql connection interface. When the isolation level for an application is not explicitly set using one of these methods, the Cursor Stability isolation level is used as the default. This is true for commands, SQL statements, and scripts that are executed from the Command Line Processor (CLP) as well as for embedded SQL, ODBC/CLI, JDBC, and SQLJ applications. Therefore, it is also possible to specify the isolation level that is to be used for any operation that is to be performed from the CLP. In this case, the isolation level is set by executing the CHANGE ISOLATION command before a connection to a database is established. Wi h V i 8 1 h bili if h i l i l l h SELECT 24

25 Locks What locks are and how they are used. 25 Now that you know what isolation levels are and you have some idea about how the isolation level used can impact concurrency, let s look at how the second mechanism DB2 UDB uses to provide concurrency support locks works. 25

26 What Is A Lock? A lock is a mechanism that is used to associate a data resource with a single transaction, for the sole purpose of controlling how other transactions interact with that resource while it is associated with the transaction that has it locked. 26 Locks Just what is a lock? A lock is a mechanism that is used to associate a data resource with a single transaction, for the sole purpose of controlling how other transactions interact with that resource while it is associated with the transaction that has it locked. (The transaction that has a resource associated with it is said to hold or own the lock.) Essentially, locks in a database environment serve the same purpose as they do in a house or a car; they determine who can and cannot gain access to a particular resource which in this case is one or more tablespaces, tables, and/or rows. The DB2 Database Manager imposes locks to prohibit owning transactions from accessing uncommitted data that has written by other transactions (unless the transaction is running under the Uncommitted Read isolation level) and to prevent other transactions from making data modifications that might adversely affect the owning transaction. When an owning transaction is terminated (by being committed or by being rolled back), any changes made to the resource that was locked are made permanent (or removed), and all locks on the resource that had been acquired by the owning transaction are released. Once unlocked, a resource can be locked again and manipulated by any other active transaction. 26

27 Lock Attributes Object (Tablespaces, Tables, Rows) Size (Number of rows locked, table locked) Duration (Length of time lock is held) State (or Mode) (Type of lock acquired) 27 All DB2 Universal Database locks have the following basic attributes: Object This attribute identifies the data resource that is being locked. The DB2 Database Manager implicitly acquires locks on data resources (specifically, tablespaces, tables, and rows) whenever they are needed. Size This attribute identifies the physical size of the portion of the data resource that is being locked. A lock does not always have to control an entire data resource. For example, rather than giving an application exclusive control over an entire table, the DB2 Database Manager can elect to give an application exclusive control over one or more specific rows in a table. Duration This attribute identifies the length of time a lock is held. The isolation level used has a significant impact on the duration of a lock. State (or Mode) This attribute identifies the type of access that is allowed for the lock owner as well as the type of access permitted for concurrent users of the locked data resource. 27

28 Lock States Intent None Intent Share Next Key Share Share Intent Exclusive Share With Intent Exclusive Update Next Key Weak Exclusive Exclusive Weak Exclusive Super Exclusive An Intent None lock is the least restrictive lock that can be held; a Super Exclusive lock is the most restrictive lock that can be held. 28 There are eleven different lock states available and the state of the lock used determines the type of access allowed for the lock owner, as well as the type of access permitted to concurrent users of the locked resource. The list on this slide identifies the lock states that are available, in order of increasing control. 28

29 Intent None (IN) Applicable Objects : Tablespaces, Tables Lock Owner : Can read all data including uncommitted data, but cannot modify data stored in the locked resource Other Transactions : Can both read and modify data stored in the locked resource Acquired by read-only transactions that do not convey the intent to modify data. 29 Intent None (IN) When an Intent None (IN) lock is held on a resource, the lock owner is allowed to read, but not modify data, including uncommitted data, stored in the locked resource (which in this case, can be a tablespace or a table). On the other hand, other transactions are allowed to both read and modify data stored in the resource while it is locked. Intent None locks are typically acquired for read-only transactions that have no intention of modifying data (transactions that execute SELECT FOR UPDATE, UPDATE WHERE, and/or INSERT statements convey the intent to modify data). Thus, additional locks will not be acquired on the transaction s behalf. 29

30 Intent Share (IS) Applicable Objects : Tablespaces, Tables Lock Owner : Can read, but cannot modify data stored in the locked resource Other Transactions : Can both read and modify data stored in the locked resource Acquired by non-read-only transactions that do not convey the intent to modify data. 30 Intent Share (IS) When an Intent Share (IS) lock is held on a resource, the lock owner is allowed to read, but not modify data stored in the locked resource (which in this case, can be a tablespace or a table). On the other hand, other transactions are allowed to both read and modify data stored in the resource while it is locked. Intent Share locks are typically acquired for transactions that do not convey the intent to modify data (transactions that execute SELECT FOR UPDATE, UPDATE WHERE, and/or INSERT statements convey the intent to modify data). 30

31 Next Key Share (NS) Applicable Objects : Rows All Transactions : Can read, but cannot modify data stored in the locked resource Acquired by transactions using the RS or CS isolation level that do not convey the intent to modify data. (Used instead of Share locks to minimize impact of locking.) 31 Next Key Share (NS) When a Next Key Share (NS) lock is held on a resource, the lock owner is allowed to read, but not modify data stored in the locked resource (which in this case, must be a row). Likewise, other transactions are allowed to read, but not modify data stored in the resource while it is locked. Next Key Share locks are typically acquired in place of a Share (S) lock for transactions that are running under the Read Stability (RS) or Cursor Stability (CS) isolation level. 31

32 Share (S) Applicable Objects : Tables, Rows All Transactions : Can read, but cannot modify data stored in the locked resource Acquired by transactions using the RR isolation level that do not convey the intent to modify data. 32 Share (S) When an Share (S) lock is held on a resource, the lock owner is allowed to read, but not modify data (excluding uncommitted data) stored in the locked resource (which in this case, can be a table or a row). Likewise, other transactions are allowed to read, but not modify data stored in the resource while it is locked. Share locks are typically acquired for transactions that do not convey the intent to modify data (transactions that execute SELECT FOR UPDATE, UPDATE WHERE, and/or INSERT statements convey the intent to modify data) that are running under the Repeatable Read (RR) isolation level. 32

33 Intent Exclusive (IX) Applicable Objects : Tablespaces, Tables All Transactions : Can both read and modify data stored in the locked resource Acquired by transactions that convey the intent to modify data. 33 Intent Exclusive (IX) When an Intent Exclusive (IX) lock is held on a resource, the lock owner is allowed to both read and modify data stored in the locked resource (which in this case, can be a tablespace or a table). Likewise, other transactions are allowed to read and modify data stored in the resource while it is locked. Intent Exclusive locks are typically acquired for transactions that convey the intent to modify data (transactions that execute SELECT FOR UPDATE, UPDATE WHERE, and/or INSERT statements convey the intent to modify data). When the lock owner works with an Intent Exclusive (IX) locked table, a Share (S) or a Next Key Share (NS) lock is acquired on every row read from that table and an Update (U) or an Exclusive (X) lock is acquired on every row in the table that is to be modified. 33

34 Share With Intent Exclusive (SIX) Applicable Objects : Tables Lock Owner : Can both read and modify data stored in the locked resource Other Transactions : Can read, but cannot modify data stored in the locked resource Acquired by transactions holding a Share lock that need an Intent Exclusive lock (or vice versa). 34 Share With Intent Exclusive (SIX) When a Share With Intent Exclusive (SIX) lock is held on a resource, the lock owner is allowed to both read and modify data stored in the locked resource (which in this case, must be a table). Other transactions, however, are only allowed to read data (except for uncommitted data) stored in the resource while it is locked. Share With Intent Exclusive locks are typically acquired when a transaction holding a Share (S) lock on a resource attempts to acquire an Intent Exclusive (IX) lock on the same resource (or vice versa). 34

35 Update (U) Applicable Objects : Tables, Rows Lock Owner : Can modify, but cannot read data stored in the locked resource Other Transactions : Can read, but cannot modify data stored in the locked resource Acquired by transactions that modify, but do not retrieve data. 35 Update (U) When an Update (U) lock is held on a resource, the lock owner is allowed to modify, but not read data stored in the locked resource (which in this case, can be a table or a row). Other transactions, however, are allowed to read, but not modify data (except for uncommitted data) stored in the resource while it is locked. Update locks are typically acquired for transactions that modify data with INSERT, UPDATE, and/or DELETE statements. 35

36 Next Key Weak Exclusive (NW) Applicable Objects : Rows All Transactions : Can read, but cannot modify data stored in the locked resource Acquired on the next available row in a table when a row is added to a non-catalog table index. 36 Next Key Weak Exclusive (NW) When a Next Key Weak Exclusive (NW) lock is held on a resource, the lock owner is allowed to read, but not modify data stored in the locked resource (which in this case, must be a row). Likewise, other transactions are allowed to read, but not modify data stored in the resource while it is locked. Next Key Weak Exclusive locks are typically acquired on the next available row in a table whenever a row is inserted into any index of a non-catalog table. 36

37 Exclusive (X) Applicable Objects : Tables, Rows Lock Owner : Can both read and modify data stored in the locked resource Other Transactions : Can neither read nor modify data stored in the locked resource unless UR isolation level is used (in which case data can be read) Acquired when a transaction both reads and modifies data. 37 Exclusive (X) When an Exclusive (X) lock is held on a resource, the lock owner is allowed to both read and modify data stored in the locked resource (which in this case, can be a table or a row). Other transactions, however, are not allowed to read nor modify data stored in the resource while it is locked unless the are running under the Uncommitted Read (UR) isolation level (in which case, they can read but cannot modify data stored in the locked resource). Exclusive locks are typically acquired for transactions that retrieve data with SELECT statements and modify data with INSERT, UPDATE, and/or DELETE statements. 37

38 Weak Exclusive (WE) Applicable Objects : Rows Lock Owner : Can both read and modify data stored in the locked resource Other Transactions : Can neither read nor modify data stored in the locked resource unless UR isolation level is used (in which case data can be read) Acquired when a row is added to a non-catalog table. 38 Weak Exclusive (WE) When a Weak Exclusive (WE) lock is held on a resource, the lock owner is allowed to both read and modify data stored in the locked resource (which in this case, must be a row). Other transactions, however, are not allowed to read or modify data stored in the resource while it is locked unless they are running under the Uncommitted Read (UR) isolation level (in which case, they can read but cannot modify data stored in the locked resource). Weak Exclusive locks are typically acquired on a row when it is inserted into a nonsystem catalog table. 38

39 Super Exclusive (Z) Applicable Objects : Tablespaces, Tables Lock Owner : Can both read and modify data stored in the locked resource Other Transactions : Can neither read nor modify data stored in the locked resource Acquired when a table is altered or dropped, when an index is created or dropped, or when a table is reorganized. 39 Super Exclusive (Z) When a Super Exclusive (Z) lock is held on a resource, the lock owner is allowed to both read and modify data stored in the locked resource (which in this case, can be a tablespace or a table). Other transactions, however, can neither read nor modify data stored in the resource while it is locked. Super Exclusive locks are typically acquired on a table whenever the lock owner attempts to alter that table, drop that table, create an index for that table, drop an index that has already been defined for that table, or reorganize the contents of the table by running the REORG utility (while the table is off-line). 39

40 How are Locks Acquired? Implicitly by the DB2 Database Manager Explicitly by executing the LOCK TABLE SQL Statement: LOCK TABLE [TableName] IN [SHARE EXCLUSIVE] MODE Explicitly by specifying the USE AND KEEP [SHARE UPDATE EXCLUSIVE] LOCKS clause with a SELECT SQL Statement: SELECT * FROM EMPLOYEE WHERE EMPID = 001 WITH RS USE AND KEEP EXCLUSIVE LOCKS 40 The DB2 Database Manager implicitly acquires locks as they are needed and once acquired, these locks remain under the DB2 Database Manager s control until they are no longer needed. As we have already seen, these locks can be placed on tablespaces, tables and/or rows and except for occasions where the Uncommitted Read (UR) isolation level is used, it is never necessary for a transaction to explicitly request a lock. In fact, the only object that can be explicitly locked by a transaction is a table. If you want to explicitly acquire a table-level lock for a particular transaction, you can do so by executing the LOCK TABLE statement immediately after the transaction is initiated. The syntax for the LOCK TABLE statement is: LOCK TABLE [TableName] IN [SHARE EXCLUSIVE] MODE where TableName identifies the name of an existing table that is to be locked. As you can see, the LOCK TABLE statement allows a transaction to acquire a tablelevel lock on a particular table, in one of two modes: SHARE mode and EXCLUSIVE mode. If a table is locked using the SHARE mode, a table-level Share (S) lock is acquired on behalf of the requesting transaction and other concurrent transactions are allowed to read, but not change the data stored in the locked table. On the other hand, if a table is locked using the EXCLUSIVE mode, a table-level Exclusive (X) lock is acquired and other concurrent transactions can neither access nor modify data stored in the locked table. For example, when executed, the statement LOCK TABLE EMPLOYEE IN SHARE MODE will acquire a table-level Share (S) lock on the EMPLOYEE table on behalf of the current transaction (provided no other transaction holds a lock on this table) and other concurrent transactions will be allowed to read, but not change the data stored in the table. On the other hand, if the statement LOCK TABLE EMPLOYEE IN SHARE MODE were executed, a table-level Exclusive (X) lock 40

41 Locks and Performance Factors that can affect locking and that can have a significant impact on performance. 41 Because the DB2 Database Manager implicitly acquires locks as they are needed, aside from using the and LOCK TABLE statement to force the DB2 Database Manager to acquire a table-level lock on behalf of a transaction, locking is out of your control. However, there are several factors that can affect locking that you should be aware of. Knowing what these factors are and understanding how they can impact overall performance, can assist you in designing applications that work well in multi-user database environments, and indirectly, give you more control over how locks are used. 41

42 Lock Compatibility If the state of one lock placed on a resource is such that another lock can be placed on the same resource at the same time by another transaction, the two locks are said to be compatible. A table showing which locks are compatible and which locks are not can be found on page 59 of the DB2 Administration Guide : Performance manual (Version 8.2). For example, if one transaction holds a Share (S) lock on a table, another transaction can also acquire a Share (S) lock on the table because the two locks are compatible. 42 Lock Compatibility If the state of a lock placed on a data resource by one transaction is such that another lock can be placed on the same resource by another transaction before the first lock acquired is released, the two locks (or lock states) are said to be compatible. (For example, if a transaction holds a Share (S) lock on a resource, another transaction can also acquire a Share (S) lock on the resource because the two locks are compatible. However, if a transaction holds a Super Exclusive (Z) lock on a resource, no other transaction can acquire a lock on that resource because the Super Exclusive (Z) lock is incompatible with all other locks.) Any time one transaction holds a lock on a data resource and another transaction attempts to acquire a lock on the same resource, the DB2 Database Manager will examine the two lock states to determine whether they are compatible. If both locks are compatible, the second lock is acquired on behalf of the requesting transaction (provided no other transactions are waiting to acquire their own lock on the data resource). On the other hand, if the two locks are incompatible, the requesting transaction must wait until the owning transaction releases its lock (in fact, the requesting transaction must wait until all existing incompatible locks are released) before it can gain access to the resource and acquire the lock desired. This is known as a lock wait event and when a lock wait event occurs, the transaction attempting to access the locked resource simply stops execution until the owning transaction terminates and the incompatible lock is released or until a lock timeout event occurs. A table showing which locks are compatible and which are not can be found on page 59 of the DB2 Administration Guide : Performance manual. 42

43 Lock Waits and Timeouts When incompatible locks are used, one transaction must wait for the other to finish. By default, a transaction will wait indefinitely to acquire a lock it needs. The locktimeout database configuration parameter provides a way to control how long a transaction will wait to acquire a resource. By default, locktimeout = -1, which means Lock timeout detection is turned off. A locktimeout value of 0 means Don t wait for locks ; any other value means Wait this number of seconds. 43 Lock Waits and Timeouts Any time a transaction holds a lock on a particular resource (tablespace, table, or row), other transactions may be denied access to that resource until the owning transaction terminates and frees all locks it has acquired. And without some sort of lock timeout detection mechanism in place, a transaction might wait indefinitely for a lock to be released. For example, if a transaction in one user s application were waiting for a lock being held by a transaction in another user s application to be released, and the other user left their workstation without performing some interaction that would have allowed their application to terminate the owning transaction and release all locks held, the application waiting for the lock to be released would be unable to continue processing for an indeterminable amount of time. Unfortunately, it would also be impossible terminate the application that is waiting for the lock to be released without compromising data consistency. To prevent situations like these from occurring, an important feature known as lock timeout detection has been incorporated into the DB2 Database Manager. When used, this feature prevents applications from waiting indefinitely for a lock to be released in an abnormal situation. By assigning a value to the locktimeout configuration parameter in the appropriate database configuration file, you can control if and when lock timeout detection will occur. This parameter controls the amount of time that any transaction will wait to obtain a requested lock; if the requested lock is not acquired before the time interval specified in the locktimeout configuration parameter has elapsed, the waiting application receives an error message, and the transaction requesting the lock is rolled back. (Once the transaction requesting the lock has been rolled back, the waiting application can be terminated, if so desired, without fear of causing inconsistency in the data to occur.) 43

44 Lock Conversion 44 Lock Conversion If a transaction attempts to access a data resource it already holds a lock on, and the mode of access needed requires a more restrictive lock than that already held, the DB2 Database Manager will attempt to change the state of the lock being held to the more restrictive state, rather than acquire a second lock. The operation of changing the state of a lock already held to a more restrictive state is known as lock conversion. Lock conversion occurs because a transaction can hold only one lock on a specific data resource at any given time. In most cases, lock conversion is performed on row-level locks and the conversion process is fairly straightforward. For example, if a Share (S) lock is held and an Exclusive (X) lock is needed, the Share (S) lock will be converted to an Exclusive (X) lock. However, Share (S) locks and Intent Exclusive (IX) locks are special cases, since neither lock is considered more restrictive than the other; if one of these locks is held and the other is requested, the held lock is converted to a Share With Intent Exclusive (SIX) lock. All other conversions result in the lock state requested becoming the new lock state of the lock being held -- provided the requested lock state is more restrictive that that of the current lock. (Lock conversion only occurs if a held lock can increase its restriction.) Once a lock has been converted, it stays at the highest level attained until the transaction holding the lock is terminated. 44

45 Lock Escalation 45 Lock Escalation All locks require space for storage, and because space in memory is a valuable resource, the DB2 Database Manager imposes a limit on the amount of storage space that can be used to store locks. Furthermore, the DB2 Database Manager imposes a limit on the amount of storage space each transaction can use for its own locks. Therefore, in order to prevent a specific database agent from exceeding these space limitations, a process known as lock escalation is performed whenever too many locks (regardless of their type) have been acquired. Lock escalation is the conversion of several individual row-level locks on rows within the same table into a single table-level lock. So just how does lock escalation work? When a transaction requests a lock and the lock storage space is full, one of the tables associated with the transaction is selected, a table-level lock is acquired, all row-level locks for that table are released to create space in the lock list data structure, and the table-level lock acquired is added to the lock list. If this process does not free up the storage space needed to then acquire the lock requested, another table is selected and the process is repeated, until enough free space is available at that point, the requested lock is acquired and the transaction resumes execution. However, if the necessary lock space is still unavailable after all the transaction's row-level locks have been escalated, an SQL error code is generated, all changes that have been made since the transaction was initiated are rolled back, and the transaction is terminated. Since lock escalation is handled internally, the only externally detectable result might be a reduction in concurrent access on one or more tables after the lock escalation operation has taken place provided the necessary lock space is available in the lock list data structure. Note: You can control the amount of storage that gets allocated for the lock list 45

46 Deadlocks A deadlock occurs when two or more transactions form a circle of wait states; each transaction in the circle waits for a lock held by another transaction in the circle to be released. 46 Deadlocks Earlier, we saw how one transaction wait indefinitely for a lock to be released and how this situation can be alleviated by establishing a lock timeout. However, there is one situation where contention for locks by two or more transactions cannot be resolved by specifying a lock timeout. This situation is known as a deadlock. A deadlock is more precisely referred to as a deadlock cycle, because the transactions involved form a circle of wait states; each transaction in the circle waits for a lock held by another transaction in the circle to be released. When a deadlock cycle occurs, all transactions involved will wait indefinitely for a lock to be released unless some outside agent steps in and breaks the deadlock cycle. With DB2 Universal Database, this agent is a background process, known as the deadlock detector, whose sole responsibility is to locate and resolve any deadlocks found in the locking subsystem. Each database has its own deadlock detector, which stays "asleep" most of the time but "wakes up" at preset intervals and examines the locking subsystem to determine whether a deadlock situation exists. Normally, the deadlock detector wakes up, sees that there are no deadlocks in the locking subsystem, and goes back to sleep. If, however, the deadlock detector discovers a deadlock cycle in the locking subsystem, it selects one of the transactions in the cycle to roll back and terminate. The transaction chosen receives an SQL error code, and every lock it had acquired is released. The remaining transaction(s) can then proceed because the deadlock cycle has been broken. The deadlock detector then goes back to sleep, only to wake up again at the next predefined interval, and reexamine the locking subsystem. 46

47 Deadlock Example 47 The best way to illustrate how a deadlock can occur is by example: Suppose Transaction 1 acquires an Exclusive (X) lock on Table A and Transaction 2 acquires an Exclusive (X) lock on Table B. Now, suppose Transaction 1 attempts to acquire an Exclusive (X) lock on Table B and Transaction 2 attempts to acquire an Exclusive (X) lock on Table A. Because the locks requested are incompatible with the locks being held, processing will be suspended until each transaction s second lock request is granted. However, because neither lock request can be granted until one of the owning transactions releases the lock it currently holds (by performing a commit or rollback operation), and because neither transaction can perform a commit or rollback operation because they both have been suspended (and are waiting on locks), a deadlock situation has occurred. 47