DB2-LC-SLIDES04-FP2005-Ver1.0

DB2

Session Plan \u2022

Introduction to Concurrency Control

\u2022

Different types of locks

\u2022

Compatibility of locks

\u2022

Isolation levels

\u2022

Issues in batch programs

\u2022

DB2 Utilities

\u2022

SQL Optimizer

Copyright \u00a9 2005, Infosys

ER/CORP/CRS/DB01/003

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.

Copyright \u00a9 2005, Infosys

ER/CORP/CRS/DB01/003

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

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

Granularity of Locks – Sizes of Locks

•

PAGE level.

•

TABLE level.

•

TABLESPACE level.

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

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

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

Ending a Transaction (2 of 4) IMS Environment EXEC SQL CHKP or XRST END-EXEC. OR EXEC SQL ROLL or ROLB END-EXEC.

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

Ending a Transaction (3 of 4) CICS Environment EXEC SQL SYNCPOINT END-EXEC. OR EXEC SQL ROLLBACK END-EXEC.

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

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

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

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

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

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

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

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.

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

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

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

Locks Compatibility

S

U

X

S

Y

Y

N

U

Y

N

N

X

N

N

N

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

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

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

Intent Locks available in DB2

•

DB2 provides three types of intent locks – IS (Intent Share) – IX (Intent Exclusive) – SIX (Shared with Intent Exclusive)

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

Locks Compatibility matrix S

U

S

Y

Y

U

Y

X

X

IS

IX

N

Y

N

N

N

N

Y

N

N

N

N

N

N

N

N

IS

Y

Y

IX

N

N

N

Y

SIX

N

N

N

Y

N

Y

Y

SIX

Y

Y N

Copyright © 2005, Infosys

N N

ER/CORP/CRS/DB01/003

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

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

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.

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

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

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

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

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

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.

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

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.

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

Read Stability (RS)

Is similar to RR, but without allowing qualifying data to be updated o 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 search condition.

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

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!

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

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

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

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 t reduce rework, must restart at the point of failure. i.e., the program must be re- startable

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

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

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

DB 2 Utilities – A few

•

LOAD

•

RUNSTATS

•

REORG

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

LOAD utility (1 of 3) •

Loads data from a sequential file into a table.

•

Involves the following phases • Initialization • Load/Reload • SORT • Build • Termination

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

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.

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

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.

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

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.

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

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

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

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

Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003

Summary •

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

Thank You! Copyright © 2005, Infosys

ER/CORP/CRS/DB01/003