BITMAP CONVERSION TO ROWIDS

This is the plan used for my query in my prod database.
10.2.0.3
In dev same oracle version, the plan is not doing bitmap conversion.
prod query time: 4minutes
dev query time:20 seconds
how can i tell oracle to stop bitmap conversing on me?
BTW, i have no bitmap index, weird.
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1934 | 267K| 3025 (1)| 00:00:37 |
| 1 | SORT ORDER BY | | 1934 | 267K| 3024 (25)| 00:00:37 |
| 2 | UNION-ALL | | | | | |
| 3 | MAT_VIEW ACCESS BY INDEX ROWID | MV_SONG | 92 | 14076 | 2304 (1)| 00:00:28 |
| 4 | BITMAP CONVERSION TO ROWIDS | | | | | |
| 5 | BITMAP AND | | | | | |
| 6 | BITMAP CONVERSION FROM ROWIDS| | | | | |
|* 7 | INDEX RANGE SCAN | IDX_MV_SONG_USCFALB | | | 417 (2)| 00:00:06 |
| 8 | BITMAP CONVERSION FROM ROWIDS| | | | | |
| 9 | SORT ORDER BY | | | | | |
|* 10 | DOMAIN INDEX | MV_SON_TITLE_FULLT_IDX | | | 1827 (0)| 00:00:22 |
| 11 | MAT_VIEW ACCESS BY INDEX ROWID | MV_SONG | 1842 | 253K| 720 (1)| 00:00:09 |
|* 12 | INDEX RANGE SCAN | IDXF_MV_SONG_SONTUSFALB | 737 | | 3 (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------

In dev same oracle version, the plan is not doing bitmap conversion.
prod query time: 4minutes
dev query time:20 secondsIs the amount of data in both databases the same?
If you want to switch off this behaviour you can change the value of the BTREE_BITMAP_PLANS parameter. (Actually it might not be an underscore parameter in 10.2 - I wouldn't know, I'm still on 9i). Of course, the usual caveats about tweaking underscore paarmters apply.
Niall Litchfield wrote an interesting article on this pararmeter aa couple of years back. You should read it.
Cheers, APC

Similar Messages

Oracle 11g performance issue ( BITMAP CONVERSION TO ROWIDS)

I have two instance of oracle 11g.
in both instance i fired same query.
one instance returns the result in 1sec but other instance returns the result in 10 sec
following is explain plan for bot instance
instance 1
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 143 | 59 (2)| 00:00:01 |
| 1 | HASH GROUP BY | | 1 | 143 | 59 (2)| 00:00:01 |
| 2 | VIEW | VM_NWVW_2 | 1 | 143 | 59 (2)| 00:00:01 |
| 3 | HASH UNIQUE | | 1 | 239 | 59 (2)| 00:00:01 |
| 4 | NESTED LOOPS | | | | | |
| 5 | NESTED LOOPS | | 1 | 239 | 58 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
| 6 | NESTED LOOPS | | 1 | 221 | 57 (0)| 00:00:01 |
| 7 | NESTED LOOPS | | 1 | 210 | 55 (0)| 00:00:01 |
| 8 | NESTED LOOPS | | 1 | 184 | 54 (0)| 00:00:01 |
| 9 | NESTED LOOPS | | 1 | 158 | 53 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 139 | 52 (0)| 00:00:01 |
| 11 | NESTED LOOPS | | 1 | 105 | 50 (0)| 00:00:01 |
|* 12 | INDEX RANGE SCAN | year_field | 1 | 29 | 2 (0)| 00:00:01 |
| 13 | SORT AGGREGATE | | 1 | 8 | | |
| 14 | INDEX FULL SCAN (MIN/MAX)| idx_bf_creation_date | 1 | 8 | 2 (0)| 00:00:01 |
|* 15 | TABLE ACCESS BY INDEX ROWID| OHRT_bugs_fact | 1 | 76 | 48 (0)| 00:00:01 |
|* 16 | INDEX RANGE SCAN | idx_bf_creation_date | 76 | | 1 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
|* 17 | TABLE ACCESS BY INDEX ROWID | OHRT_all_time_dimension | 1 | 34 | 2 (0)| 00:00:01 |
|* 18 | INDEX UNIQUE SCAN | unique_alltime_bug_instance_id | 1 | | 1 (0)| 00:00:01 |
| 19 | TABLE ACCESS BY INDEX ROWID | OHRT_all_time_dimension | 1 | 19 | 1 (0)| 00:00:01 |
|* 20 | INDEX UNIQUE SCAN | unique_alltime_bug_instance_id | 1 | | 1 (0)| 00:00:01 |
|* 21 | INDEX RANGE SCAN | bugseverity_instance_id_ref_id | 1 | 26 | 1 (0)| 00:00:01 |
|* 22 | INDEX UNIQUE SCAN | unique_alltime_bug_instance_id | 1 | 26 | 1 (0)| 00:00:01 |
| 23 | INLIST ITERATOR | | | | | |
|* 24 | TABLE ACCESS BY INDEX ROWID | OHMT_ANL_BUCKET | 1 | 11 | 2 (0)| 00:00:01 |
|* 25 | INDEX UNIQUE SCAN | SYS_C0053213 | 5 | | 1 (0)| 00:00:01 |
|* 26 | INDEX RANGE SCAN | FK_BUCKET_TYPE | 6 | | 0 (0)| 00:00:01 |
|* 27 | TABLE ACCESS BY INDEX ROWID | OHMT_ANL_BUCKET | 1 | 18 | 1 (0)| 00:00:01 |
instance 2
Plan
SELECT STATEMENT ALL_ROWS Cost: 22 Bytes: 142 Cardinality: 1
32 HASH GROUP BY Cost: 22 Bytes: 142 Cardinality: 1
31 VIEW VIEW SYS.VM_NWVW_2 Cost: 22 Bytes: 142 Cardinality: 1
30 HASH UNIQUE Cost: 22 Bytes: 237 Cardinality: 1
29 NESTED LOOPS
27 NESTED LOOPS Cost: 21 Bytes: 237 Cardinality: 1
25 NESTED LOOPS Cost: 20 Bytes: 219 Cardinality: 1
21 NESTED LOOPS Cost: 18 Bytes: 208 Cardinality: 1
19 NESTED LOOPS Cost: 17 Bytes: 183 Cardinality: 1
17 NESTED LOOPS Cost: 16 Bytes: 157 Cardinality: 1
14 NESTED LOOPS Cost: 15 Bytes: 138 Cardinality: 1
11 NESTED LOOPS Cost: 13 Bytes: 104 Cardinality: 1
3 INDEX RANGE SCAN INDEX REPORTSDB.year_field Cost: 2 Bytes: 29 Cardinality: 1
2 SORT AGGREGATE Bytes: 8 Cardinality: 1
1 INDEX FULL SCAN (MIN/MAX) INDEX REPORTSDB.idx_bf_creation_date Cost: 3 Bytes: 8 Cardinality: 1
10 TABLE ACCESS BY INDEX ROWID TABLE REPORTSDB.OHRT_bugs_fact Cost: 13 Bytes: 75 Cardinality: 1
9 BITMAP CONVERSION TO ROWIDS
8 BITMAP AND
5 BITMAP CONVERSION FROM ROWIDS
4 INDEX RANGE SCAN INDEX REPORTSDB.idx_OHRT_bugs_fact_2product Cost: 2 Cardinality: 85
7 BITMAP CONVERSION FROM ROWIDS
6 INDEX RANGE SCAN INDEX REPORTSDB.idx_bf_creation_date Cost: 2 Cardinality: 85
13 TABLE ACCESS BY INDEX ROWID TABLE REPORTSDB.OHRT_all_time_dimension Cost: 2 Bytes: 34 Cardinality: 1
12 INDEX UNIQUE SCAN INDEX (UNIQUE) REPORTSDB.unique_alltime_bug_instance_id Cost: 1 Cardinality: 1
16 TABLE ACCESS BY INDEX ROWID TABLE REPORTSDB.OHRT_all_time_dimension Cost: 1 Bytes: 19 Cardinality: 1
15 INDEX UNIQUE SCAN INDEX (UNIQUE) REPORTSDB.unique_alltime_bug_instance_id Cost: 1 Cardinality: 1
18 INDEX UNIQUE SCAN INDEX (UNIQUE) REPORTSDB.unique_alltime_bug_instance_id Cost: 1 Bytes: 26 Cardinality: 1
20 INDEX RANGE SCAN INDEX REPORTSDB.bugseverity_instance_id_ref_id Cost: 1 Bytes: 25 Cardinality: 1
24 INLIST ITERATOR
23 TABLE ACCESS BY INDEX ROWID TABLE OPSHUB.OHMT_ANL_BUCKET Cost: 2 Bytes: 11 Cardinality: 1
22 INDEX UNIQUE SCAN INDEX (UNIQUE) OPSHUB.SYS_C0040939 Cost: 1 Cardinality: 5
26 INDEX RANGE SCAN INDEX OPSHUB.FK_BUCKET_TYPE Cost: 0 Cardinality: 6
28 TABLE ACCESS BY INDEX ROWID TABLE OPSHUB.OHMT_ANL_BUCKET Cost: 1 Bytes: 18 Cardinality: 1
in both explain plan only difference is
9 BITMAP CONVERSION TO ROWIDS
8 BITMAP AND
5 BITMAP CONVERSION FROM ROWIDS
but is bitmap degrading performance lot?
or suggest me what other parameter i can see so 2nd instance gives me better performace.

I see more differences.
In plan 1:
* 16 INDEX RANGE SCAN idx_bf_creation_date 76 1 (0) 00:00:01
in Plan 2:
1 INDEX FULL SCAN (MIN/MAX) INDEX REPORTSDB.idx_bf_creation_date Cost: 3 Bytes: 8 Cardinality: 1
So this is not about "bitmap" good/bad, it about the access strategy which changed due to differences in data statistics etc. To analyze more, I'd help a LOT if those plans would be formated in a good and same way, use around it to do so.

Explain plan change after partitioning - Bitmap conversion to rowid

hi gurus,
before partitioning the table using range paritioning,
for the query,
SELECT MEDIUMID
          FROM MEDIUM_TB
          WHERE CMREFERENCEID =8
           AND CONTENTTYPEID = 8
           AND CMSTATUSID = 5
           AND SUBTYPEID = 99
A. before partitioning
SELECT STATEMENT, GOAL = ALL_ROWS          2452     882     16758
SORT ORDER BY               2452     882     16758
TABLE ACCESS BY INDEX ROWID     DBA1     MEDIUM_TB     2451     882     16758
   BITMAP CONVERSION TO ROWIDS
    BITMAP AND
     BITMAP CONVERSION FROM ROWIDS
      INDEX RANGE SCAN      DBA1     MEDIUM_TB_IX07     242     94423
     BITMAP CONVERSION FROM ROWIDS
      INDEX RANGE SCAN      DBA1     MEDIUM_TB_IX02     1973     94423
B. after partitioning
the explain plan changed to
SELECT STATEMENT, GOAL = ALL_ROWS          33601     796     15124
TABLE ACCESS BY GLOBAL INDEX ROWID     DBA1     MEDIUM_TB     33601     796     15124
INDEX RANGE SCAN     DBA1     MEDIUM_TB_IX07     300     116570     as you can see in the plan, the paln cost is very high after partitioning and the query is taking more time.
index MEDIUM_TB_IX02 is not used in the second plan and also the plan method BITMAP CONVERSION.
fyi, there is all the indexes are b-tree based and global indexes.
what could be reason for the plan change?
please help
thanks,
charles

user570138 wrote:
SELECT STATEMENT, GOAL = ALL_ROWS          2452     882     16758
SORT ORDER BY               2452     882     16758
TABLE ACCESS BY INDEX ROWID     DBA1     MEDIUM_TB     2451     882     16758
BITMAP CONVERSION TO ROWIDS
BITMAP AND
BITMAP CONVERSION FROM ROWIDS
INDEX RANGE SCAN      DBA1     MEDIUM_TB_IX07     242     94423
BITMAP CONVERSION FROM ROWIDS
INDEX RANGE SCAN      DBA1     MEDIUM_TB_IX02     1973     94423
If you supplied proper execution plans we might be able to offer some advice.
Use dbms_xplan.
A list of the index definitions might also help
Regards
Jonathan Lewis

Please explain plan with 'BITMAP CONVERSION TO ROWIDS'

Hi,
in my 9.2.0.8 I've got plan like :
Plan
SELECT STATEMENT CHOOSECost: 26,104
     7 TABLE ACCESS BY INDEX ROWID UMOWY Cost: 26,105 Bytes: 41 Cardinality: 1
          6 BITMAP CONVERSION TO ROWIDS
               5 BITMAP AND
                    2 BITMAP CONVERSION FROM ROWIDS
                         1 INDEX RANGE SCAN UMW_PRD_KPD_KOD Cost: 406 Cardinality: 111,930
                    4 BITMAP CONVERSION FROM ROWIDS
                         3 INDEX RANGE SCAN UMW_PRD_KPR_KOD Cost: 13,191 Cardinality: 111,930 as far as I know Oracle is trying to combine two indexes , so if I create multicolumn index the plan should be better right ?
Generally all bitmap conversions related to b-tree indexes are trying to combine multiple indexes to deal with or/ index combine operations right ?
And finally what about AND_EQUAL hint is that kind of alternative for that bitmap conversion steps ?
Regards
Greg

as far as I know Oracle is trying to combine two indexes , so if I create multicolumn index the plan should be better right ?Only you can really tell - but if this is supposed to be a "precision" query the optimizer thinks you don't have a good index into the target data. Don't forget to consider the benefits of compressed indexes if you do follow this route.
Generally all bitmap conversions related to b-tree indexes are trying to combine multiple indexes to deal with or/ index combine operations right ?Bitmap conversions when there are no real bitmap indexes involved are always about combining multiple b-tree index range scans to minimise the number of reads from the table.
And finally what about AND_EQUAL hint is that kind of alternative for that bitmap conversion steps ?AND_EQUAL was an older mechanism for combining index range scans to minimise visits to the table - it was restricted to a maximum of 5 indexes per table - the indexes had to be single column, non-unique, and the predicates had to be equality. The access method is deprecated in 10g. (See the following note, and the comments in particular, for more details: http://jonathanlewis.wordpress.com/2009/05/08/ioug-day-4/ )
Regards
Jonathan Lewis

[11g R2] Update-Select with BITMAP CONVERSION TO ROWIDS = very slow

Hi all,
I have to deal with some performance issues in our database.
The query below takes between 30 minutes and 60 minutes to complete (30 minutes during the batch process and 1h when I executed the query with SQLPLUS):
SQL_ID 4ky65wauhg1ub, child number 0
UPDATE fiscpt x    SET (x.cimld) =           (SELECT COUNT (*)
    FROM fiscpt f             WHERE f.comar = x.comar               AND
f.coint = x.coint               AND f.nucpt = x.nucpt               AND
f.codev != x.codev               AND f.cimvt != 0) WHERE x.comar IN
('CBOT', 'CME', 'EUREX', 'FOREX', 'LIFFE', 'METAL', 'OCC')
Plan hash value: 697684605
| Id | Operation                          | Name    | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers | Reads | OMem | 1Mem | Used-Mem |
|   0 | UPDATE STATEMENT                   |         |      1 |        |       |   773K(100)|          |      0 |00:22:22.30 |      36M|   7629 |       |       |          |
|   1 | UPDATE                            | FISCPT |      1 |        |       |            |          |      0 |00:22:22.30 |      36M|   7629 |       |       |          |
|   2 |   INLIST ITERATOR                  |         |      1 |        |       |            |          |    179K|00:00:00.37 |    1221 |      3 |       |       |          |
|* 3 |    INDEX RANGE SCAN                | FISCPT1 |      7 |    154K| 4984K|     5   (0)| 00:00:01 |    179K|00:00:00.23 |    1221 |      3 |       |       |          |
|   4 |   SORT AGGREGATE                   |         |    179K|      1 |    33 |            |          |    179K|01:02:58.45 |      35M|   3020 |       |       |          |
|* 5 |    TABLE ACCESS BY INDEX ROWID     | FISCPT |    179K|      1 |    33 |     4 (25)| 00:00:01 | 63681 |01:02:57.80 |      35M|   3020 |       |       |          |
|   6 |     BITMAP CONVERSION TO ROWIDS    |         |    179K|        |       |            |          |    121K|01:02:52.71 |      35M|    885 |       |       |          |
|   7 |      BITMAP AND                    |         |    179K|        |       |            |          | 87091 |01:02:52.25 |      35M|    885 |       |       |          |
|   8 |       BITMAP CONVERSION FROM ROWIDS|         |    179K|        |       |            |          |    179K|00:00:03.31 |     241K|      0 |       |       |          |
|* 9 |        INDEX RANGE SCAN            | FISCPT2 |    179K|   1547 |       |     1   (0)| 00:00:01 |   1645K|00:00:02.23 |     241K|      0 |       |       |          |
| 10 |       BITMAP CONVERSION FROM ROWIDS|         |    179K|        |       |            |          |    148K|01:02:44.98 |      35M|    885 |       |       |          |
| 11 |        SORT ORDER BY               |         |    179K|        |       |            |          |   2412M|00:52:19.70 |      35M|    885 | 1328K|   587K| 1180K (0)|
|* 12 |         INDEX RANGE SCAN           | FISCPT1 |    179K|   1547 |       |     2   (0)| 00:00:01 |   2412M|00:22:11.22 |      35M|    885 |       |       |          |
Query Block Name / Object Alias (identified by operation id):
   1 - UPD$1
   3 - UPD$1 / X@UPD$1
   4 - SEL$1
   5 - SEL$1 / F@SEL$1
Predicate Information (identified by operation id):
   3 - access(("X"."COMAR"='CBOT' OR "X"."COMAR"='CME' OR "X"."COMAR"='EUREX' OR "X"."COMAR"='FOREX' OR "X"."COMAR"='LIFFE' OR "X"."COMAR"='METAL' OR
              "X"."COMAR"='OCC'))
   5 - filter("F"."CIMVT"<>0)
   9 - access("F"."COINT"=:B1 AND "F"."NUCPT"=:B2)
12 - access("F"."COMAR"=:B1)
       filter(("F"."CODEV"<>:B1 AND "F"."COMAR"=:B2))
Column Projection Information (identified by operation id):
   2 - (upd=6; cmp=2,3,4,5) "SYS_ALIAS_4".ROWID[ROWID,10], "X"."COMAR"[VARCHAR2,5], "X"."COINT"[VARCHAR2,11], "X"."NUCPT"[VARCHAR2,8], "X"."CODEV"[VARCHAR2,3],
       "X"."CIMLD"[NUMBER,22]
   3 - "SYS_ALIAS_4".ROWID[ROWID,10], "X"."COMAR"[VARCHAR2,5], "X"."COINT"[VARCHAR2,11], "X"."NUCPT"[VARCHAR2,8], "X"."CODEV"[VARCHAR2,3], "X"."CIMLD"[NUMBER,22]
   4 - (#keys=0) COUNT(*)[22]
   5 - "F".ROWID[ROWID,10], "F"."COMAR"[VARCHAR2,5], "F"."COINT"[VARCHAR2,11], "F"."NUCPT"[VARCHAR2,8], "F"."CODEV"[VARCHAR2,3], "F"."CIMVT"[NUMBER,22]
   6 - "F".ROWID[ROWID,10]
   7 - STRDEF[BM VAR, 10], STRDEF[BM VAR, 10], STRDEF[BM VAR, 32496]
   8 - STRDEF[BM VAR, 10], STRDEF[BM VAR, 10], STRDEF[BM VAR, 32496]
   9 - "F".ROWID[ROWID,10]
10 - STRDEF[BM VAR, 10], STRDEF[BM VAR, 10], STRDEF[BM VAR, 32496]
11 - (#keys=1) "F".ROWID[ROWID,10]
12 - "F".ROWID[ROWID,10]
Note
   - dynamic sampling used for this statement (level=2)We intentionally don't gather statistics on the FISCPT table.
There are no indexes on the column updated so the slowness is not due to updating of indexes:
SQL> select index_name, column_name from user_ind_columns where table_name='FISCPT';
INDEX_NAME COLUMN_NAM
FISCPT1    NUCPT
FISCPT1    CODEV
FISCPT1    RGCID
FISCPT1    DATRA
FISCPT2    COINT
FISCPT2    NUCPT
FISCPT3    NUFIS
FISCPT1    COINT
FISCPT1    COMAR
9 ligne(s) sÚlectionnÚe(s).
SQL> select count(1) from FISCPT;
COUNT(1)
    179369If I replace the UPDATE-SELECT statement by a SELECT, the query runs in few seconds:
SQL> SELECT COUNT (*)
2               FROM fiscpt f, fiscpt x
3              WHERE f.comar = x.comar
4                AND f.coint = x.coint
5                AND f.nucpt = x.nucpt
6                AND f.codev != x.codev
7                AND f.cimvt != 0
8   and x.comar IN ('CBOT', 'CME', 'EUREX', 'FOREX', 'LIFFE', 'METAL', 'OCC');
COUNT(*)
     63681
EcoulÚ : 00 :00 :00.75
SQL> select * from table(dbms_xplan.display_cursor());
PLAN_TABLE_OUTPUT
SQL_ID 5drbpdmdv0gv1, child number 0
SELECT COUNT (*)              FROM fiscpt f, fiscpt x
WHERE f.comar = x.comar               AND f.coint = x.coint
AND f.nucpt = x.nucpt               AND f.codev != x.codev
   AND f.cimvt != 0 and x.comar IN ('CBOT', 'CME', 'EUREX', 'FOREX',
'LIFFE', 'METAL', 'OCC')
Plan hash value: 1326101771
| Id | Operation                      | Name    | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT               |         |       |       |       | 2477 (100)|          |
|   1 | SORT AGGREGATE                |         |     1 |    53 |       |            |          |
|* 2 |   HASH JOIN                    |         |   107K| 5557K| 4720K| 2477   (1)| 00:00:30 |
|   3 |    INLIST ITERATOR             |         |       |       |       |            |          |
|* 4 |     TABLE ACCESS BY INDEX ROWID| FISCPT |   107K| 3460K|       | 1674   (1)| 00:00:21 |
|* 5 |      INDEX RANGE SCAN          | FISCPT1 |   154K|       |       |   873   (0)| 00:00:11 |
|* 6 |    INDEX FAST FULL SCAN        | FISCPT1 |   154K| 3021K|       |   337   (0)| 00:00:05 |
Predicate Information (identified by operation id):
   2 - access("F"."COMAR"="X"."COMAR" AND "F"."COINT"="X"."COINT" AND
              "F"."NUCPT"="X"."NUCPT")
       filter("F"."CODEV"<>"X"."CODEV")
   4 - filter("F"."CIMVT"<>0)
   5 - access(("F"."COMAR"='CBOT' OR "F"."COMAR"='CME' OR "F"."COMAR"='EUREX' OR
              "F"."COMAR"='FOREX' OR "F"."COMAR"='LIFFE' OR "F"."COMAR"='METAL' OR "F"."COMAR"='OCC'))
   6 - filter(("X"."COMAR"='CBOT' OR "X"."COMAR"='CME' OR "X"."COMAR"='EUREX' OR
              "X"."COMAR"='FOREX' OR "X"."COMAR"='LIFFE' OR "X"."COMAR"='METAL' OR "X"."COMAR"='OCC'))
Note
   - dynamic sampling used for this statement (level=2)The optimizer parameters are at their default values.
The database is an 11.2.0.1 and the OS is a Linux Red hat.
can someone help me to tune this query please?

Thanks Tubby for your reply,
We don't gather statistics at all on this table because it's a process table: on the production database we may have several processes which insert/delet/update rows into this table so we prefer to rely on Dynamic Sampling instead of gathering statistics each time a process need to access this table.
I don't dynamic sampling is the problem here because when i use the level 10 the execution plan is the same:
SQL> alter session set optimizer_dynamic_sampling=10;
Session modifiÚe.
EcoulÚ : 00 :00 :00.00
SQL> explain plan for
2 UPDATE fiscpt x
3     SET (x.cimld) =
4            (SELECT COUNT (*)
5               FROM fiscpt f
6              WHERE f.comar = x.comar
7                AND f.coint = x.coint
8                AND f.nucpt = x.nucpt
9                AND f.codev != x.codev
10                AND f.cimvt != 0)
11   WHERE x.comar IN ('CBOT', 'CME', 'EUREX', 'FOREX', 'LIFFE', 'METAL', 'OCC');
ExplicitÚ.
EcoulÚ : 00 :00 :01.04
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 697684605
| Id | Operation                          | Name    | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT                   |         |   179K| 5780K|   896K (20)| 02:59:23 |
|   1 | UPDATE                            | FISCPT |       |       |            |          |
|   2 |   INLIST ITERATOR                  |         |       |       |            |          |
|* 3 |    INDEX RANGE SCAN                | FISCPT1 |   179K| 5780K|     5   (0)| 00:00:01 |
|   4 |   SORT AGGREGATE                   |         |     1 |    33 |            |          |
|* 5 |    TABLE ACCESS BY INDEX ROWID     | FISCPT |     1 |    33 |     4 (25)| 00:00:01 |
|   6 |     BITMAP CONVERSION TO ROWIDS    |         |       |       |            |          |
|   7 |      BITMAP AND                    |         |       |       |            |          |
|   8 |       BITMAP CONVERSION FROM ROWIDS|         |       |       |            |          |
|* 9 |        INDEX RANGE SCAN            | FISCPT2 | 1794 |       |     1   (0)| 00:00:01 |
| 10 |       BITMAP CONVERSION FROM ROWIDS|         |       |       |            |          |
| 11 |        SORT ORDER BY               |         |       |       |            |          |
|* 12 |         INDEX RANGE SCAN           | FISCPT1 | 1794 |       |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   3 - access("X"."COMAR"='CBOT' OR "X"."COMAR"='CME' OR "X"."COMAR"='EUREX' OR
              "X"."COMAR"='FOREX' OR "X"."COMAR"='LIFFE' OR "X"."COMAR"='METAL' OR
              "X"."COMAR"='OCC')
   5 - filter("F"."CIMVT"<>0)
   9 - access("F"."COINT"=:B1 AND "F"."NUCPT"=:B2)
12 - access("F"."COMAR"=:B1)
       filter("F"."CODEV"<>:B1 AND "F"."COMAR"=:B2)
Note
   - dynamic sampling used for this statement (level=10)I have tested the query you provided and the execution plan is almost the same (A FILTER clause is added but the COST isthe same):
SQL> explain plan for
2 UPDATE   fiscpt x
3     SET (x.cimld) =
4            (SELECT COUNT (*)
5               FROM fiscpt f
6              WHERE f.comar = x.comar
7                AND f.coint = x.coint
8                AND f.nucpt = x.nucpt
9                AND f.codev != x.codev
10                AND f.cimvt != 0
11                and   f.comar IN ('CBOT', 'CME', 'EUREX', 'FOREX', 'LIFFE', 'METAL', 'OCC')
12                )
13   WHERE x.comar IN ('CBOT', 'CME', 'EUREX', 'FOREX', 'LIFFE', 'METAL', 'OCC');
ExplicitÚ.
EcoulÚ : 00 :00 :00.01
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1565986742
| Id | Operation                           | Name    | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT                    |         |   154K| 4984K|   773K (20)| 02:34:41 |
|   1 | UPDATE                             | FISCPT |       |       |            |          |
|   2 |   INLIST ITERATOR                   |         |       |       |            |          |
|* 3 |    INDEX RANGE SCAN                 | FISCPT1 |   154K| 4984K|     5   (0)| 00:00:01 |
|   4 |   SORT AGGREGATE                    |         |     1 |    33 |            |          |
|* 5 |    FILTER                           |         |       |       |            |          |
|* 6 |     TABLE ACCESS BY INDEX ROWID     | FISCPT |     1 |    33 |     4 (25)| 00:00:01 |
|   7 |      BITMAP CONVERSION TO ROWIDS    |         |       |       |            |          |
|   8 |       BITMAP AND                    |         |       |       |            |          |
|   9 |        BITMAP CONVERSION FROM ROWIDS|         |       |       |            |          |
|* 10 |         INDEX RANGE SCAN            | FISCPT2 | 1547 |       |     1   (0)| 00:00:01 |
| 11 |        BITMAP CONVERSION FROM ROWIDS|         |       |       |            |          |
| 12 |         SORT ORDER BY               |         |       |       |            |          |
|* 13 |          INDEX RANGE SCAN           | FISCPT1 | 1547 |       |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   3 - access("X"."COMAR"='CBOT' OR "X"."COMAR"='CME' OR "X"."COMAR"='EUREX' OR
              "X"."COMAR"='FOREX' OR "X"."COMAR"='LIFFE' OR "X"."COMAR"='METAL' OR "X"."COMAR"='OCC')
   5 - filter(:B1='CBOT' OR :B2='CME' OR :B3='EUREX' OR :B4='FOREX' OR :B5='LIFFE' OR
              :B6='METAL' OR :B7='OCC')
   6 - filter(("F"."COMAR"='CBOT' OR "F"."COMAR"='CME' OR "F"."COMAR"='EUREX' OR
              "F"."COMAR"='FOREX' OR "F"."COMAR"='LIFFE' OR "F"."COMAR"='METAL' OR
              "F"."COMAR"='OCC') AND "F"."CIMVT"<>0)
10 - access("F"."COINT"=:B1 AND "F"."NUCPT"=:B2)
13 - access("F"."COMAR"=:B1)
       filter("F"."CODEV"<>:B1 AND ("F"."COMAR"='CBOT' OR "F"."COMAR"='CME' OR
              "F"."COMAR"='EUREX' OR "F"."COMAR"='FOREX' OR "F"."COMAR"='LIFFE' OR
              "F"."COMAR"='METAL' OR "F"."COMAR"='OCC') AND "F"."COMAR"=:B2)
Note
   - dynamic sampling used for this statement (level=2)I have executed this statement for 50 minutes and it is still running now
Furthermore, I have used the tuning advisor but it has not found any recommendation.
is it normal that oracle takes 1hour to update 175k rows?

How to get rid of 'BITMAP CONVERSION' in Execution Plan.

Hi I am using oracle 10g.
I am getting the path of execution of the query something as below. I have posted some part of it not all.
I want to get rid of this 'BITMAP CONVERSION' Section of the path, is there any hint for the same in oracle?
| 56 |      TABLE ACCESS BY INDEX ROWID      | XMVL_ONLINE_VIEW_BASE         | 7274 | 1662K|       | 3320 (21)| 00:00:17 |
| 57 |       BITMAP CONVERSION TO ROWIDS     |                               |       |       |       |            |          |
| 58 |        BITMAP AND                     |                               |       |       |       |            |          |
| 59 |         BITMAP OR                     |                               |       |       |       |            |          |
| 60 |          BITMAP CONVERSION FROM ROWIDS|                               |       |       |       |            |          |
| 61 |           SORT ORDER BY               |                               |       |       |       |            |          |
| 62 |            INDEX RANGE SCAN           | IDX_XMVLONLINEVIEW_BCOMPANYPK |       |       |       |     4 (50)| 00:00:01 |
| 63 |          BITMAP CONVERSION FROM ROWIDS|                               |       |       |       |            |          |
| 64 |           SORT ORDER BY               |                               |       |       | 3608K|            |          |
| 65 |            INDEX RANGE SCAN           | IDX_XMVLONLINEVIEW_BCOMPANYPK |       |       |       |     4 (50)| 00:00:01 |
| 66 |         BITMAP CONVERSION FROM ROWIDS |                               |       |       |       |            |          |
| 67 |          SORT ORDER BY                |                               |       |       | 3288K|            |          |
| 68 |           INDEX RANGE SCAN            | IDX_XMVLVIEW_UPPERVENDORNAME |       |       |       |    59 (45)| 00:00:01 |

Mark,
Please check below link :
http://www.orafaq.com/node/1420
In the above link there is a query :
EXPLAIN PLAN FOR
SELECT *
FROM ef_actl_expns
WHERE lbcr_sk IN (
SELECT lbcr_sk
FROM ed_lbr_cst_role
WHERE lbr_actv_typ_cd = 'A'
If it is ALTER SESSION SET OPTIMIZER_MODE = 'FIRST_ROWS' then there is "BITMAP CONVERSION TO ROWIDS" in the execution plan, but if it is ALTER SESSION SET OPTIMIZER_MODE = 'FIRST_ROWS_1' then there is no "BITMAP CONVERSION" in the plan. So, can we suggest to OP to go for ALTER SESSION SET OPTIMIZER_MODE = 'FIRST_ROWS_1' ?
But yes, as you stated that what is 4 digit of Oracle version is also mising in the above link. I am just asking that is it good to go with ALTER SESSION SET OPTIMIZER_MODE = 'FIRST_ROWS_1' please ? Because generally in the execution plan "BITMAP CONVERSION" happens for star transformation so, I think below link may also be interest to OP :
http://docs.oracle.com/cd/B19306_01/server.102/b14223/schemas.htm
Regards
Girish Sharma

Very Slow Query due to Bitmap Conversion

I have a strange problem with the performance of a spatial query. If I perform a 'SELECT non_geom_column FROM my_table WHERE complicated_join_query' the result comes back sub-second. However, when I replace the column selected with geometry and perform 'SELECT geom_column FROM my_table WHERE same_complicated_join_query' the response takes over a minute.
The issue is that in the second case, despite the identical where clause, the explain plan is significantly different. In the 'select geom_column' query there is a BITMAP CONVERSION (TO ROWIDS) which accounts for all of the extra time, where as in the 'select other_column' query that conversion is replaced with TABLE ACCESS (BY INDEX ROWID) which is near instant.
I have tried putting in some hints, although I do not have much experience with hints, and have also tried nesting the query in various sub-selects. Whatever I try I can not persuade the explain plan to drop the bitmap conversion when I select the geometry column. The full query and an explanation of that query are below. I have run out of things to try, so any help or suggestions at all would be much appreciated.
Regards,
Chris
Explanation and query
My application allows users to select geometries from a map image through clicking, dragging a box and various other means. The image is then refreshed - highlighting geometries based on the query with which I am having trouble. The user is then able to deselect any of those highlighted geometries, or append others with additional clicks or dragged selections.
If there are 2 (or any even number of) clicks within the same geometry then that geometry is deselected. Alternatively the geometry could have been selected through an intersection with a dragged box, and then clicked in to deselect - again an even number of selections. Any odd number of selections (i.e. selecting, deselecting, then selecting again) would result in the geometry being selected.
The application can not know if the multiple user clicks are in the same geometry, as it simply has an image to work with, so all it does is pass all the clicks so far to the database to deal with.
My query therefore does each spatial point or rectangle query in turn and then appends the unique key for the rows each returned to a list. After performing all of the queries it groups the list by the key and the groups with an odd total are 'selected'. To do this logic in a single where clause I have ended up with nested select statements that are joined with union all commands.
The query is therefore..
SELECT
--the below column (geometry) makes it very slow...replacing it with any non-spatial column takes less than 1/100 of the time - that is my problem!
geometry
FROM
my_table
WHERE
primary_key IN
SELECT primary_key FROM
SELECT primary_key FROM my_table WHERE
sdo_relate(geometry, mdsys.sdo_geometry(2003, 81989, NULL, sdo_elem_info_array(1, 1003, 3), sdo_ordinate_array( rectangle co-ords )), 'mask=anyinteract') = 'TRUE'
UNION ALL SELECT primary_key FROM my_table WHERE
sdo_relate(geometry, mdsys.sdo_geometry(2001, 81989, sdo_point_type( point co-ords , NULL), NULL, NULL), 'mask=anyinteract') = 'TRUE'
--potentially more 'union all select...' here
GROUP BY primary_key HAVING mod(count(*),2) = 1
AND
--the below is the bounding rectangle of the whole image to be returned
sdo_filter(geometry, mdsys.sdo_geometry(2003, 81989, NULL, sdo_elem_info_array(1, 1003, 3), sdo_ordinate_array( outer rectangle co-ords )), 'mask=anyinteract') = 'TRUE'

Hi
Thanks for the reply. After a lot more googling- it turns out this is a general Oracle problem and is not solely related to use of the GEOMETRY column. It seems that sometimes, the Oracle optimiser makes an arbitrary decision to do bitmap conversion. No amount of hints will get it to change its mind !
One person reported a similarly negative change after table statistic collection had run.
Why changing the columns being retrieved should change the execution path, I do not know.
We have a numeric primary key which is always set to a positive value. When I added "AND primary_key_column > 0" (a pretty pointless clause) the optimiser changed the way it works and we got it working fast again.
Chris

How to stop bitmap conversion

Hi All,
Here is the situation.
To get the reports one global temporary table has been created.
Whenever reports has to generate
1) It first insert records into temporary table from multiple tables based on select statement (here global temporary table is not analyzed after the inserts of millions records)
Insert into temp_table (select * from table_a,table_b where <condition) ;
number of records in temp_table = 5-10 millions
2) Now the reports are being generated with select statement that uses temporary table along with other table
Select <column_list> from temp_table , table_c where <some_condition>;
If I check the execution plan it includes bitmap conversion from row_id and to_id.
ID PARENT OPERATION OBJECT_NAME
0 SELECT STATEMENT
1 0 TABLE ACCESS BY INDEX ROWID LXRO_685993E3
2 1 NESTED LOOPS
3 2 INDEX FULL SCAN MXTEMPOID_MXOID_MXINDEX
4 2 BITMAP CONVERSION TO ROWIDS
5 4 BITMAP AND
6 5 BITMAP CONVERSION FROM ROWIDS
7 6 INDEX RANGE SCAN LXRO_685993E3_LXFROMLAT_INDEX
8 5 BITMAP CONVERSION FROM ROWIDS
9 8 INDEX RANGE SCAN LXRO_685993E3_LXTYPE_INDEX
To execute this query it takes long time compare to non bitmap conversion.
3) Whenevr I gather stats on the temp_table and see the new execution plan look like following (no bitmap conversion). Gathering stats only affect the subsequent queries not the current query which is running with bitmap conversion. Here I want to stop the bitmap conversion for the current query. I mean before it picks up the execution plan with bitmap conversion
ID PARENT OPERATION OBJECT_NAME
0 SELECT STATEMENT
1 0 TABLE ACCESS BY INDEX ROWID LXRO_685993E3
2 1 NESTED LOOPS
3 2 INDEX SKIP SCAN MXTEMPOID_MXOID_MXINDEX
4 2 INDEX RANGE SCAN LXRO_685993E3_TYPFLATFID_INDEX
4) Please explain how can I stop the bitmap conversion happening in execution plan. (had it been permanent table once the stats gathering is enough but as its temporary table)
5) after the report generation records from the temp tables are deleted immediately.
Thank you
-Anurag

