Failed on Viewing an Explain Plan

I have some error while trying to show the query tree plan.
After I entered SQL commands and I click 'explain', it didn't show anything.
There suppose to be showing some kind of query tree right?
But it just a blank space.
Am I doing it wrong? Or there is some adjustment that I have to do before?
Thenks,
-Irene-

Similar Messages

Explain plan left the building

Hello guys, i have interesting problem, at least it seemed to me like that.
I am on 10.2.0.4.0 and for every statement i do explain plan i get the same plan ???.
Propably very known issue to some, but i didn't exeperienced that till now, so if somene have some advice, please share.
E.g.
SQL> explain plan for select user from dual;
Explained.
SQL> select * from table(dbms_xplan.display);
Plan hash value: 3995103059
| Id | Operation                    | Name           | Rows | Bytes | Cost (%CPU)| Time     | Inst   |
|   0 | SELECT STATEMENT REMOTE      |                |     1 |    96 | 97591   (5)| 00:05:07 |        |
|   1 | SORT ORDER BY               |                |     1 |    96 | 97591   (5)| 00:05:07 |        |
|* 2 |   TABLE ACCESS BY INDEX ROWID| CCONTACT_ALL   |     1 |    54 |     3   (0)| 00:00:01 | VIPBS~ |
|   3 |    NESTED LOOPS              |                |     1 |    96 | 97590   (5)| 00:05:07 |        |
|* 4 |     TABLE ACCESS FULL        | CUSTOMER_ALL   |     1 |    42 | 97587   (5)| 00:05:07 | VIPBS~ |
|* 5 |     INDEX RANGE SCAN         | PKCCONTACT_ALL |     1 |       |     2   (0)| 00:00:01 | VIPBS~ |
Predicate Information (identified by operation id):
   2 - filter("A1"."CCCONTRACT"='X')
   4 - filter((TO_NUMBER("A2"."CSCOMPTAXNO")=3007943362918 OR
              TO_NUMBER("A2"."PASSPORTNO")=0109965330447) AND (TO_NUMBER("A2"."CSLEVEL")=10 OR
              TO_NUMBER("A2"."CSLEVEL")=20 AND "A2"."TMCODE"<>59 AND "A2"."TMCODE"<>42 AND "A2"."TMCODE"<>61
              AND "A2"."TMCODE"<>11 AND "A2"."TMCODE"<>19) AND "A2"."CSTYPE"='a' AND "A2"."PAYMNTRESP"='X')
   5 - access("A1"."CUSTOMER_ID"="A2"."CUSTOMER_ID")
       filter("A1"."CUSTOMER_ID"<>0)
Note
   - 'PLAN_TABLE' is old version
   - fully remote statement
28 rows selected....so, it looks like i am doing all that just with select user from dual .... : ) ... ok
SQL> explain plan for
2 SELECT param_value
3 FROM ncis.cis_case_script_vars
4 WHERE case_id = 296645706 AND seq = 1 AND param_name = 'OHOPNAMT';
Explained.
SQL> select * from table(dbms_xplan.display);
Plan hash value: 3995103059
| Id | Operation                    | Name           | Rows | Bytes | Cost (%CPU)| Time     | Inst   |
|   0 | SELECT STATEMENT REMOTE      |                |     1 |    96 | 97591   (5)| 00:05:07 |        |
|   1 | SORT ORDER BY               |                |     1 |    96 | 97591   (5)| 00:05:07 |        |
|* 2 |   TABLE ACCESS BY INDEX ROWID| CCONTACT_ALL   |     1 |    54 |     3   (0)| 00:00:01 | VIPBS~ |
|   3 |    NESTED LOOPS              |                |     1 |    96 | 97590   (5)| 00:05:07 |        |
|* 4 |     TABLE ACCESS FULL        | CUSTOMER_ALL   |     1 |    42 | 97587   (5)| 00:05:07 | VIPBS~ |
|* 5 |     INDEX RANGE SCAN         | PKCCONTACT_ALL |     1 |       |     2   (0)| 00:00:01 | VIPBS~ |
Predicate Information (identified by operation id):
   2 - filter("A1"."CCCONTRACT"='X')
   4 - filter((TO_NUMBER("A2"."CSCOMPTAXNO")=3007943362918 OR
              TO_NUMBER("A2"."PASSPORTNO")=0109965330447) AND (TO_NUMBER("A2"."CSLEVEL")=10 OR
              TO_NUMBER("A2"."CSLEVEL")=20 AND "A2"."TMCODE"<>59 AND "A2"."TMCODE"<>42 AND "A2"."TMCODE"<>61
              AND "A2"."TMCODE"<>11 AND "A2"."TMCODE"<>19) AND "A2"."CSTYPE"='a' AND "A2"."PAYMNTRESP"='X')
   5 - access("A1"."CUSTOMER_ID"="A2"."CUSTOMER_ID")
       filter("A1"."CUSTOMER_ID"<>0)
