Variables to improve concurrency on DB2
DB2_EVALUNCOMMITTED, DB2_SKIPDELETED, DB2_SKIPINSERTED
- DB2_EVALUNCOMMITTED
-
- Operating system: All
- Default: OFF, Values: ON, OFF
- When enabled, this variable allows, where possible, table or index
access scans to defer or avoid row locking until a data record is
known to satisfy predicate evaluation.
With this variable enabled, predicate evaluation may occur on uncommitted data.
DB2_EVALUNCOMMITTED is applicable only to statements using either Cursor Stability or Read Stability isolation levels. For index scans, the index must be a type-2 index.
Furthermore, deleted rows are skipped unconditionally on table scan access while deleted keys are not skipped for type-2 index scans unless the registry variable DB2_SKIPDELETED is also set.
The activation of the DB2_EVALUNCOMMITTED registry variable is effective on the db2start command. The decision as to whether deferred locking is applicable is made at statement compile or bind time.
- DB2_SKIPDELETED
-
- Operating system: All
- Default: OFF, Values: ON or OFF
- When enabled, this variable allows statements using either Cursor
Stability or Read Stability isolation levels to unconditionally skip
deleted keys during index access and deleted rows during table access.
With DB2_EVALUNCOMMITTED enabled,
deleted rows are automatically skipped, but uncommitted pseudo-deleted
keys in type-2 indexes are not skipped unless DB2_SKIPDELETED is
also enabled.
This registry variable does not impact the behavior of cursors on the DB2 catalog tables.
This registry variable is activated with the db2start command.
- DB2_SKIPINSERTED
-
- Operating system: All
- Default: OFF, Values: ON or OFF
- When the DB2_SKIPINSERTED registry variable
is enabled, it allows statements using either Cursor Stability or
Read Stability isolation levels to skip uncommitted inserted rows
as if they had not been inserted. This registry variable does not
impact the behavior of cursors on the DB2 catalog
tables. This registry variable is activated at database startup, while
the decision to skip uncommitted inserted rows is made at statement
compile or bind time.
Note: Skip inserted behavior is not compatible with tables that have pending rollout cleanup. As a result, scanners might wait for locks on a RID only to discover that the RID is part of a rolled out block.