user635138 wrote:
Hi Jonathan,
a) table is created as "on commit delete rows" (the default)
b) user is getting rid of the temporary data by deleting it,Not related to the index issue, but with "on commit delete rows", the users don't need to delete the GTT data, they can simply issue a "commit;" and their data will disappear. It's possible, of course, that the 3rd party application won't let you do this.
c) everyone who uses this table insert different volumes of data from different different select queriesSo we need to know if there are any statst generated at any time - perhaps by program, possibly by dynamic_sampling, that could cause plans to change when cursors were invalidated. Your early posts mentioned gathering stats on the GTT - but if you use any of the normal collection method with an "on commit delete rows" table, you should get stats showing no data in the table, and that is likely to affect the execution plan. What method are you using to generate the plan, by the way ?
d) What indexes exist on this table. for this see the syntax of table and index. it might help to come to solution
My mistake - I should have noticed that the bitmap conversion was happening on the other table, not the GTT. This suggests that you may need to consider the two-column index as a solution to the problem - but before you do that, take a look at the queries and data. You say that you get 5M to 10M rows in the GTT: that's quite a lot of "temporary" data - without looking at what the optimizer suggests, can you work out a sensible execution path for the query.
In passing - you have "conditions" in the where clause, but how variable are these, and are they only join coniditions or do you also have some flitering conditions on the non-GTT.
>
More over user executes MQL statement (this MQL is converted to SQL internally then comes on database) I have very little knowledge of MQl, don't know what change has to be made into MQL to add hints in SQL statement. no control over SQL. so only thing is, Is there any way to gather stats on table before report generation.
If you can load a real table with representative data, you could generate stats for it, then transfer the stats to the GTT. Another option - with the limitations of the dynamic_sampling hint - is to set the parameter optimizer_dynamic_sampling to the value 2, which will tell the optimizer to sample a few blocks from every table that has no stats (and this includes GTTs automatically). If you try this, remember that you seem to have collected zero stats on the GTT, so you may have to delete these before Oracle samples the table.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan

