As I’m finishing up a performance chapter for the Exadata book (a lot of work!), I thought to take a quick break and write a blog entry.
This is not really worth putting into my Oracle Exadata Performance series (which so far has only 1 article in it anyway) .. so this is a little stand-alone article …
Everybody knows that the Exadata smart scan can be used when scanning tables (and table partitions). You should also know that smart scan can be used with fast full scan on Oracle B-tree indexes (a fast full scan on an index segment is just like a full table scan, only on the index segment (and ignoring branch blocks)).
For some reason there’s a (little) myth circulating that smart scans aren’t used for scanning bitmap indexes.
So, here’s evidence, that smart scan can be used when scanning bitmap indexes:
SQL> select /*+ tanel3 */ count(*) from t1 where owner like '%XYZXYZ%';
...
Plan hash value: 39555139
-----------------------------------------------------------------------------------
| Id | Operation | Name | E-Rows | Cost (%CPU)|
-----------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | 505 (100)|
| 1 | SORT AGGREGATE | | 1 | |
| 2 | BITMAP CONVERSION COUNT | | 400K| 505 (0)|
|* 3 | BITMAP INDEX STORAGE FAST FULL SCAN| BI_T1_OWNER | | |
-----------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - storage(("OWNER" LIKE '%XYZXYZ%' AND "OWNER" IS NOT NULL))
filter(("OWNER" LIKE '%XYZXYZ%' AND "OWNER" IS NOT NULL))
So, as you see the execution plan sure shows a FAST FULL SCAN on a BITMAP INDEX segment, which happens to be on Exadata STORAGE.
Also, you see a storage() predicate applied on the line 3 of the execution plan, which means that Oracle will attempt to use a smart scan predicate offload – but this can’t always be done!
So, you can’t really determine whether a smart scan happened during execution just by looking into the execution plan, you should really check some V$SESSION statistics too. That’s where my Snapper script becomes handy.
I started Snapper on my session just before running the above query. The “smart table scan” and “smart index scan” performance counters are updated right after Oracle has opened the segment header and determines, from the number of blocks in the segment, whether to call the smart scan codepath or not. In other words, the smart scan counters are inremented in the beginning of the segment scan.
The output is following (some irrelevant counters are stripped for brevity):
@snapper all 5 1 "301"
Sampling SID 301 with interval 5 seconds, taking 1 snapshots...
setting stats to all due to option = all
-- Session Snapper v3.52 by Tanel Poder @ E2SN ( http://tech.e2sn.com )
-------------------------------------------------------------------------------------------------------------------------------------
SID, USERNAME , TYPE, STATISTIC , HDELTA, HDELTA/SEC, %TIME, GRAPH
-------------------------------------------------------------------------------------------------------------------------------------
301, TANEL , STAT, physical read total IO requests , 13, 2.6,
301, TANEL , STAT, physical read total multi block requests , 4, .8,
301, TANEL , STAT, physical read requests optimized , 1, .2,
301, TANEL , STAT, physical read total bytes optimized , 8.19k, 1.64k,
301, TANEL , STAT, physical read total bytes , 4.63M, 925.7k,
301, TANEL , STAT, cell physical IO interconnect bytes , 10.02k, 2k,
301, TANEL , STAT, physical reads , 565, 113,
301, TANEL , STAT, physical reads cache , 1, .2,
301, TANEL , STAT, physical reads direct , 564, 112.8,
301, TANEL , STAT, physical read IO requests , 13, 2.6,
301, TANEL , STAT, physical read bytes , 4.63M, 925.7k,
301, TANEL , STAT, db block changes , 1, .2,
301, TANEL , STAT, cell physical IO bytes eligible for predicate offload , 4.62M, 924.06k,
301, TANEL , STAT, cell physical IO interconnect bytes returned by smart scan, 1.82k, 364.8,
301, TANEL , STAT, cell blocks processed by cache layer , 564, 112.8,
301, TANEL , STAT, cell blocks processed by txn layer , 564, 112.8,
301, TANEL , STAT, cell blocks processed by index layer , 564, 112.8,
301, TANEL , STAT, cell blocks helped by minscn optimization , 564, 112.8,
301, TANEL , STAT, cell index scans , 1, .2,
301, TANEL , STAT, index fast full scans (full) , 1, .2,
301, TANEL , STAT, index fast full scans (direct read) , 1, .2,
301, TANEL , STAT, bytes sent via SQL*Net to client , 334, 66.8,
301, TANEL , STAT, bytes received via SQL*Net from client , 298, 59.6,
301, TANEL , STAT, SQL*Net roundtrips to/from client , 2, .4,
301, TANEL , STAT, cell flash cache read hits , 1, .2,
301, TANEL , TIME, hard parse elapsed time , 1.17ms, 233.8us, .0%, | |
301, TANEL , TIME, parse time elapsed , 1.5ms, 300.2us, .0%, | |
301, TANEL , TIME, DB CPU , 11ms, 2.2ms, .2%, | |
301, TANEL , TIME, sql execute elapsed time , 82.2ms, 16.44ms, 1.6%, |@ |
301, TANEL , TIME, DB time , 84.36ms, 16.87ms, 1.7%, |@ |
301, TANEL , WAIT, enq: KO - fast object checkpoint , 16.18ms, 3.24ms, .3%, | |
301, TANEL , WAIT, gc cr grant 2-way , 223us, 44.6us, .0%, | |
301, TANEL , WAIT, gc current grant 2-way , 136us, 27.2us, .0%, | |
301, TANEL , WAIT, cell smart index scan , 56.04ms, 11.21ms, 1.1%, |@ |
301, TANEL , WAIT, SQL*Net message to client , 7us, 1.4us, .0%, | |
301, TANEL , WAIT, SQL*Net message from client , 4.42s, 884.47ms, 88.4%, |@@@@@@@@@ |
301, TANEL , WAIT, cell single block physical read , 541us, 108.2us, .0%, | |
301, TANEL , WAIT, events in waitclass Other , 2.22ms, 443.2us, .0%, | |
-- End of Stats snap 1, end=2011-03-13 19:36:31, seconds=5
As you see from the above “cell index scans” statistic – indeed one index segment was scanned using the cell smart scan method.
So, I would rather call this feature “smart segment scan” to reflect that smart scan can scan more than just tables…
I guess one of the reasons why few people have seen smart bitmap index scans in action is that (single-column) bitmap indexes tend to be small. Smaller than corresponding table segments and B-tree index segments. On partitioned tables they’re much more likely going to be under the “_small_table_threshold” calculation which is used for determining whether to do a direct path full segment scan or not (yes, the _small_table_threshold applies to fast full index scan and fast full bitmap index scan too, not just table scans). So, it’s likely that Oracle chooses to do a regular, buffered full bitmap segment scan and thus won’t even consider using smart scan (as smart scans require direct path reads).
By the way – the direct path read (or not) decision is done per segment – not per object (like a table or index). So if you have 10 partitions in a table (or index), half of them are large, half are smaller, then Oracle may end up using direct path reads (and smart scan) on 5 of them and buffered (dumb) scan on the other 5. If you run something like Snapper on the session, then you’d see the smart scan counters go up by 5 only. As written above, Oracle decides whether to do direct path reads (and smart scan) right after opening the header block of a segment (partition) and reading out how many blocks this partition’s segment has below HWM.
The above applied to serial direct path reads – the Parallel Execution slaves should always read using direct path mode, right? …. Wrong :)
Well, partially wrong… In 11.2.0.2, if the parallel_degree_policy = manual, then yes, PX slaves behave like usual and always force a direct path read (and try to use a smart scan). However, with parallel_degree_policy = AUTO, which is the future of PX auto-management, Oracle can decide to do a buffered parallel scan instead, again disabling the use of smart scan…
One more note – I didn’t say anything about whether you should or should not use (bitmap) indexes on Exadata, it’s an entirely different discussion. I just brought out that the smart scan is used for scanning table segments, B-tree index segments and bitmap index segments if conditions are right.
And in the end I have to say…. that even with this evidence you can’t be fully sure that a smart scan was used throughout the entire segment, but more about this in the book and perhaps in a later blog article. We have interesting times ahead ;-)
