DB2 Version This Was Written For
9.7
Parameter Name
DB2_SKIPDELETED
Where This Parameter Lives
DB2 Registry (db2set)
How To Check Value
> db2set -all |grep DB2_SKIPDELETED [i] DB2_SKIPDELETED=YES [DB2_WORKLOAD]
OR
> db2 "select substr(reg_var_name,1,32) name, substr(reg_var_value,1,16) value, level, is_aggregate, substr(aggregate_name,1,32) aggregate_name from SYSIBMADM.reg_variables where reg_var_name='DB2_SKIPDELETED' with ur" NAME VALUE LEVEL IS_AGGREGATE AGGREGATE_NAME -------------------------------- ---------------- ----- ------------ -------------------------------- DB2_SKIPDELETED YES I 0 DB2_WORKLOAD
Description
Affects db2’s locking/scanning behavior when using CS or RS isolation levels. Causes DB2 to skip deleted rows and keys. Variable is activated at database start time, and is engaged (or not) at statement compile or bind time.
This variable can still have an effect if Currently Commited behavior is enabled (CUR_COMMIT) – though it only is engaged when currently committed semantics will not help avoid lock contentions.
Impact
Can reduce locking/deadlocking and increase concurrency if applications can tolerate the data integrity changes. Potentially dangerous if the application does not explicitly support this behavior.
Default
NO/OFF
Range/Values
ON, OFF
Recycle Required To Take Effect?
Yes
Can It Be Set To AUTOMATIC?
No, there is no AUTOMATIC option for this parameter.
How To Change It
db2set DB2_SKIPDELETED=YES
Rule of Thumb
If your application does not explicitly support it, do not set this parameter – leave it at the default of NO.
Tuning Considerations
The main consideration here is if your application supports this value. If your application supports this behavior, you should set this parameter.
Along with DB2_SKIPINSERTED and DB2_EVALUNCOMMITTED, you can drastically reduce deadlocking.
Related Error Messages
War Stories From The Real World
WebSphere Commerce has supported DB2_SKIPINSERTED, DB2_SKIPDELETED, and DB2_EVALUNCOMMITTED for years. They’re now part of the aggregate DB2 Registry setting DB2_WORKLOAD=WC, but we were setting them independently long before that. I have personally seen them cause a WebSphere Commerce site go from having dozens of deadlocks per day to just one or two. So for WebSphere Commerce databases, they absolutely must be set.
I wonder how having the three related parameters set is different from Currently Committed behavior available in DB2 9.7?
Think long and hard before enabling this, because you are changing the behavior of your isolation level by enabling this, and may allow concurrency phenomena that you did not intend.