Bitmap Conversion

I hope someone can help me understand this situation.
Oracle 10.2.0.3 running on aix.
Production environment and DEV environment both identically loaded with the same data, stats exported from PROD environment and loaded into DEV environment.
SYSTEM stats modified in DEV to reflect production values. The difference being in the size of the servers.., 4 cpu in dev vs 20 cpu in prod, but even the init parms are the same.
Identical queries and I'm trying to determine WHY I'm getting two different optimization plans.., I'm sure it is something simple I am overlooking but I'm stuck.
(I also realize I can force off the bitmap conversion.., but don't want to force that route unless necessary)
PRODUCTION QUERY: index range scan using XIE8ORDERS
DEV QUERY: bitmap conversion using two b-tree indexes
PROD EXPLAIN
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 398 | 162K| 34748 (1)| 00:03:48 |
| 1 | NESTED LOOPS | | 398 | 162K| 34748 (1)| 00:03:48 |
| 2 | NESTED LOOPS | | 188 | 70876 | 34746 (1)| 00:03:48 |
| 3 | NESTED LOOPS | | 144 | 50544 | 34744 (1)| 00:03:48 |
| 4 | NESTED LOOPS | | 110 | 35750 | 34743 (1)| 00:03:48 |
| 5 | NESTED LOOPS | | 105 | 31395 | 34742 (1)| 00:03:48 |
| 6 | NESTED LOOPS | | 5665 | 1598K| 33719 (1)| 00:03:42 |
| 7 | NESTED LOOPS | | 483 | 128K| 14 (0)| 00:00:01 |
| 8 | NESTED LOOPS | | 412 | 99K| 10 (0)| 00:00:01 |
|* 9 | TABLE ACCESS BY INDEX ROWID| PROBLEM | 391 | 86411 | 6 (0)| 00:00:01 |
|* 10 | INDEX RANGE SCAN | XIE3PROBLEM | 1408 | | 1 (0)| 00:00:01 |
| 11 | TABLE ACCESS BY INDEX ROWID| CODE_VALUE | 1 | 26 | 1 (0)| 00:00:01 |
|* 12 | INDEX UNIQUE SCAN | XPKCODE_VALUE | 1 | | 1 (0)| 00:00:01 |
|* 13 | TABLE ACCESS BY INDEX ROWID | PERSON | 1 | 26 | 1 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | XPKPERSON | 1 | | 1 (0)| 00:00:01 |
|* 15 | TABLE ACCESS BY INDEX ROWID | ORDERS | 12 | 192 | 70 (2)| 00:00:01 |
|* 16 | INDEX RANGE SCAN | XIE8ORDERS | 39686 | | 1 (0)| 00:00:01 |
| 17 | TABLE ACCESS BY INDEX ROWID | TASK_ACTIVITY | 1 | 10 | 1 (0)| 00:00:01 |
|* 18 | INDEX RANGE SCAN | XIE4TASK_ACTIVITY | 57 | | 1 (0)| 00:00:01 |
| 19 | TABLE ACCESS BY INDEX ROWID | CODE_VALUE | 1 | 26 | 1 (0)| 00:00:01 |
|* 20 | INDEX UNIQUE SCAN | XPKCODE_VALUE | 1 | | 1 (0)| 00:00:01 |
| 21 | TABLE ACCESS BY INDEX ROWID | PRSNL | 1 | 26 | 1 (0)| 00:00:01 |
|* 22 | INDEX UNIQUE SCAN | XPKPRSNL | 1 | | 1 (0)| 00:00:01 |
| 23 | TABLE ACCESS BY INDEX ROWID | PRSNL | 1 | 26 | 1 (0)| 00:00:01 |
|* 24 | INDEX UNIQUE SCAN | XPKPRSNL | 1 | | 1 (0)| 00:00:01 |
|* 25 | TABLE ACCESS BY INDEX ROWID | NOMENCLATURE | 2 | 80 | 1 (0)| 00:00:01 |
|* 26 | INDEX UNIQUE SCAN | XPKNOMENCLATURE | 1 | | 1 (0)| 00:00:01 |
DEV EXPLAIN
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 398 | 162K| 19780 (39)| 00:06:53 |
| 1 | NESTED LOOPS | | 398 | 162K| 19780 (39)| 00:06:53 |
| 2 | NESTED LOOPS | | 188 | 70876 | 19778 (39)| 00:06:52 |
| 3 | NESTED LOOPS | | 144 | 50544 | 19777 (39)| 00:06:52 |
| 4 | NESTED LOOPS | | 110 | 35750 | 19776 (39)| 00:06:52 |
| 5 | NESTED LOOPS | | 105 | 31395 | 19775 (39)| 00:06:52 |
|* 6 | HASH JOIN | | 5665 | 1598K| 18755 (41)| 00:06:31 |
| 7 | NESTED LOOPS | | 483 | 128K| 14 (0)| 00:00:01 |
| 8 | NESTED LOOPS | | 412 | 99K| 10 (0)| 00:00:01 |
|* 9 | TABLE ACCESS BY INDEX ROWID | PROBLEM | 391 | 86411 | 6 (0)| 00:00:01 |
|* 10 | INDEX RANGE SCAN | XIE3PROBLEM | 1408 | | 1 (0)| 00:00:01 |
| 11 | TABLE ACCESS BY INDEX ROWID | CODE_VALUE | 1 | 26 | 1 (0)| 00:00:01 |
|* 12 | INDEX UNIQUE SCAN | XPKCODE_VALUE | 1 | | 1 (0)| 00:00:01 |
|* 13 | TABLE ACCESS BY INDEX ROWID | PERSON | 1 | 26 | 1 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | XPKPERSON | 1 | | 1 (0)| 00:00:01 |
|* 15 | TABLE ACCESS BY INDEX ROWID | ORDERS | 309M| 4717M| 17552 (37)| 00:06:06 |
| 16 | BITMAP CONVERSION TO ROWIDS | | | | | |
| 17 | BITMAP MINUS | | | | | |
| 18 | BITMAP MINUS | | | | | |
| 19 | BITMAP MINUS | | | | | |
| 20 | BITMAP MINUS | | | | | |
| 21 | BITMAP CONVERSION FROM ROWIDS| | | | | |
| 22 | SORT ORDER BY | | | | | |
| 23 | INDEX FULL SCAN | XIE16ORDERS | | | 8853 (1)| 00:03:05 |
| 24 | BITMAP CONVERSION FROM ROWIDS| | | | | |
| 25 | SORT ORDER BY | | | | | |
|* 26 | INDEX RANGE SCAN | XIE10ORDERS | | | 18 (0)| 00:00:01 |
| 27 | BITMAP CONVERSION FROM ROWIDS | | | | | |
| 28 | SORT ORDER BY | | | | | |
|* 29 | INDEX RANGE SCAN | XIE10ORDERS | | | 18 (0)| 00:00:01 |
| 30 | BITMAP CONVERSION FROM ROWIDS | | | | | |
| 31 | SORT ORDER BY | | | | | |
|* 32 | INDEX RANGE SCAN | XIE10ORDERS | | | 18 (0)| 00:00:01 |
| 33 | BITMAP CONVERSION FROM ROWIDS | | | | | |
| 34 | SORT ORDER BY | | | | | |
|* 35 | INDEX RANGE SCAN | XIE10ORDERS | | | 18 (0)| 00:00:01 |
| 36 | TABLE ACCESS BY INDEX ROWID | TASK_ACTIVITY | 1 | 10 | 1 (0)| 00:00:01 |
|* 37 | INDEX RANGE SCAN | XIE4TASK_ACTIVITY | 57 | | 1 (0)| 00:00:01 |
| 38 | TABLE ACCESS BY INDEX ROWID | CODE_VALUE | 1 | 26 | 1 (0)| 00:00:01 |
|* 39 | INDEX UNIQUE SCAN | XPKCODE_VALUE | 1 | | 1 (0)| 00:00:01 |
| 40 | TABLE ACCESS BY INDEX ROWID | PRSNL | 1 | 26 | 1 (0)| 00:00:01 |
|* 41 | INDEX UNIQUE SCAN | XPKPRSNL | 1 | | 1 (0)| 00:00:01 |
| 42 | TABLE ACCESS BY INDEX ROWID | PRSNL | 1 | 26 | 1 (0)| 00:00:01 |
|* 43 | INDEX UNIQUE SCAN | XPKPRSNL | 1 | | 1 (0)| 00:00:01 |
|* 44 | TABLE ACCESS BY INDEX ROWID | NOMENCLATURE | 2 | 80 | 1 (0)| 00:00:01 |
|* 45 | INDEX UNIQUE SCAN | XPKNOMENCLATURE | 1 | | 1 (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------------

No profiles, no outlines. stats are the same. INIT PARMS are "virtually" the same
(PROD)
NAME VALUE
cpu_count 20
create_bitmap_area_size 8388608
db_block_size 8192
db_cache_size 16257122304
db_file_multiblock_read_count 16
db_keep_cache_size 0
db_recycle_cache_size 83886080
db_unique_name h3prd
hash_area_size 52428800
large_pool_size 117440512
object_cache_max_size_percent 10
object_cache_optimal_size 102400
open_cursors 2000
optimizer_index_caching 100
optimizer_index_cost_adj 1
optimizer_mode ALL_ROWS
parallel_max_servers 400
parallel_server_instances 1
parallel_threads_per_cpu 2
pga_aggregate_target 3670016000
sga_max_size 20971520000
sga_target 0
shared_pool_reserved_size 167772160
shared_pool_size 3355443200
sort_area_retained_size 26214400
sort_area_size 26214400
DEV
NAME VALUE
cpu_count 4
create_bitmap_area_size 8388608
db_block_size 8192
db_cache_size 16257122304
db_file_multiblock_read_count 16
db_keep_cache_size 0
db_recycle_cache_size 67108864
db_unique_name h3prd
hash_area_size 52428800
large_pool_size 117440512
object_cache_max_size_percent 10
object_cache_optimal_size 102400
open_cursors 4000
optimizer_index_caching 100
optimizer_index_cost_adj 1
optimizer_mode ALL_ROWS
parallel_max_servers 40
parallel_server_instances 1
parallel_threads_per_cpu 2
pga_aggregate_target 3961100697
sga_max_size 20971520000
sga_target 0
shared_pool_reserved_size 167772160
shared_pool_size 3355443200
sort_area_retained_size 26214400
sort_area_size 26214400
FROM PROD..., simple index scan
SELECT
PI_GET_MRN_LATEST(PERSON.PERSON_ID),
PROBLEM.ANNOTATED_DISPLAY,
PROBLEM.END_EFFECTIVE_DT_TM,
PROBLEM.BEG_EFFECTIVE_DT_TM,
CV_PROBLEM_CLASS_CD.DISPLAY,
PROVIDER_PROBLEM_UPDT.NAME_FULL_FORMATTED,
PERSON.NAME_FULL_FORMATTED,
CV_PROB_LIFE_CYCLE_CD.DISPLAY,
TASK_UPDT_PRSNL.NAME_FULL_FORMATTED,
pi_from_gmt(PROBLEM.UPDT_DT_TM,( 'NONE' ))
FROM
PROBLEM,
NOMENCLATURE NOMENCLATURE_PROBLEM,
PERSON,
CODE_VALUE CV_PROBLEM_CLASS_CD,
CODE_VALUE CV_PROB_LIFE_CYCLE_CD,
TASK_ACTIVITY,
ORDERS,
PRSNL TASK_UPDT_PRSNL,
PRSNL PROVIDER_PROBLEM_UPDT
WHERE
( PROBLEM.NOMENCLATURE_ID=NOMENCLATURE_PROBLEM.NOMENCLATURE_ID )
AND ( PROBLEM.PERSON_ID=PERSON.PERSON_ID )
AND ( CV_PROBLEM_CLASS_CD.CODE_VALUE=PROBLEM.CLASSIFICATION_CD )
AND ( CV_PROB_LIFE_CYCLE_CD.CODE_VALUE=PROBLEM.LIFE_CYCLE_STATUS_CD )
AND ( TASK_ACTIVITY.ORDER_ID=ORDERS.ORDER_ID )
AND ( TASK_UPDT_PRSNL.PERSON_ID=TASK_ACTIVITY.UPDT_ID )
AND ( PROVIDER_PROBLEM_UPDT.PERSON_ID=PROBLEM.UPDT_ID )
AND ( PERSON.PERSON_ID=ORDERS.PERSON_ID AND ORDERS.ACTIVE_IND=1 AND PERSON.ACTIVE_IND=1 )
AND (PERSON.ACTIVE_IND = 1 )
AND ( ( NOMENCLATURE_PROBLEM.SOURCE_IDENTIFIER IN ( '038.12','041.12','202940017','2536045013','420207019','451474015','45
5883011','V02.54','V09.0','V12.04'
,'188335012','2158224017','2158226015','2158252014','2532524011','008.45','10871012','2156783016','2643559016','28658
0015','2471361015' )
OR PROBLEM.ANNOTATED_DISPLAY LIKE '%VRE%'
OR PROBLEM.ANNOTATED_DISPLAY LIKE '%MRSA%'
OR PROBLEM.ANNOTATED_DISPLAY LIKE '%VRSA%'
OR PROBLEM.ANNOTATED_DISPLAY LIKE '%DIFFICILE%'
OR PROBLEM.ANNOTATED_DISPLAY LIKE '%KPC%'
OR PROBLEM.ANNOTATED_DISPLAY LIKE '%ESBL%' )
AND PROBLEM.UPDT_DT_TM >= TRUNC(SYSDATE) - 1
AND PROBLEM.END_EFFECTIVE_DT_TM > '30-12-2100 00:00:00'
AND ( ( PERSON.PERSON_ID ) NOT IN (21475056,23277681,23823599,30459046) )
call count cpu elapsed disk query current rows
Parse 1 8.83 9.96 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 503 7.07 167.75 10871 640458 0 4011
total 505 15.90 177.71 10871 640458 0 4011
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 5
Rows Row Source Operation
4011 NESTED LOOPS (cr=273608 pr=25 pw=0 time=1812278 us)
8204 NESTED LOOPS (cr=609237 pr=9459 pw=0 time=8129641 us)
8204 NESTED LOOPS (cr=592325 pr=9459 pw=0 time=7998354 us)
8204 NESTED LOOPS (cr=575413 pr=9458 pw=0 time=7752228 us)
8204 NESTED LOOPS (cr=558501 pr=9458 pw=0 time=7604539 us)
227552 NESTED LOOPS (cr=62460 pr=7745 pw=0 time=122650230 us)
95 NESTED LOOPS (cr=524 pr=8 pw=0 time=8727 us)
95 NESTED LOOPS (cr=227 pr=2 pw=0 time=4449 us)
95 TABLE ACCESS BY INDEX ROWID PROBLEM (cr=28 pr=2 pw=0 time=1116 us)
99 INDEX RANGE SCAN XIE3PROBLEM (cr=11 pr=0 pw=0 time=453 us)(object id 62428)
95 TABLE ACCESS BY INDEX ROWID CODE_VALUE (cr=199 pr=0 pw=0 time=2369 us)
95 INDEX UNIQUE SCAN XPKCODE_VALUE (cr=104 pr=0 pw=0 time=1405 us)(object id 62170)
95 TABLE ACCESS BY INDEX ROWID PERSON (cr=297 pr=6 pw=0 time=166064 us)
95 INDEX UNIQUE SCAN XPKPERSON (cr=199 pr=1 pw=0 time=19944 us)(object id 61446)
227552 TABLE ACCESS BY INDEX ROWID ORDERS (cr=61936 pr=7737 pw=0 time=135751758 us)
227552 INDEX RANGE SCAN XIE8ORDERS (cr=1827 pr=217 pw=0 time=4165532 us)(object id 61492)
8204 TABLE ACCESS BY INDEX ROWID TASK_ACTIVITY (cr=502112 pr=3048 pw=0 time=37997753 us)
8204 INDEX RANGE SCAN XIE4TASK_ACTIVITY (cr=493952 pr=2542 pw=0 time=30470479 us)(object id 61866)
8204 TABLE ACCESS BY INDEX ROWID CODE_VALUE (cr=16912 pr=0 pw=0 time=145634 us)
8204 INDEX UNIQUE SCAN XPKCODE_VALUE (cr=8708 pr=0 pw=0 time=84922 us)(object id 62170)
8204 TABLE ACCESS BY INDEX ROWID PRSNL (cr=16912 pr=1 pw=0 time=135174 us)
8204 INDEX UNIQUE SCAN XPKPRSNL (cr=8708 pr=0 pw=0 time=60622 us)(object id 62718)
8204 TABLE ACCESS BY INDEX ROWID PRSNL (cr=16912 pr=0 pw=0 time=150361 us)
8204 INDEX UNIQUE SCAN XPKPRSNL (cr=8708 pr=0 pw=0 time=87736 us)(object id 62718)
4011 TABLE ACCESS BY INDEX ROWID NOMENCLATURE (cr=25116 pr=77 pw=0 time=1382431 us)
8204 INDEX UNIQUE SCAN XPKNOMENCLATURE (cr=16912 pr=32 pw=0 time=553792 us)(object id 61952)
FROM DEV..., (bitmap conversion)
SELECT
PI_GET_MRN_LATEST(PERSON.PERSON_ID),
PROBLEM.ANNOTATED_DISPLAY,
PROBLEM.END_EFFECTIVE_DT_TM,
PROBLEM.BEG_EFFECTIVE_DT_TM,
CV_PROBLEM_CLASS_CD.DISPLAY,
PROVIDER_PROBLEM_UPDT.NAME_FULL_FORMATTED,
PERSON.NAME_FULL_FORMATTED,
CV_PROB_LIFE_CYCLE_CD.DISPLAY,
TASK_UPDT_PRSNL.NAME_FULL_FORMATTED,
pi_from_gmt(PROBLEM.UPDT_DT_TM,( 'NONE' ))
FROM
PROBLEM,
NOMENCLATURE NOMENCLATURE_PROBLEM,
PERSON,
CODE_VALUE CV_PROBLEM_CLASS_CD,
CODE_VALUE CV_PROB_LIFE_CYCLE_CD,
TASK_ACTIVITY,
ORDERS,
PRSNL TASK_UPDT_PRSNL,
PRSNL PROVIDER_PROBLEM_UPDT
WHERE
( PROBLEM.NOMENCLATURE_ID=NOMENCLATURE_PROBLEM.NOMENCLATURE_ID )
AND ( PROBLEM.PERSON_ID=PERSON.PERSON_ID )
AND ( CV_PROBLEM_CLASS_CD.CODE_VALUE=PROBLEM.CLASSIFICATION_CD )
AND ( CV_PROB_LIFE_CYCLE_CD.CODE_VALUE=PROBLEM.LIFE_CYCLE_STATUS_CD )
AND ( TASK_ACTIVITY.ORDER_ID=ORDERS.ORDER_ID )
AND ( TASK_UPDT_PRSNL.PERSON_ID=TASK_ACTIVITY.UPDT_ID )
AND ( PROVIDER_PROBLEM_UPDT.PERSON_ID=PROBLEM.UPDT_ID )
AND ( PERSON.PERSON_ID=ORDERS.PERSON_ID AND ORDERS.ACTIVE_IND=1 AND PERSON.ACTIVE_IND=1 )
AND (PERSON.ACTIVE_IND = 1 )
AND ( ( NOMENCLATURE_PROBLEM.SOURCE_IDENTIFIER IN ( '038.12','041.12','202940017','2536045013','420207019','451474015','45
5883011','V02.54','V09.0','V12.04'
,'188335012','2158224017','2158226015','2158252014','2532524011','008.45','10871012','2156783016','2643559016','28658
0015','2471361015' )
OR PROBLEM.ANNOTATED_DISPLAY LIKE '%VRE%'
OR PROBLEM.ANNOTATED_DISPLAY LIKE '%MRSA%'
OR PROBLEM.ANNOTATED_DISPLAY LIKE '%VRSA%'
OR PROBLEM.ANNOTATED_DISPLAY LIKE '%DIFFICILE%'
OR PROBLEM.ANNOTATED_DISPLAY LIKE '%KPC%'
OR PROBLEM.ANNOTATED_DISPLAY LIKE '%ESBL%' )
AND PROBLEM.UPDT_DT_TM >= TRUNC(SYSDATE) - 1
AND PROBLEM.END_EFFECTIVE_DT_TM > '30-12-2100 00:00:00'
AND ( ( PERSON.PERSON_ID ) NOT IN (21475056,23277681,23823599,30459046) )
call count cpu elapsed disk query current rows
Parse 1 1.69 2.44 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 50.63 207.46 141237 373765 1 0
total 3 52.32 209.90 141237 373765 1 0
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 5
Rows Row Source Operation
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=14 us)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=14 us)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=13 us)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=13 us)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=13 us)
0 HASH JOIN (cr=0 pr=0 pw=0 time=12 us)
221 NESTED LOOPS (cr=1171 pr=2 pw=0 time=5127 us)
221 NESTED LOOPS (cr=506 pr=0 pw=0 time=2471 us)
221 TABLE ACCESS BY INDEX ROWID PROBLEM (cr=62 pr=0 pw=0 time=474 us)
243 INDEX RANGE SCAN XIE3PROBLEM (cr=5 pr=0 pw=0 time=268 us)(object id 62428)
221 TABLE ACCESS BY INDEX ROWID CODE_VALUE (cr=444 pr=0 pw=0 time=1453 us)
221 INDEX UNIQUE SCAN XPKCODE_VALUE (cr=223 pr=0 pw=0 time=793 us)(object id 62170)
221 TABLE ACCESS BY INDEX ROWID PERSON (cr=665 pr=2 pw=0 time=28292 us)
221 INDEX UNIQUE SCAN XPKPERSON (cr=444 pr=0 pw=0 time=1482 us)(object id 61446)
0 TABLE ACCESS BY INDEX ROWID ORDERS (cr=0 pr=0 pw=0 time=51 us)
0 BITMAP CONVERSION TO ROWIDS (cr=0 pr=0 pw=0 time=50 us)
0 BITMAP MINUS (cr=0 pr=0 pw=0 time=34 us)
0 BITMAP MINUS (cr=0 pr=0 pw=0 time=27 us)
0 BITMAP MINUS (cr=0 pr=0 pw=0 time=22 us)
0 BITMAP MINUS (cr=0 pr=0 pw=0 time=17 us)
0 BITMAP CONVERSION FROM ROWIDS (cr=0 pr=0 pw=0 time=11 us)
0 SORT ORDER BY (cr=0 pr=0 pw=0 time=10 us)
145328388 INDEX FULL SCAN XIE16ORDERS (cr=372594 pr=141235 pw=0 time=145328401 us)(object id 72282)
0 BITMAP CONVERSION FROM ROWIDS (cr=0 pr=0 pw=0 time=5 us)
0 SORT ORDER BY (cr=0 pr=0 pw=0 time=4 us)
0 INDEX RANGE SCAN XIE10ORDERS (cr=0 pr=0 pw=0 time=3 us)(object id 147713)
0 BITMAP CONVERSION FROM ROWIDS (cr=0 pr=0 pw=0 time=4 us)
0 SORT ORDER BY (cr=0 pr=0 pw=0 time=3 us)
0 INDEX RANGE SCAN XIE10ORDERS (cr=0 pr=0 pw=0 time=1 us)(object id 147713)
0 BITMAP CONVERSION FROM ROWIDS (cr=0 pr=0 pw=0 time=4 us)
0 SORT ORDER BY (cr=0 pr=0 pw=0 time=3 us)
0 INDEX RANGE SCAN XIE10ORDERS (cr=0 pr=0 pw=0 time=1 us)(object id 147713)
0 BITMAP CONVERSION FROM ROWIDS (cr=0 pr=0 pw=0 time=4 us)
0 SORT ORDER BY (cr=0 pr=0 pw=0 time=4 us)
0 INDEX RANGE SCAN XIE10ORDERS (cr=0 pr=0 pw=0 time=1 us)(object id 147713)
0 TABLE ACCESS BY INDEX ROWID TASK_ACTIVITY (cr=0 pr=0 pw=0 time=0 us)
0 INDEX RANGE SCAN XIE4TASK_ACTIVITY (cr=0 pr=0 pw=0 time=0 us)(object id 61866)
0 TABLE ACCESS BY INDEX ROWID CODE_VALUE (cr=0 pr=0 pw=0 time=0 us)
0 INDEX UNIQUE SCAN XPKCODE_VALUE (cr=0 pr=0 pw=0 time=0 us)(object id 62170)
0 TABLE ACCESS BY INDEX ROWID PRSNL (cr=0 pr=0 pw=0 time=0 us)
0 INDEX UNIQUE SCAN XPKPRSNL (cr=0 pr=0 pw=0 time=0 us)(object id 62718)
0 TABLE ACCESS BY INDEX ROWID PRSNL (cr=0 pr=0 pw=0 time=0 us)
0 INDEX UNIQUE SCAN XPKPRSNL (cr=0 pr=0 pw=0 time=0 us)(object id 62718)
0 TABLE ACCESS BY INDEX ROWID NOMENCLATURE (cr=0 pr=0 pw=0 time=0 us)
0 INDEX UNIQUE SCAN XPKNOMENCLATURE (cr=0 pr=0 pw=0 time=0 us)(object id 61952)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=13 us)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=13 us)
0 HASH JOIN (cr=0 pr=0 pw=0 time=12 us)
221 NESTED LOOPS (cr=1171 pr=2 pw=0 time=5127 us)
221 NESTED LOOPS (cr=506 pr=0 pw=0 time=2471 us)
221 TABLE ACCESS BY INDEX ROWID PROBLEM (cr=62 pr=0 pw=0 time=474 us)
243 INDEX RANGE SCAN XIE3PROBLEM (cr=5 pr=0 pw=0 time=268 us)(object id 62428)
221 TABLE ACCESS BY INDEX ROWID CODE_VALUE (cr=444 pr=0 pw=0 time=1453 us)
221 INDEX UNIQUE SCAN XPKCODE_VALUE (cr=223 pr=0 pw=0 time=793 us)(object id 62170)
221 TABLE ACCESS BY INDEX ROWID PERSON (cr=665 pr=2 pw=0 time=28292 us)
221 INDEX UNIQUE SCAN XPKPERSON (cr=444 pr=0 pw=0 time=1482 us)(object id 61446)
0 TABLE ACCESS BY INDEX ROWID ORDERS (cr=0 pr=0 pw=0 time=51 us)
0 BITMAP CONVERSION TO ROWIDS (cr=0 pr=0 pw=0 time=50 us)
0 BITMAP MINUS (cr=0 pr=0 pw=0 time=34 us)
0 BITMAP MINUS (cr=0 pr=0 pw=0 time=27 us)
0 BITMAP MINUS (cr=0 pr=0 pw=0 time=22 us)
0 BITMAP MINUS (cr=0 pr=0 pw=0 time=17 us)
0 BITMAP CONVERSION FROM ROWIDS (cr=0 pr=0 pw=0 time=11 us)
0 SORT ORDER BY (cr=0 pr=0 pw=0 time=10 us)
145328388 INDEX FULL SCAN XIE16ORDERS (cr=372594 pr=141235 pw=0 time=145328401 us)(object id 72282)
0 BITMAP CONVERSION FROM ROWIDS (cr=0 pr=0 pw=0 time=5 us)
0 SORT ORDER BY (cr=0 pr=0 pw=0 time=4 us)
0 INDEX RANGE SCAN XIE10ORDERS (cr=0 pr=0 pw=0 time=3 us)(object id 147713)
0 BITMAP CONVERSION FROM ROWIDS (cr=0 pr=0 pw=0 time=4 us)
0 SORT ORDER BY (cr=0 pr=0 pw=0 time=3 us)
0 INDEX RANGE SCAN XIE10ORDERS (cr=0 pr=0 pw=0 time=1 us)(object id 147713)
0 BITMAP CONVERSION FROM ROWIDS (cr=0 pr=0 pw=0 time=4 us)
0 SORT ORDER BY (cr=0 pr=0 pw=0 time=3 us)
0 INDEX RANGE SCAN XIE10ORDERS (cr=0 pr=0 pw=0 time=1 us)(object id 147713)
0 BITMAP CONVERSION FROM ROWIDS (cr=0 pr=0 pw=0 time=4 us)
0 SORT ORDER BY (cr=0 pr=0 pw=0 time=4 us)
0 INDEX RANGE SCAN XIE10ORDERS (cr=0 pr=0 pw=0 time=1 us)(object id 147713)
0 TABLE ACCESS BY INDEX ROWID TASK_ACTIVITY (cr=0 pr=0 pw=0 time=0 us)
0 INDEX RANGE SCAN XIE4TASK_ACTIVITY (cr=0 pr=0 pw=0 time=0 us)(object id 61866)
0 TABLE ACCESS BY INDEX ROWID CODE_VALUE (cr=0 pr=0 pw=0 time=0 us)
0 INDEX UNIQUE SCAN XPKCODE_VALUE (cr=0 pr=0 pw=0 time=0 us)(object id 62170)
0 TABLE ACCESS BY INDEX ROWID PRSNL (cr=0 pr=0 pw=0 time=0 us)
0 INDEX UNIQUE SCAN XPKPRSNL (cr=0 pr=0 pw=0 time=0 us)(object id 62718)
0 TABLE ACCESS BY INDEX ROWID PRSNL (cr=0 pr=0 pw=0 time=0 us)
0 INDEX UNIQUE SCAN XPKPRSNL (cr=0 pr=0 pw=0 time=0 us)(object id 62718)
0 TABLE ACCESS BY INDEX ROWID NOMENCLATURE (cr=0 pr=0 pw=0 time=0 us)
0 INDEX UNIQUE SCAN XPKNOMENCLATURE (cr=0 pr=0 pw=0 time=0 us)(object id 61952)

