Partition of table n Explain plan

I am a newbie for oracle partititon. Need help!!!
I have a created a partition table, range partition by key column datatype is 'timetamp'.
Stucture would be ::
CREATE TABLE sales
( prod_id       NUMBER(6)
, cust_id       NUMBER
, time_id       DATE
, amount_sold   NUMBER(10,2)
PARTITION BY RANGE (time_id)
( PARTITION sales_q1_2006 VALUES LESS THAN (TO_DATE('01-APR-2006','dd-MON-yyyy'))
, PARTITION sales_q2_2006 VALUES LESS THAN (TO_DATE('01-JUL-2006','dd-MON-yyyy'))
, PARTITION sales_q3_2006 VALUES LESS THAN (TO_DATE('01-OCT-2006','dd-MON-yyyy'))
, PARTITION sales_q4_2006 VALUES LESS THAN (TO_DATE('01-JAN-2007','dd-MON-yyyy'))
The time i run below query, explain plan shows PStart as #1 and PStop as #4, but this date range access only one partition, explain plan must show particular partition. Also should it show partition name?
select * from sales where trunc(time_id)=trunc(sysdate-2811);

Thanks for the reply martin,I have tried below query still it goes for all partitions.Please refer to below Expalin Plan.
select * from sales where trunc(time_id) between trunc(sysdate-2811) and trunc(sysdate-2810) -1/86400
<PlanElement id="0" operation="SELECT STATEMENT" optimizer="ALL_ROWS" cost="42" cardinality="1" bytes="48" cpu_cost="1,321,416" io_cost="42" time="1">
<PlanElements>
<PlanElement id="1" operation="FILTER" qblock_name="SEL$1" filter_predicates="TRUNC(SYSDATE@!-2811)<=TRUNC(SYSDATE@!-2810)-.00001157407407407407407407407407407407407407">
<PlanElements>
<PlanElement id="2" operation="PARTITION RANGE" option="ALL" cost="42" cardinality="1" bytes="48" partition_id="2" partition_start="1" partition_stop="4" cpu_cost="1,321,416" io_cost="42" time="1">
<PlanElements>
<PlanElement object_ID="0" id="3" operation="TABLE ACCESS" option="FULL" object_owner="SONARDBO" object_name="SALES" object_type="TABLE" object_instance="1" cost="42" cardinality="1" bytes="48" partition_id="2" partition_start="1" partition_stop="4" cpu_cost="1,321,416" io_cost="42" qblock_name="SEL$1" filter_predicates="TRUNC(INTERNAL_FUNCTION("TIME_ID"))>=TRUNC(SYSDATE@!-2811) AND TRUNC(INTERNAL_FUNCTION("TIME_ID"))<=TRUNC(SYSDATE@!-2810)-.00001157407407407407407407407407407407407407" time="1" />

Similar Messages

Partition a table

Hi,
i should want to know what are the benefit to partition a table, because I follow the step on:
http://docs.oracle.com/cd/B19306_01/server.102/b14231/tables.htm#i1006754
the example 1.
but i cannot demostrate some really benefit.
For example:
I have a table AVAN with some index, after that i made AVAN partitioned with the same index, How i can demostrate that after partioned the query executed on partioned table is better?
If there is a solution of course.
thanks
Francesco

Hi, I've runned the explain plan on a partitioned table and on a non-partitioned table (both table contain the same data).
The table partioned has only an LOCAL index more, than do not have a partitioned table:
For the table partioned:
SQL> EXPLAIN PLAN SET STATEMENT_ID='PART'
2 FOR
3 select * from EVENTI_PM e where e.key_id_evento='50000034' and dt_inserimento = (select min(dt_inserimento) from eventi_pm e2
where e.key_id_evento=e2.key_id_evento);
Spiegato.See the plan:
SQL> SELECT
2 CARDINALITY,
3 BYTES,
4 COST,
5 POSITION,
6 PARTITION_START,
7 PARTITION_STOP,
8 PARTITION_ID,
9 lpad(' ',level-1)||OPERATION||' '||OPTIONS||' '||object_name as Plan
10    FROM PLAN_TABLE a
11 CONNECT BY prior id = parent_id
12          AND prior statement_id = statement_id
13    START WITH id = 0
14          AND statement_id = 'PART'
15    ORDER BY id;
CARDINALITY BYTES COST POSITION PARTITION_START PARTITION_STOP PARTITION_ID PLAN
          1   144    5        5                                              SELECT STATEMENT
          1   144    5        1                                               NESTED LOOPS
          1    26    3        1                                                VIEW VW_SQ_1
          1    17    3        1                                                 HASH GROUP BY
          2    34    3        1                                                  FIRST ROW
          2    34    3        1                                                   INDEX RANGE SCAN (MIN/MAX) EVENTO_PK
          1   118    2        2 KEY             KEY                        6   PARTITION HASH ITERATOR
          1   118    2        1 KEY             KEY                        6    TABLE ACCESS BY LOCAL INDEX ROWID EVENTI_P
                                                                             M
          1          1        1 KEY             KEY                        6     INDEX UNIQUE SCAN INDICE_LOC
Selezionate 9 righe.in which the cost is 5.
the same thing for a non-partioned table:
SQL> EXPLAIN PLAN SET STATEMENT_ID='NON_PART'
2 FOR
3 select * from EVENTI_PM2 e where e.key_id_evento='50000034' and dt_inserimento = (select min(dt_inserimento) from eventi_pm e
2 where e.key_id_evento=e2.key_id_evento);
Spiegato.see the plan
SQL> SELECT
2 CARDINALITY,
3 BYTES,
4 COST,
5 POSITION,
6 PARTITION_START,
7 PARTITION_STOP,
8 PARTITION_ID,
9 lpad(' ',level-1)||OPERATION||' '||OPTIONS||' '||object_name as Plan
10    FROM PLAN_TABLE a
11 CONNECT BY prior id = parent_id
12          AND prior statement_id = statement_id
13    START WITH id = 0
14          AND statement_id = 'NON_PART'
15    ORDER BY id;
CARDINALITY BYTES COST POSITION PARTITION_START PARTITION_STOP PARTITION_ID PLAN
          1   144    5        5                                              SELECT STATEMENT
          1   144    5        1                                               NESTED LOOPS
          1    26    3        1                                                VIEW VW_SQ_1
          1    17    3        1                                                 HASH GROUP BY
          2    34    3        1                                                  FIRST ROW
          2    34    3        1                                                   INDEX RANGE SCAN (MIN/MAX) EVENTO_PK
          1   118    2        2                                                TABLE ACCESS BY INDEX ROWID EVENTI_PM2
          1          1        1                                                 INDEX RANGE SCAN EVENTO_PK2
Selezionate 8 righe.but the cost is the same, why?Even if only one partition was used. How i can demostrate to my self that the query in the partitioned table is better?
I'm going to get crazy, partioned a table is not useful at all.Please help me!!!!!!!!!!!!!!!!!!!

EXPLAIN PLAN option disabled

Hi,
When I take an Explain Plan using TKPROF it gives the following error:
Error in CREATE TABLE of EXPLAIN PLAN table: APPS.prof$plan_table
ORA-00955: name is already used by an existing object
parse error offset: 18
EXPLAIN PLAN option disabled.
And the Explain Plan is snot displayed in the o/p file for all the queries.
Can any one help me on this.
Thanks,
Kiran

Hi kiran
When I take an Explain Plan using TKPROF it gives the following error:
Error in CREATE TABLE of EXPLAIN PLAN table: APPS.prof$plan_table
ORA-00955: name is already used by an existing object
parse error offset: 18
EXPLAIN PLAN option disabled.
********************************************************************************What is your Db verssion and EBS? What is your kprof syntax. By the way please check those doc adn see its helpful:
Run Adadmin To Recreate Grants And Synonyms ORA-20000 ORA-00955 In Synonyms Loop:create_synonym(GL,PLAN_TABLE,APPS,PLAN_TABLE) [ID 437714.1]
TKPROF With Explain Fails With ORA-00903 invalid table name [ID 257294.1]
OERR: ORA 955 is already used by an existing object [ID 18549.1]
Also check:
Re: TKPROF and Explain Plan
Regard
Helios

Explain plan - *,1 col, severals, HUH

I was wondering if someone could explain this to me. I have a simple query that joins three tables and my joins
are on the indexed columns. The stats on each of the tables are not up to date but thay are very close. (eg: stats say 950 records when there are actually 1000).
Anyway, in my query I do a select * and noticed that in the explain plan it was doing full table scans on all of the tables. So then on a whim I just selected the first column from the first table only and all of sudden the explain plan came with two of three indexes. Then when I entered in the names of all the fields of the first table the explain plan changed once again. Only this time it only used one index.
Why would what I select have any bearing on the choices
made in the explain plan. This to me makes absolutely no sense. Does it have something to do with chained or migrated records?

The query is
SELECT *
FROM Families t1,
family_memberships t2,
consent_release_form t3
where t1.family_number = t2.family_number
and t2.per_id = t3.per_id
and t3.code < >'03'
In families the PK is family number
In family_membership there is a FK back to families on
family_number. Its PK is fmd_id
In consent_release_forms there is a Index on Per_id and
a PK on consent_id.
There's an intermediate table called PERSONS that slots
between family membership and the consent_release_form table that has a PK of per_id. It wasn't necessary for the query and when i added it to the query with the appropriate links it still made no difference.
WHen I just selected family number in my Select it used all the appropriate indexes because of course family number is the PK of the driving table. But still, even I selected everything why would it use a full table scan on ALL the tables. It wasn't faster. if I added a /*+ RULE */ to the query it used the correct indexes and ran twice as fast.
I just find it odd that this has been happening lately. I never used to run into situations where FTS's were used on all the tables of a query. Maybe one or two of the tables but not all.

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.

Explain plan does not say anything about partition

Hello,
We have Oracle 11g database. And we have range partitioned a table. Now when I see explain plans for queries sometimes it says PARTITION RANGE ALL (when no filter), Some times PARTITION RANGE ITERATOR or PARTITION RANGE SINGLE or PARTITION RANGE JOIN FILTER etc. But sometimes it does not say any thing about partition.
Is the partition pruning being used? Since my understanding is that table is no more a monolithic sort of, but sort of table now has many tables for each partition.
So option is either scan all partition i.e display PARTITION RANGE ALL or scan some partitions, and display it in explain plan.
Am I thinking in wrong direction?
Please let me know.
Thank you,

The only thing to do that makes sense is to back up all your data, erase the boot drive, reinstall and update the OS, then restore only your documents from backup and reinstall your third-party software from known-good copies.
Sadly, this is not practical at the current time. She is away from home, in a place with modem-speed internet access, without access to install media or her backups (which are on a hard drive at home.) I was able to operate on her machine by sshing in, and I did the best I could to remove the crap. The rest will have to wait until she gets back.
Here is something I found by googling:
http://nnrpanel.com/offlineAU.htm
Thank you, I will try them. I doubt they will know anything (since there are no Mac instructions on that page) but maybe they can at least send me to the US center. I have tried the US Nielsen Ratings contact form, three times now, but it appears that either they don't read it or they don't respond to it. It also has a maximum message size of about 250 characters.
I wonder if it may be related to one of those make money at home - be a secret shopper - review products at your leaisure and make a ton of moneydeals.
I would tend to doubt it, if only because they are clearly quite effective (or nobody would be running those ads) and yet nobody has reported this anywhere else that I can find.
I'm going to send some emails and see if I can find someone who knows something.

Sub Partitioning does not have considerable impact Explain Plan

Hi Guys,
I have a table that is list - list sub partitioned on Oracle 11g - 11.2.0.3.
The first partition is on the CIRCLE_ID column and the second sub partition is on the LOAD_DTTM.
Now i have tried 2 queries on the database
1 - select MOBILENUMBER, CLOSING_BAL from GSM_PRR_SUM a1
where A1.CIRCLE_ID ='AK'
AND a1.LOAD_DTTM BETWEEN '28-MAR-2012' AND '03-APR-2012';
2 - select MOBILENUMBER, CLOSING_BAL from GSM_PRR_SUM a1
where A1.CIRCLE_ID ='AK'
AND to_char(a1.LOAD_DTTM) like '%MAR%'
Ideally the 2nd query should take a much higher time than the first query.
But the explain plan shows a difference of less than 1%.
Can you pls provide some insights as why Oracle is not understanding that subpartitioning will be faster?
Thanks,
Manish

Hi Dom
Thanks for your reply.
Is the first query using partition pruning? - Yes
Have you gathered stats, etc, etc? - No. All our queries always need to access the entire table and not a particular subset and the where criteria always uses partition and sub partition columns. so we dont see the need to collect stats. Can you pls advise what stats need to be collected and what will be the advantage of those?
Below are the output of the Explain Plan and Trace Output -
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> show parameter optimizer;
NAME TYPE VALUE
optimizer_capture_sql_plan_baselines boolean FALSE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 11.2.0.3
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
optimizer_use_invisible_indexes boolean FALSE
optimizer_use_pending_statistics boolean FALSE
optimizer_use_sql_plan_baselines boolean TRUE
SQL> show parameter db_file_multi;
NAME TYPE VALUE
db_file_multiblock_read_count integer 128
SQL> show parameter cursor_sharing
NAME TYPE VALUE
cursor_sharing string EXACT
SQL> column sname format a20
SQL> column pname foramt 20
SP2-0158: unknown COLUMN option "foramt"
SQL> column pname format a20
SQL> column pval2 format a20
SQL> select
2 sname
3 , pname
4 , pval1
5 ,pval2
6 from sys.aux_stats$;
from sys.aux_stats$
ERROR at line 6:
ORA-00942: table or view does not exist
SQL> explain plan for
select MOBILENUMBER, CLOSING_BAL from GSM_PRR_SUM_NEW a1
where A1.CIRCLE_ID ='KA'
AND a1.LOAD_DTTM BETWEEN '28-MAR-2012' AND '03-APR-2012'
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
Plan hash value: 3032220315
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)
| Time | Pstart| Pstop |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | 41M| 1643M| 548M(100)
|999:59:59 | | |
| 1 | PARTITION LIST SINGLE | | 41M| 1643M| 548M(100)
|999:59:59 | KEY | KEY |
| 2 | PARTITION LIST ITERATOR| | 41M| 1643M| 548M(100)
|999:59:59 | KEY | KEY |
| 3 | TABLE ACCESS FULL | GSM_PRR_SUM_NEW | 41M| 1643M| 548M(100)
|999:59:59 | KEY | KEY |
PLAN_TABLE_OUTPUT
Note
- dynamic sampling used for this statement (level=2)
14 rows selected.
SQL> explain plan for
select MOBILENUMBER, CLOSING_BAL from GSM_PRR_SUM_NEW a1
where A1.CIRCLE_ID ='KA'
AND to_char(a1.LOAD_DTTM) like '%MAR%';
2 3 4
Explained.
SQL> SQL> SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
Plan hash value: 189546713
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| T
ime | Pstart| Pstop |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | 62M| 2521M| 5435M(100)|99
9:59:59 | | |
| 1 | PARTITION LIST SINGLE| | 62M| 2521M| 5435M(100)|99
9:59:59 | KEY | KEY |
| 2 | PARTITION LIST ALL | | 62M| 2521M| 5435M(100)|99
9:59:59 | 1 | 305 |
|* 3 | TABLE ACCESS FULL | GSM_PRR_SUM_NEW | 62M| 2521M| 5435M(100)|99
9:59:59 | KEY | KEY |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
3 - filter(TO_CHAR(INTERNAL_FUNCTION("A1"."LOAD_DTTM")) LIKE '%MAR%')
Note
PLAN_TABLE_OUTPUT
- dynamic sampling used for this statement (level=2)
19 rows selected.
SQL>
SQL> SET AUTOTRACE TRACEONLY ARRAYSIZE 100
SQL> select MOBILENUMBER, CLOSING_BAL from GSM_PRR_SUM_NEW a1
where A1.CIRCLE_ID ='KA'
AND a1.LOAD_DTTM BETWEEN '28-MAR-2012' AND '03-APR-2012' 2 3 ;
49637012 rows selected.
Execution Plan
Plan hash value: 3032220315
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)
| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 41M| 1643M| 546M(100)
|999:59:59 | | |
| 1 | PARTITION LIST SINGLE | | 41M| 1643M| 546M(100)
|999:59:59 | KEY | KEY |
| 2 | PARTITION LIST ITERATOR| | 41M| 1643M| 546M(100)
|999:59:59 | KEY | KEY |
| 3 | TABLE ACCESS FULL | GSM_PRR_SUM_NEW | 41M| 1643M| 546M(100)
|999:59:59 | KEY | KEY |
Note
- dynamic sampling used for this statement (level=2)
Statistics
0 recursive calls
7 db block gets
530220 consistent gets
33636 physical reads
0 redo size
644311477 bytes sent via SQL*Net to client
5460594 bytes received via SQL*Net from client
496372 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
49637012 rows processed
SQL> SET AUTOTRACE TRACEONLY ARRAYSIZE 100
SQL> select MOBILENUMBER, CLOSING_BAL from GSM_PRR_SUM_NEW a1
where A1.CIRCLE_ID ='KA'
AND to_char(a1.LOAD_DTTM) like '%MAR%' 2 3
4 ;
219166976 rows selected.
Execution Plan
Plan hash value: 189546713
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| T
ime | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 228M| 9155M| 3552M(100)|99
9:59:59 | | |
| 1 | PARTITION LIST SINGLE| | 228M| 9155M| 3552M(100)|99
9:59:59 | KEY | KEY |
| 2 | PARTITION LIST ALL | | 228M| 9155M| 3552M(100)|99
9:59:59 | 1 | 274 |
|* 3 | TABLE ACCESS FULL | GSM_PRR_SUM_NEW | 228M| 9155M| 3552M(100)|99
9:59:59 | KEY | KEY |
Predicate Information (identified by operation id):
3 - filter(TO_CHAR(INTERNAL_FUNCTION("A1"."LOAD_DTTM")) LIKE '%MAR%')
Note
- dynamic sampling used for this statement (level=2)
Statistics
38 recursive calls
107 db block gets
2667792 consistent gets
561765 physical reads
0 redo size
2841422984 bytes sent via SQL*Net to client
24108883 bytes received via SQL*Net from client
2191671 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
219166976 rows processed
SQL>
Thanks,
Manish

