Comments on: Unique Index Result Error with Ref Cursor on Oracle 11g but Not on 10g http://hoopercharles.wordpress.com/2011/06/06/unique-index-result-error-with-ref-cursor-on-oracle-11g-but-not-on-10g/ Miscellaneous Random Oracle Topics: Stop, Think, ... Understand Thu, 13 Jun 2013 22:46:43 +0000 hourly 1 http://wordpress.com/ By: Charles Hooper http://hoopercharles.wordpress.com/2011/06/06/unique-index-result-error-with-ref-cursor-on-oracle-11g-but-not-on-10g/#comment-3408 Tue, 07 Jun 2011 16:31:09 +0000 http://hoopercharles.wordpress.com/?p=4938#comment-3408 I had wondered if the reason why this is working with a non-unique index and a full table scan, but not a unique index is the result of Oracle Database restarting the transaction, as described here in Tom Kyte’s “Expert Oracle Database Architecture” book:
http://books.google.com/books?id=HPJDlGmecwcC&pg=PA263
A before update trigger on table T1indicated that the updated only happened once, and it happened before the PL/SQL route output “Processing is complete” (that was expected).

For fun I enabled a 10046 extended SQL trace and a 10200 consistent gets trace. Unless I am reading the consistent gets trace incorrectly (that is definitely possible), it does not appear that Oracle Database builds a consistent read copy of the table block when the unique index is used to select the rows, while it does build a consistent read copy of the table block when a non-unique index is used to select the rows:

Unique Index Retrieve:

ktrgtc2(): started for block <0x0007 : 0x01d9983b> objd: 0x00015fb1
  env [0x000000001620DFCC]: (scn: 0x0000.52b9a13b  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  statement num=0  parent xid: 0x0000.000.00000000  st-scn: 0x0000.00000000  hi-scn: 0x0000.00000000  ma-scn: 0x0000.52b9a05f  flg: 0x00000661)
ktrexc(): returning 2 on:  0000000016780288  cr-scn: 0xffff.ffffffff  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  cl-scn: 0xffff.ffffffff  sfl: 0
ktrgtc2(): completed for block <0x0007 : 0x01d9983b> objd: 0x00015fb1
ktrgtc2(): started for block <0x0007 : 0x01d99834> objd: 0x00015fb0
  env [0x000000001620DFCC]: (scn: 0x0000.52b9a13b  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  statement num=0  parent xid: 0x0000.000.00000000  st-scn: 0x0000.00000000  hi-scn: 0x0000.52b9a13d  ma-scn: 0x0000.52b9a05f  flg: 0x00000662)
ktrexc(): returning 9 on:  0000000016780288  cr-scn: 0xffff.ffffffff  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  cl-scn: 0xffff.ffffffff  sfl: 0
ktrgtc2(): completed for block <0x0007 : 0x01d99834> objd: 0x00015fb0
FETCH #371953016:c=0,e=143,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=1,plh=1735687405,tim=1978249455074
STAT #371953016 id=1 cnt=0 pid=0 pos=1 obj=90032 op='TABLE ACCESS BY INDEX ROWID T1 (cr=2 pr=0 pw=0 time=137 us cost=1 size=25 card=1)'
STAT #371953016 id=2 cnt=1 pid=1 pos=1 obj=90033 op='INDEX UNIQUE SCAN IND_T1_U (cr=1 pr=0 pw=0 time=68 us cost=0 size=0 card=1)'

Non-Unique Index

ktrgtc2(): started for block <0x0007 : 0x01d9983b> objd: 0x00015fb7
  env [0x00000000198CBF5C]: (scn: 0x0000.52b9a528  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  statement num=0  parent xid: 0x0000.000.00000000  st-scn: 0x0000.00000000  hi-scn: 0x0000.00000000  ma-scn: 0x0000.52b9a468  flg: 0x00000661)