Bitmap conversion explain plan

Hi friends,
I'm trying to understand the explain plan with queries in my oracle 9.2 database. I have read something about but it is difficult to me to understand why the optimizer uses "bitmap conversion [to rowids]", "bitmap and" and "bitmap conversion [from rowids]". I'm not sure if this is a good or a bad signal. Probably is just I always find bitmap conversion when I'm not happy with queries results timin.
I have not bitmap indexes created in my database, and perhaps is it suggesting me to create them?
Thanks for answers.

Hi agemaia,
Take a look to this link:
http://www.dba-oracle.com/t_bitmap_conversion_to_rowid.htm
I think this answers your question, quite simple. I will write any other useful link.

SQL | not working anymore | BITMAP CONVERSION

* I am a beginner at SQL tuning. Advise/pointers required *
I have two similar schemas, A and B. Major difference is B has much more data than A.
My query Q has always worked on both until last week.
Note: I have no BITMAP index in both schemas
Query Q does not return result on schema B any more, it taking over 1 hour, still no result.
I have studies the explain for query Q on both schema and notice that they are very different.
Major difference is I see, there are too many âBITMAP CONVERSION FROM ROWIDSâ on schema B. e.g. below
| 15 | NESTED LOOPS | | 4483 | 227K| 1162 |
|* 16 | INDEX RANGE SCAN | COMPM_ELE_PERF1 | 4483 | 80694 | 22 |
| 17 | BITMAP CONVERSION TO ROWIDS | | | | |
| 18 | BITMAP AND | | | | |
| 19 | BITMAP CONVERSION FROM ROWIDS| | | | |
|* 20 | INDEX RANGE SCAN | TABLE_A_ROOT_X3 | 1 | | |
| 21 | BITMAP CONVERSION FROM ROWIDS| | | | |
|* 22 | INDEX RANGE SCAN | TABLE_A_ROOT_X1 | 1 | | 537 |
What is the best fix:
â¢     Rewrite the Query (advise)
â¢     Add hints (please provide sample code)
â¢     Change db config (please provide any know config change)
Thanks

