Subquery Unnest Restrictions

Whenever oracle make a hard parse ,will consider subquery unnest and view merge during query merge ,but what are subquery Unnesting Restrictions,when oracle can't make subquery unnest ???

I am not sure that I understand the question.
In general, Oracle cannot unnest a subquery if doing so would change (or would potentially change) the results. The classic example here is when the subquery contains something like the ROWNUM function or some sort of aggregate. If you have
SELECT e.empno, d.deptno, d.rn
  FROM (SELECT deptno, dname, rownum rn
        FROM dept) d,
       emp e
WHERE e.deptno = d.deptnothe subquery cannot be unnested because you only want the ROWNUM pseudocolumn evaluated for the rows in the subquery, not all the rows that the entire query would return.
Justin

Similar Messages

  • Using collection list in subquery to restrict rows

    How can I use a collection list in a subquery?
    Something like this:
    TYPE listOfIDs_t IS TABLE OF NUMBER;
    v_listOfIDs_arr listOfIDs_t;
    CURSOR c1 IS
    SELECT *
    FROM tbl
    WHERE id IN (SELECT column_value
    FROM TABLE ( CAST(v_listOfIDs_arr AS listOfIDs_t ))
    When I try something like this, I get "invalid datatype" on the collection type, listOfIDs_t. Any suggestions? Basically, I want to use the list of values in my collection to restrict my cursor/query without having to loop through my collection and execute the cursor/query each time.

    PL/SQL is two languages. PL is a programming language based on ADA. It is a formal procedural declarative language. It is "Turing complete". SQL is neither - not procedural and not Turing complete.
    PL/SQL mashes these two in a single integrated coding environment - you can write and mix PL and SQL code and the PL engine will figure out where it needs to make calls to the SQL engine, what PL variables it need to pass to the SQL engine (using SQL bind variables) and so on.
    Now you define a structure in the PL engine. The structure resides in the PL engine memory area (the process global area or PGA).
    You now want to pass that structure to the SQL engine and run SQL on it. The SQL engine cannot reference that local PL variable directly. PL has to copy it into the SQL engine.. as what?
    The SQL engine only supports SQL data types. The SQL engine does not know of the PL engine's existence. Just like it does not know about Java, C/C++, Delphi, C#, Visual Basic etc. Nor does the SQL engine support data types of these languages.
    All these languages, including PL, supports the SQL engine in some form or another. Via ODBC, BDE, OCI, JDBC, etc.
    Okay, now how does PL pass that local PL structure to the SQL engine? It cannot. That is a custom PL structure. It can contain (and often does) have features that are not supported by the SQL engine. Like boolean fields.
    What PL can do and does support is SQL data types. Including user defined data types. And these it can use itself natively inside PL (as you also can as objects in Delphi, Java etc).
    And these it can also pass back to the SQL engine for processing.
    That all said - the best place for data is inside the SQL engine (i.e. in tables). It is not the best of ideas to create data structures in PL and then continually pass (copy) these to the SQL engine to run SQLs against. It is slow. It does not scale.
    So make sure that you have sound technical reasons when actually doing this - creating a PL variable of a SQL table type, stuffing data into it, and then running SQLs on it.

  • Subquery Unnesting issue

    select *from v$version;
    BANNER
    Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
    PL/SQL Release 11.1.0.7.0 - Production
    CORE    11.1.0.7.0      Production
    TNS for Linux: Version 11.1.0.7.0 - Production
    NLSRTL Version 11.1.0.7.0 - ProductionSQL
    DELETE FROM A
        WHERE TR_STATUS IN ('C', 'R')
         OR A.TAX_AUDIT_RECORD_ID IN ( SELECT B.TAX_AUDIT_RECORD_ID FROM B WHERE A.TAX_AUDIT_RECORD_ID = B.TAX_AUDIT_RECORD_ID);Current execution plan
    | Id  | Operation                            | Name                      | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ  |IN-OUT| PQ Distrib |
    |   0 | DELETE STATEMENT                     |                           |  5639K|   123M| 14156   (1)| 00:02:50 |       |       |        |      |            |
    |   1 |  PX COORDINATOR                      |                           |       |       |            |          |       |       |        |      |            |
    |   2 |   PX SEND QC (RANDOM)                | :TQ20002                  |  5639K|   123M| 14156   (1)| 00:02:50 |       |       |  Q2,02 | P->S | QC (RAND)  |
    |   3 |    INDEX MAINTENANCE                 | A                               |       |       |            |          |       |       |  Q2,02 | PCWP |            |
    |   4 |     PX RECEIVE                       |                           |  5639K|   123M| 14156   (1)| 00:02:50 |       |       |  Q2,02 | PCWP |            |
    |   5 |      PX SEND RANGE                   | :TQ20001                  |  5639K|   123M| 14156   (1)| 00:02:50 |       |       |  Q2,01 | P->P | RANGE      |
    |   6 |       DELETE                         | A                               |       |       |            |          |       |       |  Q2,01 | PCWP |            |
    |   7 |        BUFFER SORT                   |                           |       |       |            |          |       |       |  Q2,01 | PCWC |            |
    |   8 |         PX RECEIVE                   |                           |  5639K|   123M| 14156   (1)| 00:02:50 |       |       |  Q2,01 | PCWP |            |
    |   9 |          PX SEND HASH (BLOCK ADDRESS)| :TQ20000                  |  5639K|   123M| 14156   (1)| 00:02:50 |       |       |        | S->P | HASH (BLOCK|
    |* 10 |           FILTER                     |                           |       |       |            |          |       |       |        |      |            |
    |  11 |            PX COORDINATOR            |                           |       |       |            |          |       |       |        |      |            |
    |  12 |             PX SEND QC (RANDOM)      | :TQ10000                  |  5639K|   123M| 14156   (1)| 00:02:50 |       |       |  Q1,00 | P->S | QC (RAND)  |
    |  13 |              PX BLOCK ITERATOR       |                           |  5639K|   123M| 14156   (1)| 00:02:50 |     1 |    32 |  Q1,00 | PCWC |            |
    |  14 |               TABLE ACCESS FULL      | B                               |  5639K|   123M| 14156   (1)| 00:02:50 |     1 |    32 |  Q1,00 | PCWP |            |
    |  15 |            PARTITION RANGE ALL       |                           |     1 |    21 |     3   (0)| 00:00:01 |     1 |     8 |        |      |            |
    |* 16 |             INDEX RANGE SCAN         | PK_B                              |     1 |    21 |     3   (0)| 00:00:01 |     1 |     8 |        |      |            |
    Predicate Information (identified by operation id):
      10 - filter("A"."TR_STATUS"='C' OR "A"."TR_STATUS"='R' OR  EXISTS (SELECT 0 FROM "B"  WHERE
                  "B"."TAX_AUDIT_RECORD_ID"=:B1))
      16 - access("B"."TAX_AUDIT_RECORD_ID"=:B1)There is no relationship (pk/fk) between both of these tables. PK are being populated by an oracle sequence in both the tables. There are lot of matching ids in both the tables though (1Million).
    I dont know why Oracle is using FILTER instead of using join methods. I tried using USE_HASH, USE_NL, USE_SJ, but no luck.
    Join column (TAX_AUDIT_RECORD_ID) is NOT NULL in both table definition.
    I even tried UNNEST hint in sub-query, but again, i did not get any success.

    Thanks very much Jonathan for your pointer. (I am regular reader of your blog and wondering how come i missed this one !)
    I am getting below error while using LNNVL function:
    explain plan for
    DELETE  FROM A tars where rowid in
         (select  rowid from A where TR_STATUS IN ('C', 'R')
         union all
         select rowid from A tars where exists
         (SELECT  null FROM B taxar WHERE B.TAX_AUDIT_RECORD_ID = A.TAX_AUDIT_RECORD_ID)
         and lnnvl(A.TR_STATUS IN ('C', 'R')));
    ORA-13207: incorrect use of the [LNNVL] operatorWould i expect same result(row count) with/without this function ?
    However, If i remove LNNVL,i get below plan :
    Plan hash value: 1196139345
    | Id  | Operation                                   | Name                      | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ  |IN-OUT| PQ Distrib |
    |   0 | DELETE STATEMENT                            |                           |   513G|    21T|  1434K (77)| 04:46:49 |       |       |        |      |            |
    |   1 |  PX COORDINATOR                             |                           |       |       |            |          |       |       |        |      |            |
    |   2 |   PX SEND QC (RANDOM)                       | :TQ10006                  |   513G|    21T|  1434K (77)| 04:46:49 |       |       |  Q1,06 | P->S | QC (RAND)  |
    |   3 |    INDEX MAINTENANCE                        | A                                |       |       |            |          |       |  Q1,06 | PCWP  |      |            |
    |   4 |     PX RECEIVE                              |                           |   513G|    21T|  1434K (77)| 04:46:49 |       |       |  Q1,06 | PCWP |            |
    |   5 |      PX SEND RANGE                          | :TQ10005                  |   513G|    21T|  1434K (77)| 04:46:49 |       |       |  Q1,05 | P->P | RANGE      |
    |   6 |       DELETE                                | A                         |       |       |            |          |       |       |  Q1,05 | PCWP |            |
    |   7 |        PX RECEIVE                           |                           |   513G|    21T|  1434K (77)| 04:46:49 |       |       |  Q1,05 | PCWP |            |
    |   8 |         PX SEND HASH (BLOCK ADDRESS)        | :TQ10004                  |   513G|    21T|  1434K (77)| 04:46:49 |       |       |  Q1,04 | P->P | HASH (BLOCK|
    |*  9 |          HASH JOIN BUFFERED                 |                           |   513G|    21T|  1434K (77)| 04:46:49 |       |       |  Q1,04 | PCWP |            |
    |  10 |           PX RECEIVE                        |                           |  5069K|   159M| 17222   (1)| 00:03:27 |       |       |  Q1,04 | PCWP |            |
    |  11 |            PX SEND HASH                     | :TQ10002                  |  5069K|   159M| 17222   (1)| 00:03:27 |       |       |  Q1,02 | P->P | HASH       |
    |  12 |             PX BLOCK ITERATOR               |                           |  5069K|   159M| 17222   (1)| 00:03:27 |     1 |    32 |  Q1,02 | PCWC |            |
    |  13 |              TABLE ACCESS FULL              | A                         |  5069K|   159M| 17222   (1)| 00:03:27 |     1 |    32 |  Q1,02 | PCWP |            |
    |  14 |           PX RECEIVE                        |                           |    10M|   116M|   322K  (3)| 01:04:35 |       |       |  Q1,04 | PCWP |            |
    |  15 |            PX SEND HASH                     | :TQ10003                  |    10M|   116M|   322K  (3)| 01:04:35 |       |       |  Q1,03 | P->P | HASH       |
    |  16 |             VIEW                            | VW_NSO_1                  |    10M|   116M|   322K  (3)| 01:04:35 |       |       |  Q1,03 | PCWP |            |
    |  17 |              SORT UNIQUE                    |                           |    10M|   338M|   322K (95)| 01:04:35 |       |       |  Q1,03 | PCWP |            |
    |  18 |               PX RECEIVE                    |                           |       |       |            |          |       |       |  Q1,03 | PCWP |            |
    |  19 |                PX SEND HASH                 | :TQ10001                  |       |       |            |          |       |       |  Q1,01 | P->P | HASH       |
    |  20 |                 BUFFER SORT                 |                           |   513G|    21T|            |          |       |       |  Q1,01 | PCWP |            |
    |  21 |                  UNION-ALL                  |                           |       |       |            |          |       |       |  Q1,01 | PCWP |            |
    |  22 |                   PX BLOCK ITERATOR         |                           |  5069K|    67M| 17275   (1)| 00:03:28 |     1 |    32 |  Q1,01 | PCWC |            |
    |* 23 |                    TABLE ACCESS FULL        | A                         |  5069K|    67M| 17275   (1)| 00:03:28 |     1 |    32 |  Q1,01 | PCWP |            |
    |* 24 |                   HASH JOIN SEMI            |                           |  5069K|   270M|   305K  (4)| 01:01:08 |       |       |  Q1,01 | PCWP |            |
    |  25 |                    PX BLOCK ITERATOR        |                           |  5069K|   169M| 17275   (1)| 00:03:28 |     1 |    32 |  Q1,01 | PCWC |            |
    |* 26 |                     TABLE ACCESS FULL       | A                         |  5069K|   169M| 17275   (1)| 00:03:28 |     1 |    32 |  Q1,01 | PCWP |            |
    |  27 |                    BUFFER SORT              |                           |       |       |            |          |       |       |  Q1,01 | PCWC |            |
    |  28 |                     PX RECEIVE              |                           |   276M|  5547M|   287K  (4)| 00:57:34 |       |       |  Q1,01 | PCWP |            |
    |  29 |                      PX SEND BROADCAST LOCAL| :TQ10000                  |   276M|  5547M|   287K  (4)| 00:57:34 |       |       |  Q1,00 | P->P | BCST LOCAL |
    |  30 |                       PX BLOCK ITERATOR     |                           |   276M|  5547M|   287K  (4)| 00:57:34 |     1 |     8 |  Q1,00 | PCWC |            |
    |  31 |                        TABLE ACCESS FULL    | B                         |   276M|  5547M|   287K  (4)| 00:57:34 |     1 |     8 |  Q1,00 | PCWP |            |
    Predicate Information (identified by operation id):
       9 - access(ROWID="ROWID")
      23 - filter("A"."TR_STATUS"='C' OR "A"."TR_STATUS"='R')
      24 - access("B"."TAX_AUDIT_RECORD_ID"="A"."TAX_AUDIT_RECORD_ID")
      26 - filter("A"."TR_STATUS"='C' OR "A"."TR_STATUS"='R')
         

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

  • [oracle 10.2.0.4] My view is not merged

    Hi,
    I have a view which is not merged by the CBO. I mean the CBO decides to apply the filter predicate after the execution of the view.
    Here is the definition of the view
    CREATE OR REPLACE VIEW VUNSCP AS
    SELECT X.DASFM,X.COINT,X.NUCPT,X.RGCOD,X.RGCID,X.CODEV,X.CTDEV,X.CDVRF,X.TXCHJ,X.MTNLV,X.MTVDP,
           LEAD(X.MTNLV+X.MTVDP,1) OVER (PARTITION BY X.COINT,X.NUCPT,X.CDVRF,X.CTDEV,X.CODEV,X.RGCOD,X.RGCID  ORDER BY X.DASFM DESC),
           SUM(X.MTNLV) OVER (PARTITION BY X.COINT,X.CODEV,X.RGCOD)
    FROM SFMCPT XThe query is:
    explain plan for
    select * from VUNSCP where dasfm='30-apr-10';
    select * from table(dbms_xplan.display);
    Plan hash value: 2545326530
    | Id  | Operation           | Name   | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT    |        |    13M|  1529M|       |   195K  (1)| 00:39:11 |
    |*  1 |  VIEW               | VUNSCP |    13M|  1529M|       |   195K  (1)| 00:39:11 |
    |   2 |   WINDOW SORT       |        |    13M|   646M|  1996M|   195K  (1)| 00:39:11 |
    |   3 |    TABLE ACCESS FULL| SFMCPT |    13M|   646M|       | 27991   (4)| 00:05:36 |
    Predicate Information (identified by operation id):
       1 - filter("DASFM"='30-apr-10')You can see that a FTS is performed on SFMCPT (>1 million of rows) and that the filter predicate is applied only after the view has been instantiated.
    So the index on DASFM can't be used.
    This query is returning about 30 000 rows. We see on the plan that the CBO is mistaken beacause it reckons that there's going to be 13M of rows.
    If I add the filter predicate directly on the view'script I get the correct plan:
    explain plan for
    SELECT X.DASFM,X.COINT,X.NUCPT,X.RGCOD,X.RGCID,X.CODEV,X.CTDEV,X.CDVRF,X.TXCHJ,X.MTNLV,X.MTVDP,
           LEAD(X.MTNLV+X.MTVDP,1) OVER (PARTITION BY X.COINT,X.NUCPT,X.CDVRF,X.CTDEV,X.CODEV,X.RGCOD,X.RGCID ORDER BY X.DASFM DESC),
           SUM(X.MTNLV) OVER (PARTITION BY X.COINT,X.CODEV,X.RGCOD)
    FROM SFMCPT X where dasfm='30-apr-10';
    select * from table(dbms_xplan.display);
    Plan hash value: 1865390099
    | Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT             |         | 14357 |   729K| 13271   (1)| 00:02:40 |
    |   1 |  WINDOW SORT                 |         | 14357 |   729K| 13271   (1)| 00:02:40 |
    |   2 |   TABLE ACCESS BY INDEX ROWID| SFMCPT  | 14357 |   729K| 13269   (1)| 00:02:40 |
    |*  3 |    INDEX RANGE SCAN          | SFMCPT1 | 14357 |       |    67   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       3 - access("DASFM"='30-apr-10')The index is now used and the rows estimated seem closer to the actual rows.
    I tried several things:
    - disabling the "OPTIMZER_COST_BASED_TRANSFORMATION" hidden parameter
    - use the MERGE hint
    - alter session set optimizer_features_enable = '9.2.0.8';
    All these workarounds don't work => I'm still getting the bad execution plan.
    According to Jonathan LEWIS' s book the 9i optimzer always merge views But here even if I set the optimizer_features_enable parameter to 9i the view is not merged.
    It's sure that the issue is due to the analytical functions but why ?
    Can please someone help me to understand what is going on ?
    Edited by: Ahmed AANGOUR on 5 mai 2010 08:41

    here is the 10053 trace file:
    /oracle/app/oracle/admin/UBIXPROD/udump/ubixprod_ora_24971_10053_optimizer_trace.trc
    Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    ORACLE_HOME = /oracle/app/oracle/10.2.0
    System name:    Linux
    Node name:      lin-ubi-test1.ubitrade.com
    Release:        2.6.9-78.0.1.ELsmp
    Version:        #1 SMP Tue Jul 22 18:01:05 EDT 2008
    Machine:        x86_64
    Instance name: UBIXPROD
    Redo thread mounted by this instance: 1
    Oracle process number: 26
    *** 2010-05-04 12:14:51.450
    *** ACTION NAME:() 2010-05-04 12:14:51.450
    *** MODULE NAME:([email protected] (TNS V1-V3)) 2010-05-04 12:14:51.450
    *** SERVICE NAME:(SYS$USERS) 2010-05-04 12:14:51.450
    *** SESSION ID:(135.1512) 2010-05-04 12:14:51.450
    Registered qb: SEL$1 0xa9e139a8 (PARSER)
      signature (): qb_name=SEL$1 nbfros=1 flg=0
        fro(0): flg=5 objn=297481 hint_alias="VUNSCP"@"SEL$1"
    Registered qb: SEL$2 0xa9e0bdd0 (PARSER)
      signature (): qb_name=SEL$2 nbfros=1 flg=0
        fro(0): flg=4 objn=265023 hint_alias="X"@"SEL$2"
    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 3xakq94fcx4td.
    CVM: Considering view merge in query block SEL$1 (#0)
    CVM:   Checking validity of merging SEL$2 (#0)
    CVM: Considering view merge in query block SEL$2 (#0)
    CVM:     CVM bypassed: Window functions in this view
    CBQT: Validity checks failed for 3xakq94fcx4td.
    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).
    Set-Join Conversion (SJC)
    SJC: Considering set-join conversion in SEL$2 (#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:   Passed validity checks.
    FPD: Considering simple filter push in SEL$1 (#0)
    FPD:   Current where clause predicates in SEL$1 (#0) :
             "VUNSCP"."DASFM"='30-apr-10'
    kkogcp: try to generate transitive predicate from check constraints for SEL$1 (#0)
    predicates with check contraints: "VUNSCP"."DASFM"='30-apr-10'
    after transitive predicate generation: "VUNSCP"."DASFM"='30-apr-10'
    finally: "VUNSCP"."DASFM"='30-apr-10'
    JPPD:     JPPD bypassed: View not on right-side of outer join
    FPD: Considering simple filter push in SEL$2 (#0)
    FPD:   Current where clause predicates in SEL$2 (#0) :
             apadrv-start: call(in-use=2936, alloc=16344), compile(in-use=38784, alloc=44568)
    kkoqbc-start
                : call(in-use=2936, alloc=16344), compile(in-use=40472, alloc=44568)
    kkoqbc-subheap (create addr=0x2a9740c1f0)
    Current SQL statement for this session:
    EXPLAIN PLAN FOR select * from VUNSCP where dasfm='30-apr-10'
    Peeked values of the binds in SQL statement
    PARAMETERS USED BY THE OPTIMIZER
      PARAMETERS WITH ALTERED VALUES
      _pga_max_size                       = 262140 KB
      cursor_sharing                      = similar
      _optimizer_cost_based_transformation = off
    Column Usage Monitoring is ON: tracking level = 1
    QUERY BLOCK TEXT
    EXPLAIN PLAN FOR select * from VUNSCP where dasfm='30-apr-10'
    QUERY BLOCK SIGNATURE
    qb name was generated
    signature (optimizer): qb_name=SEL$2 nbfros=1 flg=0
      fro(0): flg=0 objn=265023 hint_alias="X"@"SEL$2"
    SYSTEM STATISTICS INFORMATION
      Using NOWORKLOAD Stats
      CPUSPEED: 2503 millions instruction/sec
      IOTFRSPEED: 4096 bytes per millisecond (default is 4096)
      IOSEEKTIM: 10 milliseconds (default is 10)
    BASE STATISTICAL INFORMATION
    Table Stats::
      Table: SFMCPT  Alias:  X
        #Rows: 13036040  #Blks:  122880  AvgRowLen:  358.00
    Index Stats::
      Index: SFMCPT1  Col#: 2 3 4 8 5 7 118
        LVLS: 2  #LB: 58758  #DK: 13013072  LB/K: 1.00  DB/K: 1.00  CLUF: 11983641.00
      Index: SFMCPT2  Col#: 1
        LVLS: 2  #LB: 30031  #DK: 13483987  LB/K: 1.00  DB/K: 1.00  CLUF: 2410599.00
      Index: SFMCPT3  Col#: 3 4 8 5 7 2 118
        LVLS: 2  #LB: 39065  #DK: 13013072  LB/K: 1.00  DB/K: 1.00  CLUF: 12583891.00
    SINGLE TABLE ACCESS PATH
      BEGIN Single Table Cardinality Estimation
      Table: SFMCPT  Alias: X
        Card: Original: 13036040  Rounded: 13036040  Computed: 13036040.00  Non Adjusted: 13036040.00
      END   Single Table Cardinality Estimation
      Access Path: TableScan
        Cost:  27991.05  Resp: 27991.05  Degree: 0
          Cost_io: 26881.00  Cost_cpu: 33334822147
          Resp_io: 26881.00  Resp_cpu: 33334822147
      Best:: AccessPath: TableScan
             Cost: 27991.05  Degree: 1  Resp: 27991.05  Card: 13036040.00  Bytes: 0
    OPTIMIZER STATISTICS AND COMPUTATIONS
    GENERAL PLANS
    Considering cardinality-based initial join order.
    Permutations for Starting Table :0
    Join order[1]:  SFMCPT[X]#0
    WiF sort
        SORT resource      Sort statistics
          Sort width:         766 Area size:     1048576 Max Area size:   134215680
          Degree:               1
          Blocks to Sort:  108528 Row size:           68 Total Rows:       13036040
          Initial runs:         7 Merge passes:        1 IO Cost / pass:      58786
          Total IO sort cost: 167314      Total CPU sort cost: 16584848017
          Total Temp space used: 2093966000
    Best so far: Table#: 0  cost: 195857.3183  card: 13036040.0000  bytes: 677874080
    (newjo-stop-1) k:0, spcnt:0, perm:1, maxperm:80000
    Number of join permutations tried: 1
        SORT resource      Sort statistics
          Sort width:         766 Area size:     1048576 Max Area size:   134215680
          Degree:               1
          Blocks to Sort:  108528 Row size:           68 Total Rows:       13036040
          Initial runs:         7 Merge passes:        1 IO Cost / pass:      58786
          Total IO sort cost: 167314      Total CPU sort cost: 16584848017
          Total Temp space used: 2093966000
    Final - All Rows Plan:  Best join order: 1
      Cost: 195857.3183  Degree: 1  Card: 13036040.0000  Bytes: 677874080
      Resc: 195857.3183  Resc_io: 194195.0000  Resc_cpu: 49919670164
      Resp: 195857.3183  Resp_io: 194195.0000  Resc_cpu: 49919670164
    kkoipt: Query block SEL$2 (#0)
    ******* UNPARSED QUERY IS *******
    SELECT "X"."DASFM" "DASFM","X"."COINT" "COINT","X"."NUCPT" "NUCPT","X"."RGCOD" "RGCOD","X"."RGCID" "RGCID","X"."CODEV" "CODEV","X"."CTDEV" "CTDEV","X"."CDVRF" "CDVRF","X"."TXCHJ" "TXCHJ","X"."MTNLV" "MTNLV","X"."MTVDP" "MTVDP",DECODE(COUNT(*) OVER ( PARTITION BY "X"."COINT","X"."CODEV","X"."RGCOD","X"."CTDEV","X"."NUCPT","X"."CDVRF","X"."RGCID" ORDER BY "X"."DASFM" DESC  ROWS  BETWEEN 1 FOLLOWING  AND 1 FOLLOWING ),1,FIRST_VALUE("X"."MTNLV"+"X"."MTVDP") OVER ( PARTITION BY "X"."COINT","X"."CODEV","X"."RGCOD","X"."CTDEV","X"."NUCPT","X"."CDVRF","X"."RGCID" ORDER BY "X"."DASFM" DESC  ROWS  BETWEEN 1 FOLLOWING  AND 1 FOLLOWING ),NULL) "MTUNS",SUM("X"."MTNLV") OVER ( PARTITION BY "X"."COINT","X"."CODEV","X"."RGCOD") "MTNLI" FROM "SFMCPT" "X"
    kkoqbc-subheap (delete addr=0x2a9740c1f0, in-use=11856, alloc=12408)
    kkoqbc-end
              : call(in-use=57760, alloc=81816), compile(in-use=41096, alloc=44568)
    kkoqbc-start
                : call(in-use=57760, alloc=81816), compile(in-use=41184, alloc=44568)
    kkoqbc-subheap (create addr=0x2a9746b058)
    QUERY BLOCK TEXT
    select * from VUNSCP where dasfm='30-apr-10'
    QUERY BLOCK SIGNATURE
    qb name was generated
    signature (optimizer): qb_name=SEL$1 nbfros=1 flg=0
      fro(0): flg=1 objn=297481 hint_alias="VUNSCP"@"SEL$1"
    SYSTEM STATISTICS INFORMATION
      Using NOWORKLOAD Stats
      CPUSPEED: 2503 millions instruction/sec
      IOTFRSPEED: 4096 bytes per millisecond (default is 4096)
      IOSEEKTIM: 10 milliseconds (default is 10)
    BASE STATISTICAL INFORMATION
    Table Stats::
      Table: VUNSCP  Alias: VUNSCP  (NOT ANALYZED)
        #Rows: 0  #Blks:  0  AvgRowLen:  0.00
    OPTIMIZER STATISTICS AND COMPUTATIONS
    GENERAL PLANS
    Considering cardinality-based initial join order.
    Permutations for Starting Table :
    Join order[1]:  VUNSCP[VUNSCP]#0
    Best so far: Table#: 0  cost: 195857.3183  card: 13036040.0000  bytes: 1603432920
    (newjo-stop-1) k:0, spcnt:0, perm:1, maxperm:80000
    Number of join permutations tried: 1
    Final - All Rows Plan:  Best join order: 1
      Cost: 195857.3183  Degree: 1  Card: 13036040.0000  Bytes: 1603432920
      Resc: 195857.3183  Resc_io: 194195.0000  Resc_cpu: 49919670164
      Resp: 195857.3183  Resp_io: 194195.0000  Resc_cpu: 49919670164
    kkoipt: Query block SEL$1 (#0)
    ******* UNPARSED QUERY IS *******
    SELECT "VUNSCP"."DASFM" "DASFM","VUNSCP"."COINT" "COINT","VUNSCP"."NUCPT" "NUCPT","VUNSCP"."RGCOD" "RGCOD","VUNSCP"."RGCID" "RGCID","VUNSCP"."CODEV" "CODEV","VUNSCP"."CTDEV" "CTDEV","VUNSCP"."CDVRF" "CDVRF","VUNSCP"."TXCHJ" "TXCHJ","VUNSCP"."MTNLV" "MTNLV","VUNSCP"."MTVDP" "MTVDP","VUNSCP"."MTUNS" "MTUNS","VUNSCP"."MTNLI" "MTNLI" FROM  (SELECT "X"."DASFM" "DASFM","X"."COINT" "COINT","X"."NUCPT" "NUCPT","X"."RGCOD" "RGCOD","X"."RGCID" "RGCID","X"."CODEV" "CODEV","X"."CTDEV" "CTDEV","X"."CDVRF" "CDVRF","X"."TXCHJ" "TXCHJ","X"."MTNLV" "MTNLV","X"."MTVDP" "MTVDP",DECODE(COUNT(*) OVER ( PARTITION BY "X"."COINT","X"."CODEV","X"."RGCOD","X"."CTDEV","X"."NUCPT","X"."CDVRF","X"."RGCID" ORDER BY "X"."DASFM" DESC  ROWS  BETWEEN 1 FOLLOWING  AND 1 FOLLOWING ),1,FIRST_VALUE("X"."MTNLV"+"X"."MTVDP") OVER ( PARTITION BY "X"."COINT","X"."CODEV","X"."RGCOD","X"."CTDEV","X"."NUCPT","X"."CDVRF","X"."RGCID" ORDER BY "X"."DASFM" DESC  ROWS  BETWEEN 1 FOLLOWING  AND 1 FOLLOWING ),NULL) "MTUNS",SUM("X"."MTNLV") OVER ( PARTITION BY "X"."COINT","X"."CODEV","X"."RGCOD") "MTNLI" FROM "SFMCPT" "X") "VUNSCP" WHERE "VUNSCP"."DASFM"='30-apr-10'
    kkoqbc-subheap (delete addr=0x2a9746b058, in-use=11544, alloc=12408)
    kkoqbc-end
              : call(in-use=63208, alloc=81816), compile(in-use=41688, alloc=44568)
    apadrv-end: call(in-use=63208, alloc=81816), compile(in-use=42872, alloc=44568)
    sql_id=3xakq94fcx4td.
    Current SQL statement for this session:
    EXPLAIN PLAN FOR select * from VUNSCP where dasfm='30-apr-10'
    ============
    Plan Table
    ============
    ---------------------------------------+-----------------------------------+
    | Id  | Operation            | Name    | Rows  | Bytes | Cost  | Time      |
    ---------------------------------------+-----------------------------------+
    | 0   | SELECT STATEMENT     |         |       |       |  191K |           |
    | 1   |  VIEW                | VUNSCP  |   12M | 1529M |  191K |  00:39:11 |
    | 2   |   WINDOW SORT        |         |   12M |  646M |  191K |  00:39:11 |
    | 3   |    TABLE ACCESS FULL | SFMCPT  |   12M |  646M |   27K |  00:06:36 |
    ---------------------------------------+-----------------------------------+
    Predicate Information:
    1 - filter("DASFM"='30-apr-10')Edited by: Ahmed AANGOUR on 5 mai 2010 08:43

  • 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

  • Oracle Lite, optimizer?

    Hi all!
    I'm in Oracle lite 10.3...what type of optimizer use Olite?
    I've some mysterious results in a select, only i change the order in the where conditions and the results are distincts...

    Hey Anastasia,
    Do you mean for the client or for MGP? I am assuming you want to unnest the subquery within the COMPOSE phase. Correct?
    Here is the only reference to unnesting on the client in the documentation:
    Example 5
    In this example, the "ordered" hint selects the EMP table as the outermost table in the join ordering. The optimizer still attempts to pick the best possible indexes to use for execution. All other optimizations, such as view replacement and subquery unnesting are still attempted.
    Select //ordered// Eno, Ename, Loc from Emp, Dept
    where Dept.DeptNo = Emp.DeptNo and Emp.Sal > 50000;
    But if this is your MGP that you are inquiring about, just alter the publication select statement with:
    SELECT /*+ UNNEST */ * FROM SOMESCHEMA.SOMETABLE WHERE BLAH, BLAH, BLAH

  • CBO - Wrong Cardinality Estimate

    Hello,
    Version 10.2.0.3
    I am trying to understand the figures in the Explain Plan. I am not able to explain the cardinality of 70 on step 4.
    The query takes very long to execute (about 400 secs). I would expect HASH JOIN SEMI instead of NESTED LOOPS SEMI.
    I have tried to provide as much information as possible. I have just requested the 10053 trace, dont have it now.
    There is a primary key on ORDERS.ORDER_ID (NUMBER) column. However, we are forced to use to_char(order_id) to accomodate for COT_EXTERNAL_ID being VARCHAR2 field.
      1  select cdw.* from cdw_orders cdw where cdw.cot_external_id in
      2  (
      3  select to_char(order_id) from orders o where o.status_id in (12,16,22)
      4* )
    SQL> /
    Execution Plan
    Plan hash value: 733167152
    | Id  | Operation                     | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT              |                      |     2 |   280 |   326   (1)| 00:00:04 |
    |   1 |  NESTED LOOPS SEMI            |                      |     2 |   280 |   326   (1)| 00:00:04 |
    |   2 |   TABLE ACCESS FULL           | CDW_ORDERS           |  3362 |   433K|   293   (1)| 00:00:04 |
    |   3 |   INLIST ITERATOR             |                      |       |       |            |          |
    |*  4 |    TABLE ACCESS BY INDEX ROWID| ORDERS               |    70 |   560 |     1   (0)| 00:00:01 |
    |*  5 |     INDEX RANGE SCAN          | ORDERS_STATUS_ID_IDX |     2 |       |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       4 - filter("CDW"."COT_EXTERNAL_ID"=TO_CHAR("ORDER_ID"))
       5 - access("O"."STATUS_ID"=12 OR "O"."STATUS_ID"=16 OR "O"."STATUS_ID"=22)Here is some of the details on the table columns and data.
    SQL> select column_name,num_distinct,density,num_nulls,num_buckets from all_tab_columns where table_name = 'ORDERS'
      2  and column_name in ('STATUS_ID','ORDER_ID');
    COLUMN_NAME                    NUM_DISTINCT                        DENSITY  NUM_NULLS NUM_BUCKETS
    ORDER_ID                             177951             .00000561952447584          0         254
    STATUS_ID                                23             .00000275335899280          0          23
    SQL> select num_rows from all_tables where table_name = 'ORDERS';
      NUM_ROWS
        177951
    SQL> select index_name,distinct_keys,clustering_factor,num_rows,sample_size from all_indexes where index_name = 'ORDERS_STATUS_ID_IDX'
      2  /
    INDEX_NAME                     DISTINCT_KEYS CLUSTERING_FACTOR   NUM_ROWS SAMPLE_SIZE
    ORDERS_STATUS_ID_IDX                      25             35893     177951      177951Histograms on column STATUS_ID
    SQL> select * from (
      2  select column_name,endpoint_value,endpoint_number- nvl(lag(endpoint_number) over (order by endpoint_value),0) count
      3  from all_tab_histograms where column_name = 'STATUS_ID' and table_name = 'ORDERS'
      4  ) where endpoint_value in (12,16,22);
    COLUMN_NAME                    ENDPOINT_VALUE      COUNT
    STATUS_ID                                  12        494
    STATUS_ID                                  16         24
    STATUS_ID                                  22       3064
    SQL> select max(endpoint_number) from all_tab_histograms where column_name = 'STATUS_ID' and table_name = 'ORDERS' ;
    MAX(ENDPOINT_NUMBER)
                    5641I tried to run the query for individual values instead of inlist to check the numbers.
      1  select cdw.* from cdw_orders cdw where cdw.cot_external_id in
      2  (
      3  select to_char(order_id) from orders o where o.status_id = 12
      4* )
    SQL> /
    Execution Plan
    Plan hash value: 3178043291
    | Id  | Operation                    | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT             |                      |     2 |   280 |    33  (19)| 00:00:01 |
    |   1 |  MERGE JOIN SEMI             |                      |     2 |   280 |    33  (19)| 00:00:01 |
    |   2 |   TABLE ACCESS BY INDEX ROWID| CDW_ORDERS           |  3362 |   433K|    21   (0)| 00:00:01 |
    |   3 |    INDEX FULL SCAN           | CDW_ORD_COT_EXT_ID   |  3362 |       |     2   (0)| 00:00:01 |
    |*  4 |   SORT UNIQUE                |                      | 15584 |   121K|    11  (46)| 00:00:01 |
    |*  5 |    VIEW                      | index$_join$_002     | 15584 |   121K|     9  (34)| 00:00:01 |
    |*  6 |     HASH JOIN                |                      |       |       |            |          |
    |*  7 |      INDEX RANGE SCAN        | ORDERS_STATUS_ID_IDX | 15584 |   121K|     1   (0)| 00:00:01 |
    |   8 |      INDEX FAST FULL SCAN    | PK_ORDERS            | 15584 |   121K|     5   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       4 - access("CDW"."COT_EXTERNAL_ID"=TO_CHAR("ORDER_ID"))
           filter("CDW"."COT_EXTERNAL_ID"=TO_CHAR("ORDER_ID"))
       5 - filter("O"."STATUS_ID"=12)
       6 - access(ROWID=ROWID)
       7 - access("O"."STATUS_ID"=12)For status_id = 12, the cardinality on step 7 for orders_status_id_idx is 15584 which is inline with the expectation ie., (494/5641)*177951 = 15583.7 ~ 15584.
    Now, I continue the same with status_is = 16
      1  select cdw.* from cdw_orders cdw where cdw.cot_external_id in
      2  (
      3  select to_char(order_id) from orders o where o.status_id = 16
      4* )
    SQL> /
    Execution Plan
    Plan hash value: 43581000
    | Id  | Operation                      | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT               |                      |  1363 |   186K|    10  (10)| 00:00:01 |
    |   1 |  TABLE ACCESS BY INDEX ROWID   | CDW_ORDERS           |     2 |   264 |     1   (0)| 00:00:01 |
    |   2 |   NESTED LOOPS                 |                      |  1363 |   186K|    10  (10)| 00:00:01 |
    |   3 |    SORT UNIQUE                 |                      |   757 |  6056 |     2   (0)| 00:00:01 |
    |   4 |     TABLE ACCESS BY INDEX ROWID| ORDERS               |   757 |  6056 |     2   (0)| 00:00:01 |
    |*  5 |      INDEX RANGE SCAN          | ORDERS_STATUS_ID_IDX |   757 |       |     1   (0)| 00:00:01 |
    |*  6 |    INDEX RANGE SCAN            | CDW_ORD_COT_EXT_ID   |     2 |       |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       5 - access("O"."STATUS_ID"=16)
       6 - access("CDW"."COT_EXTERNAL_ID"=TO_CHAR("ORDER_ID"))Here also the cardinality on step 5 for orders_status_id_idx is as expected ie., (24/5641)*177951 = 757.1 ~ 757
    Finally, running the same for status_id = 22 surprises me
      1  select cdw.* from cdw_orders cdw where cdw.cot_external_id in
      2  (
      3  select to_char(order_id) from orders o where o.status_id = 22
      4* )
    SQL> /
    Execution Plan
    Plan hash value: 3496542905
    | Id  | Operation                    | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT             |                      |     2 |   280 |   326   (1)| 00:00:04 |
    |   1 |  NESTED LOOPS SEMI           |                      |     2 |   280 |   326   (1)| 00:00:04 |
    |   2 |   TABLE ACCESS FULL          | CDW_ORDERS           |  3362 |   433K|   293   (1)| 00:00:04 |
    |*  3 |   TABLE ACCESS BY INDEX ROWID| ORDERS               |    60 |   480 |     1   (0)| 00:00:01 |
    |*  4 |    INDEX RANGE SCAN          | ORDERS_STATUS_ID_IDX |     2 |       |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       3 - filter("CDW"."COT_EXTERNAL_ID"=TO_CHAR("ORDER_ID"))
       4 - access("O"."STATUS_ID"=22)Like the ones for 12 and 16, I would have expected the cardinality on step 4 to be (3064/5641)*177951 = 96657, but I see only 2.
    This is where my doubt is. Is this got to do with 22 being a popular value ? Can someone explain this behaviour ?
    As a solution I am thinking of creating an index on to_char(order_id) - function based, hoping that the step 3 CDW.COT_EXTERNAL_ID = TO_CHAR(ORDER_ID) changes
    to access instead of filter. Let me know your thoughts on the index creation as well.
    Thanks,
    Rgds,
    Gokul
    Edited by: Gokul Gopal on 24-May-2012 02:40

    Hello Jonathan,
    Apologies, I was wrong about optimizer_index_cost_adj value to be set to 100. I gather from DBA the value is set to currently set to 1.
    I have pasted the 10053 trace file for value 22. I was not able to figure out the "jsel=min(1, 6.1094e-04)" bit.
    /dborafiles/COTP/bycota2/udump/bycota2_ora_2147_values_22.trc
    Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
    With the Partitioning, Real Application Clusters, OLAP and Data Mining options
    ORACLE_HOME = /dboracle/orabase/product/10.2.0
    System name:     Linux
    Node name:     byl945d002
    Release:     2.6.9-55.ELsmp
    Version:     #1 SMP Fri Apr 20 16:36:54 EDT 2007
    Machine:     x86_64
    Instance name: bycota2
    Redo thread mounted by this instance: 2
    Oracle process number: 37
    Unix process pid: 2147, image: oracle@byl945d002 (TNS V1-V3)
    *** 2012-05-28 14:00:59.737
    *** ACTION NAME:() 2012-05-28 14:00:59.737
    *** MODULE NAME:(SQL*Plus) 2012-05-28 14:00:59.737
    *** SERVICE NAME:(SYS$USERS) 2012-05-28 14:00:59.737
    *** SESSION ID:(713.51629) 2012-05-28 14:00:59.737
    Registered qb: SEL$1 0x973e5458 (PARSER)
      signature (): qb_name=SEL$1 nbfros=1 flg=0
        fro(0): flg=4 objn=51893 hint_alias="CDW"@"SEL$1"
    Registered qb: SEL$2 0x973e6058 (PARSER)
      signature (): qb_name=SEL$2 nbfros=1 flg=0
        fro(0): flg=4 objn=51782 hint_alias="O"@"SEL$2"
    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 passed for 5r4bhr2yrt5gz.
    apadrv-start: call(in-use=704, alloc=16344), compile(in-use=60840, alloc=63984)
    Current SQL statement for this session:
    select cdw.* from cdw_orders cdw where cdw.cot_external_id in (select to_char(o.order_id) from orders o where status_id = 22)
    Legend
    The following abbreviations are used by optimizer trace.
    CBQT - cost-based query transformation
    JPPD - join predicate push-down
    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
    ST - star transformation
    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)
    CPUCSPEED - 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)
      512: 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
      128: use hash partitioning dimension
      256: use range partitioning dimension
      2048: use list partitioning dimension
      1024: run the join in serial
      0: invalid distribution method
    sel - selectivity
    ptn - partition
    Peeked values of the binds in SQL statement
    PARAMETERS USED BY THE OPTIMIZER
      PARAMETERS WITH ALTERED VALUES
      sort_area_retained_size             = 65535
      optimizer_mode                      = first_rows_100
      optimizer_index_cost_adj            = 25
      optimizer_index_caching             = 100
      Bug Fix Control Environment
      fix  4611850 = enabled
      fix  4663804 = enabled
      fix  4663698 = enabled
      fix  4545833 = enabled
      fix  3499674 = disabled
      fix  4584065 = enabled
      fix  4602374 = enabled
      fix  4569940 = enabled
      fix  4631959 = enabled
      fix  4519340 = enabled
      fix  4550003 = enabled
      fix  4488689 = enabled
      fix  3118776 = enabled
      fix  4519016 = enabled
      fix  4487253 = enabled
      fix  4556762 = 15     
      fix  4728348 = enabled
      fix  4723244 = enabled
      fix  4554846 = enabled
      fix  4175830 = enabled
      fix  4722900 = enabled
      fix  5094217 = enabled
      fix  4904890 = enabled
      fix  4483286 = disabled
      fix  4969880 = disabled
      fix  4711525 = enabled
      fix  4717546 = enabled
      fix  4904838 = enabled
      fix  5005866 = enabled
      fix  4600710 = enabled
      fix  5129233 = enabled
      fix  5195882 = enabled
      fix  5084239 = enabled
      fix  4595987 = enabled
      fix  4134994 = enabled
      fix  5104624 = enabled
      fix  4908162 = enabled
      fix  5015557 = enabled
      PARAMETERS WITH DEFAULT VALUES
      optimizer_mode_hinted               = false
      optimizer_features_hinted           = 0.0.0
      parallel_execution_enabled          = true
      parallel_query_forced_dop           = 0
      parallel_dml_forced_dop             = 0
      parallel_ddl_forced_degree          = 0
      parallel_ddl_forced_instances       = 0
      _query_rewrite_fudge                = 90
      optimizer_features_enable           = 10.2.0.3
      _optimizer_search_limit             = 5
      cpu_count                           = 8
      active_instance_count               = 2
      parallel_threads_per_cpu            = 2
      hash_area_size                      = 131072
      bitmap_merge_area_size              = 1048576
      sort_area_size                      = 65536
      _sort_elimination_cost_ratio        = 0
      _optimizer_block_size               = 8192
      _sort_multiblock_read_count         = 2
      _hash_multiblock_io_count           = 0
      _db_file_optimizer_read_count       = 32
      _optimizer_max_permutations         = 2000
      pga_aggregate_target                = 602112 KB
      _pga_max_size                       = 204800 KB
      _query_rewrite_maxdisjunct          = 257
      _smm_auto_min_io_size               = 56 KB
      _smm_auto_max_io_size               = 248 KB
      _smm_min_size                       = 602 KB
      _smm_max_size                       = 102400 KB
      _smm_px_max_size                    = 301056 KB
      _cpu_to_io                          = 0
      _optimizer_undo_cost_change         = 10.2.0.3
      parallel_query_mode                 = enabled
      parallel_dml_mode                   = disabled
      parallel_ddl_mode                   = enabled
      sqlstat_enabled                     = false
      _optimizer_percent_parallel         = 101
      _always_anti_join                   = choose
      _always_semi_join                   = choose
      _optimizer_mode_force               = true
      _partition_view_enabled             = true
      _always_star_transformation         = false
      _query_rewrite_or_error             = false
      _hash_join_enabled                  = true
      cursor_sharing                      = exact
      _b_tree_bitmap_plans                = true
      star_transformation_enabled         = false
      _optimizer_cost_model               = choose
      _new_sort_cost_estimate             = true
      _complex_view_merging               = true
      _unnest_subquery                    = true
      _eliminate_common_subexpr           = true
      _pred_move_around                   = true
      _convert_set_to_join                = false
      _push_join_predicate                = true
      _push_join_union_view               = true
      _fast_full_scan_enabled             = true
      _optim_enhance_nnull_detection      = true
      _parallel_broadcast_enabled         = true
      _px_broadcast_fudge_factor          = 100
      _ordered_nested_loop                = true
      _no_or_expansion                    = false
      _system_index_caching               = 0
      _disable_datalayer_sampling         = false
      query_rewrite_enabled               = true
      query_rewrite_integrity             = enforced
      _query_cost_rewrite                 = true
      _query_rewrite_2                    = true
      _query_rewrite_1                    = true
      _query_rewrite_expression           = true
      _query_rewrite_jgmigrate            = true
      _query_rewrite_fpc                  = true
      _query_rewrite_drj                  = true
      _full_pwise_join_enabled            = true
      _partial_pwise_join_enabled         = true
      _left_nested_loops_random           = true
      _improved_row_length_enabled        = true
      _index_join_enabled                 = true
      _enable_type_dep_selectivity        = true
      _improved_outerjoin_card            = true
      _optimizer_adjust_for_nulls         = true
      _optimizer_degree                   = 0
      _use_column_stats_for_function      = true
      _subquery_pruning_enabled           = true
      _subquery_pruning_mv_enabled        = false
      _or_expand_nvl_predicate            = true
      _like_with_bind_as_equality         = false
      _table_scan_cost_plus_one           = true
      _cost_equality_semi_join            = true
      _default_non_equality_sel_check     = true
      _new_initial_join_orders            = true
      _oneside_colstat_for_equijoins      = true
      _optim_peek_user_binds              = true
      _minimal_stats_aggregation          = true
      _force_temptables_for_gsets         = false
      workarea_size_policy                = auto
      _smm_auto_cost_enabled              = true
      _gs_anti_semi_join_allowed          = true
      _optim_new_default_join_sel         = true
      optimizer_dynamic_sampling          = 2
      _pre_rewrite_push_pred              = true
      _optimizer_new_join_card_computation = true
      _union_rewrite_for_gs               = yes_gset_mvs
      _generalized_pruning_enabled        = true
      _optim_adjust_for_part_skews        = true
      _force_datefold_trunc               = false
      statistics_level                    = typical
      _optimizer_system_stats_usage       = true
      skip_unusable_indexes               = true
      _remove_aggr_subquery               = true
      _optimizer_push_down_distinct       = 0
      _dml_monitoring_enabled             = true
      _optimizer_undo_changes             = false
      _predicate_elimination_enabled      = true
      _nested_loop_fudge                  = 100
      _project_view_columns               = true
      _local_communication_costing_enabled = true
      _local_communication_ratio          = 50
      _query_rewrite_vop_cleanup          = true
      _slave_mapping_enabled              = true
      _optimizer_cost_based_transformation = linear
      _optimizer_mjc_enabled              = true
      _right_outer_hash_enable            = true
      _spr_push_pred_refspr               = true
      _optimizer_cache_stats              = false
      _optimizer_cbqt_factor              = 50
      _optimizer_squ_bottomup             = true
      _fic_area_size                      = 131072
      _optimizer_skip_scan_enabled        = true
      _optimizer_cost_filter_pred         = false
      _optimizer_sortmerge_join_enabled   = true
      _optimizer_join_sel_sanity_check    = true
      _mmv_query_rewrite_enabled          = true
      _bt_mmv_query_rewrite_enabled       = true
      _add_stale_mv_to_dependency_list    = true
      _distinct_view_unnesting            = false
      _optimizer_dim_subq_join_sel        = true
      _optimizer_disable_strans_sanity_checks = 0
      _optimizer_compute_index_stats      = true
      _push_join_union_view2              = true
      _optimizer_ignore_hints             = false
      _optimizer_random_plan              = 0
      _query_rewrite_setopgrw_enable      = true
      _optimizer_correct_sq_selectivity   = true
      _disable_function_based_index       = false
      _optimizer_join_order_control       = 3
      _optimizer_cartesian_enabled        = true
      _optimizer_starplan_enabled         = true
      _extended_pruning_enabled           = true
      _optimizer_push_pred_cost_based     = true
      _sql_model_unfold_forloops          = run_time
      _enable_dml_lock_escalation         = false
      _bloom_filter_enabled               = true
      _update_bji_ipdml_enabled           = 0
      _optimizer_extended_cursor_sharing  = udo
      _dm_max_shared_pool_pct             = 1
      _optimizer_cost_hjsmj_multimatch    = true
      _optimizer_transitivity_retain      = true
      _px_pwg_enabled                     = true
      optimizer_secure_view_merging       = true
      _optimizer_join_elimination_enabled = true
      flashback_table_rpi                 = non_fbt
      _optimizer_cbqt_no_size_restriction = true
      _optimizer_enhanced_filter_push     = true
      _optimizer_filter_pred_pullup       = true
      _rowsrc_trace_level                 = 0
      _simple_view_merging                = true
      _optimizer_rownum_pred_based_fkr    = true
      _optimizer_better_inlist_costing    = all
      _optimizer_self_induced_cache_cost  = false
      _optimizer_min_cache_blocks         = 10
      _optimizer_or_expansion             = depth
      _optimizer_order_by_elimination_enabled = true
      _optimizer_outer_to_anti_enabled    = true
      _selfjoin_mv_duplicates             = true
      _dimension_skip_null                = true
      _force_rewrite_enable               = false
      _optimizer_star_tran_in_with_clause = true
      _optimizer_complex_pred_selectivity = true
      _optimizer_connect_by_cost_based    = true
      _gby_hash_aggregation_enabled       = true
      _globalindex_pnum_filter_enabled    = true
      _fix_control_key                    = 0
      _optimizer_skip_scan_guess          = false
      _enable_row_shipping                = false
      _row_shipping_threshold             = 80
      _row_shipping_explain               = false
      _optimizer_rownum_bind_default      = 10
      _first_k_rows_dynamic_proration     = true
      _optimizer_native_full_outer_join   = off
      Bug Fix Control Environment
      fix  4611850 = enabled
      fix  4663804 = enabled
      fix  4663698 = enabled
      fix  4545833 = enabled
      fix  3499674 = disabled
      fix  4584065 = enabled
      fix  4602374 = enabled
      fix  4569940 = enabled
      fix  4631959 = enabled
      fix  4519340 = enabled
      fix  4550003 = enabled
      fix  4488689 = enabled
      fix  3118776 = enabled
      fix  4519016 = enabled
      fix  4487253 = enabled
      fix  4556762 = 15     
      fix  4728348 = enabled
      fix  4723244 = enabled
      fix  4554846 = enabled
      fix  4175830 = enabled
      fix  4722900 = enabled
      fix  5094217 = enabled
      fix  4904890 = enabled
      fix  4483286 = disabled
      fix  4969880 = disabled
      fix  4711525 = enabled
      fix  4717546 = enabled
      fix  4904838 = enabled
      fix  5005866 = enabled
      fix  4600710 = enabled
      fix  5129233 = enabled
      fix  5195882 = enabled
      fix  5084239 = enabled
      fix  4595987 = enabled
      fix  4134994 = enabled
      fix  5104624 = enabled
      fix  4908162 = enabled
      fix  5015557 = enabled
      PARAMETERS IN OPT_PARAM HINT
    Column Usage Monitoring is ON: tracking level = 1
    COST-BASED QUERY TRANSFORMATIONS
    FPD: Considering simple filter push (pre rewrite) in SEL$1 (#0)
    FPD:   Current where clause predicates in SEL$1 (#0) :
             "CDW"."COT_EXTERNAL_ID"=ANY (SELECT TO_CHAR("O"."ORDER_ID") FROM "ORDERS" "O")
    Registered qb: SEL$1 0x974658b0 (COPY SEL$1)
      signature(): NULL
    Registered qb: SEL$2 0x9745e408 (COPY SEL$2)
      signature(): NULL
    Cost-Based Subquery Unnesting
    SU: No subqueries to consider in query block SEL$2 (#2).
    SU: Considering subquery unnesting in query block SEL$1 (#1)
    SU: Performing unnesting that does not require costing.
    SU: Considering subquery unnest on SEL$1 (#1).
    SU:   Checking validity of unnesting subquery SEL$2 (#2)
    SU:   Passed validity checks.
    SU:   Transforming ANY subquery to a join.
    Registered qb: SEL$5DA710D3 0x974658b0 (SUBQUERY UNNEST SEL$1; SEL$2)
      signature (): qb_name=SEL$5DA710D3 nbfros=2 flg=0
        fro(0): flg=0 objn=51893 hint_alias="CDW"@"SEL$1"
        fro(1): flg=0 objn=51782 hint_alias="O"@"SEL$2"
    Cost-Based Complex View Merging
    CVM: Finding query blocks in SEL$5DA710D3 (#1) that are valid to merge.
    SU:   Transforming ANY subquery to a join.
    Set-Join Conversion (SJC)
    SJC: Considering set-join conversion in SEL$5DA710D3 (#1).
    Query block (0x2a973e5458) before join elimination:
    SQL:******* UNPARSED QUERY IS *******
    SELECT "CDW".* FROM "COT_PLUS"."ORDERS" "O","COT_PLUS"."CDW_ORDERS" "CDW" WHERE "CDW"."COT_EXTERNAL_ID"=TO_CHAR("O"."ORDER_ID") AND "O"."STATUS_ID"=22
    Query block (0x2a973e5458) unchanged
    Predicate Move-Around (PM)
    PM: Considering predicate move-around in SEL$5DA710D3 (#1).
    PM:   Checking validity of predicate move-around in SEL$5DA710D3 (#1).
    PM:     PM bypassed: Outer query contains no views.
    JPPD: Applying transformation directives
    JPPD: Checking validity of push-down in query block SEL$5DA710D3 (#1)
    JPPD:   No view found to push predicate into.
    FPD: Considering simple filter push in SEL$5DA710D3 (#1)
    FPD:   Current where clause predicates in SEL$5DA710D3 (#1) :
             "CDW"."COT_EXTERNAL_ID"=TO_CHAR("O"."ORDER_ID") AND "O"."STATUS_ID"=22
    kkogcp: try to generate transitive predicate from check constraints for SEL$5DA710D3 (#1)
    predicates with check contraints: "CDW"."COT_EXTERNAL_ID"=TO_CHAR("O"."ORDER_ID") AND "O"."STATUS_ID"=22
    after transitive predicate generation: "CDW"."COT_EXTERNAL_ID"=TO_CHAR("O"."ORDER_ID") AND "O"."STATUS_ID"=22
    finally: "CDW"."COT_EXTERNAL_ID"=TO_CHAR("O"."ORDER_ID") AND "O"."STATUS_ID"=22
    First K Rows: Setup begin
    kkoqbc-start
                : call(in-use=1592, alloc=16344), compile(in-use=101000, alloc=134224)
    QUERY BLOCK TEXT
    select cdw.* from cdw_orders cdw where cdw.cot_external_id in (select to_char(o.order_id) from orders o where status_id = 22)
    QUERY BLOCK SIGNATURE
    qb name was generated
    signature (optimizer): qb_name=SEL$5DA710D3 nbfros=2 flg=0
      fro(0): flg=0 objn=51893 hint_alias="CDW"@"SEL$1"
      fro(1): flg=0 objn=51782 hint_alias="O"@"SEL$2"
    SYSTEM STATISTICS INFORMATION
      Using NOWORKLOAD Stats
      CPUSPEED: 714 millions instruction/sec
      IOTFRSPEED: 4096 bytes per millisecond (default is 4096)
      IOSEEKTIM: 10 milliseconds (default is 10)
    BASE STATISTICAL INFORMATION
    Table Stats::
      Table: CDW_ORDERS  Alias: CDW
        #Rows: 3375  #Blks:  1504  AvgRowLen:  132.00
    Index Stats::
      Index: CDW_ORD_COT_EXT_ID  Col#: 10
        LVLS: 1  #LB: 232  #DK: 1878  LB/K: 1.00  DB/K: 1.00  CLUF: 1899.00
      Index: CDW_ORD_REFERENCE_IDX  Col#: 13
        LVLS: 0  #LB: 0  #DK: 0  LB/K: 0.00  DB/K: 0.00  CLUF: 0.00
      Index: COMMITTED_IDX  Col#: 12
        LVLS: 1  #LB: 171  #DK: 1673  LB/K: 1.00  DB/K: 1.00  CLUF: 1657.00
      Index: OBJID_IDX  Col#: 16 17
        LVLS: 2  #LB: 318  #DK: 3372  LB/K: 1.00  DB/K: 1.00  CLUF: 1901.00
      Index: ORDID_IDX  Col#: 14
        LVLS: 0  #LB: 0  #DK: 0  LB/K: 0.00  DB/K: 0.00  CLUF: 0.00
    Table Stats::
      Table: ORDERS  Alias:  O
        #Rows: 178253  #Blks:  7300  AvgRowLen:  282.00
    Index Stats::
      Index: IDX_ORDERS_CONFIG  Col#: 80
        LVLS: 1  #LB: 215  #DK: 452  LB/K: 1.00  DB/K: 130.00  CLUF: 59161.00
      Index: IDX_ORDERS_REFRENCE_NUMBER  Col#: 6
        LVLS: 1  #LB: 428  #DK: 68698  LB/K: 1.00  DB/K: 1.00  CLUF: 115830.00
      Index: ORDERS_BILLING_SI_IDX  Col#: 13
        LVLS: 1  #LB: 84  #DK: 3049  LB/K: 1.00  DB/K: 8.00  CLUF: 27006.00
      Index: ORDERS_LATEST_ORD_IDX  Col#: 3
        LVLS: 0  #LB: 0  #DK: 0  LB/K: 0.00  DB/K: 0.00  CLUF: 0.00
      Index: ORDERS_ORDER_TYPE_IDX  Col#: 4
        LVLS: 2  #LB: 984  #DK: 64  LB/K: 15.00  DB/K: 932.00  CLUF: 59702.00
      Index: ORDERS_ORD_MINOR__IDX  Col#: 43 5
        LVLS: 2  #LB: 784  #DK: 112  LB/K: 7.00  DB/K: 375.00  CLUF: 42012.00
      Index: ORDERS_OWNING_ORG_IDX  Col#: 37
        LVLS: 0  #LB: 0  #DK: 0  LB/K: 0.00  DB/K: 0.00  CLUF: 0.00
      Index: ORDERS_PARENT_ORD_IDX  Col#: 2
        LVLS: 1  #LB: 206  #DK: 37492  LB/K: 1.00  DB/K: 1.00  CLUF: 58051.00
      Index: ORDERS_SD_CONFIG__IDX  Col#: 42
        LVLS: 2  #LB: 604  #DK: 10  LB/K: 60.00  DB/K: 3638.00  CLUF: 36389.00
      Index: ORDERS_SPECIAL_OR_IDX  Col#: 36
        LVLS: 1  #LB: 63  #DK: 2  LB/K: 31.00  DB/K: 556.00  CLUF: 1113.00
      Index: ORDERS_STATUS_ID_IDX  Col#: 5
        LVLS: 2  #LB: 635  #DK: 25  LB/K: 25.00  DB/K: 1440.00  CLUF: 36015.00
      Index: PK_ORDERS  Col#: 1
        LVLS: 1  #LB: 408  #DK: 178253  LB/K: 1.00  DB/K: 1.00  CLUF: 131025.00
    SINGLE TABLE ACCESS PATH
      Column (#5): STATUS_ID(NUMBER)
        AvgLen: 3.00 NDV: 20 Nulls: 0 Density: 2.7653e-06 Min: 2 Max: 33
        Histogram: Freq  #Bkts: 20  UncompBkts: 5567  EndPtVals: 20
      Table: ORDERS  Alias: O    
        Card: Original: 178253  Rounded: 95450  Computed: 95450.37  Non Adjusted: 95450.37
      Access Path: TableScan
        Cost:  1419.89  Resp: 1419.89  Degree: 0
          Cost_io: 1408.00  Cost_cpu: 101897352
          Resp_io: 1408.00  Resp_cpu: 101897352
    kkofmx: index filter:"O"."STATUS_ID"=22
      Access Path: index (skip-scan)
        SS sel: 0.53548  ANDV (#skips): 60
        SS io: 419.81 vs. table scan io: 1408.00
        Skip Scan chosen
      Access Path: index (SkipScan)
        Index: ORDERS_ORD_MINOR__IDX
        resc_io: 22918.81  resc_cpu: 204258888
        ix_sel: 0.53548  ix_sel_with_filters: 0.53548
        Cost: 5735.66  Resp: 5735.66  Degree: 1
      Access Path: index (AllEqRange)
        Index: ORDERS_STATUS_ID_IDX
        resc_io: 19629.00  resc_cpu: 180830676
        ix_sel: 0.53548  ix_sel_with_filters: 0.53548
        Cost: 4912.53  Resp: 4912.53  Degree: 1
      ****** trying bitmap/domain indexes ******
      Best:: AccessPath: TableScan
             Cost: 1419.89  Degree: 1  Resp: 1419.89  Card: 95450.37  Bytes: 0
    SINGLE TABLE ACCESS PATH
      Table: CDW_ORDERS  Alias: CDW    
        Card: Original: 3375  Rounded: 3375  Computed: 3375.00  Non Adjusted: 3375.00
      Access Path: TableScan
        Cost:  292.51  Resp: 292.51  Degree: 0
          Cost_io: 291.00  Cost_cpu: 12971896
          Resp_io: 291.00  Resp_cpu: 12971896
      Best:: AccessPath: TableScan
             Cost: 292.51  Degree: 1  Resp: 292.51  Card: 3375.00  Bytes: 0
    OPTIMIZER STATISTICS AND COMPUTATIONS
    GENERAL PLANS
    Considering cardinality-based initial join order.
    Permutations for Starting Table :0
    Join order[1]:  CDW_ORDERS[CDW]#0  ORDERS[O]#1
    Now joining: ORDERS[O]#1
    NL Join
      Outer table: Card: 3375.00  Cost: 292.51  Resp: 292.51  Degree: 1  Bytes: 132
      Inner table: ORDERS  Alias: O
      Access Path: TableScan
        NL Join:  Cost: 4788284.86  Resp: 4788284.86  Degree: 0
          Cost_io: 4748144.00  Cost_cpu: 343916534896
          Resp_io: 4748144.00  Resp_cpu: 343916534896
    kkofmx: index filter:"O"."STATUS_ID"=22
    OPTIMIZER PERCENT INDEX CACHING = 100
      Access Path: index (FullScan)
        Index: ORDERS_ORD_MINOR__IDX
        resc_io: 22497.00  resc_cpu: 217815366
        ix_sel: 1  ix_sel_with_filters: 0.53548
        NL Join: Cost: 19004464.41  Resp: 19004464.41  Degree: 1
          Cost_io: 18982134.75  Cost_cpu: 191314735126
          Resp_io: 18982134.75  Resp_cpu: 191314735126
    OPTIMIZER PERCENT INDEX CACHING = 100
      Access Path: index (AllEqJoin)
        Index: ORDERS_STATUS_ID_IDX
        resc_io: 1.00  resc_cpu: 7981
        ix_sel: 1.0477e-05  ix_sel_with_filters: 1.0477e-05
        NL Join: Cost: 1137.05  Resp: 1137.05  Degree: 1
          Cost_io: 1134.75  Cost_cpu: 19706236
          Resp_io: 1134.75  Resp_cpu: 19706236
      ****** trying bitmap/domain indexes ******
      Best NL cost: 1137.05
              resc: 1137.05 resc_io: 1134.75 resc_cpu: 19706236
              resp: 1137.05 resp_io: 1134.75 resp_cpu: 19706236
    adjusting AJ/SJ sel based on min/max ranges: jsel=min(1, 6.1094e-04)Semi Join Card:  2.06 = outer (3375.00) * sel (6.1094e-04)
    Join Card - Rounded: 2 Computed: 2.06
    SM Join
      Outer table:
        resc: 292.51  card 3375.00  bytes: 132  deg: 1  resp: 292.51
      Inner table: ORDERS  Alias: O
        resc: 1419.89  card: 95450.37  bytes: 8  deg: 1  resp: 1419.89
        using dmeth: 2  #groups: 1
        SORT resource      Sort statistics
          Sort width:         598 Area size:      616448 Max Area size:   104857600
          Degree:               1
          Blocks to Sort:      65 Row size:          156 Total Rows:           3375
          Initial runs:         1 Merge passes:        0 IO Cost / pass:          0
          Total IO sort cost: 0      Total CPU sort cost: 10349977
          Total Temp space used: 0
        SORT resource      Sort statistics
          Sort width:         598 Area size:      616448 Max Area size:   104857600
          Degree:               1
          Blocks to Sort:     223 Row size:           19 Total Rows:          95450
          Initial runs:         2 Merge passes:        1 IO Cost / pass:        122
          Total IO sort cost: 345      Total CPU sort cost: 85199490
          Total Temp space used: 3089000
      SM join: Resc: 2068.56  Resp: 2068.56  [multiMatchCost=0.00]
      SM cost: 2068.56
         resc: 2068.56 resc_io: 2044.00 resc_cpu: 210418716
         resp: 2068.56 resp_io: 2044.00 resp_cpu: 210418716
    SM Join (with index on outer)
      Access Path: index (FullScan)
        Index: CDW_ORD_COT_EXT_ID
        resc_io: 2132.00  resc_cpu: 18119160
        ix_sel: 1  ix_sel_with_filters: 1
        Cost: 533.53  Resp: 533.53  Degree: 1
      Outer table:
        resc: 533.53  card 3375.00  bytes: 132  deg: 1  resp: 533.53
      Inner table: ORDERS  Alias: O
        resc: 1419.89  card: 95450.37  bytes: 8  deg: 1  resp: 1419.89
        using dmeth: 2  #groups: 1
        SORT resource      Sort statistics
          Sort width:         598 Area size:      616448 Max Area size:   104857600
          Degree:               1
          Blocks to Sort:     223 Row size:           19 Total Rows:          95450
          Initial runs:         2 Merge passes:        1 IO Cost / pass:        122
          Total IO sort cost: 345      Total CPU sort cost: 85199490
          Total Temp space used: 3089000
      SM join: Resc: 2308.37  Resp: 2308.37  [multiMatchCost=0.00]
    HA Join
      Outer table:
        resc: 292.51  card 3375.00  bytes: 132  deg: 1  resp: 292.51
      Inner table: ORDERS  Alias: O
        resc: 1419.89  card: 95450.37  bytes: 8  deg: 1  resp: 1419.89
        using dmeth: 2  #groups: 1
        Cost per ptn: 1.67  #ptns: 1
        hash_area: 151 (max=25600)   Hash join: Resc: 1714.08  Resp: 1714.08  [multiMatchCost=0.00]
      HA cost: 1714.08
         resc: 1714.08 resc_io: 1699.00 resc_cpu: 129204369
         resp: 1714.08 resp_io: 1699.00 resp_cpu: 129204369
    Best:: JoinMethod: NestedLoopSemi
           Cost: 1137.05  Degree: 1  Resp: 1137.05  Card: 2.06  Bytes: 140
    Best so far: Table#: 0  cost: 292.5140  card: 3375.0000  bytes: 445500
                 Table#: 1  cost: 1137.0501  card: 2.0619  bytes: 280
    Number of join permutations tried: 1
    (newjo-save)    [0 1 ]
    Final - All Rows Plan:  Best join order: 1
      Cost: 1137.0501  Degree: 1  Card: 2.0000  Bytes: 280
      Resc: 1137.0501  Resc_io: 1134.7500  Resc_cpu: 19706236
      Resp: 1137.0501  Resp_io: 1134.7500  Resc_cpu: 19706236
    kkoipt: Query block SEL$5DA710D3 (#1)
    kkoqbc-end
              : call(in-use=156048, alloc=164408), compile(in-use=103696, alloc=134224)
    First K Rows: Setup end
    ***********************

  • DB upgrade fom 9i to 10gR2

    Do we need to know if failover and loadbalancing is implemented to plan for DB upgrade from 9i to 10gR2? If so why?

    Hi,
    Issues when upgrading from Oracle 9i :
    1. Hash Group by aggregation which allows a hash algorithm to process group by statements. You have to use for sorts ORDER BY.
    2. 10g CBO has been added costed subquery unnesting and view merging functionality.
    a. Symptoms might range from high parse times to wrong results
    3.The CONNECT Role has been changed since 10g R2
    4. Parse times may increase after upgrade/migration
    Hope it helps....
    Thanks
    LaserSoft

  • Subquery in IF statement in trigger, without using foreign keys

    Hello,
    I'm investigating ways of writing a subquery in an IF statement, which is placed inside a trigger.
    I wanna write smth like IF (:new.jazz not in (select goldies from T where ... )) etc. I don't know whether the fact that the IF is in a trigger adds some additional restrictions. (Does it?)
    So far I found the solution described here: SubQuery Comparison in If Statement which I find a bit tacky, I could have the 'cooleststarinthegalaxy' instead of 1 and seems you need to do extra light, but still extra lifting.
    I also read about the possibility of using MERGE, which I'm currently researching.
    Is there any other way?
    Thanks
    Edited by: BluShadow on 14-Nov-2012 13:37
    fixed link
    Edite by me: the question is how (if possible) to do this without a foreign key.
    Edited by: questioningq12 on Nov 14, 2012 6:11 AM
    Edited by: questioningq12 on Nov 14, 2012 6:13 AM

    Hi,
    questioningq12 wrote:
    Say I have tables A(namea varchar(10)), B(nameb varchar(10)), and B contains tuples ('1stname','2ndname').
    I wrote a trigger before insertion, for each row, on table A. For a tuple t to be inserted, it should check whether t.namea is in the set of values nameb from B.
    E.g., INSERT INTO A VALUES('1stname') should work. But INSERT INTO A VALUES ('3rdname') should fail. You can use a foreign key constraint for that.
    If the tables already exist, and b.nameb is declared as UNIQUE (or PRIMARY KEY), then you can say:
    ALTER TABLE  a
        ADD CONSTRAINT     a_namea_fk
        FOREIGN KEY  (namea)
        REFERENCES b (nameb)
    ;If you had a situation where you really needed to query a table in PL/SQL, and you weren't sure if the query would find anything, you could put the query in its own BEGIN ... EXCEPTION block, and test for NO_DATA_FOUND.
    If you're just checking to see if a row exists or not, you can always write a query that is guaranteed to return exactly 1 row, like this:
    BEGIN
        SELECT  COUNT (*)
        INTO    x
        FROM    b
        WHERE   nameb = :NEW.namea
        AND         ROWNUM  = 1;
        IF x = 0
        THEN  
            ...        -- print msgs, raise exceptions etc
        END IF;
    END;Edited by: Frank Kulash on Nov 14, 2012 9:22 AM
    Added example

  • 11g-[nQSError: 42029] Subquery contains too many values for the IN predicat

    Hi,
    I am having 2 reports one is for subquery which returns inputs to Main report. Actually the report was working fine in 10g. But in 11g we are gettting following error:
    View Display Error
    Odbc driver returned an error (SQLExecDirectW).
    Error Details
    Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
    State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 43113] Message returned from OBIS. [nQSError: 43119] Query Failed: [nQSError: 42029] Subquery contains too many values for the IN predicate.Please have your System Administrator look at the log for more details on this error. (HY000)
    Please have your System Administrator look at the log for more details on this error.
    Getting same error after modofying the parameter value MAX_EXPANDED_SUBQUERY_PREDICATES to 12000
    Please suggest what could be the other reason it may fail or any other settings we need to check.
    Regards,
    ckeng

    ckeng,
    Normally the IN clause has restriction of 10000 values in general sql/plsql we will go with inline queries i think model your rpd to generate inner queries
    select * from emp where dept_id in (Select distinct dept_id from dept);
    or have a condition/filter on sub report and make one more inner report with sub-filter but definitely it will cause performance issues.
    thanks,
    Saichand.v

  • Subquery is not supported on fast refresh ?

    Hi ,
    There is a long and complex sql statement in our production environment and the following subquery in it is called more 5 times in different clause.
    I created materialized view to simplize it and decrease i/o, but fast refresh at commit time of the transaction was not support.
    select report_dp as rpt_dp
    from sys_currency_tbl where curr_cd = (select para_value from sys_system_param_tbl where para = 'base_currency')
    SQL> select * from v$version;
    BANNER
    Oracle Database 10g Release 10.2.0.3.0 - 64bit Production
    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
    SQL> create materialized view log on sys_system_param_tbl tablespace tbs_tmp with rowid,sequence (para,para_value) including new values;
    Materialized view log created.
    SQL> create materialized view log on sys_currency_tbl tablespace tbs_tmp with rowid,sequence (report_dp,curr_cd) including new values;
    Materialized view log created.
    SQL> create materialized view sys_currency_tbl_mv
    2 refresh fast
    3 on commit
    4 as
    5 select report_dp as rpt_dp
    6 from sys_currency_tbl where curr_cd = (select para_value from sys_system_param_tbl where para = 'base_currency');
    FROM sys_currency_tbl WHERE curr_cd = (SELECT para_value FROM sys_system_param_tbl WHERE para = 'BASE_CURRENCY')
    ERROR at line 6:
    ORA-12054: cannot set the ON COMMIT refresh attribute for the materialized view
    SQL> delete from mv_capabilities_table;
    0 rows deleted.
    SQL> exec dbms_mview.explain_mview('select report_dp as rpt_dp from sys_currency_tbl where curr_cd =
    (select para_value from sys_system_param_tbl where para = ''base_currency'')','test');
    PL/SQL procedure successfully completed.
    SQL> set linesize 160
    SQL> col msgtxt format a60
    SQL> SELECT capability_name, possible,msgno,SUBSTR(msgtxt,1,60) AS msgtxt
    2 FROM mv_capabilities_table
    WHERE statement_id='test' and capability_name like '%FAST%';
    3
    CAPABILITY_NAME P MSGNO MSGTXT
    REFRESH_FAST N
    REFRESH_FAST_AFTER_INSERT N *2129 join or filter condition(s) are complex*
    REFRESH_FAST_AFTER_ONETAB_DML N 2146 see the reason why REFRESH_FAST_AFTER_INSERT is disabled
    REFRESH_FAST_AFTER_ANY_DML N 2161 see the reason why REFRESH_FAST_AFTER_ONETAB_DML is disabled
    REFRESH_FAST_PCT N 2157 PCT is not possible on any of the detail tables in the mater
    General Restrictions on Fast Refresh
    The defining query of the materialized view is restricted as follows:
         The materialized view must not contain references to non-repeating expressions like SYSDATE and ROWNUM.
         The materialized view must not contain references to RAW or LONG RAW data types.
         It cannot contain a SELECT list subquery.
         It cannot contain analytical functions (for example, RANK) in the SELECT clause.
         It cannot contain a MODEL clause.
         It cannot contain a HAVING clause with a subquery.
         It cannot contain nested queries that have ANY, ALL, or NOT EXISTS.
         It cannot contain a [START WITH …] CONNECT BY clause.
         It cannot contain multiple detail tables at different sites.
         On-commit materialized view cannot have remote detail tables.
         Nested materialized views must have a join or aggregate.
    Above general restriction tell us subquery is not support on fast refresh, is right ?
    If so could someone tell me how to simple the sql statement to avoid a lot of parse and I/O cost?

    One way to simplify the statement and be able to use fast refreshed materialized views is getting rid of the sub-query
    select a.reort_dp as rpt_dp
    from sys_currency_tbl a ,  sys_system_param_tbl b
    where a.curr_cd =b.para_value
    and  b.para = 'base_currency'To get a faster execution, you need to do a comprehensive review of the statement, starting with explain plan, index availability and table/index statistics.
    Iordan Iotzov
    http://iiotzov.wordpress.com/

  • Subquery referencing parent query table????

    Well my problem ( which I hope has a solution :) ) is the following:
    I work on a little OS Advertising project.
    When an advertiser wants to start a campaign, he must see the list of the publisher websites where he can advertise.
    ::::SELECT [...] FROM website wsite[...]
    With their places count
    ::::[...]COUNT(place.id) AS placeCnt[...]INNER JOIN place ON place.website_id = wsite.id[...]
    -Yes but the websites that have at least 1 place
    ::::[...]GROUP BY wsite.id HAVING COUNT(place.id)>0[...]
    -And here comes my big dead end problem:
    I would like to remove the websites where the advertiser can't advertiser.
    I mean by there > if every ads of the advertiser are blacklisted for the site "google.com", he can't see "google.com" in the list because he won't be able to advertiser on in anyway.
    however, if the advertiser has 4 ads, and all of it are blacklisted excepted the 4th, he must see "google.com" because he can advertise with the ad #4.
    There is 2 types of blacklisting :
    targetted ( by defining a website id on the blacklist line )
    global ( by setting the website id = null , so for example if ad#1 is globally blacklisted by user #1, ad#1 couldn't be able to advertise on every websites of user#1 )
    I thought I found a solutoin put it doesn't seem to work:
    ::::WHERE 0< (
    SELECT COUNT(DISTINCT ad.id)
    FROM ad
    LEFT OUTER JOIN blacklist bl ON bl.ad_id =ad.id AND (bl.website_id=wsite.id OR bl.site_id IS NULL)
    WHERE ad.user_id= $userid
    AND bl.id IS NULL
    A concrete scenario example: ( SQL included at the end of the post )
    the user [email protected] ( userid = 2 ) has 3 ads.
    -"my forbidden ad" ( id = 1)
    -"my ad" ( id = 2 )
    -"my unappreciated ad" ( id = 3 )
    the user [email protected] ( userid = 1 ) has 3 websites
    -google.com ( id = 1 )
    -yahoo.com ( id = 2 )
    [email protected] has blacklisted the following ads:
    -"my unappreciated ad" ON yahoo.com, type targetted, ( website_id = 2, ad_id = 3 , publisher_id = 1)
    -"my forbidden ad" type global, ( website_id = null , ad_id = 1 publisher_id = 1)
    so the publisher websites we'll see with the resulting query should be ( as the the advertiser, user 2 ) :
    google.com
    yahoo.com
    lol.com
    WHY?
    -Because the advertiser can advertise thanks to ad 2 ( ad2 is allowed to be advertised on each website )
    -Even if "forbidden ad" is blacklisted globally, unapprediated ad remains for google.com
    NOW, if the publisher adds another blacklist restriction
    -"my ad" , type global ( website_id = null, ad_id = 2 , publisher_id = 1)
    the result would be ( as the the advertiser, user 2 )
    google.com
    WHY?
    -Because the advertiser do not have any ad to put on yahoo.com. Ad 1 and Ad 2 are blacklisted globally, ad 3 is blacklisted for yahoo.com
    WELL, I thought I found the solution by this query but mysql returns an error > unknown colum on the subquery
    THe only thing I want to is to LINK the parent query WITH the subquery ON bl.site_id=psite.id
    Enfin bon, tout ça pour un truc qui semblait être possible avec cette requête mais qui renvoie donc une erreur de unknown column:
    SELECT wsite.*,COUNT(place.id) AS placeCnt
    FROM website wsite
    INNER JOIN place ON place.website_id = wsite.id
    WHERE 0< (
    SELECT COUNT(DISTINCT ad.id)
    FROM ad
    LEFT OUTER JOIN blacklist bl ON bl.ad_id =ad.id AND (*bl.website_id=wsite.id* OR bl.website_id IS NULL)
    WHERE ad.advertiser_id= 2
    AND bl.id IS NULL
    GROUP BY wsite.id
    HAVING COUNT(place.id)>0
    WELL THANKS A LOT to have read this post, AND THANK YOU EVEN MORE IF SOMEONE FIND A TRICK!
    PS :
    ( the only solution I can see for the moment is a loop like )
    foreach($publisher_sites as $s){
    if(advertiserCanAdvertiser($s['id'])) $sites[]=$s
    but the performances are really bad
    I think the following would help :)
    MySQL Data Transfer
    Source Host: localhost
    Source Database: orads
    Target Host: localhost
    Target Database: orads
    Date: 10/20/2009 1:02:03 PM
    SET FOREIGN_KEY_CHECKS=0;
    -- Table structure for ad
    DROP TABLE IF EXISTS `ad`;
    CREATE TABLE `ad` (
    `id` int(11) NOT NULL auto_increment,
    `title` varchar(32) NOT NULL,
    `url` varchar(50) NOT NULL,
    `advertiser_id` int(11) NOT NULL,
    PRIMARY KEY (`id`)
    ) ENGINE=MyISAM AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;
    -- Table structure for blacklist
    DROP TABLE IF EXISTS `blacklist`;
    CREATE TABLE `blacklist` (
    `id` int(11) NOT NULL auto_increment,
    `ad_id` int(11) NOT NULL,
    `website_id` int(11) default NULL,
    `publisher_id` int(11) NOT NULL,
    PRIMARY KEY (`id`)
    ) ENGINE=MyISAM AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;
    -- Table structure for place
    DROP TABLE IF EXISTS `place`;
    CREATE TABLE `place` (
    `id` int(11) NOT NULL auto_increment,
    `name` varchar(32) NOT NULL,
    `website_id` int(11) NOT NULL,
    PRIMARY KEY (`id`)
    ) ENGINE=MyISAM AUTO_INCREMENT=5 DEFAULT CHARSET=utf8;
    -- Table structure for user
    DROP TABLE IF EXISTS `user`;
    CREATE TABLE `user` (
    `id` int(11) NOT NULL auto_increment,
    `email` varchar(64) NOT NULL,
    `password` varchar(16) NOT NULL,
    PRIMARY KEY (`id`)
    ) ENGINE=MyISAM AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;
    -- Table structure for website
    DROP TABLE IF EXISTS `website`;
    CREATE TABLE `website` (
    `id` int(11) NOT NULL auto_increment,
    `title` varchar(32) NOT NULL,
    `url` varchar(32) NOT NULL,
    `publisher_id` int(11) NOT NULL,
    PRIMARY KEY (`id`)
    ) ENGINE=MyISAM AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;
    -- Records
    INSERT INTO `ad` VALUES ('1', 'my forbidden ad 1', 'http://www.no.com', '2');
    INSERT INTO `ad` VALUES ('2', 'my ad 2', 'http://www.lol.com', '2');
    INSERT INTO `ad` VALUES ('3', 'my unappreciated ad 3', 'http://www.abc.com', '2');
    INSERT INTO `blacklist` VALUES ('1', '1', null, '1');
    INSERT INTO `blacklist` VALUES ('2', '3', '2', '1');
    INSERT INTO `place` VALUES ('1', 'banner1', '1');
    INSERT INTO `place` VALUES ('2', 'yahoo banner', '2');
    INSERT INTO `user` VALUES ('1', '[email protected]', 'publisher');
    INSERT INTO `user` VALUES ('2', '[email protected]', 'advertiser');
    INSERT INTO `website` VALUES ('1', 'google', 'http://www.google.com', '1');
    INSERT INTO `website` VALUES ('2', 'yahoo', 'http://www.yahoo.com', '1');
    Edited by: user12086067 on Oct 20, 2009 4:51 AM

    Hi,
    Welcome to the forum!
    Interesting problem!
    Here's one way to do that in Oracle:
    SELECT DISTINCT     w.*
    FROM     website     w
    JOIN     place     p  ON     p.website_id     = w.id
    JOIN     ad     a  ON     w.publisher_id     NOT IN (
                                    SELECT     b.publisher_id
                                    FROM     blacklist     b
                                    WHERE     b.ad_id     = a.id
                                    AND     COALESCE ( b.website_id
                                                    , w.id
                                             ) = w.id
    WHERE     a.advertiser_id     = 2     -- parameter
    ;Thanks for posting the CREATE TABLE and INSERT statements. Since this is an Oracle forum, you should post statementts that will work in Oracle.
    I don't know anything about MySQL, so I don't know if you'll need to change query above or not.
    This doesn't quite produce the output you requested, since lol.com isn't in the website table. Do you need to get lol.com from the user table somehow?

  • Subquery not working in 11g

    Hi all,
    We have an 11.1.0.7 instance on SLES10. And when we run following sql, it crashes.
    select decode(sum(pos),0,'H',decode(sum(hareket),0,'P','T')) from
    (select count(1) pos,0 hareket from cost.pos_hareket p where
    p.onay_eh='E' and p.is_merkez_kod='70' and
    p.tarih>='28.04.2011'
    union
    select 0,count(1) from otel.hareket h where h.tarih>='28.04.2011' and
    h.is_merkezi_kod='70' and h.belge_no not in (select
    p.belge_no from cost.pos_hareket p where p.onay_eh='E' and
    p.is_merkez_kod='70' and p.tarih>='28.04.2011' union select
    o.belge_no from otel.onburo_manuel_extra o where
    o.is_merkez_kod='70'));
    But when we run following sql, it is ok.
    select decode(sum(pos),0,'H',decode(sum(hareket),0,'P','T')) from
    (select count(1) pos,0 hareket from cost.pos_hareket p where
    p.onay_eh='E' and p.is_merkez_kod='70' and
    p.tarih>='28.04.2011'
    union
    select 0,count(1) from otel.hareket h where h.tarih>='28.04.2011' and
    h.is_merkezi_kod='70' and (h.belge_no not in (select
    p.belge_no from cost.pos_hareket p where p.onay_eh='E' and
    p.is_merkez_kod='70' and p.tarih>='28.04.2011') or h.belge_no not in (select
    o.belge_no from otel.onburo_manuel_extra o where
    o.is_merkez_kod='70')));

    ilke_altinpulluk wrote:
    the query hold up very very long time.In that case the obvious thing to do would (normally) be to run the faster query.
    In your case I am not keen on suggesting this as the two queries don't appear to be logically equivalent.
    They are hard to read in the form you've posted but one appears to be:
    select ....
    where something not in (
        select ...
        union
        select ...
    )While the second is:
    select ....
    where something not in (
        select ...
    or something not in (
        select ...
    )If my interpretation is correct, then that OR should be an AND for the queries to be logically the same.
    In the absence of any further information, I think it's likely that the first query is able to unnest the subquery, while the second query has to operate the two subqueries as filter subqueries - and the nature of your data, indexing, etc. makes one plan much more efficient than the other.
    You could try an /*+ no_unnest */ hint in the subquery of the first query to see what impact that might have.
    Regards
    Jonathan Lewis

  • In operator and subquery

    I have created a sql query for oracle rdbms. I am passing a particular id in the subquery of my main query . I have one major difference in the query whenever i use a subquery with IN operator and using IN_list values in IN operator. I found that whenever after using IN operator with sub-query ,all the tables were going for full tablescan but if i used in_list values in the IN operator , all the required indexes were getting used.
    This is part of the query
    from ems_exception
    left outer join EMS_EXCEPTION_LINK_MAP
    on (ems_exception.ID = EMS_EXCEPTION_LINK_MAP.EXCEPTION_ID
    and ems_exception.id in  (SELECt ID
      FROM (SELECT  inner.*,ROWNUM rn
              FROM (SELECT /*+ UNNEST */ e.id,max(e.created_ts) aa
                        FROM ems_exception e
                        join ems_status_def
                        on ( e.status_id =ems_status_def.id and ems_status_def.id in (1,2,3))
                        join ems_exception_link_map
                       on (e.id = ems_exception_link_map.exception_id)
                       join ems_link
                       on (ems_link.id = ems_exception_link_map.link_id)
                       group by e.id 
                       order by aa desc
                       ) inner) outer
                       where outer.rn>=201 and outer.rn <=400 ))
    If i use values instead of the sub-query , the query plan was optimum . Is combination of IN operator and subquery bad in terms of query performance?

    It's not inherently bad - but it does depend on the optimizer getting  good estimate of the data volume.
    Did you test with 200 distinct values in your IN list, and can you see in the execution plan Oracle estimate of how many rows the subquery would generate.
    Regards
    Jonathan Lewis

Maybe you are looking for

  • Is it possible to resize the log and capture window?

    Hi, Using Final cut pro, I would like to make my capture window a bit bigger while capturing. I am capturing footage via my Blackmagic Infinity card and get the input through an HDMI cable. I'm capturing in Apple Pro ress on 720p, 59,59 fps. For a go

  • MacBook Pro - New HD: Nothing working

    So...I have this brand new MacBook Pro. I've had it for 3 months and I've already had the HD changed, about 2 weeks ago...ever since I've reinstalled everything on my computer through TimeMachine, everything's just been wrong. I cannot open Microsoft

  • Clipboard issue with Word and Flash CS4 in Snow Leopard

    I use Flash CS4/word 2008 on a regular basis and copy text from word into flash. Since I upgraded to SL, I no longer can paste text into Flash. This is a major productivity killer for me. Are there any global clipboard settings?

  • Forms won't do order by after the formula columns or constants in union all

    i have a big select as : select * from ( select .....,id doc_id, '1' op from ..... union all select ......., id doc_id, '2' op from ..... union all select ......., id doc_id, '3' op from ..... ) order by id, op where i can have the same id for a numb

  • Exception:cannot be cast to oracle.jbo.uicli.binding.JUCtrlValueBindingRef

    Hi all, Please help - I got this exception when try to retrieve a table row from my backing bean: Caused by: java.lang.ClassCastException: oracle.adfinternal.view.faces.model.binding.FacesCtrlHierNodeBinding cannot be cast to oracle.jbo.uicli.binding