DML restart and tracked columns

Which columns are rely tracked by oracle to grantee write consistency and if needed trigger a DML restart when using the default statement-level consistency ?

Sometimes you may see strange ,unexpected behavior and write consistency bugs because not all the columns that are supposed to be tracked ,are really tracked !

Just check the following articles :

A bug from 2011 (still there in 18c) : http://db-blog.web.cern.ch/blog/franck-pachot/2018-09-oracle-write-consistency-bug-and-multi-thread-de-queuing

A Bug from 2006  (still there in 12.2) : http://blog.sqlora.com/en/merge-and-ora-30926-part-2-or-differences-in-write-consistency-between-update-and-merge/

So how to know it the columns that are supposed to be tracked really are ? I’m going only to treat UPDATE and MERGE statement here.

Write consistency : Not all restarts are equals

When writing my blog post Write consistency and DML restart i noticed something that had motivated me to dig deeper. And here we go !

Oracle Linux UEK 5 : DTrace and the PID provider

The UEK5 kernel is out and as usually  there is many enhancements and new features included in it ! One of the notable new feature is the dtrace PID provider Which allow  setting “function boundary probes on user space functions, and to probe most arbitrary instructions within user space functions”  check uek5-features-dtrace

Let’s give it a try :