Tuesday, July 29, 2014

When Lock Escalation meets CUR_COMMIT

If your database is configured to use currently committed ( ie, setting cur_commit = on), you will enjoy many of the benefits those Oracle users have been taking for granted for 20+ years, ie, row reader that does not block row writer, and writer does not block reader.

This is great! ... unless you encounter .... LOCK ESCALATION!

If, say , table T1 is being populated, and the data insert volume has triggered a lock escalation. What you will get is an "X" lock on T1, which prevents any reads on the same table due to the fact that a read requires an "IS" lock on the table first, which is incompatible with "X" lock.

Bummer! :)

DB2 still has a long way to go ....




No comments:

Post a Comment