Matakuliah Tahun : T0413 : 2009 Concurrency and locking Pertemuan 8 What is a Transaction? Your bank account Your Mom’s bank account Balance = $1000 Balance = $200 Transfer $100 from your account to your Mom’s account: - Debit $100 from Savings account - Credit $100 to Checking account Bina Nusantara University 3 Concurrency overview App A App B App C App D Bina Nusantara University ID Name Age 3 Peter 33 5 John 23 22 Mary 22 35 Ann 55 4 Locking overview App A App B App C App D Bina Nusantara University ID Name Age 3 Peter 33 5 John 23 22 Mary 22 35 Ann 55 5 Concurrency • DB2 was designed as a multi-user database • Access to data must be coordinated properly and transparently using a mechanism to ensure data integrity and consistency • Without some form of concurrency control, the following problems may be encountered – – – – Bina Nusantara University Lost update Uncommitted read Non-repeatable read Phantom read 6 Lost Update Reservations Flight 512 512 ... Seat 7C 7B ... Update Reservations Set P-name = 'Instruct' Where Flight = 512 and Seat = '7C' and P_name is NULL 512 Bina Nusantara University 7C Instruct ... P-Name ... ? Update Reservations Set P-name = 'Manager' Where Flight = 512 and Seat = '7C' and P_Name is NULL 512 7C Manager ... 7 Uncommitted Read Reservations Flight 512 Seat 7C 512 ... 7B ... P_Name 2 Select seat From Reservations Where P-name is NULL 1 Update Reservations Set P-name = 'Instruct' Where Flight = 512 and Seat = '7C' and P_Name is NULL 512 3 Roll back Bina Nusantara University 7C Instruct 4 Incorrect results set 8 Non-repeatable Read FLIGHT SEAT 512 7B DENVER 8A SAN JOSE 1C HONOLULU SAN JOSE NAME DESTINATION ORIGIN DALLAS .... .... 814 DENVER .... 134 .... .... Book a flight from Dallas to Honolulu Bina Nusantara University 9 Phantom Read Reservations Flight 512 512 ... P-name Seat 7B 7A ... Susan Liu 1 Select seat From Reservations Where P-name is NULL 512 3 Repeat 1 now seat Bina Nusantara 7AUniversity is available 2 Update Reservations Set P-name = 'NULL' Where Flight = 512 and Seat = '7A' and P-name = 'Susan Liu ' 7B 10 Locking • DB2 uses locking to maintain data integrity • Locks are acquired automatically as needed to support a transaction and are released when the transaction terminates (COMMIT/ROLLBACK) • Locks can be acquired on tables or rows • Two basic types of locks: – Share locks (S locks) – acquired when an application wants to read and prevent others from updating the same row – Exclusive locks (X locks) – acquired when an application updates, inserts, or deletes a row Bina Nusantara University 11 Isolation Levels • DB2 provides different levels of protection to isolate data – – – – Uncommitted Read (UR) Cursor Stability (CS) Read Stability (RS) Repeatable Read (RR) • Isolation level can be specified at many levels – Session (application). Defaults to CS – Connection – Statement • For embedded SQL, the level is set at bind time • For dynamic SQL, the level is set at run time Bina Nusantara University 12 Comparing isolation levels Bina Nusantara University 13 Isolation Levels – Uncommitted Read • Uncommitted Read is also known as DIRTY READ – Lowest level of isolation – Provides highest degree of concurrency • No row locks are obtained on read operations – unless other application attempts to drop or alter table • Update operations act as if using Cursor Stability • Possible Situations – Uncommitted Read – Non-repeatable Read – Phantom Read • Situations Prevented – Loss of Update Bina Nusantara University 14 Isolation Levels – Cursor Stability • Cursor Stability is the default isolation level – Minimal degree of locking – Locks the "current" row of a cursor – If the row is only read • the lock is held until a new row is fetched or the unit of work is terminated – If the row is updated • the lock is held until the unit of work is terminated • Possible Situations – Non-repeatable Read – Phantom Read • Prevented Situations – Loss of Update Bina Nusantara University – Uncommitted Read 15 Isolation Levels – Read Stability • Locks all the rows an application retrieves within a unit of work – For a given cursor, it locks all rows that qualify for the result set – Moderate degree of locking • Possible Situations – Phantom Read • Prevented Situations – Loss of Update – Uncommitted Read – Non-repeatable Read Bina Nusantara University 16 Isolation Levels – Repeatable Read • Highest isolation level, least concurrency – Same query issued by the application more than once in a unit of work will give the same result each time – High degree of locking – Locks held on all rows processed to build the result set • i.e. rows not necessarily in the final result set may be locked – No other application can update, delete, or insert a row that would affect the result set until the unit of work completes • Possible Situations – none • Prevented Situations Bina Nusantara University – – – – Loss of Update Uncommitted Read Non-repeatable Read Phantom Read 17 Comparison of Isolation Level Terminolgy DB2 .NET JDBC Uncommitted Read ReadUncommitted TRANSACTION_RE OMMITTED Cursor Stability (CS) ReadCommitted TRANSACTION_RE MITTED Read Stability (RS) RepeatableRead TRANSACTION_RE _READ Repeatable Read Serializable TRANSACTION_SE E Bina Nusantara University 18 Statement Level Isolation SELECT ... WITH {UR | CS | RS | RR} UR = Uncommitted Read CS = Cursor Stability RS = Read Stability RR = Repeatable Read • Example Scenario: – Application needs to get a "rough" count of how many rows are in table. Performance is of utmost importance. Cursor Stability isolation level is required with the exception of one SQL statement: SELECT COUNT(*) FROM tab1 WITH UR Bina Nusantara University 19 Lock Escalation Bina Nusantara University 20 Lock Escalation • When optimizer thinks it is better to have one lock on the entire table, rather than multiple row locks • Database configuration parameters that affect lock escalation: – LOCKLIST – the amount of memory (4k pages) to manage locks for all connected applications • Default is 50 * 4K pages on Windows – MAXLOCKS –Max percentage of the entire lock list that a single application can use up Bina Nusantara University • Default is 22 percent 21 Lock Escalation (continued) • If the default values are used, lock escalation occurs when a single application requires more than 44K of lock memory • If lock escalation, increase the value of LOCKLIST and MAXLOCKS • Avoid lock escalations: Performance bottleneck • Check the DB2 diagnostic log file (db2diag.log). The location is shown below. On Windows XP, 2003: – C:\Documents and Settings\All Users\Application Data\IBM\DB2\DB2COPY1\<instance name> On Windows Vista: – ProgramData\IBM\DB2\ On Linux/UNIX: – INSTHOME/sqllib/db2dump (INSTHOME is the home directory of the instance owner) Bina Nusantara University 22 Lock Escalation indication in the db2diag.log 2007-01-02-23.04.43.699000 Instance:DB2 Node:000 PID:984(db2syscs.exe) TID:1720 Appid:*LOCAL.DB2.011003030417 data_management sqldEscalateLocks Probe:1 Database:SAMPLE -- Start Table Lock Escalation. -- Lock Count, Target : 28, 14 7570 6461 7465 2065 6d70 6c6f 7965 6520 7365 7420 6669 7273 746e 6d65 3d27 6162 6327 c' update employee set firstnme='ab 2007-01-02-23.04.43.699001 Instance:DB2 Node:000 PID:984(db2syscs.exe) TID:1720 Appid:*LOCAL.DB2.011003030417 data_management sqldEscalateLocks Probe:2 Database:SAMPLE -- Lock Count, Target : 28, 14 -- Table (ID) Name : (2;5) ADMINISTRATOR.EMPLOYEE -- Locks, Request Type : 25, X -- Result (0 = success): 0 Bina Nusantara University 23 Application Lock Snapshot Lock Snapshot View locks currently held by an application UPDATE MONITOR SWITCHES USING LOCK ON GET SNAPSHOT FOR LOCKS FOR APPLICATION AGENT ID <handle> Bina Nusantara University Snapshot timestamp Application handle Application ID Sequence number Application name Authorization ID Application status Status change time Application code page Locks held Total wait time (ms) = 11-05-2002 00:09:08.672586 =9 = *LOCAL.DB2.00B9C5050843 = 0001 = db2bp.exe = ADMINISTRATOR = UOW Waiting = Not Collected = 1252 =4 =0 List Of Locks Lock Name = 0x05000700048001000000000052 Lock Attributes = 0x00000000 Release Flags = 0x40000000 Lock Count = 255 Hold Count =0 Lock Object Name = 98308 Object Type = Row Tablespace Name = TEST4K Table Schema = ADMINISTRATOR Table Name = T2 Mode =X 24 Lock Wait • By default, an application waits indefinitely to obtain any needed locks • LOCKTIMEOUT (db cfg): – Change to specify the number of seconds to wait for a lock – Default value is -1 or infinite wait • A database connection also has a user-definable CURRENT LOCK TIMEOUT register – – – – By default it inherits its value from the LOCKTIMEOUT parameter Use the SET LOCK TIMEOUT statement to change its value Once it is set for a connection, it persists across transactions e.g. SET LOCK TIMEOUT=WAIT n Bina Nusantara University 25 Deadlock Causes and Detection RAISIN BRAN USER A MILK USER B within a UNIT OF WORK (UOW) Bina Nusantara University INSERT CEREAL AND MILK into BOWL 26 Deadlock Settings • Deadlocks are an application design issue most of the time • DLCHKTIME (db cfg) sets the time interval for checking for deadlocks – It defines the frequency that the database manager checks for deadlocks among all the applications connected to a database • If you are experiencing many deadlocks, you should re-examine your existing transactions and see if any re-structuring is possible 27 Bina Nusantara University Best Practices • Keep transactions as short as possible – Issue frequent COMMIT statements – even for read-only transactions • Log transaction information only when required – Purge data quick using: • ALTER TABLE ACTIVATE NOT LOGGED INITIALLY WITH EMPTY TABLE – Perform data modifications in batches/groups • DELETE FROM ( SELECT * FROM tedwas.t1 WHERE c1 = … FETCH FIRST 3000 ROWS ONLY ) – Use concurrency features in DB2 data movement tools • Set the database level LOCKTIMEOUT parameter (usually between 30120 seconds) – Can also use session-based lock timeout • Do not retrieve more data than is required – Use the FETCH FIRST n ROWS ONLY clause in SELECT statements Bina Nusantara University 28