I believe you have B Tree indexes and that the optimiser is choosing a plan which will convert the rows from B Tree form into Bitmap form such that it can perform an AND operation to get the required results...so you don't physically have bitmap indexes but its kind of creating them in memory on the fly by using the content of the B Tree indexes.
Without much more information as to the plan and statistics on the tables/indexes/init.ora settings etc... I can't advise why its choosing this plan or why this plan takes so long....lets start with asking what has changed since it last ran quickly ? That's likely to be the problem.
If you want to rule out the indexes as per the previous post then just use a hint (NO_INDEX) and the FULL hints on the tables....
More information please....
Cheers
Jeff

9i BITMAP Conversions in exec plan

Hi,
on 9i (9.2.0.7) hp-ux, optimizer=choose
we have no bitmap indexes on underlined tables yet
sometimes optimizer chooses to do 'BITMAP CONVERSION TO ROWIDS',
[statistics are done using 'FOR ALL INDEXED COLUMNS']
why is this happening? When we use hints select runs in 0.17 sec as opposed to
bitmap coversions it runs minutes... Is there a way to prevent this behaviour other than using hints and outlines?
Thank you,
Dan.

Dan,
This parameter only prevents Oracle to create bitmap index during query execution. I never see other functionnality disabled after setting it.
Rgds
Nico

