Personal tools
You are here: Home DB2 How To's Variables to improve concurrency on DB2
Navigation
Log in


Forgot your password?
 
Document Actions

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.
 
Security Awareness
Would you like your company to implement gamification into your security awareness program?





Polls