Note
   - 'PLAN_TABLE' is old version
   - fully remote statement
28 rows selected.
SQL>..same plan for different sql...
..and now, i am trying to explain plan for several easy sqls but look...
SQL> explain plan for select * from all_objects where rownum < 2;
explain plan for select * from all_objects where rownum < 2
ERROR at line 1:
ORA-01039: insufficient privileges on underlying objects of the view
SQL> explain plan for select * from user_tables ;
explain plan for select * from user_tables
ERROR at line 1:
ORA-01039: insufficient privileges on underlying objects of the view
SQL> desc all_objects
Name                                                                    Null?    Type
OWNER                                                                   NOT NULL VARCHAR2(30)
OBJECT_NAME                                                             NOT NULL VARCHAR2(30)
SUBOBJECT_NAME                                                                   VARCHAR2(30)
OBJECT_ID                                                               NOT NULL NUMBER
DATA_OBJECT_ID                                                                   NUMBER
OBJECT_TYPE                                                                      VARCHAR2(19)
CREATED                                                                 NOT NULL DATE
LAST_DDL_TIME                                                           NOT NULL DATE
TIMESTAMP                                                                        VARCHAR2(19)
STATUS                                                                           VARCHAR2(7)
TEMPORARY                                                                        VARCHAR2(1)
GENERATED                                                                        VARCHAR2(1)
SECONDARY                                                                        VARCHAR2(1)...i can't figure this out... maybe i have to flush 'explain plan' ? it's ok if it sounds funny,im off with ideas..
then i tried to explain this sql:
SQL> explain plan for
2 SELECT param_value
3 FROM ncis.cis_case_script_vars
4 WHERE case_id = 296645706 AND seq = 1 AND param_name = 'OHOPNAMT';
Explained.
SQL> select * from table(dbms_xplan.display);
Plan hash value: 3995103059
| Id | Operation                    | Name           | Rows | Bytes | Cost (%CPU)| Time     | Inst   |
|   0 | SELECT STATEMENT REMOTE      |                |     1 |    96 | 97591   (5)| 00:05:07 |        |
|   1 | SORT ORDER BY               |                |     1 |    96 | 97591   (5)| 00:05:07 |        |
|* 2 |   TABLE ACCESS BY INDEX ROWID| CCONTACT_ALL   |     1 |    54 |     3   (0)| 00:00:01 | VIPBS~ |
|   3 |    NESTED LOOPS              |                |     1 |    96 | 97590   (5)| 00:05:07 |        |
|* 4 |     TABLE ACCESS FULL        | CUSTOMER_ALL   |     1 |    42 | 97587   (5)| 00:05:07 | VIPBS~ |
|* 5 |     INDEX RANGE SCAN         | PKCCONTACT_ALL |     1 |       |     2   (0)| 00:00:01 | VIPBS~ |
Predicate Information (identified by operation id):
   2 - filter("A1"."CCCONTRACT"='X')
   4 - filter((TO_NUMBER("A2"."CSCOMPTAXNO")=3007943362918 OR
              TO_NUMBER("A2"."PASSPORTNO")=0109965330447) AND (TO_NUMBER("A2"."CSLEVEL")=10 OR
              TO_NUMBER("A2"."CSLEVEL")=20 AND "A2"."TMCODE"<>59 AND "A2"."TMCODE"<>42 AND "A2"."TMCODE"<>61
              AND "A2"."TMCODE"<>11 AND "A2"."TMCODE"<>19) AND "A2"."CSTYPE"='a' AND "A2"."PAYMNTRESP"='X')
   5 - access("A1"."CUSTOMER_ID"="A2"."CUSTOMER_ID")
       filter("A1"."CUSTOMER_ID"<>0)
Note
   - 'PLAN_TABLE' is old version
   - fully remote statement
28 rows selected.
SQL>..and got the same plan again....
anyone with suggestons, anyone encountered this behaviour ?

Vili Dialis wrote:
Is there some way to force usage of one of them explicitly, how can i know which one is currently used ?
So what happend here ?
I am using what plan table of the above, and why that table generates always the same plan ?
*/To bypass the problem (probably), and to see how it happened (possibly) see http://jonathanlewis.wordpress.com/2010/01/25/old-plan_table/
Not sure why you keep getting the same plan, but dbms_xplan does a 'select where plan_id = (select max(plan_id) ..) so perhaps the plan_table(s) you keep using have an artificially high plan_id which is always getting selected. (You could try doing: delete from plan_table ; commit; )
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
A general reminder about "Forum Etiquette / Reward Points": http://forums.oracle.com/forums/ann.jspa?annID=718
If you never mark your questions as answered people will eventually decide that it's not worth trying to answer you because they will never know whether or not their answer has been of any use, or whether you even bothered to read it.
It is also important to mark answers that you thought helpful - again it lets other people know that you appreciate their help, but it also acts as a pointer for other people when they are researching the same question, moreover it means that when you mark a bad or wrong answer as helpful someone may be prompted to tell you (and the rest of the forum) what's so bad or wrong about the answer you found helpful.

