DB2 LC SLIDES04 FP2005 Ver1.0

DB2
Session Plan
• Introduction to Concurrency Control
• Different types of locks
• Compatibility of locks
• Isolation levels
• Issues in batch programs
• DB2 Utilities
• SQL Optimizer
Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

2
Technologies Ltd 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.

3
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

4
Granularity of Locks – Sizes of Locks
• PAGE level.
• TABLE level.
• TABLESPACE level.

5
Ending a Transaction (1 of 4)
TSO Environment
EXEC SQL
COMMIT or COMMIT WORK
END-EXEC.
OR
EXEC SQL
ROLLBACK
END-EXEC.

6
IMS Environment
EXEC SQL
CHKP or XRST
END-EXEC.
OR
EXEC SQL
ROLL or ROLB
END-EXEC.

7
CICS Environment
EXEC SQL
SYNCPOINT
END-EXEC.
OR
EXEC SQL
ROLLBACK
END-EXEC.

8
• 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

9
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.

10
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

11
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.

12
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

13
Locks Compatibility
S U X
S Y Y N
U Y N N
X N N N

14
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

15
Intent Locks available in DB2
• DB2 provides three types of intent locks
– IS (Intent Share)
– IX (Intent Exclusive)
– SIX (Shared with Intent Exclusive)

16
Locks Compatibility matrix
S U X IS IX SIX
S Y Y N Y N N
U Y N N Y N N
X N N N N N N
IS Y Y N Y Y Y
IX N N N Y Y N
SIX N N N Y N N

17
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

18
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.

19
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).

20
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).

21
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.

22
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.

23
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.

24
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!

25
• 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?)

26
• 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

27
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?)

28
DB 2 Utilities – A few
• LOAD
• RUNSTATS
• REORG

29
LOAD utility (1 of 3)
• Loads data from a sequential file into a table.
• Involves the following phases

• Initialization
• Load/Reload
• SORT
• Build
• Termination

30
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.

31
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.

32
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.

33
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

34
SQL Optimizer
An optimizer performs the following four steps
3) Receive and verify the SQL statement.
4) Analyze the environment and optimize the methods of satisfying the

SQL statement.
5) Create machine readable instructions to execute the optimized SQL.
6) Execute the instructions or store them for future execution

35
Summary
• Introduction to Concurrency Control
• Different types of locks
• Compatibility of locks
• Isolation levels
• Issues in batch programs
• DB2 Utilities
• SQL Optimizer

36
Thank You!

37

DB2 LC SLIDES04 FP2005 Ver1.0

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DB2 LC SLIDES04 FP2005 Ver1.0

Uploaded by

Copyright:

Available Formats

DB2

• Different types of locks

• Issues in batch programs

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

DB2 manages concurrency control with several types of locks

In the exceptional case, the programmers specify the type of a

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

• Supports S, U, X and intent locks.

• Generally DB2 begins acquiring locks on a transaction’s affected data

• All the locks are released at COMMIT time or at thread deallocation

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

• If an explicit COMMIT is not issued, at the end of the program, when

• If the program abends, DB2 does an auto ROLLBACK.

• In CICS pseudo-conversational programs, every time we do a

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

• Generally a COMMIT WORK statement should be included before a

• However, if the input is for an update rather than an insertion or

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

• If a transaction takes a S lock on some data, then other transactions

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

• If a transaction takes an U lock on some data, then other transactions

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

• If a transaction takes an X lock on some data, then no other

• X locks are taken for INSERT, UPDATE and DELETE purposes

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

• DB2 provides three types of intent locks

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

• DB2 checks for deadlocks in the system at pre specified intervals

• Deadlock resolution is done by rolling back one of the transactions

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

• During BIND, DB2 allows us to specify transaction level lock acquiring

• ACQUIRE (USE) - Take locks at the time of first SQL statement

• ACQUIRE (ALLOCATE) - Take all necessary locks at the start of the

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

• RELEASE (COMMIT) - To release all locks at transaction commit time.

• RELEASE (DEALLOCATE) - To release all locks only when the

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

• Isolation level refers to the extent by which the data

• DB2 supports 2 Isolation Levels for every transaction

– Cursor Stability (CS).

– Repeatable Read (RR) (Default).

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

• The lock on the last page is released at commit time or at thread

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

• In CS, while your transaction reads data, other transaction could

• CS provides higher concurrency.

• RR provides higher consistency.

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

Is similar to RR, but without allowing qualifying data to be updated or

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

• Batch programs are COBOL programs with embedded SQL

• If a transaction boundary is not defined, then the whole program

• Imagine, updating all Infosys employees’ salary as one transaction and

Copyright © 2005, Infosys ER/CORP/CRS/DB01/003

• It is good to keep transactions as small as possible.