Following on from Monday’s posting about reading execution plans and related information, I noticed a question on the ODC database forum asking about the difference between “in ({list of values})” and a list of “column = {constant}” predicates connected by OR. The answer to the question is that there’s essentially no difference as you would be able to see from the predicate section of an execution plan:
SELECT c1, c2, c3, c4, c5, c6, c7, c8..
FROM TAB1
WHERE STS IN ( 'A', 'B')
AND cnt < '4'
AND dt < sysdate
and rownum <=1;
---------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 1847 | 33399 (1)| 00:03:14 |
|* 1 | COUNT STOPKEY | | | | | |
| 2 | INLIST ITERATOR | | | | | |
|* 3 | TABLE ACCESS BY INDEX ROWID| TAB1 | 114K| 201M| 33399 (1)| 00:03:14 |
|* 4 | INDEX RANGE SCAN | TAB1_STS_IDX | 114K| | 723 (1)| 00:00:05 |
---------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(ROWNUM<=1)
3 - filter("cnt"<'4' AND "dt"<SYSDATE@!)
4 - access("STS"='A' OR "STS"='B')
Note how the predicate section tells you that the original “sts in ( ‘A’, ‘B’ )” has been transformed into “sts = ‘A’ or sts = ‘B'”.
A further point I made about IN-lists in Monday’s post was that as one step in the transformation Oracle would sort the list and eliminate duplicates, and it suddenly occurred to me to wonder whether Oracle would sort the list in descending order if the only relevant index were defined to start with a descending column. Naturally I had to try it so here’s a suitable script to prepare some data:
rem
rem Script: descending_bug_06.sql
rem Author: Jonathan Lewis
rem Dated: Aug 2018
rem Purpose:
rem
rem Last tested
rem 18.3.0.0 Crashes
rem 12.2.0.1 Crashes
rem 12.1.0.2 Crashes
rem 11.2.0.4 Bad Plan
rem
create table t1
nologging
pctfree 95 pctused 5
as
with generator as (
select
rownum id
from dual
connect by
level <= 1e4 -- > comment to avoid WordPress format issue
)
select
rownum id,
lpad(rownum,10,'0') v1,
case mod(rownum,1000)
when 0 then 'A'
when 3 then 'B'
when 6 then 'C'
else 'D'
end sts,
case mod(rownum,1000)
when 0 then '1'
when 3 then '2'
when 6 then '3'
else '4'
end cnt,
lpad('x',100,'x') padding
from
generator v1,
generator v2
where
rownum <= 1e5 -- > comment to avoid WordPress format issue
;
create index t1_i1a on t1(sts) nologging;
create index t1_i1d on t1(sts desc) nologging;
begin
dbms_stats.gather_table_stats(
ownname => null,
tabname => 'T1',
method_opt => 'for all columns size skewonly'
);
end;
/
There is one oddity in this script – if you’ve got every column in an index declared as DESC you’ve made a mistake and none of the columns should be declared as DESC. The feature is relevant only if you want a mixture of ascending and descending column in a single index.
An important detail of the script is that I’ve gathered stats AFTER creating the objects – it’s important to do this, even in 18.3, because (a) creating the “descending” index will result in a hidden virtual column being created to represent the descending column and I want make sure I have stats on that column and (b) the “stats on creation” code doesn’t generate histograms and I want a (frequency) histogram on columns sts and the hidden, virtual, descending version of the column.
After generating the data and checking that I have the correct histograms for sts and sys_nc00006$ (the relevant hidden column) I can then run the following test:
set serveroutput off
alter session set statistics_level = all;
alter index t1_i1d invisible;
select sts, count(*)
from t1
where sts in ('B','C')
group by
sts
;
select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));
alter index t1_i1d visible;
alter index t1_i1a invisible;
select sts, count(*)
from t1
where sts in ('B','C')
group by
sts
;
select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));
alter session set statistics_level = typical;
set serveroutput on
The code makes one index invisible then runs a query that should use an inlist iterator; then it switches indexes making the invisible one visible and vice versa and repeats the query. I’ve enabled rowsource execution statistics and pulled the execution plans from memory to make sure I don’t get fooled by any odd glitches that might exist within “explain plan”. Here are the results from 11.2.0.4 – normal index, then descending index – with a little cosmetic cleaning:
S COUNT(*)
- ----------
B 100
C 100
SQL_ID f20u42pmw1z6w, child number 0
-------------------------------------
select sts, count(*) from t1 where sts in ('B','C') group by sts
-----------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 2 |00:00:00.01 | 5 |
| 1 | SORT GROUP BY NOSORT| | 1 | 2 | 2 |00:00:00.01 | 5 |
| 2 | INLIST ITERATOR | | 1 | | 200 |00:00:00.01 | 5 |
|* 3 | INDEX RANGE SCAN | T1_I1A | 2 | 178 | 200 |00:00:00.01 | 5 |
-----------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access(("STS"='B' OR "STS"='C'))
Index altered.
Index altered.
S COUNT(*)
- ----------
C 100
B 100
SQL_ID f20u42pmw1z6w, child number 0
-------------------------------------
select sts, count(*) from t1 where sts in ('B','C') group by sts
-----------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 2 |00:00:00.02 | 198 |
| 1 | SORT GROUP BY NOSORT| | 1 | 2 | 2 |00:00:00.02 | 198 |
|* 2 | INDEX FULL SCAN | T1_I1D | 1 | 1000 | 200 |00:00:00.02 | 198 |
-----------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter((SYS_OP_UNDESCEND("T1"."SYS_NC00006$")='B' OR
SYS_OP_UNDESCEND("T1"."SYS_NC00006$")='C'))
As expected we see counts of 100 for ‘B’s and ‘C’s, and we also see that the “sort group by nosort” operation with the descending index has produced the results in reverse order. The problem though is that the optimizer has decided to use an “index full scan” on the descending index, and the estimate of the rows returned is terribly wrong (and seems to be the common “5% guess”, used once for each target value), and the number of buffer visits is huge compared to the result from the normal index – Oracle really did walk every leaf block in the index to get this result. The predicate section also looks rather silly – why hasn’t the optimizer produced predicates more like: “sys_nc00006$ = sys_op_descend(‘B’)” ?
In passing you’ll notice that the estimated rows in the plan using the normal index is a little low. This is the result of Oracle using a small sample (ca. 5,500 rows) in 11g to gather histogram stats. 12c will do better for a frequency histogram with the fast algorithm it uses for a 100% (auto) sample size.
So 11g doesn’t do very well but we’ve got 12.1.0.2, 12.2.0.1, and (in the last couple of weeks) 18.3 to play with. Here’s the result from 12.1.0.2 and 12.2.0.1 for the query that should use the descending index:
select sts, count(*)
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [qernsRowP], [1], [], [], [], [], [], [], [], [], [], []
SQL_ID f20u42pmw1z6w, child number 0
-------------------------------------
select sts, count(*) from t1 where sts in ('B','C') group by sts
-----------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 0 |00:00:00.01 | 0 |
| 1 | SORT GROUP BY NOSORT| | 1 | 2 | 0 |00:00:00.01 | 0 |
| 2 | INLIST ITERATOR | | 1 | | 101 |00:00:00.03 | 5 |
|* 3 | INDEX RANGE SCAN | T1_I1D | 2 | 200 | 101 |00:00:00.01 | 5 |
-----------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access(("T1"."SYS_NC00006$"=SYS_OP_DESCEND('B') OR
"T1"."SYS_NC00006$"=SYS_OP_DESCEND('C')))
filter((SYS_OP_UNDESCEND("T1"."SYS_NC00006$")='B' OR
SYS_OP_UNDESCEND("T1"."SYS_NC00006$")='C'))
The query crashed! The plan, however, did look appropriate – the optimizer picked an inlist iterator, picked an index range scan, got the correct estimate of rows (index entries), and did better with the predicate section (though having used a sensible predicate for the access predciate it then used the bizarre version as the filter predicate). Judging from the A-rows column the query seems to have crashed at roughly the point where the optimizer was switching from the range scan for the first iteration into the range scan for the second iteration.
And then there’s Oracle 18.3 – which does the same as the 12c versions :(
To make sure that my silly “single column so it shouldn’t be declared descending” index was the sole cause of the problem I repeated the tests using a two-column index on (sts, cnt).
Conclusion:
Descending indexes or (to be more accurate) indexes with descending columns can still produce problems even in the very latest version of Oracle.
Footnote
Oracle MoS has the wonderful “ORA-600/ORA-7445/ORA-700 Error Look-up Tool (Doc ID 153788.1)” (which doesn’t yet allow you to choose 18.3 as a version) so I used this to do a look up for ORA-00600 errors with first paremeter qernsRowP in 12.2.0.1 and got the following suggestion from doc ID 285913.1: “set event:10119 to disable no-sort fetch and then reparse the failing SQL.” The example suggested setting the event to level 12, and this solved the problem for all three failing versions – but the suggestion came with a warning: “Setting this event at system level may impact the performance of database.” The execution plan (taken, in this case, from 18.2) may explain the warning:
S COUNT(*)
- ----------
B 100
C 100
SQL_ID f20u42pmw1z6w, child number 0
-------------------------------------
select sts, count(*) from t1 where sts in ('B','C') group by sts
------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | OMem | 1Mem | Used-Mem |
------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 2 |00:00:00.01 | 4 | | | |
| 1 | HASH GROUP BY | | 1 | 2 | 2 |00:00:00.01 | 4 | 1558K| 1558K| 659K (0)|
| 2 | INLIST ITERATOR | | 1 | | 200 |00:00:00.01 | 4 | | | |
|* 3 | INDEX RANGE SCAN| T1_I1D | 2 | 200 | 200 |00:00:00.01 | 4 | | | |
------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access(("T1"."SYS_NC00006$"=SYS_OP_DESCEND('B') OR "T1"."SYS_NC00006$"=SYS_OP_DESCEND('C')))
filter((SYS_OP_UNDESCEND("T1"."SYS_NC00006$")='B' OR SYS_OP_UNDESCEND("T1"."SYS_NC00006$")='C'))
The plan has changed from using a “sort group by nosort” – which effectively means just keeping a running count as you go – to a real “hash group by” which means you have to do the hashing arithmetic for every value (though maybe there’s a deterministic trick that means Oracle won’t do the arithmetic if the next value to be hashed is the same as the previous value) and the actual memory used (659K) does seem a little extreme for counting two distinct values.