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.
Similar Messages
-
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 -
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 -
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 -
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 -
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 -
Explain plan result for a long-running query used in data-warehousing. Tuni
I have executed an explain plan for a query that is used in a data-warehousing application.
This sql is taking too long to execute as it is visiting 24 partitions.
Where each partition contains data for 1 month month, so it fetches last 2 year data.
And each partition has a million or so rows.
All this is kept in table prescrip_retail. So this table has 24 partitions.
abc@def>explain plan set statement_id='dwh_query'
2 for
3 SELECT r.pier_account_id,
4 p.presc_num,
5 spm.product_id,
6 p.month,
7 t.best_call_state,
8 sum(p.trx_count)
9 FROM rlup_assigned_account r,
10 temp_presc_num_TEST t,
11 retail.prescrip_retail p,
12 sherlock.sherlock_product_mapping spm
13 WHERE spm.product_id like '056%'
14 and t.CLIENT_ID='934759'
15 and p.month >= add_months(sysdate,-24)
16 and spm.mds6 = p.product_id
17 and t.CLIENT_ID = p.presc_num
18 and r.ndc_pyr_id = p.payer_plan
19 and t.best_call_state = r.ST
20 GROUP BY r.pier_account_id,
21 p.presc_num,
22 spm.product_id,
23 p.month,
24 t.best_call_state;
Explained.
abc@def>ed
Wrote file afiedt.buf
1 select operation,options,optimizer,cost,cardinality,partition_start,partition_stop
2 from plan_table
3* where statement_id='dwh_query'
abc@def>/
OPERATION OPTIONS OPTIMIZER COST CARDINALITY
PARTITION_START
PARTITION_STOP
SELECT STATEMENT CHOOSE 850 1
SORT GROUP BY 850 1
NESTED LOOPS 848 1
HASH JOIN 845 3
HASH JOIN 842 6
TABLE ACCESS FULL ANALYZED 1 6
PARTITION RANGE ITERATOR
KEY
36
TABLE ACCESS BY LOCAL INDEX ROWID ANALYZED 839 166
KEY
36
BITMAP CONVERSION TO ROWIDS
BITMAP INDEX SINGLE VALUE
KEY
36
TABLE ACCESS FULL 2 50
TABLE ACCESS BY INDEX ROWID ANALYZED 1 149501
INDEX UNIQUE SCAN ANALYZED 149501
13 rows selected.Here is the create statement for PRESCRIP_RETAIL table:
I have observed 2 things:
1. In the query the following joins are present.
13 WHERE spm.product_id like '056%'
14 and t.CLIENT_ID='934759'
15 and p.month >= add_months(sysdate,-24)
16 and spm.mds6 = p.product_id
17 and t.CLIENT_ID = p.presc_num
18 and r.ndc_pyr_id = p.payer_plan
19 and t.best_call_state = r.ST
Index exist for p.product_id,p.presc_num,p.payer_plan as you can see below.
However, the index does not exist for month.
I am also doing search for month.
I feel if I create a "partitioned index" on month, query performance should improve.
Q Can you provide me the syntax for creating a partitioned index on month?
2.The following tables are used in the query:
9 FROM rlup_assigned_account r,
10 temp_presc_num_TEST t,
11 retail.prescrip_retail p,
12 sherlock.sherlock_product_mapping spm
In these tables, apart from sherlock.sherlock_product_mapping table the statistics that exist is old.
I need to analyse on table level as well as column level.
For example:
Table prescrip_retail is analyzed in 2002,
table temp_presc_num_TEST is not analysed at all.
table rlup_assigned_account is analysed in Feb 2007.
sherlock_product_mapping is the only table that has updated statistics, analysed on Oct. 2007
Here is the table creation statement of PRESCRIP_RETAIL and index on it.
Prompt Table PRESCRIP_RETAIL;
-- PRESCRIP_RETAIL (Table)
-- Row count:2806673860
CREATE TABLE RETAIL.PRESCRIP_RETAIL
PRESC_NUM NUMBER,
PIER_NUM CHAR(8),
RELID CHAR(9) NOT NULL,
ME_NUM CHAR(10) NOT NULL,
PRODUCT_ID CHAR(6) NOT NULL,
PRODUCT_FRMSTR CHAR(1) NOT NULL,
PAYER_PLAN CHAR(6) NOT NULL,
MONTH DATE NOT NULL,
PYMT_CODE CHAR(1) NOT NULL,
NRX_COUNT NUMBER(7) NOT NULL,
NRX_QUANTITY NUMBER(9) NOT NULL,
NRX_DOLLARS NUMBER(13,2) NOT NULL,
TRX_COUNT NUMBER(7) NOT NULL,
TRX_QUANTITY NUMBER(9) NOT NULL,
TRX_DOLLARS NUMBER(13,2) NOT NULL
TABLESPACE PRESC_PARTITION_29
NOLOGGING
PARTITION BY RANGE (MONTH)
PARTITION PRESC200406 VALUES LESS THAN (TO_DATE(' 2004-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_30,
PARTITION PRESC200407 VALUES LESS THAN (TO_DATE(' 2004-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_31,
PARTITION PRESC200408 VALUES LESS THAN (TO_DATE(' 2004-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_32,
PARTITION PRESC200409 VALUES LESS THAN (TO_DATE(' 2004-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_33,
PARTITION PRESC200410 VALUES LESS THAN (TO_DATE(' 2004-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_34,
PARTITION PRESC200411 VALUES LESS THAN (TO_DATE(' 2004-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_35,
PARTITION PRESC200412 VALUES LESS THAN (TO_DATE(' 2005-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_36,
PARTITION PRESC200501 VALUES LESS THAN (TO_DATE(' 2005-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_01,
PARTITION PRESC200502 VALUES LESS THAN (TO_DATE(' 2005-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_02,
PARTITION PRESC200503 VALUES LESS THAN (TO_DATE(' 2005-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_03,
PARTITION PRESC200504 VALUES LESS THAN (TO_DATE(' 2005-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_04,
PARTITION PRESC200505 VALUES LESS THAN (TO_DATE(' 2005-06-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_05,
PARTITION PRESC200506 VALUES LESS THAN (TO_DATE(' 2005-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_06,
PARTITION PRESC200507 VALUES LESS THAN (TO_DATE(' 2005-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_07,
PARTITION PRESC200508 VALUES LESS THAN (TO_DATE(' 2005-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_08,
PARTITION PRESC200509 VALUES LESS THAN (TO_DATE(' 2005-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_09,
PARTITION PRESC200510 VALUES LESS THAN (TO_DATE(' 2005-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_10,
PARTITION PRESC200511 VALUES LESS THAN (TO_DATE(' 2005-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_11,
PARTITION PRESC200512 VALUES LESS THAN (TO_DATE(' 2006-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_12,
PARTITION PRESC200601 VALUES LESS THAN (TO_DATE(' 2006-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_13,
PARTITION PRESC200602 VALUES LESS THAN (TO_DATE(' 2006-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_14,
PARTITION PRESC200603 VALUES LESS THAN (TO_DATE(' 2006-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_15,
PARTITION PRESC200604 VALUES LESS THAN (TO_DATE(' 2006-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_16,
PARTITION PRESC200605 VALUES LESS THAN (TO_DATE(' 2006-06-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_17,
PARTITION PRESC200606 VALUES LESS THAN (TO_DATE(' 2006-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_18,
PARTITION PRESC200607 VALUES LESS THAN (TO_DATE(' 2006-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_19,
PARTITION PRESC200608 VALUES LESS THAN (TO_DATE(' 2006-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_20,
PARTITION PRESC200609 VALUES LESS THAN (TO_DATE(' 2006-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_21,
PARTITION PRESC200610 VALUES LESS THAN (TO_DATE(' 2006-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_22,
PARTITION PRESC200611 VALUES LESS THAN (TO_DATE(' 2006-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_23,
PARTITION PRESC200612 VALUES LESS THAN (TO_DATE(' 2007-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_24,
PARTITION PRESC200701 VALUES LESS THAN (TO_DATE(' 2007-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_25,
PARTITION PRESC200702 VALUES LESS THAN (TO_DATE(' 2007-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_26,
PARTITION PRESC200703 VALUES LESS THAN (TO_DATE(' 2007-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_27,
PARTITION PRESC200704 VALUES LESS THAN (TO_DATE(' 2007-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_28,
PARTITION PRESC200705 VALUES LESS THAN (TO_DATE(' 2007-06-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_29
NOCACHE
NOPARALLEL;
Prompt Index BX2_PRESC_PAYER;
-- BX2_PRESC_PAYER (Index)
-- Dependencies:
-- PRESCRIP_RETAIL (Table)
CREATE BITMAP INDEX RETAIL.BX2_PRESC_PAYER ON RETAIL.PRESCRIP_RETAIL
(PAYER_PLAN)
TABLESPACE PRESC_PARTITION_29
LOGGING
LOCAL (
PARTITION PRESC200406
NOLOGGING
TABLESPACE PRESC_PARTITION_30,
PARTITION PRESC200407
NOLOGGING
TABLESPACE PRESC_PARTITION_31,
PARTITION PRESC200408
NOLOGGING
TABLESPACE PRESC_PARTITION_32,
PARTITION PRESC200409
NOLOGGING
TABLESPACE PRESC_PARTITION_33,
PARTITION PRESC200410
NOLOGGING
TABLESPACE PRESC_PARTITION_34,
PARTITION PRESC200411
NOLOGGING
TABLESPACE PRESC_PARTITION_35,
PARTITION PRESC200412
NOLOGGING
TABLESPACE PRESC_PARTITION_36,
PARTITION PRESC200501
NOLOGGING
TABLESPACE PRESC_PARTITION_01,
PARTITION PRESC200502
NOLOGGING
TABLESPACE PRESC_PARTITION_02,
PARTITION PRESC200503
NOLOGGING
TABLESPACE PRESC_PARTITION_03,
PARTITION PRESC200504
NOLOGGING
TABLESPACE PRESC_PARTITION_04,
PARTITION PRESC200505
NOLOGGING
TABLESPACE PRESC_PARTITION_05,
PARTITION PRESC200506
NOLOGGING
TABLESPACE PRESC_PARTITION_06,
PARTITION PRESC200507
NOLOGGING
TABLESPACE PRESC_PARTITION_07,
PARTITION PRESC200508
NOLOGGING
TABLESPACE PRESC_PARTITION_08,
PARTITION PRESC200509
NOLOGGING
TABLESPACE PRESC_PARTITION_09,
PARTITION PRESC200510
NOLOGGING
TABLESPACE PRESC_PARTITION_10,
PARTITION PRESC200511
NOLOGGING
TABLESPACE PRESC_PARTITION_11,
PARTITION PRESC200512
NOLOGGING
TABLESPACE PRESC_PARTITION_12,
PARTITION PRESC200601
NOLOGGING
TABLESPACE PRESC_PARTITION_13,
PARTITION PRESC200602
NOLOGGING
TABLESPACE PRESC_PARTITION_14,
PARTITION PRESC200603
NOLOGGING
TABLESPACE PRESC_PARTITION_15,
PARTITION PRESC200604
NOLOGGING
TABLESPACE PRESC_PARTITION_16,
PARTITION PRESC200605
NOLOGGING
TABLESPACE PRESC_PARTITION_17,
PARTITION PRESC200606
NOLOGGING
TABLESPACE PRESC_PARTITION_18,
PARTITION PRESC200607
NOLOGGING
TABLESPACE PRESC_PARTITION_19,
PARTITION PRESC200608
NOLOGGING
TABLESPACE PRESC_PARTITION_20,
PARTITION PRESC200609
NOLOGGING
TABLESPACE PRESC_PARTITION_21,
PARTITION PRESC200610
NOLOGGING
TABLESPACE PRESC_PARTITION_22,
PARTITION PRESC200611
NOLOGGING
TABLESPACE PRESC_PARTITION_23,
PARTITION PRESC200612
NOLOGGING
TABLESPACE PRESC_PARTITION_24,
PARTITION PRESC200701
NOLOGGING
TABLESPACE PRESC_PARTITION_25,
PARTITION PRESC200702
NOLOGGING
TABLESPACE PRESC_PARTITION_26,
PARTITION PRESC200703
NOLOGGING
TABLESPACE PRESC_PARTITION_27,
PARTITION PRESC200704
NOLOGGING
TABLESPACE PRESC_PARTITION_28,
PARTITION PRESC200705
NOLOGGING
TABLESPACE PRESC_PARTITION_29
NOPARALLEL;
Prompt Index BX3_PRESC_PAYERCD;
-- BX3_PRESC_PAYERCD (Index)
-- Dependencies:
-- PRESCRIP_RETAIL (Table)
CREATE BITMAP INDEX RETAIL.BX3_PRESC_PAYERCD ON RETAIL.PRESCRIP_RETAIL
(PYMT_CODE)
TABLESPACE PRESC_PARTITION_29
NOLOGGING
LOCAL (
PARTITION PRESC200406
NOLOGGING
TABLESPACE PRESC_PARTITION_30,
PARTITION PRESC200407
NOLOGGING
TABLESPACE PRESC_PARTITION_31,
PARTITION PRESC200408
NOLOGGING
TABLESPACE PRESC_PARTITION_32,
PARTITION PRESC200409
NOLOGGING
TABLESPACE PRESC_PARTITION_33,
PARTITION PRESC200410
NOLOGGING
TABLESPACE PRESC_PARTITION_34,
PARTITION PRESC200411
NOLOGGING
TABLESPACE PRESC_PARTITION_35,
PARTITION PRESC200412
NOLOGGING
TABLESPACE PRESC_PARTITION_36,
PARTITION PRESC200501
NOLOGGING
TABLESPACE PRESC_PARTITION_01,
PARTITION PRESC200502
NOLOGGING
TABLESPACE PRESC_PARTITION_02,
PARTITION PRESC200503
NOLOGGING
TABLESPACE PRESC_PARTITION_03,
PARTITION PRESC200504
NOLOGGING
TABLESPACE PRESC_PARTITION_04,
PARTITION PRESC200505
NOLOGGING
TABLESPACE PRESC_PARTITION_05,
PARTITION PRESC200506
NOLOGGING
TABLESPACE PRESC_PARTITION_06,
PARTITION PRESC200507
NOLOGGING
TABLESPACE PRESC_PARTITION_07,
PARTITION PRESC200508
NOLOGGING
TABLESPACE PRESC_PARTITION_08,
PARTITION PRESC200509
NOLOGGING
TABLESPACE PRESC_PARTITION_09,
PARTITION PRESC200510
NOLOGGING
TABLESPACE PRESC_PARTITION_10,
PARTITION PRESC200511
NOLOGGING
TABLESPACE PRESC_PARTITION_11,
PARTITION PRESC200512
NOLOGGING
TABLESPACE PRESC_PARTITION_12,
PARTITION PRESC200601
NOLOGGING
TABLESPACE PRESC_PARTITION_13,
PARTITION PRESC200602
NOLOGGING
TABLESPACE PRESC_PARTITION_14,
PARTITION PRESC200603
NOLOGGING
TABLESPACE PRESC_PARTITION_15,
PARTITION PRESC200604
NOLOGGING
TABLESPACE PRESC_PARTITION_16,
PARTITION PRESC200605
NOLOGGING
TABLESPACE PRESC_PARTITION_17,
PARTITION PRESC200606
NOLOGGING
TABLESPACE PRESC_PARTITION_18,
PARTITION PRESC200607
NOLOGGING
TABLESPACE PRESC_PARTITION_19,
PARTITION PRESC200608
NOLOGGING
TABLESPACE PRESC_PARTITION_20,
PARTITION PRESC200609
NOLOGGING
TABLESPACE PRESC_PARTITION_21,
PARTITION PRESC200610
NOLOGGING
TABLESPACE PRESC_PARTITION_22,
PARTITION PRESC200611
NOLOGGING
TABLESPACE PRESC_PARTITION_23,
PARTITION PRESC200612
NOLOGGING
TABLESPACE PRESC_PARTITION_24,
PARTITION PRESC200701
NOLOGGING
TABLESPACE PRESC_PARTITION_25,
PARTITION PRESC200702
NOLOGGING
TABLESPACE PRESC_PARTITION_26,
PARTITION PRESC200703
NOLOGGING
TABLESPACE PRESC_PARTITION_27,
PARTITION PRESC200704
NOLOGGING
TABLESPACE PRESC_PARTITION_28,
PARTITION PRESC200705
NOLOGGING
TABLESPACE PRESC_PARTITION_29
NOPARALLEL;
Prompt Index BX4_PRESC_PRESC;
-- BX4_PRESC_PRESC (Index)
-- Dependencies:
-- PRESCRIP_RETAIL (Table)
CREATE BITMAP INDEX RETAIL.BX4_PRESC_PRESC ON RETAIL.PRESCRIP_RETAIL
(PRESC_NUM)
TABLESPACE PRESC_PARTITION_29
NOLOGGING
LOCAL (
PARTITION PRESC200406
NOLOGGING
TABLESPACE PRESC_PARTITION_30,
PARTITION PRESC200407
NOLOGGING
TABLESPACE PRESC_PARTITION_31,
PARTITION PRESC200408
NOLOGGING
TABLESPACE PRESC_PARTITION_32,
PARTITION PRESC200409
NOLOGGING
TABLESPACE PRESC_PARTITION_33,
PARTITION PRESC200410
NOLOGGING
TABLESPACE PRESC_PARTITION_34,
PARTITION PRESC200411
NOLOGGING
TABLESPACE PRESC_PARTITION_35,
PARTITION PRESC200412
NOLOGGING
TABLESPACE PRESC_PARTITION_36,
PARTITION PRESC200501
NOLOGGING
TABLESPACE PRESC_PARTITION_01,
PARTITION PRESC200502
NOLOGGING
TABLESPACE PRESC_PARTITION_02,
PARTITION PRESC200503
NOLOGGING
TABLESPACE PRESC_PARTITION_03,
PARTITION PRESC200504
NOLOGGING
TABLESPACE PRESC_PARTITION_04,
PARTITION PRESC200505
NOLOGGING
TABLESPACE PRESC_PARTITION_05,
PARTITION PRESC200506
NOLOGGING
TABLESPACE PRESC_PARTITION_06,
PARTITION PRESC200507
NOLOGGING
TABLESPACE PRESC_PARTITION_07,
PARTITION PRESC200508
NOLOGGING
TABLESPACE PRESC_PARTITION_08,
PARTITION PRESC200509
NOLOGGING
TABLESPACE PRESC_PARTITION_09,
PARTITION PRESC200510
NOLOGGING
TABLESPACE PRESC_PARTITION_10,
PARTITION PRESC200511
NOLOGGING
TABLESPACE PRESC_PARTITION_11,
PARTITION PRESC200512
NOLOGGING
TABLESPACE PRESC_PARTITION_12,
PARTITION PRESC200601
NOLOGGING
TABLESPACE PRESC_PARTITION_13,
PARTITION PRESC200602
NOLOGGING
TABLESPACE PRESC_PARTITION_14,
PARTITION PRESC200603
NOLOGGING
TABLESPACE PRESC_PARTITION_15,
PARTITION PRESC200604
NOLOGGING
TABLESPACE PRESC_PARTITION_16,
PARTITION PRESC200605
NOLOGGING
TABLESPACE PRESC_PARTITION_17,
PARTITION PRESC200606
NOLOGGING
TABLESPACE PRESC_PARTITION_18,
PARTITION PRESC200607
NOLOGGING
TABLESPACE PRESC_PARTITION_19,
PARTITION PRESC200608
NOLOGGING
TABLESPACE PRESC_PARTITION_20,
PARTITION PRESC200609
NOLOGGING
TABLESPACE PRESC_PARTITION_21,
PARTITION PRESC200610
NOLOGGING
TABLESPACE PRESC_PARTITION_22,
PARTITION PRESC200611
NOLOGGING
TABLESPACE PRESC_PARTITION_23,
PARTITION PRESC200612
NOLOGGING
TABLESPACE PRESC_PARTITION_24,
PARTITION PRESC200701
NOLOGGING
TABLESPACE PRESC_PARTITION_25,
PARTITION PRESC200702
NOLOGGING
TABLESPACE PRESC_PARTITION_26,
PARTITION PRESC200703
NOLOGGING
TABLESPACE PRESC_PARTITION_27,
PARTITION PRESC200704
NOLOGGING
TABLESPACE PRESC_PARTITION_28,
PARTITION PRESC200705
NOLOGGING
TABLESPACE PRESC_PARTITION_29
NOPARALLEL;
Prompt Index BX5_PRESC_PIER;
-- BX5_PRESC_PIER (Index)
-- Dependencies:
-- PRESCRIP_RETAIL (Table)
CREATE BITMAP INDEX RETAIL.BX5_PRESC_PIER ON RETAIL.PRESCRIP_RETAIL
(PIZR_NUM)
TABLESPACE PRESC_PARTITION_29
LOGGING
LOCAL (
PARTITION PRESC200406
NOLOGGING
TABLESPACE PRESC_PARTITION_30,
PARTITION PRESC200407
NOLOGGING
TABLESPACE PRESC_PARTITION_31,
PARTITION PRESC200408
NOLOGGING
TABLESPACE PRESC_PARTITION_32,
PARTITION PRESC200409
NOLOGGING
TABLESPACE PRESC_PARTITION_33,
PARTITION PRESC200410
NOLOGGING
TABLESPACE PRESC_PARTITION_34,
PARTITION PRESC200411
NOLOGGING
TABLESPACE PRESC_PARTITION_35,
PARTITION PRESC200412
NOLOGGING
TABLESPACE PRESC_PARTITION_36,
PARTITION PRESC200501
NOLOGGING
TABLESPACE PRESC_PARTITION_01,
PARTITION PRESC200502
NOLOGGING
TABLESPACE PRESC_PARTITION_02,
PARTITION PRESC200503
NOLOGGING
TABLESPACE PRESC_PARTITION_03,
PARTITION PRESC200504
NOLOGGING
TABLESPACE PRESC_PARTITION_04,
PARTITION PRESC200505
NOLOGGING
TABLESPACE PRESC_PARTITION_05,
PARTITION PRESC200506
NOLOGGING
TABLESPACE PRESC_PARTITION_06,
PARTITION PRESC200507
NOLOGGING
TABLESPACE PRESC_PARTITION_07,
PARTITION PRESC200508
NOLOGGING
TABLESPACE PRESC_PARTITION_08,
PARTITION PRESC200509
NOLOGGING
TABLESPACE PRESC_PARTITION_09,
PARTITION PRESC200510
NOLOGGING
TABLESPACE PRESC_PARTITION_10,
PARTITION PRESC200511
NOLOGGING
TABLESPACE PRESC_PARTITION_11,
PARTITION PRESC200512
NOLOGGING
TABLESPACE PRESC_PARTITION_12,
PARTITION PRESC200601
NOLOGGING
TABLESPACE PRESC_PARTITION_13,
PARTITION PRESC200602
NOLOGGING
TABLESPACE PRESC_PARTITION_14,
PARTITION PRESC200603
NOLOGGING
TABLESPACE PRESC_PARTITION_15,
PARTITION PRESC200604
NOLOGGING
TABLESPACE PRESC_PARTITION_16,
PARTITION PRESC200605
NOLOGGING
TABLESPACE PRESC_PARTITION_17,
PARTITION PRESC200606
NOLOGGING
TABLESPACE PRESC_PARTITION_18,
PARTITION PRESC200607
NOLOGGING
TABLESPACE PRESC_PARTITION_19,
PARTITION PRESC200608
NOLOGGING
TABLESPACE PRESC_PARTITION_20,
PARTITION PRESC200609
NOLOGGING
TABLESPACE PRESC_PARTITION_21,
PARTITION PRESC200610
NOLOGGING
TABLESPACE PRESC_PARTITION_22,
PARTITION PRESC200611
NOLOGGING
TABLESPACE PRESC_PARTITION_23,
PARTITION PRESC200612
NOLOGGING
TABLESPACE PRESC_PARTITION_24,
PARTITION PRESC200701
NOLOGGING
TABLESPACE PRESC_PARTITION_25,
PARTITION PRESC200702
NOLOGGING
TABLESPACE PRESC_PARTITION_26,
PARTITION PRESC200703
NOLOGGING
TABLESPACE PRESC_PARTITION_27,
PARTITION PRESC200704
NOLOGGING
TABLESPACE PRESC_PARTITION_28,
PARTITION PRESC200705
NOLOGGING
TABLESPACE PRESC_PARTITION_29
NOPARALLEL;
Prompt Index BX6_PRESC_RELID;
-- BX6_PRESC_RELID (Index)
-- Dependencies:
-- PRESCRIP_RETAIL (Table)
CREATE BITMAP INDEX RETAIL.BX6_PRESC_RELID ON RETAIL.PRESCRIP_RETAIL
(RELID)
TABLESPACE PRESC_PARTITION_29
LOGGING
LOCAL (
PARTITION PRESC200406
NOLOGGING
TABLESPACE PRESC_PARTITION_30,
PARTITION PRESC200407
NOLOGGING
TABLESPACE PRESC_PARTITION_31,
PARTITION PRESC200408
NOLOGGING
TABLESPACE PRESC_PARTITION_32,
PARTITION PRESC200409
NOLOGGING
TABLESPACE PRESC_PARTITION_33,
PARTITION PRESC200410
NOLOGGING
TABLESPACE PRESC_PARTITION_34,
PARTITION PRESC200411
NOLOGGING
TABLESPACE PRESC_PARTITION_35,
PARTITION PRESC200412
NOLOGGING
TABLESPACE PRESC_PARTITION_36,
PARTITION PRESC200501
NOLOGGING
TABLESPACE PRESC_PARTITION_01,
PARTITION PRESC200502
NOLOGGING
TABLESPACE PRESC_PARTITION_02,
PARTITION PRESC200503
NOLOGGING
TABLESPACE PRESC_PARTITION_03,
PARTITION PRESC200504
NOLOGGING
TABLESPACE PRESC_PARTITION_04,
PARTITION PRESC200505
NOLOGGING
TABLESPACE PRESC_PARTITION_05,
PARTITION PRESC200506
NOLOGGING
TABLESPACE PRESC_PARTITION_06,
PARTITION PRESC200507
NOLOGGING
TABLESPACE PRESC_PARTITION_07,
PARTITION PRESC200508
NOLOGGING
TABLESPACE PRESC_PARTITION_08,
PARTITION PRESC200509
NOLOGGING
TABLESPACE PRESC_PARTITION_09,
PARTITION PRESC200510
NOLOGGING
TABLESPACE PRESC_PARTITION_10,
PARTITION PRESC200511
NOLOGGING
TABLESPACE PRESC_PARTITION_11,
PARTITION PRESC200512
NOLOGGING
TABLESPACE PRESC_PARTITION_12,
PARTITION PRESC200601
NOLOGGING
TABLESPACE PRESC_PARTITION_13,
PARTITION PRESC200602
NOLOGGING
TABLESPACE PRESC_PARTITION_14,
PARTITION PRESC200603
NOLOGGING
TABLESPACE PRESC_PARTITION_15,
PARTITION PRESC200604
NOLOGGING
TABLESPACE PRESC_PARTITION_16,
PARTITION PRESC200605
NOLOGGING
TABLESPACE PRESC_PARTITION_17,
PARTITION PRESC200606
NOLOGGING
TABLESPACE PRESC_PARTITION_18,
PARTITION PRESC200607
NOLOGGING
TABLESPACE PRESC_PARTITION_19,
PARTITION PRESC200608
NOLOGGING
TABLESPACE PRESC_PARTITION_20,
PARTITION PRESC200609
NOLOGGING
TABLESPACE PRESC_PARTITION_21,
PARTITION PRESC200610
NOLOGGING
TABLESPACE PRESC_PARTITION_22,
PARTITION PRESC200611
NOLOGGING
TABLESPACE PRESC_PARTITION_23,
PARTITION PRESC200612
NOLOGGING
TABLESPACE PRESC_PARTITION_24,
PARTITION PRESC200701
NOLOGGING
TABLESPACE PRESC_PARTITION_25,
PARTITION PRESC200702
NOLOGGING
TABLESPACE PRESC_PARTITION_26,
PARTITION PRESC200703
NOLOGGING
TABLESPACE PRESC_PARTITION_27,
PARTITION PRESC200704
NOLOGGING
TABLESPACE PRESC_PARTITION_28,
PARTITION PRESC200705
NOLOGGING
TABLESPACE PRESC_PARTITION_29
NOPARALLEL;
Prompt Index BX7_PRESC_ME;
-- BX7_PRESC_ME (Index)
-- Dependencies:
-- PRESCRIP_RETAIL (Table)
CREATE BITMAP INDEX RETAIL.BX7_PRESC_ME ON RETAIL.PRESCRIP_RETAIL
(ME_NUM)
TABLESPACE PRESC_PARTITION_29
LOGGING
LOCAL (
PARTITION PRESC200406
NOLOGGING
TABLESPACE PRESC_PARTITION_30,
PARTITION PRESC200407
NOLOGGING
TABLESPACE PRESC_PARTITION_31,
PARTITION PRESC200408
NOLOGGING
TABLESPACE PRESC_PARTITION_32,
PARTITION PRESC200409
NOLOGGING
TABLESPACE PRESC_PARTITION_33,
PARTITION PRESC200410
NOLOGGING
TABLESPACE PRESC_PARTITION_34,
PARTITION PRESC200411
NOLOGGING
TABLESPACE PRESC_PARTITION_35,
PARTITION PRESC200412
NOLOGGING
TABLESPACE PRESC_PARTITION_36,
PARTITION PRESC200501
NOLOGGING
TABLESPACE PRESC_PARTITION_01,
PARTITION PRESC200502
NOLOGGING
TABLESPACE PRESC_PARTITION_02,
PARTITION PRESC200503
NOLOGGING
TABLESPACE PRESC_PARTITION_03,
PARTITION PRESC200504
NOLOGGING
TABLESPACE PRESC_PARTITION_04,
PARTITION PRESC200505
NOLOGGING
TABLESPACE PRESC_PARTITION_05,
PARTITION PRESC200506
NOLOGGING
TABLESPACE PRESC_PARTITION_06,
PARTITION PRESC200507
NOLOGGING
TABLESPACE PRESC_PARTITION_07,
PARTITION PRESC200508
NOLOGGING
TABLESPACE PRESC_PARTITION_08,
PARTITION PRESC200509
NOLOGGING
TABLESPACE PRESC_PARTITION_09,
PARTITION PRESC200510
NOLOGGING
TABLESPACE PRESC_PARTITION_10,
PARTITION PRESC200511
NOLOGGING
TABLESPACE PRESC_PARTITION_11,
PARTITION PRESC200512
NOLOGGING
TABLESPACE PRESC_PARTITION_12,
PARTITION PRESC200601
NOLOGGING
TABLESPACE PRESC_PARTITION_13,
PARTITION PRESC200602
NOLOGGING
TABLESPACE PRESC_PARTITION_14,
PARTITION PRESC200603
NOLOGGING
TABLESPACE PRESC_PARTITION_15,
PARTITION PRESC200604
NOLOGGING
TABLESPACE PRESC_PARTITION_16,
PARTITION PRESC200605
NOLOGGING
TABLESPACE PRESC_PARTITION_17,
PARTITION PRESC200606
NOLOGGING
TABLESPACE PRESC_PARTITION_18,
PARTITION PRESC200607
NOLOGGING
TABLESPACE PRESC_PARTITION_19,
PARTITION PRESC200608
NOLOGGING
TABLESPACE PRESC_PARTITION_20,
PARTITION PRESC200609
NOLOGGING
TABLESPACE PRESC_PARTITION_21,
PARTITION PRESC200610
NOLOGGING
TABLESPACE PRESC_PARTITION_22,
PARTITION PRESC200611
NOLOGGING
TABLESPACE PRESC_PARTITION_23,
PARTITION PRESC200612
NOLOGGING
TABLESPACE PRESC_PARTITION_24,
PARTITION PRESC200701
NOLOGGING
TABLESPACE PRESC_PARTITION_25,
PARTITION PRESC200702
NOLOGGING
TABLESPACE PRESC_PARTITION_26,
PARTITION PRESC200703
NOLOGGING
TABLESPACE PRESC_PARTITION_27,
PARTITION PRESC200704
NOLOGGING
TABLESPACE PRESC_PARTITION_28,
PARTITION PRESC200705
NOLOGGING
TABLESPACE PRESC_PARTITION_29
NOPARALLEL;
Prompt Index BX1_PRESC_PROD;
-- BX1_PRESC_PROD (Index)
-- Dependencies:
-- PRESCRIP_RETAIL (Table)
CREATE BITMAP INDEX RETAIL.BX1_PRESC_PROD ON RETAIL.PRESCRIP_RETAIL
(PRODUCT_ID, PRODUCT_FRMSTR)
TABLESPACE PRESC_PARTITION_29
LOGGING
LOCAL (
PARTITION PRESC200406
NOLOGGING
TABLESPACE PRESC_PARTITION_30,
PARTITION PRESC200407
NOLOGGING
TABLESPACE PRESC_PARTITION_31,
PARTITION PRESC200408
NOLOGGING
TABLESPACE PRESC_PARTITION_32,
PARTITION PRESC200409
NOLOGGING
TABLESPACE PRESC_PARTITION_33,
PARTITION PRESC200410
NOLOGGING
TABLESPACE PRESC_PARTITION_34,
PARTITION PRESC200411
NOLOGGING
TABLESPACE PRESC_PARTITION_35,
PARTITION PRESC200412
NOLOGGING
TABLESPACE PRESC_PARTITION_36,
PARTITION PRESC200501
NOLOGGING
TABLESPACE PRESC_PARTITION_01,
PARTITION PRESC200502
NOLOGGING
TABLESPACE PRESC_PARTITION_02,
PARTITION PRESC200503
NOLOGGING
TABLESPACE PRESC_PARTITION_03,
PARTITION PRESC200504
NOLOGGING
TABLESPACE PRESC_PARTITION_04,
PARTITION PRESC200505
NOLOGGING
TABLESPACE PRESC_PARTITION_05,
PARTITION PRESC200506
NOLOGGING
TABLESPACE PRESC_PARTITION_06,
PARTITION PRESC200507
NOLOGGING
TABLESPACE PRESC_PARTITION_07,
PARTITION PRESC200508
NOLOGGING
TABLESPACE PRESC_PARTITION_08,
PARTITION PRESC200509
NOLOGGING
TABLESPACE PRESC_PARTITION_09,
PARTITION PRESC200510
NOLOGGING
TABLESPACE PRESC_PARTITION_10,
PARTITION PRESC200511
NOLOGGING
TABLESPACE PRESC_PARTITION_11,
PARTITION PRESC200512
NOLOGGING
TABLESPACE PRESC_PARTITION_12,
PARTITION PRESC200601
NOLOGGING
TABLESPACE PRESC_PARTITION_13,
PARTITION PRESC200602
NOLOGGING
TABLESPACE PRESC_PARTITION_14,
PARTITION PRESC200603
NOLOGGING
TABLESPACE PRESC_PARTITION_15,
PARTITION PRESC200604
NOLOGGING
TABLESPACE PRESC_PARTITION_16,
PARTITION PRESC200605
NOLOGGING
TABLESPACE PRESC_PARTITION_17,
PARTITION PRESC200606
NOLOGGING
TABLESPACE PRESC_PARTITION_18,
PARTITION PRESC200607
NOLOGGING
TABLESPACE PRESC_PARTITION_19,
PARTITION PRESC200608
NOLOGGING
TABLESPACE PRESC_PARTITION_20,
PARTITION PRESC200609
NOLOGGING
TABLESPACE PRESC_PARTITION_21,
PARTITION PRESC200610
NOLOGGING
TABLESPACE PRESC_PARTITION_22,
PARTITION PRESC200611
NOLOGGING
TABLESPACE PRESC_PARTITION_23,
PARTITION PRESC200612
NOLOGGING
TABLESPACE PRESC_PARTITION_24,
PARTITION PRESC200701
NOLOGGING
TABLESPACE PRESC_PARTITION_25,
PARTITION PRESC200702
NOLOGGING
TABLESPACE PRESC_PARTITION_26,
PARTITION PRESC200703
NOLOGGING
TABLESPACE PRESC_PARTITION_27,
PARTITION PRESC200704
NOLOGGING
TABLESPACE PRESC_PARTITION_28,
PARTITION PRESC200705
NOLOGGING
TABLESPACE PRESC_PARTITION_29
NOPARALLEL; -
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. -
Analyze Explain Plan --Query Stuck
Hello,
I am a newbie to Oracle.Urgently need help on a query running on Production Oracle 11g database.
This query is getting stuck for a very long time while fetching data.Here is the explain Plan for it.Could anyone please point out what is the problem and what needs to be corrected.Thanks in advance.
Rollback complete.
Explain complete.
Commit complete.
PLAN_TABLE_OUTPUT
Plan hash value: 3980578161
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 155 | 33325 | 716 (1)| 00:00:11 | | |
| 1 | SORT ORDER BY | | 155 | 33325 | 716 (1)| 00:00:11 | | |
|* 2 | VIEW | | 155 | 33325 | 715 (1)| 00:00:11 | | |
|* 3 | WINDOW SORT PUSHED RANK | | 155 | 61535 | 715 (1)| 00:00:11 | | |
|* 4 | VIEW | | 155 | 61535 | 714 (1)| 00:00:10 | | |
| 5 | WINDOW BUFFER | | 155 | 34565 | 714 (1)| 00:00:10 | | |
| 6 | SORT GROUP BY | | 155 | 34565 | 714 (1)| 00:00:10 | | |
| 7 | TABLE ACCESS BY INDEX ROWID | BTM_EIN | 1 | 19 | 2 (0)| 00:00:01 | | |
| 8 | NESTED LOOPS | | 155 | 34565 | 712 (1)| 00:00:10 | | |
|* 9 | HASH JOIN | | 155 | 31620 | 669 (1)| 00:00:10 | | |
|* 10 | HASH JOIN | | 222 | 28194 | 662 (1)| 00:00:10 | | |
| 11 | TABLE ACCESS BY LOCAL INDEX ROWID| PR_EMPRESS_PAYROLL_FACT | 194 | 7178 | 658 (1)| 00:00:10 | | |
| 12 | NESTED LOOPS | | 1001 | 89089 | 658 (1)| 00:00:10 | | |
| 13 | NESTED LOOPS | | 5 | 260 | 17 (6)| 00:00:01 | | |
|* 14 | HASH JOIN | | 5 | 200 | 7 (15)| 00:00:01 | | |
| 15 | NESTED LOOPS | | 6 | 144 | 4 (0)| 00:00:01 | | |
PLAN_TABLE_OUTPUT
|* 16 | INDEX UNIQUE SCAN | REPORT_OU_IDX1 | 1 | 14 | 1 (0)| 00:00:01 | | |
|* 17 | MAT_VIEW ACCESS FULL | PARENT_LEVEL_LOOKUP_MV | 6 | 60 | 3 (0)| 00:00:01 | | |
| 18 | TABLE ACCESS BY INDEX ROWID | TP_OUC_HIER_CDIM | 5 | 80 | 2 (0)| 00:00:01 | | |
| 19 | BITMAP CONVERSION TO ROWIDS | | | | | | | |
|* 20 | BITMAP INDEX SINGLE VALUE | TP_OUC_HI_IDX2 | | | | | | |
| 21 | TABLE ACCESS BY INDEX ROWID | LEDGER_OUC | 1 | 12 | 2 (0)| 00:00:01 | | |
|* 22 | INDEX RANGE SCAN | LEDGER_OUC_I1 | 1 | | 1 (0)| 00:00:01 | | |
| 23 | PARTITION RANGE ALL | | | | | | 1 | 82 |
| 24 | BITMAP CONVERSION TO ROWIDS | | | | | | | |
|* 25 | BITMAP INDEX SINGLE VALUE | PR_EMPRES_IDX7 | | | | | 1 | 82 |
|* 26 | MAT_VIEW ACCESS FULL | TP_TIME_CDIM_MV | 12 | 456 | 3 (0)| 00:00:01 | | |
|* 27 | TABLE ACCESS FULL | EMPRESS_CODE_DIM | 289 | 22253 | 7 (0)| 00:00:01 | | |
|* 28 | INDEX RANGE SCAN | BTM_EIN_I1 | 1 | | 1 (0)| 00:00:01 | | |
Predicate Information (identified by operation id):
2 - filter("D1"."C16"=1)
3 - filter(ROW_NUMBER() OVER ( PARTITION BY "SAWITH1"."C5","SAWITH1"."C6","SAWITH1"."C20","SAWITH1"."C21","SAWITH1"."C26","S
AWITH1"."C27","SAWITH1"."C28","SAWITH1"."C29","SAWITH1"."C30" ORDER BY
PLAN_TABLE_OUTPUT
"SAWITH1"."C5","SAWITH1"."C6","SAWITH1"."C20","SAWITH1"."C21","SAWITH1"."C26","SAWITH1"."C27","SAWITH1"."C28","SAWITH1"."C29","
SAWITH1"."C30")<=1)
4 - filter(CASE WHEN '@{PR_Allowance}'='London Weighting' THEN "SAWITH1"."C9" WHEN '@{PR_Allowance}'='Pensionable' THEN
"SAWITH1"."C10" WHEN '@{PR_Allowance}'='Non Pensionable' THEN "SAWITH1"."C11" ELSE "SAWITH1"."C8" END <>0.0)
9 - access("T808692"."EMPRESS_CODE_KEY"="T808833"."PR_EMPRESS_CODE_KEY")
10 - access("T808833"."PERIOD_KEY"="T809005"."PERIOD_KEY")
14 - access("T808816"."LEVEL_FROM_PARENT"="T808999"."LEVEL_FROM_PARENT")
16 - access("T809014"."TP_REPORT_OUC_KEY"='B')
17 - filter("T808816"."OUC_TYPE"='Summed')
20 - access("T808999"."TP_REPORT_OUC_KEY"='B')
22 - access("T808999"."TP_CHILD_REPORT_OUC_KEY"="REPORT_OUC")
25 - access("T808833"."TP_LEDGER_OUC_KEY"="LEDGER_OUC")
26 - filter("T809005"."YEAR_DESC"='2010/11' AND TO_NUMBER("T809005"."PERIOD_KEY")<=201112)
27 - filter("T808692"."EMPRESS_HIER_3_CODE"=3 OR "T808692"."EMPRESS_HIER_3_CODE"=5 OR "T808692"."EMPRESS_HIER_3_CODE"=13 OR
"T808692"."EMPRESS_HIER_3_CODE"=17 OR "T808692"."EMPRESS_HIER_3_CODE"=19 OR "T808692"."EMPRESS_HIER_3_CODE"=27 OR
"T808692"."EMPRESS_HIER_3_CODE"=29 OR "T808692"."EMPRESS_HIER_3_CODE"=31)
28 - access("A"."EIN"="T808833"."TP_EIN_KEY")
Note
- dynamic sampling used for this statement
63 rows selected.
Regards
ADHere is the explain plan for the same query run on CT environment.
Rollback complete.
Explain complete.
Commit complete.
PLAN_TABLE_OUTPUT
Plan hash value: 3514862671
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | TQ |I
N-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 58565 | 14M| | 5558 (1)| 00:01:18 | | | |
| |
| 1 | PX COORDINATOR | | | | | | | | | |
| |
| 2 | PX SEND QC (ORDER) | :TQ10011 | 58565 | 14M| | 5558 (1)| 00:01:18 | | | Q1,11 |
P->S | QC (ORDER) |
| 3 | SORT ORDER BY | | 58565 | 14M| 33M| 5558 (1)| 00:01:18 | | | Q1,11 |
PLAN_TABLE_OUTPUT
PCWP | |
| 4 | PX RECEIVE | | 58565 | 14M| | 5556 (1)| 00:01:18 | | | Q1,11 |
PCWP | |
| 5 | PX SEND RANGE | :TQ10010 | 58565 | 14M| | 5556 (1)| 00:01:18 | | | Q1,10 |
P->P | RANGE |
|* 6 | VIEW | | 58565 | 14M| | 5556 (1)| 00:01:18 | | | Q1,10 |
PCWP | |
|* 7 | WINDOW SORT PUSHED RANK | | 58565 | 24M| 57M| 5556 (1)| 00:01:18 | | | Q1,10 |
PCWP | |
|* 8 | VIEW | | 58565 | 24M| | 5555 (1)| 00:01:18 | | | Q1,10 |
PCWP | |
| 9 | WINDOW BUFFER | | 58565 | 13M| | 5555 (1)| 00:01:18 | | | Q1,10 |
PCWP | |
| 10 | SORT GROUP BY | | 58565 | 13M| 28M| 5555 (1)| 00:01:18 | | | Q1,10 |
PLAN_TABLE_OUTPUT
PCWP | |
| 11 | PX RECEIVE | | 58565 | 13M| | 5554 (1)| 00:01:18 | | | Q1,10 |
PCWP | |
| 12 | PX SEND HASH | :TQ10009 | 58565 | 13M| | 5554 (1)| 00:01:18 | | | Q1,09 |
P->P | HASH |
|* 13 | HASH JOIN | | 58565 | 13M| | 5554 (1)| 00:01:18 | | | Q1,09 |
PCWP | |
| 14 | PX RECEIVE | | 58565 | 12M| | 1731 (1)| 00:00:25 | | | Q1,09 |
PCWP | |
| 15 | PX SEND HASH | :TQ10008 | 58565 | 12M| | 1731 (1)| 00:00:25 | | | Q1,08 |
P->P | HASH |
|* 16 | HASH JOIN BUFFERED | | 58565 | 12M| | 1731 (1)| 00:00:25 | | | Q1,08 |
PCWP | |
| 17 | BUFFER SORT | | | | | | | | | Q1,08 |
PLAN_TABLE_OUTPUT
PCWC | |
| 18 | PX RECEIVE | | 1 | 14 | | 1 (0)| 00:00:01 | | | Q1,08 |
PCWP | |
| 19 | PX SEND BROADCAST | :TQ10001 | 1 | 14 | | 1 (0)| 00:00:01 | | | |
S->P | BROADCAST |
|* 20 | INDEX RANGE SCAN | REPORT_OU_IDX1 | 1 | 14 | | 1 (0)| 00:00:01 | | | |
| |
|* 21 | HASH JOIN | | 58565 | 11M| | 1730 (1)| 00:00:25 | | | Q1,08 |
PCWP | |
| 22 | BUFFER SORT | | | | | | | | | Q1,08 |
PCWC | |
| 23 | PX RECEIVE | | 383 | 31023 | | 7 (0)| 00:00:01 | | | Q1,08 |
PCWP | |
| 24 | PX SEND BROADCAST | :TQ10002 | 383 | 31023 | | 7 (0)| 00:00:01 | | | |
PLAN_TABLE_OUTPUT
S->P | BROADCAST |
|* 25 | TABLE ACCESS FULL | EMPRESS_CODE_DIM | 383 | 31023 | | 7 (0)| 00:00:01 | | | |
| |
|* 26 | HASH JOIN | | 82520 | 9912K| | 1722 (1)| 00:00:25 | | | Q1,08 |
PCWP | |
| 27 | BUFFER SORT | | | | | | | | | Q1,08 |
PCWC | |
| 28 | PX RECEIVE | | 6 | 60 | | 3 (0)| 00:00:01 | | | Q1,08 |
PCWP | |
| 29 | PX SEND BROADCAST | :TQ10003 | 6 | 60 | | 3 (0)| 00:00:01 | | | |
S->P | BROADCAST |
|* 30 | MAT_VIEW ACCESS FULL | PARENT_LEVEL_LOOKUP_MV | 6 | 60 | | 3 (0)| 00:00:01 | | | |
| |
|* 31 | HASH JOIN | | 136K| 14M| | 1718 (1)| 00:00:25 | | | Q1,08 |
PLAN_TABLE_OUTPUT
PCWP | |
| 32 | BUFFER SORT | | | | | | | | | Q1,08 |
PCWC | |
| 33 | PX RECEIVE | | 43293 | 845K| | 1137 (1)| 00:00:16 | | | Q1,08 |
PCWP | |
| 34 | PX SEND BROADCAST | :TQ10004 | 43293 | 845K| | 1137 (1)| 00:00:16 | | | |
S->P | BROADCAST |
| 35 | TABLE ACCESS BY INDEX ROWID | TP_OUC_HIER_CDIM | 43293 | 845K| | 1137 (1)| 00:00:16 | | | |
| |
| 36 | BITMAP CONVERSION TO ROWIDS| | | | | | | | | |
| |
|* 37 | BITMAP INDEX SINGLE VALUE | TP_OUC_HI_IDX2 | | | | | | | | |
| |
|* 38 | HASH JOIN | | 627K| 55M| | 581 (2)| 00:00:09 | | | Q1,08 |
{code}
Edited by: user1128836 on Apr 26, 2012 3:39 AM -
Differenet Explain Plan for Same Query
DB Version : 11.2.0.3
OS Version : AIX 6
I have two Queries ( The Difference between Them Only 940 and 584 ) When I Generate Explain Plan Different Output Why ? Why CPU time is Different Each Time
First Query Statement :
INSERT INTO TempSearchResult (t_aid,
t_umidl,
t_umidh,
X_CREA_DATE_TIME_MESG)
SELECT z.aid,
z.mesg_s_umidl,
z.mesg_s_umidh,
z.mesg_crea_date_time
FROM ( SELECT m.aid,
m.mesg_s_umidl,
m.mesg_s_umidh,
m.mesg_crea_date_time
FROM RSMESG_ESIDE m
WHERE 1 = 1
AND m.mesg_crea_date_time BETWEEN TO_DATE (
'20120131 10:00:00',
'YYYYMMDD HH24:MI:SS')
AND TO_DATE (
'20120131 13:00:00',
'YYYYMMDD HH24:MI:SS')
AND m.mesg_frmt_name = 'Swift'
AND m.mesg_sender_x1 = 'SOGEFRPPXXX'
AND m.mesg_nature = 'FINANCIAL_MSG'
AND m.mesg_type LIKE '950'
ORDER BY mesg_crea_date_time) z
WHERE ROWNUM <= 5000
Explain Plan for First Query :
PLAN_TABLE_OUTPUT
Plan hash value: 3901722890
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | INSERT STATEMENT | | 2866 | 134K| 197 (3)| 00:00:03 | | |
| 1 | LOAD TABLE CONVENTIONAL | TEMPSEARCHRESULT | | | | | | |
|* 2 | COUNT STOPKEY | | | | | | | |
| 3 | VIEW | | 2866 | 134K| 197 (3)| 00:00:03 | | |
|* 4 | SORT ORDER BY STOPKEY | | 2866 | 333K| 197 (3)| 00:00:03 | | |
| 5 | NESTED LOOPS | | 2866 | 333K| 196 (2)| 00:00:03 | | |
PLAN_TABLE_OUTPUT
| 6 | NESTED LOOPS | | 1419 | 148K| 196 (2)| 00:00:03 | | |
|* 7 | HASH JOIN | | 1419 | 141K| 196 (2)| 00:00:03 | | |
| 8 | NESTED LOOPS | | 91 | 1911 | 2 (0)| 00:00:01 | | |
| 9 | TABLE ACCESS BY INDEX ROWID | SUSER | 1 | 10 | 1 (0)| 00:00:01 | | |
|* 10 | INDEX UNIQUE SCAN | IX_SUSER | 1 | | 0 (0)| 00:00:01 | | |
|* 11 | INDEX FULL SCAN | PK_SUNITUSERGROUP | 91 | 1001 | 1 (0)| 00:00:01 | | |
| 12 | PARTITION RANGE SINGLE | | 1450 | 114K| 193 (2)| 00:00:03 | 2 | 2 |
|* 13 | TABLE ACCESS BY LOCAL INDEX ROWID| RMESG | 1450 | 114K| 193 (2)| 00:00:03 | 2 | 2 |
|* 14 | INDEX SKIP SCAN | IX_RMESG | 415 | | 14 (15)| 00:00:01 | 2 | 2 |
|* 15 | INDEX UNIQUE SCAN | PK_SMSGUSERGROUP | 1 | 5 | 0 (0)| 00:00:01 | | |
|* 16 | INDEX UNIQUE SCAN | PK_SBICUSERGROUP | 2 | 24 | 0 (0)| 00:00:01 | | |
PLAN_TABLE_OUTPUT
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
2 - filter(ROWNUM<=5000)
4 - filter(ROWNUM<=5000)
7 - access("X_INST0_UNIT_NAME"="UNIT")
10 - access("SUSER"."USERNAME"="SIDE"."GETMYUSER"())
11 - access("SUSER"."GROUPID"="SUNITUSERGROUP"."GROUPID")
filter("SUSER"."GROUPID"="SUNITUSERGROUP"."GROUPID")
PLAN_TABLE_OUTPUT
13 - filter("RMESG"."MESG_SENDER_X1"='SOGEFRPPXXX' AND "RMESG"."MESG_NATURE"='FINANCIAL_MSG' AND
"RMESG"."MESG_FRMT_NAME"='Swift')
14 - access("RMESG"."MESG_CREA_DATE_TIME">=TO_DATE(' 2012-01-31 10:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"RMESG"."MESG_TYPE"='950' AND "RMESG"."MESG_CREA_DATE_TIME"<=TO_DATE(' 2012-01-31 13:00:00', 'syyyy-mm-dd hh24:mi:ss'))
filter("RMESG"."MESG_TYPE"='950')
15 - access("X_CATEGORY"="CATEGORY" AND "SUSER"."GROUPID"="SMSGUSERGROUP"."GROUPID")
16 - access("X_OWN_LT"="BICCODE" AND "SUSER"."GROUPID"="SBICUSERGROUP"."GROUPID")
40 rows selected.
Second query
INSERT INTO TempSearchResult (t_aid,
t_umidl,
t_umidh,
X_CREA_DATE_TIME_MESG)
SELECT z.aid,
z.mesg_s_umidl,
z.mesg_s_umidh,
z.mesg_crea_date_time
FROM ( SELECT m.aid,
m.mesg_s_umidl,
m.mesg_s_umidh,
m.mesg_crea_date_time
FROM RSMESG_ESIDE m
WHERE 1 = 1
AND m.mesg_crea_date_time BETWEEN TO_DATE (
'20120117 10:00:00',
'YYYYMMDD HH24:MI:SS')
AND TO_DATE (
'20120117 13:00:00',
'YYYYMMDD HH24:MI:SS')
AND m.mesg_frmt_name = 'Swift'
AND m.mesg_sender_x1 = 'SOGEFRPPGSS'
AND m.mesg_nature = 'FINANCIAL_MSG'
AND m.mesg_type LIKE '548'
ORDER BY mesg_crea_date_time) z
WHERE ROWNUM <= 5000
Explain Plan For Second Query :
PLAN_TABLE_OUTPUT
Plan hash value: 4106071428
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
| 0 | INSERT STATEMENT | | 1073 | 51504 | | 2622 (1)| 00:00:32 | | |
| 1 | LOAD TABLE CONVENTIONAL | TEMPSEARCHRESULT | | | | | | | |
|* 2 | COUNT STOPKEY | | | | | | | | |
| 3 | VIEW | | 1073 | 51504 | | 2622 (1)| 00:00:32 | | |
|* 4 | SORT ORDER BY STOPKEY | | 1073 | 124K| | 2622 (1)| 00:00:32 | | |
| 5 | NESTED LOOPS | | 1073 | 124K| | 2621 (1)| 00:00:32 | | |
PLAN_TABLE_OUTPUT
| 6 | NESTED LOOPS | | 531 | 56817 | | 2621 (1)| 00:00:32 | | |
| 7 | NESTED LOOPS | | 531 | 54162 | | 2621 (1)| 00:00:32 | | |
| 8 | NESTED LOOPS | | 543 | 49413 | | 2621 (1)| 00:00:32 | | |
| 9 | TABLE ACCESS BY INDEX ROWID | SUSER | 1 | 10 | | 1 (0)| 00:00:01 | | |
|* 10 | INDEX UNIQUE SCAN | IX_SUSER | 1 | | | 0 (0)| 00:00:01 | | |
| 11 | PARTITION RANGE SINGLE | | 543 | 43983 | | 2621 (1)| 00:00:32 | 2 | 2 |
|* 12 | TABLE ACCESS BY LOCAL INDEX ROWID| RMESG | 543 | 43983 | | 2621 (1)| 00:00:32 | 2 | 2 |
| 13 | BITMAP CONVERSION TO ROWIDS | | | | | | | | |
| 14 | BITMAP AND | | | | | | | | |
| 15 | BITMAP CONVERSION FROM ROWIDS | | | | | | | | |
|* 16 | INDEX RANGE SCAN | IX_SENDER | 25070 | | | 894 (1)| 00:00:11 | 2 | 2 |
PLAN_TABLE_OUTPUT
| 17 | BITMAP CONVERSION FROM ROWIDS | | | | | | | | |
| 18 | SORT ORDER BY | | | | 408K| | | | |
|* 19 | INDEX RANGE SCAN | IX_RMESG | 25070 | | | 1405 (1)| 00:00:17 | 2 | 2 |
|* 20 | INDEX UNIQUE SCAN | PK_SUNITUSERGROUP | 1 | 11 | | 0 (0)| 00:00:01 | | |
|* 21 | INDEX UNIQUE SCAN | PK_SMSGUSERGROUP | 1 | 5 | | 0 (0)| 00:00:01 | | |
|* 22 | INDEX UNIQUE SCAN | PK_SBICUSERGROUP | 2 | 24 | | 0 (0)| 00:00:01 | | |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
2 - filter(ROWNUM<=5000)
4 - filter(ROWNUM<=5000)
10 - access("SUSER"."USERNAME"="SIDE"."GETMYUSER"())
12 - filter("RMESG"."MESG_NATURE"='FINANCIAL_MSG' AND "RMESG"."MESG_FRMT_NAME"='Swift')
16 - access("RMESG"."MESG_SENDER_X1"='SOGEFRPPGSS')
19 - access("RMESG"."MESG_CREA_DATE_TIME">=TO_DATE(' 2012-01-17 10:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"RMESG"."MESG_TYPE"='548' AND "RMESG"."MESG_CREA_DATE_TIME"<=TO_DATE(' 2012-01-17 13:00:00', 'syyyy-mm-dd hh24:mi:ss'))
filter("RMESG"."MESG_TYPE"='548' AND "RMESG"."MESG_CREA_DATE_TIME"<=TO_DATE(' 2012-01-17 13:00:00', 'syyyy-mm-dd
hh24:mi:ss') AND "RMESG"."MESG_CREA_DATE_TIME">=TO_DATE(' 2012-01-17 10:00:00', 'syyyy-mm-dd hh24:mi:ss'))
20 - access("X_INST0_UNIT_NAME"="UNIT" AND "SUSER"."GROUPID"="SUNITUSERGROUP"."GROUPID")
21 - access("X_CATEGORY"="CATEGORY" AND "SUSER"."GROUPID"="SMSGUSERGROUP"."GROUPID")
PLAN_TABLE_OUTPUT
22 - access("X_OWN_LT"="BICCODE" AND "SUSER"."GROUPID"="SBICUSERGROUP"."GROUPID")
45 rows selected.
Table Structure TEMPSEARCHRESULT
CREATE GLOBAL TEMPORARY TABLE TEMPSEARCHRESULT
T_AID NUMBER(3),
T_UMIDL NUMBER(10),
T_UMIDH NUMBER(10),
X_CREA_DATE_TIME_MESG DATE
ON COMMIT PRESERVE ROWS
NOCACHE;
CREATE INDEX SIDE.TEMP_SEARCH_INDEX ON SIDE.TEMPSEARCHRESULT
(T_AID, T_UMIDL, T_UMIDH, X_CREA_DATE_TIME_MESG);Again Thank you For your amazing Answer.
For indexes it's a balance. Check this query which is Simple
Select * from RMESGI generated Explain Plan for it to see effect of indexes .
PLAN_TABLE_OUTPUT
Plan hash value: 1686435785
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 11M| 8920M| 376K (1)| 01:15:20 | | |
| 1 | PARTITION RANGE ALL| | 11M| 8920M| 376K (1)| 01:15:20 | 1 | 12 |
| 2 | TABLE ACCESS FULL | RMESG | 11M| 8920M| 376K (1)| 01:15:20 | 1 | 12 |
---------------------------------------------------------------------------------------------1:15:20 For table access and Full Scan Also , I generate new Indexes on the table like the following
CREATE TABLE RMESG(
aid NUMBER(3) NOT NULL,
mesg_s_umidl NUMBER(10) NOT NULL,
mesg_s_umidh NUMBER(10) NOT NULL,
mesg_validation_requested CHAR(18) NOT NULL,
mesg_validation_passed CHAR(18) NOT NULL,
mesg_class CHAR(16) NOT NULL,
mesg_is_text_readonly NUMBER(1) NOT NULL,
mesg_is_delete_inhibited NUMBER(1) NOT NULL,
mesg_is_text_modified NUMBER(1) NOT NULL,
mesg_is_partial NUMBER(1) NOT NULL,
mesg_crea_mpfn_name CHAR(24) NOT NULL,
mesg_crea_rp_name CHAR(24) NOT NULL,
mesg_crea_oper_nickname CHAR(151) NOT NULL,
mesg_crea_date_time DATE NOT NULL,
mesg_mod_oper_nickname CHAR(151) NOT NULL,
mesg_mod_date_time DATE NOT NULL,
mesg_frmt_name VARCHAR2(17) NOT NULL,
mesg_nature CHAR(14) NOT NULL,
mesg_sender_x1 CHAR(11) NOT NULL,
mesg_sender_corr_type VARCHAR2(24) NOT NULL,
mesg_uumid VARCHAR2(50) NOT NULL,
mesg_uumid_suffix NUMBER(10) NOT NULL,
x_own_lt CHAR(8) NOT NULL,
x_inst0_unit_name VARCHAR2(32) default 'NONE' NOT NULL,
x_category CHAR(1) NOT NULL,
archived NUMBER(1) NOT NULL,
restored NUMBER(1) NOT NULL,
mesg_related_s_umid CHAR(16) NULL,
mesg_status CHAR(12) NULL,
mesg_crea_appl_serv_name CHAR(24) NULL,
mesg_verf_oper_nickname CHAR(151) NULL,
mesg_data_last NUMBER(10) NULL,
mesg_token NUMBER(10) NULL,
mesg_batch_reference VARCHAR2(46) NULL,
mesg_cas_sender_reference VARCHAR2(40) NULL,
mesg_cas_target_rp_name VARCHAR2(20) NULL,
mesg_ccy_amount VARCHAR2(501) NULL,
mesg_copy_service_id VARCHAR2(4) NULL,
mesg_data_keyword1 VARCHAR2(80) NULL,
mesg_data_keyword2 VARCHAR2(80) NULL,
mesg_data_keyword3 VARCHAR2(80) NULL,
mesg_delv_overdue_warn_req NUMBER(1) NULL,
mesg_fin_ccy_amount VARCHAR2(24) NULL,
mesg_fin_value_date CHAR(6) NULL,
mesg_is_live NUMBER(1) NULL,
mesg_is_retrieved NUMBER(1) NULL,
mesg_mesg_user_group VARCHAR2(24) NULL,
mesg_network_appl_ind CHAR(3) NULL,
mesg_network_delv_notif_req NUMBER(1) NULL,
mesg_network_obso_period NUMBER(10) NULL,
mesg_network_priority CHAR(12) NULL,
mesg_possible_dup_creation VARCHAR2(8) NULL,
mesg_receiver_alia_name VARCHAR2(32) NULL,
mesg_receiver_swift_address CHAR(12) NULL,
mesg_recovery_accept_info VARCHAR2(80) NULL,
mesg_rel_trn_ref VARCHAR2(80) NULL,
mesg_release_info VARCHAR2(32) NULL,
mesg_security_iapp_name VARCHAR2(80) NULL,
mesg_security_required NUMBER(1) NULL,
mesg_sender_x2 VARCHAR2(21) NULL,
mesg_sender_x3 VARCHAR2(21) NULL,
mesg_sender_x4 VARCHAR2(21) NULL,
mesg_sender_branch_info VARCHAR2(71) NULL,
mesg_sender_city_name VARCHAR2(36) NULL,
mesg_sender_ctry_code VARCHAR2(3) NULL,
mesg_sender_ctry_name VARCHAR2(71) NULL,
mesg_sender_institution_name VARCHAR2(106) NULL,
mesg_sender_location VARCHAR2(106) NULL,
mesg_sender_swift_address CHAR(12) NULL,
mesg_sub_format VARCHAR2(6) NULL,
mesg_syntax_table_ver VARCHAR2(8) NULL,
mesg_template_name VARCHAR2(32) NULL,
mesg_trn_ref VARCHAR2(16) NULL,
mesg_type CHAR(3) NULL,
mesg_user_issued_as_pde NUMBER(1) NULL,
mesg_user_priority_code CHAR(4) NULL,
mesg_user_reference_text VARCHAR2(30) NULL,
mesg_zz41_is_possible_dup NUMBER(1) NULL,
x_fin_ccy CHAR(3) NULL,
x_fin_amount NUMBER(21,4) NULL,
x_fin_value_date DATE NULL,
x_fin_ocmt_ccy CHAR(3) NULL,
x_fin_ocmt_amount NUMBER(21,4) NULL,
x_receiver_x1 CHAR(11) NULL,
x_receiver_x2 VARCHAR2(21) NULL,
x_receiver_x3 VARCHAR2(21) NULL,
x_receiver_x4 VARCHAR2(21) NULL,
last_update DATE NULL,
set_id NUMBER(10) NULL,
mesg_requestor_dn VARCHAR2(101) NULL,
mesg_service VARCHAR2(31) NULL,
mesg_request_type VARCHAR2(31) NULL,
mesg_identifier VARCHAR2(31) NULL,
mesg_xml_query_ref1 VARCHAR2(101) NULL,
mesg_xml_query_ref2 VARCHAR2(101) NULL,
mesg_xml_query_ref3 VARCHAR2(101) NULL,
mesg_appl_sender_reference VARCHAR2(51) NULL,
mesg_payload_type VARCHAR2(31) NULL,
mesg_sign_digest_reference VARCHAR2(41) NULL,
mesg_sign_digest_value VARCHAR2(51) NULL,
mesg_use_pki_signature NUMBER(1) NULL
PARTITION BY RANGE(MESG_CREA_DATE_TIME) (
PARTITION SIDE_MIN VALUES LESS THAN (TO_DATE(20000101, 'YYYYMMDD')) TABLESPACE TBS_SIDEDB_DA_01);
CREATE UNIQUE INDEX SIDE.IX_PK_RMESG on SIDE.RMESG (AID, MESG_S_UMIDH, MESG_S_UMIDL, MESG_CREA_DATE_TIME) LOCAL;
ALTER TABLE SIDE.RMESG ADD CONSTRAINT IX_PK_RMESG PRIMARY KEY (AID, MESG_S_UMIDH, MESG_S_UMIDL, MESG_CREA_DATE_TIME) USING INDEX SIDE.IX_PK_RMESG;
CREATE INDEX SIDE.ix_rmesg_cassender ON SIDE.rmesg (MESG_CAS_SENDER_REFERENCE) LOCAL;
CREATE INDEX SIDE.ix_rmesg_creationdate ON SIDE.rmesg (MESG_CREA_DATE_TIME) LOCAL;
CREATE INDEX SIDE.ix_rmesg_trnref ON SIDE.rmesg (MESG_TRN_REF) LOCAL;
CREATE INDEX SIDE.ix_rmesg_uumid ON SIDE.rmesg (MESG_UUMID, MESG_UUMID_SUFFIX) LOCAL;
CREATE INDEX SIDE.IX_UNIT_NAME_RMESG on RMESG(mesg_crea_date_time,X_INST0_UNIT_NAME) LOCAL;
CREATE INDEX SIDE.IX_RMESG on RMESG(mesg_crea_date_time ,mesg_type,x_fin_ccy) LOCAL;
CREATE INDEX SIDE.IX_NAME_FORMAT_TYPE_RMESG on RMESG(mesg_frmt_name,mesg_sub_format,mesg_type,mesg_crea_date_time ) LOCAL;same Explain Plan Same Result .
I always remember TOM Quote "full scans are not evil, indexes are not good"
Which Mean Something Wrong Goes with Indexes , the partition depend on MESG_CREA_DATE_TIME Column I create Index for this column but same explain plan Appear every time. With Same Time.
Thank you
Osama -
Explain plan going in Billions
Dear All,
We are having a huge table of data and when I am running explain plan for the table I am getting the below plan from ORACLE.
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 4149 | 129K| 1692 | | |
| 1 | SORT GROUP BY NOSORT | | 4149 | 129K| 1692 | | |
| 2 | VIEW | | 4149 | 129K| 1692 | | |
| 3 | SORT GROUP BY | | 4149 | 717K| 1692 | | |
| 4 | FILTER | | | | | | |
| 5 | HASH JOIN | | 4149 | 717K| 1691 | | |
| 6 | TABLE ACCESS FULL | R_CFG_CATEGORY_MAS | 103 | 4429 | 3 | | |
| 7 | HASH JOIN | | 4149 | 542K| 1687 | | |
| 8 | PARTITION RANGE ITERATOR | | 4149 | 287K| 21687 | KEY | KEY |
| 9 | PARTITION HASH SINGLE | | 4149 | 287K| 21687 | KEY | KEY |
| 10 | TABLE ACCESS FULL | R_CFG_WH_EXCEP | 4149 | 287K| 21687 | | |
| 11 | MERGE JOIN CARTESIAN | | 2105K| 126M| *18E*| | |
| 12 | VIEW | | 475 | 10925 | 3 | | |
| 13 | CONNECT BY WITH FILTERING | | | | | | |
| 14 | TABLE ACCESS BY INDEX ROWID| R_CFG_CAT_HIERARCHY_MAS | | | | | |
| 15 | NESTED LOOPS | | 19 | 247 | 3 | | |
| 16 | TABLE ACCESS FULL | R_CFG_CAT_HIERARCHY_MAS | 19 | 171 | 3 | | |
| 17 | INDEX UNIQUE SCAN | PK_RCCHM_CAT_REGID_PK | 1 | 4 | 0 | | |
| 18 | HASH JOIN | | | | | | |
| 19 | CONNECT BY PUMP | | | | | | |
| 20 | TABLE ACCESS FULL | R_CFG_CAT_HIERARCHY_MAS | 475 | 5225 | 3 | | |
| 21 | TABLE ACCESS FULL | R_CFG_CAT_HIERARCHY_MAS | 475 | 5225 | 3 | | |
| 22 | BUFFER SORT | | 4432 | 173K| *18E*| | |
| 23 | TABLE ACCESS BY INDEX ROWID | R_DEVICE_INFO | 4432 | 173K| *18E*| | |
| 24 | BITMAP CONVERSION TO ROWIDS| | | | | | |
| 25 | BITMAP INDEX SINGLE VALUE | R_DEVICE_INFO_CPYKEY | | | | | |
Note
- 'PLAN_TABLE' is old version
I can see cost in 18E which is huge and ridiculous.
I can explain points that I noted on this table.
This table is having more than 1 BILLIION RECORDS AND I am querying for a user which has got 5 MILLION RECORDS.
This table is properly partitioned and is having proper indexes.
We got some BITMAP indexes on this table also.
This table has got proper partitioned indexes also. (But the indexes and the table are in the same tablespace).
Can Anyone give me some sugessitions on how to reduce the overall cost.
Appreciate your response on this one.
Thanks,
Madhu K.569725 wrote:
I can see cost in 18E which is huge and ridiculous.For a cartesian merge join... Cartesian joins are notoriously expensive.
This table is having more than 1 BILLIION RECORDS AND I am querying for a user which has got 5 MILLION RECORDS.Does not matter. The number of rows (note we store rows in tables, not records) does not matter. It is about how much I/O is needed to process that amount of data.
And this is what invariably we design for.. using relational design, using indexes, using partitioning, using clustering, etc. All these are techniques to reduce I/O. From eliminating duplication of data to providing optimal I/O paths to the data.
A real world example:
SQL> set timing on
SQL> select count(*) from daily_xxxxx;
COUNT(*)
2160339906
Elapsed: 00:00:10.09
SQL>
SQL> select count(*) from all_objects;
COUNT(*)
51255
Elapsed: 00:01:43.60So despite "+processing+" over 2 billion rows, the count is significantly faster than the count of the very much smaller ALL_OBJECTS view.
Why? Because it took less I/O to count those 2 billion rows (using a single index) than the nearly 52 thousand objects in the data dictionary (using several indexes and tables).
The rules that governs performance do not change with the number of rows in a table. The same rules and principles apply. What does change is the "+error margin+" - you are going to see a performance problem quite a lot sooner on a large table than a very small table. You may not notice that a 1ms overhead per row is a performance problem on a 100 row table. You will definitely notice it on a million row table.
So forget about the number of rows in these tables. Make sure that the SQL is designed logically correctly. Make sure that the table/db design provides optimal I/O paths for that SQL.
And catersian merge joins, nested loops with full table scans and so on.. that points to both these as being potential problems. SQL designed incorrectly (like forgetting join criteria). Table design lacking (requiring nested loop full table scans as oppose to index range scans or hash joins).
Oh yeah - and as already mentioned, forget the cost that the execution plan shows. Unless you know what unit that cost is expressed in and how to interpret it? -
Query with same explain-plan but slower in one env
Hi there
I have a stored procedure which is executed from a web application. It contains a query (insert-select-from statement). When this stored procedure is called by the web application in PROD, it takes 13sec but it takes 19sec in TEST env. I checked the explain plan for this insert statement in both instances and it is same (see below). Actually, the cost is lower in TEST env.
ENV: Oracle 10gR2 EE, on ASM - RHEL 64bit
The TEST server is on a better/faster hardware and will become the new PROD in near future (faster and 16 CPUs vs 8 in PROD, high performance SAN, 132GB RAM vs 96GB in PROD, etc). The TEST database has exact same init parameter and version/patch level as current PROD. So the application is being tested against it at the moment.
Here are the explain-plans from both environments:
From PROD Server
Plan
INSERT STATEMENT ALL_ROWS Cost: 143 Bytes: 696 Cardinality: 3
18 SORT ORDER BY Cost: 143 Bytes: 696 Cardinality: 3
17 HASH UNIQUE Cost: 142 Bytes: 696 Cardinality: 3
16 WINDOW SORT Cost: 143 Bytes: 696 Cardinality: 3
15 HASH JOIN Cost: 141 Bytes: 696 Cardinality: 3
13 HASH JOIN Cost: 128 Bytes: 519 Cardinality: 3
11 TABLE ACCESS BY INDEX ROWID TABLE MKTG.SATDATAIMPORT Cost: 125 Bytes: 1,728 Cardinality: 12
10 NESTED LOOPS Cost: 125 Bytes: 1,992 Cardinality: 12
3 HASH JOIN Cost: 5 Bytes: 22 Cardinality: 1
1 TABLE ACCESS FULL TABLE MKTG.TMPG_CLICKS_HDGS Cost: 2 Bytes: 12 Cardinality: 1
2 TABLE ACCESS FULL TABLE MKTG.TMPG_CLICKS_DIRS Cost: 2 Bytes: 10 Cardinality: 1
9 BITMAP CONVERSION TO ROWIDS
8 BITMAP AND
5 BITMAP CONVERSION FROM ROWIDS
4 INDEX RANGE SCAN INDEX MKTG.SATDATAIMPORT_HEADINGNO Cost: 19 Cardinality: 4,920
7 BITMAP CONVERSION FROM ROWIDS
6 INDEX RANGE SCAN INDEX MKTG.SATDATAIMPORT_DIRNO Cost: 89 Cardinality: 4,920
12 TABLE ACCESS FULL TABLE MKTG.MONTHS12 Cost: 2 Bytes: 84 Cardinality: 12
14 TABLE ACCESS FULL TABLE MKTG.REF_WEST_CATEGORY Cost: 12 Bytes: 191,809 Cardinality: 3,251
From TEST Server
Plan
INSERT STATEMENT ALL_ROWS Cost: 107 Bytes: 232 Cardinality: 1
18 SORT ORDER BY Cost: 107 Bytes: 232 Cardinality: 1
17 HASH UNIQUE Cost: 106 Bytes: 232 Cardinality: 1
16 WINDOW SORT Cost: 107 Bytes: 232 Cardinality: 1
15 HASH JOIN Cost: 105 Bytes: 232 Cardinality: 1
13 HASH JOIN Cost: 93 Bytes: 173 Cardinality: 1
11 TABLE ACCESS BY INDEX ROWID TABLE MKTG.SATDATAIMPORT Cost: 89 Bytes: 864 Cardinality: 6
10 NESTED LOOPS Cost: 89 Bytes: 996 Cardinality: 6
3 HASH JOIN Cost: 7 Bytes: 22 Cardinality: 1
1 TABLE ACCESS FULL TABLE MKTG.TMPG_CLICKS_HDGS Cost: 3 Bytes: 12 Cardinality: 1
2 TABLE ACCESS FULL TABLE MKTG.TMPG_CLICKS_DIRS Cost: 3 Bytes: 10 Cardinality: 1
9 BITMAP CONVERSION TO ROWIDS
8 BITMAP AND
5 BITMAP CONVERSION FROM ROWIDS
4 INDEX RANGE SCAN INDEX MKTG.SATDATAIMPORT_HEADINGNO Cost: 9 Cardinality: 2,977
7 BITMAP CONVERSION FROM ROWIDS
6 INDEX RANGE SCAN INDEX MKTG.SATDATAIMPORT_DIRNO Cost: 59 Cardinality: 2,977
12 TABLE ACCESS FULL TABLE MKTG.MONTHS12 Cost: 3 Bytes: 84 Cardinality: 12
14 TABLE ACCESS FULL TABLE MKTG.REF_WEST_CATEGORY Cost: 12 Bytes: 191,868 Cardinality: 3,252
What else can I check to find out why the query is slower in TEST env?
Please advise.
Best regardsHere is some more info. The query is below:
select distinct dr.line_num
,row_number() over (partition by di.HEADINGNO,di.DIRECTORYNO order by reportyear,to_number(di.monthno)) monthposition
,di.SATID,di.REPORTYEAR,di.MONTHNO,di.MONTHEN,di.MONTHFR,di.HEADINGNO,hn.NAME_EN,hn.NAME_FR,di.DIRECTORYNO
,di.SUPERDIRECTORYNO,di.PRINTDIRCODE,di.DIRECTORYNAME,round(to_number(di.IMPTTOTAL)) imptotal
,round(to_number(di.IMPBEST)) impbest ,round(to_number(di.IMPTAVERAGE)) imptaverage
,round(to_number(di.CLICKTOTAL)) clicktotal,round(to_number(di.CLICKBEST)) clickbest
,round(to_number(di.CLICKAVERAGE)) clickaverage
,round(avg(to_number(impttotal)) over(partition by di.HEADINGNO,di.DIRECTORYNO)) avgimp
from satdataimport di,tmpg_clicks_hdgs hd,tmpg_clicks_dirs dr, months12 m12, ref_west_category hn
where di.headingno = hd.id
and di.directoryno = dr.id
and dr.line_num=hd.line_num
and di.reportyear = m12.year
and di.monthno = m12.month
and hn.CATEGORY_CODE = di.headingno
order by di.headingno, di.directoryno,di.reportyear,to_number(di.monthno)
The largest table is "satdataimport" in the query has "12274818" rows. Rest of the tables are very small containing few rows to less than 4000 rows.
I have refreshed the statistics of the larger table but this did not help either. Even a simple query like "select count(*) from satdataimport" is taking 15sec in TEST while it takes 4Sec in PROD when I run it from TOAD.
The other strange thing is that when I run this stored procedure from TOAD, it takes 200 milli sec to complete. There is a logging table to which the stored procedure records the elapsed time taken by this INSERT statement.
Since this query is in a stored procedure being called from the web app, the QA team wants quicker response. Current PROD is faster.
The tables have same indexes, etc and contain identical data as that in PROD (were refreshed from PROD yesterday).
What else can I check?
Best regards -
Explain plan looks ok but query still slow
hi,
i have a query that from the explain plan it looks ok( at least to me) but the query is taking very long time to return results
how can i further improve its performance ?
SELECT STATEMENT, GOAL = CHOOSE Cardinality=45 Cost=7529 Optimizer=CHOOSE
SORT UNIQUE Cardinality=45 Cost=7426
FILTER
FILTER
HASH JOIN Cardinality=45 Cost=7421
INDEX RANGE SCAN Cardinality=277 Cost=5 Optimizer=ANALYZED Object name=FDC_EQP_IDX
TABLE ACCESS BY INDEX ROWID Cardinality=417 Cost=7415 Optimizer=ANALYZED Object name=FDC_SSALARMACTIVE
INDEX RANGE SCAN Cardinality=15015 Cost=42 Optimizer=ANALYZED Object name=FDC_SSALARM_IDX
BITMAP CONVERSION TO ROWIDS
BITMAP AND
BITMAP INDEX SINGLE VALUE Object name=FDC_ALARM_IDX1
BITMAP CONVERSION FROM ROWIDS
INDEX RANGE SCAN Cardinality=11 Cost=1 Optimizer=ANALYZED Object name=FDC_ALARM_IDX2tks & rdgsHi,
I agreed with Nicolas. But I have few suggestion for.
First you check the indexes used is fine or not.
-FDC_SSALARMACTIVE
-FDC_SSALARM_IDX
Because I am confuse here
""TABLE ACCESS BY INDEX ROWID Cardinality=417 Cost=7415 Optimizer=ANALYZED Object name=FDC_SSALARMACTIVE"
IF the table is accessed by index rowid then why both the Cost & Cardinality is that much high.
Thanx.. Ratan -
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)
Maybe you are looking for
-
How do i only disable the icloud on the ipad mini only?
Hi, I have a macbook pro, iphone 5 and a ipad mini. I would like to know how do I disable the icloud settings on only my ipad mini? Basically, I do not want icloud Active on the ipad mini.. I only want it active only on my macbook pro and on my ipho
-
I purchased a TV show in HD but where's the SD version?
I purchased a TV show season in HD and usually the SD version starts to download along with the HD version when I click the "Buy" button, however, this time not only did it not appear in Downloads, when I go to the show's iTunes store page it shows
-
How Create a dynamic filter on Segment
Hi guys. I have already the complete integration between Oracle BIEE and Siebel MARKETING. So i want to create, in the oracle BI side, a single segment filtered with a System Parameter-->"Campaign origin code". Because i want define only 1 segment,wi
-
My password was reset today but I still cannot open Adobe Reader - help!
-
hi all, iam using BDC_close_group. while executing this iam getting queue error. plz suggest me any solution