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
AD

Here 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

Similar Messages

Is there any tool to analyze explain plan and gives the report

Hi All,
Is there any tool/scripts to analyze explain plan from plan_table and gives the output report
Thanks,
Sankar

Hi Jaffar,
Thank you!!!
The below query will generate the execution tree:
SELECT OPERATION,
     OPTIONS OPTIONS,
DECODE(TO_CHAR(ID),'0','---',OBJECT_NAME) OBJECT_NAME,
     (ID ||'-'|| NVL(PARENT_ID,0) ||'-'|| NVL(POSITION,0) ) "ID**PARENT_ID**EXECUTION_STEP",
     SUBSTR(OPTIMIZER,1,8) OPT
FROM PLAN_TABLE
START WITH ID = 0
AND STATEMENT_ID = 'Q1'
CONNECT BY PRIOR ID = PARENT_ID
AND STATEMENT_ID = 'Q1'
Thanks,
Sankar

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

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.

Looking for a book or link to understand indexes stats an explain plan

Please,
Where could I find a good book or link to leran more about indexes statistics:
My Concerns are:
How could I know indexes in the database that are most used,less used and used at all in order to get rid of the last one?
A book or link to fully undertstand how to analyze explain plan give some advices from that.
Thank a lot for your coperation

There is any link where I can find how to analyze explain plan output?Again, the manuals are usually a good place to start:
http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm#g42231

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åkon

Thank 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

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 different for same query

Hi all,
I have a query, which basically selects some columns from a remote database view. The query is as follows:
select * from tab1@remotedb, tab2@remotedb
where tab1.cash_id = tab2.id
and tab1.date = '01-JAN-2003'
and tab2.country_code = 'GB';
Now, i am working on two environments, one is production and other is development. Production environment has following specification:
1. Remotedb = Oracle9i, Linux OS
2. Database on which query is running = Oracle10g, Linux OS
Development environment has following specification:
1. Remotedb = Oracle10g, Windows OS
2. Database on which query is running = Oracle10g, Linux OS
Both databases in development and production environments are on different machines.
when i execute the above query on production, i see full table scans on both tables in execution plan(TOAD), but when i execute the query in development, i see that both remote database tables are using index.
Why am i getting different execution plans on both databases? is there is any difference of user rights/priviliges or there is a difference of statistics on both databases. I have checked the statistics for both tables on Production and Development databases, they are updated.
This issue is creating a performance disaster in our Production system. Any kind of help or knowledge sharing is appreciated.
Thank you and Best Regards.

We ran into a similar situation yesterday morning, though our implementation was easier than yours. Different plans in development and production though both systems were 10gR2 at the time. Production was doing a Merge Join Cartesian (!) instead of nested loop joins. Our DBA figured out that the production stats had been locked for some tables preventing stat refresh; she unlocked them and re-analyzed so which fixed our problem.
Of some interest was discovering that I got different execution plans from the same UPDATE via EXPLAIN PLAN and SQL*PLUS AUTOTRACE in development. Issue appears to have been bind peeking. Converting bind variables to constants yielded the AUTOTRACE plan, as did turning bind peeking off while using the bind variables. CURSOR_SHARING was set to EXACT too.
Message was edited by:
riedelme

General queries regarding explain plan and query

Hello Oracle buddies,
I have few badly formed queries with plenty of nested loops, merge join cartesian , plenty of sorting and in the query so many sub queries and all.. The cost of the queries are high like anything.
some even has 130Crore of cost .
When I got the chance to look into those quries I test them in Non Prod systems and which almost have 90-95% similar data as it was refresh by PROD few weeks back.
I found few queries are having the same explain plan but cost is less like anything. for example 5000 or 6000.
When I check for the possibilities of wrong statistics I found they just collect with default setting...
In Non prod I saw only the auto stat job is ran and most of the tables are having the stats which are of last analyzed on the day of refresh.
Now what could be so differentiating factor that drives a queries' cost lesser than Prod systems, when the data is almost same. Also if prod ssystem is gather by only gather_schema_stat('SCHEMA_NAME') then it should carry the same stat in non prod while refreshing. I know ppl do not gather stat on test only auto job is running ...
I need to have clear prove before I can have a clear understanding..
Please help me to know what factors could be differentiating?
-Regards,
J_DBA_Sourav

j_DBA_sourav wrote:
Hello Jonathan,
Thanks for the reply. The team refreshed it, by expdp/impdp method where by default statistics are included. In that case?
Is this problem probable to happen due to statistics only or anything else is also responsible. Even the explain plan is same.
Please through some light on it.
Auto job is on as I stated earlier but in test systems most of the tables are showing refreshed date as last_analyzed
-Regards
JDS
Anything that puts the stats out of sync with each other may be sufficient to cause problems. Any queries that depend on sysdate may cause a problem.
As a simple check: select table_name, last_analyzed from user_tables on the two systems, with some order by clause (e.g. table_name), and see how many tables were analysed at different times - anything on either system after the exp/imp could be part of your problem.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Now on Twitter: @jloracle

Query regarding Partition table Explain plan