Explain plan change after partitioning - Bitmap conversion to rowid

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

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

Explain plan changing after partition exchange

I currently have a data warehouse where I use partition exchange to refresh the data. I'm finding that after a partition exchange of exactly the same data. explain plan changes.
database 11.2.0.2
To demonstrate what I'm doing I simplified the steps.
first I gather stats on the table that will be exchanged and run explain plan
exec dbms_stats.gather_table_stats( ownname=> 'IDW_TARGET', tabname=> 'PROGRAM_DIM' );
Select
FROM IDW_TARGET.ITD_MONTHLY_SUMMARY_FACT A,
IDW_TARGET.GL_PERIOD_DIM B,
IDW_TARGET.PROGRAM_DIM C,
IDW_TARGET.RPT_ENTITY_DIM D
WHERE ASST_SEC_CONCISE_NAME = 'abc'
AND A.GL_PERIOD_KEY = B.KEY
AND A.PROGRAM_KEY = C.KEY
AND A.RPT_ENTITY_KEY = D.KEY
AND B.PERIOD_YEAR >= 2006;
** uses FTS on fact table and runs in 20 seconds. **
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 25M| 71G| 47105 (1)| 00:09:26 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10003 | 25M| 71G| 47105 (1)| 00:09:26 | | | Q1,03 | P->S | QC (RAND) |
|* 3 | HASH JOIN | | 25M| 71G| 47105 (1)| 00:09:26 | | | Q1,03 | PCWP | |
| 4 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 5 | PX RECEIVE | | 4551 | 1773K| 103 (0)| 00:00:02 | | | Q1,03 | PCWP | |
| 6 | PX SEND BROADCAST | :TQ10000 | 4551 | 1773K| 103 (0)| 00:00:02 | | | | S->P | BROADCAST |
| 7 | PARTITION RANGE SINGLE | | 4551 | 1773K| 103 (0)| 00:00:02 | 1 | 1 | | | |
| 8 | TABLE ACCESS FULL | RPT_ENTITY_DIM | 4551 | 1773K| 103 (0)| 00:00:02 | 1 | 1 | | | |
|* 9 | HASH JOIN | | 25M| 61G| 46999 (1)| 00:09:24 | | | Q1,03 | PCWP | |
| 10 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 11 | PX RECEIVE | | 184 | 35696 | 5 (0)| 00:00:01 | | | Q1,03 | PCWP | |
| 12 | PX SEND BROADCAST | :TQ10001 | 184 | 35696 | 5 (0)| 00:00:01 | | | | S->P | BROADCAST |
| 13 | PARTITION RANGE SINGLE | | 184 | 35696 | 5 (0)| 00:00:01 | 1 | 1 | | | |
|* 14 | TABLE ACCESS FULL | GL_PERIOD_DIM | 184 | 35696 | 5 (0)| 00:00:01 | 1 | 1 | | | |
|* 15 | HASH JOIN | | 25M| 57G| 46992 (1)| 00:09:24 | | | Q1,03 | PCWP | |
| 16 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 17 | PX RECEIVE | | 4085 | 6829K| 1334 (1)| 00:00:17 | | | Q1,03 | PCWP | |
| 18 | PX SEND BROADCAST | :TQ10002 | 4085 | 6829K| 1334 (1)| 00:00:17 | | | | S->P | BROADCAST |
| 19 | PARTITION RANGE SINGLE| | 4085 | 6829K| 1334 (1)| 00:00:17 | 1 | 1 | | | |
|* 20 | TABLE ACCESS FULL | PROGRAM_DIM | 4085 | 6829K| 1334 (1)| 00:00:17 | 1 | 1 | | | |
| 21 | PX BLOCK ITERATOR | | 71M| 45G| 45650 (1)| 00:09:08 | 1 | LAST | Q1,03 | PCWC | |
| 22 | TABLE ACCESS FULL | ITD_MONTHLY_SUMMARY_FACT | 71M| 45G| 45650 (1)| 00:09:08 | 1 | 141 | Q1,03 | PCWP | |
Predicate Information (identified by operation id):
3 - access("A"."RPT_ENTITY_KEY"="D"."KEY")
9 - access("A"."GL_PERIOD_KEY"="B"."KEY")
14 - filter("B"."PERIOD_YEAR">=2006)
15 - access("A"."PROGRAM_KEY"="C"."KEY")
20 - filter("ASST_SEC_CONCISE_NAME"='abc'')
drop table PELPROGRAMDIMALLDATA; -- Start fresh here and drop the partition that will be exchanged
create table PELPROGRAMDIMALLDATA as select * from PROGRAM_DIM; -- going to use exact same data for partition exchange (only one parition)
alter table PELPROGRAMDIMALLDATA add constraint CON_342 unique ("VALUE" ) using index ;
alter table PELPROGRAMDIMALLDATA add constraint CON_343 primary key ("KEY" ) using index ;
exec dbms_stats.gather_table_stats(ownname=>'IDW_TARGET', tabname=>'PELPROGRAMDIMALLDATA');
alter table PROGRAM_DIM exchange partition ALL_DATA with table PELPROGRAMDIMALLDATA excluding indexes;
** rebuild indexes **
** explain plan for same statement uses nested loop**
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 2637K| 7514M| 33428 (1)| 00:06:42 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10003 | 2637K| 7514M| 33428 (1)| 00:06:42 | | | Q1,03 | P->S | QC (RAND) |
|* 3 | HASH JOIN | | 2637K| 7514M| 33428 (1)| 00:06:42 | | | Q1,03 | PCWP | |
| 4 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 5 | PX RECEIVE | | 4551 | 1773K| 103 (0)| 00:00:02 | | | Q1,03 | PCWP | |
| 6 | PX SEND BROADCAST | :TQ10000 | 4551 | 1773K| 103 (0)| 00:00:02 | | | | S->P | BROADCAST |
| 7 | PARTITION RANGE SINGLE | | 4551 | 1773K| 103 (0)| 00:00:02 | 1 | 1 | | | |
| 8 | TABLE ACCESS FULL | RPT_ENTITY_DIM | 4551 | 1773K| 103 (0)| 00:00:02 | 1 | 1 | | | |
|* 9 | HASH JOIN | | 2637K| 6511M| 33324 (1)| 00:06:40 | | | Q1,03 | PCWP | |
| 10 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 11 | PX RECEIVE | | 184 | 35696 | 5 (0)| 00:00:01 | | | Q1,03 | PCWP | |
| 12 | PX SEND BROADCAST | :TQ10001 | 184 | 35696 | 5 (0)| 00:00:01 | | | | S->P | BROADCAST |
| 13 | PARTITION RANGE SINGLE | | 184 | 35696 | 5 (0)| 00:00:01 | 1 | 1 | | | |
|* 14 | TABLE ACCESS FULL | GL_PERIOD_DIM | 184 | 35696 | 5 (0)| 00:00:01 | 1 | 1 | | | |
| 15 | NESTED LOOPS | | 2642K| 6035M| 33318 (1)| 00:06:40 | | | Q1,03 | PCWP | |
| 16 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 17 | PX RECEIVE | | | | | | | | Q1,03 | PCWP | |
| 18 | PX SEND ROUND-ROBIN | :TQ10002 | | | | | | | | S->P | RND-ROBIN |
| 19 | PARTITION RANGE SINGLE | | 420 | 702K| 220 (0)| 00:00:03 | 1 | 1 | | | |
| 20 | TABLE ACCESS BY LOCAL INDEX ROWID| PROGRAM_DIM | 420 | 702K| 220 (0)| 00:00:03 | 1 | 1 | | | |
|* 21 | INDEX RANGE SCAN | PROGRAM_DIM_IX20 | 420 | | 3 (0)| 00:00:01 | 1 | 1 | | | |
| 22 | PARTITION RANGE ALL | | 6299 | 4201K| 33318 (1)| 00:06:40 | 1 | 9 | Q1,03 | PCWP | |
| 23 | PARTITION LIST ALL | | 6299 | 4201K| 33318 (1)| 00:06:40 | 1 | LAST | Q1,03 | PCWP | |
| 24 | TABLE ACCESS BY LOCAL INDEX ROWID | ITD_MONTHLY_SUMMARY_FACT | 6299 | 4201K| 33318 (1)| 00:06:40 | 1 | 141 | Q1,03 | PCWP | |
| 25 | BITMAP CONVERSION TO ROWIDS | | | | | | | | Q1,03 | PCWP | |
|* 26 | BITMAP INDEX SINGLE VALUE | ITD_MONTHLY_SUMMARY_SK09 | | | | | 1 | 141 | Q1,03 | PCWP | |
Predicate Information (identified by operation id):
3 - access("A"."RPT_ENTITY_KEY"="D"."KEY")
9 - access("A"."GL_PERIOD_KEY"="B"."KEY")
14 - filter("B"."PERIOD_YEAR">=2006)
21 - access("ASST_SEC_CONCISE_NAME"='abc')
26 - access("A"."PROGRAM_KEY"="C"."KEY")
exec dbms_stats.gather_table_stats( ownname=> 'IDW_TARGET', tabname=> 'PROGRAM_DIM' );
** explain plan for same statement uses full table scan**
see first explain plan
Since the stats were not gathered after the partition exchange I would imagine that they would still be used.
Edited by: user12198207 on Feb 7, 2012 8:13 AM
Edited by: user12198207 on Feb 7, 2012 9:47 AM

Locking stats did not make any difference. Also, I deleted the stats at the global level leaving just partition stats and it continued to use the nested loop which takes 15+ minutes instead of 20 seconds with the FTS.
In my original situation it listed the stats at the global level as stale after the partition exchange. But after I removed many of the steps and use just what's described in this posts.
select * from dba_tab_statistics
where table_name='PROGRAM_DIM';
shows stale stats=no for both global and partition. Kind of unexpected. Further digging in shows that is just determined by a case statement.
from dba_tab_statistics view ddl
case
when t.analyzetime is null then null
when ((m.inserts + m.deletes + m.updates) >
t.rowcnt *
to_number(DBMS_STATS.GET_PREFS('STALE_PERCENT',
u.name, o.name))/100 or
bitand(m.flags,1) = 1) then 'YES'
else 'NO'
end

Virtual column partitioning - explain plan takes lot of time.

I have some problem with table with partitioning based on virtual column.
Explain plan generates for some simple select 2-5 minutes,
but the same select but without part of where clausule generate in secounds.
In both query there is the same explain plan.
Could someone explain why?
Table:
CREATE TABLE "SUBSCRIPTION"
"CUSTOMER_ID" VARCHAR2(100 BYTE),
"IDENT_SOURCE_ID" VARCHAR2(20 BYTE),
"ACCOUNT_ID" VARCHAR2(100 BYTE),
"MSISDN" VARCHAR2(500 BYTE),
"IMSI" VARCHAR2(500 BYTE),
"SIM" VARCHAR2(500 BYTE),
"IMEI" VARCHAR2(500 BYTE),
"MEID" VARCHAR2(15 BYTE),
"EMAIL" VARCHAR2(100 BYTE),
"TELCOOP" VARCHAR2(1000 BYTE),
"MSISDN_TYPE" VARCHAR2(20 BYTE),
"GSM" NUMBER(1,0),
"CDMA" NUMBER(1,0),
"VALID_FROM" DATE,
"VALID_TO" DATE,
"MSISDN_HASH" NUMBER(3,0) GENERATED ALWAYS AS (MOD(TO_NUMBER(NVL2(RTRIM(TRANSLATE(NVL(SUBSTR("MSISDN",-3),NVL("MSISDN",'err')),'123456789','000000000'),'0'),'-1',NVL(SUBSTR("MSISDN",-3),"MSISDN"))),125)) VIRTUAL VISIBLE, --generali mod from 3 last digits of msisdn
) PARTITION BY LIST ( "MSISDN_HASH" )
PARTITION "PCHR" VALUES ( -1 )
PARTITION "P000" VALUES ( 0 )
PARTITION "P001" VALUES ( 1 )
... and so on till...
PARTITION "P124" VALUES (124)
PARALLEL 4;
Slow select:
select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
from dbident2.subscription
where MSISDN = '600489461'
AND MSISDN_HASH = 86
AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
Fast select:
select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
from dbident2.subscription
where MSISDN = '600489461'
AND MSISDN_HASH = 86

