DB2

2 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Session Plan Introduction to Concurrency Control Different types of locks Compatibility of locks Isolation levels Issues in batch programs DB2 Utilities SQL Optimizer

3 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Concurrency Control DB2 manages concurrency control with several types of locks In all but one case, DB2 selects the appropriate lock type based on concurrency control requirements inherent in the transaction. These locks are called implicit locks. The strategy for implicit locks is decided during the bind phase. In the exceptional case, the programmers specify the type of a lock for a table in the application program. These locks are called explicit locks.

4 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Concurrency Control Supports S, U, X and intent locks. Generally DB2 begins acquiring locks on a transaction’s affected data when the first SQL statement in a program is executed or at the beginning of the transaction. All the locks are released at COMMIT time or at thread deallocation time

5 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Granularity of Locks – Sizes of Locks PAGE level. TABLE level. TABLESPACE level.

6 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Ending a Transaction (1 of 4) TSO Environment EXEC SQL COMMIT or COMMIT WORK END-EXEC. OR EXEC SQL ROLLBACK END-EXEC.

7 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Ending a Transaction (2 of 4) IMS Environment EXEC SQL CHKP or XRST END-EXEC. OR EXEC SQL ROLL or ROLB END-EXEC.

8 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Ending a Transaction (3 of 4) CICS Environment EXEC SQL SYNCPOINT END-EXEC. OR EXEC SQL ROLLBACK END-EXEC.

9 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Ending a Transaction (4 of 4) If an explicit COMMIT is not issued, at the end of the program, when the task ends DB2 does an auto COMMIT. If the program abends, DB2 does an auto ROLLBACK. In CICS pseudo-conversational programs, every time we do a RETURN (conditional or unconditional), CICS issues an auto SYNCPOINT to DB2

10 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a When to COMMIT work Generally a COMMIT WORK statement should be included before a program asks for terminal input.. However, if the input is for an update rather than an insertion or deletion, it may be best to retain the lock while waiting for information.

11 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Shared lock (S) If a transaction takes a S lock on some data, then other transactions can get only S lock on it. In other words if a transaction reads some data, then other transactions can read but not update or delete the same data

12 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Update lock (U) If a transaction takes an U lock on some data, then other transactions can only get only S lock on it. In other words if a transaction reads some data with the intention of update, then other transactions can only read that data but not update or delete.

13 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Exclusive lock (X) If a transaction takes an X lock on some data, then no other transaction can get access to it. i.e., no other transaction can read, update, or delete) X locks are taken for INSERT, UPDATE and DELETE purposes

14 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Locks Compatibility SUX YYNS YNNU NNNX

15 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Intent Locking Works like a “traffic cop” at the table or table space level and regulate the use of page level locks and signal to concurrent transactions whether a particular type of page lock is possible or not. This is to regulate the page level locks and signal to other concurrent transactions whether a particular lock request can be satisfied or not. This reduces the processing time to manage the locks while allowing a high degree of concurrency

16 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Intent Locks available in DB2 DB2 provides three types of intent locks –IS (Intent Share) –IX (Intent Exclusive) –SIX (Shared with Intent Exclusive)

17 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Locks Compatibility matrix SUX YYNS YNNU NNNX ISIXSIX IS IX SIX YNN YNN NNN YYNYYY NNNYYN NNNYNN

18 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Deadlocks Two transactions A & B enter a deadlock state when a transaction A which has locked an object X waits on an object Y locked by transaction B which itself is waiting for X. DB2 checks for deadlocks in the system at pre specified intervals (Usually once in 15 seconds). Deadlock resolution is done by rolling back one of the transactions (from the set of transactions which lead to deadlock situation) which has the least log entries

19 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a ACQUIRE During BIND, DB2 allows us to specify transaction level lock acquiring and releasing parameters. ACQUIRE (USE) - Take locks at the time of first SQL statement execution. This is DB2 default. ACQUIRE (ALLOCATE) - Take all necessary locks at the start of the transaction.

20 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a RELEASE RELEASE (COMMIT) - To release all locks at transaction commit time. This is DB2 default. RELEASE (DEALLOCATE) - To release all locks only when the program ends (i.e., the thread is deallocated).