ktrexc(): returning 8 on:  000000001F2C8E98  cr-scn: 0xffff.ffffffff  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  cl-scn: 0xffff.ffffffff  sfl: 0
ktrgtc2(): completed for block <0x0007 : 0x01d9983b> objd: 0x00015fb7
ktrget2(): started for block  <0x0007 : 0x01d99833> objd: 0x00015fb6
env [0x00000000198CBF5C]: (scn: 0x0000.52b9a528  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  statement num=0  parent xid: 0x0000.000.00000000  st-scn: 0x0000.00000000  hi-scn: 0x0000.00000000  ma-scn: 0x0000.52b9a468  flg: 0x00000661)
ktrexf(): returning 9 on:  000000001F2C8E98  cr-scn: 0xffff.ffffffff  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  cl-scn: 0xffff.ffffffff  sfl: 0
kcbchg updating CR fields for 0x00000001D1F873F8, 31037491; 0:52b9a528
kcbchg new CR fields for 0x00000001D1F873F8, 31037491; 0:52b9a528
ktrgcm(): completed for block  <0x0007 : 0x01d99833> objd: 0x00015fb6
ktrget2(): completed for  block <0x0007 : 0x01d99833> objd: 0x00015fb6
FETCH #452951904:c=0,e=196,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=1,plh=634656657,tim=1979147455414
ktrget2(): started for block  <0x0007 : 0x01d9983b> objd: 0x00015fb7
env [0x00000000198CBF5C]: (scn: 0x0000.52b9a528  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  statement num=0  parent xid: 0x0000.000.00000000  st-scn: 0x0000.00000000  hi-scn: 0x0000.00000000  ma-scn: 0x0000.52b9a468  flg: 0x00000660)
ktrexf(): returning 9 on:  000000001F2C8E98  cr-scn: 0xffff.ffffffff  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  cl-scn: 0xffff.ffffffff  sfl: 0
ktrgcm(): completed for block  <0x0007 : 0x01d9983b> objd: 0x00015fb7
ktrget2(): completed for  block <0x0007 : 0x01d9983b> objd: 0x00015fb7
FETCH #452951904:c=0,e=82,p=0,cr=1,cu=0,mis=0,r=0,dep=1,og=1,plh=634656657,tim=1979147455578
STAT #452951904 id=1 cnt=1 pid=0 pos=1 obj=90038 op='TABLE ACCESS BY INDEX ROWID T1 (cr=4 pr=0 pw=0 time=190 us cost=1 size=25 card=1)'
STAT #452951904 id=2 cnt=1 pid=1 pos=1 obj=90039 op='INDEX RANGE SCAN IND_T1 (cr=2 pr=0 pw=0 time=150 us cost=1 size=0 card=1)'

Full Table Retrieve:

ktrget2(): started for block  <0x0007 : 0x01d99833> objd: 0x00015fb2
env [0x00000000198B970C]: (scn: 0x0000.52b9a294  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  statement num=0  parent xid: 0x0000.000.00000000  st-scn: 0x0000.00000000  hi-scn: 0x0000.00000000  ma-scn: 0x0000.52b9a1cf  flg: 0x00000661)
ktrexf(): returning 9 on:  000000001F2C8E98  cr-scn: 0xffff.ffffffff  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  cl-scn: 0xffff.ffffffff  sfl: 0
ktrgcm(): completed for block  <0x0007 : 0x01d99833> objd: 0x00015fb2
ktrget2(): completed for  block <0x0007 : 0x01d99833> objd: 0x00015fb2
ktrget2(): started for block  <0x0007 : 0x01d99834> objd: 0x00015fb2
env [0x00000000198B970C]: (scn: 0x0000.52b9a294  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  statement num=0  parent xid: 0x0000.000.00000000  st-scn: 0x0000.00000000  hi-scn: 0x0000.00000000  ma-scn: 0x0000.52b9a1cf  flg: 0x00000660)
ktrexf(): returning 9 on:  000000001F2C8E98  cr-scn: 0xffff.ffffffff  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  cl-scn: 0xffff.ffffffff  sfl: 0
ktrgcm(): completed for block  <0x0007 : 0x01d99834> objd: 0x00015fb2
ktrget2(): completed for  block <0x0007 : 0x01d99834> objd: 0x00015fb2
ktrget2(): started for block  <0x0007 : 0x01d99835> objd: 0x00015fb2
env [0x00000000198B970C]: (scn: 0x0000.52b9a294  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  statement num=0  parent xid: 0x0000.000.00000000  st-scn: 0x0000.00000000  hi-scn: 0x0000.00000000  ma-scn: 0x0000.52b9a1cf  flg: 0x00000660)
ktrexf(): returning 9 on:  000000001F2C8E98  cr-scn: 0xffff.ffffffff  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  cl-scn: 0xffff.ffffffff  sfl: 0
ktrgcm(): completed for block  <0x0007 : 0x01d99835> objd: 0x00015fb2
ktrget2(): completed for  block <0x0007 : 0x01d99835> objd: 0x00015fb2
ktrget2(): started for block  <0x0007 : 0x01d99836> objd: 0x00015fb2
env [0x00000000198B970C]: (scn: 0x0000.52b9a294  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  statement num=0  parent xid: 0x0000.000.00000000  st-scn: 0x0000.00000000  hi-scn: 0x0000.00000000  ma-scn: 0x0000.52b9a1cf  flg: 0x00000660)
ktrexf(): returning 9 on:  000000001F2C8E98  cr-scn: 0xffff.ffffffff  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  cl-scn: 0xffff.ffffffff  sfl: 0
ktrgcm(): completed for block  <0x0007 : 0x01d99836> objd: 0x00015fb2
ktrget2(): completed for  block <0x0007 : 0x01d99836> objd: 0x00015fb2
ktrget2(): started for block  <0x0007 : 0x01d99837> objd: 0x00015fb2
env [0x00000000198B970C]: (scn: 0x0000.52b9a294  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  statement num=0  parent xid: 0x0000.000.00000000  st-scn: 0x0000.00000000  hi-scn: 0x0000.00000000  ma-scn: 0x0000.52b9a1cf  flg: 0x00000660)
ktrexf(): returning 9 on:  000000001F2C8E98  cr-scn: 0xffff.ffffffff  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  cl-scn: 0xffff.ffffffff  sfl: 0
ktrgcm(): completed for block  <0x0007 : 0x01d99837> objd: 0x00015fb2
ktrget2(): completed for  block <0x0007 : 0x01d99837> objd: 0x00015fb2