--Slower select trace:
Registered qb: SEL$1 0xf4ea2a20 (PARSER)
QUERY BLOCK SIGNATURE
signature (): qb_name=SEL$1 nbfros=1 flg=0
fro(0): flg=4 objn=848731 hint_alias="SUBSCRIPTION"@"SEL$1"
SPM: statement not found in SMB
SPM: statement not a candidate for auto-capture
Dynamic sampling level auto-adjusted from 6 to 6
Automatic degree of parallelism (ADOP)
Automatic degree of parallelism is disabled: Parameter.
PM: Considering predicate move-around in query block SEL$1 (#0)
Predicate Move-Around (PM)
OPTIMIZER INFORMATION
----- Current SQL Statement for this session (sql_id=afjvvjmx6tqgr) -----
explain plan for
select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
from subscription
where MSISDN = '600600600' AND MSISDN_HASH = 86
AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
Legend
The following abbreviations are used by optimizer trace.
CBQT - cost-based query transformation
JPPD - join predicate push-down
OJPPD - old-style (non-cost-based) JPPD
FPD - filter push-down
PM - predicate move-around
CVM - complex view merging
SPJ - select-project-join
SJC - set join conversion
SU - subquery unnesting
OBYE - order by elimination
OST - old style star transformation
ST - new (cbqt) star transformation
CNT - count(col) to count(*) transformation
JE - Join Elimination
JF - join factorization
SLP - select list pruning
DP - distinct placement
qb - query block
LB - leaf blocks
DK - distinct keys
LB/K - average number of leaf blocks per key
DB/K - average number of data blocks per key
CLUF - clustering factor
NDV - number of distinct values
Resp - response cost
Card - cardinality
Resc - resource cost
NL - nested loops (join)
SM - sort merge (join)
HA - hash (join)
CPUSPEED - CPU Speed
IOTFRSPEED - I/O transfer speed
IOSEEKTIM - I/O seek time
SREADTIM - average single block read time
MREADTIM - average multiblock read time
MBRC - average multiblock read count
MAXTHR - maximum I/O system throughput
SLAVETHR - average slave I/O throughput
dmeth - distribution method
1: no partitioning required
2: value partitioned
4: right is random (round-robin)
128: left is random (round-robin)
8: broadcast right and partition left
16: broadcast left and partition right
32: partition left using partitioning of right
64: partition right using partitioning of left
256: run the join in serial
0: invalid distribution method
sel - selectivity
ptn - partition
PARAMETERS USED BY THE OPTIMIZER
PARAMETERS WITH ALTERED VALUES
Compilation Environment Dump
pgamax_size = 1258280 KB
parallel_query_default_dop = 32
db_file_multiblock_read_count = 16
Bug Fix Control Environment
PARAMETERS IN OPT_PARAM HINT
Column Usage Monitoring is ON: tracking level = 1
Considering Query Transformations on query block SEL$1 (#0)
Query transformations (QT)
JF: Checking validity of join factorization for query block SEL$1 (#0)
JF: Bypassed: not a UNION or UNION-ALL query block.
ST: not valid since star transformation parameter is FALSE
TE: Checking validity of table expansion for query block SEL$1 (#0)
TE: Bypassed: No relevant table found.
CBQT bypassed for query block SEL$1 (#0): no complex view, sub-queries or UNION (ALL) queries.
CBQT: Validity checks failed for afjvvjmx6tqgr.
CSE: Considering common sub-expression elimination in query block SEL$1 (#0)
Common Subexpression elimination (CSE)
CSE: CSE not performed on query block SEL$1 (#0).
OBYE: Considering Order-by Elimination from view SEL$1 (#0)
Order-by elimination (OBYE)
OBYE: OBYE bypassed: no order by to eliminate.
CVM: Considering view merge in query block SEL$1 (#0)
query block SEL$1 (#0) unchanged
Considering Query Transformations on query block SEL$1 (#0)
Query transformations (QT)
JF: Checking validity of join factorization for query block SEL$1 (#0)
JF: Bypassed: not a UNION or UNION-ALL query block.
ST: not valid since star transformation parameter is FALSE
TE: Checking validity of table expansion for query block SEL$1 (#0)
TE: Bypassed: No relevant table found.
CBQT bypassed for query block SEL$1 (#0): no complex view, sub-queries or UNION (ALL) queries.
CBQT: Validity checks failed for afjvvjmx6tqgr.
CSE: Considering common sub-expression elimination in query block SEL$1 (#0)
Common Subexpression elimination (CSE)
CSE: CSE not performed on query block SEL$1 (#0).
SU: Considering subquery unnesting in query block SEL$1 (#0)
Subquery Unnest (SU)
SJC: Considering set-join conversion in query block SEL$1 (#0)
Set-Join Conversion (SJC)
SJC: not performed
PM: Considering predicate move-around in query block SEL$1 (#0)
Predicate Move-Around (PM)
PM: PM bypassed: Outer query contains no views.
PM: PM bypassed: Outer query contains no views.
query block SEL$1 (#0) unchanged
FPD: Considering simple filter push in query block SEL$1 (#0)
"SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."MSISDN_HASH"=86 AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
try to generate transitive predicate from check constraints for query block SEL$1 (#0)
finally: "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."MSISDN_HASH"=86 AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
apadrv-start sqlid=12053738773107497463
call(in-use=8176, alloc=32712), compile(in-use=114912, alloc=116848), execution(in-use=175432, alloc=178928)
Peeked values of the binds in SQL statement
Final query after transformations:******* UNPARSED QUERY IS *******
SELECT "SUBSCRIPTION"."CUSTOMER_ID" "CUSTOMER_ID","SUBSCRIPTION"."IDENT_SOURCE_ID" "IDENT_SOURCE_ID","SUBSCRIPTION"."ACCOUNT_ID" "ACCOUNT_ID","SUBSCRIPTION"."MSISDN" "MSISDN","SUBSCRIPTION"."IMSI" "IMSI","SUBSCRIPTION"."SIM" "SIM","SUBSCRIPTION"."IMEI" "IMEI","SUBSCRIPTION"."MEID" "MEID","SUBSCRIPTION"."EMAIL" "EMAIL","SUBSCRIPTION"."TELCOOP" "TELCOOP" FROM "DBIDENT2"."SUBSCRIPTION" "SUBSCRIPTION" WHERE "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."MSISDN_HASH"=86 AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
kkoqbc: optimizing query block SEL$1 (#0)
call(in-use=8320, alloc=32712), compile(in-use=115880, alloc=116848), execution(in-use=175432, alloc=178928)
kkoqbc-subheap (create addr=0x2b24ebece950)
QUERY BLOCK TEXT
select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
from subscription
where MSISDN = '600600600' AND MSISDN_HASH = 86
AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
QUERY BLOCK SIGNATURE
signature (optimizer): qb_name=SEL$1 nbfros=1 flg=0
fro(0): flg=0 objn=848731 hint_alias="SUBSCRIPTION"@"SEL$1"
SYSTEM STATISTICS INFORMATION
Using NOWORKLOAD Stats
CPUSPEEDNW: 714 millions instructions/sec (default is 100)
IOTFRSPEED: 4096 bytes per millisecond (default is 4096)
IOSEEKTIM: 10 milliseconds (default is 10)
MBRC: -1 blocks (default is 16)
BASE STATISTICAL INFORMATION
Table Stats::
Table: SUBSCRIPTION Alias: SUBSCRIPTION Partition [87]
#Rows: 218104 #Blks: 11008 AvgRowLen: 129.00 ChainCnt: 0.00
#Rows: 218104 #Blks: 11008 AvgRowLen: 129.00 ChainCnt: 0.00
Index Stats::
Index: SUBSCRIPTION_NDX_ACCID Col#: 3
LVLS: 3 #LB: 121036 #DK: 9767936 LB/K: 1.00 DB/K: 1.00 CLUF: 13921256.00
Index: SUBSCRIPTION_NDX_CUSID Col#: 1 2 18
LVLS: 3 #LB: 142123 #DK: 24665396 LB/K: 1.00 DB/K: 1.00 CLUF: 24842146.00
Index: SUBSCRIPTION_NDX_EMAIL Col#: 9
LVLS: 2 #LB: 8365 #DK: 1361827 LB/K: 1.00 DB/K: 1.00 CLUF: 1361798.00
Index: SUBSCRIPTION_NDX_EXT1 Col#: 19
LVLS: 2 #LB: 65756 #DK: 67792 LB/K: 1.00 DB/K: 80.00 CLUF: 5446485.00
Index: SUBSCRIPTION_NDX_IMEI Col#: 7
LVLS: 2 #LB: 44539 #DK: 9199616 LB/K: 1.00 DB/K: 1.00 CLUF: 10413439.00
Index: SUBSCRIPTION_NDX_IMSI Col#: 5
LVLS: 3 #LB: 92914 #DK: 12846080 LB/K: 1.00 DB/K: 1.00 CLUF: 23472821.00
Index: SUBSCRIPTION_NDX_MEID Col#: 8
LVLS: 1 #LB: 132 #DK: 12585 LB/K: 1.00 DB/K: 1.00 CLUF: 18419.00
Index: SUBSCRIPTION_NDX_MSISDN Col#: 4 PARTITION [87]
LVLS: 2 #LB: 1092 #DK: 74848 LB/K: 1.00 DB/K: 2.00 CLUF: 191920.00
LVLS: 2 #LB: 1092 #DK: 74848 LB/K: 1.00 DB/K: 2.00 CLUF: 191920.00
Index: SUBSCRIPTION_NDX_SIM Col#: 6
LVLS: 2 #LB: 88153 #DK: 13169664 LB/K: 1.00 DB/K: 1.00 CLUF: 24727298.00
Index: SUBSCRIPTION_NDX_SRCID Col#: 2 17
LVLS: 2 #LB: 81729 #DK: 4 LB/K: 20432.00 DB/K: 257314.00 CLUF: 1029257.00
Access path analysis for SUBSCRIPTION
SINGLE TABLE ACCESS PATH
Single Table Cardinality Estimation for SUBSCRIPTION[SUBSCRIPTION]
*** 2012-06-12 12:34:53.283
** Performing dynamic sampling initial checks. **
Column (#14):
NewDensity:0.000020, OldDensity:0.000366 BktCnt:254, PopBktCnt:22, PopValCnt:1, NDV:46252
Column (#14):
NewDensity:0.000163, OldDensity:0.000378 BktCnt:254, PopBktCnt:12, PopValCnt:1, NDV:5852
Column (#14): VALID_FROM( Part#: 87
AvgLen: 8 NDV: 5852 Nulls: 2 Density: 0.000163 Min: 2450364 Max: 2456082
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 244
Column (#14): VALID_FROM(
AvgLen: 8 NDV: 5852 Nulls: 2 Density: 0.000163 Min: 2450364 Max: 2456082
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 244
Column (#4):
NewDensity:0.000000, OldDensity:0.000000 BktCnt:254, PopBktCnt:0, PopValCnt:0, NDV:9730048
Column (#4):
NewDensity:0.000013, OldDensity:0.000033 BktCnt:254, PopBktCnt:0, PopValCnt:0, NDV:74848
Column (#4): MSISDN( Part#: 87
AvgLen: 10 NDV: 74848 Nulls: 0 Density: 0.000013
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 255
Column (#4): MSISDN(
AvgLen: 10 NDV: 74848 Nulls: 0 Density: 0.000013
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 255
** Dynamic sampling initial checks returning TRUE (level = 6).
*** 2012-06-12 12:34:53.284
** Generated dynamic sampling query:
query text :
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false') NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),0), NVL(SUM(C2),0) FROM (SELECT /*+ IGNORE_WHERE_CLAUSE NO_PARALLEL("SUBSCRIPTION") FULL("SUBSCRIPTION") NO_PARALLEL_INDEX("SUBSCRIPTION") */ 1 AS C1, CASE WHEN "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss') THEN 1 ELSE 0 END AS C2 FROM "DBIDENT2"."SUBSCRIPTION" SAMPLE BLOCK (1.153706 , 1) SEED (1) "SUBSCRIPTION" WHERE "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) SAMPLESUB
*** 2012-06-12 12:36:44.452
** Executed dynamic sampling query:
level : 6
sample pct. : 1.153706
total partitions : 1
partitions for sampling : 1
actual sample size : 342182
filtered sample card. : 0
orig. card. : 218104
block cnt. table stat. : 11008
block cnt. for sampling: 11008
max. sample block cnt. : 128
sample block cnt. : 127
min. sel. est. : 0.00001260
** Not using dynamic sampling for single table sel. or cardinality.
DS Failed for : ----- Current SQL Statement for this session (sql_id=afjvvjmx6tqgr) -----
explain plan for
select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
from subscription
where MSISDN = '600600600' AND MSISDN_HASH = 86
AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
Column (#21):
NewDensity:0.002912, OldDensity:0.000000 BktCnt:14078, PopBktCnt:14078, PopValCnt:126, NDV:126
Column (#21): MSISDN_HASH( Part#: 87
AvgLen: 3 NDV: 1 Nulls: 0 Density: 0.000002 Min: 86 Max: 86
Histogram: Freq #Bkts: 1 UncompBkts: 13365 EndPtVals: 1
Column (#21): MSISDN_HASH(
AvgLen: 3 NDV: 1 Nulls: 0 Density: 0.000002 Min: 86 Max: 86
Histogram: Freq #Bkts: 1 UncompBkts: 13365 EndPtVals: 1
Column (#1):
NewDensity:0.000000, OldDensity:0.000241 BktCnt:254, PopBktCnt:31, PopValCnt:2, NDV:9768960
Column (#1):
NewDensity:0.000009, OldDensity:0.000250 BktCnt:254, PopBktCnt:36, PopValCnt:3, NDV:99208
Column (#1): CUSTOMER_ID( Part#: 87
AvgLen: 11 NDV: 99208 Nulls: 0 Density: 0.000009
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 222
Column (#1): CUSTOMER_ID(
AvgLen: 11 NDV: 99208 Nulls: 0 Density: 0.000009
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 222
Column (#2):
NewDensity:0.000639, OldDensity:0.000000 BktCnt:14078, PopBktCnt:14078, PopValCnt:3, NDV:3
Column (#2):
NewDensity:0.000786, OldDensity:0.000002 BktCnt:13365, PopBktCnt:13365, PopValCnt:3, NDV:3
Column (#2): IDENT_SOURCE_ID( Part#: 87
AvgLen: 5 NDV: 3 Nulls: 0 Density: 0.000786
Histogram: Freq #Bkts: 3 UncompBkts: 13365 EndPtVals: 3
Column (#2): IDENT_SOURCE_ID(
AvgLen: 5 NDV: 3 Nulls: 0 Density: 0.000786
Histogram: Freq #Bkts: 3 UncompBkts: 13365 EndPtVals: 3
ColGroup (#1, Index) SUBSCRIPTION_NDX_CUSID
Col#: 1 2 18 CorStregth: -1.00
ColGroup (#2, Index) SUBSCRIPTION_NDX_SRCID
Col#: 2 17 CorStregth: -1.00
ColGroup Usage:: PredCnt: 2 Matches Full: Partial:
***** Virtual column Adjustment ******
Column name MSISDN_HASH
cost_cpu 2300.00
cost_io 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00
***** End virtual column Adjustment ******
Table: SUBSCRIPTION Alias: SUBSCRIPTION
Card: Original: 218104.000000 Rounded: 3 Computed: 2.75 Non Adjusted: 2.75
Access Path: TableScan
Cost: 2420.71 Resp: 672.42 Degree: 0
Cost_io: 2409.00 Cost_cpu: 100334308
Resp_io: 669.17 Resp_cpu: 27870641
kkofmx: index filter:"SUBSCRIPTION"."MSISDN_HASH"=86
***** Virtual column Adjustment ******
Column name MSISDN_HASH
cost_cpu 2300.00
cost_io 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00
***** End virtual column Adjustment ******
Access Path: index (AllEqRange)
Index: SUBSCRIPTION_NDX_MSISDN
resc_io: 6.00 resc_cpu: 36840
ix_sel: 0.000013 ix_sel_with_filters: 0.000013
***** Logdef predicate Adjustment ******
Final IO cst 0.00 , CPU cst 2300.00
***** End Logdef Adjustment ******
Cost: 6.01 Resp: 6.01 Degree: 1
Best:: AccessPath: IndexRange
Index: SUBSCRIPTION_NDX_MSISDN
Cost: 6.01 Degree: 1 Resp: 6.01 Card: 2.75 Bytes: 0
OPTIMIZER STATISTICS AND COMPUTATIONS
GENERAL PLANS
Considering cardinality-based initial join order.
Permutations for Starting Table :0
Join order[1]: SUBSCRIPTION[SUBSCRIPTION]#0
Best so far: Table#: 0 cost: 6.0051 card: 2.7487 bytes: 291
****** Recost for parallel table scan *******
Access path analysis for SUBSCRIPTION
SINGLE TABLE ACCESS PATH
Single Table Cardinality Estimation for SUBSCRIPTION[SUBSCRIPTION]
*** 2012-06-12 12:36:44.454
** Performing dynamic sampling initial checks. **
** TABLE SUBSCRIPTION Alias: SUBSCRIPTION : reused cached dynamic sampling result (failure).
ColGroup Usage:: PredCnt: 2 Matches Full: Partial:
***** Virtual column Adjustment ******
Column name MSISDN_HASH
cost_cpu 2300.00
cost_io 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00
***** End virtual column Adjustment ******
Table: SUBSCRIPTION Alias: SUBSCRIPTION
Card: Original: 218104.000000 Rounded: 3 Computed: 2.75 Non Adjusted: 2.75
Access Path: TableScan
Cost: 2420.71 Resp: 672.42 Degree: 0
Cost_io: 2409.00 Cost_cpu: 100334308
Resp_io: 669.17 Resp_cpu: 27870641
Best:: AccessPath: TableScan
Cost: 672.42 Degree: 4 Resp: 672.42 Card: 2.75 Bytes: 97
Join order[1]: SUBSCRIPTION[SUBSCRIPTION]#0
Join order aborted: cost > best plan cost
(newjo-stop-1) k:0, spcnt:0, perm:1, maxperm:2000
Number of join permutations tried: 1
Enumerating distribution method (advanced)
Trying or-Expansion on query block SEL$1 (#0)
Transfer Optimizer annotations for query block SEL$1 (#0)
id=0 frofkks[i] (index start key) predicate="SUBSCRIPTION"."MSISDN"='600600600'
id=0 frofkke[i] (index stop key) predicate="SUBSCRIPTION"."MSISDN"='600600600'
id=0 frofand predicate="SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
Final cost for query block SEL$1 (#0) - All Rows Plan:
Best join order: 1
Cost: 6.0051 Degree: 1 Card: 3.0000 Bytes: 291
Resc: 6.0051 Resc_io: 6.0000 Resc_cpu: 43740
Resp: 6.0051 Resp_io: 6.0000 Resc_cpu: 43740
kkoqbc-subheap (delete addr=0x2b24ebece950, in-use=21280, alloc=32840)
kkoqbc-end:
call(in-use=252920, alloc=343912), compile(in-use=129048, alloc=133000), execution(in-use=192248, alloc=195240)
kkoqbc: finish optimizing query block SEL$1 (#0)
apadrv-end
call(in-use=252920, alloc=343912), compile(in-use=129960, alloc=133000), execution(in-use=192248, alloc=195240)
Starting SQL statement dump
user_id=115 user_name=xxx module=SQL*Plus action=
sql_id=afjvvjmx6tqgr plan_hash_value=1672204165 problem_type=3
----- Current SQL Statement for this session (sql_id=afjvvjmx6tqgr) -----
explain plan for
select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
from subscription
where MSISDN = '600600600' AND MSISDN_HASH = 86
AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
sql_text_length=266
sql=explain plan for
select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
from subscription
where MSISDN = '600600600' AND MSISDN_HASH = 86
AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH2
sql=4:MI:SS')
----- Explain Plan Dump -----
----- Plan Table -----
============
Plan Table
============
-----------------------------------------------------------------------------------------------------------------------+
| Id | Operation | Name | Rows | Bytes | Cost | Time | Pstart| Pstop |
-----------------------------------------------------------------------------------------------------------------------+
| 0 | SELECT STATEMENT | | | | 6 | | | |
| 1 | PARTITION LIST SINGLE | | 3 | 291 | 6 | 00:00:01 | 88 | 88 |
| 2 | TABLE ACCESS BY LOCAL INDEX ROWID | SUBSCRIPTION | 3 | 291 | 6 | 00:00:01 | 88 | 88 |
| 3 | INDEX RANGE SCAN | SUBSCRIPTION_NDX_MSISDN| 3 | | 3 | 00:00:01 | 88 | 88 |
-----------------------------------------------------------------------------------------------------------------------+
Predicate Information:
2 - filter("VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
3 - access("MSISDN"='600600600')
Content of other_xml column
===========================
nodeid/pflags: 1 1 db_version : 11.2.0.2
parse_schema : xxx
plan_hash : 1672204165
plan_hash_2 : 1960934971
Outline Data:
/*+
BEGIN_OUTLINE_DATA
IGNORE_OPTIM_EMBEDDED_HINTS
OPTIMIZER_FEATURES_ENABLE('11.2.0.2')
DB_VERSION('11.2.0.2')
OPT_PARAM('optimizer_dynamic_sampling' 6)
ALL_ROWS
OUTLINE_LEAF(@"SEL$1")
INDEX_RS_ASC(@"SEL$1" "SUBSCRIPTION"@"SEL$1" ("SUBSCRIPTION"."MSISDN"))
END_OUTLINE_DATA
Query Block Registry:
SEL$1 0xf4ea2a20 (PARSER) [FINAL]
call(in-use=259392, alloc=343912), compile(in-use=170344, alloc=270888), execution(in-use=344120, alloc=346656)
End of Optimizer State Dump
Dumping Hints
=============
====================== END SQL Statement Dump ======================
Edited by: user3754081 on 2012-06-12 08:07

How to create an explain plan with rowsource statistics for a complex query that include multiple table joins ?

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 different with no stats but with no rows & rows in a table

Hi All,
This is in Oracle 8.1.7.4.0 DB.
1. Query was taking long time to return rows. It was based on a view.
2. View has multiple tables.
3. The explain plan was showing one of the Table(e.g. TABLE1) using incorrect INDEX. At the time of explain plan table has no statistics.
4. truncated Table TABLE1
5. The explain plan now taking correct INDEX for the table TABLE1.
How does optimizer choosing the incorrect index when rows in a table & correct index when there are no rows in the table ?
any insights.
Thanks
Sandeep

I don't know about your particular db version, but CBO in absence of statistics uses some default values (e.g. average row length 100 bytes) and also uses actual number of block for the table. I assume something similar might be for indexes.
To be sure what has changed you can run 10053 level trace.
Gints Plivna
http://www.gplivna.eu

Explain Plan Table

Hi,
I have created the plan_table using utlxplan.sql but still i am getting the error:
ORA-02404: specified plan table not found
Is there something else to be done to get it fixed?
please suggest.
Regards
Arpit

As Lukasz suggested check the table privs between the schema where the table was created and the user trying to use it. Also make sure there's a synonym for the user using explain plan to get to the plan table easily; a public synonym might work best

Strange explain plan when query SYS tables

Oracle Version 9.2.0.7
We have an application that runs the following query on Oracle 9.2.0.7
SELECT T1.TABLE_NAME,T1.COLUMN_NAME, T1.SRID, T2.SDO_UB, T2.SDO_LB, T1.OWNER FROM ALL_SDO_GEOM_METADATA T1, TABLE(T1.DIMINFO) T2 WHERE T1.OWNER=UPPER(:"SYS_B_0") AND T1.TABLE_NAME=UPPER(:"SYS_B_1")
Without the self join the query is fine, but with the self join on our customers database the explain plan is doing full table scans and Hash Joins on SYS tables and takes 2 minutes.
Rows Row Source Operation
2 FILTER
2 NESTED LOOPS
1 TABLE ACCESS FULL SDO_GEOM_METADATA_TABLE
2 COLLECTION ITERATOR PICKLER FETCH
1 UNION-ALL
0 FILTER
0 NESTED LOOPS OUTER
0 HASH JOIN
37 TABLE ACCESS FULL TS$
0 HASH JOIN OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS
1 NESTED LOOPS
1 TABLE ACCESS BY INDEX ROWID USER$
1 INDEX UNIQUE SCAN I_USER1 (object id 44)
1 TABLE ACCESS BY INDEX ROWID OBJ$
1 INDEX RANGE SCAN I_OBJ2 (object id 37)
0 TABLE ACCESS CLUSTER TAB$
1 INDEX UNIQUE SCAN I_OBJ# (object id 3)
0 TABLE ACCESS CLUSTER SEG$
0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (object id 9)
0 TABLE ACCESS BY INDEX ROWID OBJ$
0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
0 TABLE ACCESS FULL USER$
0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
0 NESTED LOOPS
0 FIXED TABLE FULL X$KZSRO
0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
0 FIXED TABLE FULL X$KZSPR
0 FILTER
0 NESTED LOOPS OUTER
0 HASH JOIN
54 TABLE ACCESS FULL USER$
0 HASH JOIN
29447 TABLE ACCESS FULL OBJ$
0 HASH JOIN OUTER
0 HASH JOIN OUTER
0 HASH JOIN OUTER
0 NESTED LOOPS
0 NESTED LOOPS OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS
1 NESTED LOOPS
1 TABLE ACCESS BY INDEX ROWID USER$
1 INDEX UNIQUE SCAN I_USER1 (object id 44)
1 TABLE ACCESS BY INDEX ROWID OBJ$
1 INDEX RANGE SCAN I_OBJ2 (object id 37)
0 TABLE ACCESS CLUSTER TAB$
1 INDEX UNIQUE SCAN I_OBJ# (object id 3)
0 TABLE ACCESS CLUSTER TS$
0 INDEX UNIQUE SCAN I_TS# (object id 7)
0 TABLE ACCESS CLUSTER COL$
0 TABLE ACCESS CLUSTER SEG$
0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (object id 9)
0 TABLE ACCESS BY INDEX ROWID OBJ$
0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
0 TABLE ACCESS CLUSTER COLTYPE$
0 TABLE ACCESS FULL USER$
0 TABLE ACCESS FULL OBJ$
0 TABLE ACCESS FULL USER$
0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
0 NESTED LOOPS
0 FIXED TABLE FULL X$KZSRO
0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
0 FIXED TABLE FULL X$KZSPR
1 FILTER
1 NESTED LOOPS
1 NESTED LOOPS OUTER
1 NESTED LOOPS
1 TABLE ACCESS BY INDEX ROWID USER$
1 INDEX UNIQUE SCAN I_USER1 (object id 44)
1 TABLE ACCESS BY INDEX ROWID OBJ$
1 INDEX RANGE SCAN I_OBJ2 (object id 37)
0 INDEX UNIQUE SCAN I_TYPED_VIEW1 (object id 105)
1 INDEX UNIQUE SCAN I_VIEW1 (object id 104)
0 NESTED LOOPS
0 FIXED TABLE FULL X$KZSRO
0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
0 FIXED TABLE FULL X$KZSPR
On our development database it takes 0.07 sec with no full table scans and no hash joins.
Rows Row Source Operation
2 NESTED LOOPS
1 TABLE ACCESS BY INDEX ROWID SDO_GEOM_METADATA_TABLE
1 INDEX RANGE SCAN SDO_GEOM_IDX (object id 36753)
1 UNION-ALL
0 FILTER
0 NESTED LOOPS
0 NESTED LOOPS OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS
1 NESTED LOOPS
1 TABLE ACCESS BY INDEX ROWID USER$
1 INDEX UNIQUE SCAN I_USER1 (object id 44)
1 TABLE ACCESS BY INDEX ROWID OBJ$
1 INDEX RANGE SCAN I_OBJ2 (object id 37)
0 TABLE ACCESS CLUSTER TAB$
1 INDEX UNIQUE SCAN I_OBJ# (object id 3)
0 TABLE ACCESS BY INDEX ROWID OBJ$
0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
0 TABLE ACCESS CLUSTER USER$
0 INDEX UNIQUE SCAN I_USER# (object id 11)
0 TABLE ACCESS CLUSTER SEG$
0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (object id 9)
0 TABLE ACCESS CLUSTER TS$
0 INDEX UNIQUE SCAN I_TS# (object id 7)
0 NESTED LOOPS
0 FIXED TABLE FULL X$KZSRO
0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
0 FIXED TABLE FULL X$KZSPR
0 FILTER
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS OUTER
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS
1 NESTED LOOPS
1 TABLE ACCESS BY INDEX ROWID USER$
1 INDEX UNIQUE SCAN I_USER1 (object id 44)
1 TABLE ACCESS BY INDEX ROWID OBJ$
1 INDEX RANGE SCAN I_OBJ2 (object id 37)
0 TABLE ACCESS CLUSTER TAB$
1 INDEX UNIQUE SCAN I_OBJ# (object id 3)
0 TABLE ACCESS CLUSTER TS$
0 INDEX UNIQUE SCAN I_TS# (object id 7)
0 TABLE ACCESS CLUSTER COL$
0 TABLE ACCESS CLUSTER COLTYPE$
0 TABLE ACCESS CLUSTER SEG$
0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (object id 9)
0 TABLE ACCESS BY INDEX ROWID OBJ$
0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
0 TABLE ACCESS CLUSTER USER$
0 INDEX UNIQUE SCAN I_USER# (object id 11)
0 TABLE ACCESS BY INDEX ROWID OBJ$
0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
0 TABLE ACCESS CLUSTER USER$
0 INDEX UNIQUE SCAN I_USER# (object id 11)
0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
0 TABLE ACCESS BY INDEX ROWID OBJ$
0 INDEX RANGE SCAN I_OBJ3 (object id 38)
0 TABLE ACCESS CLUSTER USER$
0 INDEX UNIQUE SCAN I_USER# (object id 11)
0 NESTED LOOPS
0 FIXED TABLE FULL X$KZSRO
0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
0 FIXED TABLE FULL X$KZSPR
1 FILTER
1 NESTED LOOPS
1 NESTED LOOPS OUTER
1 NESTED LOOPS
1 TABLE ACCESS BY INDEX ROWID USER$
1 INDEX UNIQUE SCAN I_USER1 (object id 44)
1 TABLE ACCESS BY INDEX ROWID OBJ$
1 INDEX RANGE SCAN I_OBJ2 (object id 37)
0 INDEX UNIQUE SCAN I_TYPED_VIEW1 (object id 105)
1 INDEX UNIQUE SCAN I_VIEW1 (object id 104)
0 NESTED LOOPS
0 FIXED TABLE FULL X$KZSRO
0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
0 FIXED TABLE FULL X$KZSPR
2 COLLECTION ITERATOR PICKLER FETCH
ALL_SDO_GEOM_METADATA is a view in the MDSYS schema (generated by Oracle ).
SELECT SDO_OWNER OWNER,
SDO_TABLE_NAME TABLE_NAME,
SDO_COLUMN_NAME COLUMN_NAME,
SDO_DIMINFO DIMINFO,
SDO_SRID SRID
FROM SDO_GEOM_METADATA_TABLE
WHERE
(exists
(select table_name from all_tables
where table_name=sdo_table_name
and owner = sdo_owner
union all
select table_name from all_object_tables
where table_name=sdo_table_name
and owner = sdo_owner
union all
select view_name table_name from all_views
where view_name=sdo_table_name
and owner = sdo_owner))
Statistics have been gathered for the MDSYS user.
If this had not been SYS schema I would have immediately concluded that fresh statistics are required. The SYS objects concerend are valid with all indexes
From my understanding you are not meant to gather stats for the SYS schema in Oracle 9 as Data Dictionary queries still uses RBO?
Any ideas as to why Oracle is doing full table scans when querying SYS tables? The optimizer_mode is set to FIRST_ROWS.
Any ideas greatly recevied.
Thanks

Maybe I'm missing something but this:
INDEX FULL SCAN SISESTAT I0_ESTRUTURA_COMERCIALindicates that one of those indexes is being used.
This:
T_ESTRUTURA_COMERCIALIs nowhere to be found in your Explain Plan. It appears that either you have posted the wrong plan
or Oracle is doing a query rewrite to a materialized view.

Interpret EXPLAIN PLAN TABLE OUTPUT

Please point me to some document to understand on how to interpret this data, especially " OUTLINE DATA ".
ORCL > explain plan for select * from hr.employees e, hr.departments d where e.department_id = d.department_id ;
Explained.
Elapsed: 00:00:00.11
ORCL > select plan_table_output from table (DBMS_XPLAN.DISPLAY(NULL, NULL, 'ADVANCED')) ;
PLAN_TABLE_OUTPUT
Plan hash value: 1343509718
| Id | Operation                    | Name        | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT             |             |   106 | 9540 |     6 (17)| 00:00:01 |
|   1 | MERGE JOIN                  |             |   106 | 9540 |     6 (17)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| DEPARTMENTS |    27 |   567 |     2   (0)| 00:00:01 |
|   3 |    INDEX FULL SCAN           | DEPT_ID_PK |    27 |       |     1   (0)| 00:00:01 |
|* 4 |   SORT JOIN                  |             |   107 | 7383 |     4 (25)| 00:00:01 |
|   5 |    TABLE ACCESS FULL         | EMPLOYEES   |   107 | 7383 |     3   (0)| 00:00:01 |
Query Block Name / Object Alias (identified by operation id):
   1 - SEL$1
   2 - SEL$1 / D@SEL$1
   3 - SEL$1 / D@SEL$1
   5 - SEL$1 / E@SEL$1
Outline Data
/*+
      BEGIN_OUTLINE_DATA
      USE_MERGE(@"SEL$1" "E"@"SEL$1")
      LEADING(@"SEL$1" "D"@"SEL$1" "E"@"SEL$1")
      FULL(@"SEL$1" "E"@"SEL$1")
      INDEX(@"SEL$1" "D"@"SEL$1" ("DEPARTMENTS"."DEPARTMENT_ID"))
      OUTLINE_LEAF(@"SEL$1")
      ALL_ROWS
      DB_VERSION('11.2.0.1')
      OPTIMIZER_FEATURES_ENABLE('11.2.0.1')
      IGNORE_OPTIM_EMBEDDED_HINTS
      END_OUTLINE_DATA
Predicate Information (identified by operation id):
   4 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")
       filter("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")
Column Projection Information (identified by operation id):
   1 - (#keys=0) "D"."DEPARTMENT_ID"[NUMBER,22], "E"."DEPARTMENT_ID"[NUMBER,22],
       "D"."LOCATION_ID"[NUMBER,22], "D"."DEPARTMENT_NAME"[VARCHAR2,30],
       "D"."MANAGER_ID"[NUMBER,22], "E"."EMPLOYEE_ID"[NUMBER,22],
       "E"."FIRST_NAME"[VARCHAR2,20], "E"."LAST_NAME"[VARCHAR2,25],
       "E"."EMAIL"[VARCHAR2,25], "E"."PHONE_NUMBER"[VARCHAR2,20], "E"."HIRE_DATE"[DATE,7],
       "E"."JOB_ID"[VARCHAR2,10], "E"."SALARY"[NUMBER,22],
       "E"."COMMISSION_PCT"[NUMBER,22], "E"."MANAGER_ID"[NUMBER,22]
   2 - "D"."DEPARTMENT_ID"[NUMBER,22], "D"."DEPARTMENT_NAME"[VARCHAR2,30],
       "D"."MANAGER_ID"[NUMBER,22], "D"."LOCATION_ID"[NUMBER,22]
   3 - "D".ROWID[ROWID,10], "D"."DEPARTMENT_ID"[NUMBER,22]
   4 - (#keys=1) "E"."DEPARTMENT_ID"[NUMBER,22], "E"."EMPLOYEE_ID"[NUMBER,22],
       "E"."FIRST_NAME"[VARCHAR2,20], "E"."LAST_NAME"[VARCHAR2,25],
       "E"."EMAIL"[VARCHAR2,25], "E"."PHONE_NUMBER"[VARCHAR2,20], "E"."HIRE_DATE"[DATE,7],
       "E"."JOB_ID"[VARCHAR2,10], "E"."SALARY"[NUMBER,22],
       "E"."COMMISSION_PCT"[NUMBER,22], "E"."MANAGER_ID"[NUMBER,22]
   5 - "E"."EMPLOYEE_ID"[NUMBER,22], "E"."FIRST_NAME"[VARCHAR2,20],
       "E"."LAST_NAME"[VARCHAR2,25], "E"."EMAIL"[VARCHAR2,25],
       "E"."PHONE_NUMBER"[VARCHAR2,20], "E"."HIRE_DATE"[DATE,7],
       "E"."JOB_ID"[VARCHAR2,10], "E"."SALARY"[NUMBER,22],
       "E"."COMMISSION_PCT"[NUMBER,22], "E"."MANAGER_ID"[NUMBER,22],
       "E"."DEPARTMENT_ID"[NUMBER,22]
68 rows selected.
/

"outline data" are a set of hints that enforce the use of the given plan.
The best source on interpreting plans (I know) is: http://antognini.ch/papers/InterpretingExecutionPlans_20091017.pdf
Regards
Martin

Partition of table n Explain plan

Similar Messages

Maybe you are looking for