Hello,
We are amidst a tuning activity, wherein a large table has been partitioned for better administration. During testing, I was analyzing the explain plans for long running sql's and found a piece that I was unable to understand. The PSTART and PSTOP columns show ROWID as its value, which in normal partition pruning scenario be the Partition number or the KEY. I tried to look around for this issue but did not get enough information. Can anybody help me of what it means? Also, if there is a good explanation of the same, it will be extremely helpful.
The snippet from explain plan looks like:
| Id | Operation                                | Name                          | Rows | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
7 |        TABLE ACCESS BY GLOBAL INDEX ROWID| XXXXXXXXXXXXXXXXXXXX             | 43874 | 9083K|       | 1386   (1)| 00:00:17 | ROWID | ROWID |
On another similar query it looks like:
| Id | Operation                             | Name                         | Rows | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
|   6 |     TABLE ACCESS BY GLOBAL INDEX ROWID| XXXXXXXXXXXXXX               | 22455 | 4648K|       |   456   (1)| 00:00:06 |     9 |     9 |
I have another query with regards to the Partition tables. Does it, require/benefit if, the Indexes to be in partitioned mode? I tried to read about it but did not get a conclusive evidence. I am trying to test it and post here the outcome, but if anybody has experience of working with it, it would be great to have some advice.
Oracle Version:- 10.2.0.4
Regards,
Purvesh.

Hi Purvesh.
Great explanation and example on this this topic...
Ask Tom &quot;explain plan on range-partitioned table&quot;
Hope this help.

Query Regarding Explain Plan on Query

Hello,
I have one big query which shows report of 50000 daily records from @ 20,00,000 records.
I have two databases UAT and PROD.when i do Explain Plan on the query is these different database i get the different plan where everything is same in both database.
In UAT it is doing Index scan where as in PROD it is doing Full TableScan. Below are the results.
In production it is not using any of the indexes present but in UAT it is.What could be the reasong behind this?

Sure.
UAT Explain Plan (Please copy in Textpad for better View)
SELECT STATEMENT, GOAL = HINT: ALL_ROWS     Cost=371     Cardinality=238     Optimizer=HINT: ALL_ROWS     Bytes=134470
VIEW     Object owner=SWNET1          Cost=371     Cardinality=238          Bytes=134470
COUNT STOPKEY
VIEW     Object owner=SWNET1          Cost=371     Cardinality=238          Bytes=131376
SORT ORDER BY STOPKEY          Cost=371     Cardinality=238          Bytes=54026
FILTER
HASH JOIN RIGHT ANTI          Cost=370     Cardinality=238          Bytes=54026
INLIST ITERATOR
TABLE ACCESS BY INDEX ROWID     Object owner=SWNET1     Object name=IS_TB_END_POINT     Cost=1     Cardinality=1     Optimizer=ANALYZED     Bytes=31
INDEX RANGE SCAN          Object owner=SWNET1     Object name=IS_UK_EP_NAME     Cost=1     Cardinality=1     Optimizer=ANALYZED
TABLE ACCESS BY INDEX ROWID     Object owner=SWNET1     Object name=IS_TB_TRANSACTION     Cost=368     Cardinality=253     Optimizer=ANALYZED     Bytes=49588
INDEX FULL SCAN          Object owner=SWNET1     Object name=IS_IX_T_DESTINATION_EP     Cost=18     Cardinality=13909     Optimizer=ANALYZED
PRODUCTION Explain Plan
SELECT STATEMENT, GOAL = HINT: ALL_ROWS               Cost=65702     Cardinality=1000     Optimizer=HINT: ALL_ROWS     Bytes=565000
VIEW     Object owner=SWNET1          Cost=65702     Cardinality=1000          Bytes=565000
COUNT STOPKEY
VIEW     Object owner=SWNET1          Cost=65702     Cardinality=38739          Bytes=21383928
SORT ORDER BY STOPKEY          Cost=65702     Cardinality=38739          Bytes=9646011
FILTER
HASH JOIN RIGHT ANTI          Cost=63616     Cardinality=38739          Bytes=9646011
INLIST ITERATOR
TABLE ACCESS BY INDEX ROWID     Object owner=SWNET1     Object name=IS_TB_END_POINT     Cost=1     Cardinality=2     Optimizer=ANALYZED     Bytes=64
INDEX UNIQUE SCAN          Object owner=SWNET1     Object name=IS_UK_EP_NAME     Cost=1     Cardinality=2     Optimizer=ANALYZED
TABLE ACCESS FULL          Object owner=SWNET1     Object name=IS_TB_TRANSACTION     Cost=63614     Cardinality=44697     Optimizer=ANALYZED     Bytes=9699249
Index Query (Same on both places)
create index IS_IX_T_DESTINATION_EP on IS_TB_TRANSACTION (T_DESTINATION_EP)
tablespace IS_XML_IND
pctfree 10
initrans 2
maxtrans 255
storage
initial 128M
next 128K
minextents 1
maxextents unlimited
pctincrease 0
);

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 & rdgs

Hi,
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

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 AM

885901 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: 1

damorgan 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.

Analyze Explain Plan --Query Stuck

Similar Messages

Maybe you are looking for