DB Console - explain plan

Does anyone know if there is an explain plan functionality included in the DB Console GUI? Just curious. Thanks.

You can view the explain plan of the existing SQL's which are running or executed in a DB.
Click Performance --> Click on Top acitivity under Additional Monitoring Links --> click on the SQL_ID ( hash_value) of any specific SQL) Under Top SQL --> Click on Plan to view the execution plan.

How to switch to graphical explain plan

When I view an explain plan it is presented in a textualy. I would like to switch it to graphical but can not figure out how to. Anyone know how to make the switch?
Thanks,
Bill

Graphical representation is possible as long as you are using the SVG plugin.
I had installed the plugin but did not realize is was not working until I saw our primary dba's screen yesterday with the graphics.
I started looking around and realized that the SVG plugin was disabled in my browser by default. I enabled the plugin and now everything works.
Bill

Explain Plan for Materialized Views in 10g

I am verifying explain plan for few queries on 10g as compared to 9i I was wondering in Materialized Views queries MAT_VIEW ACCESS instead of TABLE ACCESS is it expected behaviour or am missing something?
Couldn't find information in 10g documentation
thanks in advance

I've put together a query for the v$sql_plan in 9iR2.
Depending on what you use, you can probably drop some columns (eg OTHER and partition columns) and you could drive it from the v$session by getting the hash_value from there for the sid you are interested in :
(select * from v$sql_plan where hash_value =
(select sql_hash_value from v$session where sid=:sid))
select level, optimizer, lpad('_',1*(level-1),'_')||operation operation,
options, object_owner||'.'||object_name obj_name, search_columns,
ltrim(to_char(cardinality,'999,999,999')) no_rows,
ltrim(to_char(bytes/1024,'999,999')) kbytes, cost tot_cost,
object_node link, id, parent_id, other_tag||':'||other other,
partition_start, partition_stop, cpu_cost, io_cost,
access_predicates, filter_predicates,
round(temp_space/(1024*1024),2) temp_space_mb
from (select * from v$sql_plan where hash_value = :hash_val)
start with id=0
connect by prior id = parent_id and prior child_number = child_number
order by child_number, id, position;

TS3988 I have an icloud account and I view my mail with Mail V5.2. I recieve my email but the senders get messages saying the delivery failed. Can anyone explain this or help me.

I have an icloud account and I view my mail with Mail V5.2. I recieve my email but the senders get messages saying the delivery failed. Can anyone explain this or help me.

Thank you for replying. Yes I deleted the old email address..

Explain plan when have a View

Hi
I have a query and trying to use INDEX with hint, but I no use when is a view, is there some way for to use it ?
SELECT /*+ INDEX(T1 I0_PS_COMPL_ESTRUT_COMERCIAL)
           INDEX(T2 I0_ESTRUTURA_COMERCIAL) */
        T2.CD_TIPO_ESTRUTURA_COMERCIAL,
        T2.CD_ESTRUTURA_COMERCIAL,
        T2.CD_GERENCIA_VENDA
FROM T_PS_COMPL_ESTRUT_COMERCIAL T1,
       T_ESTRUTURA_COMERCIAL       T2
WHERE T1.CD_TIPO_ESTRUTURA_COMERCIAL = T2.CD_TIPO_ESTRUTURA_COMERCIAL
AND   T1.CD_ESTRUTURA_COMERCIAL = T2.CD_ESTRUTURA_COMERCIAL
AND   T2.ID_ESTRUTURA_ATIVA = 1
AND   T1.ID_PROXIMIDADE = 2
ORDER BY 3,2
SELECT STATEMENT, GOAL = CHOOSE               74     534     27768     71          1
SORT ORDER BY               74     534     27768     71     SEL$F5BB74E1     1
HASH JOIN               73     534     27768     71          1
   MAT_VIEW ACCESS BY INDEX ROWID     SISESTAT     M_ESTRUTURA_COMERCIAL_CAD     69     1685     23590     68     SEL$F5BB74E1     1
    INDEX FULL SCAN     SISESTAT     I0_ESTRUTURA_COMERCIAL     10     3370          10     SEL$F5BB74E1     1
   REMOTE          T_PS_COMPL_ESTRUT_COMERCIAL     3     1069     40622     3     SEL$F5BB74E1     1

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.

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.

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

Problem to create Explain Plan and use XML Indexes. Plz follow scenario..

