Query help, join 3 times

Hi Friends,
the example table is:
EMP : columns are emp_id (primary Key), name
STORES_REQUISITION_MASTER: columns are
req_id,
req_date,
requested_by(referes to emp_id of EMP),
approved_by(refers to emp_id of EMP),
authorised_by (refers to emp_id of EMP)
and i want a report of all requisitions like this.
req_id,req_date,name_of_the_reuested_employee,name_of_approved_employee,name_of_authorised_employee.
what is the best way to get this format.
thanks in advance.

SELECT S.req_id, S.req_date, R.name, A.name, T.name
FROM Stores_Requisition_Master S,
EMP R,
EMP A,
EMP T
WHERE S.requested_by = R.id
AND S.approved_by = A.id
AND S.authorised_by = T.id;

Similar Messages

  • Seibel Query help : -  Joining Order table with Asset or CX_ACTION table.

    Hi Team
    I need help joining the Order table with the Asset table
    or the Order table with CX_ACTION table to
    Can i get reference on this .
    select x.x_msisdn,
    x.x_product_name,
    x.x_action,
    x.x_status_outcome,
    a.recovered_dt,
    x.x_amount,
    x.created,
    x.x_number_retries,
    o.ORDER_NUM "FMW Order No",
    DECODE(FULFLMNT_STATUS_CD , 'Failed','Failed', o.STATUS_CD) "Order Status"
    from
    siebel.cx_action x,
    siebel.s_order o,
    siebel.s_asset a
    where a.row_id = x.x_asset_id
    and x.created > to_date('08/01/2013 08:00:00', 'dd/mm/yyyy hh24:mi:ss')
    and x.created < to_date('09/04/2013 07:50:00', 'dd/mm/yyyy hh24:mi:ss')
    Regards

    I'm not familiar with Seibel or any of these tables but right off the bat I'd suggest you're missing a join predicate to your s_order table. This could give you far more rows than you're expecting.
    Aside from that you haven't told us what problems you are having. An error? Wrong results? Performance?

  • Pagination query help needed for large table - force a different index

    I'm using a slight modification of the pagination query from over at Ask Tom's: [http://www.oracle.com/technology/oramag/oracle/07-jan/o17asktom.html]
    Mine looks like this when fetching the first 100 rows of all members with last name Smith, ordered by join date:
    SELECT members.*
    FROM members,
        SELECT RID, rownum rnum
        FROM
            SELECT rowid as RID
            FROM members
            WHERE last_name = 'Smith'
            ORDER BY joindate
        WHERE rownum <= 100
    WHERE rnum >= 1
             and RID = members.rowidThe difference between this and the one at Ask Tom's is that my innermost query just returns the ROWID. Then in the outermost query we join the ROWIDs returned to the members table, after we have pruned the ROWIDs down to only the chunk of 100 we want. This makes it MUCH faster (verifiably) on our large tables, as it is able to use the index on the innermost query (well... read on).
    The problem I have is this:
    SELECT rowid as RID
    FROM members
    WHERE last_name = 'Smith'
    ORDER BY joindateThis will use the index for the predicate column (last_name) instead of the unique index I have defined for the joindate column (joindate, sequence). (Verifiable with explain plan). It is much slower this way on a large table. So I can hint it using either of the following methods:
    SELECT /*+ index(members, joindate_idx) */ rowid as RID
    FROM members
    WHERE last_name = 'Smith'
    ORDER BY joindate
    SELECT /*+ first_rows(100) */ rowid as RID
    FROM members
    WHERE last_name = 'Smith'
    ORDER BY joindateEither way, it now uses the index of the ORDER BY column (joindate_idx), so now it is much faster as it does not have to do a sort (remember, VERY large table, millions of records). So that seems good. But now, on my outermost query, I join the rowid with the meaningful columns of data from the members table, as commented below:
    SELECT members.*      -- Select all data from members table
    FROM members,           -- members table added to FROM clause
        SELECT RID, rownum rnum
        FROM
            SELECT /*+ index(members, joindate_idx) */ rowid as RID   -- Hint is ignored now that I am joining in the outer query
            FROM members
            WHERE last_name = 'Smith'
            ORDER BY joindate
        WHERE rownum <= 100
    WHERE rnum >= 1
            and RID = members.rowid           -- Merge the members table on the rowid we pulled from the inner queriesOnce I do this join, it goes back to using the predicate index (last_name) and has to perform the sort once it finds all matching values (which can be a lot in this table, there is high cardinality on some columns).
    So my question is, in the full query above, is there any way I can get it to use the ORDER BY column for indexing to prevent it from having to do a sort? The join is what causes it to revert back to using the predicate index, even with hints. Remove the join and just return the ROWIDs for those 100 records and it flies, even on 10 million records.
    It'd be great if there was some generic hint that could accomplish this, such that if we change the table/columns/indexes, we don't need to change the hint (the FIRST_ROWS hint is a good example of this, while the INDEX hint is the opposite), but any help would be appreciated. I can provide explain plans for any of the above if needed.
    Thanks!

    Lakmal Rajapakse wrote:
    OK here is an example to illustrate the advantage:
    SQL> set autot traceonly
    SQL> select * from (
    2  select a.*, rownum x  from
    3  (
    4  select a.* from aoswf.events a
    5  order by EVENT_DATETIME
    6  ) a
    7  where rownum <= 1200
    8  )
    9  where x >= 1100
    10  /
    101 rows selected.
    Execution Plan
    Plan hash value: 3711662397
    | Id  | Operation                      | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT               |            |  1200 |   521K|   192   (0)| 00:00:03 |
    |*  1 |  VIEW                          |            |  1200 |   521K|   192   (0)| 00:00:03 |
    |*  2 |   COUNT STOPKEY                |            |       |       |            |          |
    |   3 |    VIEW                        |            |  1200 |   506K|   192   (0)| 00:00:03 |
    |   4 |     TABLE ACCESS BY INDEX ROWID| EVENTS     |   253M|    34G|   192   (0)| 00:00:03 |
    |   5 |      INDEX FULL SCAN           | EVEN_IDX02 |  1200 |       |     2   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    1 - filter("X">=1100)
    2 - filter(ROWNUM<=1200)
    Statistics
    0  recursive calls
    0  db block gets
    443  consistent gets
    0  physical reads
    0  redo size
    25203  bytes sent via SQL*Net to client
    281  bytes received via SQL*Net from client
    8  SQL*Net roundtrips to/from client
    0  sorts (memory)
    0  sorts (disk)
    101  rows processed
    SQL>
    SQL>
    SQL> select * from aoswf.events a, (
    2  select rid, rownum x  from
    3  (
    4  select rowid rid from aoswf.events a
    5  order by EVENT_DATETIME
    6  ) a
    7  where rownum <= 1200
    8  ) b
    9  where x >= 1100
    10  and a.rowid = rid
    11  /
    101 rows selected.
    Execution Plan
    Plan hash value: 2308864810
    | Id  | Operation                   | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT            |            |  1200 |   201K|   261K  (1)| 00:52:21 |
    |   1 |  NESTED LOOPS               |            |  1200 |   201K|   261K  (1)| 00:52:21 |
    |*  2 |   VIEW                      |            |  1200 | 30000 |   260K  (1)| 00:52:06 |
    |*  3 |    COUNT STOPKEY            |            |       |       |            |          |
    |   4 |     VIEW                    |            |   253M|  2895M|   260K  (1)| 00:52:06 |
    |   5 |      INDEX FULL SCAN        | EVEN_IDX02 |   253M|  4826M|   260K  (1)| 00:52:06 |
    |   6 |   TABLE ACCESS BY USER ROWID| EVENTS     |     1 |   147 |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    2 - filter("X">=1100)
    3 - filter(ROWNUM<=1200)
    Statistics
    8  recursive calls
    0  db block gets
    117  consistent gets
    0  physical reads
    0  redo size
    27539  bytes sent via SQL*Net to client
    281  bytes received via SQL*Net from client
    8  SQL*Net roundtrips to/from client
    0  sorts (memory)
    0  sorts (disk)
    101  rows processed
    Lakmal (and OP),
    Not sure what advantage you are trying to show here. But considering that we are talking about pagination query here and order of records is important, your 2 queries will not always generate output in same order. Here is the test case:
    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> show parameter optimizer
    NAME                                 TYPE        VALUE
    optimizer_dynamic_sampling           integer     2
    optimizer_features_enable            string      10.2.0.1
    optimizer_index_caching              integer     0
    optimizer_index_cost_adj             integer     100
    optimizer_mode                       string      ALL_ROWS
    optimizer_secure_view_merging        boolean     TRUE
    SQL> show parameter pga
    NAME                                 TYPE        VALUE
    pga_aggregate_target                 big integer 103M
    SQL> create table t nologging as select * from all_objects where 1 = 2 ;
    Table created.
    SQL> create index t_idx on t(last_ddl_time) nologging ;
    Index created.
    SQL> insert /*+ APPEND */ into t (owner, object_name, object_id, created, last_ddl_time) select owner, object_name, object_id, created, sysdate - dbms_random.value(1, 100) from all_objects order by dbms_random.random;
    40617 rows created.
    SQL> commit ;
    Commit complete.
    SQL> exec dbms_stats.gather_table_stats(user, 'T', cascade=>true);
    PL/SQL procedure successfully completed.
    SQL> select object_id, object_name, created from t, (select rid, rownum rn from (select rowid rid from t order by created desc) where rownum <= 1200) t1 where rn >= 1190 and t.rowid = t1.rid ;
    OBJECT_ID OBJECT_NAME                    CREATED
         47686 ALL$OLAP2_JOIN_KEY_COLUMN_USES 28-JUL-2009 08:08:39
         47672 ALL$OLAP2_CUBE_DIM_USES        28-JUL-2009 08:08:39
         47681 ALL$OLAP2_CUBE_MEASURE_MAPS    28-JUL-2009 08:08:39
         47682 ALL$OLAP2_FACT_LEVEL_USES      28-JUL-2009 08:08:39
         47685 ALL$OLAP2_AGGREGATION_USES     28-JUL-2009 08:08:39
         47692 ALL$OLAP2_CATALOGS             28-JUL-2009 08:08:39
         47665 ALL$OLAPMR_FACTTBLKEYMAPS      28-JUL-2009 08:08:39
         47688 ALL$OLAP2_DIM_LEVEL_ATTR_MAPS  28-JUL-2009 08:08:39
         47689 ALL$OLAP2_DIM_LEVELS_KEYMAPS   28-JUL-2009 08:08:39
         47669 ALL$OLAP9I2_HIER_DIMENSIONS    28-JUL-2009 08:08:39
         47666 ALL$OLAP9I1_HIER_DIMENSIONS    28-JUL-2009 08:08:39
    11 rows selected.
    SQL> select object_id, object_name, last_ddl_time from t, (select rid, rownum rn from (select rowid rid from t order by last_ddl_time desc) where rownum <= 1200) t1 where rn >= 1190 and t.rowid = t1.rid ;
    OBJECT_ID OBJECT_NAME                    LAST_DDL_TIME
         11749 /b9fe5b99_OraRTStatementComman 06-FEB-2010 03:43:49
         13133 oracle/jdbc/driver/OracleLog$3 06-FEB-2010 03:45:44
         37534 com/sun/mail/smtp/SMTPMessage  06-FEB-2010 03:46:14
         36145 /4e492b6f_SerProfileToClassErr 06-FEB-2010 03:11:09
         26815 /7a628fb8_DefaultHSBChooserPan 06-FEB-2010 03:26:55
         16695 /2940a364_RepIdDelegator_1_3   06-FEB-2010 03:38:17
         36539 sun/io/ByteToCharMacHebrew     06-FEB-2010 03:28:57
         14044 /d29b81e1_OldHeaders           06-FEB-2010 03:12:12
         12920 /25f8f3a5_BasicSplitPaneUI     06-FEB-2010 03:11:06
         42266 SI_GETCLRHSTGRFTR              06-FEB-2010 03:40:20
         15752 /2f494dce_JDWPThreadReference  06-FEB-2010 03:09:31
    11 rows selected.
    SQL> select object_id, object_name, last_ddl_time from (select t1.*, rownum rn from (select * from t order by last_ddl_time desc) t1 where rownum <= 1200) where rn >= 1190 ;
    OBJECT_ID OBJECT_NAME                    LAST_DDL_TIME
         37534 com/sun/mail/smtp/SMTPMessage  06-FEB-2010 03:46:14
         13133 oracle/jdbc/driver/OracleLog$3 06-FEB-2010 03:45:44
         11749 /b9fe5b99_OraRTStatementComman 06-FEB-2010 03:43:49
         42266 SI_GETCLRHSTGRFTR              06-FEB-2010 03:40:20
         16695 /2940a364_RepIdDelegator_1_3   06-FEB-2010 03:38:17
         36539 sun/io/ByteToCharMacHebrew     06-FEB-2010 03:28:57
         26815 /7a628fb8_DefaultHSBChooserPan 06-FEB-2010 03:26:55
         14044 /d29b81e1_OldHeaders           06-FEB-2010 03:12:12
         36145 /4e492b6f_SerProfileToClassErr 06-FEB-2010 03:11:09
         12920 /25f8f3a5_BasicSplitPaneUI     06-FEB-2010 03:11:06
         15752 /2f494dce_JDWPThreadReference  06-FEB-2010 03:09:31
    11 rows selected.
    SQL> select object_id, object_name, last_ddl_time from t, (select rid, rownum rn from (select rowid rid from t order by last_ddl_time desc) where rownum <= 1200) t1 where rn >= 1190 and t.rowid = t1.rid order by last_ddl_time desc ;
    OBJECT_ID OBJECT_NAME                    LAST_DDL_TIME
         37534 com/sun/mail/smtp/SMTPMessage  06-FEB-2010 03:46:14
         13133 oracle/jdbc/driver/OracleLog$3 06-FEB-2010 03:45:44
         11749 /b9fe5b99_OraRTStatementComman 06-FEB-2010 03:43:49
         42266 SI_GETCLRHSTGRFTR              06-FEB-2010 03:40:20
         16695 /2940a364_RepIdDelegator_1_3   06-FEB-2010 03:38:17
         36539 sun/io/ByteToCharMacHebrew     06-FEB-2010 03:28:57
         26815 /7a628fb8_DefaultHSBChooserPan 06-FEB-2010 03:26:55
         14044 /d29b81e1_OldHeaders           06-FEB-2010 03:12:12
         36145 /4e492b6f_SerProfileToClassErr 06-FEB-2010 03:11:09
         12920 /25f8f3a5_BasicSplitPaneUI     06-FEB-2010 03:11:06
         15752 /2f494dce_JDWPThreadReference  06-FEB-2010 03:09:31
    11 rows selected.
    SQL> set autotrace traceonly
    SQL> select object_id, object_name, last_ddl_time from t, (select rid, rownum rn from (select rowid rid from t order by last_ddl_time desc) where rownum <= 1200) t1 where rn >= 1190 and t.rowid = t1.rid order by last_ddl_time desc
      2  ;
    11 rows selected.
    Execution Plan
    Plan hash value: 44968669
    | Id  | Operation                       | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                |       |  1200 | 91200 |   180   (2)| 00:00:03 |
    |   1 |  SORT ORDER BY                  |       |  1200 | 91200 |   180   (2)| 00:00:03 |
    |*  2 |   HASH JOIN                     |       |  1200 | 91200 |   179   (2)| 00:00:03 |
    |*  3 |    VIEW                         |       |  1200 | 30000 |    98   (0)| 00:00:02 |
    |*  4 |     COUNT STOPKEY               |       |       |       |            |          |
    |   5 |      VIEW                       |       | 40617 |   475K|    98   (0)| 00:00:02 |
    |   6 |       INDEX FULL SCAN DESCENDING| T_IDX | 40617 |   793K|    98   (0)| 00:00:02 |
    |   7 |    TABLE ACCESS FULL            | T     | 40617 |  2022K|    80   (2)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("T".ROWID="T1"."RID")
       3 - filter("RN">=1190)
       4 - filter(ROWNUM<=1200)
    Statistics
              1  recursive calls
              0  db block gets
            348  consistent gets
              0  physical reads
              0  redo size
           1063  bytes sent via SQL*Net to client
            385  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              1  sorts (memory)
              0  sorts (disk)
             11  rows processed
    SQL> select object_id, object_name, last_ddl_time from (select t1.*, rownum rn from (select * from t order by last_ddl_time desc) t1 where rownum <= 1200) where rn >= 1190 ;
    11 rows selected.
    Execution Plan
    Plan hash value: 882605040
    | Id  | Operation                | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT         |      |  1200 | 62400 |    80   (2)| 00:00:01 |
    |*  1 |  VIEW                    |      |  1200 | 62400 |    80   (2)| 00:00:01 |
    |*  2 |   COUNT STOPKEY          |      |       |       |            |          |
    |   3 |    VIEW                  |      | 40617 |  1546K|    80   (2)| 00:00:01 |
    |*  4 |     SORT ORDER BY STOPKEY|      | 40617 |  2062K|    80   (2)| 00:00:01 |
    |   5 |      TABLE ACCESS FULL   | T    | 40617 |  2062K|    80   (2)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - filter("RN">=1190)
       2 - filter(ROWNUM<=1200)
       4 - filter(ROWNUM<=1200)
    Statistics
              0  recursive calls
              0  db block gets
            343  consistent gets
              0  physical reads
              0  redo size
           1063  bytes sent via SQL*Net to client
            385  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              1  sorts (memory)
              0  sorts (disk)
             11  rows processed
    SQL> select object_id, object_name, last_ddl_time from t, (select rid, rownum rn from (select rowid rid from t order by last_ddl_time desc) where rownum <= 1200) t1 where rn >= 1190 and t.rowid = t1.rid ;
    11 rows selected.
    Execution Plan
    Plan hash value: 168880862
    | Id  | Operation                      | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT               |       |  1200 | 91200 |   179   (2)| 00:00:03 |
    |*  1 |  HASH JOIN                     |       |  1200 | 91200 |   179   (2)| 00:00:03 |
    |*  2 |   VIEW                         |       |  1200 | 30000 |    98   (0)| 00:00:02 |
    |*  3 |    COUNT STOPKEY               |       |       |       |            |          |
    |   4 |     VIEW                       |       | 40617 |   475K|    98   (0)| 00:00:02 |
    |   5 |      INDEX FULL SCAN DESCENDING| T_IDX | 40617 |   793K|    98   (0)| 00:00:02 |
    |   6 |   TABLE ACCESS FULL            | T     | 40617 |  2022K|    80   (2)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - access("T".ROWID="T1"."RID")
       2 - filter("RN">=1190)
       3 - filter(ROWNUM<=1200)
    Statistics
              0  recursive calls
              0  db block gets
            349  consistent gets
              0  physical reads
              0  redo size
           1063  bytes sent via SQL*Net to client
            385  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
             11  rows processed
    SQL> select object_id, object_name, last_ddl_time from (select t1.*, rownum rn from (select * from t order by last_ddl_time desc) t1 where rownum <= 1200) where rn >= 1190 order by last_ddl_time desc ;
    11 rows selected.
    Execution Plan
    Plan hash value: 882605040
    | Id  | Operation           | Name | Rows     | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT      |     |  1200 | 62400 |    80   (2)| 00:00:01 |
    |*  1 |  VIEW                |     |  1200 | 62400 |    80   (2)| 00:00:01 |
    |*  2 |   COUNT STOPKEY       |     |     |     |          |          |
    |   3 |    VIEW            |     | 40617 |  1546K|    80   (2)| 00:00:01 |
    |*  4 |     SORT ORDER BY STOPKEY|     | 40617 |  2062K|    80   (2)| 00:00:01 |
    |   5 |      TABLE ACCESS FULL      | T     | 40617 |  2062K|    80   (2)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - filter("RN">=1190)
       2 - filter(ROWNUM<=1200)
       4 - filter(ROWNUM<=1200)
    Statistics
         175  recursive calls
           0  db block gets
         388  consistent gets
           0  physical reads
           0  redo size
           1063  bytes sent via SQL*Net to client
         385  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           4  sorts (memory)
           0  sorts (disk)
          11  rows processed
    SQL> set autotrace off
    SQL> spool offAs you will see, the join query here has to have an ORDER BY clause at the end to ensure that records are correctly sorted. You can not rely on optimizer choosing NESTED LOOP join method and, as above example shows, when optimizer chooses HASH JOIN, oracle is free to return rows in no particular order.
    The query that does not involve join always returns rows in the desired order. Adding an ORDER BY does add a step in the plan for the query using join but does not affect the other query.

  • Approach to tune a query in short time

    Hi All,
    Oracle 10g I know this question is asked number of times and there are many good replies to them.
    But I just want to know how to approach a completely new query ( like the task given to me to fine tume a query in 1 day when I dont have even the slightest idea about how to proceed) if the timeline is very stringent and by just looking at the explain plan, you have to take the decision.
    I am just posting my query here and what I am looking for is some lead on how to identify the congetion point which is where this query takes long time ( in my case some 15 mins as reported to me)
    select
                     "LEGAL ENTITY",
                     "Legal Entity Description",
                     "Cluster",
                     "Sub_Cluster",
                     "Account",
                      rownum,
                     "Moody_Rating",
                     "Process_Date",
                     "Merge_Description",
                      rownum,
                     "Merge_Description",
                     "is_id_ic",
                     "is_n",
                     "cusip",
                     "isin",
                     "credit_spread_PV01",
                     "amount",
                     "Market_Value",
                     "Currency",
                     "Sensitivity_Type",
                     "maturity_Date",
                     "Exception_Flag",
                     "Base_Security_Id",
                     DECODE(sign("Market_Value"),-1,DeCode(SigN("Recovery"),-1,"Recovery",('-'||"Recovery")), ABS("Recovery")) as "Recovery"
                     from
                     select
                     le.name "LEGAL ENTITY",
                     le.display_name "Legal Entity Description",
                     mn4.display_name "Cluster",
                     mn3.display_name "Sub_Cluster",
                     bookname.display_name "Account",
                     (SELECT RATING_NAME
                        FROM moody_rating
                       where moody_rating_id = i.moody_rating_id) "Moody_Rating",
                     to_char(to_date(:v_cob_date,'DD-MM-YY'),'YYYYMMDD') "Process_Date",
                     ss.issuer "Merge_Description",
                     PART.MARS_ISSUER "is_id_ic",
                     PART.PARTICIPANT_NAME "is_n",
                     NULL "cusip",
                     NULL "isin",
                     NULL "credit_spread_PV01",
                     NULL "amount",
                     sum(mtmsens.sensitivity_value) "Market_Value",
                     (SELECT distinct cc.CCY
                        FROM legacy_country CC
                       INNER JOIN MARSNODE MN ON CC.countryisocode = MN.NAME
                                             and mn.close_date is null
                       INNER JOIN MARSNODETYPE MNT ON MN.TYPE_ID =
                                                      MNT.NODE_TYPE_ID
                                                  AND MNT.NAME = 'COUNTRY'
                                                  and mnt.close_date is null
                       where MN.NODE_ID = part.country_domicile_id
                         and cc.begin_cob_date <= :v_cob_date
                         and cc.end_cob_date > :v_cob_date
                         and rownum < 2) "Currency",
                     'CREDITSPREADMARKETVALUE' "Sensitivity_Type",
                     NULL "maturity_Date",
                     NULL "Exception_Flag",
                     NULL "Base_Security_Id",
                     sum(ss.sensitivity_value) "Recovery"
                     from staging_position sp
                left JOIN position p on (
                                         p.feed_instance_id = sp.feed_instance_id
                                     AND p.feed_row_id = sp.feed_row_id)
                left JOIN staging_instrument si on (si.feed_instance_id =
                                                   sp.feed_instance_id AND
                                                   si.position_key =
                                                   sp.position_key)
                left join book b on (b.book_id = p.book_id and
                                    b.begin_cob_date <= :v_cob_date and
                                    b.end_cob_date > :v_cob_date)
                left join marsnode bk on (b.book_id = bk.node_id and
                                         bk.close_date is null)
                left join marsnode le on (b.leg_ent_id = le.node_id and
                                         le.close_date is null)
                left join marsnode bookname on (bookname.node_id = p.book_id and
                                               bookname.close_date is null)
                left join marsnodelink mnl on p.book_id = mnl.node_id
                                          and :v_bus_org_hier_id =
                                              mnl.hierarchy_id
                                          and mnl.close_date is null
                                          and :v_cob_date >= mnl.begin_cob_date
                                          and :v_cob_date < mnl.end_cob_date
                left join marsnode mn on mn.node_id = mnl.parent_id
                                     and mn.close_date is null
                left join marsnodelink mnl2 on mn.node_id = mnl2.node_id
                                           and :v_bus_org_hier_id =
                                               mnl2.hierarchy_id
                                           and mnl2.close_date is null
                                           and :v_cob_date >= mnl2.begin_cob_date
                                           and :v_cob_date < mnl2.end_cob_date
                left join marsnode mn2 on mn2.node_id = mnl2.parent_id
                                      and mn2.close_date is null
                left join marsnodelink mnl3 on mn2.node_id = mnl3.node_id
                                           and :v_bus_org_hier_id =
                                               mnl3.hierarchy_id
                                           and mnl3.close_date is null
                                           and :v_cob_date >= mnl3.begin_cob_date
                                           and :v_cob_date < mnl3.end_cob_date
                left join marsnode mn3 on mn3.node_id = mnl3.parent_id
                                      and mn3.close_date is null
                left join marsnodelink mnl4 on mn3.node_id = mnl4.node_id
                                           and :v_bus_org_hier_id =
                                               mnl4.hierarchy_id
                                           and mnl4.close_date is null
                                           and :v_cob_date >= mnl4.begin_cob_date
                                           and :v_cob_date < mnl4.end_cob_date
                left join marsnode mn4 on mn4.node_id = mnl4.parent_id
                                      and mn4.close_date is null
              --sensitivity data
                left JOIN STAGING_SENSITIVITY ss ON (ss.FEED_INSTANCE_ID =
                                                    sp.FEED_INSTANCE_ID AND
                                                    ss.FEED_ROW_ID =
                                                    sp.FEED_ROW_ID)
              --sensitivity data
                left JOIN STAGING_SENSITIVITY mtmsens ON (mtmsens.FEED_INSTANCE_ID =
                                                         sp.FEED_INSTANCE_ID AND
                                                         mtmsens.FEED_ROW_ID =
                                                         sp.FEED_ROW_ID)
                LEFT join xref_domain_value_map XREF on (XREF.Src_Value =
                                                        ss.issuer and
                                                        XREF.close_action_id is null and
                                                        XREF.Begin_Cob_Date <=
                                                        :v_cob_date and
                                                        XREF.End_Cob_Date >
                                                        :v_cob_date AND
                                                        xref.domain_map_id = 601 AND
                                                        xref.source_system_id = 307 AND xref.ISSUE_ID is not null)
                Left join ISSUE i on (i.issue_id = xref.issue_id)
                LEFT join participant PART ON (PART.PARTICIPANT_ID =
                                              XREF.TGT_VALUE and
                                              PART.Close_Action_Id is null and
                                              PART.Begin_Cob_Date <= :v_cob_date and
                                              PART.End_Cob_Date > :v_cob_date)
                left join moody_rating RATING on (rating.moody_rating_id =
                                                  i.MOODY_RATING_ID)
               where sp.feed_instance_id in
                     (select fbi.feed_instance_id
                      from   feed_book_status fbi ,
                             feed_instance fi
                      where  fbi.cob_date = :v_cob_date
                      and    fbi.feed_instance_id = fi.feed_instance_id
                      and    fi.feed_id in (
                                           select feed_id from feed_group_xref where feed_group_id in (
                                               select feed_group_id from feed_group where description like 'CDO Feeds')
                                               and close_action_id is null
                 and sp.Feed_Row_Status_Id = 1
                 and ss.sensitivity_type = 'CREDITSPREADDEFAULT'
                 and mtmsens.sensitivity_type = 'MTMVALUE'
                 and le.name='161'
                 group by le.name,
                        le.display_name,
                        mn3.display_name,
                        mn4.display_name,
                        mn.display_name,
                        i.moody_rating_id,
                        ss.issuer,
                        PART.MARS_ISSUER,
                        PART.PARTICIPANT_NAME,
                        sp.feed_instance_id,
                        part.country_domicile_id,
                        bookname.display_name) And the explain plan
    SELECT STATEMENT, GOAL = CHOOSE               Cost=19365     Cardinality=1     Bytes=731
    TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MOODY_RATING     Cost=1     Cardinality=1     Bytes=9
      INDEX UNIQUE SCAN     Object owner=MARS     Object name=PK_MOODY_RATING     Cost=0     Cardinality=1     
    HASH UNIQUE               Cost=77     Cardinality=1     Bytes=488
      COUNT STOPKEY                         
       HASH JOIN               Cost=76     Cardinality=1     Bytes=488
        NESTED LOOPS               Cost=68     Cardinality=1     Bytes=460
         HASH JOIN               Cost=66     Cardinality=1     Bytes=450
          HASH JOIN               Cost=59     Cardinality=1     Bytes=412
           NESTED LOOPS               Cost=51     Cardinality=1     Bytes=402
            HASH JOIN               Cost=49     Cardinality=1     Bytes=392
             NESTED LOOPS               Cost=42     Cardinality=1     Bytes=359
              NESTED LOOPS               Cost=40     Cardinality=1     Bytes=349
               NESTED LOOPS               Cost=37     Cardinality=1     Bytes=300
                NESTED LOOPS               Cost=34     Cardinality=1     Bytes=251
                 HASH JOIN               Cost=32     Cardinality=1     Bytes=241
                  TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=27
                   NESTED LOOPS               Cost=24     Cardinality=1     Bytes=231
                    NESTED LOOPS               Cost=21     Cardinality=1     Bytes=204
                     NESTED LOOPS               Cost=18     Cardinality=1     Bytes=171
                      NESTED LOOPS               Cost=16     Cardinality=1     Bytes=136
                       NESTED LOOPS               Cost=13     Cardinality=1     Bytes=86
                        NESTED LOOPS               Cost=10     Cardinality=1     Bytes=37
                         VIEW     Object owner=MARS          Cost=7     Cardinality=1     Bytes=10
                          FILTER                         
                           CONNECT BY WITH FILTERING                         
                            TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK               
                             INDEX RANGE SCAN     Object owner=MARS     Object name=FKI_15632_PARENT_ID     Cost=3     Cardinality=250     Bytes=2500
                              HASH JOIN               Cost=5     Cardinality=1     Bytes=62
                               TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
                               TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHYROOT     Cost=2     Cardinality=5     Bytes=175
                            NESTED LOOPS                         
                             CONNECT BY PUMP                         
                             TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK     Cost=7     Cardinality=1     Bytes=39
                              INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_MNL_HI_PI_NI     Cost=3     Cardinality=4     
                           TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
                         TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=27
                          INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
                        TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=49
                         INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
                       TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=50
                        INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
                      TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODETYPE     Cost=2     Cardinality=1     Bytes=35
                       INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODETYPE     Cost=1     Cardinality=1     
                     TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=NODE_ASSOC     Cost=3     Cardinality=1     Bytes=33
                      INDEX RANGE SCAN     Object owner=MARS     Object name=PK_NODE_ASSOC     Cost=1     Cardinality=3     
                    INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
                  VIEW     Object owner=MARS          Cost=7     Cardinality=1     Bytes=10
                   FILTER                         
                    CONNECT BY WITH FILTERING                         
                     TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK               
                      INDEX RANGE SCAN     Object owner=MARS     Object name=FKI_15632_PARENT_ID     Cost=3     Cardinality=250     Bytes=2500
                       HASH JOIN               Cost=5     Cardinality=1     Bytes=62
                        TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
                        TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHYROOT     Cost=2     Cardinality=5     Bytes=175
                     NESTED LOOPS                         
                      CONNECT BY PUMP                         
                      TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK     Cost=7     Cardinality=1     Bytes=39
                       INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_MNL_HI_PI_NI     Cost=3     Cardinality=4     
                    TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
                 INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     Bytes=10
                TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=NODE_ASSOC     Cost=3     Cardinality=1     Bytes=49
                 INDEX RANGE SCAN     Object owner=MARS     Object name=PK_NODE_ASSOC     Cost=1     Cardinality=3     
               TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=49
                INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
              INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     Bytes=10
             VIEW     Object owner=MARS          Cost=7     Cardinality=1     Bytes=33
              FILTER                         
               CONNECT BY WITH FILTERING                         
                TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK               
                 INDEX RANGE SCAN     Object owner=MARS     Object name=FKI_15632_PARENT_ID     Cost=3     Cardinality=250     Bytes=2500
                  HASH JOIN               Cost=5     Cardinality=1     Bytes=62
                   TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
                   TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHYROOT     Cost=2     Cardinality=5     Bytes=175
                NESTED LOOPS                         
                 CONNECT BY PUMP                         
                 TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK     Cost=7     Cardinality=1     Bytes=39
                  INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_MNL_HI_PI_NI     Cost=3     Cardinality=4     
               TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
            INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     Bytes=10
           VIEW     Object owner=MARS          Cost=7     Cardinality=1     Bytes=10
            FILTER                         
             CONNECT BY WITH FILTERING                         
              TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK               
               INDEX RANGE SCAN     Object owner=MARS     Object name=FKI_15632_PARENT_ID     Cost=3     Cardinality=250     Bytes=2500
                HASH JOIN               Cost=5     Cardinality=1     Bytes=62
                 TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
                 TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHYROOT     Cost=2     Cardinality=5     Bytes=175
              NESTED LOOPS                         
               CONNECT BY PUMP                         
               TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK     Cost=7     Cardinality=1     Bytes=39
                INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_MNL_HI_PI_NI     Cost=3     Cardinality=4     
             TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
          VIEW     Object owner=MARS          Cost=7     Cardinality=1     Bytes=38
           FILTER                         
            CONNECT BY WITH FILTERING                         
             TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK               
              INDEX RANGE SCAN     Object owner=MARS     Object name=FKI_15632_PARENT_ID     Cost=3     Cardinality=250     Bytes=2500
               HASH JOIN               Cost=5     Cardinality=1     Bytes=62
                TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
                TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHYROOT     Cost=2     Cardinality=5     Bytes=175
             NESTED LOOPS                         
              CONNECT BY PUMP                         
              TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK     Cost=7     Cardinality=1     Bytes=57
               INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_MNL_HI_PI_NI     Cost=3     Cardinality=4     
            TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=36
         INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     Bytes=10
        VIEW     Object owner=MARS          Cost=7     Cardinality=1     Bytes=28
         FILTER                         
          CONNECT BY WITH FILTERING                         
           TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK               
            INDEX RANGE SCAN     Object owner=MARS     Object name=FKI_15632_PARENT_ID     Cost=3     Cardinality=250     Bytes=2500
             HASH JOIN               Cost=5     Cardinality=1     Bytes=62
              TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
              TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHYROOT     Cost=2     Cardinality=5     Bytes=175
           NESTED LOOPS                         
            CONNECT BY PUMP                         
            TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK     Cost=7     Cardinality=1     Bytes=57
             INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_MNL_HI_PI_NI     Cost=3     Cardinality=4     
          TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
    COUNT                         
      VIEW     Object owner=MARS          Cost=19365     Cardinality=1     Bytes=731
       HASH GROUP BY               Cost=19365     Cardinality=1     Bytes=1112
        NESTED LOOPS OUTER               Cost=19364     Cardinality=1     Bytes=1112
         NESTED LOOPS OUTER               Cost=19361     Cardinality=1     Bytes=1040
          NESTED LOOPS OUTER               Cost=19361     Cardinality=1     Bytes=1037
           NESTED LOOPS OUTER               Cost=19360     Cardinality=1     Bytes=1019
            NESTED LOOPS OUTER               Cost=19357     Cardinality=1     Bytes=951
             NESTED LOOPS OUTER               Cost=19354     Cardinality=1     Bytes=914
              NESTED LOOPS OUTER               Cost=19351     Cardinality=1     Bytes=877
               NESTED LOOPS OUTER               Cost=19337     Cardinality=1     Bytes=820
                NESTED LOOPS OUTER               Cost=19334     Cardinality=1     Bytes=783
                 NESTED LOOPS OUTER               Cost=19320     Cardinality=1     Bytes=726
                  NESTED LOOPS OUTER               Cost=19317     Cardinality=1     Bytes=707
                   NESTED LOOPS OUTER               Cost=19303     Cardinality=1     Bytes=650
                    NESTED LOOPS OUTER               Cost=19300     Cardinality=1     Bytes=613
                     NESTED LOOPS               Cost=19285     Cardinality=1     Bytes=556
                      NESTED LOOPS               Cost=19280     Cardinality=1     Bytes=443
                       NESTED LOOPS OUTER               Cost=19275     Cardinality=1     Bytes=330
                        HASH JOIN RIGHT SEMI               Cost=17457     Cardinality=1     Bytes=248
                         VIEW     Object owner=SYS     Object name=VW_NSO_1     Cost=1119     Cardinality=30     Bytes=150
                          HASH JOIN               Cost=1119     Cardinality=30     Bytes=2040
                           TABLE ACCESS FULL     Object owner=MARS     Object name=FEED_GROUP     Cost=2     Cardinality=5     Bytes=120
                           HASH JOIN               Cost=1116     Cardinality=1607     Bytes=70708
                            TABLE ACCESS FULL     Object owner=MARS     Object name=FEED_GROUP_XREF     Cost=13     Cardinality=701     Bytes=14721
                            HASH JOIN               Cost=1102     Cardinality=3602     Bytes=82846
                             INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_FBS_CD_FII_BI     Cost=22     Cardinality=3602     Bytes=46826
                             TABLE ACCESS FULL     Object owner=MARS     Object name=FEED_INSTANCE     Cost=1024     Cardinality=670264     Bytes=6702640
                         NESTED LOOPS               Cost=16337     Cardinality=324     Bytes=78732
                          HASH JOIN               Cost=14324     Cardinality=1977     Bytes=302481
                           NESTED LOOPS OUTER               Cost=11     Cardinality=1     Bytes=114
                            NESTED LOOPS               Cost=8     Cardinality=1     Bytes=95
                             TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=5     Cardinality=1     Bytes=59
                              INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_NODE1     Cost=3     Cardinality=2     
                             TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=BOOK     Cost=3     Cardinality=2     Bytes=72
                              INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_BOOK_LEI_BCD     Cost=2     Cardinality=4     
                            TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=19
                             INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
                           PARTITION RANGE ALL               Cost=13995     Cardinality=3854299     Bytes=150317661
                            TABLE ACCESS FULL     Object owner=MARS     Object name=POSITION     Cost=13995     Cardinality=3854299     Bytes=150317661
                          PARTITION RANGE ITERATOR               Cost=2     Cardinality=1     Bytes=90
                           PARTITION HASH ITERATOR               Cost=2     Cardinality=1     Bytes=90
                            TABLE ACCESS BY LOCAL INDEX ROWID     Object owner=MARS     Object name=STAGING_POSITION     Cost=2     Cardinality=1     Bytes=90
                             INDEX UNIQUE SCAN     Object owner=MARS     Object name=PK_STAGINGPOSITON     Cost=1     Cardinality=1     
                        PARTITION HASH ITERATOR               Cost=1819     Cardinality=1     Bytes=82
                         TABLE ACCESS BY LOCAL INDEX ROWID     Object owner=MARS     Object name=STAGING_INSTRUMENT     Cost=1819     Cardinality=1     Bytes=82
                          INDEX RANGE SCAN     Object owner=MARS     Object name=PK_STAGINGINSTRUMENT     Cost=9     Cardinality=2551     
                       PARTITION RANGE ITERATOR               Cost=5     Cardinality=1     Bytes=113
                        PARTITION HASH ITERATOR               Cost=5     Cardinality=1     Bytes=113
                         TABLE ACCESS BY LOCAL INDEX ROWID     Object owner=MARS     Object name=STAGING_SENSITIVITY     Cost=5     Cardinality=1     Bytes=113
                          INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_SENSITIVITY_FEED_ROW_ID     Cost=3     Cardinality=8     
                      PARTITION RANGE ITERATOR               Cost=5     Cardinality=1     Bytes=113
                       PARTITION HASH ITERATOR               Cost=5     Cardinality=1     Bytes=113
                        TABLE ACCESS BY LOCAL INDEX ROWID     Object owner=MARS     Object name=STAGING_SENSITIVITY     Cost=5     Cardinality=1     Bytes=113
                         INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_SENSITIVITY_FEED_ROW_ID     Cost=3     Cardinality=8     
                     TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK     Cost=14     Cardinality=1     Bytes=57
                      INDEX RANGE SCAN     Object owner=MARS     Object name=FKI_15632_NODE_ID     Cost=2     Cardinality=14     
                    TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=37
                     INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
                   TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK     Cost=14     Cardinality=1     Bytes=57
                    INDEX RANGE SCAN     Object owner=MARS     Object name=FKI_15632_NODE_ID     Cost=2     Cardinality=14     
                  TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=19
                   INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
                 TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK     Cost=14     Cardinality=1     Bytes=57
                  INDEX RANGE SCAN     Object owner=MARS     Object name=FKI_15632_NODE_ID     Cost=2     Cardinality=14     
                TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=37
                 INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
               TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK     Cost=14     Cardinality=1     Bytes=57
                INDEX RANGE SCAN     Object owner=MARS     Object name=FKI_15632_NODE_ID     Cost=2     Cardinality=14     
              TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=37
               INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
             TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=37
              INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
            TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=XREF_DOMAIN_VALUE_MAP     Cost=3     Cardinality=1     Bytes=68
             INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_XDVM_DMI_SV_BCD     Cost=2     Cardinality=1     
           TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=ISSUE     Cost=1     Cardinality=1     Bytes=18
            INDEX UNIQUE SCAN     Object owner=MARS     Object name=PK_ISSUE     Cost=0     Cardinality=1     
          INDEX UNIQUE SCAN     Object owner=MARS     Object name=PK_MOODY_RATING     Cost=0     Cardinality=1     Bytes=3
         TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=PARTICIPANT     Cost=3     Cardinality=1     Bytes=72
          INDEX RANGE SCAN     Object owner=MARS     Object name=PK_PARTICIPANT     Cost=2     Cardinality=1     

    Hi,
    in your explain plan:
    HASH JOIN RIGHT SEMI               Cost=17457     Cardinality=1     Bytes=248
    VIEW     Object owner=SYS     Object name=VW_NSO_1     Cost=1119     Cardinality=30     Bytes=150
    HASH JOIN               Cost=1119     Cardinality=30     Bytes=2040
    TABLE ACCESS FULL     Object owner=MARS     Object name=FEED_GROUP     Cost=2     Cardinality=5     Bytes=120
    HASH JOIN               Cost=1116     Cardinality=1607     Bytes=70708
    TABLE ACCESS FULL     Object owner=MARS     Object name=FEED_GROUP_XREF     Cost=13     Cardinality=701     Bytes=14721
    HASH JOIN               Cost=1102     Cardinality=3602     Bytes=82846
    INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_FBS_CD_FII_BI     Cost=22     Cardinality=3602     Bytes=46826
    TABLE ACCESS FULL     Object owner=MARS     Object name=FEED_INSTANCEThis part has the highest costs (this doesn't always mean it is slow). So this leads me to the WHERE clause where feed_group, feed_group_xref and feed_instance full are used. Maybe this can be improved, although the cardinality is not that high, so a full table can be the best. So the question is can indexes help here?
    Furthermore there is the full table scan on POSITION:
    TABLE ACCESS FULL     Object owner=MARS     Object name=POSITION     Cost=13995     Cardinality=3854299     Bytes=150317661This looks also a large tabel (3 million + records), so is it possible to get this part smaller?
    Herald ten Dam
    http://htendam.wordpress.com

  • Stopping a Query taking more time to execute in runtime in Oracle Forms.

    Hi,
    In the present application one of the oracle form screen is taking long time to execute a query, user wanted an option to stop the query in between and browse the result (whatever has been fetched before stopping the query).
    We have tried three approach.
    1. set max fetch record in form and block level.
    2. set max fetch time in form and block level.
    in above two method does not provide the appropiate solution for us.
    3. the third approach we applied is setting the interaction mode to "NON BLOCKING" at the form level.
    It seems to be worked, while the query took long time to execute, oracle app server prompts an message to press Esc to cancel the query and it a displaying the results fetched upto that point.
    But the drawback is one pressing esc, its killing the session itself. which is causing the entire application to collapse.
    Please suggest if there is any alternative approach for this or how to overcome this perticular scenario.
    This kind of facility is alreday present in TOAD and PL/SQL developer where we can stop an executing query and browse the results fetched upto that point, is the similar facility is avialable in oracle forms ,please suggest.
    Thanks and Regards,
    Suraj
    Edited by: user10673131 on Jun 25, 2009 4:55 AM

    Hello Friend,
    You query will definitely take more time or even fail in PROD,becuase the way it is written. Here are my few observations, may be it can help :-
    1. XLA_AR_INV_AEL_SL_V XLA_AEL_SL_V : Never use a view inside such a long query , becuase View is just a window to the records.
    and when used to join other table records, then all those tables which are used to create a view also becomes part of joining conition.
    First of all please check if you really need this view. I guess you are using to check if the records have been created as Journal entries or not ?
    Please check the possbility of finding it through other AR tables.
    2. Remove _ALL tables instead use the corresponding org specific views (if you are in 11i ) or the sysnonymns ( in R12 )
    For example : For ra_cust_trx_types_all use ra_cust_trx_types.
    This will ensure that the query will execute only for those ORG_IDs which are assigned to that responsibility.
    3. Check with the DBA whether the GATHER SCHEMA STATS have been run atleast for ONT and RA tables.
    You can also check the same using
    SELECT LAST_ANALYZED FROM ALL_TABLES WHERE TABLE_NAME = 'ra_customer_trx_all'.
    If the tables are not analyzed , the CBO will not be able to tune your query.
    4. Try to remove the DISTINCT keyword. This is the MAJOR reason for this problem.
    5. If its a report , try to separate the logic in separate queries ( using a procedure ) and then populate the whole data in custom table, and use this custom table for generating the
    report.
    Thanks,
    Neeraj Shrivastava
    [email protected]
    Edited by: user9352949 on Oct 1, 2010 8:02 PM
    Edited by: user9352949 on Oct 1, 2010 8:03 PM

  • Linked Server - Getting Error when performing Cross Instance Query with joins

    Hi Guys,
    I've successfully created a Linked Server that connects a local DB Engine with another DB Engine through an ip over an extranet. I am able to run simple Select statement queries on the Local DB
    Engine and get results from the linked server. However when attempting to perform more complex queries that join tables from
    the linked server with tables from the local DB server, I get the following error message after several minutes of execution:
    OLE DB provider "SQLNCLI11" for linked server "<ip of Linked Server>" returned message "Protocol error in TDS stream".
    OLE DB provider "SQLNCLI11" for linked server "<ip of Linked Server>"
    returned message "Communication link failure".
    Msg -1, Level 16, State 1, Line 0
    Session Provider: Physical connection is not usable [xFFFFFFFF].
    OLE DB provider "SQLNCLI11" for linked server "<ip of Linked Server>"
    returned message "Communication link failure".
    Msg -1, Level 16, State 1, Line 0
    Session Provider: Physical connection is not usable [xFFFFFFFF].
    OLE DB provider "SQLNCLI11" for linked server "<ip of Linked Server>"
    returned message "Communication link failure".
    Msg 10054, Level 16, State 1, Line 0
    TCP Provider: An existing connection was forcibly closed by the remote host.
    Grateful if you could advise what may be causing this issue and how I can resolve it. I've read on Distributed Transactions but I understand that it only applies to manipulation statements?
    Both are SQL servers. Linked Server is SQL2008R2 if not mistaken. Local DB Engine is SQL2014.
    Thanks and Regards,
    Rhyan.

    Thank you for your insight Erland. Can you advise how I can check the SQL Server errorlog pls?
    I just got word from a user that the query ran successfully this morning but took 15 mins to complete.. does it ring a bell to you in terms of issues that may be causing this?
    This kind of behaviour would suggest something makes the query "time out" or stop abruptly.. How can I further investigate it pls? Can a BEGIN DISTRIBUTED TRANSACTION  statement in the query help me mitigate or resolve the error? ref: https://msdn.microsoft.com/en-us/library/ms188386.aspx?f=255&MSPPError=-2147217396
    SQL Version for Remote Server is : 
    Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64) Oct 19 2012 13:38:57 Copyright
    (c) Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.2 <X64> (Build 9200: ) (Hypervisor)
    SQL Version for Local Server is:
    Microsoft SQL Server 2014 - 12.0.2000.8 (X64) Feb 20 2014 20:04:26 Copyright
    (c) Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: ) (Hypervisor)
    Thanks and Regards,
    Rhyan

  • Select query running long time

    Hi,
    DB version : 10g
    platform : sunos
    My select sql query running long time (more than 20hrs) .Still running .
    Is there any way to find sql query completion time approximately. (Pending time)
    Also is there any possibilities to increase the speed of sql query (already running) like adding hints.
    Please help me on this .
    Thanks

    Hi Sathish thanks for your reply,
    I have already checked in V$SESSION_LONGOPS .But it's showing TIME_REMAINING -->0
    select TOTALWORK,SOFAR,START_TIME,TIME_REMAINING from V$SESSION_LONGOPS where SID='10'
    TOTALWORK      SOFAR START_TIME      TIME_REMAINING
         1099759    1099759 27-JAN-11                    0Any idea ?
    Thanks.

  • Select Query Takes more time

    Hi All,
    I have cloned KSB1 tcode to custom one as required by business.
    Below query takes more time than excepted.
    Here V_DB_TABLE = COVP.
    Values in Where clause are as follows
    OBNJR in ( KSBB010000001224  BT  KSBB012157221571)
    GJAHR in blank
    VERSN in '000'
    WRTTP in '04' and '11'
    all others are blank
    VT_VAR_COND = ( CPUDT BETWEEN '20091201' and '20091208' )
    SELECT (VT_FIELDS) INTO CORRESPONDING FIELDS OF GS_COVP_EXT      
                        FROM (V_DB_TABLE)                             
                        WHERE LEDNR = '00'                            
                        AND   OBJNR IN LR_OBJNR                       
                        AND   GJAHR IN GR_GJAHR                       
                        AND   VERSN IN GR_VERSN                       
                        AND   WRTTP IN GR_WRTTP                       
                        AND   KSTAR IN LR_KSTAR                       
                        AND   PERIO IN GR_PERIO                       
                        AND   BUDAT IN GR_BUDAT                       
                        AND   PAROB IN GR_PAROB                       
                        AND   (VT_VAR_COND).    
    Checked in table for this condition it has only 92 entries.
    But when i execute program takes long time as 3 Hrs.
    Could any one help me on this

    >1.Dont use SELECT/ENDSELECT instead use INTO TABLE addition .
    > 2.Avoid using corresponding addition.create a type and reference it.
    > If the select is going for dump beacause of storage limitations ,then use Cursors.
    you got three large NOs .... all three recommendations are wrong!
    The SE16 test is going in the right direction ... but what was filled. Nobody knows!!!!
    Select options:
    Did you ever try to trace the SE16?  The generic statement has for every field an in-condition!
    Without the information what was actually filled, nobody can say something there
    are at least 2**n  combinations possible!
    Use ST05 for SE16 and check actual statement plus explain!

  • Query taking long time for EXTRACTING the data more than 24 hours

    Hi ,
    Query taking long time for EXTRACTING the data more than 24 hours please find the query and explain plan details below even indexes avilable on table's goe's to FULL TABLE SCAN. please suggest me.......
    SQL> explain plan for select a.account_id,round(a.account_balance,2) account_balance,
    2 nvl(ah.invoice_id,ah.adjustment_id) transaction_id,
    to_char(ah.effective_start_date,'DD-MON-YYYY') transaction_date,
    to_char(nvl(i.payment_due_date,
    to_date('30-12-9999','dd-mm-yyyy')),'DD-MON-YYYY')
    due_date, ah.current_balance-ah.previous_balance amount,
    decode(ah.invoice_id,null,'A','I') transaction_type
    3 4 5 6 7 8 from account a,account_history ah,invoice i_+
    where a.account_id=ah.account_id
    and a.account_type_id=1000002
    and round(a.account_balance,2) > 0
    and (ah.invoice_id is not null or ah.adjustment_id is not null)
    and ah.CURRENT_BALANCE > ah.previous_balance
    and ah.invoice_id=i.invoice_id(+)
    AND a.account_balance > 0
    order by a.account_id,ah.effective_start_date desc; 9 10 11 12 13 14 15 16
    Explained.
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)|
    | 0 | SELECT STATEMENT | | 544K| 30M| | 693K (20)|
    | 1 | SORT ORDER BY | | 544K| 30M| 75M| 693K (20)|
    |* 2 | HASH JOIN | | 544K| 30M| | 689K (20)|
    |* 3 | TABLE ACCESS FULL | ACCOUNT | 20080 | 294K| | 6220 (18)|
    |* 4 | HASH JOIN OUTER | | 131M| 5532M| 5155M| 678K (20)|
    |* 5 | TABLE ACCESS FULL| ACCOUNT_HISTORY | 131M| 3646M| | 197K (25)|
    | 6 | TABLE ACCESS FULL| INVOICE | 262M| 3758M| | 306K (18)|
    Predicate Information (identified by operation id):
    2 - access("A"."ACCOUNT_ID"="AH"."ACCOUNT_ID")
    3 - filter("A"."ACCOUNT_TYPE_ID"=1000002 AND "A"."ACCOUNT_BALANCE">0 AND
    ROUND("A"."ACCOUNT_BALANCE",2)>0)
    4 - access("AH"."INVOICE_ID"="I"."INVOICE_ID"(+))
    5 - filter("AH"."CURRENT_BALANCE">"AH"."PREVIOUS_BALANCE" AND ("AH"."INVOICE_ID"
    IS NOT NULL OR "AH"."ADJUSTMENT_ID" IS NOT NULL))
    22 rows selected.
    Index Details:+_
    SQL> select INDEX_OWNER,INDEX_NAME,COLUMN_NAME,TABLE_NAME from dba_ind_columns where
    2 table_name in ('INVOICE','ACCOUNT','ACCOUNT_HISTORY') order by 4;
    INDEX_OWNER INDEX_NAME COLUMN_NAME TABLE_NAME
    OPS$SVM_SRV4 P_ACCOUNT ACCOUNT_ID ACCOUNT
    OPS$SVM_SRV4 U_ACCOUNT_NAME ACCOUNT_NAME ACCOUNT
    OPS$SVM_SRV4 U_ACCOUNT CUSTOMER_NODE_ID ACCOUNT
    OPS$SVM_SRV4 U_ACCOUNT ACCOUNT_TYPE_ID ACCOUNT
    OPS$SVM_SRV4 I_ACCOUNT_ACCOUNT_TYPE ACCOUNT_TYPE_ID ACCOUNT
    OPS$SVM_SRV4 I_ACCOUNT_INVOICE INVOICE_ID ACCOUNT
    OPS$SVM_SRV4 I_ACCOUNT_PREVIOUS_INVOICE PREVIOUS_INVOICE_ID ACCOUNT
    OPS$SVM_SRV4 U_ACCOUNT_NAME_ID ACCOUNT_NAME ACCOUNT
    OPS$SVM_SRV4 U_ACCOUNT_NAME_ID ACCOUNT_ID ACCOUNT
    OPS$SVM_SRV4 I_LAST_MODIFIED_ACCOUNT LAST_MODIFIED ACCOUNT
    OPS$SVM_SRV4 I_ACCOUNT_INVOICE_ACCOUNT INVOICE_ACCOUNT_ID ACCOUNT
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ACCOUNT ACCOUNT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ACCOUNT SEQNR ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_INVOICE INVOICE_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ADINV INVOICE_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_CIA CURRENT_BALANCE ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_CIA INVOICE_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_CIA ADJUSTMENT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_CIA ACCOUNT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_LMOD LAST_MODIFIED ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ADINV ADJUSTMENT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_PAYMENT PAYMENT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ADJUSTMENT ADJUSTMENT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_APPLIED_DT APPLIED_DATE ACCOUNT_HISTORY
    OPS$SVM_SRV4 P_INVOICE INVOICE_ID INVOICE
    OPS$SVM_SRV4 U_INVOICE CUSTOMER_INVOICE_STR INVOICE
    OPS$SVM_SRV4 I_LAST_MODIFIED_INVOICE LAST_MODIFIED INVOICE
    OPS$SVM_SRV4 U_INVOICE_ACCOUNT ACCOUNT_ID INVOICE
    OPS$SVM_SRV4 U_INVOICE_ACCOUNT BILL_RUN_ID INVOICE
    OPS$SVM_SRV4 I_INVOICE_BILL_RUN BILL_RUN_ID INVOICE
    OPS$SVM_SRV4 I_INVOICE_INVOICE_TYPE INVOICE_TYPE_ID INVOICE
    OPS$SVM_SRV4 I_INVOICE_CUSTOMER_NODE CUSTOMER_NODE_ID INVOICE
    32 rows selected.
    Regards,
    Bathula
    Oracle-DBA

    I have some suggestions. But first, you realize that you have some redundant indexes, right? You have an index on account(account_name) and also account(account_name, account_id), and also account_history(invoice_id) and account_history(invoice_id, adjustment_id). No matter, I will suggest some new composite indexes.
    Also, you do not need two lines for these conditions:
    and round(a.account_balance, 2) > 0
    AND a.account_balance > 0
    You can just use: and a.account_balance >= 0.005
    So the formatted query isselect a.account_id,
           round(a.account_balance, 2) account_balance,
           nvl(ah.invoice_id, ah.adjustment_id) transaction_id,
           to_char(ah.effective_start_date, 'DD-MON-YYYY') transaction_date,
           to_char(nvl(i.payment_due_date, to_date('30-12-9999', 'dd-mm-yyyy')),
                   'DD-MON-YYYY') due_date,
           ah.current_balance - ah.previous_balance amount,
           decode(ah.invoice_id, null, 'A', 'I') transaction_type
      from account a, account_history ah, invoice i
    where a.account_id = ah.account_id
       and a.account_type_id = 1000002
       and (ah.invoice_id is not null or ah.adjustment_id is not null)
       and ah.CURRENT_BALANCE > ah.previous_balance
       and ah.invoice_id = i.invoice_id(+)
       AND a.account_balance >= .005
    order by a.account_id, ah.effective_start_date desc;You will probably want to select:
    1. From ACCOUNT first (your smaller table), for which you supply a literal on account_type_id. That should limit the accounts retrieved from ACCOUNT_HISTORY
    2. From ACCOUNT_HISTORY. We want to limit the records as much as possible on this table because of the outer join.
    3. INVOICE we want to access last because it seems to be least restricted, it is the biggest, and it has the outer join condition so it will manufacture rows to match as many rows as come back from account_history.
    Try the query above after creating the following composite indexes. The order of the columns is important:create index account_composite_i on account(account_type_id, account_balance, account_id);
    create index acct_history_comp_i on account_history(account_id, invoice_id, adjustment_id, current_balance, previous_balance, effective_start_date);
    create index invoice_composite_i on invoice(invoice_id, payment_due_date);All the columns used in the where clause will be indexed, in a logical order suited to the needs of the query. Plus each selected column is indexed as well so that we should not need to touch the tables at all to satisfy the query.
    Try the query after creating these indexes.
    A final suggestion is to try larger sort and hash area sizes and a manual workarea policy.alter session set workarea_size_policy = manual;
    alter session set sort_area_size = 2147483647;
    alter session set hash_area_size = 2147483647;

  • How to build a query to join on two tables without mapping

    I did Automatic mapping by the workbench Directofield mapping with the table and java object.
    Wanted to build a simple join query by joining on the same field on both the tables.Not the sql query through the toplink using expression builder.
    Please help.............
    Spent one full day for this................

    Thanks Don for the reply,sorry to bug you,but i need help.....
    SELECT A.AGNCY_C,
         A.TYPE_C,
         A.RESN_C,
         A.S_TYPE_C,
         A.SUB_ID_C,
         A.RY_C
    FROM RATING A, REF B
    WHERE A.ID_C = B._ID_C
    AND A.ALPHA_C = B.ALPHA_C
    AND A.EFF_D >= B.MATURITY_D
    This is the real query i was talking about.I did mapping automatically through the workbench,generated java classes also throught the workbench.
    Now they don't want to execute the raw sql.They wanted to get all the RATING objects with the where condition.
    So how to build a query by using toplink.
    tried your example
    ExpressionBuilder builder = new ExpressionBuilder();
    Expression creditRating = builder.getTable("RATING").getField("ID_C");
    Expression issue_ref = builder.getTable("REF").getField("ID_C");
    Expression join = creditRating.equal(issue_ref);
    I am getting java.lang.OutOfMemoryError
    error.
    I selected the option generate classes and descriptors
    from the tables (RATING,REF).,so it created the classes and dscriptors automatically.
    In Database script for the table RATING like this
    ALTER TABLE RATING ADD (
    CONSTRAINT RATING_F1 FOREIGN KEY (ID_C, ALPHA_C)
    REFERENCES REF (ID_C,ALPHA_C));
    I think when i generate descriptor automatically it is keeping this association.
    Please help me.........

  • F4 help for Time field in webdynpro abap

    Hi Guru's,
    how to get f4 help for time field in webdynpro abap.
    thanks in advance,
    narendra

    Hi Narendra,
    Check this link:
    Re: Time Search Help
    Also few more links here:
    http://forumsa.sdn.sap.com/search.jspa?forumID=249&threadID=&q=time+help&objID=f249&dateRange=lastyear&numResults=15&rankBy=10001
    Also check if this example helps you: WDR_TEST_HELP
    If your query is not yet answered then its advisable to post in webdynpro for abap (Web Dynpro ABAP). You may get some quick repliy.
    Regards,
    Swarna Munukoti.

  • Query to join 2 tables by interval of value

    Hi all
    I need your help in creating a query to join 2 tables by interval of values.
    The thing i want to d ois like this: i have 2 tables the first one containing list of serial number and the secon is containing interval of serial number (startnumber and end number) and other information like the user creating the serial number.
    I want to list all serial numbers from the first table and the user creating each serial number from the second one if the serial number is between each interval of the second table.
    here is an example>
    SQL> create table test1 (code varchar2(1), serial number);
    Table created.
    SQL> create table test2 (requester varchar2(10),startno number, endno number);
    Table created.
    SQL> insert into test1 values('A',1);
    1 row created.
    SQL> insert into test1 values('B',3);
    1 row created.
    SQL> insert into test1 values('C',8);
    1 row created.
    SQL> insert into test1 values('D',12);
    1 row created.
    SQL> insert into test1 values('E',20);
    1 row created.
    SQL> commit;
    Commit complete.
    SQL> insert into test2 values('TATA',1,5);
    1 row created.
    SQL> insert into test2 values('TOTO',6,10);
    1 row created.
    SQL> commit;
    Commit complete.
    The result i want to get are:
    TESt1.CODE     TEST2.REQUESTER
    A          TATA
    B          TATA
    C          TOTO
    D          null
    E          null

    Use outer join:
    select  code,
            requester
      from  test1,
            test2
      where serial between startno(+) and endno(+)
      order by code
    C REQUESTER
    A TATA
    B TATA
    C TOTO
    D
    E
    SQL> SY.

  • Need complex query  with joins and AGGREGATE  functions.

    Hello Everyone ;
    Good Morning to all ;
    I have 3 tables with 2 lakhs record. I need to check query performance.. How CBO rewrites my query in materialized view ?
    I want to make complex join with AGGREGATE FUNCTION.
    my table details
    SQL> select from tab;*
    TNAME TABTYPE CLUSTERID
    DEPT TABLE
    PAYROLL TABLE
    EMP TABLE
    SQL> desc emp
    Name
    EID
    ENAME
    EDOB
    EGENDER
    EQUAL
    EGRADUATION
    EDESIGNATION
    ELEVEL
    EDOMAIN_ID
    EMOB_NO
    SQL> desc dept
    Name
    EID
    DNAME
    DMANAGER
    DCONTACT_NO
    DPROJ_NAME
    SQL> desc payroll
    Name
    EID
    PF_NO
    SAL_ACC_NO
    SALARY
    BONUS
    I want to make  complex query  with joins and AGGREGATE  functions.
    Dept names are : IT , ITES , Accounts , Mgmt , Hr
    GRADUATIONS are : Engineering , Arts , Accounts , business_applications
    I want to select records who are working in IT and ITES and graduation should be "Engineering"
    salary > 20000 and < = 22800 and bonus > 1000 and <= 1999 with count for males and females Separately ;
    Please help me to make a such complex query with joins ..
    Thanks in advance ..
    Edited by: 969352 on May 25, 2013 11:34 AM

    969352 wrote:
    why do you avoid providing requested & NEEDED details?I do NOT understand what do you expect ?
    My Goal is :
    1. When executing my own query i need to check expalin plan.please proceed to do so
    http://docs.oracle.com/cd/E11882_01/server.112/e26088/statements_9010.htm#SQLRF01601
    2. IF i enable query rewrite option .. i want to check explain plan ( how optimizer rewrites my query ) ? please proceed to do so
    http://docs.oracle.com/cd/E11882_01/server.112/e16638/ex_plan.htm#PFGRF009
    3. My only aim is QUERY PERFORMANCE with QUERY REWRITE clause in materialized view.It is an admirable goal.
    Best Wishes on your quest for performance improvements.

  • Is index range scan the reason for query running long time

    I would like to know whether index range scan is the reason for the query running long time. Below is the explain plan. If so, how to optimise it? Please help
    Operation     Object     COST     CARDINALITY     BYTES
    SELECT STATEMENT ()          413     1000     265000
    COUNT (STOPKEY)                    
    FILTER ()                    
    TABLE ACCESS (BY INDEX ROWID)     ORDERS     413     58720     15560800
    INDEX (RANGE SCAN)     IDX_SERV_PROV_ID     13     411709     
    TABLE ACCESS (BY INDEX ROWID)     ADDRESSES     2     1     14
    INDEX (UNIQUE SCAN)     SYS_C004605     1     1     
    TABLE ACCESS (BY INDEX ROWID)     ADDRESSES     2     1     14
    INDEX (UNIQUE SCAN)     SYS_C004605     1     1     
    TABLE ACCESS (BY INDEX ROWID)     ADDRESSES     2     1     14
    INDEX (UNIQUE SCAN)     SYS_C004605     1     1

    The index range scan means that the optimiser has determined that it is better to read the index rather than perform a full table scan. So in answer to your question - quite possibly but the alternative might take even longer!
    The best thing to do is to review your query and check that you need every table included in the query and that you are accessing the tables via the best route. For example if you can access a table via primary key index that would be better than using a non-unique index. But the best way of reducing the time the query takes to run is to give it less tables (and indexes) to read.
    John Seaman
    http://www.asktheoracle.net

  • SQL Query taking longer time as seen from Trace file

    Below Query Execution timings:
    Any help will be benefitial as its affecting business needs.
    SELECT MATERIAL_DETAIL_ID
    FROM
    GME_MATERIAL_DETAILS WHERE BATCH_ID = :B1 FOR UPDATE OF ACTUAL_QTY NOWAIT
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.70 0 0 0 0
    Execute 2256 8100.00 24033.51 627 12298 31739 0
    Fetch 2256 900.00 949.82 0 12187 0 30547
    total 4513 9000.00 24984.03 627 24485 31739 30547
    Thanks and Regards

    Thanks Buddy.
    Data Collected from Trace file:
    SELECT STEP_CLOSE_DATE
    FROM
    GME_BATCH_STEPS WHERE BATCH_ID
    IN (SELECT
    DISTINCT BATCH_ID FROM
    GME_MATERIAL_DETAILS START WITH BATCH_ID = :B2 CONNECT BY PRIOR PHANTOM_ID=BATCH_ID)
    AND NVL(STEP_CLOSE_DATE, :B1) > :B1
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.54 0 0 0 0
    Execute 2256 800.00 1120.32 0 0 0 0
    Fetch 2256 9100.00 13551.45 396 77718 0 0
    total 4513 9900.00 14672.31 396 77718 0 0
    Misses in library cache during parse: 0
    Optimizer goal: CHOOSE
    Parsing user id: 66 (recursive depth: 1)
    Rows Row Source Operation
    0 TABLE ACCESS BY INDEX ROWID GME_BATCH_STEPS
    13160 NESTED LOOPS
    6518 VIEW
    6518 SORT UNIQUE
    53736 CONNECT BY WITH FILTERING
    30547 NESTED LOOPS
    30547 INDEX RANGE SCAN GME_MATERIAL_DETAILS_U1 (object id 146151)
    30547 TABLE ACCESS BY USER ROWID GME_MATERIAL_DETAILS
    23189 NESTED LOOPS
    53736 BUFFER SORT
    53736 CONNECT BY PUMP
    23189 TABLE ACCESS BY INDEX ROWID GME_MATERIAL_DETAILS
    23189 INDEX RANGE SCAN GME_MATERIAL_DETAILS_U1 (object id 146151)
    4386 INDEX RANGE SCAN GME_BATCH_STEPS_U1 (object id 146144)
    In the Package there are lots of SQL Statements using CONNECT BY CLAUSE.
    Does the use of CONNECT BY Clause degrades performance?
    As you can see the Rows Section is 0 but the Query and elapsed time is taking longer
    Regards

Maybe you are looking for