Bitmap indexes and group by

I'm trying to understand why Oracle 8.1.6 sometimes uses bitmap indexes sometimes not.
Of course I have all the statistics, my bitmap indexes are valid and so on.
The problem is this:
- I have a customer table very very large
- I have many columns with bitmap indexes
- I run this statement:
select education_key, count(*)
from customer
group by education_key
and obtain a correct execution plan:
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=235 Card=5 Bytes=10)
1 0 SORT (GROUP BY NOSORT) (Cost=235 Card=5 Bytes=10)
2 1 BITMAP CONVERSION (COUNT)
3 2 BITMAP INDEX (FULL SCAN) OF 'CL_EDU'
with the use of the bitmap indexes (only five different values)
- now I want to put a condition on a column
which has a bitmap index.
The new statement is:
select education_key, count(*)
from customer
where age_key = 30
group by education_key
No join, only a scan of a sort of
fact table. In this case Oracle
doesn't use the bitmap index on
education_key:
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3458 Card=5 Bytes=20
1 0 SORT (GROUP BY) (Cost=3458 Card=5 Bytes=20)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'CUSTOMER' (Cost=3395 C
ard=18296 Bytes=73184)
3 2 BITMAP CONVERSION (TO ROWIDS)
4 3 BITMAP INDEX (SINGLE VALUE) OF 'CL_AGE'
With this execution plan Oracle has to
read some blocks from the table when I
think that using both the bitmap indexes
the query is faster.
Someone knows why Oracle has this
behaviour? I'm trying to change
many things (also altering statistics
value), but it seems that with a
condition Oracle doesn'use the bitmap
index on the group by column.
null