21 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Isolation Levels Isolation level refers to the extent by which the data accessed by a transaction is isolated from all other transactions. DB2 supports 2 Isolation Levels for every transaction –Cursor Stability (CS). –Repeatable Read (RR) (Default).

22 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Cursor Stability (CS) DB2 takes a lock on the page the cursor is accessing and releases the lock on that page when the cursor moves onto a different page. This is not done when we use FOR UPDATE OF statement in cursor. The lock on the last page is released at commit time or at thread deallocation time.

23 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Repeatable Read (RR) In CS, while your transaction reads data, other transaction could change the data you have already read. In RR, DB2 holds all the page locks while the cursor is moving on till the transaction commits or the thread is deallocated. CS provides higher concurrency. RR provides higher consistency.

24 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Read Stability (RS) Is similar to RR, but without allowing qualifying data to be updated or deleted by another process. It offers greater concurrency than repeatable read, because although other applications cannot change rows that are returned to the original application, they can insert new rows, or update rows that did not satisfy the original application's search condition.

25 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Issues in Batch Programs (1 of 3) Batch programs are COBOL programs with embedded SQL statements. If a transaction boundary is not defined, then the whole program becomes one transaction. Imagine, updating all Infosys employees’ salary as one transaction and just before updating last employee’s salary, the system fails!

26 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Issues in Batch Programs (2 of 3) It is good to keep transactions as small as possible. Let 25 employees’ salary updation be one transaction (i.e., after every 25 updations the program issues a COMMIT statement) What if a failure occurs after updating 30 salaries? (DB2 only rolls back the last 5 updations. Why?)

27 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Issues in Batch Programs (3 of 3) Should the program be restarted from the beginning now? If the program is restarted then the first 25 employee’s salary will be updated again!!! All the batch programs which splits the job into multiple transactions to reduce rework, must restart at the point of failure. i.e., the program must be re- startable

28 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Restarting Programs After every transaction, store the last key (in our case Employee #) in a separate table known as restart table. Should the last key be written just before the COMMIT or just after the COMMIT? A program which is written using this logic always starts from the restart key (What about the first time?)

29 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a DB 2 Utilities – A few LOAD RUNSTATS REORG

30 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a LOAD utility (1 of 3) Loads data from a sequential file into a table. Involves the following phases Initialization Load/Reload SORT Build Termination

31 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Load Utility The following are the options available with LOAD utility. 1.Load some fields from the input file and ignore the others. 2.Load only records that meet the specified condition. 3.Load data into multiple tables of a table space. 4.Load some fields into columns in one table and other fields into columns in another table. 5.Specify a discard dataset to receive records that cannot be loaded. 6.Load can replace existing data or add additional data. 7.Convert input data from one numeric type to another. 8.Alter the length of input data items.

32 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a REORG utility Reorganizes data on the physical storage. Repositions rows in proper sequence in case of tables have clustered indexes. Reclaim space from pages where some rows were deleted.

33 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a RUNSTATS utility Reads table spaces and indexes to collect statistical information describing the data such as the number of pages and rows and stores them in Catalog tables. This information is used by the DB 2’s optimizer while selecting the most efficient access paths to service database requests. Execution of RUNSTATS will have no effect unless the application plans and packages are rebound.

34 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Performance Issue When there is an issue in performance and if all the table spaces for an application are being reorganized, each of the following utility should be run in sequence. One REORG Job One RUNSTATS Job One COPY Job One REBIND Job

35 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a SQL Optimizer An optimizer performs the following four steps 1)Receive and verify the SQL statement. 2)Analyze the environment and optimize the methods of satisfying the SQL statement. 3)Create machine readable instructions to execute the optimized SQL. 4)Execute the instructions or store them for future execution

36 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Summary Introduction to Concurrency Control Different types of locks Compatibility of locks Isolation levels Issues in batch programs DB2 Utilities SQL Optimizer

37 Copyright © 2005, Infosys Technologies Ltd ER/CORP/CRS/DB01/003 Version No:2.0a Thank You!