Explain Plan query
I just changed the hint to pick different indexes inside the same SQL and they have significant different performance. SQL1 is much faster than SQL2 and the explain plain is very different. I found that there is some values like :Q1003, :Q1004 and :Q1005 under Object Code in the explain plan of SQL1. May I know how to interpret this?
Thanks.
Edited by: 843672 on Mar 11, 2011 3:42 AM
Welcome to the forum.
Before you even think of posting another 'question', first read:
http://tkyte.blogspot.com/2005/06/how-to-ask-questions.html
and secondly, when it comes to tuning requests, read:
When your query takes too long ...
HOW TO: Post a SQL statement tuning request - template posting
and there's also a FAQ and a SQL and PL/SQL FAQ....
http://forums.oracle.com/forums/ann.jspa?annID=1535
Similar Messages
-
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 -
Explain Plan understand technique & Query optimizing check list
Hello gurus,
Can some body help me with doc available or your experience to tell on how to understand Explain Plan & Query optimizing check list.
Thanks..That's correct,
But unfortunately the institute is pretty far from home.. and travelling time will be high..
I am a working man..
Please suggest if some good book or link.
Thanks. -
Query tunning in Oracle using Explain Plan
Adding to my below question: I have now modified the query and the path shownby 'Explain plan' has reduced. The 'Time' column of plan_table is also showing much lesser value. However, some people are suggesting me to consider the time required by the query to execute on Toad. Will it be practical? Please help!!
Hi, I am using Oracle 11g. I need to optimize a Select query(Need to minimize the execution time). I need to know how 'Explain Plan' would help me. I know how to use Explain Plan command. I refer Plan_table table to see the details of the plan. Please guide me regarding which columns of the Plan_table should be considered while modifying the query for optimization. Some people say, 'Time' column should be considered, some say 'Bytes' etc. Some suggest on minimizing the full table scans, while some people say that I should minimize the total no. operations (less no. of rows should be displayed in Plan_table). As per an experienced friend of mine, full table scans should be reduced (for e.g. if there are 5 full table scans in the plan, then try to reduce them to less than 5. ). However, if I consider any full table scan operation in the plan_table, its shows value of 'time' column as only 1 which is very very less. Does this mean the full scan is actually taking very less time?? If yes, then this means full table scans are very fast in my case and no need to work on them. Some articles suggest that plan shown by 'Explain Plan' command is not necessarily followed while executing the query. So what should I look for then? How should I optimize the query and how will I come to know that it's optimized?? Please help!!...
Edited by: 885901 on Sep 20, 2011 2:10 AM885901 wrote:
Hi, I am using Oracle 11g. I need to optimize a Select query(Need to minimize the execution time). I need to know how 'Explain Plan' would help me. I know how to use Explain Plan command. I refer Plan_table table to see the details of the plan. Please guide me regarding which columns of the Plan_table should be considered while modifying the query for optimization. Some people say, 'Time' column should be considered, some say 'Bytes' etc. Some suggest on minimizing the full table scans, while some people say that I should minimize the total no. operations (less no. of rows should be displayed in Plan_table). As per an experienced friend of mine, full table scans should be reduced (for e.g. if there are 5 full table scans in the plan, then try to reduce them to less than 5. ). However, if I consider any full table scan operation in the plan_table, its shows value of 'time' column as only 1 which is very very less. Does this mean the full scan is actually taking very less time?? If yes, then this means full table scans are very fast in my case and no need to work on them. Some articles suggest that plan shown by 'Explain Plan' command is not necessarily followed while executing the query. So what should I look for then? How should I optimize the query and how will I come to know that it's optimized?? Please help!!...how fast is fast enough? -
Performance problem: Query explain plan changes in pl/sql vs. literal args
I have a complex query with 5+ table joins on large (million+ row) tables. In it's most simplified form, it's essentially
select * from largeTable large
join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
join...(other aux tables)
where large.pk_id between 123 and 456;
Its performance was excellent with literal arguments (1 sec per execution).
But, when I used pl/sql bind argument variables instead of 123 and 456 as literals, the explain plan changes drastically, and runs 10+ minutes.
Ex:
CREATE PROCEDURE runQuery(param1 INTEGER, param2 INTEGER){
CURSOR LT_CURSOR IS
select * from largeTable large
join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
join...(other aux tables)
where large.pk_id between param1 AND param2;
BEGIN
FOR aRecord IN LT_CURSOR
LOOP
(print timestamp...)
END LOOP;
END runQuery;
Rewriting the query 5 different ways was unfruitful. DB hints were also unfruitful in this particular case. LargeTable.pk_id was an indexed field as were all other join fields.
Solution:
Lacking other options, I wrote a literal query that concatenated the variable args. Open a cursor for the literal query.
Upside: It changed the explain plan to the only really fast option and performed at 1 second instead of 10mins.
Downside: Query not cached for future use. Perfectly fine for this query's purpose.
Other suggestions are welcome.AmandaSoosai wrote:
I have a complex query with 5+ table joins on large (million+ row) tables. In it's most simplified form, it's essentially
select * from largeTable large
join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
join...(other aux tables)
where large.pk_id between 123 and 456;
Its performance was excellent with literal arguments (1 sec per execution).
But, when I used pl/sql bind argument variables instead of 123 and 456 as literals, the explain plan changes drastically, and runs 10+ minutes.
Ex:
CREATE PROCEDURE runQuery(param1 INTEGER, param2 INTEGER){
CURSOR LT_CURSOR IS
select * from largeTable large
join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
join...(other aux tables)
where large.pk_id between param1 AND param2;
BEGIN
FOR aRecord IN LT_CURSOR
LOOP
(print timestamp...)
END LOOP;
END runQuery;
Rewriting the query 5 different ways was unfruitful. DB hints were also unfruitful in this particular case. LargeTable.pk_id was an indexed field as were all other join fields.
Solution:
Lacking other options, I wrote a literal query that concatenated the variable args. Open a cursor for the literal query.
Upside: It changed the explain plan to the only really fast option and performed at 1 second instead of 10mins.
Downside: Query not cached for future use. Perfectly fine for this query's purpose.
Other suggestions are welcome.Best wild guess based on what you've posted is a bind variable mismatch (your column is declared as a NUMBER data type and your bind variable is declared as a VARCHAR for example). Unless you have histograms on the columns in question ... which, if you're using bind variables is usually a really bad idea.
A basic illustration of my guess
http://blogs.oracle.com/optimizer/entry/how_do_i_get_sql_executed_from_an_application_to_uses_the_same_execution_plan_i_get_from_sqlplus -
How to improve the query performance or tune query from Explain Plan
Hi
The following is my explain plan for sql query. (The plan is generated by Toad v9.7). How to fix the query?
SELECT STATEMENT ALL_ROWSCost: 4,160 Bytes: 25,296 Cardinality: 204
8 NESTED LOOPS Cost: 3 Bytes: 54 Cardinality: 1
5 NESTED LOOPS Cost: 2 Bytes: 23 Cardinality: 1
2 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 13 Cardinality: 1
1 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
4 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 1 Bytes: 10 Cardinality: 1
3 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1
7 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 1 Bytes: 31 Cardinality: 1
6 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1
10 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
9 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
15 NESTED LOOPS Cost: 2 Bytes: 29 Cardinality: 1
12 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
14 TABLE ACCESS BY INDEX ROWID TABLE ONT.OE_ORDER_HEADERS_ALL Cost: 1 Bytes: 17 Cardinality: 1
13 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Cardinality: 1
21 FILTER
16 TABLE ACCESS FULL TABLE ONT.OE_TRANSACTION_TYPES_TL Cost: 2 Bytes: 1,127 Cardinality: 49
20 NESTED LOOPS Cost: 2 Bytes: 21 Cardinality: 1
18 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
17 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
19 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Bytes: 9 Cardinality: 1
23 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
22 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
45 NESTED LOOPS Cost: 4,160 Bytes: 25,296 Cardinality: 204
42 NESTED LOOPS Cost: 4,150 Bytes: 23,052 Cardinality: 204
38 NESTED LOOPS Cost: 4,140 Bytes: 19,992 Cardinality: 204
34 NESTED LOOPS Cost: 4,094 Bytes: 75,850 Cardinality: 925
30 NESTED LOOPS Cost: 3,909 Bytes: 210,843 Cardinality: 3,699
26 PARTITION LIST ALL Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
25 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_HEADERS Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
24 INDEX SKIP SCAN INDEX XLA.XLA_AE_HEADERS_N1 Cost: 264 Cardinality: 1,398,115 Partition #: 29 Partitions accessed #1 - #18
29 PARTITION LIST ITERATOR Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
28 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_LINES Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
27 INDEX RANGE SCAN INDEX (UNIQUE) XLA.XLA_AE_LINES_U1 Cost: 1 Cardinality: 1 Partition #: 32
33 PARTITION LIST ITERATOR Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
32 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_DISTRIBUTION_LINKS Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
31 INDEX RANGE SCAN INDEX XLA.XLA_DISTRIBUTION_LINKS_N3 Cost: 1 Cardinality: 1 Partition #: 35
37 PARTITION LIST SINGLE Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 38
36 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_EVENTS Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 39 Partitions accessed #2
35 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_EVENTS_U1 Cost: 1 Cardinality: 1 Partition #: 40 Partitions accessed #2
41 PARTITION LIST SINGLE Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 41
40 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_TRANSACTION_ENTITIES Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 42 Partitions accessed #2
39 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_TRANSACTION_ENTITIES_U1 Cost: 1 Cardinality: 1 Partition #: 43 Partitions accessed #2
44 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_CODE_COMBINATIONS Cost: 1 Bytes: 11 Cardinality: 1
43 INDEX UNIQUE SCAN INDEX (UNIQUE) GL.GL_CODE_COMBINATIONS_U1 Cost: 1 Cardinality: 1damorgan wrote:
Tuning is NOT about reducing the cost of i/o.
i/o is only one of many contributors to cost and only one of many contributors to waits.
Any time you would like to explore this further run this code:
SELECT 1 FROM dual
WHERE regexp_like(' ','^*[ ]*a');but not on a production box because you are going to experience an extreme tuning event with zero i/o.
And when I say "extreme" I mean "EXTREME!"
You've been warned.I think you just need a faster server.
SQL> set autotrace traceonly statistics
SQL> set timing on
SQL> select 1 from dual
2 where
3 regexp_like (' ','^*[ ]*a');
no rows selected
Elapsed: 00:00:00.00
Statistics
1 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
243 bytes sent via SQL*Net to client
349 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processedRepeated from an Oracle 10.2.0.x instance:
SQL> SELECT DISTINCT SID FROM V$MYSTAT;
SID
310
SQL> ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
Session altered.
SQL> select 1 from dual
2 where
3 regexp_like (' ','^*[ ]*a');The session is hung. Wait a little while and connect to the database using a different session:
COLUMN STAT_NAME FORMAT A35 TRU
SET PAGESIZE 200
SELECT
STAT_NAME,
VALUE
FROM
V$SESS_TIME_MODEL
WHERE
SID=310;
STAT_NAME VALUE
DB time 9247
DB CPU 9247
background elapsed time 0
background cpu time 0
sequence load elapsed time 0
parse time elapsed 6374
hard parse elapsed time 5997
sql execute elapsed time 2939
connection management call elapsed 1660
failed parse elapsed time 0
failed parse (out of shared memory) 0
hard parse (sharing criteria) elaps 0
hard parse (bind mismatch) elapsed 0
PL/SQL execution elapsed time 95
inbound PL/SQL rpc elapsed time 0
PL/SQL compilation elapsed time 0
Java execution elapsed time 0
repeated bind elapsed time 48
RMAN cpu time (backup/restore) 0Seems to be using a bit of time for the hard parse (hard parse elapsed time). Wait a little while, then re-execute the query:
STAT_NAME VALUE
DB time 9247
DB CPU 9247
background elapsed time 0
background cpu time 0
sequence load elapsed time 0
parse time elapsed 6374
hard parse elapsed time 5997
sql execute elapsed time 2939
connection management call elapsed 1660
failed parse elapsed time 0
failed parse (out of shared memory) 0
hard parse (sharing criteria) elaps 0
hard parse (bind mismatch) elapsed 0
PL/SQL execution elapsed time 95
inbound PL/SQL rpc elapsed time 0
PL/SQL compilation elapsed time 0
Java execution elapsed time 0
repeated bind elapsed time 48
RMAN cpu time (backup/restore) 0The session is not reporting additional CPU usage or parse time.
Let's check one of the session's statistics:
SELECT
SS.VALUE
FROM
V$SESSTAT SS,
V$STATNAME SN
WHERE
SN.NAME='consistent gets'
AND SN.STATISTIC#=SS.STATISTIC#
AND SS.SID=310;
VALUE
163Not many consistent gets after 20+ minutes.
Let's take a look at the plan:
SQL> SELECT SQL_ID,CHILD_NUMBER FROM V$SQL WHERE SQL_TEXT LIKE 'select 1 from du
al%';
SQL_ID CHILD_NUMBER
04mpgrzhsv72w 0
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('04mpgrzhsv72w',0,'TYPICAL'))
select 1 from dual where regexp_like (' ','^*[ ]*a')
NOTE: cannot fetch plan for SQL_ID: 04mpgrzhsv72w, CHILD_NUMBER: 0
Please verify value of SQL_ID and CHILD_NUMBER;
It could also be that the plan is no longer in cursor cache (check v$sql_p
lan)No plan...
Let's take a look at the 10053 trace file:
Registered qb: SEL$1 0x19157f38 (PARSER)
signature (): qb_name=SEL$1 nbfros=1 flg=0
fro(0): flg=4 objn=258 hint_alias="DUAL"@"SEL$1"
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM: Checking validity of predicate move-around in SEL$1 (#0).
CBQT: Validity checks failed for 7uqx4guu04x3g.
CVM: Considering view merge in query block SEL$1 (#0)
CBQT: Validity checks failed for 7uqx4guu04x3g.
Subquery Unnest
SU: Considering subquery unnesting in query block SEL$1 (#0)
Set-Join Conversion (SJC)
SJC: Considering set-join conversion in SEL$1 (#0).
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM: Checking validity of predicate move-around in SEL$1 (#0).
PM: PM bypassed: Outer query contains no views.
FPD: Considering simple filter push in SEL$1 (#0)
FPD: Current where clause predicates in SEL$1 (#0) :
REGEXP_LIKE (' ','^*[ ]*a')
kkogcp: try to generate transitive predicate from check constraints for SEL$1 (#0)
predicates with check contraints: REGEXP_LIKE (' ','^*[ ]*a')
after transitive predicate generation: REGEXP_LIKE (' ','^*[ ]*a')
finally: REGEXP_LIKE (' ','^*[ ]*a')
apadrv-start: call(in-use=592, alloc=16344), compile(in-use=37448, alloc=42256)
kkoqbc-start
: call(in-use=592, alloc=16344), compile(in-use=38336, alloc=42256)
kkoqbc-subheap (create addr=000000001915C238)Looks like the query never had a chance to start executing - it is still parsing after 20 minutes.
I am not sure that this is a good example - the query either executes very fast, or never has a chance to start executing. But, it might still make your point physical I/O is not always the problem when performance problems are experienced.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
Same query, same dataset, same ddl setup, but wildly different explain plan
Hello o fountains of oracle knowledge!
We have a problem that caused us a full stop when rolling out a new version of our system to a customer and a whole Sunday to boot.
The scenario is as follows:
1. An previous version database schema
2. The current version database schema
3. A migration script to migrate the old schema to the new
So we perform the following migration:
1. Export the previous version database schema
2. Import into a new schema called schema_old
3. Create a new schema called schema_new
4. Run migration script which creates objects, copies data, creates indexes etc etc in schema_new
The migration runs fine in all environments (development, test and production)
In our development and test environments performance is stellar, on the customer production server the performance is terrible.
This using the exact same export file (from the production environment) and performing the exact same steps with the exact same migration script.
Database version is 10.2.0.1.0 EE on all databases. OS is Microsoft Windows Server 2003 EE SP2 on all servers.
The system is not in any sense under a heavy load (we have tested with no other load than ourselves).
Looking at the explain plan for a query that is run frequently and does not use bind variables we see wildly different explain plans.
The explain plan cost on our development and test servers is estimated to *7* for this query and there are no full table scans.
On the production server the cost is *8433* and there are two full table scans of which one is on the largest table.
We have tried to run analyse on all objects with very little effect. The plan changed very slightly, but still includes the two full table scans on the problem server and the cost is still the same.
All tables and indexes are identical (including storage options), created from the same migration script.
I am currently at loss for where to look? What can be causing this? I assume this could be caused by some parameter that is set on the server, but I don't know what to look for.
I would be very grateful for any pointers.
Thanks,
HåkonThank you for your answer.
We collected statistics only after we determined that the production server where not behaving according to expectations.
In this case we used TOAD and the tool within to collect statistics for all objects. We used 'Analyze' and 'Compute Statistics' options.
I am not an expert, so sorry if this is too naive an approach.
Here is the query:SELECT count(0)
FROM score_result sr, web_scorecard sc, product p
WHERE sr.score_final_decision like 'VENT%'
AND sc.CREDIT_APPLICATION_ID = sr.CREDIT_APPLICATION_ID
AND sc.application_complete='Y'
AND p.product = sc.web_product
AND p.inactive_product = '2' ;I use this as an example, but the problem exists for virtually all queries.
The output from the 'good' server:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 1 | 39 | 7 (0)|
| 1 | SORT AGGREGATE | | 1 | 39 | |
| 2 | NESTED LOOPS | | 1 | 39 | 7 (0)|
| 3 | NESTED LOOPS | | 1 | 30 | 6 (0)|
| 4 | TABLE ACCESS BY INDEX ROWID| SCORE_RESULT | 1 | 17 | 4 (0)|
| 5 | INDEX RANGE SCAN | SR_FINAL_DECISION_IDX | 1 | | 3 (0)|
| 6 | TABLE ACCESS BY INDEX ROWID| WEB_SCORECARD | 1 | 13 | 2 (0)|
| 7 | INDEX UNIQUE SCAN | WEB_SCORECARD_PK | 1 | | 1 (0)|
| 8 | TABLE ACCESS BY INDEX ROWID | PRODUCT | 1 | 9 | 1 (0)|
| 9 | INDEX UNIQUE SCAN | PK_PRODUCT | 1 | | 0 (0)|
---------------------------------------------------------------------------------------------The output from the 'bad' server:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 1 | 32 | 8344 (3)|
| 1 | SORT AGGREGATE | | 1 | 32 | |
| 2 | HASH JOIN | | 10887 | 340K| 8344 (3)|
| 3 | TABLE ACCESS FULL | PRODUCT | 6 | 42 | 3 (0)|
| 4 | HASH JOIN | | 34381 | 839K| 8340 (3)|
| 5 | VIEW | index$_join$_001 | 34381 | 503K| 2193 (3)|
| 6 | HASH JOIN | | | | |
| 7 | INDEX RANGE SCAN | SR_FINAL_DECISION_IDX | 34381 | 503K| 280 (3)|
| 8 | INDEX FAST FULL SCAN| SCORE_RESULT_PK | 34381 | 503K| 1371 (2)|
| 9 | TABLE ACCESS FULL | WEB_SCORECARD | 489K| 4782K| 6137 (4)|
----------------------------------------------------------------------------------------I hope the formatting makes this readable.
Stats (from SQL Developer), good table:NUM_ROWS 489716
BLOCKS 27198
AVG_ROW_LEN 312
SAMPLE_SIZE 489716
LAST_ANALYZED 15.12.2009
LAST_ANALYZED_SINCE 15.12.2009Stats (from SQL Developer), bad table:
NUM_ROWS 489716
BLOCKS 27199
AVG_ROW_LEN 395
SAMPLE_SIZE 489716
LAST_ANALYZED 17.12.2009
LAST_ANALYZED_SINCE 17.12.2009I'm unsure what would cause the difference in average row length.
I could obviously try to tune our sql-statements to work on the server not behaving better, but I would rather understand why they are different and make sure that we can expect similar behaviour between environments.
Thank you again for trying to help me.
Håkon
Edited by: ergates on 17.des.2009 05:57
Edited by: ergates on 17.des.2009 06:02 -
How to change the explain plan for currently running query?
Hi All,
I am using Oracle enterprise 9i edition. I have a query which frames dynamically and running in the database. I noticed a table with 31147758 rows
in the query which has no indexes and taking more time to process. I tried to create an INdex on that table. I know the query is already running with a FULL table scan. Is it possible to change the explain plan for the current running query to consider the INDEX?
[code]
SELECT /*+ USE_HASH (c,e,b,a) */
d.att_fcc extrt_prod_dim_id,
d.att_fcc compr_prod_dim_id,
a.glbl_uniq_id glbl_uniq_id,
to_date(c.dit_code,'RRRRMMDD')STRT_DT,
(to_date(c.dit_code,'RRRRMMDD')+150)END_DT,
a.pat_nbr pat_id,
a.rxer_id rxer_id,
e.rxer_geog_id rxer_geog_id,
a.pharmy_id pharmy_id,
a.pscr_pack_id pscr_pack_id,
a.dspnsd_pack_id dspnsd_pack_id,
DENSE_RANK () OVER (PARTITION BY a.pat_nbr ORDER BY c.dit_code) daterank,
COUNT( DISTINCT d.att_fcc ) OVER (PARTITION BY a.pat_nbr, c.dit_code) event_cnt
DENSE_RANK () OVER (PARTITION BY a.pat_nbr,
d.att_fcc
ORDER BY c.dit_code) prodrank,
DENSE_RANK () OVER (PARTITION BY a.pat_nbr,
d.att_fcc
ORDER BY c.dit_code DESC) stoprank
FROM
pd_dimitems c,
pd_pack_attribs d ,
lrx_tmp_rxer_geog e,
lrx_tmp_pat_daterank p,
lrx_tmp_valid_fact_link a
WHERE c.dit_id = a.tm_id
AND e.rxer_id = a.rxer_id
AND a.glbl_uniq_id = p.glbl_uniq_id
AND p.daterank > 1
AND a.pscr_pack_id = d.att_dit_id
[/code]
The table lrx_tmp_pat_daterank is having that 31147758 rows. So I am wondering how to make the query to use the newly created index on the table?Why do you think using Indexes will improve the performance of the query? How many rows this query is returning? Optimizer might chose a Full table scan when it finds out that Index plan might not be useful. Why are you using /*+ USE_HASH (c,e,b,a) */ hint? This Hint will force oracle to use Full table scan instead of using the index. Try removing it and see if the plan changes.
Regards, -
1. How to create an explain plan with rowsource statistics for a complex query that include multiple table joins ?
When multiple tables are involved , and the actual number of rows returned is more than what the explain plan tells. How can I find out what change is needed in the stat plan ?
2. Does rowsource statistics gives some kind of understanding of Extended stats ?You can get Row Source Statistics only *after* the SQL has been executed. An Explain Plan midway cannot give you row source statistics.
To get row source statistics either set STATISTICS_LEVEL='ALL' in the session that executes theSQL OR use the Hint "gather_plan_statistics" in the SQL being executed.
Then use dbms_xplan.display_cursor
Hemant K Chitale -
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; -
Explain plan for same query in three databases
Hi,
We have three databases dev, uat and test, all have same init parameters and almost same data. We are running a query which runs long on dev and on uat and test it runs very fast, the explain plan on uat and test shows a cost of around 4000 but on dev the cost is 20000. Statistics were collected on three instances 2 days ago and the objects are also same.
My question is what else should I look for this optimizer behaviour? the database version is 10.2.0.3.
Please help.
Thanks
Clinuser627471 wrote:
Hi,
We have three databases dev, uat and test, all have same init parameters and almost same data. We are running a query which runs long on dev and on uat and test it runs very fast, the explain plan on uat and test shows a cost of around 4000 but on dev the cost is 20000. Statistics were collected on three instances 2 days ago and the objects are also same.
My question is what else should I look for this optimizer behaviour? the database version is 10.2.0.3.
Please help.
Thanks
Clinpost both EXPLAIN PLAN here -
Query Performance and reading an Explain Plan
Hi,
Below I have posted a query that is running slowly for me - upwards of 10 minutes which I would not expect. I have also supplied the explain plan. I'm fairly new to explain plans and not sure what the danger signs are that I should be looking out for.
I have added indexes to these tables, a lot of which are used in the JOIN and so I expected this to be quicker.
Any help or pointers in the right direction would be very much appreciated -
SELECT a.lot_id, a.route, a.route_rev
FROM wlos_owner.tbl_current_lot_status_dim a, wlos_owner.tbl_last_seq_num b, wlos_owner.tbl_hist_metrics_at_op_lkp c
WHERE a.fw_ver = '2'
AND a.route = b.route
AND a.route_rev = b.route_rev
AND a.fw_ver = b.fw_ver
AND a.route = c.route
AND a.route_rev = c.route_rev
AND a.fw_ver = c.fw_ver
AND a.prod = c.prod
AND a.lot_type = c.lot_type
AND c.step_seq_num >= a.step_seq_num
PLAN_TABLE_OUTPUT
Plan hash value: 2447083104
| Id | Operation | Name | Rows | Bytes | Cost
(%CPU)| Time |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | 333 | 33633 | 1347
(8)| 00:00:17 |
|* 1 | HASH JOIN | | 333 | 33633 | 1347
(8)| 00:00:17 |
|* 2 | HASH JOIN | | 561 | 46002 | 1333
(7)| 00:00:17 |
|* 3 | TABLE ACCESS FULL| TBL_CURRENT_LOT_STATUS_DIM | 11782 | 517K| 203
(5)| 00:00:03 |
PLAN_TABLE_OUTPUT
|* 4 | TABLE ACCESS FULL| TBL_HIST_METRICS_AT_OP_LKP | 178K| 6455K| 1120
(7)| 00:00:14 |
|* 5 | TABLE ACCESS FULL | TBL_LAST_SEQ_NUM | 8301 | 154K| 13
(16)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
1 - access("A"."ROUTE"="B"."ROUTE" AND "A"."ROUTE_REV"="B"."ROUTE_REV" AND
"A"."FW_VER"=TO_NUMBER("B"."FW_VER"))
2 - access("A"."ROUTE"="C"."ROUTE" AND "A"."ROUTE_REV"="C"."ROUTE_REV" AND
"A"."FW_VER"="C"."FW_VER" AND "A"."PROD"="C"."PROD" AND "A"."LOT_T
YPE"="C"."LOT_TYPE")
filter("C"."STEP_SEQ_NUM">="A"."STEP_SEQ_NUM")
3 - filter("A"."FW_VER"=2)
PLAN_TABLE_OUTPUT
4 - filter("C"."FW_VER"=2)
5 - filter(TO_NUMBER("B"."FW_VER")=2)
24 rows selected.Guys thank you for your help.
I changed the type of the offending column and the plan looks a lot better and results seem a lot quicker.
However I have added to my SELECT, quite substantially, and have a new explain plan.
There are two sections in particular that have a high cost and I was wondering if you seen anything inherently wrong or can explain more fully what the PLAN_TABLE_OUTPUT descriptions are telling me - in particular
INDEX FULL SCAN
PLAN_TABLE_OUTPUT
Plan hash value: 3665357134
| Id | Operation | Name | Rows
| Bytes | Cost (%CPU)| Time |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | |
4 | 316 | 52 (2)| 00:00:01 |
|* 1 | VIEW | |
4 | 316 | 52 (2)| 00:00:01 |
| 2 | WINDOW SORT | |
4 | 600 | 52 (2)| 00:00:01 |
|* 3 | TABLE ACCESS BY INDEX ROWID | TBL_HIST_METRICS_AT_OP_LKP |
1 | 71 | 1 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
| 4 | NESTED LOOPS | |
4 | 600 | 51 (0)| 00:00:01 |
| 5 | NESTED LOOPS | | 7
5 | 5925 | 32 (0)| 00:00:01 |
|* 6 | INDEX FULL SCAN | UNIQUE_LAST_SEQ | 8
9 | 2492 | 10 (0)| 00:00:01 |
| 7 | TABLE ACCESS BY INDEX ROWID| TBL_CURRENT_LOT_STATUS_DIM |
PLAN_TABLE_OUTPUT
1 | 51 | 1 (0)| 00:00:01 |
|* 8 | INDEX RANGE SCAN | TBL_CUR_LOT_STATUS_DIM_IDX1 |
1 | | 1 (0)| 00:00:01 |
|* 9 | INDEX RANGE SCAN | TBL_HIST_METRIC_AT_OP_LKP_IDX1 | 2
9 | | 1 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
1 - filter("SEQ"=1)
3 - filter("C"."FW_VER"=2 AND "A"."PROD"="C"."PROD" AND "A"."LOT_TYPE"="C"."L
OT_TYPE" AND
"C"."STEP_SEQ_NUM">="A"."STEP_SEQ_NUM")
6 - access("B"."FW_VER"=2)
filter("B"."FW_VER"=2)
PLAN_TABLE_OUTPUT
8 - access("A"."ROUTE"="B"."ROUTE" AND "A"."ROUTE_REV"="B"."ROUTE_REV" AND "A
"."FW_VER"=2)
9 - access("A"."ROUTE"="C"."ROUTE" AND "A"."ROUTE_REV"="C"."ROUTE_REV") -
How i can obtain explain plan without run the query
Hello,
i need to know the result of explain of a query without run the query, it's this possible?
Thanks and best regards.explain plan for <your query>;
select * from table(dbms_xplan.display);Regards,
Rob. -
Query with diff. explain plans
Hi,
Our query returns different execution plans in Prod and non-prod. It is slow in PROD. The data size is the same in both DBs and stats are gathered at 50% estimate for both schemas:
Prod (slow) explain plan:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 852 | 33 (4)| 00:00:01 |
|* 1 | FILTER | | | | | |
| 2 | HASH GROUP BY | | 1 | 852 | 33 (4)| 00:00:01 |
| 3 | NESTED LOOPS | | 1 | 852 | 32 (0)| 00:00:01 |
| 4 | NESTED LOOPS | | 1 | 802 | 31 (0)| 00:00:01 |
| 5 | NESTED LOOPS OUTER | | 1 | 785 | 30 (0)| 00:00:01 |
| 6 | NESTED LOOPS OUTER | | 1 | 742 | 29 (0)| 00:00:01 |
| 7 | NESTED LOOPS | | 1 | 732 | 29 (0)| 00:00:01 |
| 8 | NESTED LOOPS | | 1 | 678 | 26 (0)| 00:00:01 |
| 9 | NESTED LOOPS | | 1 | 666 | 26 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 623 | 25 (0)| 00:00:01 |
| 11 | NESTED LOOPS | | 1 | 580 | 24 (0)| 00:00:01 |
| 12 | NESTED LOOPS | | 1 | 576 | 24 (0)| 00:00:01 |
| 13 | NESTED LOOPS | | 2 | 1076 | 13 (0)| 00:00:01 |
| 14 | NESTED LOOPS | | 2 | 1040 | 13 (0)| 00:00:01 |
| 15 | NESTED LOOPS | | 2 | 1028 | 13 (0)| 00:00:01 |
| 16 | NESTED LOOPS | | 2 | 996 | 13 (0)| 00:00:01 |
| 17 | NESTED LOOPS | | 2 | 988 | 13 (0)| 00:00:01 |
| 18 | NESTED LOOPS | | 2 | 954 | 13 (0)| 00:00:01 |
| 19 | NESTED LOOPS | | 2 | 944 | 13 (0)| 00:00:01 |
| 20 | NESTED LOOPS | | 2 | 920 | 13 (0)| 00:00:01 |
| 21 | NESTED LOOPS | | 2 | 912 | 13 (0)| 00:00:01 |
| 22 | NESTED LOOPS | | 2 | 826 | 11 (0)| 00:00:01 |
| 23 | NESTED LOOPS | | 1 | 370 | 9 (0)| 00:00:01 |
| 24 | NESTED LOOPS | | 1 | 306 | 8 (0)| 00:00:01 |
| 25 | NESTED LOOPS | | 1 | 263 | 7 (0)| 00:00:01 |
| 26 | NESTED LOOPS | | 1 | 220 | 6 (0)| 00:00:01 |
| 27 | NESTED LOOPS | | 1 | 177 | 5 (0)| 00:00:01 |
| 28 | NESTED LOOPS | | 1 | 129 | 4 (0)| 00:00:01 |
| 29 | NESTED LOOPS | | 1 | 86 | 3 (0)| 00:00:01 |
| 30 | TABLE ACCESS BY INDEX ROWID| SYMMETADATA | 1 | 43 | 2 (0)| 00:00:01 |
|* 31 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 1 (0)| 00:00:01 |
| 32 | TABLE ACCESS BY INDEX ROWID| SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 33 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 34 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 35 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 36 | TABLE ACCESS BY INDEX ROWID | TPRODUCT | 1 | 48 | 1 (0)| 00:00:01 |
|* 37 | INDEX UNIQUE SCAN | TPRODUCT_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 38 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 39 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 40 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 41 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 42 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 43 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 44 | TABLE ACCESS BY INDEX ROWID | TPRODUCT | 1 | 64 | 1 (0)| 00:00:01 |
|* 45 | INDEX UNIQUE SCAN | TPRODUCT_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 46 | INLIST ITERATOR | | | | | |
| 47 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 2 | 86 | 2 (0)| 00:00:01 |
|* 48 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 2 | | 1 (0)| 00:00:01 |
| 49 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 50 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
|* 51 | INDEX UNIQUE SCAN | SYMUSERCOUNT_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 52 | INDEX UNIQUE SCAN | SYMUSERCOUNT_PK | 1 | 12 | 0 (0)| 00:00:01 |
|* 53 | INDEX UNIQUE SCAN | SYMSKUTYPE_PK | 1 | 5 | 0 (0)| 00:00:01 |
|* 54 | INDEX UNIQUE SCAN | SYMSKUTYPE_PK | 1 | 17 | 0 (0)| 00:00:01 |
|* 55 | INDEX UNIQUE SCAN | SYMSKULANGUAGE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 56 | INDEX UNIQUE SCAN | SYMSKULANGUAGE_PK | 1 | 16 | 0 (0)| 00:00:01 |
|* 57 | INDEX UNIQUE SCAN | SYMVENDOR_PK | 1 | 6 | 0 (0)| 00:00:01 |
|* 58 | INDEX UNIQUE SCAN | SYMVENDOR_PK | 1 | 18 | 0 (0)| 00:00:01 |
| 59 | TABLE ACCESS BY INDEX ROWID | SYMPRODUCTSKU | 1 | 38 | 6 (0)| 00:00:01 |
|* 60 | INDEX RANGE SCAN | I_PSKU_MERCH_LOOKUP | 1 | | 5 (0)| 00:00:01 |
|* 61 | INDEX UNIQUE SCAN | SYMMEDIATYPE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 62 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 63 | INDEX UNIQUE SCAN | SYMMETADATA_PK | 1 | | 0 (0)| 00:00:01 |
| 64 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 65 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
|* 66 | INDEX UNIQUE SCAN | SYMMEDIATYPE_PK | 1 | 12 | 0 (0)| 00:00:01 |
| 67 | TABLE ACCESS BY INDEX ROWID | SYMPRODUCTSKU | 1 | 54 | 3 (0)| 00:00:01 |
|* 68 | INDEX RANGE SCAN | I_PSKU_MERCH_LOOKUP | 1 | | 2 (0)| 00:00:01 |
|* 69 | INDEX UNIQUE SCAN | SYMPCCOUNT_PK | 1 | 10 | 0 (0)| 00:00:01 |
| 70 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 43 | 1 (0)| 00:00:01 |
|* 71 | INDEX UNIQUE SCAN | SYMMETADATA_PK | 1 | | 0 (0)| 00:00:01 |
|* 72 | TABLE ACCESS BY INDEX ROWID | TPRODUCTSKU | 1 | 17 | 1 (0)| 00:00:01 |
|* 73 | INDEX UNIQUE SCAN | TPRODUCTSKU_PK | 1 | | 0 (0)| 00:00:01 |
|* 74 | TABLE ACCESS BY INDEX ROWID | TPRODUCTSKU | 1 | 50 | 1 (0)| 00:00:01 |
|* 75 | INDEX UNIQUE SCAN | TPRODUCTSKU_PK | 1 | | 0 (0)| 00:00:01 |
Non Prod (Fast) Plan:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 383 | 28 (0)| 00:00:01 |
|* 1 | FILTER | | | | | |
| 2 | NESTED LOOPS | | 1 | 383 | 17 (0)| 00:00:01 |
| 3 | NESTED LOOPS OUTER | | 1 | 350 | 16 (0)| 00:00:01 |
| 4 | NESTED LOOPS | | 1 | 308 | 15 (0)| 00:00:01 |
| 5 | NESTED LOOPS | | 1 | 266 | 14 (0)| 00:00:01 |
| 6 | NESTED LOOPS OUTER | | 1 | 262 | 14 (0)| 00:00:01 |
| 7 | NESTED LOOPS | | 1 | 258 | 14 (0)| 00:00:01 |
| 8 | NESTED LOOPS | | 2 | 438 | 7 (0)| 00:00:01 |
| 9 | NESTED LOOPS | | 2 | 428 | 7 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 2 | 420 | 7 (0)| 00:00:01 |
| 11 | NESTED LOOPS | | 2 | 410 | 7 (0)| 00:00:01 |
| 12 | NESTED LOOPS | | 2 | 402 | 7 (0)| 00:00:01 |
| 13 | NESTED LOOPS | | 1 | 159 | 5 (0)| 00:00:01 |
| 14 | NESTED LOOPS | | 1 | 126 | 4 (0)| 00:00:01 |
| 15 | NESTED LOOPS | | 1 | 84 | 3 (0)| 00:00:01 |
| 16 | TABLE ACCESS BY INDEX ROWID| SYMMETADATA | 1 | 42 | 2 (0)| 00:00:01 |
|* 17 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 1 (0)| 00:00:01 |
| 18 | TABLE ACCESS BY INDEX ROWID| SYMMETADATA | 1 | 42 | 1 (0)| 00:00:01 |
|* 19 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 20 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 42 | 1 (0)| 00:00:01 |
|* 21 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 22 | TABLE ACCESS BY INDEX ROWID | TPRODUCT | 1 | 33 | 1 (0)| 00:00:01 |
|* 23 | INDEX UNIQUE SCAN | TPRODUCT_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 24 | INLIST ITERATOR | | | | | |
| 25 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 2 | 84 | 2 (0)| 00:00:01 |
|* 26 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 2 | | 1 (0)| 00:00:01 |
|* 27 | INDEX UNIQUE SCAN | SYMUSERCOUNT_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 28 | INDEX UNIQUE SCAN | SYMSKUTYPE_PK | 1 | 5 | 0 (0)| 00:00:01 |
|* 29 | INDEX UNIQUE SCAN | SYMSKULANGUAGE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 30 | INDEX UNIQUE SCAN | SYMVENDOR_PK | 1 | 5 | 0 (0)| 00:00:01 |
| 31 | TABLE ACCESS BY INDEX ROWID | SYMPRODUCTSKU | 1 | 39 | 4 (0)| 00:00:01 |
|* 32 | INDEX RANGE SCAN | I_PSKU_MERCH_LOOKUP | 1 | | 3 (0)| 00:00:01 |
|* 33 | INDEX UNIQUE SCAN | SYMPCCOUNT_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 34 | INDEX UNIQUE SCAN | SYMMEDIATYPE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 35 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 42 | 1 (0)| 00:00:01 |
|* 36 | INDEX UNIQUE SCAN | SYMMETADATA_PK | 1 | | 0 (0)| 00:00:01 |
| 37 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 42 | 1 (0)| 00:00:01 |
|* 38 | INDEX UNIQUE SCAN | SYMMETADATA_PK | 1 | | 0 (0)| 00:00:01 |
|* 39 | TABLE ACCESS BY INDEX ROWID | TPRODUCTSKU | 1 | 33 | 1 (0)| 00:00:01 |
|* 40 | INDEX UNIQUE SCAN | TPRODUCTSKU_PK | 1 | | 0 (0)| 00:00:01 |
| 41 | SORT AGGREGATE | | 1 | 252 | | |
| 42 | NESTED LOOPS | | 1 | 252 | 11 (0)| 00:00:01 |
| 43 | NESTED LOOPS | | 1 | 240 | 10 (0)| 00:00:01 |
| 44 | NESTED LOOPS | | 1 | 205 | 7 (0)| 00:00:01 |
| 45 | NESTED LOOPS | | 1 | 200 | 7 (0)| 00:00:01 |
| 46 | NESTED LOOPS | | 1 | 196 | 7 (0)| 00:00:01 |
| 47 | NESTED LOOPS | | 1 | 191 | 7 (0)| 00:00:01 |
| 48 | NESTED LOOPS | | 1 | 187 | 7 (0)| 00:00:01 |
| 49 | NESTED LOOPS | | 1 | 183 | 7 (0)| 00:00:01 |
| 50 | NESTED LOOPS | | 1 | 150 | 6 (0)| 00:00:01 |
| 51 | NESTED LOOPS | | 1 | 120 | 5 (0)| 00:00:01 |
| 52 | NESTED LOOPS | | 1 | 90 | 4 (0)| 00:00:01 |
| 53 | NESTED LOOPS | | 1 | 60 | 3 (0)| 00:00:01 |
| 54 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 30 | 2 (0)| 00:00:01 |
|* 55 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 1 (0)| 00:00:01 |
| 56 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 30 | 1 (0)| 00:00:01 |
|* 57 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 58 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 30 | 1 (0)| 00:00:01 |
|* 59 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 60 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 30 | 1 (0)| 00:00:01 |
|* 61 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 62 | TABLE ACCESS BY INDEX ROWID | SYMMETADATA | 1 | 30 | 1 (0)| 00:00:01 |
|* 63 | INDEX UNIQUE SCAN | SYMMETADATA_UNIQUE | 1 | | 0 (0)| 00:00:01 |
| 64 | TABLE ACCESS BY INDEX ROWID | TPRODUCT | 1 | 33 | 1 (0)| 00:00:01 |
|* 65 | INDEX UNIQUE SCAN | TPRODUCT_UNIQUE | 1 | | 0 (0)| 00:00:01 |
|* 66 | INDEX UNIQUE SCAN | SYMUSERCOUNT_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 67 | INDEX UNIQUE SCAN | SYMMEDIATYPE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 68 | INDEX UNIQUE SCAN | SYMSKUTYPE_PK | 1 | 5 | 0 (0)| 00:00:01 |
|* 69 | INDEX UNIQUE SCAN | SYMSKULANGUAGE_PK | 1 | 4 | 0 (0)| 00:00:01 |
|* 70 | INDEX UNIQUE SCAN | SYMVENDOR_PK | 1 | 5 | 0 (0)| 00:00:01 |
| 71 | TABLE ACCESS BY INDEX ROWID | SYMPRODUCTSKU | 1 | 35 | 3 (0)| 00:00:01 |
|* 72 | INDEX RANGE SCAN | I_PSKU_MERCH_LOOKUP | 1 | | 2 (0)| 00:00:01 |
|* 73 | TABLE ACCESS BY INDEX ROWID | TPRODUCTSKU | 1 | 12 | 1 (0)| 00:00:01 |
|* 74 | INDEX UNIQUE SCAN | TPRODUCTSKU_PK | 1 | | 0 (0)| 00:00:01 |
Database version is 10.2.0.4. Can anyone help me understand what else to be looking for to make it work faster?Please see the following threads for the ideal information required:
How to post a sql tuning request:
HOW TO: Post a SQL statement tuning request - template posting
When your query takes too long:
When your query takes too long ... -
Same query is taking different times in two databses.
Both dababases are similar being refreshed from one.
Below are the the explain plan from both queries.
Can anything be conclusive from this information.
Second explain plan is for a faster execution.
SELECT STATEMENT ALL_ROWSCost: 245,393
18 PX COORDINATOR
17 PX SEND QC (RANDOM) PARALLEL_TO_SERIAL SYS.:TQ10003 Cost: 245,393 Bytes: 735,679,824 Cardinality: 8,359,998
16 HASH GROUP BY PARALLEL_COMBINED_WITH_PARENT Cost: 245,393 Bytes: 735,679,824 Cardinality: 8,359,998
15 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 198,164 Bytes: 735,679,824 Cardinality: 8,359,998
14 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10002 Cost: 198,164 Bytes: 735,679,824 Cardinality: 8,359,998
13 HASH JOIN PARALLEL_COMBINED_WITH_PARENT Cost: 198,164 Bytes: 735,679,824 Cardinality: 8,359,998
4 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD
3 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 15 Bytes: 129,220 Cardinality: 2,485
2 PX SEND BROADCAST PARALLEL_FROM_SERIAL SYS.:TQ10000 Cost: 15 Bytes: 129,220 Cardinality: 2,485
1 TABLE ACCESS FULL TABLE myschema.team Cost: 15 Bytes: 129,220 Cardinality: 2,485
12 TABLE ACCESS BY LOCAL INDEX ROWID TABLE PARALLEL_COMBINED_WITH_PARENT myschema.mytable Cost: 18,117 Bytes: 4,777,136 Cardinality: 183,736
11 NESTED LOOPS PARALLEL_COMBINED_WITH_PARENT Cost: 198,125 Bytes: 300,959,928 Cardinality: 8,359,998
8 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD
7 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT
6 PX SEND BROADCAST PARALLEL_FROM_SERIAL SYS.:TQ10001
5 TABLE ACCESS FULL TABLE myschema.dim Cost: 12 Bytes: 450 Cardinality: 45
10 PX PARTITION RANGE ITERATOR PARALLEL_COMBINED_WITH_CHILD Cost: 38 Cardinality: 183,736 Partition #: 17
9 INDEX RANGE SCAN INDEX PARALLEL_COMBINED_WITH_PARENT myschema.IDX_TDATE_DC_FLAG Cost: 38 Cardinality: 183,736 Partition #: 17
SELECT STATEMENT CHOOSECost: 2,830
14 PX COORDINATOR
13 PX SEND QC (RANDOM) PARALLEL_TO_SERIAL SYS.:TQ10003 Cost: 2,830 Bytes: 21,327,392 Cardinality: 288,208
12 HASH GROUP BY PARALLEL_COMBINED_WITH_PARENT Cost: 2,830 Bytes: 21,327,392 Cardinality: 288,208
11 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 2,828 Bytes: 21,327,392 Cardinality: 288,208
10 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10002 Cost: 2,828 Bytes: 21,327,392 Cardinality: 288,208
9 HASH JOIN BUFFERED PARALLEL_COMBINED_WITH_PARENT Cost: 2,828 Bytes: 21,327,392 Cardinality: 288,208
4 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD
3 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 19 Bytes: 129,272 Cardinality: 2,486
2 PX SEND HASH PARALLEL_FROM_SERIAL SYS.:TQ10000 Cost: 19 Bytes: 129,272 Cardinality: 2,486
1 TABLE ACCESS FULL TABLE myschema.team Cost: 19 Bytes: 129,272 Cardinality: 2,486
8 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208
7 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10001 Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208
6 PX BLOCK ITERATOR PARALLEL_COMBINED_WITH_CHILD Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208 Partition #: 13 Partitions accessed #1 - #5
5 MAT_VIEW REWRITE ACCESS FULL MAT_VIEW REWRITE PARALLEL_COMBINED_WITH_PARENT myschema.matv_2 Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208 Partition #: 13 Partitions accessed
Edited by: user610910 on Feb 13, 2009 5:12 AMSELECT STATEMENT CHOOSE Cost: 2,830
14 PX COORDINATOR
13 PX SEND QC (RANDOM) PARALLEL_TO_SERIAL SYS.:TQ10003 Cost: 2,830 Bytes: 21,327,392 Cardinality: 288,208
12 HASH GROUP BY PARALLEL_COMBINED_WITH_PARENT Cost: 2,830 Bytes: 21,327,392 Cardinality: 288,208
11 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 2,828 Bytes: 21,327,392 Cardinality: 288,208
10 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10002 Cost: 2,828 Bytes: 21,327,392 Cardinality: 288,208
9 HASH JOIN BUFFERED PARALLEL_COMBINED_WITH_PARENT Cost: 2,828 Bytes: 21,327,392 Cardinality: 288,208
4 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD
3 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 19 Bytes: 129,272 Cardinality: 2,486
2 PX SEND HASH PARALLEL_FROM_SERIAL SYS.:TQ10000 Cost: 19 Bytes: 129,272 Cardinality: 2,486
1 TABLE ACCESS FULL TABLE MYSCHEMA.TEAM Cost: 19 Bytes: 129,272 Cardinality: 2,486
8 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208
7 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10001 Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208
6 PX BLOCK ITERATOR PARALLEL_COMBINED_WITH_CHILD Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208 Partition #: 13 Partitions accessed #1 - #5
5 MAT_VIEW REWRITE ACCESS FULL MAT_VIEW REWRITE PARALLEL_COMBINED_WITH_PARENT MYSCHEMA.MATVW Cost: 2,808 Bytes: 6,340,576 Cardinality: 288,208 Partition #: 13 Partitions accessed #1 - #5
SELECT STATEMENT ALL_ROWSCost: 245,393
18 PX COORDINATOR
17 PX SEND QC (RANDOM) PARALLEL_TO_SERIAL SYS.:TQ10003 Cost: 245,393 Bytes: 735,679,824 Cardinality: 8,359,998
16 HASH GROUP BY PARALLEL_COMBINED_WITH_PARENT Cost: 245,393 Bytes: 735,679,824 Cardinality: 8,359,998
15 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 198,164 Bytes: 735,679,824 Cardinality: 8,359,998
14 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10002 Cost: 198,164 Bytes: 735,679,824 Cardinality: 8,359,998
13 HASH JOIN PARALLEL_COMBINED_WITH_PARENT Cost: 198,164 Bytes: 735,679,824 Cardinality: 8,359,998
4 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD
3 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 15 Bytes: 129,220 Cardinality: 2,485
2 PX SEND BROADCAST PARALLEL_FROM_SERIAL SYS.:TQ10000 Cost: 15 Bytes: 129,220 Cardinality: 2,485
1 TABLE ACCESS FULL TABLE MYSCHEMA.TEAM Cost: 15 Bytes: 129,220 Cardinality: 2,485
12 TABLE ACCESS BY LOCAL INDEX ROWID TABLE PARALLEL_COMBINED_WITH_PARENT MYSCHEMA.MY_TABLE Cost: 18,117 Bytes: 4,777,136 Cardinality: 183,736
11 NESTED LOOPS PARALLEL_COMBINED_WITH_PARENT Cost: 198,125 Bytes: 300,959,928 Cardinality: 8,359,998
8 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD
7 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT
6 PX SEND BROADCAST PARALLEL_FROM_SERIAL SYS.:TQ10001
5 TABLE ACCESS FULL TABLE MYSCHEMA.DIM Cost: 12 Bytes: 450 Cardinality: 45
10 PX PARTITION RANGE ITERATOR PARALLEL_COMBINED_WITH_CHILD Cost: 38 Cardinality: 183,736 Partition #: 17
9 INDEX RANGE SCAN INDEX PARALLEL_COMBINED_WITH_PARENT MYSCHEMA.MY_IDX Cost: 38 Cardinality: 183,736 Partition #: 17 I think this one looks better.
Maybe you are looking for
-
Random Pinwheeling (Beach Ball) after upgrade to 10.6.4
Everything was fine on 10.6.3. After System Update to 10.6.4, my MacPro takes 5 minutes to boot and launching apps takes 10 times longer (e.g. FCP 6 normally opens in 20 seconds but now takes over 2 minutes). Everything is slowed down from surfing th
-
An unknown error occurred (-50)
There was an a Problem downloading "A 1.86 GB Movie File" An unknown error occurred (-50) Please check that the connection to the network is active and try again. The Download is stuck at 800.1 MB of 1.86 GB. I have done the asked troubleshooting b
-
Image is not displayed after upload
Hello, I have imported an application from oracle APEX 3.0 10g in my express edition APEX 3.0 . In this application you can upload pictures in the database and afterwards show them in a report. in 10g everything works well. In my XE the pictures are
-
Agent running but host unavailable in grid control
hi, well yet another question, am having a bad day with grid control. I have pushed an agent out to server xxx and the agent is now monitored through grid control however, the host remains unavailable. I have done agentca -d and -f, the agent is secu
-
How do I close the right side message view in mail
how do I close the right side message view in mail