Hi Michael, what is the address for the lasagne? ....
In init.ora.parms I had 32Mb for bitmap index merge, I suppose it's enough, hovewer I have tried to increase it and nothing changes.
I already use STAR_TRASFORMATION_ENABLED=TRUE.
I have tried with different level of statistics (estimate, compute, also with very precise histograms), always the same
behaviour. I have also tried to change, in a manual way, the statistics in order to change the Oracle behaviour but nothing ...
For this particular statement even if I use the INDEX_COMBINE hint, I mantain the same execution plan.
I use CHOOSE, FIRST_ROWS, ALL_ROWS: always the same behaviour.
I think that Oracle is not able to use a bitmap index on a column involved in a group by when there is another condition in the select.
Hovewer with bitmap indexes, I have many other problems (to read 1% of the table Oracle decides to make a full table scan even if there are the correct bitmap indexes ...).
Many of them are solved using BITMAP_INDEX, but it's difficult to use it in a query tool like Discover or Business Objects because I have to fix the use of INDEX_COMBINE also in situation in which this use is not correct from a performance point of view.
The life with the query optimizer is very hard!
Thank you for your guesses

BITMAP indexes ignored with large IN(...)

I have a fact table with 20 million records joined to a few dimension tables using 10g BITMAP INDEXes but if I add more than two or three items to my SELECT query the optimizer does not choose to use the bitmaps. For example, the first query
SELECT p.period_date, po.agent_id, count(*), SUM(ah.charge_amt)
FROM Travel_History ah, Period p, Agent po
WHERE ah.primary_agent_key = po.agent_key
AND ah.period_key = p.period_key
AND po.agent_id IN( 'DGF ', '001MG ' )
AND p.period_date =
TO_DATE( '20010701', 'YYYYMMDD' )
AND p.period_date =
TO_DATE( '20010801', 'YYYYMMDD' )
GROUP BY po.agent_id, p.period_date
definitely uses my BITMAPs as I see that in my EXECUTION PLAN (i.e. I have set autotrace on):
| 0 | SELECT STATEMENT | | 1 | 32
| 1 | HASH GROUP BY | | 1 | 32
|* 2 | FILTER | | |
| 3 | NESTED LOOPS | | 1 | 32
|* 4 | HASH JOIN | | 1 | 19
|* 5 | TABLE ACCESS FULL | PERIOD | 1 | 10
| 6 | TABLE ACCESS BY INDEX ROWID | TRAVEL_HISTORY | 4000K| 34
| 7 | BITMAP CONVERSION TO ROWIDS | | |
| 8 | BITMAP AND | | |
| 9 | BITMAP OR | | |
|* 10 | BITMAP INDEX SINGLE VALUE| XIF4TRAVEL_HISTORY | |
|* 11 | BITMAP INDEX SINGLE VALUE| XIF4TRAVEL_HISTORY | |
| 12 | BITMAP MERGE | | |
|* 13 | BITMAP INDEX RANGE SCAN | TRVLHIST_MULTI3_BMIX | |
|* 14 | BITMAP INDEX SINGLE VALUE | XIF1TRAVEL_HISTORY | |
|* 15 | TABLE ACCESS BY INDEX ROWID | AGENT | 1 | 13
|* 16 | INDEX UNIQUE SCAN | XPKAGENT | 1 |
There are only a few hundred records for those two dates, and the above query returns in
less than a second.
However, if I replace the two "period_date =" with IN(...) as:
SELECT /*+ INDEX_COMBINE( Travel_history
AcctHist_MULTI3_bmix
XIF4TRAVEL_HISTORY
XIF1TRAVEL_HISTORY )
p.period_date, po.agent_id, count(*), SUM(ah.charge_amt)
FROM Travel_History ah, Period p, Agent po
WHERE ah.primary_agent_key = po.agent_key
AND ah.period_key = p.period_key
AND po.agent_id IN( 'DGF ', '001MG ' )
AND p.period_date IN (
TO_DATE( '20010701', 'YYYYMMDD' ),
TO_DATE( '20010801', 'YYYYMMDD' ) )
GROUP BY po.agent_id, p.period_date
the execution plan goes back to
| 0 | SELECT STATEMENT | | 747 | 23904 | 45760 (7)|
| 1 | HASH GROUP BY | | 747 | 23904 | 45760 (7)|
|* 2 | FILTER | | | | |
|* 3 | HASH JOIN | | 5000K| 152M| 44897 (5)|
| 4 | MERGE JOIN CARTESIAN| | 860 | 19780 | 26 (0)|
|* 5 | TABLE ACCESS FULL | PERIOD | 4 | 40 | 6 (0)|
| 6 | BUFFER SORT | | 215 | 2795 | 20 (0)|
| 7 | TABLE ACCESS FULL | AGENT | 215 | 2795 | 5 (0)|
| 8 | TABLE ACCESS FULL | TRAVEL_HISTORY | 20M| 171M| 44527 (4)|
If I do a UNION with two SELECTs each with a unique period then the BITMAPs get used. I don't get it.
Is there any reason this would be happening???

There are no bitmap indexes, there is a 64k tablespace header block containing the bitmap of occupied and free extents.
Sybrand Bakker
Senior Oracle DBA

Bitmap indexes

hi everyone,
There is table t
and there are several bitmap one-column indexes
i1 on t(c1)
i2 on t(c2)
i3 on t(c3)
Column C1 is not nullable.
Columns C2 and C3 is nullable.
There is query
select /*+ index_combine(t) */
from t
where c1 = :1
   and c2 in (:2, 'X')
   and c3 = :3