Maybe someone can explain why a consistent read copy of the table block was not created when a unique index was used?

]]> By: Select For Update fetching across commit « OraStory http://hoopercharles.wordpress.com/2011/06/06/unique-index-result-error-with-ref-cursor-on-oracle-11g-but-not-on-10g/#comment-3402 Tue, 07 Jun 2011 10:45:35 +0000 http://hoopercharles.wordpress.com/?p=4938#comment-3402 [...] was another one yesterday from Charles Hooper that definitely must be a bug because it’s related to whether a unique index is used as the [...]

]]> By: Dom Brooks http://hoopercharles.wordpress.com/2011/06/06/unique-index-result-error-with-ref-cursor-on-oracle-11g-but-not-on-10g/#comment-3399 Tue, 07 Jun 2011 09:20:21 +0000 http://hoopercharles.wordpress.com/?p=4938#comment-3399 Hi Mohamed,

I’m just doing an upgrade from 9.2.0.8 to 11.2.0.2 and a whole rack of PLSQL code doing exactly this was just revealed, thanks to this behaviour change (thank goodness). It may be that as far back as 7 that the behaviour was the same, I can’t remember now. Certainly in 9.2.0.8 the commit just releases the locks.

I can’t now seem to find the metalink note that I had previously regarding this change being explicitly implemented in 10.2.0.5.

Cheers,
Dominic

]]> By: Houri Mohamed http://hoopercharles.wordpress.com/2011/06/06/unique-index-result-error-with-ref-cursor-on-oracle-11g-but-not-on-10g/#comment-3397 Tue, 07 Jun 2011 07:16:51 +0000 http://hoopercharles.wordpress.com/?p=4938#comment-3397 Dom,

I am not sure that the ora-1002 fetch out of sequence started to manifest itselve since 10.2.0.5.

I did remember reading an oracle documentation for Oracle 7 which was speaking about the error we will have when commiting inside a loop driven by a select for update.

Mohamed Houri

]]> By: Charles Hooper http://hoopercharles.wordpress.com/2011/06/06/unique-index-result-error-with-ref-cursor-on-oracle-11g-but-not-on-10g/#comment-3384 Mon, 06 Jun 2011 15:05:24 +0000 http://hoopercharles.wordpress.com/?p=4938#comment-3384 Dom,

Thanks for providing the link to Jonathan’s article. I remembered reading a quote somewhere, but I could not remember where:

“It doesn’t really matter whether you think the old behaviour or the new behaviour is correct – the problem is that the behaviour has changed in a way that could silently produce unexpected results.”

Are you able to confirm that you see the problem in 10.2.0.5. I tested 10.2.0.5 in 64 bit Windows and was able to reproduce the problem. I then tested 10.2.0.4 in 32 bit Windows and could not reproduce the problem. The MOS (Metalink) Bug article states that the problem is not present in 10.2.0.5 on one of the Unix platforms (Solaris), but I am curious to know if the problem is found only in the Windows release of 10.2.0.5 (it was released after most of the Linux/Unix platforms and included additional bug fixes).

]]> By: Dom Brooks http://hoopercharles.wordpress.com/2011/06/06/unique-index-result-error-with-ref-cursor-on-oracle-11g-but-not-on-10g/#comment-3383 Mon, 06 Jun 2011 14:51:38 +0000 http://hoopercharles.wordpress.com/?p=4938#comment-3383 It’s interesting that it’s in 10.2.0.5 that this first crops up.

I believe that that is the version when a commit inside a loop driven by a select for update started to raise an ora-1002 fetch out of sequence (a good change to protect against a flawed coding habit).

]]> By: Dom Brooks http://hoopercharles.wordpress.com/2011/06/06/unique-index-result-error-with-ref-cursor-on-oracle-11g-but-not-on-10g/#comment-3382 Mon, 06 Jun 2011 14:38:18 +0000 http://hoopercharles.wordpress.com/?p=4938#comment-3382 Very worrying.

When you consider other evidence such as this – http://jonathanlewis.wordpress.com/2011/03/20/upgrade-whoa/ – it’s hard not to come to the conclusion that core developers have been somewhat careless in and around the read consistency mechanism in recent years.

]]>