|在“Locking and Deadlocks”一节的“Applications Slow or Appear to Hang”小节中，将“Lock waits or deadlocks are not caused by next key locking”下的描述更改为以下内容：
|Next key locking guarantees Repeatable Read (RR) |isolation level by automatically locking the next key for all INSERT and DELETE |statements and the next higher key value above the result set for SELECT statements. |For UPDATE statements that alter key parts of an index, the original index |key is deleted and the new key value is inserted. Next key locking is done |on both the key insertion and key deletion. It is required to guarantee ANSI |and SQL92 standard RR, and is the DB2 default.
|Examine snapshot information for the application. If the problem appears |to be with next key locking, you can set the DB2_RR_TO_RS option on if none |of your applications rely on Repeatable Read (RR) behavior and it is acceptable |for scans to skip over uncommitted deletes.
|When DB2_RR_TO_RS is on, RR behavior cannot be guaranteed for scans on |user tables because next key locking is not done during index key insertion |and deletion. Catalog tables are not affected by this option.
|The other change in behavior is that with DB2_RR_TO_RS on, scans will skip |over rows that have been deleted but not committed, even though the row may |have qualified for the scan.
|For example, consider the scenario where transaction A deletes the row |with column1=10 and transaction B does a scan where column1>8 and column1<12.
|With DB2_RR_TO_RS off, transaction B will wait for transaction A to commit |or rollback. If it rolls back, the row with column1=10 will be included in |the result set of transaction B's query.
|With DB2_RR_TO_RS on, transaction B will not wait for transaction A to |commit or rollback. It will immediately receive query results that do not |include the deleted row.
|Do not use this option if you require ANSI and SQL92 standard RR or if |you do not want scans to skip uncommitted deletes.