Hi,
Oracle Version - Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit
I have been able to reproduce the error as below:
Please run the following code in Schema1:
CREATE TABLE TNAME1
   DB_ID            VARCHAR2 (10 BYTE),
   DATA_ID          VARCHAR2 (10 BYTE),
   DATA_ID2         VARCHAR2 (10 BYTE),
   IDENTIFIER1      NUMBER (19) NOT NULL,
   ID1              NUMBER (10) NOT NULL,
   STATUS1          NUMBER (10) NOT NULL,
   TIME_STAMP       NUMBER (19) NOT NULL,
   OBJECT_ID        VARCHAR2 (40 BYTE) NOT NULL,
   OBJECT_NAME      VARCHAR2 (80 BYTE) NOT NULL,
   UNIQUE_ID        VARCHAR2 (255 BYTE),
   DATA_LIVE        CHAR (1 BYTE) NOT NULL,
   XML_MESSAGE      SYS.XMLTYPE,
   ID2              VARCHAR2 (255 BYTE) NOT NULL,
   FLAG1            CHAR (1 BYTE) NOT NULL,
   KEY1             VARCHAR2 (255 BYTE),
   HEADER1          VARCHAR2 (2000 BYTE) NOT NULL,
   VERSION2         VARCHAR2 (255 BYTE) NOT NULL,
   TYPE1            VARCHAR2 (15 BYTE),
   TIMESTAMP1   TIMESTAMP (6),
   SOURCE_NUMBER    NUMBER
