0096635C3 109CB2C50
200000000000000 000000000
110C221E8 110A597A0
dbgexPhaseII()+1212 call ksfdmp() 000002004 110A597A0
000000000 FFFFFFFFFFEC658
FFFFFFFFFFEC580
FFFFFFFFFFECCA8 1001D04B8
110C221E8
dbgexProcessError() call dbgexPhaseII() 110A597A0 110C203F8
+3604 0000296E8 200000000
FFFFFFFFFFED258 00000006A
000000000 000000000
dbgeExecuteForError call dbgexProcessError() 110A597A0 110C221E8
()+72 100000000 000000000
110D01C88 000000000
110CADC78 110C23F30
dbgePostErrorKGE()+ call dbgeExecuteForError FFFFFFFFFFF0830
1152 () B7417335409B9B1B
FFFFFFFFFFF06F0 0409B9800
10524EA10
2147AE154168E65F
10524EA10 000000000
dbkePostKGE_kgsf()+ call dbgePostErrorKGE() 002050000 001160000
64 25810001330 000000000
110001330 FFFFFFFFFFF1510
109613CD0 110CB3F18
这个SQL错误的奇特之处在于，如果将ORDER BY语句中的a.policyno变成其他列，则不会导致错误，甚至是换成与之相等关联的f.policyno，同样不会报错。
这显然是一个bug，查询metalink发现，居然目前唯一确认影响的版本就是11.2.0.2，这个Bug的描述为Bug 12591252 Query with ORDER BY fails with ORA-600 [kkoipt:invalid join method]。而Oracle的解释是，优化器试图通过索引来避免排序操作时，可能引发这个bug。这正好说明了为什么SQL中换成其他的列就不会导致错误。
目前这个bug在Windows平台的11.2.0.2的patch 10中被fixed，其他平台只能通过单独的12591252补丁来解决这个问题。当然如果能通过改写SQL来实现这个目的，无疑代价是最小的。