db2pd and Lock Wait

db2pd has got to be one of my all time favourite tool. It is like the swiss knife of troubleshooting :)  But recently I found out that there is *one* thing that it can't do:

----> It can't display lock wait chain that is triggered  by a lock conversion <----

That is very surprising. Is it a bug? Given that the same lock chain can be displayed by db2top, so, it is really weird that db2pd has no visibility of such lock blocking.

Beware!

Mother of all fixpacks: DB2 10.5 LUW FP4

About a year ago, I wrote that DB2 BLU features are not compatible with 'DB2_COMPATIBILITY_VECTOR=ORA', ie, it does not allow the same DB to be 'Oracle compatible' while operating in BLU mode. That was a let down.

Curse no more. FP4 ( aka Cancun ) which was released a few weeks back has fixed that. This fixpack also adds char/varchar datatype to be 'data skip-able'. Now the whole BLU thing feels complete.

This fixpack also adds 'shadow table' to the mix, allowing the same data to be stored in 'row'  *and* 'column' format. That can be really useful in some scenarios. However, to set this up, you will also need CDC, and that makes the entire process rather painful ... hey, can DB2 BLU still claim to be 'easy'? I don't think so ;)

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 ....