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
Similar Messages
-
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 -
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,
charlesuser570138 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 -
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. -
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
Gregas 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 -
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 -
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
-Anuraguser635138 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 -
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. -
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) -
[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? -
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 -
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)
ThanksI 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 -
Bad exec plan when joining tables using primary keys together w/ Contains
Hello all...this is something that confuzzles me....
When joining 2 tables, the exec plan shows that the domain index is first accessed, before checking if there is a record in the other table using a highly selective index.
create table users
(userid varchar2(20),
name varchar2(100),
resume clob
create table seeker
(seekerid varchar2(20),
userid varchar2(20),
jobid varchar2(20)
create index user_idx on users(userid)
create index job_resume_index on users(resume)
indextype is ctxsys.context
create unique index seeker_unik on seeker(seekerid)
create index seeker_index on seeker(jobid,userid)
then sample records where inserted, then the text index was sync'ed.
Query and Execution Plan:
select u.userid, u.name
from users u, seeker s
where s.jobid = 'HJOBP000000000218627'
and u.userid = s.userid
and contains(resume,'texas') > 1
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=72)
1 0 NESTED LOOPS (Cost=3 Card=1 Bytes=72)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'USERS' (Cost=2 Card=1
Bytes=30)
3 2 DOMAIN INDEX OF 'JOB_RESUME_INDEX' (Cost=0)
4 1 INDEX (RANGE SCAN) OF 'SEEKER_INDEX' (NON-UNIQUE) (Cost=
1 Card=1 Bytes=42)
The problem with execution plan is if the domain index returns huge number of records i.e. 40k rows, then it has to check each userid with the SEEKER table, and returns only 10 rows. I can add a hint to specify the use of the user_idx instead of the domain index to improve performance.
My question is how does the database determine when to use the domain index or to use other highly selective index with out the aid of a HINT. The trace file shows the use of "CTXSYS"."TEXTOPTSTATS".ODCIStatsIndexCost and "CTXSYS"."TEXTOPTSTATS".ODCIStatsFunctionCost. Are these used to compute and compare the cost of each index and decide on what index to used? If so, why does it return a lower cost for domain index when the btree index is more efficient? I have all statistics gathered for all tables and indexes (inc dr$ tables and its indexes)
Thanks,
jojoHi,
What I'm pasting here is actually from Ch9 of Expert PL/SQL. It shows what happens during a select with CONTAINS. It does not include a join with another table, or an additional column in the where clause. Hope it helps.
================================================
By default, the Extensible Query Optimizer is enabled. When enabled, the Extensible Query Optimizer can determine the I/O and CPU cost associated with the CONTAINS predicate, find the cost of each call to the CONTAINS() function, and determine the selectivity of the CONTAINS predicate.
To see this in action I ran the basic select earlier. Examining the SQL trace shows the steps.
Step 1 - Determine the I/O and CPU cost of the CONTAINS() function:
--Available online as part of contains_trace.doc
"CTXSYS"."TEXTOPTSTATS".ODCIStatsFunctionCost(
sys.ODCIFuncInfo('CTXSYS',
'CTX_CONTAINS',
'TEXTCONTAINS',
2),
cost,
sys.ODCIARGDESCLIST(
sys.ODCIARGDESC(
2, 'DOCUMENT_REPOSITORY', 'PLSQL',
'"DOCUMENT"', NULL, NULL, NULL),
sys.ODCIARGDESC(3, NULL, NULL, NULL, NULL, NULL, NULL)),
NULL,
'constitution',
sys.ODCIENV(0,0,0,1));
Step 2 Determine the selectivity of the CONTAINS predicate
-- Available online as part of contains_trace.doc
"CTXSYS"."TEXTOPTSTATS".ODCIStatsSelectivity(
sys.ODCIPREDINFO('CTXSYS',
'CTX_CONTAINS',
'TEXTCONTAINS',
32),
sel,
sys.ODCIARGDESCLIST(
sys.ODCIARGDESC(3, NULL, NULL, NULL, NULL, NULL, NULL),
sys.ODCIARGDESC(5, NULL, NULL, NULL, NULL, NULL, NULL),
sys.ODCIARGDESC(2, 'DOCUMENT_REPOSITORY', 'PLSQL',
"DOCUMENT"', NULL, NULL, NULL),
sys.ODCIARGDESC(3, NULL, NULL, NULL, NULL, NULL, NULL)),
0,
NULL,
NULL,
'constitution',
sys.ODCIENV(0,0,0,1));
Step 3: Determine the I/O and CPU cost of the CONTAINS predicate
-- Available online as part of contains_trace.doc
"CTXSYS"."TEXTOPTSTATS".ODCIStatsIndexCost(
sys.ODCIINDEXINFO('PLSQL',
'EXPERT_IDX',
sys.ODCICOLINFOLIST(
sys.ODCICOLINFO('PLSQL', 'DOCUMENT_REPOSITORY',
'"DOCUMENT"', 'BFILE', NULL, NULL)),
NULL,
0,
0),
50.00000000,
cost,
sys.ODCIQUERYINFO(
2,
sys.ODCIOBJECTLIST(sys.ODCIOBJECT('SCORE', 'CTXSYS'))),
sys.ODCIPREDINFO('CTXSYS', 'CONTAINS', NULL, 0),
sys.ODCIARGDESCLIST(
sys.ODCIARGDESC(3, NULL, NULL, NULL, NULL, NULL, NULL),
sys.ODCIARGDESC(5, NULL, NULL, NULL, NULL, NULL, NULL),
sys.ODCIARGDESC(2, 'DOCUMENT_REPOSITORY', 'PLSQL',
'"DOCUMENT"', NULL, NULL, NULL),
sys.ODCIARGDESC(3, NULL, NULL, NULL, NULL, NULL, NULL)),
1,
NULL,
'constitution',
sys.ODCIENV(0,0,0,1));
Note: The 50.00000000 in this last call is the selectivity retrieved from step 2.
Only after these three steps complete does the query actually get executed:
-- Available online as part of contains_trace.doc
SELECT score(1), title
FROM document_repository
WHERE CONTAINS(document, 'constitution', 1) > 0
ORDER BY 1 DESC;
This is not the end of the processing though. To retrieve the records, the $I table (the index data table) is queried as follows:
-- Available online as part of contains_trace.doc
SELECT /*+ INDEX(i) */ TOKEN_FIRST,TOKEN_LAST,TOKEN_COUNT,ROWID
FROM "PLSQL"."DR$EXPERT_IDX$I" i
WHERE TOKEN_TEXT = 'CONSTITUTION'
AND TOKEN_TYPE = 0
ORDER BY TOKEN_TEXT, TOKEN_TYPE, TOKEN_FIRST;
Note: The search term is UPPERCASE when querying against the DR$EXPERT_IDX$I table because all of the tokens are stored in uppercase by default. The original SELECT was in lowercase. This automatic conversion to uppercase allows the Text index to provide case-insensitive searching.
This query returns the following result:
TOKEN_FIRST TOKEN_LAST TOKEN_COUNT ROWID
1 2 2 AAAN54AAEAAAOvEAAo
Finally, the $R table (the rowid table) is queried.
-- Available online as part of contains_trace.doc
SELECT data
FROM "PLSQL"."DR$EXPERT_IDX$R"
WHERE row_no = 0;
Only now do I see the results of my query:
SCORE(1) TITLE
55 United States Constitution
8 Bill of Rights
Keep in mind that modifications to the query, such as the addition of other columns in the where clause or the addition of operators, will result in a different trace.
=============================== -
Conversion indicator in planned order
Hi,
I have one query with Conversion indicator in planned order.I maintained procurement type X(Both) in MRP2 for a assy say Y.
Since Y is maintained in header say X.Also Y has its own BOM with active status 1.
I took MRP run for header X, I found that Y has generated planned order without conversion indicator.
Is there any setting missing.
Kindly suggest.
TusharHello Masters,
I checked configuration as well as master data. During MRP run, system is creating planned order but Conversion Indicator in planned order is not checked. I am able to put conversion indicator in planned order and covert that planned order to production order using CO41. I checked BOM dates and status (it is set as 1) as well but could not find reason.
Tushar >> Did you find anything on this, even I am facing same problem.
Any input from all you PP masters will be great help.
Thanks and regards,
Devang -
Conversions in a planning View
Hello everyone,
In the SAP2 scenario there is a "conversion" tab available when designing a planning view (see picture). Could someone tell me how to make this Tab available?
Thanks in advanceThis box will appear after you do the UOM and or currency conversion.
Check the advanced course here that describe how to configure the conversions. (Advanced Modeling)
http://scn.sap.com/docs/DOC-53435
Maybe you are looking for
-
Hi All, I have developed a report. After start-of-selection, i have written a perform statement, in which the data is getting retrieved for printing the same in ALV layout. If there is no data available in the table, the code will raise an error mess
-
I
-
can anyone please help me over how to write submenu code in struts.
-
Zen (Agent) service delayed start
Hi! ZCM 10.3.3 on SLES 11 SP1, Windows XP and 7 ws's. One problem or thing I noticed long time. When device is restarted then even ZCC show ws in green and agent service is started on on ws it seems to that Agent Service start is not in effect ... de
-
Forgot to switch to Point Banking after Elite, made a purchase; too late?
I know that it's never too late to switch to Point Banking, but I was wondering if there's any way to bank points from a certificate that was earned after achieving Elite status. What happened was that I lost Elite status at the beginning of this yea