| Id | Operation                     |
|   0 | SELECT STATEMENT              |
|   1 | TABLE ACCESS BY INDEX ROWID |
|   2 |   BITMAP CONVERSION TO ROWIDS |
|   3 |    BITMAP AND                 |
|   4 |     BITMAP INDEX SINGLE VALUE |
|   5 |     BITMAP INDEX SINGLE VALUE |
|   6 |     BITMAP OR                 |
|   7 |      BITMAP INDEX SINGLE VALUE|
|   8 |      BITMAP INDEX SINGLE VALUE|
---------------------------------------Fine.
But if I create following indexes (and drop previous)
create bitmap index idx1 on t(C1, C2);
create bitmap index idx2 on t(C1, C3);
then the plan of the query above is following:
| Id | Operation                    |
|   0 | SELECT STATEMENT             |
|   1 | TABLE ACCESS BY INDEX ROWID |
|   2 |   BITMAP CONVERSION TO ROWIDS|
|   3 |    BITMAP INDEX SINGLE VALUE |
--------------------------------------And the question:
why the plan does not consist BITMAP AND ?
Is it possible to scan both new indexes in the query with BITMAP AND?
Thanks

793769 wrote:
Jonathan Lewis wrote:
I think this means there's a hole in the optimizer's legal strategies that you might have to fill by other methods.Do I right understand that it is impossible to combine bitmap non-one-column indexes?No, you're generalising from the particular - thus are myths created.
I have demonstrated a case where two bitmap indexes start with the same column+, and the optimizer therefore refuses to do a "bitmap and" between these two indexes when you have where clause that uses equality on the common first column and equalities on the seperate second columns. This is a very small subset of query patterns involving combinations of "non-one-column" (multi-column) indexes.
For example - why don't you try recreating your (c1, c3) index as (c3, c1) to see what the optimizer can do ?
In my example it produced the following path:
| Id | Operation                    | Name    | Rows | Bytes | Cost |
|   0 | SELECT STATEMENT             |         |    10 | 1250 |     6 |
|   1 | TABLE ACCESS BY INDEX ROWID | T1      |    10 | 1250 |     6 |
|   2 |   BITMAP CONVERSION TO ROWIDS|         |       |       |       |
|   3 |    BITMAP AND                |         |       |       |       |
|* 4 |     BITMAP INDEX SINGLE VALUE| T1_B1B2 |       |       |       |
|   5 |     BITMAP MERGE             |         |       |       |       |
|* 6 |      BITMAP INDEX RANGE SCAN | T1_B3B1 |       |       |       |
Predicate Information (identified by operation id):
   4 - access("C1"=5 AND "C2"=50)
   6 - access("C3"=50)
       filter("C3"=50)So it is combining two multi column indexes - but it doesn't appear to be able to use the common column twice to make the second index access as efficient as possible. (This plan appeared for 10.2.0.3 and 11.2.0.2).
Regards
Jonathan Lewis

BITMAP CONVERSION TO ROWIDS

Similar Messages

Maybe you are looking for