Comments on: Mything 2

By: Jonathan Lewis

Jonathan Lewis — Tue, 28 Jun 2011 08:45:16 +0000

goiyala3,

This isn’t really the right place to ask the question – but it’s an interesting example and IS associated (loosely) with the topic, so I’m going to see if I can find some time later on this week to explain what’s going on. I’ll copy this comment into a new post to do so.

The first thing to note, of course, is that Oracle can only do the index hash join after translating the bitmaps for the whole table into rowids – and this is why you use so much PGA. Oracle has, internally, no mechanismm for taking advantage of partitionwise processing to do the job you want – and that’s key to rewriting the query.

By: goiyala3

goiyala3 — Tue, 28 Jun 2011 07:37:10 +0000

Hi jonathan I have a query which is using 2 indexes both are bitmap indexes (sizes are 37 and 24 Mbs) and table size is 17gb. While i ran the following query which can very well get the index itself, it takes around 6-8 minutes and using pga around 3 gb. could you please explain me why ? [sourcecode gutter="false"] SQL_ID 5z0a50a2yzdky, child number 0 ------------------------------------- select count(1) from (select distinct SRC_SYS,PROD_KEY from dds.REV_F) Plan hash value: 867747470 -------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | -------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 221K(100)| | | | | 1 | SORT AGGREGATE | | 1 | | | | | | | 2 | VIEW | | 24533 | | 221K (6)| 00:44:22 | | | | 3 | HASH UNIQUE | | 24533 | 479K| 221K (6)| 00:44:22 | | | | 4 | VIEW | index$_join$_002 | 63M| 1209M| 212K (2)| 00:42:28 | | | |* 5 | HASH JOIN | | | | | | | | | 6 | PARTITION LIST ALL | | 63M| 1209M| 3591 (1)| 00:00:44 | 1 | 145 | | 7 | BITMAP CONVERSION TO ROWIDS| | 63M| 1209M| 3591 (1)| 00:00:44 | | | | 8 | BITMAP INDEX FULL SCAN | REV_F_IDX1 | | | | | 1 | 145 | | 9 | PARTITION LIST ALL | | 63M| 1209M| 13724 (1)| 00:02:45 | 1 | 145 | | 10 | BITMAP CONVERSION TO ROWIDS| | 63M| 1209M| 13724 (1)| 00:02:45 | | | | 11 | BITMAP INDEX FULL SCAN | REV_F_IDX5 | | | | | 1 | 145 | -------------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 5 - access(ROWID=ROWID) 28 rows selected. call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.01 0.00 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 2 610.89 1464.86 707459 17090 0 1 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 4 610.90 1464.87 707459 17090 0 1 Misses in library cache during parse: 1 Optimizer mode: ALL_ROWS Parsing user id: SYS Rows Row Source Operation ------- --------------------------------------------------- 1 SORT AGGREGATE (cr=17090 pr=707459 pw=446115 time=1464867976 us) 26066 VIEW (cr=17090 pr=707459 pw=446115 time=1464795748 us) 26066 HASH UNIQUE (cr=17090 pr=707459 pw=446115 time=1464769678 us) 63422824 VIEW index$_join$_002 (cr=17090 pr=707459 pw=446115 time=1084846545 us) 63422824 HASH JOIN (cr=17090 pr=707459 pw=446115 time=958000889 us) 63422824 PARTITION LIST ALL PARTITION: 1 145 (cr=3561 pr=0 pw=0 time=63423134 us) 63422824 BITMAP CONVERSION TO ROWIDS (cr=3561 pr=0 pw=0 time=9554 us) 7112 BITMAP INDEX FULL SCAN REV_F_IDX1 PARTITION: 1 145 (cr=3561 pr=0 pw=0 time=155525 us)(object id 366074) 63422824 PARTITION LIST ALL PARTITION: 1 145 (cr=13529 pr=8864 pw=0 time=190268771 us) 63422824 BITMAP CONVERSION TO ROWIDS (cr=13529 pr=8864 pw=0 time=63553723 us) 432700 BITMAP INDEX FULL SCAN REV_F_IDX5 PARTITION: 1 145 (cr=13529 pr=8864 pw=0 time=3157351 us)(object id 366658) Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- ------------ SQL*Net message to client 2 0.00 0.00 direct path write temp 29741 1.62 107.05 db file sequential read 8864 0.20 2.35 direct path read temp 46573 0.79 211.02 SQL*Net message from client 2 29.22 29.22 [/sourcecode]

By: Connor

Connor — Mon, 27 Jun 2011 04:23:34 +0000

I was initially unsure about clicking on this link….as I read it as “My-thing” :-)

By: Mark W. Farnham

Mark W. Farnham — Sat, 25 Jun 2011 13:59:13 +0000

Completely interesting, and great advice to avoid overgeneralizing when going from facts and logic to a theory. (And especially avoiding “mything” a a theory based on one fact and no case analysis.)

And, of course, since all the columns in the example have specified values, it begs another myth: Why does Oracle go to the table at all (even in the plan) when it has all the values for all the attributes in hand? You’d like to think it only needs to count the satisfaction of the bitmap and and produce the requisite number of rows. (That’s a less trivial optimization if it potentially eliminates several tables from a join or facilitates skipping the return of the data from storage to memory on platforms where that is possible.)

But does Oracle always fail to skip tables you can prove from a semantic analysis are not needed? I don’t know – at this point that would be a myth, or more kindly a suspicion.

Thanks for throwing down the guantlet challenging folks to keep logic tight and avoid overgeneralization.