XMLTYPE XML_MESSAGE STORE AS BINARY XML
PARTITION BY RANGE (TIMESTAMP1)
   (PARTITION MAX
       VALUES LESS THAN (MAXVALUE)
NOCOMPRESS
NOCACHE
ENABLE ROW MOVEMENT
begin
app_utils.drop_parameter('TNAME1_PAR');
end;
BEGIN
DBMS_XMLINDEX.REGISTERPARAMETER(
'TNAME1_PAR',
'PATH TABLE     TNAME1_RP_PT
                          PATHS (INCLUDE (            /abc:Msg/product/productType
                                                                /abc:Msg/Products/Owner
                                 NAMESPACE MAPPING (     xmlns:abc="Abc:Set"
END;
CREATE INDEX Indx_XPATH_TNAME1
   ON "TNAME1" (XML_MESSAGE)
   INDEXTYPE IS XDB.XMLINDEX PARAMETERS ( 'PARAM TNAME1_PAR' )
local;Then in Schema2, create
create synonym TNAME1 FOR SCHEMA1.TNAME1
SCHEMA1:
GRant All on TNAME1 to SCHEMA2Now in SCHEMA2, if we try:
Explain Plan for
SELECT xmltype.getclobval (XML_MESSAGE)
FROM TNAME1 t
WHERE XMLEXISTS (
'declare namespace abc="Abc:Set"; /abc:Msg/product/productType= ("1", "2") '
PASSING XML_MESSAGE);WE GET -> ORA-00942: table or view does not exist
whereas this works:
Explain Plan for
SELECT xmltype.getclobval (XML_MESSAGE)
FROM TNAME1 t- Please tell me, what is the reason behind it and how can I overcome it. It's causing all my views based on this condition to fail in another schema i.e. not picking up the XMLIndexes.
Also
SELECT * from DBA_XML_TAB_COLS WHERE TABLE_NAME like 'TNAME1';Output is like:
OWNER, || TABLE_NAME, || COLUMN_NAME, || XMLSCHEMA || SCHEMA_OWNER, || ELEMENT_NAME, || STORAGE_TYPE, || ANYSCHEMA, || NONSCHEMA
SCHEMA1 || TNAME1 ||     XML_MESSAGE ||          ||          || BINARY     || NO     || YES ||
SCHEMA1 || TNAME1 ||     SYS_NC00025$ ||          ||          || CLOB     ||     ||
- Can I change AnySchema to YES from NO for -column_name = XML_MESSAGE ? May be that will solve my problem.
- SYS_NC00025$ is the XML Index, Why don't I get any values for ANYSCHEMA, NONSCHEMA on it. Is this what is causing the problem.
Kindly suggest.. Thanks..

The problem sounds familiar. Please create a SR on http://support.oracle.com for this one.

Problems with explain plan and statement

Hi community,
I have migrated a j2ee application from DB2 to Oracle.
First some facts of our application and database instance:
We are using oracle version 10.2.0.3 and driver version 10.2.0.3. It runs with charset Unicode 3.0 UTF-8.
Our application is using Tomcat as web container and jboss as application server. We are only using prepared statements. So if I talk about statements I always mean prepared statements. Also our application is setting the defaultNChar property to true because every char and varchar field has been created as an nchar and nvarchar.
We have some jsp sites that contains lists with search forms. Everytime I enter a value to the form that returns a filled resultset, the lists are performing great. But everytime I enter a value that returns an empty resultset, the lists are 100 times slower. The jsp sites are running in the tomcat environment and submitting their statements directly to the database. The connections are pooled by dbcp. So what can cause this behaviour??
To anaylze this problem I started logging all statements and filled-in search field values and combinations that are executed by the lists described above. I also developed a standalone helper tool that reads the logged statements, executes them to the database and generates an explain plan for every statement. But now there appears a strange situation. Every statement, that performs really fast within our application, is now executed by the helper tool extremely slow. So I edited some jsp pages within our application to force an explain plan from there (tomcat env). So when I'm executing the same statement I'm getting with the exactly same code two completely different explain plans.
First the statement itself:
select LINVIN.BBASE , INVINNUM , INVINNUMALT , LINVIN.LSUPPLIERNUM , LSUPPLIERNUMEXT , LINVIN.COMPANYCODE , ACCOUNT , INVINTXT , INVINSTS , INVINTYP , INVINDAT , RECEIPTDAT , POSTED , POSTINGDATE , CHECKCOSTCENTER , WORKFLOWIDEXT , INVINREFERENCE , RESPONSIBLEPERS , INVINSUM_V , INVINSUMGROSS_V , VOUCHERNUM , HASPOSITIONS , PROCESSINSTANCEID , FCURISO_V , LSUPPLIER.AADDRLINE1 from LINVIN, LSUPPLIER where LINVIN.BBASE = LSUPPLIER.BBASE and LINVIN.LSUPPLIERNUM = LSUPPLIER.LSUPPLIERNUM and LINVIN.BBASE = ? order by LINVIN.BBASE, INVINDAT DESC
Now the explain plan from our application:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 101 | 28583 | 55 (0)| 00:00:01 |
| 1 | NESTED LOOPS | | 101 | 28583 | 55 (0)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| LINVIN | 93709 | 12M| 25 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | LINV_INVDAT | 101 | | 1 (0)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| LSUPPLIER | 1 | 148 | 1 (0)| 00:00:01 |
|* 5 | INDEX UNIQUE SCAN | PK_177597 | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("LINVIN"."BBASE"=:1)
filter("LINVIN"."BBASE"=:1)
5 - access("LSUPPLIER"."BBASE"=:1 AND "LINVIN"."LSUPPLIERNUM"="LSUPPLIER"."LSUPPLIERNUM")
Now the one from the standalone tool:
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 93773 | 25M| | 12898 (1)| 00:02:35 |
| 1 | SORT ORDER BY | | 93773 | 25M| 61M| 12898 (1)| 00:02:35 |
|* 2 | HASH JOIN | | 93773 | 25M| 2592K| 7185 (1)| 00:01:27 |
| 3 | TABLE ACCESS BY INDEX ROWID| LSUPPLIER | 16540 | 2390K| | 332 (0)| 00:00:04 |
|* 4 | INDEX RANGE SCAN | LSUPPLIER_HAS_BASE_FK | 16540 | | | 11 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID| LINVIN | 93709 | 12M| | 6073 (1)| 00:01:13 |
|* 6 | INDEX RANGE SCAN | LINVOICE_BMDT_FK | 93709 | | | 84 (2)| 00:00:02 |
Predicate Information (identified by operation id):
2 - access("LINVIN"."BBASE"="LSUPPLIER"."BBASE" AND "LINVIN"."LSUPPLIERNUM"="LSUPPLIER"."LSUPPLIERNUM")
4 - access("LSUPPLIER"."BBASE"=:1)
6 - access("LINVIN"."BBASE"=:1)
The size of the tables are: LINVIN - 383.692 Rows, LSUPPLIER - 115.782 Rows
As you can see the one executed from our application is much faster than the one from the helper tool. So why picks oracle a completely different explain plan for the same statement? An why is a hash join much slower than a nested loop? Because If I'm right a nested loop should only be used when the tables are pretty small..
I also tried to play with some parameters:
I set optimizer_index_caching to 100 and optimizer_index_cost_adj to 30. I also changed optimizer_mode to FIRST_ROWS_100.
I would really appreciated, if somebody can help me with this issue, because I'm really getting more and more distressed...
Thanks in advance,
Tobias
Edited by: tobiwan on Sep 3, 2008 11:49 PM
Edited by: tobiwan on Sep 3, 2008 11:50 PM
Edited by: tobiwan on Sep 4, 2008 12:01 AM
Edited by: tobiwan on Sep 4, 2008 12:02 AM
Edited by: tobiwan on Sep 4, 2008 12:04 AM
Edited by: tobiwan on Sep 4, 2008 12:06 AM
Edited by: tobiwan on Sep 4, 2008 12:06 AM
Edited by: tobiwan on Sep 4, 2008 12:07 AM

tobiwan wrote:
Hi again,
Here ist the answer:
The problem, because I got two different explain plans, was that the external tool uses the NLS sesssion parameters coming from the OS which are in my case "de/DE".
Within our application these parameters are changed to "en/US"!! So if I'm calling in my external tool the java function Locale.setDefault(new Locale("en","US")) before connecting to the database the explain plans are finally equal.That might explain why you got two different execution plan, because one plan was obviously able to avoid a SORT ORDER BY operation, whereas the second plan required to run SORT ORDER BY operation, obviously because of the different NLS_SORT settings. An index by default uses the NLS_SORT = 'binary' order whereas ORDER BY obeys the NLS_SORT setting, which probably was set to 'GERMAN' in your "external tool" case. You can check the "NLS_SESSION_PARAMETERS" view to check your current NLS_SORT setting.
For more information regarding this issue, see my blog note I've written about this some time ago:
http://oracle-randolf.blogspot.com/2008/09/getting-first-rows-of-large-sorted.html
Now let me make a guess why you observe the behaviour that it takes so long if your result set is empty:
The plan avoiding the SORT ORDER BY is able to return the first rows of the result set very quickly, but could take quite a while until all rows are processed, since it requires potentially a lot of iterations of the loop until everything has been processed. Your front end probably by default only display the first n rows of the result set and therefore works fine with this execution plan.
Now if the result set is empty, depending on your data, indexes and search criteria, Oracle has to work through all the data using the inefficient NESTED LOOP approach only to find out that no data has been found, and since your application attempts to fetch the first n records, but no records will be found, it has to wait until all data has been processed.
You can try to reproduce this by deliberately fetching all records of a query that returns data and that uses the NESTED LOOP approach... It probably takes as long as in the case when no records are found.
Note that you seem to use bind variables and 10g, therefore you might be interested that due to the "bind variable peeking" functionality you might potentially end up with "unstable" plans depending on the values "peeked" when the statement is parsed.
For more information, see this comprehensive description of the issue:
http://www.pythian.com/blogs/867/stabilize-oracle-10gs-bind-peeking-behaviour-by-cutting-histograms
Note that this changes in 11g with the introduction of the "Adaptive Cursor Sharing".
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

Not Understanding the filter in Explain Plan - filter(NULL IS NOT NULL)

Hi All,
Request your help in understanding the below scenario. (I am not aware of teh application and table details. Just trying to help my friend)
SQL> conn
Enter user-name: [email protected]
Enter password:
Connected.
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
PL/SQL Release 10.2.0.3.0 - Production
CORE    10.2.0.3.0      Production
TNS for Linux: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production
--Checking the count in PO_LINES
SQL> select count(*) from po_lines;
COUNT(*)
         0
--PO_LINES is a synonym
SQL> select object_type,owner from dba_objects where object_name = 'PO_LINES';
OBJECT_TYPE         OWNER
SYNONYM             APPS
--The synonym is pointing to PO.PO_LINES_ALL
SQL> select * from user_synonyms where synonym_name = 'PO_LINES';
SYNONYM_NAME                   TABLE_OWNER                    TABLE_NAME                     DB_LINK
PO_LINES                       PO                             PO_LINES_ALL
--But when counting PO.PO_LINES_ALL I am getting different result
SQL> select count(*) c from po.po_lines_all;
         C
      8828
--Explain plan of teh original query is
SQL> explain plan for
2 select
3 * from po_lines;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation          | Name         | Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT   |              |     1 |   252 |     0   (0)|
|* 1 | FILTER            |              |       |       |            |
|   2 |   TABLE ACCESS FULL| PO_LINES_ALL | 8796 | 2164K|   106   (4)|
Predicate Information (identified by operation id):
   1 - filter(NULL IS NOT NULL)
--Now the object PO.PO_LINES_ALL is TABLE, not an mview.
SQL> select object_type,owner from dba_objects where object_name = 'PO_LINES_ALL';
OBJECT_TYPE         OWNER
TABLE               POSeek your help in understanding what is happening here.
Thanks in Advance,
jeneesh

Next time, prefix with APPS. when you show us the explain plan:
SQL> explain plan for
2 select
3 * from apps.po_lines; -- added the prefix of owner.Just like you prefixed with PO. when you showed us the query on PO_LINES_ALL. It ensures that you are using the synonym which you showed us.
Btw. PO_LINES_ALL, could still be a VIEW given your overview of the situation.
Anyway a filter "NULL IS NOT NULL" is indicative that the optimizer performed something called semantic query optimization (SQO).
SQO is the process of deducing new predicates based upon a) existing predicates in your query (which there is none), b) added predicates to your query (eg. by a VPD policy function), and c) declared constraints on the tables invovled in your query.
A typical example of when a "NOT is NOT NULL" predicate will show up is when for instance in the EMP table there is a declared constraint on EMPNO like this:
check(EMPNO > 0)And your query would hold a predicate that is inconsistent with the constraint, for instance like this:
select *
from EMP
where EMPNO <= 0Oracle will deduce that EMPNO cannot be both greater than zero (constraint) as well as smaller than or equal to zero (your query predicate), and will transform the query into:
select *
from EMP
where EMPNO <= 0
and NULL is NOT NULLThus preventing accessing the EMP table all together, and immediately returning this query with no data found.
Edited by: Toon Koppelaars on Mar 15, 2010 7:17 AM

Filter(NULL IS NOT NULL) in Explain Plan ??

Hi All,
Can someone please explain what this explain plan statement means? I see a filter(NULL IS NOT NULL) as the first statement - could not figure out why it came up so from googling.
My Query Used:
EXPLAIN PLAN FOR
MERGE INTO summary_bysrccd
USING
(SELECT LAST_DAY(TRUNC(to_timestamp(os.requestdatetime, 'yyyymmddhh24:mi:ss.ff4'))) AS SUMMARY_DATE,
os.acctnum,
ol.sourcecode AS sourcecode,
ol.sourcename AS sourcename,
count(1) cnt_articleview
FROM article_views os , master_sourcecode ol
where os.sourcecode = ol.sourcecode
AND os.acctnum IS NOT NULL
AND ol.sourcecode IS NOT NULL
AND os.requestdatetime IS NOT NULL
AND UPPER(os.success_ind) = 'S'
     AND (
          ('INCR' = 'FULL'
          AND (get_date_timestamp(os.requestdatetime) BETWEEN TO_DATE('23-AUG-2011 00:00:00','DD-MON-YYYY HH24:MI:SS') AND TO_DATE('27-AUG-2011 23:59:59','DD-MON-YYYY HH24:MI:SS')
          AND   os.entry_CreatedDate BETWEEN TO_DATE('22-AUG-2011 00:00:00','DD-MON-YYYY HH24:MI:SS') AND TO_DATE('28-AUG-2011 00:00:00','DD-MON-YYYY HH24:MI:SS')
          OR ('INCR' = 'FULL'
          AND os.entry_createddate BETWEEN TO_DATE('23-AUG-2011 00:00:00','DD-MON-YYYY HH24:MI:SS') AND TO_DATE('27-AUG-2011 23:59:59','DD-MON-YYYY HH24:MI:SS') )
group by LAST_DAY(TRUNC(to_timestamp(os.requestdatetime, 'yyyymmddhh24:mi:ss.ff4'))),
os.acctnum,ol.sourcecode,ol.sourcename) mrg_query
ON (ods_av_summary_bysrccd.acctnum = mrg_query.acctnum AND
ods_av_summary_bysrccd.summary_date=mrg_query.summary_date AND
ods_av_summary_bysrccd.sourcecode=mrg_query.sourcecode)
WHEN NOT MATCHED THEN
INSERT (SUMMARY_date,ACCTNUM,SOURCECODE,SOURCENAME,CNT_ARTICLEVIEW,ENTRY_LASTUPDATEDDATE)
VALUES(mrg_query.summary_date,mrg_query.acctnum,mrg_query.sourcecode,mrg_query.sourcename,
mrg_query.cnt_articleview,sysdate)
WHEN MATCHED THEN
UPDATE SET ods_av_summary_bysrccd.cnt_articleview=
CASE WHEN NVL('INCR','INCR') = 'FULL' THEN mrg_query.cnt_articleview
ELSE ods_av_summary_bysrccd.cnt_articleview+mrg_query.cnt_articleview
END,
ods_av_summary_bysrccd.entry_lastupdateddate=sysdate;My Explain Plan:
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 268591246
| Id | Operation                                 | Name                      | Rows | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | MERGE STATEMENT                           |                           |     1 |   456 |       |     3   (0)| 00:00:01 |       |       |
|   1 | MERGE                                    | ODS_AV_SUMMARY_BYSRCCD    |       |       |       |            |          |       |       |
|   2 |   VIEW                                    |                           |       |       |       |            |          |       |       |
|   3 |    NESTED LOOPS OUTER                     |                           |     1 |   417 |       |     3   (0)| 00:00:01 |       |       |
|   4 |     VIEW                                  |                           |     1 |   360 |       |     5 (100)| 00:00:01 |       |       |
|   5 |      SORT GROUP BY                        |                           |     1 |    73 |   595M|            |          |       |       |
PLAN_TABLE_OUTPUT
|* 6 |       FILTER                              |                           |       |       |       |            |          |       |       |
|* 7 |        HASH JOIN                          |                           | 6975K|   485M| 3944K| 17594   (1)| 00:03:32 |       |       |
|   8 |         TABLE ACCESS FULL                 | ODS_MASTER_SOURCECODE     | 84021 | 2953K|       |   273   (1)| 00:00:04 |       |       |
|* 9 |         TABLE ACCESS BY GLOBAL INDEX ROWID| ODS_ARTICLE_VIEWS         | 7007K|   247M|       |   826   (0)| 00:00:10 |    33 |    33 |
|* 10 |          INDEX FULL SCAN                  | IDX_AV_ACCTNUM            |    25M|       |       |    26   (0)| 00:00:01 |       |       |
| 11 |     TABLE ACCESS BY GLOBAL INDEX ROWID    | ODS_AV_SUMMARY_BYSRCCD    |     1 |    57 |       |     3   (0)| 00:00:01 | ROWID | ROWID |
|* 12 |      INDEX UNIQUE SCAN                    | ODS_AV_SUMMARY_BYSRCCD_PK |     1 |       |       |     2   (0)| 00:00:01 |       |       |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   6 - filter(NULL IS NOT NULL)
   7 - access("OS"."SOURCECODE"="OL"."SOURCECODE")
   9 - filter("OS"."REQUESTDATETIME" IS NOT NULL AND "OS"."ENTRY_CREATEDDATE">=TO_DATE(' 2011-08-23 00:00:00', 'syyyy-mm-dd
              hh24:mi:ss') AND "OS"."ENTRY_CREATEDDATE"<=TO_DATE(' 2011-08-27 23:59:59', 'syyyy-mm-dd hh24:mi:ss') AND UPPER("OS"."SUCCESS_IND")='S')
10 - filter("OS"."ACCTNUM" IS NOT NULL)
12 - access("ODS_AV_SUMMARY_BYSRCCD"."SUMMARY_DATE"(+)=INTERNAL_FUNCTION("MRG_QUERY"."SUMMARY_DATE") AND
              "ODS_AV_SUMMARY_BYSRCCD"."ACCTNUM"(+)="MRG_QUERY"."ACCTNUM" AND "ODS_AV_SUMMARY_BYSRCCD"."SOURCECODE"(+)="MRG_QUERY"."SOURCECODE")
Note
PLAN_TABLE_OUTPUT
   - dynamic sampling used for this statement

Hi Toon,
Thanks for the quick resolution. I went back and verified the table's colunm details and it has a NOT NULL constraint.
Regards,
Chaitanya
P.S: Is it ok if I ask you for some help regarding a production issue I have been encountering since 15 days but haev no clear resolution yet about what/why is the reason (the said issue is neither uniform nor regular - its affecting some modules and happening on some days - i shall give the full details if you are willing to have a look) - i shall start a new post or email you directly - yur convenience.

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

What are the privileges required for explain plan in Oracle 11g database

I am facing the problem in doing a explain plan for a view in Oracle 11g database. When I select from the view like this:
select * from zonewisearpu
It does a select on the view but when I give explain plan like
explain plan for
select * from zonewisearpu
I get the error like insufficient privileges.
Please let me know if things are getting missed out as I guess system level privileges are required to execute this.
I hope, my question is clear.
It’s a humble request to revert urgently if possible as I need to complete a task and do not know the way out.
Regards

975148 wrote:
Thanks for your reply. I have found out that an explain plan is possible on the user's own objects and is not possible on the granted objects from a different schema. For eg, if I do a explain plan on a view querying on tables from a different view, it would not allow the explain plan to proceed. This could mean that explain plan needs different privileges than just a select.
Requesting for a revert to this.
Here is a simple test case that I have perfomed
SQL> create user test1 identified by test1;
User created.
SQL> create user test2 identified by test1;
User created.
SQL> grant connect, resource to test1,test2;
Grant succeeded.
SQL> create table test1.tab1 as select * from v$session;
Table created.
SQL> connect test2/test1
Conencted.
SQL> show user
USER is "TEST2"
SQL>
SQL> explain plan for
2 select sid,serial#,status,username from test1.tab1 where username<> '';
Explained.
SQL>
So, as can be seen I am able to do a explain plan from user test2 for tables belong to user test1.
As far as privileges are concerned, following is the list
SQL> select * from dba_role_privs where grantee in ('TEST1','TEST2') order by 1;
GRANTEE                        GRANTED_ROLE                   ADM DEF
TEST1                          CONNECT                        NO YES
TEST1                          RESOURCE                       NO YES
TEST2                          CONNECT                        NO YES
TEST2                          RESOURCE                       NO YES
SQL>
SQL> select grantee,owner,table_name,privilege from dba_tab_privs where grantee in ('TEST1','TEST2') order by 1;
GRANTEE    OWNER      TABLE_NAME           PRIVILEGE
TEST2      TEST1      TAB1                 SELECT
SQL>
SQL> select * from dba_sys_privs where grantee in ('TEST1','TEST2') order by 1;
GRANTEE    PRIVILEGE                      ADM
TEST1      UNLIMITED TABLESPACE           NO
TEST2      UNLIMITED TABLESPACE           NO
SQL>

Failed on Viewing an Explain Plan

Similar Messages

Maybe you are looking for