Comments on: IOUG Day 4

By: Star Transformation – 2 « Oracle Scratchpad

Star Transformation – 2 « Oracle Scratchpad — Fri, 26 Aug 2011 06:02:53 +0000

[...] important case where this is always true – when you’re running Standard Edition, which doesn’t support bitmap indexes. So if you’re running SE and want to do star transformations – you now know [...]

By: Collaborate09 thoughts… | Oracle

Collaborate09 thoughts… | Oracle — Tue, 11 Aug 2009 09:49:44 +0000

[...] pretty smart guy when it comes to Oracle knowledge) posted about some things he discovered for the first time. I strongly encourage everyone to attend at least one event if possible every year – to [...]

By: Log Buffer #146: a Carnival of the Vanities for DBAs | Pythian Group Blog

Log Buffer #146: a Carnival of the Vanities for DBAs | Pythian Group Blog — Fri, 15 May 2009 17:00:14 +0000

[...] start with Jonathan Lewis’s report from IOUG Day 4: ” Not so much a little gem today as a little surprise and a few consequential thoughts. In a [...]

By: Gary

Gary — Sun, 10 May 2009 23:00:35 +0000

I checked Chen’s results on an 11.1.0.7 Standard Edition and came out with the same plans. So nothing has changed there. None of the bitmap system parameters (public or hidden) are set to false, so it isn’t simply down to different defaults.

By: Jonathan Lewis

Jonathan Lewis — Sat, 09 May 2009 10:17:34 +0000

Chen,

Thanks for that – I think you’ve covered all the bases.

Tentative conclusion: if you’re using 9i Standard Edition, then some of your queries may stop using and_equal() execution plans when you upgrade to 10g Standard Edition and find some other less efficient plan.

Anyone in this position might want to run a few scans of v$sql_plan before upgrading checking for “operation = ‘AND-EQUAL’” to find the SQL at risk.

“I couldn’t resist …”I shall, however, resist mentioning a few of the other little things I’ve been waiting to test against SE – otherwise you might end up spend all week-end at your computer running my experiments ;)

By: Chen Shapira

Chen Shapira — Fri, 08 May 2009 22:40:44 +0000

I couldn’t resist and tried it on the 9.2.0.7 that was on the “must upgrade this quarter” plan for the last 2 years:
Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=1 Bytes=117) 1 0 TABLE ACCESS (BY INDEX ROWID) OF 'T2' (Cost=4 Card=1 Bytes=117) 2 1 AND-EQUAL 3 2 INDEX (RANGE SCAN) OF 'T2_B1' (NON-UNIQUE) 4 2 INDEX (RANGE SCAN) OF 'T2_B2' (NON-UNIQUE) (Cost=1 Card=60)


You got it :)

AND-EQUAL is used, not full-scan.

Quiet amazing, really.

By: Jonathan Lewis

Jonathan Lewis — Fri, 08 May 2009 21:24:47 +0000

Chen,

Fantastic, I think that’s beginning to look fairly conclusive – and I think it highlights an interesting case.

I think earlier versions of Oracle would probably do the AND-EQUAL at that point, but 10.2 won’t because it’s deprecated, but SE can’t do the expected bitmap conversion to compensate.

By: Chen Shapira

Chen Shapira — Fri, 08 May 2009 21:07:18 +0000

Still no bitmap conversion:


Execution Plan
----------------------------------------------------------
Plan hash value: 1513984157

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |   117 |    13   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T2   |     1 |   117 |    13   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("B1"=20 AND "B2"=20)

By: Jonathan Lewis

Jonathan Lewis — Fri, 08 May 2009 20:55:15 +0000

Chen, That's interesting; thanks for running the test. It really does suggest that the whole bitmap code path might be blocked in Standard Edition. If you have a few minutes could you try a simpler query just to see if that works, e.g: select * from t2 where b1 = 20 and b2 = 20, with the same index_combine() hint.

By: prodlife

prodlife — Fri, 08 May 2009 18:45:47 +0000

I happened to have 10.2.0.3 standard edition laying around. So I ran the example from: http://jonathanlewis.wordpress.com/2007/02/08/index-combine/ And got the following plan:


Execution Plan
----------------------------------------------------------
Plan hash value: 1755794669
--------------------------------------------------------------------------------
| Id  | Operation                    | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |       |     5 |   125 |    40   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                |       |     5 |   125 |    40   (0)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| T1    |     3 |    24 |     4   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN          | T1_N1 |     3 |       |     1   (0)| 00:00:01 |
|*  4 |   TABLE ACCESS FULL          | T2    |     2 |    34 |    12   (0)| 00:00:01 |
--------------------------------------------------------------------------------

No "BITMAP CONVERSION TO ROWIDS" in sight :) Same test on Enterprise Edition gave the expected plan you posted in the "Index Combine" blog post.