Cardinality in plans

Hello,
Can some one please explain to me what can cause the fact that for the same query, the owner of the objects (tables) and a user with just select rights show different cardinalities in the explain plan?
So user a owns all the tables and the views:
connect a/a
select * from myview;
show cardinality for table t1 referenced in the view 100k.
connect a_read/a_ared
select * from a.myview
show cardinality for table a.t1 referenced in the view 100k.
user a_read doesn't own any objects at all.
Thank you,

show different cardinalities in the explain planWhy didn't you post the explain plans as well then?
And if you decide to do so (on second thought): Please use the tag
( See: http://forums.oracle.com/forums/help.jspa )
And if you're after maximum response: http://tkyte.blogspot.com/2005/06/how-to-ask-questions.html
the owner of the objects (tables) and a user with just select rights show different cardinalities in the explain plan?
Different schema's could mean different ways/intervals regarding gathering statistics, they could be outdated for x, and accurate for y.
See?
I'm just guessing...based on your input
And if my car won't start tomorrow, I'll ask you why ;)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

Similar Messages

  • Query plan shows  Cost: 0 Bytes: 851 Cardinality: 1

    Hi,
    Customer running 10.2.0.4 on linux 64 bit.
    Explain plan shows:
    SELECT STATEMENT ALL_ROWS Cost: 0 Bytes: 851 Cardinality: 1
    8 FILTER
    7 SORT ORDER BY Bytes: 851 Cardinality: 1
    6 HASH JOIN OUTER Cost: 2,873,137 Bytes: 5,047,622,251 Cardinality: 5,931,401
    4 HASH JOIN Cost: 1,696,501 Bytes: 4,567,178,770 Cardinality: 5,931,401
    1 TABLE ACCESS FULL TABLE LIVE.INSTRUMENT Cost: 212,073 Bytes: 679,589,280 Cardinality: 1,595,280
    3 PARTITION RANGE ALL Cost: 764,856 Bytes: 2,040,401,944 Cardinality: 5,931,401 Partition #: 6 Partitions accessed #1 - #27
    2 TABLE ACCESS FULL TABLE LIVE.DEALTRANS Cost: 764,856 Bytes: 2,040,401,944 Cardinality: 5,931,401 Partition #: 6 Partitions accessed #1 - #27
    5 TABLE ACCESS FULL TABLE LIVE.SMDBINSTRUMENT Cost: 1,169 Bytes: 4,958,172 Cardinality: 61,212
    I understand that explain plans can be unreliable but:
    1) why does cost show as 0? Its obviously much higher. Is there just not enough room?
    2) why a cardinality of 1?
    Thanks in advance,
    Steve

    Hi Someoneelse,
    Not sure, i have a query into the client.
    Thanks for responding.
    Steve

  • Datatype best practice and plan cardinality

    Hi,
    I have a scenario where I need to store the data in the format YYYYMM (e.g. 201001 which means January, 2010).
    I am trying to evaluate what is the most appropriate datatype to store this kind of data. I am comparing 2 options, NUMBER and DATE.
    As the data is essentially a component of oracle date datatype and experts like Tom Kyte have proved (with examples) that using right
    datatype is better for optimizer. So I was expecting that using DATE datatype will yield (at least) similar (if not better) cardinality estimates
    than using NUMBER datatype. However, my tests show that when using DATE the cardinality estimates are way off from actuals whereas
    using NUMBER the cardinality estimates are much closer to actuals.
    My questions are:
    1) What should be the most appropriate datatype used to store YYYYMM data?
    2) Why does using DATE datatype yield estimates that are way off from actuals than using NUMBER datatype?
    SQL> select * from V$VERSION ;
    BANNER
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
    PL/SQL Release 10.2.0.1.0 - Production
    CORE     10.2.0.1.0     Production
    TNS for Linux: Version 10.2.0.1.0 - Production
    NLSRTL Version 10.2.0.1.0 - Production
    SQL>  create table a nologging as select to_number(to_char(add_months(to_date('200101','YYYYMM'),level - 1), 'YYYYMM')) id from dual connect by level <= 289 ;
    Table created.
    SQL> create table b (id number) ;
    Table created.
    SQL> begin
      2  for i in 1..8192
      3  loop
      4     insert into b select * from a ;
      5  end loop;
      6  commit;
      7  end;
      8  /
    PL/SQL procedure successfully completed.
    SQL> alter table a add dt date ;
    Table altered.
    SQL> alter table b add dt date ;
    Table altered.
    SQL> select to_date(200101, 'YYYYMM') from dual ;
    TO_DATE(2
    01-JAN-01
    SQL> update a set dt = to_date(id, 'YYYYMM') ;
    289 rows updated.
    SQL> update b set dt = to_date(id, 'YYYYMM') ;
    2367488 rows updated.
    SQL> commit ;
    Commit complete.
    SQL> exec dbms_stats.gather_table_stats(user, 'A', estimate_percent=>NULL) ;
    PL/SQL procedure successfully completed.
    SQL> exec dbms_stats.gather_table_stats(user, 'B', estimate_percent=>NULL) ;    
    SQL> explain plan for select count(*) from b where id between 200810 and 200903 ;
    Explained.
    SQL> select * from table(dbms_xplan.display) ;
    PLAN_TABLE_OUTPUT
    Plan hash value: 749587668
    | Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time       |
    |   0 | SELECT STATEMENT   |       |     1 |     5 |   824   (4)| 00:00:10 |
    |   1 |  SORT AGGREGATE    |       |     1 |     5 |            |       |
    |*  2 |   TABLE ACCESS FULL| B       | 46604 |   227K|   824   (4)| 00:00:10 |
    Predicate Information (identified by operation id):
    PLAN_TABLE_OUTPUT
       2 - filter("ID"<=200903 AND "ID">=200810)
    14 rows selected.
    SQL> explain plan for select count(*) from b where dt between to_date(200810, 'YYYYMM') and to_date(200903, 'YYYYMM') ;
    Explained.
    SQL> select * from table(dbms_xplan.display) ;
    PLAN_TABLE_OUTPUT
    Plan hash value: 749587668
    | Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time       |
    |   0 | SELECT STATEMENT   |       |     1 |     5 |   825   (4)| 00:00:10 |
    |   1 |  SORT AGGREGATE    |       |     1 |     5 |            |       |
    |*  2 |   TABLE ACCESS FULL| B       |  5919 | 29595 |   825   (4)| 00:00:10 |
    Predicate Information (identified by operation id):
    PLAN_TABLE_OUTPUT
       2 - filter("DT">=TO_DATE('2008-10-01 00:00:00', 'yyyy-mm-dd
               hh24:mi:ss') AND "DT"<=TO_DATE('2009-03-01 00:00:00', 'yyyy-mm-dd
               hh24:mi:ss'))
    16 rows selected.

    Charles,
    Thanks for your response.
    I did not think of the possibilitty of histograms. When I ran the tests on 10.2.0.4, I could get the results as you have shown.
    So I thought it might be due to some bug in 10.2.0.1. But interestingly, when I ran the test after collecting statistics using 'FOR ALL COLUMNS SIZE 1'
    option, I got the cardinalities that match my 10.2.0.1 results (where METHOD_OPT was default i.e. 'FOR ALL COLUMNS SIZE AUTO').
    So I carried out the tests again on 10.2.0.1 but the results did not look consistent to me. When there were no histograms on DATE column, the cardinality
    was quite close to actuals but when I collected stats using 'FOR ALL COLUMNS SIZE SKEWONLY', it generated histograms on DATE column but
    the cardinality was not quite close to actuals.
    So I am bit confused about whether this is due to a bug or due to combined effect of optimizer's "intelligence" while collecting statistics using default option
    values and the way table is queried (COL_USAGE$ data).
    Here is my test:
    SQL> select * from v$version ;
    BANNER
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
    PL/SQL Release 10.2.0.1.0 - Production
    CORE     10.2.0.1.0     Production
    TNS for Linux: Version 10.2.0.1.0 - Production
    NLSRTL Version 10.2.0.1.0 - Production
    SQL> exec dbms_stats.delete_table_stats(user, 'B') ;
    PL/SQL procedure successfully completed.
    SQL> select column_name, num_distinct, num_buckets, histogram from user_tab_col_statistics where table_name = 'B' ;
    no rows selected
    SQL> exec dbms_stats.gather_table_stats(user, 'B') ;
    PL/SQL procedure successfully completed.
    SQL> select column_name, num_distinct, num_buckets, histogram from user_tab_col_statistics where table_name = 'B' ;
    COLUMN_NAME                    NUM_DISTINCT NUM_BUCKETS HISTOGRAM
    ID                                      289         254 HEIGHT BALANCED
    DT                                      289         254 HEIGHT BALANCED
    SQL> explain plan for select count(*) from b where b.id between 200810 and 200903 ;
    Explained.
    SQL> select * from table(dbms_xplan.display) ;
    PLAN_TABLE_OUTPUT
    Plan hash value: 749587668
    | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |      |     1 |     5 |  3691   (1)| 00:00:45 |
    |   1 |  SORT AGGREGATE    |      |     1 |     5 |            |          |
    |*  2 |   TABLE ACCESS FULL| B    | 38218 |   186K|  3691   (1)| 00:00:45 |
    Predicate Information (identified by operation id):
       2 - filter("B"."ID"<=200903 AND "B"."ID">=200810)
    14 rows selected.
    SQL> explain plan for select count(*) from b where b.dt between to_date(200810, 'YYYYMM') and to_date(200903, 'YYYYMM') ;
    Explained.
    SQL> select * from table(dbms_xplan.display) ;
    PLAN_TABLE_OUTPUT
    Plan hash value: 749587668
    | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |      |     1 |     8 |  3693   (1)| 00:00:45 |
    |   1 |  SORT AGGREGATE    |      |     1 |     8 |            |          |
    |*  2 |   TABLE ACCESS FULL| B    | 38218 |   298K|  3693   (1)| 00:00:45 |
    Predicate Information (identified by operation id):
       2 - filter("B"."DT"<=TO_DATE('2009-03-01 00:00:00', 'yyyy-mm-dd
                  hh24:mi:ss') AND "B"."DT">=TO_DATE('2008-10-01 00:00:00', 'yyyy-mm-dd
                  hh24:mi:ss'))
    16 rows selected.
    SQL> connect sys as sysdba ;
    Connected.
    SQL> delete from sys.col_usage$ where obj# in (select object_id from all_objects where owner = 'HR' and object_name in ('A','B')) ;
    4 rows deleted.
    SQL> commit ;
    Commit complete.
    SQL> connect hr/hr ;
    Connected.
    SQL> set serveroutput on size 10000
    SQL> exec dbms_stats.delete_table_stats(user, 'B') ;
    PL/SQL procedure successfully completed.
    SQL> exec dbms_stats.gather_table_stats(user, 'B') ;
    PL/SQL procedure successfully completed.
    SQL> select column_name, num_distinct, num_buckets, histogram from user_tab_col_statistics where table_name = 'B' ;
    COLUMN_NAME                    NUM_DISTINCT NUM_BUCKETS HISTOGRAM
    ID                                      289           1 NONE
    DT                                      289           1 NONE
    SQL> explain plan for select count(*) from b where b.id between 200810 and 200903 ;
    Explained.
    SQL> select * from table(dbms_xplan.display) ;
    PLAN_TABLE_OUTPUT
    Plan hash value: 749587668
    | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |      |     1 |     5 |  3691   (1)| 00:00:45 |
    |   1 |  SORT AGGREGATE    |      |     1 |     5 |            |          |
    |*  2 |   TABLE ACCESS FULL| B    |   110K|   541K|  3691   (1)| 00:00:45 |
    Predicate Information (identified by operation id):
       2 - filter("B"."ID"<=200903 AND "B"."ID">=200810)
    14 rows selected.
    SQL> explain plan for select count(*) from b where b.dt between to_date(200810, 'YYYYMM') and to_date(200903, 'YYYYMM') ;
    Explained.
    SQL> select * from table(dbms_xplan.display) ;
    PLAN_TABLE_OUTPUT
    Plan hash value: 749587668
    | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |      |     1 |     8 |  3693   (1)| 00:00:45 |
    |   1 |  SORT AGGREGATE    |      |     1 |     8 |            |          |
    |*  2 |   TABLE ACCESS FULL| B    | 58680 |   458K|  3693   (1)| 00:00:45 |
    Predicate Information (identified by operation id):
       2 - filter("B"."DT"<=TO_DATE('2009-03-01 00:00:00', 'yyyy-mm-dd
                  hh24:mi:ss') AND "B"."DT">=TO_DATE('2008-10-01 00:00:00', 'yyyy-mm-dd
                  hh24:mi:ss'))
    16 rows selected.
    SQL> exec dbms_stats.gather_table_stats(user, 'B') ;
    PL/SQL procedure successfully completed.
    SQL> select column_name, num_distinct, num_buckets, histogram from user_tab_col_statistics where table_name = 'B' ;
    COLUMN_NAME                    NUM_DISTINCT NUM_BUCKETS HISTOGRAM
    ID                                      289         254 HEIGHT BALANCED
    DT                                      289           1 NONE
    SQL> explain plan for select count(*) from b where b.id between 200810 and 200903 ;
    Explained.
    SQL> select * from table(dbms_xplan.display) ;
    PLAN_TABLE_OUTPUT
    Plan hash value: 749587668
    | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |      |     1 |     5 |  3690   (1)| 00:00:45 |
    |   1 |  SORT AGGREGATE    |      |     1 |     5 |            |          |
    |*  2 |   TABLE ACCESS FULL| B    | 46303 |   226K|  3690   (1)| 00:00:45 |
    Predicate Information (identified by operation id):
       2 - filter("B"."ID"<=200903 AND "B"."ID">=200810)
    14 rows selected.
    SQL> explain plan for select count(*) from b where b.dt between to_date(200810, 'YYYYMM') and to_date(200903, 'YYYYMM') ;
    Explained.
    SQL> select * from table(dbms_xplan.display) ;
    PLAN_TABLE_OUTPUT
    Plan hash value: 749587668
    | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |      |     1 |     8 |  3692   (1)| 00:00:45 |
    |   1 |  SORT AGGREGATE    |      |     1 |     8 |            |          |
    |*  2 |   TABLE ACCESS FULL| B    | 56797 |   443K|  3692   (1)| 00:00:45 |
    Predicate Information (identified by operation id):
       2 - filter("B"."DT"<=TO_DATE('2009-03-01 00:00:00', 'yyyy-mm-dd
                  hh24:mi:ss') AND "B"."DT">=TO_DATE('2008-10-01 00:00:00', 'yyyy-mm-dd
                  hh24:mi:ss'))
    16 rows selected.
    SQL> exec dbms_stats.gather_table_stats(user, 'B') ;
    PL/SQL procedure successfully completed.
    SQL> select column_name, num_distinct, num_buckets, histogram from user_tab_col_statistics where table_name = 'B' ;
    COLUMN_NAME                    NUM_DISTINCT NUM_BUCKETS HISTOGRAM
    ID                                      289         254 HEIGHT BALANCED
    DT                                      289           1 NONE
    SQL> exec dbms_stats.gather_table_stats(user, 'B', method_opt=>'FOR ALL COLUMNS SIZE SKEWONLY') ;
    PL/SQL procedure successfully completed.
    SQL> select column_name, num_distinct, num_buckets, histogram from user_tab_col_statistics where table_name = 'B' ;
    COLUMN_NAME                 NUM_DISTINCT NUM_BUCKETS HISTOGRAM
    ID                         289         254 HEIGHT BALANCED
    DT                         289         254 HEIGHT BALANCED
    SQL> explain plan for select count(*) from b where b.dt between to_date(200810, 'YYYYMM') and to_date(200903, 'YYYYMM') ;
    Explained.
    SQL> select * from table(dbms_xplan.display) ;
    PLAN_TABLE_OUTPUT
    Plan hash value: 749587668
    | Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time       |
    |   0 | SELECT STATEMENT   |       |     1 |     8 |  3692   (1)| 00:00:45 |
    |   1 |  SORT AGGREGATE    |       |     1 |     8 |            |       |
    |*  2 |   TABLE ACCESS FULL| B       | 27862 |   217K|  3692   (1)| 00:00:45 |
    Predicate Information (identified by operation id):
       2 - filter("B"."DT"<=TO_DATE('2009-03-01 00:00:00', 'yyyy-mm-dd
               hh24:mi:ss') AND "B"."DT">=TO_DATE('2008-10-01 00:00:00', 'yyyy-mm-dd
               hh24:mi:ss'))
    16 rows selected.
    SQL> explain plan for select count(*) from b where id between 200810 and 200903 ;
    Explained.
    SQL> select * from table(dbms_xplan.display) ;
    PLAN_TABLE_OUTPUT
    Plan hash value: 749587668
    | Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time       |
    |   0 | SELECT STATEMENT   |       |     1 |     5 |  3690   (1)| 00:00:45 |
    |   1 |  SORT AGGREGATE    |       |     1 |     5 |            |       |
    |*  2 |   TABLE ACCESS FULL| B       | 32505 |   158K|  3690   (1)| 00:00:45 |
    Predicate Information (identified by operation id):
       2 - filter("ID"<=200903 AND "ID">=200810)
    14 rows selected.

  • Force statement to use a given rule or execution plan

    Hi!
    We have a statement that in our production system takes 6-7 seconds to complete. The statement comes from our enterprise application's core code and we are not able to change the statement.
    When using a RULE-hint (SELECT /*+RULE*/ 0 pay_rec...........) for this statement, the execution time is down to 500 milliseconds.
    My question is: Is there any way to pin a execution plan to a given statement. I have started reading about outlines, which seems promising. However, the statement is not using bind-variables, and since this is core code in an enterprise application I cannot change that either. Is it possible to use outlines with such a statement?
    Additional information:
    When I remove all statistics for the involved tables, the query blows away in 500 ms.
    The table tran_info_types has 61 rows and is a stable table with few updates
    The table ab_tran_info has 1 717 439 records and is 62 MB in size.
    The table query_result has 777 015 records and is 216 MB in size. This table is constantly updated/insterted/deleted.
    The query below return 0 records as there is no hits in the table query_result.
    This is the statement:
    SELECT  /*+ALL_ROWS*/
           0 pay_rec, abi.tran_num, abi.type_id, abi.VALUE
      FROM ab_tran_info abi,
           tran_info_types ti,
           query_result qr1,
           query_result qr2
    WHERE abi.tran_num = qr1.query_result
       AND abi.type_id = qr2.query_result
       AND abi.type_id = ti.type_id
       AND ti.ins_or_tran = 0
       AND qr1.unique_id = 5334549
       AND qr2.unique_id = 5334550
    UNION ALL
    SELECT 1 pay_rec, abi.tran_num, abi.type_id, abi.VALUE
      FROM ab_tran_info abi,
           tran_info_types ti,
           query_result qr1,
           query_result qr2
    WHERE abi.tran_num = qr1.query_result
       AND abi.type_id = qr2.query_result
       AND abi.type_id = ti.type_id
       AND ti.ins_or_tran = 0
       AND qr1.unique_id = 5334551
       AND qr2.unique_id = 5334552;Here is the explain plan with statistics:
    Plan
    SELECT STATEMENT  HINT: ALL_ROWSCost: 900  Bytes: 82  Cardinality: 2                           
         15 UNION-ALL                      
              7 NESTED LOOPS  Cost: 450  Bytes: 41  Cardinality: 1                 
                   5 NESTED LOOPS  Cost: 449  Bytes: 1,787,940  Cardinality: 59,598            
                        3 NESTED LOOPS  Cost: 448  Bytes: 19,514,824  Cardinality: 1,027,096       
                             1 INDEX RANGE SCAN UNIQUE TRADEDB.TIT_DANIEL_2 Search Columns: 1  Cost: 1  Bytes: 155  Cardinality: 31 
                             2 INDEX RANGE SCAN UNIQUE TRADEDB.ATI_DANIEL_7 Search Columns: 1  Cost: 48  Bytes: 471,450  Cardinality: 33,675 
                        4 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 11  Cardinality: 1       
                   6 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 11  Cardinality: 1            
              14 NESTED LOOPS  Cost: 450  Bytes: 41  Cardinality: 1                 
                   12 NESTED LOOPS  Cost: 449  Bytes: 1,787,940  Cardinality: 59,598            
                        10 NESTED LOOPS  Cost: 448  Bytes: 19,514,824  Cardinality: 1,027,096       
                             8 INDEX RANGE SCAN UNIQUE TRADEDB.TIT_DANIEL_2 Search Columns: 1  Cost: 1  Bytes: 155  Cardinality: 31 
                             9 INDEX RANGE SCAN UNIQUE TRADEDB.ATI_DANIEL_7 Search Columns: 1  Cost: 48  Bytes: 471,450  Cardinality: 33,675 
                        11 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 11  Cardinality: 1       
                   13 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 11  Cardinality: 1            Here is the execution plan when I have removed all statistics (exec DBMS_STATS.DELETE_TABLE_STATS(.........,..........); )
    Plan
    SELECT STATEMENT  HINT: ALL_ROWSCost: 12  Bytes: 3,728  Cardinality: 16                           
         15 UNION-ALL                      
              7 NESTED LOOPS  Cost: 6  Bytes: 1,864  Cardinality: 8                 
                   5 NESTED LOOPS  Cost: 6  Bytes: 45,540  Cardinality: 220            
                        3 NESTED LOOPS  Cost: 6  Bytes: 1,145,187  Cardinality: 6,327       
                             1 TABLE ACCESS FULL TRADEDB.TRAN_INFO_TYPES Cost: 2  Bytes: 104  Cardinality: 4 
                             2 INDEX RANGE SCAN UNIQUE TRADEDB.ATI_DANIEL_6 Search Columns: 1  Cost: 1  Bytes: 239,785  Cardinality: 1,547 
                        4 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 26  Cardinality: 1       
                   6 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 26  Cardinality: 1            
              14 NESTED LOOPS  Cost: 6  Bytes: 1,864  Cardinality: 8                 
                   12 NESTED LOOPS  Cost: 6  Bytes: 45,540  Cardinality: 220            
                        10 NESTED LOOPS  Cost: 6  Bytes: 1,145,187  Cardinality: 6,327       
                             8 TABLE ACCESS FULL TRADEDB.TRAN_INFO_TYPES Cost: 2  Bytes: 104  Cardinality: 4 
                             9 INDEX RANGE SCAN UNIQUE TRADEDB.ATI_DANIEL_6 Search Columns: 1  Cost: 1  Bytes: 239,785  Cardinality: 1,547 
                        11 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 26  Cardinality: 1       
                   13 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 26  Cardinality: 1            Our Oracle 9.2 database is set up with ALL_ROWS.
    Outlines: http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96533/outlines.htm#13091
    Cursor sharing: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:3696883368520

    Hi!
    We are on Oracle 9iR2, running on 64-bit Linux.
    We are going to upgrade to Oracle 10gR2 in some months. Oracle 11g is not an option for us as our application is not certified by our vendor to run on that version.
    However, our performance problems are urgent so we are looking for a solution before we upgrade as we are not able to upgrade before we have done extensive testing which takes 2-3 months.
    We have more problem sql's than the one shown in this post. I am using the above SQL as a sample as I think we can solve many other slow running SQL's if we solve this one.
    Is the SQL Plan management an option on Oracle 9i and/or Oracle 10g?

  • Cardinality estimator 2014 is off with OR in where clause

    Here is my test setup on SQL Server 2014.
    -- Create big table
    CREATE TABLE [dbo].[Store](
    Id int IDENTITY(1,1) NOT NULL,
    City int NOT NULL,
    Size int NOT NULL,
    Name varchar(max) NULL,
    CONSTRAINT [PK_Store] PRIMARY KEY CLUSTERED ([Id] ASC)
    GO
    CREATE NONCLUSTERED INDEX [IX_Store] ON [dbo].[Store] (City ASC, Size ASC)
    GO
    -- Fill with 100k rows
    INSERT Store
    SELECT i % 101, i % 11, 'Store ' + CAST(i AS VARCHAR)
    FROM
    (SELECT TOP 100000 ROW_NUMBER() OVER (ORDER BY s1.[object_id]) AS i
    FROM sys.all_objects s1, sys.all_objects s2) numbers
    GO
    -- Create small table
    CREATE TABLE #StoreRequest (City int NOT NULL, Size int NOT NULL)
    GO
    INSERT #StoreRequest values (55, 1)
    INSERT #StoreRequest values (66, 2)
    Now I execute the following query (I force the index to show statistics estimates)
    SELECT s.City
    FROM #StoreRequest AS r
    INNER JOIN Store AS s WITH(INDEX(IX_Store), FORCESEEK)
    ON s.City = r.City AND s.Size = r.Size
    WHERE s.Size <> 1 OR r.City <> 55
    Here are the estimates that I get (I'm not allowed to upload pictures):
    Index Seek IX_Store
    Actual Number of Rows: 90
    Estimated Number of Rows: 50000
    Fixing WHERE clause to use one table not two makes the estimate perfect:
    SELECT s.City
    FROM #StoreRequest AS r
    INNER JOIN Store AS s WITH(INDEX(IX_Store), FORCESEEK)
    ON s.City = r.City AND s.Size = r.Size
    WHERE s.Size <> 1 OR s.City <> 55
    Index Seek IX_Store
    Actual Number of Rows: 90
    Estimated Number of Rows: 89.74
    Switching to 2012 compatibility mode gives estimate of 1 in both cases:
    Index Seek IX_Store
    Actual Number of Rows: 90
    Estimated Number of Rows: 1
    Could anyone explain the first result? I'm a bit worried about it. The fix in this case is trivial, but this problem gave us quite some headache in more complex real life queries with multiple joins.
    Thank you!

    But not full statistics on a field basis, just sometimes some default stats like total row count that some plans will build.  Even your StoreRequest table only has one two-field index that will have a full histogram.
    But I've seen SQL Server make massively bad plans on two-field indexes.
    I've seen SQL Server go wrong one-column indexes, so that is not a very relevant point.
    Temp tables or not, the estimate here is clearly incorrect. SQL Server knows the density of Size and City. It knows the cardinality of the temp table. The density information gives how many rows the the join will produce. The WHERE clause will then remove
    a certain number of rows. With no statistics for the temp table, it does not now how many, but it will apply some standard guess.
    50000 is a completely bogus number, because the join cannot produce that many rows, and SQL Server is able to compute the join with out the WHERE clause decently. (Well, it estimates 90, when the number is 180.) No, this is obviously a case of the cardinality
    estimator giving up completely.
    It is worth noting that both these WHERE clauses gives reasonable estimates:
     WHERE r.Size <> 11 OR r.City <> 550
     WHERE s.Size <> 11 OR s.City <> 550
    Whereas these two gives the spooky 50000:
     WHERE s.Size <> 11 OR r.City <> 550
     WHERE r.Size <> 11 OR s.City <> 550
    Erland Sommarskog, SQL Server MVP, [email protected]

  • Execution plan with bind variable

    dear all
    I join two tables and get "index fast full scan" with high cost using bind variable
    but when I remove the bind variable it executes with "index" and with lower cost
    What is the reason and how should I know which execution plan is really used in real life?
    thanks
    john

    1) What is oracle version?
    2) Post here both query and their explain plan.
    In fact INDEX FAST FULL SCAN indicate is multiblock read for composite indexes(and based on your query and predicates).In this case CBO behavior as FULL TABLE SCAN(affected by db_multiblock_read_count,system stats,etc).And you use bind variable.So in bind variable case CBO define selectivity based on arithmetic(5% of the cardinality) ,if you use concrete values instead of bind variable CBO identify other selectivity based on statistics,histograms,.... then it was identify cost of multiblock read and single block reads.You can see these 10053 event.Finally it choose lower cost`s plan.

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

  • What is line item dimension and cardinality in BI 7.0

    Can u plz suggest me what is line item dimension and cardinality in BI 7.0..
    Thanks in advance.
    Venkat

    Hi Babu
    Line item: This means the dimension contains precisely one characteristic. This means that the system does not create a dimension table. Instead, the SID table of the characteristic takes on the role of dimension table. Removing the dimension table has the following advantages:
    ¡        When loading transaction data, no IDs are generated for the entries in the dimension table. This number range operation can compromise performance precisely in the case where a degenerated dimension is involved.
    ¡        A table- having a very large cardinality- is removed from the star schema. As a result, the SQL-based queries are simpler. In many cases, the database optimizer can choose better execution plans.
    Nevertheless, it also has a disadvantage: A dimension marked as a line item cannot subsequently include additional characteristics. This is only possible with normal dimensions.
    Note: In SAP BW 3.0, the term line item dimension from SAP BW 2.0 must a) have precisely one characteristic and b) this characteristic must have a high cardinality. Before, the term line item dimension was often only associated with a). Hence the inclusion of this property in the above. Be aware that a line item dimension has a different meaning now than in SAP BW2.0.
    SAP recommends that you use ODS objects, where possible, instead of InfoCubes for line items.
    Hope this helps.
    Plz check these links:
    SAP Help:
    http://help.sap.com/saphelp_nw04s/helpdata/en/a7/d50f395fc8cb7fe10000000a11402f/frameset.htm
    Thanks & Regards
    Reward if helped
    Edited by: Noor Ahmed khan on Aug 5, 2008 2:36 PM

  • How to force a execution plan

    Hello ,
    I am working on oracle 11g R2 on AIX.
    One query was performing good around 20 sec. but suddenly it took more then 15 min.
    We check that the sql executoin plan changes , it showing that order of operation changed like order of using indexes is different.
    Now the new plan is not good.
    we want to force the old plan of sql to use in future.
    I read about sql plan management , it shows a manual method to create baseline and evolve the all plan. In one texample we found that
    first query execution plan was created using with out index and then with index So, second plan was good and accepted.
    But in this case we do not need to change any thing ,query is performing bad may be becasue changes order of operation ..
    One other way to use hint , but for this we need to change sqls , which is not possiable in production now.
    The issue is
    For this we need to run the sql again and oracle may not create plan like old one.So we will not be having old good plan to accept.
    All 2 execution plan are already in cache .
    I am looking for a way using that we can set sql plan hash value ( of good plan) or any other id of that sql plan to force to use that plan only.
    any idea how to do it ..

    Stored Outlines are deprecated.
    OP:
    To fix a specific plan you have two choices:
    1. SQL Plan Baselines - assuming the "good" plan is in AWR still then the steps are along the lines of load old plan from AWR into sql tuning set using DBMS_SQLTUNE.SELECT_WORKLOAD_REPOSITORY and DBMS_SQLTUNE.LOAD_SQLSET then load plans from sqlset into sql plan baseline using DBMS_SPM.LOAD_PLANS_FROM_SQLSET.
    2. Using SQL Profiles to fix the outline hints - so similar to a stored outline but using the sql profile mechanism - using the coe_xfr_sql_profile.sql script, part of an approach in Oracle support doc id 215187.1
    But +1 for Nikolay's recommendation of understanding whether there is a root cause to this problem instability (plan instability being "normal", but flip flopping between "good" and "bad" being a problem). Cardinality feedback is an obvious possible influence, different peeked binds another, stat changes, etc.

  • Bad query plan for self-referencing CTE view query and variable in WHERE clause. Is there way out or this is SQL Server defect?

    Please help. Thank you for your time and expertise.
    Prerequisites: sql query needs to be a view. Real view is more than recursion. It computes location path,  is used in JOINs and returns this path.
    Problem: no matter what I tried, sql server does not produce 'index seek' when using variable but does with literal.
    See full reproduction code below.
    I expect that query SELECT lcCode FROM dbo.vwLocationCodes l WHERE l.lcID = @lcID will seek UNIQUE index but it does not.
    I tried these:
    1. Changing UX and/or PK to be CLUSTERED.
    2. query OPTION(RECOMPILE)
    3. FORCESEEK on view
    4. SQL Server 2012/2014
    5. Wrap it into function and CROSS APPLY. On large outer number of rows this just dies, no solution
    but to no avail. This smells like a bug in SQL Server. I am seeking your confirmation.
    I am thinking it is a bug as variable value is high-cardinality, 1, and query is against unique key. This must produce single seek, depending if clustered or nonclustred index is unique
    Thanks
    Vladimir
    use tempdb
    BEGIN TRAN
    -- setup definition
    CREATE TABLE dbo.LocationHierarchy(
    lcID int NOT NULL ,
    lcHID hierarchyid NOT NULL,
    lcCode nvarchar(25) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
    lcHIDParent AS lcHID.GetAncestor(1) PERSISTED,
    CONSTRAINT PK_LocationHierarchy_lcID PRIMARY KEY NONCLUSTERED (lcID ASC),
    CONSTRAINT UX_LocationHierarchy_pltID_lcHID UNIQUE CLUSTERED (lcHID ASC)
    -- add some data
    INSERT INTO dbo.LocationHierarchy
    VALUES
    (1, '/', 'A')
    ,(2, '/1/', 'B')
    ,(3, '/1/1/', 'C')
    ,(4, '/1/1/1/', 'D')
    --DROP VIEW dbo.vwLocationCodes
    GO
    CREATE VIEW dbo.vwLocationCodes
    AS
    WITH ru AS
    SELECT
    lh.lcID
    ,lh.lcCode
    ,lh.lcHID
    ,CAST('/' + lh.lcCode + '/' as varchar(8000)) as LocationPath
    -- to support recursion
    ,lh.lcHIDParent
    FROM dbo.LocationHierarchy lh
    UNION ALL
    SELECT
    ru.lcID
    ,ru.lcCode
    ,ru.lcHID
    ,CAST('/' + lh.lcCode + ru.LocationPath as varchar(8000)) as LocationPath
    ,lh.lcHIDParent
    FROM dbo.LocationHierarchy lh
    JOIN ru ON ru.lcHIDParent = lh.lcHID
    SELECT
    lh.lcID
    ,lh.lcCode
    ,lh.LocationPath
    ,lh.lcHID
    FROM ru lh
    WHERE lh.lcHIDParent IS NULL
    GO
    -- get data via view
    SELECT
    CONCAT(SPACE(l.lcHID.GetLevel() * 4), lcCode) as LocationIndented
    FROM dbo.vwLocationCodes l
    ORDER BY lcHID
    GO
    SET SHOWPLAN_XML ON
    GO
    DECLARE @lcID int = 2
    -- I believe this produces bad plan and is defect in SQL Server optimizer.
    -- variable value cardinality is 1 and SQL Server should know that. Optiomal plan is to do index seek with key lookup.
    -- This does not happen.
    SELECT lcCode FROM dbo.vwLocationCodes l WHERE l.lcID = @lcID -- bad plan
    -- this is a plan I expect.
    SELECT lcCode FROM dbo.vwLocationCodes l WHERE l.lcID = 2 -- good plan
    -- I reviewed these but I need a view here, can't be SP
    -- http://sqlblogcasts.com/blogs/tonyrogerson/archive/2008/05/17/non-recursive-common-table-expressions-performance-sucks-1-cte-self-join-cte-sub-query-inline-expansion.aspx
    -- http://social.msdn.microsoft.com/Forums/sqlserver/en-US/22d2d580-0ff8-4a9b-b0d0-e6a8345062df/issue-with-select-using-a-recursive-cte-and-parameterizing-the-query?forum=transactsql
    GO
    SET SHOWPLAN_XML OFF
    GO
    ROLLBACK
    Vladimir Moldovanenko

    Here is more... note that I am creating table Items and these can be in Locations.
    I am trying LEFT JOIN and OUTER APLLY to 'bend' query into NESTED LOOP and SEEK. There has to be nested loop, 2 rows against 4. But SQL Server fails to generate optimal plan with SEEK. Even RECOMPILE does not help
    use tempdb
    BEGIN TRAN
    -- setup definition
    CREATE TABLE dbo.LocationHierarchy(
    lcID int NOT NULL ,
    lcHID hierarchyid NOT NULL,
    lcCode nvarchar(25) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
    lcHIDParent AS lcHID.GetAncestor(1) PERSISTED,
    CONSTRAINT PK_LocationHierarchy_lcID PRIMARY KEY NONCLUSTERED (lcID ASC),
    CONSTRAINT UX_LocationHierarchy_pltID_lcHID UNIQUE CLUSTERED (lcHID ASC)
    -- add some data
    INSERT INTO dbo.LocationHierarchy
    VALUES
    (1, '/', 'A')
    ,(2, '/1/', 'B')
    ,(3, '/1/1/', 'C')
    ,(4, '/1/1/1/', 'D')
    --DROP VIEW dbo.vwLocationCodes
    GO
    --DECLARE @Count int = 10;
    --WITH L0 AS (SELECT N FROM (VALUES(1),(1),(1),(1),(1),(1),(1),(1),(1),(1)) N (N))-- 10 rows
    --,L1 AS (SELECT n1.N FROM L0 n1 CROSS JOIN L0 n2) -- 100 rows
    --,L2 AS (SELECT n1.N FROM L1 n1 CROSS JOIN L1 n2) -- 10,000 rows
    --,L3 AS (SELECT n1.N FROM L2 n1 CROSS JOIN L2 n2) -- 100,000,000 rows
    --,x AS
    -- SELECT TOP (ISNULL(@Count, 0))
    -- ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) as Number
    -- FROM L3 n1
    --SELECT Number as itmID, NTILE(4)OVER(ORDER BY Number) as lcID
    --INTO dbo.Items
    --FROM x
    ----ORDER BY n1.N
    --ALTER TABLE dbo.Items ALTER COLUMN itmID INT NOT NULL
    --ALTER TABLE dbo.Items ADD CONSTRAINT PK PRIMARY KEY CLUSTERED (itmID)
    CREATE TABLE dbo.Items (itmID int NOT NULL PRIMARY KEY, lcID int NOT NULL)
    INSERT INTO dbo.items
    VALUES(1, 1)
    ,(2, 3)
    GO
    CREATE VIEW dbo.vwLocationCodes
    AS
    WITH ru AS
    SELECT
    lh.lcID
    ,lh.lcCode
    ,lh.lcHID
    ,CAST('/' + lh.lcCode + '/' as varchar(8000)) as LocationPath
    -- to support recursion
    ,lh.lcHIDParent
    FROM dbo.LocationHierarchy lh
    UNION ALL
    SELECT
    ru.lcID
    ,ru.lcCode
    ,ru.lcHID
    ,CAST('/' + lh.lcCode + ru.LocationPath as varchar(8000)) as LocationPath
    ,lh.lcHIDParent
    FROM dbo.LocationHierarchy lh
    JOIN ru ON ru.lcHIDParent = lh.lcHID
    SELECT
    lh.lcID
    ,lh.lcCode
    ,lh.LocationPath
    ,lh.lcHID
    FROM ru lh
    WHERE lh.lcHIDParent IS NULL
    GO
    -- get data via view
    SELECT
    CONCAT(SPACE(l.lcHID.GetLevel() * 4), lcCode) as LocationIndented
    FROM dbo.vwLocationCodes l
    ORDER BY lcHID
    GO
    --SET SHOWPLAN_XML ON
    GO
    DECLARE @lcID int = 2
    -- I believe this produces bad plan and is defect in SQL Server optimizer.
    -- variable value cardinality is 1 and SQL Server should know that. Optiomal plan is to do index seek with key lookup.
    -- This does not happen.
    SELECT lcCode FROM dbo.vwLocationCodes l WHERE l.lcID = @lcID-- OPTION(RECOMPILE) -- bad plan
    -- this is a plan I expect.
    SELECT lcCode FROM dbo.vwLocationCodes l WHERE l.lcID = 2 -- good plan
    SELECT *
    FROM dbo.Items itm
    LEFT JOIN dbo.vwLocationCodes l ON l.lcID = itm.lcID
    OPTION(RECOMPILE)
    SELECT *
    FROM dbo.Items itm
    OUTER APPLY
    SELECT *
    FROM dbo.vwLocationCodes l
    WHERE l.lcID = itm.lcID
    ) l
    -- I reviewed these but I need a view here, can't be SP
    -- http://sqlblogcasts.com/blogs/tonyrogerson/archive/2008/05/17/non-recursive-common-table-expressions-performance-sucks-1-cte-self-join-cte-sub-query-inline-expansion.aspx
    -- http://social.msdn.microsoft.com/Forums/sqlserver/en-US/22d2d580-0ff8-4a9b-b0d0-e6a8345062df/issue-with-select-using-a-recursive-cte-and-parameterizing-the-query?forum=transactsql
    GO
    --SET SHOWPLAN_XML OFF
    GO
    ROLLBACK
    Vladimir Moldovanenko

  • Cardinality explosion with several XMLTable calls in one query - how to constrain ?

    Hi,
    when I engage several (say, four) XMLTable calls using comma (= cartesian join) in a single query, the plan shows me insane cost of 15 digits. Though execution time is reasonable because XML document is very small, I would like the plan appear with more realistic values to correctly predict query time when XML document becomes larger. How can I make CBO be aware of actual size of XML text?
    Should I use XML indexing to constrain search space? What are the 'best practices' in indexing XML text for efficient parsing by XMLTable?
    SQL> select * from v$version;
    BANNER
    Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
    PL/SQL Release 11.2.0.3.0 - Production
    CORE    11.2.0.3.0      Production
    TNS for Linux: Version 11.2.0.3.0 - Production
    NLSRTL Version 11.2.0.3.0 - Production
    Thanks for your answers!

    Hi,
    Thanks, odie_63. I used index to give CBA an idea of cardinality.
    So, the original plan is (P=Peta, T=Tera, etc...):
    Plan hash value: 954188411
    | Id  | Operation             | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT      |             |  4451T|  5099P|    14T  (1)|999:59:59 |
    |   1 |  NESTED LOOPS         |             |  4451T|  5099P|    14T  (1)|999:59:59 |
    |   2 |   NESTED LOOPS        |             |   544G|   638T|  1816M  (1)|999:59:59 |
    |   3 |    NESTED LOOPS       |             |    66M|    79G|   222K  (1)| 00:44:34 |
    |   4 |     NESTED LOOPS      |             |  8168 |     9M|    32   (0)| 00:00:01 |
    |   5 |      TABLE ACCESS FULL| XML_DROPBOX |     1 |  1252 |     3   (0)| 00:00:01 |
    |   6 |      XPATH EVALUATION |             |       |       |            |          |
    |   7 |     XPATH EVALUATION  |             |       |       |            |          |
    |   8 |    XPATH EVALUATION   |             |       |       |            |          |
    |   9 |   XPATH EVALUATION    |             |       |       |            |          |
    Note
       - Unoptimized XML construct detected (enable XMLOptimizationCheck for more information)
    After creating an index, like:
    CREATE INDEX XML_DROPBOX_IDX  ON XML_DROPBOX (SYS_NC_ROWINFO$)
      INDEXTYPE IS XDB.XMLINDEX PARAMETERS (
      'PATH TABLE XML_DROPBOX_PATH_IDX (NOLOGGING ENABLE ROW MOVEMENT)
       PATH ID INDEX XML_DROPBOX_PATH_ID_IDX (NOLOGGING)'
    the plan become more voluminous, but shows realistic cost:
    Plan hash value: 1726871192
    | Id  | Operation                          | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                   |                         |     1 | 10666 |     9   (0)| 00:00:01 |
    |*  1 |  FILTER                            |                         |       |       |            |          |
    |*  2 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 |  3524 |     2   (0)| 00:00:01 |
    |*  3 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
    |*  4 |  FILTER                            |                         |       |       |            |          |
    |*  5 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 |  3524 |     2   (0)| 00:00:01 |
    |*  6 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
    |*  7 |  FILTER                            |                         |       |       |            |          |
    |*  8 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 |  3524 |     2   (0)| 00:00:01 |
    |*  9 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
    |* 10 |  FILTER                            |                         |       |       |            |          |
    |* 11 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 |  3524 |     2   (0)| 00:00:01 |
    |* 12 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
    |* 13 |  FILTER                            |                         |       |       |            |          |
    |* 14 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 |  3524 |     2   (0)| 00:00:01 |
    |* 15 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
    |* 16 |  FILTER                            |                         |       |       |            |          |
    |* 17 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 |  3524 |     2   (0)| 00:00:01 |
    |* 18 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
    |* 19 |  FILTER                            |                         |       |       |            |          |
    |* 20 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 |  3524 |     2   (0)| 00:00:01 |
    |* 21 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
    |* 22 |  FILTER                            |                         |       |       |            |          |
    |* 23 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 |  3524 |     2   (0)| 00:00:01 |
    |* 24 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
    |* 25 |  FILTER                            |                         |       |       |            |          |
    |* 26 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 |  3524 |     2   (0)| 00:00:01 |
    |* 27 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
    |* 28 |  FILTER                            |                         |       |       |            |          |
    |* 29 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 |  3524 |     2   (0)| 00:00:01 |
    |* 30 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
    |* 31 |  FILTER                            |                         |       |       |            |          |
    |* 32 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 |  3524 |     2   (0)| 00:00:01 |
    |* 33 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
    |* 34 |  FILTER                            |                         |       |       |            |          |
    |* 35 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 |  3524 |     2   (0)| 00:00:01 |
    |* 36 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
    |* 37 |  FILTER                            |                         |       |       |            |          |
    |* 38 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 |  3524 |     2   (0)| 00:00:01 |
    |* 39 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
    |* 40 |  FILTER                            |                         |       |       |            |          |
    |* 41 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 |  3524 |     2   (0)| 00:00:01 |
    |* 42 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
    |* 43 |  FILTER                            |                         |       |       |            |          |
    |* 44 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 |  3524 |     2   (0)| 00:00:01 |
    |* 45 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
    |* 46 |  FILTER                            |                         |       |       |            |          |
    |* 47 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 |  3524 |     2   (0)| 00:00:01 |
    |* 48 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
    |* 49 |  FILTER                            |                         |       |       |            |          |
    |* 50 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 |  3524 |     2   (0)| 00:00:01 |
    |* 51 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
    |  52 |  NESTED LOOPS                      |                         |     1 | 10666 |     9   (0)| 00:00:01 |
    |  53 |   NESTED LOOPS                     |                         |     1 | 10654 |     8   (0)| 00:00:01 |
    |  54 |    NESTED LOOPS                    |                         |     1 |  9132 |     7   (0)| 00:00:01 |
    |  55 |     NESTED LOOPS                   |                         |     1 |  7610 |     6   (0)| 00:00:01 |
    |  56 |      NESTED LOOPS                  |                         |     1 |  6088 |     5   (0)| 00:00:01 |
    |  57 |       NESTED LOOPS                 |                         |     1 |  4566 |     4   (0)| 00:00:01 |
    |  58 |        NESTED LOOPS                |                         |     1 |  3044 |     3   (0)| 00:00:01 |
    |* 59 |         TABLE ACCESS BY INDEX ROWID| XML_DROPBOX_PATH_IDX    |     1 |  1522 |     2   (0)| 00:00:01 |
    |* 60 |          INDEX RANGE SCAN          | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
    |* 61 |         TABLE ACCESS BY INDEX ROWID| XML_DROPBOX_PATH_IDX    |     1 |  1522 |     1   (0)| 00:00:01 |
    |* 62 |          INDEX RANGE SCAN          | XML_DROPBOX_PATH_ID_IDX |     1 |       |     0   (0)| 00:00:01 |
    |* 63 |        TABLE ACCESS BY INDEX ROWID | XML_DROPBOX_PATH_IDX    |     1 |  1522 |     1   (0)| 00:00:01 |
    |* 64 |         INDEX RANGE SCAN           | XML_DROPBOX_PATH_ID_IDX |     1 |       |     0   (0)| 00:00:01 |
    |* 65 |       TABLE ACCESS BY INDEX ROWID  | XML_DROPBOX_PATH_IDX    |     1 |  1522 |     1   (0)| 00:00:01 |
    |* 66 |        INDEX RANGE SCAN            | XML_DROPBOX_PATH_ID_IDX |     1 |       |     0   (0)| 00:00:01 |
    |* 67 |      TABLE ACCESS BY INDEX ROWID   | XML_DROPBOX_PATH_IDX    |     1 |  1522 |     1   (0)| 00:00:01 |
    |* 68 |       INDEX RANGE SCAN             | XML_DROPBOX_PATH_ID_IDX |     1 |       |     0   (0)| 00:00:01 |
    |* 69 |     TABLE ACCESS BY INDEX ROWID    | XML_DROPBOX_PATH_IDX    |     1 |  1522 |     1   (0)| 00:00:01 |
    |* 70 |      INDEX RANGE SCAN              | XML_DROPBOX_PATH_ID_IDX |     1 |       |     0   (0)| 00:00:01 |
    |* 71 |    TABLE ACCESS BY INDEX ROWID     | XML_DROPBOX_PATH_IDX    |     1 |  1522 |     1   (0)| 00:00:01 |
    |* 72 |     INDEX RANGE SCAN               | XML_DROPBOX_PATH_ID_IDX |     1 |       |     0   (0)| 00:00:01 |
    |  73 |   TABLE ACCESS BY USER ROWID       | XML_DROPBOX             |     1 |    12 |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
       2 - filter("SYS_P6"."ORDER_KEY">:B1 AND "SYS_P6"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
                  SYS_ORDERKEY_DEPTH("SYS_P6"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
                  SYS_XMLI_LOC_ISNODE("SYS_P6"."LOCATOR")=1)
       3 - access("SYS_P6"."PATHID"=HEXTORAW('6043')  AND "SYS_P6"."RID"=:B1)
       4 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
       5 - filter("SYS_P9"."ORDER_KEY">:B1 AND "SYS_P9"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
                  SYS_ORDERKEY_DEPTH("SYS_P9"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
                  SYS_XMLI_LOC_ISNODE("SYS_P9"."LOCATOR")=1)
       6 - access("SYS_P9"."PATHID"=HEXTORAW('66A6')  AND "SYS_P9"."RID"=:B1)
       7 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
       8 - filter("SYS_P12"."ORDER_KEY">:B1 AND "SYS_P12"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
                  SYS_ORDERKEY_DEPTH("SYS_P12"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
                  SYS_XMLI_LOC_ISNODE("SYS_P12"."LOCATOR")=1)
       9 - access("SYS_P12"."PATHID"=HEXTORAW('4203')  AND "SYS_P12"."RID"=:B1)
      10 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
      11 - filter("SYS_P15"."ORDER_KEY">:B1 AND "SYS_P15"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
                  SYS_ORDERKEY_DEPTH("SYS_P15"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
                  SYS_XMLI_LOC_ISNODE("SYS_P15"."LOCATOR")=1)
      12 - access("SYS_P15"."PATHID"=HEXTORAW('66BA')  AND "SYS_P15"."RID"=:B1)
      13 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
      14 - filter("SYS_P18"."ORDER_KEY">:B1 AND "SYS_P18"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
                  SYS_ORDERKEY_DEPTH("SYS_P18"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
                  SYS_XMLI_LOC_ISNODE("SYS_P18"."LOCATOR")=1)
      15 - access("SYS_P18"."PATHID"=HEXTORAW('550B')  AND "SYS_P18"."RID"=:B1)
      16 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
      17 - filter("SYS_P21"."ORDER_KEY">:B1 AND "SYS_P21"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
                  SYS_ORDERKEY_DEPTH("SYS_P21"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
                  SYS_XMLI_LOC_ISNODE("SYS_P21"."LOCATOR")=1)
      18 - access("SYS_P21"."PATHID"=HEXTORAW('652E')  AND "SYS_P21"."RID"=:B1)
      19 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
      20 - filter("SYS_P24"."ORDER_KEY">:B1 AND "SYS_P24"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
                  SYS_ORDERKEY_DEPTH("SYS_P24"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
                  SYS_XMLI_LOC_ISNODE("SYS_P24"."LOCATOR")=1)
      21 - access("SYS_P24"."PATHID"=HEXTORAW('44EC')  AND "SYS_P24"."RID"=:B1)
      22 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
      23 - filter("SYS_P31"."ORDER_KEY">:B1 AND "SYS_P31"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
                  SYS_ORDERKEY_DEPTH("SYS_P31"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
                  SYS_XMLI_LOC_ISNODE("SYS_P31"."LOCATOR")=1)
      24 - access("SYS_P31"."PATHID"=HEXTORAW('2C38')  AND "SYS_P31"."RID"=:B1)
      25 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
      26 - filter("SYS_P34"."ORDER_KEY">:B1 AND "SYS_P34"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
                  SYS_ORDERKEY_DEPTH("SYS_P34"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
                  SYS_XMLI_LOC_ISNODE("SYS_P34"."LOCATOR")=1)
      27 - access("SYS_P34"."PATHID"=HEXTORAW('3026')  AND "SYS_P34"."RID"=:B1)
      28 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
      29 - filter("SYS_P37"."ORDER_KEY">:B1 AND "SYS_P37"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
                  SYS_ORDERKEY_DEPTH("SYS_P37"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+2 AND
                  SYS_XMLI_LOC_ISNODE("SYS_P37"."LOCATOR")=1)
      30 - access("SYS_P37"."PATHID"=HEXTORAW('4F1A')  AND "SYS_P37"."RID"=:B1)
      31 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
      32 - filter("SYS_P40"."ORDER_KEY">:B1 AND "SYS_P40"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
                  SYS_ORDERKEY_DEPTH("SYS_P40"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+2 AND
                  SYS_XMLI_LOC_ISNODE("SYS_P40"."LOCATOR")=1)
      33 - access("SYS_P40"."PATHID"=HEXTORAW('7E65')  AND "SYS_P40"."RID"=:B1)
      34 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
      35 - filter("SYS_P43"."ORDER_KEY">:B1 AND "SYS_P43"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
                  SYS_ORDERKEY_DEPTH("SYS_P43"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
                  SYS_XMLI_LOC_ISNODE("SYS_P43"."LOCATOR")=1)
      36 - access("SYS_P43"."PATHID"=HEXTORAW('7497')  AND "SYS_P43"."RID"=:B1)
      37 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
      38 - filter("SYS_P46"."ORDER_KEY">:B1 AND "SYS_P46"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
                  SYS_ORDERKEY_DEPTH("SYS_P46"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
                  SYS_XMLI_LOC_ISNODE("SYS_P46"."LOCATOR")=1)
      39 - access("SYS_P46"."PATHID"=HEXTORAW('2D8D')  AND "SYS_P46"."RID"=:B1)
      40 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
      41 - filter("SYS_P49"."ORDER_KEY">:B1 AND "SYS_P49"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
                  SYS_ORDERKEY_DEPTH("SYS_P49"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
                  SYS_XMLI_LOC_ISNODE("SYS_P49"."LOCATOR")=1)
      42 - access("SYS_P49"."PATHID"=HEXTORAW('4486')  AND "SYS_P49"."RID"=:B1)
      43 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
      44 - filter("SYS_P66"."ORDER_KEY">:B1 AND "SYS_P66"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
                  SYS_ORDERKEY_DEPTH("SYS_P66"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
                  SYS_XMLI_LOC_ISNODE("SYS_P66"."LOCATOR")=1)
      45 - access("SYS_P66"."PATHID"=HEXTORAW('5005')  AND "SYS_P66"."RID"=:B1)
      46 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
      47 - filter("SYS_P69"."ORDER_KEY">:B1 AND "SYS_P69"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
                  SYS_ORDERKEY_DEPTH("SYS_P69"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
                  SYS_XMLI_LOC_ISNODE("SYS_P69"."LOCATOR")=1)
      48 - access("SYS_P69"."PATHID"=HEXTORAW('3935')  AND "SYS_P69"."RID"=:B1)
      49 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
      50 - filter("SYS_P59"."ORDER_KEY">:B1 AND "SYS_P59"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
                  SYS_ORDERKEY_DEPTH("SYS_P59"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
                  SYS_XMLI_LOC_ISNODE("SYS_P59"."LOCATOR")=1)
      51 - access("SYS_P59"."PATHID"=HEXTORAW('37CE')  AND "SYS_P59"."RID"=:B1)
      59 - filter(SYS_XMLI_LOC_ISNODE("SYS_P49"."LOCATOR")=1)
      60 - access("SYS_P49"."PATHID"=HEXTORAW('4486') )
      61 - filter(SYS_XMLI_LOC_ISNODE("SYS_P62"."LOCATOR")=1 AND
                  "SYS_P49"."ORDER_KEY"<"SYS_P62"."ORDER_KEY" AND "SYS_P62"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD("SYS_P49".
                  "ORDER_KEY") AND SYS_ORDERKEY_DEPTH("SYS_P49"."ORDER_KEY")+1=SYS_ORDERKEY_DEPTH("SYS_P62"."ORDER_KEY")
      62 - access("SYS_P62"."PATHID"=HEXTORAW('780B')  AND "SYS_P62"."RID"="SYS_P49"."RID")
      63 - filter(SYS_XMLI_LOC_ISNODE("SYS_P27"."LOCATOR")=1 AND
                  "SYS_P27"."ORDER_KEY"<"SYS_P49"."ORDER_KEY" AND "SYS_P49"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD("SYS_P27".
                  "ORDER_KEY") AND SYS_ORDERKEY_DEPTH("SYS_P27"."ORDER_KEY")+1=SYS_ORDERKEY_DEPTH("SYS_P49"."ORDER_KEY")
      64 - access("SYS_P27"."PATHID"=HEXTORAW('49C4')  AND "SYS_P49"."RID"="SYS_P27"."RID")
      65 - filter(SYS_XMLI_LOC_ISNODE("SYS_P46"."LOCATOR")=1 AND
                  "SYS_P27"."ORDER_KEY"<"SYS_P46"."ORDER_KEY" AND "SYS_P46"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD("SYS_P27".
                  "ORDER_KEY") AND SYS_ORDERKEY_DEPTH("SYS_P27"."ORDER_KEY")+1=SYS_ORDERKEY_DEPTH("SYS_P46"."ORDER_KEY")
      66 - access("SYS_P46"."PATHID"=HEXTORAW('2D8D')  AND "SYS_P46"."RID"="SYS_P27"."RID")
      67 - filter(SYS_XMLI_LOC_ISNODE("SYS_P52"."LOCATOR")=1 AND
                  "SYS_P46"."ORDER_KEY"<"SYS_P52"."ORDER_KEY" AND "SYS_P52"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD("SYS_P46".
                  "ORDER_KEY") AND SYS_ORDERKEY_DEPTH("SYS_P46"."ORDER_KEY")+1=SYS_ORDERKEY_DEPTH("SYS_P52"."ORDER_KEY")
      68 - access("SYS_P52"."PATHID"=HEXTORAW('6AFA')  AND "SYS_P52"."RID"="SYS_P46"."RID")
      69 - filter(SYS_XMLI_LOC_ISNODE("SYS_P24"."LOCATOR")=1 AND
                  "SYS_P24"."ORDER_KEY"<"SYS_P27"."ORDER_KEY" AND "SYS_P27"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD("SYS_P24".
                  "ORDER_KEY") AND SYS_ORDERKEY_DEPTH("SYS_P24"."ORDER_KEY")+1=SYS_ORDERKEY_DEPTH("SYS_P27"."ORDER_KEY")
      70 - access("SYS_P24"."PATHID"=HEXTORAW('44EC')  AND "SYS_P27"."RID"="SYS_P24"."RID")
      71 - filter(SYS_XMLI_LOC_ISNODE("SYS_P4"."LOCATOR")=1 AND
                  "SYS_P4"."ORDER_KEY"<"SYS_P24"."ORDER_KEY" AND "SYS_P24"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD("SYS_P4"."O
                  RDER_KEY") AND SYS_ORDERKEY_DEPTH("SYS_P4"."ORDER_KEY")+1=SYS_ORDERKEY_DEPTH("SYS_P24"."ORDER_KEY"))
      72 - access("SYS_P4"."PATHID"=HEXTORAW('5B3D')  AND "SYS_P24"."RID"="SYS_P4"."RID")
    Note
       - dynamic sampling used for this statement (level=2)

  • Explain Plan in Pl/SQL developer tool

    How to get the explain plan result of a query in PL/SQL developer tool which has a database link ?
    Also, please suggest the min and max Cost, Cardinality and byte values
    Thanks

    859486 wrote:
    How to get the explain plan result of a query in PL/SQL developer tool which has a database link ?PL/SQL Developer is a tool written by allround automations.
    I suggest you ask how to use that tool vie the support option on their own website/forums:
    http://www.allroundautomations.com/plsqldev.html
    Also, please suggest the min and max Cost, Cardinality and byte valuesmin cost would be 0
    max cost could be anything
    cardinality is http://en.wikipedia.org/wiki/Cardinality_%28SQL_statements%29
    bytes are the number of estimated bytes involved in the data retrieved/processed.

  • Explain plan result for a long-running query used in data-warehousing. Tuni

    I have executed an explain plan for a query that is used in a data-warehousing application.
    This sql is taking too long to execute as it is visiting 24 partitions.
    Where each partition contains data for 1 month month, so it fetches last 2 year data.
    And each partition has a million or so rows.
    All this is kept in table prescrip_retail. So this table has 24 partitions.
    abc@def>explain plan set statement_id='dwh_query'
    2 for
    3 SELECT r.pier_account_id,
    4 p.presc_num,
    5 spm.product_id,
    6 p.month,
    7 t.best_call_state,
    8 sum(p.trx_count)
    9 FROM rlup_assigned_account r,
    10 temp_presc_num_TEST t,
    11 retail.prescrip_retail p,
    12 sherlock.sherlock_product_mapping spm
    13 WHERE spm.product_id like '056%'
    14 and t.CLIENT_ID='934759'
    15 and p.month >= add_months(sysdate,-24)
    16 and spm.mds6 = p.product_id
    17 and t.CLIENT_ID = p.presc_num
    18 and r.ndc_pyr_id = p.payer_plan
    19 and t.best_call_state = r.ST
    20 GROUP BY r.pier_account_id,
    21 p.presc_num,
    22 spm.product_id,
    23 p.month,
    24 t.best_call_state;
    Explained.
    abc@def>ed
    Wrote file afiedt.buf
    1 select operation,options,optimizer,cost,cardinality,partition_start,partition_stop
    2 from plan_table
    3* where statement_id='dwh_query'
    abc@def>/
    OPERATION OPTIONS OPTIMIZER COST CARDINALITY
    PARTITION_START
    PARTITION_STOP
    SELECT STATEMENT CHOOSE 850 1
    SORT GROUP BY 850 1
    NESTED LOOPS 848 1
    HASH JOIN 845 3
    HASH JOIN 842 6
    TABLE ACCESS FULL ANALYZED 1 6
    PARTITION RANGE ITERATOR
    KEY
    36
    TABLE ACCESS BY LOCAL INDEX ROWID ANALYZED 839 166
    KEY
    36
    BITMAP CONVERSION TO ROWIDS
    BITMAP INDEX SINGLE VALUE
    KEY
    36
    TABLE ACCESS FULL 2 50
    TABLE ACCESS BY INDEX ROWID ANALYZED 1 149501
    INDEX UNIQUE SCAN ANALYZED 149501
    13 rows selected.

    Here is the create statement for PRESCRIP_RETAIL table:
    I have observed 2 things:
    1. In the query the following joins are present.
    13 WHERE spm.product_id like '056%'
    14 and t.CLIENT_ID='934759'
    15 and p.month >= add_months(sysdate,-24)
    16 and spm.mds6 = p.product_id
    17 and t.CLIENT_ID = p.presc_num
    18 and r.ndc_pyr_id = p.payer_plan
    19 and t.best_call_state = r.ST
    Index exist for p.product_id,p.presc_num,p.payer_plan as you can see below.
    However, the index does not exist for month.
    I am also doing search for month.
    I feel if I create a "partitioned index" on month, query performance should improve.
    Q Can you provide me the syntax for creating a partitioned index on month?
    2.The following tables are used in the query:
    9 FROM rlup_assigned_account r,
    10 temp_presc_num_TEST t,
    11 retail.prescrip_retail p,
    12 sherlock.sherlock_product_mapping spm
    In these tables, apart from sherlock.sherlock_product_mapping table the statistics that exist is old.
    I need to analyse on table level as well as column level.
    For example:
    Table prescrip_retail is analyzed in 2002,
    table temp_presc_num_TEST is not analysed at all.
    table rlup_assigned_account is analysed in Feb 2007.
    sherlock_product_mapping is the only table that has updated statistics, analysed on Oct. 2007
    Here is the table creation statement of PRESCRIP_RETAIL and index on it.
    Prompt Table PRESCRIP_RETAIL;
    -- PRESCRIP_RETAIL (Table)
    -- Row count:2806673860
    CREATE TABLE RETAIL.PRESCRIP_RETAIL
    PRESC_NUM NUMBER,
    PIER_NUM CHAR(8),
    RELID CHAR(9) NOT NULL,
    ME_NUM CHAR(10) NOT NULL,
    PRODUCT_ID CHAR(6) NOT NULL,
    PRODUCT_FRMSTR CHAR(1) NOT NULL,
    PAYER_PLAN CHAR(6) NOT NULL,
    MONTH DATE NOT NULL,
    PYMT_CODE CHAR(1) NOT NULL,
    NRX_COUNT NUMBER(7) NOT NULL,
    NRX_QUANTITY NUMBER(9) NOT NULL,
    NRX_DOLLARS NUMBER(13,2) NOT NULL,
    TRX_COUNT NUMBER(7) NOT NULL,
    TRX_QUANTITY NUMBER(9) NOT NULL,
    TRX_DOLLARS NUMBER(13,2) NOT NULL
    TABLESPACE PRESC_PARTITION_29
    NOLOGGING
    PARTITION BY RANGE (MONTH)
    PARTITION PRESC200406 VALUES LESS THAN (TO_DATE(' 2004-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_30,
    PARTITION PRESC200407 VALUES LESS THAN (TO_DATE(' 2004-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_31,
    PARTITION PRESC200408 VALUES LESS THAN (TO_DATE(' 2004-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_32,
    PARTITION PRESC200409 VALUES LESS THAN (TO_DATE(' 2004-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_33,
    PARTITION PRESC200410 VALUES LESS THAN (TO_DATE(' 2004-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_34,
    PARTITION PRESC200411 VALUES LESS THAN (TO_DATE(' 2004-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_35,
    PARTITION PRESC200412 VALUES LESS THAN (TO_DATE(' 2005-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_36,
    PARTITION PRESC200501 VALUES LESS THAN (TO_DATE(' 2005-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_01,
    PARTITION PRESC200502 VALUES LESS THAN (TO_DATE(' 2005-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_02,
    PARTITION PRESC200503 VALUES LESS THAN (TO_DATE(' 2005-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_03,
    PARTITION PRESC200504 VALUES LESS THAN (TO_DATE(' 2005-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_04,
    PARTITION PRESC200505 VALUES LESS THAN (TO_DATE(' 2005-06-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_05,
    PARTITION PRESC200506 VALUES LESS THAN (TO_DATE(' 2005-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_06,
    PARTITION PRESC200507 VALUES LESS THAN (TO_DATE(' 2005-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_07,
    PARTITION PRESC200508 VALUES LESS THAN (TO_DATE(' 2005-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_08,
    PARTITION PRESC200509 VALUES LESS THAN (TO_DATE(' 2005-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_09,
    PARTITION PRESC200510 VALUES LESS THAN (TO_DATE(' 2005-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_10,
    PARTITION PRESC200511 VALUES LESS THAN (TO_DATE(' 2005-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_11,
    PARTITION PRESC200512 VALUES LESS THAN (TO_DATE(' 2006-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_12,
    PARTITION PRESC200601 VALUES LESS THAN (TO_DATE(' 2006-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_13,
    PARTITION PRESC200602 VALUES LESS THAN (TO_DATE(' 2006-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_14,
    PARTITION PRESC200603 VALUES LESS THAN (TO_DATE(' 2006-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_15,
    PARTITION PRESC200604 VALUES LESS THAN (TO_DATE(' 2006-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_16,
    PARTITION PRESC200605 VALUES LESS THAN (TO_DATE(' 2006-06-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_17,
    PARTITION PRESC200606 VALUES LESS THAN (TO_DATE(' 2006-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_18,
    PARTITION PRESC200607 VALUES LESS THAN (TO_DATE(' 2006-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_19,
    PARTITION PRESC200608 VALUES LESS THAN (TO_DATE(' 2006-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_20,
    PARTITION PRESC200609 VALUES LESS THAN (TO_DATE(' 2006-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_21,
    PARTITION PRESC200610 VALUES LESS THAN (TO_DATE(' 2006-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_22,
    PARTITION PRESC200611 VALUES LESS THAN (TO_DATE(' 2006-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_23,
    PARTITION PRESC200612 VALUES LESS THAN (TO_DATE(' 2007-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_24,
    PARTITION PRESC200701 VALUES LESS THAN (TO_DATE(' 2007-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_25,
    PARTITION PRESC200702 VALUES LESS THAN (TO_DATE(' 2007-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_26,
    PARTITION PRESC200703 VALUES LESS THAN (TO_DATE(' 2007-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_27,
    PARTITION PRESC200704 VALUES LESS THAN (TO_DATE(' 2007-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_28,
    PARTITION PRESC200705 VALUES LESS THAN (TO_DATE(' 2007-06-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    TABLESPACE PRESC_PARTITION_29
    NOCACHE
    NOPARALLEL;
    Prompt Index BX2_PRESC_PAYER;
    -- BX2_PRESC_PAYER (Index)
    -- Dependencies:
    -- PRESCRIP_RETAIL (Table)
    CREATE BITMAP INDEX RETAIL.BX2_PRESC_PAYER ON RETAIL.PRESCRIP_RETAIL
    (PAYER_PLAN)
    TABLESPACE PRESC_PARTITION_29
    LOGGING
    LOCAL (
    PARTITION PRESC200406
    NOLOGGING
    TABLESPACE PRESC_PARTITION_30,
    PARTITION PRESC200407
    NOLOGGING
    TABLESPACE PRESC_PARTITION_31,
    PARTITION PRESC200408
    NOLOGGING
    TABLESPACE PRESC_PARTITION_32,
    PARTITION PRESC200409
    NOLOGGING
    TABLESPACE PRESC_PARTITION_33,
    PARTITION PRESC200410
    NOLOGGING
    TABLESPACE PRESC_PARTITION_34,
    PARTITION PRESC200411
    NOLOGGING
    TABLESPACE PRESC_PARTITION_35,
    PARTITION PRESC200412
    NOLOGGING
    TABLESPACE PRESC_PARTITION_36,
    PARTITION PRESC200501
    NOLOGGING
    TABLESPACE PRESC_PARTITION_01,
    PARTITION PRESC200502
    NOLOGGING
    TABLESPACE PRESC_PARTITION_02,
    PARTITION PRESC200503
    NOLOGGING
    TABLESPACE PRESC_PARTITION_03,
    PARTITION PRESC200504
    NOLOGGING
    TABLESPACE PRESC_PARTITION_04,
    PARTITION PRESC200505
    NOLOGGING
    TABLESPACE PRESC_PARTITION_05,
    PARTITION PRESC200506
    NOLOGGING
    TABLESPACE PRESC_PARTITION_06,
    PARTITION PRESC200507
    NOLOGGING
    TABLESPACE PRESC_PARTITION_07,
    PARTITION PRESC200508
    NOLOGGING
    TABLESPACE PRESC_PARTITION_08,
    PARTITION PRESC200509
    NOLOGGING
    TABLESPACE PRESC_PARTITION_09,
    PARTITION PRESC200510
    NOLOGGING
    TABLESPACE PRESC_PARTITION_10,
    PARTITION PRESC200511
    NOLOGGING
    TABLESPACE PRESC_PARTITION_11,
    PARTITION PRESC200512
    NOLOGGING
    TABLESPACE PRESC_PARTITION_12,
    PARTITION PRESC200601
    NOLOGGING
    TABLESPACE PRESC_PARTITION_13,
    PARTITION PRESC200602
    NOLOGGING
    TABLESPACE PRESC_PARTITION_14,
    PARTITION PRESC200603
    NOLOGGING
    TABLESPACE PRESC_PARTITION_15,
    PARTITION PRESC200604
    NOLOGGING
    TABLESPACE PRESC_PARTITION_16,
    PARTITION PRESC200605
    NOLOGGING
    TABLESPACE PRESC_PARTITION_17,
    PARTITION PRESC200606
    NOLOGGING
    TABLESPACE PRESC_PARTITION_18,
    PARTITION PRESC200607
    NOLOGGING
    TABLESPACE PRESC_PARTITION_19,
    PARTITION PRESC200608
    NOLOGGING
    TABLESPACE PRESC_PARTITION_20,
    PARTITION PRESC200609
    NOLOGGING
    TABLESPACE PRESC_PARTITION_21,
    PARTITION PRESC200610
    NOLOGGING
    TABLESPACE PRESC_PARTITION_22,
    PARTITION PRESC200611
    NOLOGGING
    TABLESPACE PRESC_PARTITION_23,
    PARTITION PRESC200612
    NOLOGGING
    TABLESPACE PRESC_PARTITION_24,
    PARTITION PRESC200701
    NOLOGGING
    TABLESPACE PRESC_PARTITION_25,
    PARTITION PRESC200702
    NOLOGGING
    TABLESPACE PRESC_PARTITION_26,
    PARTITION PRESC200703
    NOLOGGING
    TABLESPACE PRESC_PARTITION_27,
    PARTITION PRESC200704
    NOLOGGING
    TABLESPACE PRESC_PARTITION_28,
    PARTITION PRESC200705
    NOLOGGING
    TABLESPACE PRESC_PARTITION_29
    NOPARALLEL;
    Prompt Index BX3_PRESC_PAYERCD;
    -- BX3_PRESC_PAYERCD (Index)
    -- Dependencies:
    -- PRESCRIP_RETAIL (Table)
    CREATE BITMAP INDEX RETAIL.BX3_PRESC_PAYERCD ON RETAIL.PRESCRIP_RETAIL
    (PYMT_CODE)
    TABLESPACE PRESC_PARTITION_29
    NOLOGGING
    LOCAL (
    PARTITION PRESC200406
    NOLOGGING
    TABLESPACE PRESC_PARTITION_30,
    PARTITION PRESC200407
    NOLOGGING
    TABLESPACE PRESC_PARTITION_31,
    PARTITION PRESC200408
    NOLOGGING
    TABLESPACE PRESC_PARTITION_32,
    PARTITION PRESC200409
    NOLOGGING
    TABLESPACE PRESC_PARTITION_33,
    PARTITION PRESC200410
    NOLOGGING
    TABLESPACE PRESC_PARTITION_34,
    PARTITION PRESC200411
    NOLOGGING
    TABLESPACE PRESC_PARTITION_35,
    PARTITION PRESC200412
    NOLOGGING
    TABLESPACE PRESC_PARTITION_36,
    PARTITION PRESC200501
    NOLOGGING
    TABLESPACE PRESC_PARTITION_01,
    PARTITION PRESC200502
    NOLOGGING
    TABLESPACE PRESC_PARTITION_02,
    PARTITION PRESC200503
    NOLOGGING
    TABLESPACE PRESC_PARTITION_03,
    PARTITION PRESC200504
    NOLOGGING
    TABLESPACE PRESC_PARTITION_04,
    PARTITION PRESC200505
    NOLOGGING
    TABLESPACE PRESC_PARTITION_05,
    PARTITION PRESC200506
    NOLOGGING
    TABLESPACE PRESC_PARTITION_06,
    PARTITION PRESC200507
    NOLOGGING
    TABLESPACE PRESC_PARTITION_07,
    PARTITION PRESC200508
    NOLOGGING
    TABLESPACE PRESC_PARTITION_08,
    PARTITION PRESC200509
    NOLOGGING
    TABLESPACE PRESC_PARTITION_09,
    PARTITION PRESC200510
    NOLOGGING
    TABLESPACE PRESC_PARTITION_10,
    PARTITION PRESC200511
    NOLOGGING
    TABLESPACE PRESC_PARTITION_11,
    PARTITION PRESC200512
    NOLOGGING
    TABLESPACE PRESC_PARTITION_12,
    PARTITION PRESC200601
    NOLOGGING
    TABLESPACE PRESC_PARTITION_13,
    PARTITION PRESC200602
    NOLOGGING
    TABLESPACE PRESC_PARTITION_14,
    PARTITION PRESC200603
    NOLOGGING
    TABLESPACE PRESC_PARTITION_15,
    PARTITION PRESC200604
    NOLOGGING
    TABLESPACE PRESC_PARTITION_16,
    PARTITION PRESC200605
    NOLOGGING
    TABLESPACE PRESC_PARTITION_17,
    PARTITION PRESC200606
    NOLOGGING
    TABLESPACE PRESC_PARTITION_18,
    PARTITION PRESC200607
    NOLOGGING
    TABLESPACE PRESC_PARTITION_19,
    PARTITION PRESC200608
    NOLOGGING
    TABLESPACE PRESC_PARTITION_20,
    PARTITION PRESC200609
    NOLOGGING
    TABLESPACE PRESC_PARTITION_21,
    PARTITION PRESC200610
    NOLOGGING
    TABLESPACE PRESC_PARTITION_22,
    PARTITION PRESC200611
    NOLOGGING
    TABLESPACE PRESC_PARTITION_23,
    PARTITION PRESC200612
    NOLOGGING
    TABLESPACE PRESC_PARTITION_24,
    PARTITION PRESC200701
    NOLOGGING
    TABLESPACE PRESC_PARTITION_25,
    PARTITION PRESC200702
    NOLOGGING
    TABLESPACE PRESC_PARTITION_26,
    PARTITION PRESC200703
    NOLOGGING
    TABLESPACE PRESC_PARTITION_27,
    PARTITION PRESC200704
    NOLOGGING
    TABLESPACE PRESC_PARTITION_28,
    PARTITION PRESC200705
    NOLOGGING
    TABLESPACE PRESC_PARTITION_29
    NOPARALLEL;
    Prompt Index BX4_PRESC_PRESC;
    -- BX4_PRESC_PRESC (Index)
    -- Dependencies:
    -- PRESCRIP_RETAIL (Table)
    CREATE BITMAP INDEX RETAIL.BX4_PRESC_PRESC ON RETAIL.PRESCRIP_RETAIL
    (PRESC_NUM)
    TABLESPACE PRESC_PARTITION_29
    NOLOGGING
    LOCAL (
    PARTITION PRESC200406
    NOLOGGING
    TABLESPACE PRESC_PARTITION_30,
    PARTITION PRESC200407
    NOLOGGING
    TABLESPACE PRESC_PARTITION_31,
    PARTITION PRESC200408
    NOLOGGING
    TABLESPACE PRESC_PARTITION_32,
    PARTITION PRESC200409
    NOLOGGING
    TABLESPACE PRESC_PARTITION_33,
    PARTITION PRESC200410
    NOLOGGING
    TABLESPACE PRESC_PARTITION_34,
    PARTITION PRESC200411
    NOLOGGING
    TABLESPACE PRESC_PARTITION_35,
    PARTITION PRESC200412
    NOLOGGING
    TABLESPACE PRESC_PARTITION_36,
    PARTITION PRESC200501
    NOLOGGING
    TABLESPACE PRESC_PARTITION_01,
    PARTITION PRESC200502
    NOLOGGING
    TABLESPACE PRESC_PARTITION_02,
    PARTITION PRESC200503
    NOLOGGING
    TABLESPACE PRESC_PARTITION_03,
    PARTITION PRESC200504
    NOLOGGING
    TABLESPACE PRESC_PARTITION_04,
    PARTITION PRESC200505
    NOLOGGING
    TABLESPACE PRESC_PARTITION_05,
    PARTITION PRESC200506
    NOLOGGING
    TABLESPACE PRESC_PARTITION_06,
    PARTITION PRESC200507
    NOLOGGING
    TABLESPACE PRESC_PARTITION_07,
    PARTITION PRESC200508
    NOLOGGING
    TABLESPACE PRESC_PARTITION_08,
    PARTITION PRESC200509
    NOLOGGING
    TABLESPACE PRESC_PARTITION_09,
    PARTITION PRESC200510
    NOLOGGING
    TABLESPACE PRESC_PARTITION_10,
    PARTITION PRESC200511
    NOLOGGING
    TABLESPACE PRESC_PARTITION_11,
    PARTITION PRESC200512
    NOLOGGING
    TABLESPACE PRESC_PARTITION_12,
    PARTITION PRESC200601
    NOLOGGING
    TABLESPACE PRESC_PARTITION_13,
    PARTITION PRESC200602
    NOLOGGING
    TABLESPACE PRESC_PARTITION_14,
    PARTITION PRESC200603
    NOLOGGING
    TABLESPACE PRESC_PARTITION_15,
    PARTITION PRESC200604
    NOLOGGING
    TABLESPACE PRESC_PARTITION_16,
    PARTITION PRESC200605
    NOLOGGING
    TABLESPACE PRESC_PARTITION_17,
    PARTITION PRESC200606
    NOLOGGING
    TABLESPACE PRESC_PARTITION_18,
    PARTITION PRESC200607
    NOLOGGING
    TABLESPACE PRESC_PARTITION_19,
    PARTITION PRESC200608
    NOLOGGING
    TABLESPACE PRESC_PARTITION_20,
    PARTITION PRESC200609
    NOLOGGING
    TABLESPACE PRESC_PARTITION_21,
    PARTITION PRESC200610
    NOLOGGING
    TABLESPACE PRESC_PARTITION_22,
    PARTITION PRESC200611
    NOLOGGING
    TABLESPACE PRESC_PARTITION_23,
    PARTITION PRESC200612
    NOLOGGING
    TABLESPACE PRESC_PARTITION_24,
    PARTITION PRESC200701
    NOLOGGING
    TABLESPACE PRESC_PARTITION_25,
    PARTITION PRESC200702
    NOLOGGING
    TABLESPACE PRESC_PARTITION_26,
    PARTITION PRESC200703
    NOLOGGING
    TABLESPACE PRESC_PARTITION_27,
    PARTITION PRESC200704
    NOLOGGING
    TABLESPACE PRESC_PARTITION_28,
    PARTITION PRESC200705
    NOLOGGING
    TABLESPACE PRESC_PARTITION_29
    NOPARALLEL;
    Prompt Index BX5_PRESC_PIER;
    -- BX5_PRESC_PIER (Index)
    -- Dependencies:
    -- PRESCRIP_RETAIL (Table)
    CREATE BITMAP INDEX RETAIL.BX5_PRESC_PIER ON RETAIL.PRESCRIP_RETAIL
    (PIZR_NUM)
    TABLESPACE PRESC_PARTITION_29
    LOGGING
    LOCAL (
    PARTITION PRESC200406
    NOLOGGING
    TABLESPACE PRESC_PARTITION_30,
    PARTITION PRESC200407
    NOLOGGING
    TABLESPACE PRESC_PARTITION_31,
    PARTITION PRESC200408
    NOLOGGING
    TABLESPACE PRESC_PARTITION_32,
    PARTITION PRESC200409
    NOLOGGING
    TABLESPACE PRESC_PARTITION_33,
    PARTITION PRESC200410
    NOLOGGING
    TABLESPACE PRESC_PARTITION_34,
    PARTITION PRESC200411
    NOLOGGING
    TABLESPACE PRESC_PARTITION_35,
    PARTITION PRESC200412
    NOLOGGING
    TABLESPACE PRESC_PARTITION_36,
    PARTITION PRESC200501
    NOLOGGING
    TABLESPACE PRESC_PARTITION_01,
    PARTITION PRESC200502
    NOLOGGING
    TABLESPACE PRESC_PARTITION_02,
    PARTITION PRESC200503
    NOLOGGING
    TABLESPACE PRESC_PARTITION_03,
    PARTITION PRESC200504
    NOLOGGING
    TABLESPACE PRESC_PARTITION_04,
    PARTITION PRESC200505
    NOLOGGING
    TABLESPACE PRESC_PARTITION_05,
    PARTITION PRESC200506
    NOLOGGING
    TABLESPACE PRESC_PARTITION_06,
    PARTITION PRESC200507
    NOLOGGING
    TABLESPACE PRESC_PARTITION_07,
    PARTITION PRESC200508
    NOLOGGING
    TABLESPACE PRESC_PARTITION_08,
    PARTITION PRESC200509
    NOLOGGING
    TABLESPACE PRESC_PARTITION_09,
    PARTITION PRESC200510
    NOLOGGING
    TABLESPACE PRESC_PARTITION_10,
    PARTITION PRESC200511
    NOLOGGING
    TABLESPACE PRESC_PARTITION_11,
    PARTITION PRESC200512
    NOLOGGING
    TABLESPACE PRESC_PARTITION_12,
    PARTITION PRESC200601
    NOLOGGING
    TABLESPACE PRESC_PARTITION_13,
    PARTITION PRESC200602
    NOLOGGING
    TABLESPACE PRESC_PARTITION_14,
    PARTITION PRESC200603
    NOLOGGING
    TABLESPACE PRESC_PARTITION_15,
    PARTITION PRESC200604
    NOLOGGING
    TABLESPACE PRESC_PARTITION_16,
    PARTITION PRESC200605
    NOLOGGING
    TABLESPACE PRESC_PARTITION_17,
    PARTITION PRESC200606
    NOLOGGING
    TABLESPACE PRESC_PARTITION_18,
    PARTITION PRESC200607
    NOLOGGING
    TABLESPACE PRESC_PARTITION_19,
    PARTITION PRESC200608
    NOLOGGING
    TABLESPACE PRESC_PARTITION_20,
    PARTITION PRESC200609
    NOLOGGING
    TABLESPACE PRESC_PARTITION_21,
    PARTITION PRESC200610
    NOLOGGING
    TABLESPACE PRESC_PARTITION_22,
    PARTITION PRESC200611
    NOLOGGING
    TABLESPACE PRESC_PARTITION_23,
    PARTITION PRESC200612
    NOLOGGING
    TABLESPACE PRESC_PARTITION_24,
    PARTITION PRESC200701
    NOLOGGING
    TABLESPACE PRESC_PARTITION_25,
    PARTITION PRESC200702
    NOLOGGING
    TABLESPACE PRESC_PARTITION_26,
    PARTITION PRESC200703
    NOLOGGING
    TABLESPACE PRESC_PARTITION_27,
    PARTITION PRESC200704
    NOLOGGING
    TABLESPACE PRESC_PARTITION_28,
    PARTITION PRESC200705
    NOLOGGING
    TABLESPACE PRESC_PARTITION_29
    NOPARALLEL;
    Prompt Index BX6_PRESC_RELID;
    -- BX6_PRESC_RELID (Index)
    -- Dependencies:
    -- PRESCRIP_RETAIL (Table)
    CREATE BITMAP INDEX RETAIL.BX6_PRESC_RELID ON RETAIL.PRESCRIP_RETAIL
    (RELID)
    TABLESPACE PRESC_PARTITION_29
    LOGGING
    LOCAL (
    PARTITION PRESC200406
    NOLOGGING
    TABLESPACE PRESC_PARTITION_30,
    PARTITION PRESC200407
    NOLOGGING
    TABLESPACE PRESC_PARTITION_31,
    PARTITION PRESC200408
    NOLOGGING
    TABLESPACE PRESC_PARTITION_32,
    PARTITION PRESC200409
    NOLOGGING
    TABLESPACE PRESC_PARTITION_33,
    PARTITION PRESC200410
    NOLOGGING
    TABLESPACE PRESC_PARTITION_34,
    PARTITION PRESC200411
    NOLOGGING
    TABLESPACE PRESC_PARTITION_35,
    PARTITION PRESC200412
    NOLOGGING
    TABLESPACE PRESC_PARTITION_36,
    PARTITION PRESC200501
    NOLOGGING
    TABLESPACE PRESC_PARTITION_01,
    PARTITION PRESC200502
    NOLOGGING
    TABLESPACE PRESC_PARTITION_02,
    PARTITION PRESC200503
    NOLOGGING
    TABLESPACE PRESC_PARTITION_03,
    PARTITION PRESC200504
    NOLOGGING
    TABLESPACE PRESC_PARTITION_04,
    PARTITION PRESC200505
    NOLOGGING
    TABLESPACE PRESC_PARTITION_05,
    PARTITION PRESC200506
    NOLOGGING
    TABLESPACE PRESC_PARTITION_06,
    PARTITION PRESC200507
    NOLOGGING
    TABLESPACE PRESC_PARTITION_07,
    PARTITION PRESC200508
    NOLOGGING
    TABLESPACE PRESC_PARTITION_08,
    PARTITION PRESC200509
    NOLOGGING
    TABLESPACE PRESC_PARTITION_09,
    PARTITION PRESC200510
    NOLOGGING
    TABLESPACE PRESC_PARTITION_10,
    PARTITION PRESC200511
    NOLOGGING
    TABLESPACE PRESC_PARTITION_11,
    PARTITION PRESC200512
    NOLOGGING
    TABLESPACE PRESC_PARTITION_12,
    PARTITION PRESC200601
    NOLOGGING
    TABLESPACE PRESC_PARTITION_13,
    PARTITION PRESC200602
    NOLOGGING
    TABLESPACE PRESC_PARTITION_14,
    PARTITION PRESC200603
    NOLOGGING
    TABLESPACE PRESC_PARTITION_15,
    PARTITION PRESC200604
    NOLOGGING
    TABLESPACE PRESC_PARTITION_16,
    PARTITION PRESC200605
    NOLOGGING
    TABLESPACE PRESC_PARTITION_17,
    PARTITION PRESC200606
    NOLOGGING
    TABLESPACE PRESC_PARTITION_18,
    PARTITION PRESC200607
    NOLOGGING
    TABLESPACE PRESC_PARTITION_19,
    PARTITION PRESC200608
    NOLOGGING
    TABLESPACE PRESC_PARTITION_20,
    PARTITION PRESC200609
    NOLOGGING
    TABLESPACE PRESC_PARTITION_21,
    PARTITION PRESC200610
    NOLOGGING
    TABLESPACE PRESC_PARTITION_22,
    PARTITION PRESC200611
    NOLOGGING
    TABLESPACE PRESC_PARTITION_23,
    PARTITION PRESC200612
    NOLOGGING
    TABLESPACE PRESC_PARTITION_24,
    PARTITION PRESC200701
    NOLOGGING
    TABLESPACE PRESC_PARTITION_25,
    PARTITION PRESC200702
    NOLOGGING
    TABLESPACE PRESC_PARTITION_26,
    PARTITION PRESC200703
    NOLOGGING
    TABLESPACE PRESC_PARTITION_27,
    PARTITION PRESC200704
    NOLOGGING
    TABLESPACE PRESC_PARTITION_28,
    PARTITION PRESC200705
    NOLOGGING
    TABLESPACE PRESC_PARTITION_29
    NOPARALLEL;
    Prompt Index BX7_PRESC_ME;
    -- BX7_PRESC_ME (Index)
    -- Dependencies:
    -- PRESCRIP_RETAIL (Table)
    CREATE BITMAP INDEX RETAIL.BX7_PRESC_ME ON RETAIL.PRESCRIP_RETAIL
    (ME_NUM)
    TABLESPACE PRESC_PARTITION_29
    LOGGING
    LOCAL (
    PARTITION PRESC200406
    NOLOGGING
    TABLESPACE PRESC_PARTITION_30,
    PARTITION PRESC200407
    NOLOGGING
    TABLESPACE PRESC_PARTITION_31,
    PARTITION PRESC200408
    NOLOGGING
    TABLESPACE PRESC_PARTITION_32,
    PARTITION PRESC200409
    NOLOGGING
    TABLESPACE PRESC_PARTITION_33,
    PARTITION PRESC200410
    NOLOGGING
    TABLESPACE PRESC_PARTITION_34,
    PARTITION PRESC200411
    NOLOGGING
    TABLESPACE PRESC_PARTITION_35,
    PARTITION PRESC200412
    NOLOGGING
    TABLESPACE PRESC_PARTITION_36,
    PARTITION PRESC200501
    NOLOGGING
    TABLESPACE PRESC_PARTITION_01,
    PARTITION PRESC200502
    NOLOGGING
    TABLESPACE PRESC_PARTITION_02,
    PARTITION PRESC200503
    NOLOGGING
    TABLESPACE PRESC_PARTITION_03,
    PARTITION PRESC200504
    NOLOGGING
    TABLESPACE PRESC_PARTITION_04,
    PARTITION PRESC200505
    NOLOGGING
    TABLESPACE PRESC_PARTITION_05,
    PARTITION PRESC200506
    NOLOGGING
    TABLESPACE PRESC_PARTITION_06,
    PARTITION PRESC200507
    NOLOGGING
    TABLESPACE PRESC_PARTITION_07,
    PARTITION PRESC200508
    NOLOGGING
    TABLESPACE PRESC_PARTITION_08,
    PARTITION PRESC200509
    NOLOGGING
    TABLESPACE PRESC_PARTITION_09,
    PARTITION PRESC200510
    NOLOGGING
    TABLESPACE PRESC_PARTITION_10,
    PARTITION PRESC200511
    NOLOGGING
    TABLESPACE PRESC_PARTITION_11,
    PARTITION PRESC200512
    NOLOGGING
    TABLESPACE PRESC_PARTITION_12,
    PARTITION PRESC200601
    NOLOGGING
    TABLESPACE PRESC_PARTITION_13,
    PARTITION PRESC200602
    NOLOGGING
    TABLESPACE PRESC_PARTITION_14,
    PARTITION PRESC200603
    NOLOGGING
    TABLESPACE PRESC_PARTITION_15,
    PARTITION PRESC200604
    NOLOGGING
    TABLESPACE PRESC_PARTITION_16,
    PARTITION PRESC200605
    NOLOGGING
    TABLESPACE PRESC_PARTITION_17,
    PARTITION PRESC200606
    NOLOGGING
    TABLESPACE PRESC_PARTITION_18,
    PARTITION PRESC200607
    NOLOGGING
    TABLESPACE PRESC_PARTITION_19,
    PARTITION PRESC200608
    NOLOGGING
    TABLESPACE PRESC_PARTITION_20,
    PARTITION PRESC200609
    NOLOGGING
    TABLESPACE PRESC_PARTITION_21,
    PARTITION PRESC200610
    NOLOGGING
    TABLESPACE PRESC_PARTITION_22,
    PARTITION PRESC200611
    NOLOGGING
    TABLESPACE PRESC_PARTITION_23,
    PARTITION PRESC200612
    NOLOGGING
    TABLESPACE PRESC_PARTITION_24,
    PARTITION PRESC200701
    NOLOGGING
    TABLESPACE PRESC_PARTITION_25,
    PARTITION PRESC200702
    NOLOGGING
    TABLESPACE PRESC_PARTITION_26,
    PARTITION PRESC200703
    NOLOGGING
    TABLESPACE PRESC_PARTITION_27,
    PARTITION PRESC200704
    NOLOGGING
    TABLESPACE PRESC_PARTITION_28,
    PARTITION PRESC200705
    NOLOGGING
    TABLESPACE PRESC_PARTITION_29
    NOPARALLEL;
    Prompt Index BX1_PRESC_PROD;
    -- BX1_PRESC_PROD (Index)
    -- Dependencies:
    -- PRESCRIP_RETAIL (Table)
    CREATE BITMAP INDEX RETAIL.BX1_PRESC_PROD ON RETAIL.PRESCRIP_RETAIL
    (PRODUCT_ID, PRODUCT_FRMSTR)
    TABLESPACE PRESC_PARTITION_29
    LOGGING
    LOCAL (
    PARTITION PRESC200406
    NOLOGGING
    TABLESPACE PRESC_PARTITION_30,
    PARTITION PRESC200407
    NOLOGGING
    TABLESPACE PRESC_PARTITION_31,
    PARTITION PRESC200408
    NOLOGGING
    TABLESPACE PRESC_PARTITION_32,
    PARTITION PRESC200409
    NOLOGGING
    TABLESPACE PRESC_PARTITION_33,
    PARTITION PRESC200410
    NOLOGGING
    TABLESPACE PRESC_PARTITION_34,
    PARTITION PRESC200411
    NOLOGGING
    TABLESPACE PRESC_PARTITION_35,
    PARTITION PRESC200412
    NOLOGGING
    TABLESPACE PRESC_PARTITION_36,
    PARTITION PRESC200501
    NOLOGGING
    TABLESPACE PRESC_PARTITION_01,
    PARTITION PRESC200502
    NOLOGGING
    TABLESPACE PRESC_PARTITION_02,
    PARTITION PRESC200503
    NOLOGGING
    TABLESPACE PRESC_PARTITION_03,
    PARTITION PRESC200504
    NOLOGGING
    TABLESPACE PRESC_PARTITION_04,
    PARTITION PRESC200505
    NOLOGGING
    TABLESPACE PRESC_PARTITION_05,
    PARTITION PRESC200506
    NOLOGGING
    TABLESPACE PRESC_PARTITION_06,
    PARTITION PRESC200507
    NOLOGGING
    TABLESPACE PRESC_PARTITION_07,
    PARTITION PRESC200508
    NOLOGGING
    TABLESPACE PRESC_PARTITION_08,
    PARTITION PRESC200509
    NOLOGGING
    TABLESPACE PRESC_PARTITION_09,
    PARTITION PRESC200510
    NOLOGGING
    TABLESPACE PRESC_PARTITION_10,
    PARTITION PRESC200511
    NOLOGGING
    TABLESPACE PRESC_PARTITION_11,
    PARTITION PRESC200512
    NOLOGGING
    TABLESPACE PRESC_PARTITION_12,
    PARTITION PRESC200601
    NOLOGGING
    TABLESPACE PRESC_PARTITION_13,
    PARTITION PRESC200602
    NOLOGGING
    TABLESPACE PRESC_PARTITION_14,
    PARTITION PRESC200603
    NOLOGGING
    TABLESPACE PRESC_PARTITION_15,
    PARTITION PRESC200604
    NOLOGGING
    TABLESPACE PRESC_PARTITION_16,
    PARTITION PRESC200605
    NOLOGGING
    TABLESPACE PRESC_PARTITION_17,
    PARTITION PRESC200606
    NOLOGGING
    TABLESPACE PRESC_PARTITION_18,
    PARTITION PRESC200607
    NOLOGGING
    TABLESPACE PRESC_PARTITION_19,
    PARTITION PRESC200608
    NOLOGGING
    TABLESPACE PRESC_PARTITION_20,
    PARTITION PRESC200609
    NOLOGGING
    TABLESPACE PRESC_PARTITION_21,
    PARTITION PRESC200610
    NOLOGGING
    TABLESPACE PRESC_PARTITION_22,
    PARTITION PRESC200611
    NOLOGGING
    TABLESPACE PRESC_PARTITION_23,
    PARTITION PRESC200612
    NOLOGGING
    TABLESPACE PRESC_PARTITION_24,
    PARTITION PRESC200701
    NOLOGGING
    TABLESPACE PRESC_PARTITION_25,
    PARTITION PRESC200702
    NOLOGGING
    TABLESPACE PRESC_PARTITION_26,
    PARTITION PRESC200703
    NOLOGGING
    TABLESPACE PRESC_PARTITION_27,
    PARTITION PRESC200704
    NOLOGGING
    TABLESPACE PRESC_PARTITION_28,
    PARTITION PRESC200705
    NOLOGGING
    TABLESPACE PRESC_PARTITION_29
    NOPARALLEL;

  • Out of the box execution plan for Payables EBS 11.5.10

    Has anyone else experienced performance issues with the out of the box execution plan for the Payables subject area for Oracle EBS 11.5.10? Our incremental ETL for this particular subject area is taking 8+ hours. I understand that there are several factors involved with performance and that there are a lot of AP transactions, but this is ridiculous for a nightly incremental ETL job.
    In particular it is the SDE_ORA_APTransactionFact_Payment task that is taking forever. This query appears to have extremely high cost (see explain plan below). Has anyone been successful in rewriting or changing this query?
    SELECT STATEMENT  ALL_ROWSCost: 586,953  Bytes: 16,550  Cardinality: 50                                                                         
                13 NESTED LOOPS OUTER  Cost: 586,953  Bytes: 16,550  Cardinality: 50                                                         
                            10 NESTED LOOPS  Cost: 586,952  Bytes: 15,800  Cardinality: 50                                             
                                        7 HASH JOIN  Cost: 468,320  Bytes: 11,693,526  Cardinality: 59,358                               
                                                    5 HASH JOIN  Cost: 429,964  Bytes: 9,200,490  Cardinality: 59,358                     
                                                                3 HASH JOIN  Cost: 366,009  Bytes: 7,740,544  Cardinality: 60,473         
                                                                            1 TABLE ACCESS FULL TABLE AP.AP_AE_LINES_ALL Cost: 273,240  Bytes: 15,212,604  Cardinality: 230,494 
                                                                            2 TABLE ACCESS FULL TABLE AP.AP_INVOICE_PAYMENTS_ALL Cost: 45,211  Bytes: 715,512,860  Cardinality: 11,540,530 
                                                                4 TABLE ACCESS FULL TABLE AP.AP_PAYMENT_SCHEDULES_ALL Cost: 39,003  Bytes: 309,648,420  Cardinality: 11,468,460       
                                                    6 TABLE ACCESS FULL TABLE AP.AP_CHECKS_ALL Cost: 28,675  Bytes: 130,126,920  Cardinality: 3,098,260               
                                        9 TABLE ACCESS BY INDEX ROWID TABLE AP.AP_INVOICES_ALL Cost: 2  Bytes: 119  Cardinality: 1                                 
                                                    8 INDEX UNIQUE SCAN INDEX (UNIQUE) AP.AP_INVOICES_U1 Cost: 1  Cardinality: 1             
                            12 TABLE ACCESS BY INDEX ROWID TABLE PO.PO_HEADERS_ALL Cost: 1  Bytes: 15  Cardinality: 1                                                 
                                        11 INDEX UNIQUE SCAN INDEX (UNIQUE) PO.PO_HEADERS_U1 Cost: 1  Cardinality: 1                       

    Hi Srini, All,
    Thanks for the reply.
    The payables documentation (i.e. User Guide) discusses about options that could be used in implementing EFT. However, if possible, we would like suggestions on what would be the better ways to implement EFT (US bank) using either XML or text formats. We would also prefer not using e-commerce gateway or EDI.
    Thanks in advance.
    MM

  • How to set value to Model Node of cardinality 0..N

    hi
    I am looking for a way to set value to a model node of cardinality 0..N
    i imported a WSDL into my applicaion , which has the following Node Structure.
    Context
    --- ModelNode_Request
          ---ModelNode2_Input
          ---ModleNode3_Roles  [ cardinality 0..n singleton 1..1]
               ****Model_Attribute RoleID     <<<<<<<<<<<<
               ****Model_Attribute SysID      <<<<<<<<<<<<
      ---ModelNode_Response
    i tried with the below code  but effort went in vain.
    i tried following ways to set the value but , i get Nullpointer expection error.
         wdContext.nodeRequest__SubmitRequest().nodeRequestDetails().nodeRoles().
              currentRolesElement().setRoleId("BASIC");
         wdContext.nodeRequest__SubmitRequest().nodeRequestDetails().nodeRoles().
              currentRolesElement().setSysId("R3_220");
    i aslo looked into the forum  https://www.sdn.sap.com/irj/scn/thread?messageID=2035342 but couldnt find any solid solution.
    It would be great if some one can throw some snippets on the same.
    Thanks
    Edited by: RR on Dec 22, 2008 5:48 PM

    Hi RR,
    As far as i know u can set model nodes and values nodes are different. whats shown in the link is for values node. u should do differently for model node..
        Since this is a model node...u first need to create an object of the node type. then create an arraylist for that and then add values..
    try this..
    // Create an object for structures in the node to be used
    Yweb_Po_Items objPOItems = null; // where Yweb_Po_Items is the structure of the node...
    // Create an abstractlist for structures in the RFC node to be used, if u are planning to give single or multiple rows (in node/table) as input to the RFC
    AbstractList POObjAbsList = new Yweb_Po_Items.Yweb_Po_Items_List();
    objPOItems = new Yweb_Po_Items();
    //    /set first set of values
    objPOItems.setColumn1(u201Cabcu201D); // here hard codede for example
    objPOItems.setColumn2(u201Cabcfghu201D);
    // add the object to the abstract list
    POObjAbsList.add(objPOItems);
    //    /set second set of values
    objPOItems.setColumn1(u201Cnewabcu201D);
    objPOItems.setColumn2(u201Cnewabcfghu201D);
    // add the object to the abstract list again
    POObjAbsList.add(objPOItems); // now u got 2 records
    // now set the abstractlist to the node in the RFC
    objGoodsReceiptPO.setPo_Items_In(POObjAbsList);
    Hope this information is useful...
    Thanks
    Md. Yusuf

Maybe you are looking for

  • How to get iBook to Automatically turning the page

    It used to do this on The software before but now I just can't get it to do it on iOS 7  please can anybody help thanks in advance

  • My (valid) Serial Number won't work on a new computer

    I'm entering my serial number to authorise CS6 Design & Web Premium on my new Macbook Pro. I get an error message "Serial Number you provided is valid, but a qualifying product could not be found on this computer", and it is asking me to choose a qua

  • Profile for Aperture books

    ( we calibrate our screens ) but our books come back slighly darker - we use SRGB

  • Restarting with 2 Admin users logged in

    This does not work under 10.5.8 on either PowerPC or Intel portables. The OS does not accept either user's id or password. You must logout one user and then action the restart from the other user. This means that if you want to install software that

  • Hyper draw graphic bug?

    Can anyone confirm this? When I draw in hyper edit data or move track automation to a region, the display in the arrange page is one quarter note later than the data that shows up in the event list. Needless to say this makes editing data difficult.