.
\nThis follows the comments on Clemens Bleile post about SQL Plan Directives in Oracle 12.2 where he discovered a new behavior that is not documented. The feature is good: bypass the cardinality feedback overhead when the query is fast anyway.
\n
In Clemens Bleile post about SQL Plan Directives changes in 12cR2 he determined than the new feature coming in bug 23596611 was responsible for the bypass of automatic reoptimization (the 12c cardinality feedback) in some cases.
\nThe description gives the idea that the reason for the bypass of cardinality feedback is ‘small queries’:
\nSQL> select BUGNO,SQL_FEATURE,DESCRIPTION,OPTIMIZER_FEATURE_ENABLE from v$system_fix_control where bugno=23596611;\n \n BUGNO SQL_FEATURE DESCRIPTION OPTIMIZER_FEATURE_ENABLE\n---------- ------------------------------ -------------------------------------- -------------------------\n 23596611 QKSFM_STATS_FEEDBACK_23596611 No feedback for small queries 12.2.0.1This is a new concept and in the traces we know there is nothing about ‘small queries’. Here is how to get more information.
\nFirst, I’m looking for the ‘small queries’ text in the oracle executable:
\n$ strings $ORACLE_HOME/bin/oracle | grep \"small query\"\nkkocfbCheckCardEst: No feedback for small query (BG %f, CPU %f (ms)\nkkocfbCompareExecStats: skipping cost comparision forsmall query (BG %f, CPU %f (ms)Good. This looks like there is a way to trace some information about that bypass decision, and there’s a clue that ‘small queries’ are evaluated on number of buffer gets (BG) and CPU time threshold. More than that, we have the name of the C function that traces this: kkocfbCheckCardEst
\nkkocfb probably means:
\n\n\n\n@johnnyq72 it’s kernel kompile costing cardinality feedback probably. and it seems there is a trace function…
\n— Frits Hoogland (@fritshoogland) January 4, 2017
and then I’m looking for a way to get this trace. I didn’t know which event can trace that, but others know:
\n\n\n\nare you talking about event 10507 level 512?
\n— Mauro Pagano (@Mautro) January 4, 2017
However there is another way to get an idea of the events that are checked by a function.
\nThe idea is described here: http://yong321.freeshell.org/computer/OracleFuncCalls.html
We are not allowed to disassemble oracle code (this is in the licensing rules that you accept when you download oracle) so I’ll not do it here.
\nIf you think you have a special permission to do it, just run:
gdb oracle <<<"disas kkocfbCheckCardEst"I can’t show the dissassembled code, so here is how to get the list of the events that are checked by the kkocfbCheckCardEst function:
\n$ gdb oracle <<<"disas kkocfbCheckCardEst" | awk --non-decimal-data '/mov .*,%edi$/{gsub(/[$,]/," ");a=$4}/EventRdbmsErr/{printf "%dn", a}' | sort -u\n10507The information we have about this event does not describe all what can be traced:
\n$ oerr ora 10507\n10507, 00000, \"Trace bind equivalence logic\"\n// *Cause:\n// *Action:From that, I don’t know which level to set the event, but in case of doubt and because levels are often bit flags, you can set it to the maximum 0xFFFFFFFF:
\n\nalter session set events '10507 trace name context forever, level 4294967295';\nWhen I run the query where execution is doing less than 100 buffer gets I get the following trace with event 10507 level 512:
\n\n****** Begin CFB Hints (APA) [sql_id=a71qw8t17qpqq] xsc=0x7fca901f0e30 ctx=0x9415d4f8 ******\nDumping Hints\n=============\n*********** End CFB Hints (APA) ***********\nkkocfbInitCardFdbkCompCtx [sql_id=a71qw8t17qpqq] monitor=y\nkkocfbCheckCardEst: No feedback for small query (BG 0.000000, CPU 0.000000 (ms)\nThe message is clear: no feedback for small query. The Buffer Get and CPU show 0 but on my test case, increasing the size of the table, I have seen that 100 buffer gets is the threshold:
\n\nbq4fc1rdx97av is_reoptimizable: N buffer_gets: 95 cpu_time: 0\nbq4fc1rdx97av is_reoptimizable: N buffer_gets: 95 cpu_time: 1000\nbq4fc1rdx97av is_reoptimizable: N buffer_gets: 96 cpu_time: 1000\nbq4fc1rdx97av is_reoptimizable: N buffer_gets: 96 cpu_time: 1000\nbq4fc1rdx97av is_reoptimizable: N buffer_gets: 97 cpu_time: 0\nbq4fc1rdx97av is_reoptimizable: N buffer_gets: 97 cpu_time: 0\nbq4fc1rdx97av is_reoptimizable: N buffer_gets: 98 cpu_time: 1000\nbq4fc1rdx97av is_reoptimizable: N buffer_gets: 98 cpu_time: 0\nbq4fc1rdx97av is_reoptimizable: N buffer_gets: 99 cpu_time: 1000\nbq4fc1rdx97av is_reoptimizable: N buffer_gets: 99 cpu_time: 0\nbq4fc1rdx97av is_reoptimizable: Y buffer_gets: 100 cpu_time: 1000\nbq4fc1rdx97av is_reoptimizable: Y buffer_gets: 100 cpu_time: 1000\nbq4fc1rdx97av is_reoptimizable: Y buffer_gets: 101 cpu_time: 1000\nbq4fc1rdx97av is_reoptimizable: Y buffer_gets: 101 cpu_time: 0\nbq4fc1rdx97av is_reoptimizable: Y buffer_gets: 102 cpu_time: 0\nbq4fc1rdx97av is_reoptimizable: Y buffer_gets: 102 cpu_time: 1000\nWhen the query reads more than 100 buffer gets, the cursor is marked as reoptimizable and here is the trace:
\n\n****** Begin CFB Hints (APA) [sql_id=a71qw8t17qpqq] xsc=0x7fed7dc2ca40 ctx=0x9418f4f8 ******\nDumping Hints\n=============\n*********** End CFB Hints (APA) ***********\nkkocfbInitCardFdbkCompCtx [sql_id=a71qw8t17qpqq] monitor=y\nReparsing due to card est...\n @=0x95426550 type=1 nodeid=1 monitor=Y halias=\"DEMO_TABLE\" loc=\"SEL$1\" act=500 min=0 est=63 next=(nil)\nkkocfbCheckCardEst [sql_id=a71qw8t17qpqq] reparse=y ecs=n efb=n ost=n fbs=n\n *********** Begin Dump Context (kkocfbCheckCardEst) [sql_id=a71qw8t17qpqq cpcnt=0] ***********\n @=0x95426550 type=1 nodeid=1 monitor=Y halias=\"DEMO_TABLE\" loc=\"SEL$1\" act=500 min=0 est=63 next=(nil)\n *********** End Dump Context ***********\nact=500 is the actual number of rows (A-Rows) and est=63 is the estimated one (A-Rows) and this is how misestimate is detected.
\nAt that point we can see the feedback as OPT_ESTIMATE hints in v$sql_reoptimization_hints.
\nWhen we run the same query another time, it is parsed again with those hits, fixing cardinality tho the A-Rows of previous execution.
\nHere is the trace for this second execution.
\n\nkkoarCopyCtx: [sql_id=a71qw8t17qpqq] origin=CFB old=0x63904140 new=0x7fcda3716d40 copyCnt=1 copyClient=y\n**************************************************************\nkkocfbCopyBestEst: Best Stats\n Exec count: 1\n CR gets: 279\n CU gets: 4\n Disk Reads: 0\n Disk Writes: 0\n IO Read Requests: 0\n IO Write Requests: 0\n Bytes Read: 0\n Bytes Written: 0\n Bytes Exchanged with Storage: 0\n Bytes Exchanged with Disk: 0\n Bytes Simulated Read: 0\n Bytes Simulated Returned: 0\n Elapsed Time: 6998 (us)\n CPU Time: 2000 (us)\n User I/O Time: 0 (us)\n *********** Begin Dump Context (kkocfbCopyBestEst) **********\n *********** End Dump Context ***********\nkkocfbCopyCardCtx: oldCtx Dumping string mapping\n----------------------\nkkocfbCopyCardCtx: newCtx Dumping string mapping\n----------------------\n**************************************************************\nkkocfbCopyCardCtx: Best stats\n Exec count: 1\n CR gets: 279\n CU gets: 4\n Disk Reads: 0\n Disk Writes: 0\n IO Read Requests: 0\n IO Write Requests: 0\n Bytes Read: 0\n Bytes Written: 0\n Bytes Exchanged with Storage: 0\n Bytes Exchanged with Disk: 0\n Bytes Simulated Read: 0\n Bytes Simulated Returned: 0\n Elapsed Time: 6998 (us)\n CPU Time: 2000 (us)\n User I/O Time: 0 (us)\n **** Begin Dump Context (kkocfbCopyCardCtx - best est) ****\n ********************* End Dump Context ********************\n *********** Begin Dump Context (Copy:old) [sql_id=a71qw8t17qpqq cpcnt=0] ***********\n @=0x6446dc58 type=1 nodeid=1 monitor=Y halias=\"DEMO_TABLE\" loc=\"SEL$1\" act=500 min=0 est=63 next=(nil)\n *********** End Dump Context ***********\n *********** Begin Dump Context (Copy:new) [sql_id=a71qw8t17qpqq cpcnt=0] ***********\n @=0x7fcda3716a78 type=1 nodeid=1 monitor=Y halias=\"DEMO_TABLE\" loc=\"SEL$1\" act=500 min=0 est=63 next=(nil)\n *********** End Dump Context ***********\nkkoarReparse: xsc=0x7fcda3672b98 kxsAutoReoptCtx=0x7fcda3716d40\nkkocfbAddCardHints: Dumping string mapping\n----------------------\n******** Begin CFB Hints [sql_id=a71qw8t17qpqq] xsc=0x7fcda3672b98 ********\nDumping Hints\n=============\n atom_hint=(@=0x7fcda37831e8 err=0 resol=0 used=0 token=1018 org=6 lvl=3 txt=OPT_ESTIMATE (@\"SEL$1\" TABLE \"DEMO_TABLE\"@\"SEL$1\" ROWS=500.000000 ) )\n********** End CFB Hints **********\nYou can see the OPT_ESTIMATE hints here.
\n\n****** Begin CFB Hints (APA) [sql_id=a71qw8t17qpqq] xsc=0x7fcda3672b98 ctx=0x8a274118 ******\nDumping Hints\n=============\n atom_hint=(@=0x7fcda37831e8 err=0 resol=1 used=0 token=1018 org=6 lvl=3 txt=OPT_ESTIMATE (@\"SEL$1\" TABLE \"DEMO_TABLE\"@\"SEL$1\" ROWS=500.000000 ) )\n atom_hint=(@=0x7fcda3782d10 err=0 resol=1 used=0 token=1018 org=6 lvl=3 txt=OPT_ESTIMATE (@\"SEL$1\" TABLE \"DEMO_TABLE\"@\"SEL$1\" ROWS=500.000000 ) )\n*********** End CFB Hints (APA) ***********\nkkocfbInitCardFdbkCompCtx [sql_id=a71qw8t17qpqq] monitor=y\n**************************************************************\nkkocfbCopyBestEst: Best Stats\n Exec count: 1\n CR gets: 279\n CU gets: 4\n Disk Reads: 0\n Disk Writes: 0\n IO Read Requests: 0\n IO Write Requests: 0\n Bytes Read: 0\n Bytes Written: 0\n Bytes Exchanged with Storage: 0\n Bytes Exchanged with Disk: 0\n Bytes Simulated Read: 0\n Bytes Simulated Returned: 0\n Elapsed Time: 6998 (us)\n CPU Time: 2000 (us)\n User I/O Time: 0 (us)\n *********** Begin Dump Context (kkocfbCopyBestEst) **********\n *********** End Dump Context ***********\nkkocfbCheckCardEst [sql_id=a71qw8t17qpqq] reparse=n ecs=n efb=y ost=n fbs=n\nWith those adaptive feature it is good to be able to trace the decisions in order to understand and reproduce the problems we encounter. Event 10507 is very useful. It’s the execution time counterpart for the event 10053 which explains compile time decision. And in latest versions, the optimizer is more and more present at execution time.
\nWe have always seen problems coming from cardinality feedback. Most of them are coming from bad statistics or a data model where there is not one optimal access plan. Then the CBO is always trying to find better and sometimes the best is the enemy of the good.
\nNow in 12.2 you have a very good way to avoid the cardinality feedback side effect: tune your queries and your data model so that the critical queries read less than 100 logical reads.