DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

Specification
on DECLARE
Specification
on FETCH
Type of
Cursor
Comments
Sensitive Sensitive Updatable Aware of own updates and deletes within the
cursor.
Changes by another agent are visible to the
cursor after commit.
Any inserts are not recognized.
DB2 uses the predefined TEMP database and
segmented table space to create your DTT and
move in the results at execution time.
The following is the description of the DECLARE CURSOR and FETCH options which were
introduced in V7. The DECLARE CURSOR statement specifies that the cursor is scrollable by
the SCROLL keyword. If SCROLL is specified, then you need to specify either INSENSITIVE
or SENSITIVE STATIC. Any inserts are not visible in static scrollable cursors in every option,
because for static scrollable cursors, inserts are not considered cursor operations and the
result table is considered fixed after open cursor.
► If you specify INSENSITIVE in DECLARE CURSOR, the scrollable cursor is strictly
read-only. In a FETCH statement you can only specify INSENSITIVE. FETCH
INSENSITIVE retrieves the row from the result table. The cursor is not sensitive to
updates, inserts, and deletes made to the base table. So the application cannot see the
changes made through the cursor, using positioned update and delete, nor the changes
made outside the cursor.
► If you specify SENSITIVE in DECLARE CURSOR, the scrollable cursor is updatable. In a
FETCH statement you can specify INSENSITIVE or SENSITIVE to determine whether or
not changes to the rows outside the cursor can be seen by the FETCH.
– INSENSITIVE in a FETCH statement
Applications can see the changes they have made themselves, using positioned
updates or deletes through the cursor. In this case DB2 updates both the base table
and result table. However, updates and deletes to the base table made outside of the
cursor are not visible to the application. The reason is that a FETCH INSENSITIVE
cursor only accesses the result table, so the changes to the base table made outside
the cursor are not visible.
– SENSITIVE in a FETCH statement
Applications can see the committed updates and deletes made by other applications
outside the cursor, as well as changes they have made themselves using positioned
and searched updates and delete through the cursor. A FETCH SENSITIVE first
refreshes the rows in the DTT to pick up any committed updates and deletes from the
base table, while a FETCH INSENSITIVE just returns the appropriate row from the
DTT.
Optimistic locking
The static cursor model introduces the concept of optimistic locking. A specification of
Isolation Level Cursor Stability (CS) can be used with Lock Size Row such that locks are held
for the minimum duration because locking is optimistic in that no positioned update or delete
occurs (lock/unlock the row), and even if it does, a new lock is acquired to compare the values
between the base table and temporary table. In short, optimistic locking holds locks for the
minimum duration, thereby increasing concurrency for that table. In addition, for applications
that compare by value, it frees these applications from coding the comparison by moving this
logic to the DBMS for better performance and less application code.
Chapter 3. SQL performance 93