Partition Independence

 <  Day Day Up  >  

DB2 augments resource serialization using claims and drains in addition to transaction locking. The claim and drain process enables DB2 to perform concurrent operations on multiple partitions of the same table space.

Claims and drains provide another "locking" mechanism to control concurrency for resources between SQL statements, utilities, and commands. Do not confuse the issue: DB2 continues to use transaction locking, as well as claims and drains.

As with transaction locks, claims and drains can time out while waiting for a resource.

Claims

DB2 uses a claim to register that a resource is being accessed. The following resources can be claimed:

  • Simple table spaces

  • Segmented table spaces

  • A single data partition of a partitioned table space

  • A non-partitioned index space

  • graphics/v8_icon.gif A single index partition of a partitioned index (of either the partitioning index or a DPSI)

Think of claims as usage indicators. A process stakes a claim on a resource, telling DB2, in effect, "Hey, I'm using this!"

Claims prevent drains from acquiring a resource. A claim is acquired when a resource is first accessed. This is true regardless of the ACQUIRE parameter specified ( USE or ALLOCATE ). Claims are released at commit time, except for cursors declared using the WITH HOLD clause or when the claimer is a utility.

Multiple agents can claim a single resource. Claims on objects are acquired by the following:

  • SQL statements ( SELECT , INSERT , UPDATE , DELETE )

  • DB2 restart on INDOUBT objects

  • Some utilities (for example, COPY SHRLEVEL CHANGE , RUNSTATS SHRLEVEL CHANGE , and REPORT )

Every claim has a claim class associated with it. The claim class is based on the type of access being requested , as follows :

  • A CS claim is acquired when data is read from a package or plan bound specifying ISOLATION(CS) .

  • An RR claim is acquired when data is read from a package or plan bound specifying ISOLATION(RR) .

  • A write claim is acquired when data is deleted, inserted, or updated.

Drains

Like claims, drains also are acquired when a resource is first accessed. A drain acquires a resource by quiescing claims against that resource. Drains can be requested by commands and utilities.

Multiple drainers can access a single resource. However, a process that drains all claim classes cannot drain an object concurrently with any other process.

To more fully understand the concept of draining, think back to the last time that you went to a movie theater. Before anyone is permitted into the movie, the prior attendees must first be cleared out. In essence, this example illustrates the concept of draining. DB2 drains make sure that all other users of a resource are cleared out before allowing any subsequent access.

The following resources can be drained:

  • Simple table spaces

  • Segmented table spaces

  • A single data partition of a partitioned table space

  • A non-partitioned index space

  • graphics/v8_icon.gif A single index partition of a partitioned index (of either the partitioning index or a DPSI)

A drain places drain locks on a resource. A drain lock is acquired for each claim class that must be released. Drain locks prohibit processes from attempting to drain the same object at the same time.

The process of quiescing a claim class and prohibiting new claims from being acquired for the resource is called draining . Draining allows DB2 utilities and commands to acquire partial or full control of a specific object with a minimal impact on concurrent access.

Three types of drain locks can be acquired:

  • A cursor stability drain lock

  • A repeatable read drain lock

  • A write drain lock

A drain requires either partial control of a resource, in which case a write drain lock is taken, or complete control of a resource, accomplished by placing a CS drain lock, an RR drain lock, and a write drain lock on an object.

You can think of drains as the mechanism for telling new claimers, "Hey, you can't use this in that way!" The specific action being prevented by the drain is based on the claim class being drained. Draining write claims enables concurrent access to the resource, but the resource cannot be modified. Draining read ( CS and/or RR ) and write claims prevents any and all concurrent access.

Drain locks are released when the utility or command completes. When the resource has been drained of all appropriate claim classes, the drainer acquires sole access to the resource.

Claim and Drain Lock Compatibility

As with transaction locks, concurrent claims and drains can be taken, but only if they are compatible with one another. Table 23.11 shows which drains are compatible with existing claims.

Table 23.11. Claim/Drain Compatibility Matrix

Existing Claim for PGM2

Drain required by PGM1

 

Write

CS

RR

Write

No

No

No

RR

Yes

No

No

CS

Yes

No

No


Table 23.12 shows which drains are compatible with existing drains.

Table 23.12. Drain/Drain Compatibility Matrix

Existing Drain for PGM2

Drain required by PGM1

 

Write

CS

RR

Write

Yes

No

No

RR

No

No

No

CS

No

No

No


Transaction Locking Versus Claims and Drains

DB2 uses transaction locks to serialize access to a resource between multiple claimers, such as two SQL statements or an SQL statement and a utility that takes claims, such as RUNSTATS SHRLEVEL(CHANGE) .

Claims and drains serialize access between a claimer and a drainer. For example, an INSERT statement is a claimer that must be dealt with by the LOAD utility, which is a drainer.

Drain locks are used to control concurrency when both a command and a utility try to access the same resource.

 <  Day Day Up  >  


DB2 Developers Guide
DB2 Developers Guide (5th Edition)
ISBN: 0672326132
EAN: 2147483647
Year: 2004
Pages: 388

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net