Performance - direct joins vs joining datasets

Which is better way to build query and which would give better performance
select * from A, B
where A.id=B.id
or select * from
(select * from A), (select * from B)
join on A.id =B.id
Essentially, join directly on tables or get results and join the datasets. This might too simplistic a example above

Hi,
927740 wrote:
Which is better way to build query and which would give better performance
select * from A, B
where A.id=B.idThat's the best way to do it.
or select * from
(select * from A), (select * from B)
join on A.id =B.idThis won't work. Table A is only in scope in the first (unnamed) in-line view, and B is only in scope in the second (unnamed) in-line view, so neither can be refererenced in the main query. You would need to give table aliases to the in-line views if you need to reference a column name (like id) that exists in both.
Essentially, join directly on tables or get results and join the datasets. This might too simplistic a example aboveJoin the tables directly when you have a choice.
There's no point in using
FROM    (SELECT * FROM a)rather than just
FROM    aIf there is a difference in performance, the simpler way will probably be faster, but the optimizer will probably use the same plan either way. The more complicate way will just confuse whoever has to debug and maintain the code.

Similar Messages

  • Performance for join 9 custom table with native SQL ?

    Hi Expert,
    I need your opinion regarding performance to join 9 tables with native sql. Recently i have to tunning some customize extraction cost  report. This report extract about 10 million cost of material everyday.
    The current program actually, try to populate the condition data and insert into customize table and join all the table to get data using native sql.
    SELECT /*+ ordered use_hash(mst,pg,rg,ps,rs,dpg,drg,dps,drs) */
                mst.werks, ....................................
    FROM
                sapsr3.zab_info mst,
                sapsr3.zab_pc pg,
                sapsr3.zab_rc rg,
                sapsr3.zab_pc ps,
                sapsr3.zab_rc rs,
                sapsr3.zab_g_pc dpg,
                sapsr3.zab_g_rc drg,
                sapsr3.zab_s_pc dps,
                sapsr3.zab_s_rc drs
            WHERE mst.zseq_no = :p_rep_run_id
            AND mst.werks = :p_werks
            AND mst.mandt = rg.mandt(+)
            AND mst.ekorg = rg.ekorg(+)
            AND mst.lifnr = rg.lifnr(+)
            AND mst.matnr = rg.matnr(+)
            ...............................................   unitl all table (9 tables)
            AND ps.mandt = dps.mandt(+)
            AND ps.knumh = dps.knumh(+)
            AND ps.zseq_no = dps.zseq_no(+)
            AND COALESCE (dps.kbetr, drs.kbetr, dpg.kbetr, drg.kbetr) <> 0
    It seems the query ask for database to using hashed table. would that be it will burden the database ? and impacted to others sap process ?
    Please advise
    Thank You and Best Regards

    you can only argue coming from measurements and that is not the case.
    Coming from the code, I see only that you do not understand it at all, so better leave it as it is. It is not a hash table, but a hash join on these table.

  • OAM11g - How to perform direct login without accessing protected resource?

    Hi,
    I think this should be a common requirement as website needs to provide a direct login page.
    The OAM Documentation seems focus on the flow of starting from accessing protected resource then redirect to login page.
    How can we perform direct login?
    I tried from my custom login page directly, but it always gives me *"PolicyEvaluationException: OAMSSA-06191: The runtime request contains no resource"* once the login form submitted.
    Anyone can advise? Thanks in advance.

    Thanks for the reply.
    We need to cater for both the scenarios:
    Scenario 1: User tries to access a protected page. He/she will be redirected to the login page. Once it is authenticated, he/she will be redirected back to the previously requested protected page
    Scenario 2: User clicks the "Login" link on the homepage where the homepage is definitely unprotected. He/she will be redirected to the login page. Once it is authenticated, he/she will be redirected back to homepage.
    I have tried to the "Success URL" parameter of the Authentication Policy. However, once "Success URL" is defined, Scenario 1 will NOT work...
    Yes. There are some work around solution I can think about.
    Example: use a intermediate page 'rediret.jsp' which is defined as the protected resource.
    The flow is: clicks the "Login" link on the homepage -> a intermediate page 'rediret.jsp' -> login page -> redirect back to 'rediret.jsp' -> 'rediret.jsp' will redirect user to the Homepage...
    But I think Scenario 2 should be very common and it should be a right solution for it. Please advise. Thanks

  • Poor performance while join of 2 comprehensive large views and small table

    Hi,
    The following SQL statement has been identified to perform poorly. It currently takes up to 6 seconds to execute, but it's supposed to take ~30-40ms at most.
    This is the statement(all bind variables change to numbers):
    SELECT v__96.connector_objectid, v__96.connector_classid, v__96.from_objectid,
           v__96.to_objectid, v__96.from_classid, v__96.to_classid,
           v__96.from_firstunit, v__96.to_firstunit, v__96.number_of_units,
           tmp_trace.first_unit, tmp_trace.last_unit, v__96.inv_status_number,
           tmp_trace.first_unit, tmp_trace.last_unit, v__96.answers,
           v__96.priority, v__97.first_unit, v__97.n_units,
           v__97.mid_span_distance
      FROM ne.tmp_trace,
           (SELECT b.objectid, b.answers, b.connector_classid,
                   b.connector_objectid, b.from_classid, b.from_objectid,
                   b.to_classid, b.to_objectid, b.from_firstunit, b.to_firstunit,
                   b.number_of_units, b.inv_status_number, b.splice_closure_name,
                   b.work_order_name, b.work_order_item_number,
                   b.inventory_status_code, b.priority
              FROM ne.connection b
             WHERE b.objectid NOT IN (
                      SELECT /*+ HASH_AJ */
                             sde_deletes_row_id
                        FROM ne.d96
                       WHERE deleted_at IN (
                                SELECT l.lineage_id
                                  FROM sde.state_lineages l
                                 WHERE l.lineage_name = 2
                                   AND l.lineage_id <= 115)
                         AND sde_state_id = 0)
            UNION ALL
            SELECT a.objectid, a.answers, a.connector_classid,
                   a.connector_objectid, a.from_classid, a.from_objectid,
                   a.to_classid, a.to_objectid, a.from_firstunit, a.to_firstunit,
                   a.number_of_units, a.inv_status_number, a.splice_closure_name,
                   a.work_order_name, a.work_order_item_number,
                   a.inventory_status_code, a.priority
              FROM ne.a96 a, sde.state_lineages sl
             WHERE (a.objectid, a.sde_state_id) NOT IN (
                      SELECT /*+ HASH_AJ */
                             sde_deletes_row_id, sde_state_id
                        FROM ne.d96
                       WHERE deleted_at IN (
                                SELECT l.lineage_id
                                  FROM sde.state_lineages l
                                 WHERE l.lineage_name = 2
                                   AND l.lineage_id <= 115)
                         AND sde_state_id > 0)
               AND a.sde_state_id = sl.lineage_id
               AND sl.lineage_name = 2
               AND sl.lineage_id <= 115) v__96,
           (SELECT b.objectid, b.tray_number, b.db_loss, b.first_unit, b.n_units,
                   b.connection_objectid, b.connector_type_name,
                   b.dedicated_status, b.mid_span_distance
              FROM ne.connection_attributes b
             WHERE b.objectid NOT IN (
                      SELECT /*+ HASH_AJ */
                             sde_deletes_row_id
                        FROM ne.d97
                       WHERE deleted_at IN (
                                SELECT l.lineage_id
                                  FROM sde.state_lineages l
                                 WHERE l.lineage_name = 2
                                   AND l.lineage_id <= 115)
                         AND sde_state_id = 0)
            UNION ALL
            SELECT a.objectid, a.tray_number, a.db_loss, a.first_unit, a.n_units,
                   a.connection_objectid, a.connector_type_name,
                   a.dedicated_status, a.mid_span_distance
              FROM ne.a97 a, sde.state_lineages sl
             WHERE (a.objectid, a.sde_state_id) NOT IN (
                      SELECT /*+ HASH_AJ */
                             sde_deletes_row_id, sde_state_id
                        FROM ne.d97
                       WHERE deleted_at IN (
                                SELECT l.lineage_id
                                  FROM sde.state_lineages l
                                 WHERE l.lineage_name = 2
                                   AND l.lineage_id <= 115)
                         AND sde_state_id > 0)
               AND a.sde_state_id = sl.lineage_id
               AND sl.lineage_name = 2
               AND sl.lineage_id <= 115) v__97
    WHERE (    (    (    (    (   (    ne.tmp_trace.equipment_object_id =
                                                                 v__96.to_objectid
                                    AND v__96.to_classid = 9
                                OR (    ne.tmp_trace.transmedia_object_id =
                                                                 v__96.to_objectid
                                    AND v__96.to_classid = 5
                           AND (   (v__96.to_firstunit
                                       BETWEEN ne.tmp_trace.first_unit
                                           AND ne.tmp_trace.last_unit
                                OR (ne.tmp_trace.first_unit
                                       BETWEEN v__96.to_firstunit
                                           AND   v__96.to_firstunit
                                               + v__96.number_of_units
                                               - 1
                      AND v__96.answers = 0
                 AND v__96.objectid = v__97.connection_objectid
            AND (ne.tmp_trace.session_id = -1234)
           );It should return many values from 2 comprehensive views (v__96, v__97) and business table (tmp_trace). 2 comprehensive views ~1,000,000 recs each, business table ~ 10 recs.
    The version of the database is 11.1.0.6.
    These are the parameters relevant to the optimizer:
    SQL> show parameter optimizer
    NAME                                 TYPE                             VALUE
    optimizer_capture_sql_plan_baselines boolean                          FALSE
    optimizer_dynamic_sampling           integer                          2
    optimizer_features_enable            string                           11.1.0.6
    optimizer_index_caching              integer                          0
    optimizer_index_cost_adj             integer                          100
    optimizer_mode                       string                           ALL_ROWS
    optimizer_secure_view_merging        boolean                          TRUE
    optimizer_use_invisible_indexes      boolean                          FALSE
    optimizer_use_pending_statistics     boolean                          FALSE
    optimizer_use_sql_plan_baselines     boolean                          TRUE
    SQL> show parameter db_file_multi
    NAME                                 TYPE                             VALUE
    db_file_multiblock_read_count        integer                          128
    SQL> show parameter db_block_size
    NAME                                 TYPE                             VALUE
    db_block_size                        integer                          8192
    SQL> show parameter cursor_sharing
    NAME                                 TYPE                             VALUE
    cursor_sharing                       string                           FORCE
    SQL> column sname format a20
    SQL> column pname format a20
    SQL> column pval2 format a20
    SQL> select sname, pname, pval1, pval2 from sys.aux_stats$;
    SNAME                PNAME                     PVAL1 PVAL2
    SYSSTATS_INFO        STATUS                          COMPLETED
    SYSSTATS_INFO        DSTART                          07-15-2009 10:27
    SYSSTATS_INFO        DSTOP                           07-15-2009 10:27
    SYSSTATS_INFO        FLAGS                         1
    SYSSTATS_MAIN        CPUSPEEDNW           1812.32129
    SYSSTATS_MAIN        IOSEEKTIM                    10
    SYSSTATS_MAIN        IOTFRSPEED                 4096
    SYSSTATS_MAIN        SREADTIM
    SYSSTATS_MAIN        MREADTIM
    SYSSTATS_MAIN        CPUSPEED
    SYSSTATS_MAIN        MBRC
    SNAME                PNAME                     PVAL1 PVAL2
    SYSSTATS_MAIN        MAXTHR
    SYSSTATS_MAIN        SLAVETHR
    13 rows selected.Here is the output of EXPLAIN PLAN:
    explain plan for -- statement above
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 1005186751
    | Id  | Operation                          | Name                  | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                   |                       |     1 |   282 |   268   (2)| 00:00:04 |
    |   1 |  NESTED LOOPS                      |                       |     1 |   282 |   268   (2)| 00:00:04 |
    |   2 |   MERGE JOIN CARTESIAN             |                       |     1 |   119 |   260   (1)| 00:00:04 |
    |*  3 |    TABLE ACCESS FULL               | TMP_TRACE             |     1 |    65 |     2   (0)| 00:00:01 |
    |   4 |    BUFFER SORT                     |                       |   103K|  5467K|   258   (1)| 00:00:04 |
    |   5 |     VIEW                           |                       |   103K|  5467K|   258   (1)| 00:00:04 |
    |   6 |      UNION-ALL                     |                       |       |       |            |       |
    |   7 |       NESTED LOOPS ANTI            |                       |     1 |    82 |     3   (0)| 00:00:01 |
    |   8 |        TABLE ACCESS FULL           | CONNECTION_ATTRIBUTES |     1 |    78 |     2   (0)| 00:00:01 |
    |   9 |        VIEW PUSHED PREDICATE       | VW_NSO_1              |     1 |     4 |     1   (0)| 00:00:01 |
    |  10 |         NESTED LOOPS               |                       |     1 |    20 |     1   (0)| 00:00:01 |
    |* 11 |          INDEX RANGE SCAN          | LINEAGES_PK           |     5 |    35 |     1   (0)| 00:00:01 |
    |* 12 |          INDEX UNIQUE SCAN         | D97_PK                |     1 |    13 |     0   (0)| 00:00:01 |
    |* 13 |       HASH JOIN RIGHT ANTI         |                       |   103K|  5568K|   255   (1)| 00:00:04 |
    |  14 |        VIEW                        | VW_NSO_2              |     1 |    26 |     2   (0)| 00:00:01 |
    |  15 |         NESTED LOOPS               |                       |     1 |    20 |     2   (0)| 00:00:01 |
    |* 16 |          INDEX FAST FULL SCAN      | D97_PK                |     1 |    13 |     2   (0)| 00:00:01 |
    |* 17 |          INDEX UNIQUE SCAN         | LINEAGES_PK           |     1 |     7 |     0   (0)| 00:00:01 |
    |  18 |        NESTED LOOPS                |                       |       |       |            |       |
    |  19 |         NESTED LOOPS               |                       |   103K|  2936K|   252   (1)| 00:00:04 |
    |* 20 |          INDEX RANGE SCAN          | LINEAGES_PK           |     5 |    35 |     1   (0)| 00:00:01 |
    |* 21 |          INDEX RANGE SCAN          | A97_STATEID_IX1       | 17731 |       |    32   (0)| 00:00:01 |
    |  22 |         TABLE ACCESS BY INDEX ROWID| A97                   | 21491 |   461K|   123   (1)| 00:00:02 |
    |* 23 |   VIEW                             |                       |     1 |   163 |     8  (13)| 00:00:01 |
    |  24 |    UNION ALL PUSHED PREDICATE      |                       |       |       |            |       |
    |  25 |     NESTED LOOPS ANTI              |                       |     1 |   185 |     1   (0)| 00:00:01 |
    |* 26 |      TABLE ACCESS BY INDEX ROWID   | CONNECTION            |     1 |   181 |     0   (0)| 00:00:01 |
    |* 27 |       INDEX UNIQUE SCAN            | R96_SDE_ROWID_UK      |     1 |       |     0   (0)| 00:00:01 |
    |  28 |      VIEW PUSHED PREDICATE         | VW_NSO_3              |     1 |     4 |     1   (0)| 00:00:01 |
    |  29 |       NESTED LOOPS                 |                       |     1 |    20 |     1   (0)| 00:00:01 |
    |* 30 |        INDEX RANGE SCAN            | LINEAGES_PK           |     5 |    35 |     1   (0)| 00:00:01 |
    |* 31 |        INDEX UNIQUE SCAN           | D96_PK                |     1 |    13 |     0   (0)| 00:00:01 |
    |* 32 |     HASH JOIN ANTI                 |                       |     1 |    97 |     7  (15)| 00:00:01 |
    |  33 |      NESTED LOOPS                  |                       |     1 |    71 |     4   (0)| 00:00:01 |
    |* 34 |       TABLE ACCESS BY INDEX ROWID  | A96                   |     1 |    64 |     4   (0)| 00:00:01 |
    |* 35 |        INDEX RANGE SCAN            | A96_PK                |     1 |       |     3   (0)| 00:00:01 |
    |* 36 |       INDEX UNIQUE SCAN            | LINEAGES_PK           |     1 |     7 |     0   (0)| 00:00:01 |
    |  37 |      VIEW                          | VW_NSO_4              |     1 |    26 |     2   (0)| 00:00:01 |
    |  38 |       NESTED LOOPS                 |                       |     1 |    20 |     2   (0)| 00:00:01 |
    |* 39 |        INDEX FAST FULL SCAN        | D96_PK                |     1 |    13 |     2   (0)| 00:00:01 |
    |* 40 |        INDEX UNIQUE SCAN           | LINEAGES_PK           |     1 |     7 |     0   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       3 - filter("TMP_TRACE"."SESSION_ID"=(-1234))
      11 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
      12 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
                  "SDE_STATE_ID"=0)
           filter("DELETED_AT"<=115)
      13 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
      16 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
      17 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
           filter("L"."LINEAGE_ID"<=115)
      20 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
      21 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
           filter("A"."SDE_STATE_ID"<=115)
      23 - filter(("TMP_TRACE"."EQUIPMENT_OBJECT_ID"="V__96"."TO_OBJECTID" AND "V__96"."TO_CLASSID"=9
                  OR "TMP_TRACE"."TRANSMEDIA_OBJECT_ID"="V__96"."TO_OBJECTID" AND "V__96"."TO_CLASSID"=5) AND
                  ("V__96"."TO_FIRSTUNIT">="TMP_TRACE"."FIRST_UNIT" AND
                  "V__96"."TO_FIRSTUNIT"<="TMP_TRACE"."LAST_UNIT" OR "TMP_TRACE"."FIRST_UNIT">="V__96"."TO_FIRSTUNIT"
                  AND "TMP_TRACE"."FIRST_UNIT"<="V__96"."TO_FIRSTUNIT"+"V__96"."NUMBER_OF_UNITS"-1))
      26 - filter("B"."ANSWERS"=0)
      27 - access("B"."OBJECTID"="V__97"."CONNECTION_OBJECTID")
      30 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
      31 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
                  "SDE_STATE_ID"=0)
           filter("DELETED_AT"<=115)
      32 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
      34 - filter("A"."ANSWERS"=0)
      35 - access("A"."OBJECTID"="V__97"."CONNECTION_OBJECTID" AND "A"."SDE_STATE_ID"<=115)
      36 - access("SL"."LINEAGE_NAME"=2 AND "A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
           filter("SL"."LINEAGE_ID"<=115)
      39 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND
                  "SDE_DELETES_ROW_ID"="V__97"."CONNECTION_OBJECTID" AND "SDE_STATE_ID">0)
      40 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
           filter("L"."LINEAGE_ID"<=115)
    Note
       - dynamic sampling used for this statement
    87 rows selected.Here is the output of SQL*Plus AUTOTRACE including the TIMING information:
    SQL> set autotrace traceonly arraysize 100
    Elapsed: 00:00:01.64
    Execution Plan
    Plan hash value: 1198408274
    | Id  | Operation                          | Name                  | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                   |                       |   876K|   238M|  1301   (2)| 00:00:16 |
    |   1 |  CONCATENATION                     |                       |       |       |            |       |
    |*  2 |   HASH JOIN                        |                       |   438K|   119M|   651   (2)| 00:00:08 |
    |*  3 |    HASH JOIN                       |                       |   423 | 98559 |   390   (2)| 00:00:05 |
    |*  4 |     TABLE ACCESS FULL              | TMP_TRACE             |    82 |  5330 |    29   (0)| 00:00:01 |
    |*  5 |     VIEW                           |                       |   103K|    16M|   360   (1)| 00:00:05 |
    |   6 |      UNION-ALL                     |                       |       |       |            |       |
    |   7 |       NESTED LOOPS ANTI            |                       |     1 |   185 |     3   (0)| 00:00:01 |
    |*  8 |        TABLE ACCESS FULL           | CONNECTION            |     1 |   181 |     2   (0)| 00:00:01 |
    |   9 |        VIEW PUSHED PREDICATE       | VW_NSO_3              |     1 |     4 |     1   (0)| 00:00:01 |
    |  10 |         NESTED LOOPS               |                       |     1 |    20 |     1   (0)| 00:00:01 |
    |* 11 |          INDEX RANGE SCAN          | LINEAGES_PK           |     5 |    35 |     1   (0)| 00:00:01 |
    |* 12 |          INDEX UNIQUE SCAN         | D96_PK                |     1 |    13 |     0   (0)| 00:00:01 |
    |* 13 |       HASH JOIN RIGHT ANTI         |                       |   103K|  9820K|   357   (1)| 00:00:05 |
    |  14 |        VIEW                        | VW_NSO_4              |     1 |    26 |     2   (0)| 00:00:01 |
    |  15 |         NESTED LOOPS               |                       |     1 |    20 |     2   (0)| 00:00:01 |
    |* 16 |          INDEX FAST FULL SCAN      | D96_PK                |     1 |    13 |     2   (0)| 00:00:01 |
    |* 17 |          INDEX UNIQUE SCAN         | LINEAGES_PK           |     1 |     7 |     0   (0)| 00:00:01 |
    |  18 |        NESTED LOOPS                |                       |       |       |            |       |
    |  19 |         NESTED LOOPS               |                       |   103K|  7188K|   354   (1)| 00:00:05 |
    |* 20 |          INDEX RANGE SCAN          | LINEAGES_PK           |     5 |    35 |     1   (0)| 00:00:01 |
    |* 21 |          INDEX RANGE SCAN          | A96_STATEID_IX1       | 17731 |       |    32   (0)| 00:00:01 |
    |* 22 |         TABLE ACCESS BY INDEX ROWID| A96                   | 21491 |  1343K|   224   (1)| 00:00:03 |
    |  23 |    VIEW                            |                       |   103K|  5264K|   258   (1)| 00:00:04 |
    |  24 |     UNION-ALL                      |                       |       |       |            |       |
    |  25 |      NESTED LOOPS ANTI             |                       |     1 |    82 |     3   (0)| 00:00:01 |
    |  26 |       TABLE ACCESS FULL            | CONNECTION_ATTRIBUTES |     1 |    78 |     2   (0)| 00:00:01 |
    |  27 |       VIEW PUSHED PREDICATE        | VW_NSO_1              |     1 |     4 |     1   (0)| 00:00:01 |
    |  28 |        NESTED LOOPS                |                       |     1 |    20 |     1   (0)| 00:00:01 |
    |* 29 |         INDEX RANGE SCAN           | LINEAGES_PK           |     5 |    35 |     1   (0)| 00:00:01 |
    |* 30 |         INDEX UNIQUE SCAN          | D97_PK                |     1 |    13 |     0   (0)| 00:00:01 |
    |* 31 |      HASH JOIN RIGHT ANTI          |                       |   103K|  5568K|   255   (1)| 00:00:04 |
    |  32 |       VIEW                         | VW_NSO_2              |     1 |    26 |     2   (0)| 00:00:01 |
    |  33 |        NESTED LOOPS                |                       |     1 |    20 |     2   (0)| 00:00:01 |
    |* 34 |         INDEX FAST FULL SCAN       | D97_PK                |     1 |    13 |     2   (0)| 00:00:01 |
    |* 35 |         INDEX UNIQUE SCAN          | LINEAGES_PK           |     1 |     7 |     0   (0)| 00:00:01 |
    |  36 |       NESTED LOOPS                 |                       |       |       |            |       |
    |  37 |        NESTED LOOPS                |                       |   103K|  2936K|   252   (1)| 00:00:04 |
    |* 38 |         INDEX RANGE SCAN           | LINEAGES_PK           |     5 |    35 |     1   (0)| 00:00:01 |
    |* 39 |         INDEX RANGE SCAN           | A97_STATEID_IX1       | 17731 |       |    32   (0)| 00:00:01 |
    |  40 |        TABLE ACCESS BY INDEX ROWID | A97                   | 21491 |   461K|   123   (1)| 00:00:02 |
    |* 41 |   HASH JOIN                        |                       |   438K|   119M|   651   (2)| 00:00:08 |
    |* 42 |    HASH JOIN                       |                       |   423 | 98559 |   390   (2)| 00:00:05 |
    |* 43 |     TABLE ACCESS FULL              | TMP_TRACE             |    82 |  5330 |    29   (0)| 00:00:01 |
    |* 44 |     VIEW                           |                       |   103K|    16M|   360   (1)| 00:00:05 |
    |  45 |      UNION-ALL                     |                       |       |       |            |       |
    |  46 |       NESTED LOOPS ANTI            |                       |     1 |   185 |     3   (0)| 00:00:01 |
    |* 47 |        TABLE ACCESS FULL           | CONNECTION            |     1 |   181 |     2   (0)| 00:00:01 |
    |  48 |        VIEW PUSHED PREDICATE       | VW_NSO_3              |     1 |     4 |     1   (0)| 00:00:01 |
    |  49 |         NESTED LOOPS               |                       |     1 |    20 |     1   (0)| 00:00:01 |
    |* 50 |          INDEX RANGE SCAN          | LINEAGES_PK           |     5 |    35 |     1   (0)| 00:00:01 |
    |* 51 |          INDEX UNIQUE SCAN         | D96_PK                |     1 |    13 |     0   (0)| 00:00:01 |
    |* 52 |       HASH JOIN RIGHT ANTI         |                       |   103K|  9820K|   357   (1)| 00:00:05 |
    |  53 |        VIEW                        | VW_NSO_4              |     1 |    26 |     2   (0)| 00:00:01 |
    |  54 |         NESTED LOOPS               |                       |     1 |    20 |     2   (0)| 00:00:01 |
    |* 55 |          INDEX FAST FULL SCAN      | D96_PK                |     1 |    13 |     2   (0)| 00:00:01 |
    |* 56 |          INDEX UNIQUE SCAN         | LINEAGES_PK           |     1 |     7 |     0   (0)| 00:00:01 |
    |  57 |        NESTED LOOPS                |                       |       |       |            |       |
    |  58 |         NESTED LOOPS               |                       |   103K|  7188K|   354   (1)| 00:00:05 |
    |* 59 |          INDEX RANGE SCAN          | LINEAGES_PK           |     5 |    35 |     1   (0)| 00:00:01 |
    |* 60 |          INDEX RANGE SCAN          | A96_STATEID_IX1       | 17731 |       |    32   (0)| 00:00:01 |
    |* 61 |         TABLE ACCESS BY INDEX ROWID| A96                   | 21491 |  1343K|   224   (1)| 00:00:03 |
    |  62 |    VIEW                            |                       |   103K|  5264K|   258   (1)| 00:00:04 |
    |  63 |     UNION-ALL                      |                       |       |       |            |       |
    |  64 |      NESTED LOOPS ANTI             |                       |     1 |    82 |     3   (0)| 00:00:01 |
    |  65 |       TABLE ACCESS FULL            | CONNECTION_ATTRIBUTES |     1 |    78 |     2   (0)| 00:00:01 |
    |  66 |       VIEW PUSHED PREDICATE        | VW_NSO_1              |     1 |     4 |     1   (0)| 00:00:01 |
    |  67 |        NESTED LOOPS                |                       |     1 |    20 |     1   (0)| 00:00:01 |
    |* 68 |         INDEX RANGE SCAN           | LINEAGES_PK           |     5 |    35 |     1   (0)| 00:00:01 |
    |* 69 |         INDEX UNIQUE SCAN          | D97_PK                |     1 |    13 |     0   (0)| 00:00:01 |
    |* 70 |      HASH JOIN RIGHT ANTI          |                       |   103K|  5568K|   255   (1)| 00:00:04 |
    |  71 |       VIEW                         | VW_NSO_2              |     1 |    26 |     2   (0)| 00:00:01 |
    |  72 |        NESTED LOOPS                |                       |     1 |    20 |     2   (0)| 00:00:01 |
    |* 73 |         INDEX FAST FULL SCAN       | D97_PK                |     1 |    13 |     2   (0)| 00:00:01 |
    |* 74 |         INDEX UNIQUE SCAN          | LINEAGES_PK           |     1 |     7 |     0   (0)| 00:00:01 |
    |  75 |       NESTED LOOPS                 |                       |       |       |            |       |
    |  76 |        NESTED LOOPS                |                       |   103K|  2936K|   252   (1)| 00:00:04 |
    |* 77 |         INDEX RANGE SCAN           | LINEAGES_PK           |     5 |    35 |     1   (0)| 00:00:01 |
    |* 78 |         INDEX RANGE SCAN           | A97_STATEID_IX1       | 17731 |       |    32   (0)| 00:00:01 |
    |  79 |        TABLE ACCESS BY INDEX ROWID | A97                   | 21491 |   461K|   123   (1)| 00:00:02 |
    Predicate Information (identified by operation id):
       2 - access("V__96"."OBJECTID"="V__97"."CONNECTION_OBJECTID")
       3 - access("TMP_TRACE"."TRANSMEDIA_OBJECT_ID"="V__96"."TO_OBJECTID")
           filter("V__96"."TO_FIRSTUNIT">="TMP_TRACE"."FIRST_UNIT" AND
                  "V__96"."TO_FIRSTUNIT"<="TMP_TRACE"."LAST_UNIT" OR "TMP_TRACE"."FIRST_UNIT">="V__96"."TO_FIRSTUNIT"
                  AND "TMP_TRACE"."FIRST_UNIT"<="V__96"."TO_FIRSTUNIT"+"V__96"."NUMBER_OF_UNITS"-1)
       4 - filter("TMP_TRACE"."SESSION_ID"=(-1234))
       5 - filter("V__96"."TO_CLASSID"=5)
       8 - filter("B"."ANSWERS"=0)
      11 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
      12 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
                  "SDE_STATE_ID"=0)
           filter("DELETED_AT"<=115)
      13 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
      16 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
      17 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
           filter("L"."LINEAGE_ID"<=115)
      20 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
      21 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
           filter("A"."SDE_STATE_ID"<=115)
      22 - filter("A"."ANSWERS"=0)
      29 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
      30 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
                  "SDE_STATE_ID"=0)
           filter("DELETED_AT"<=115)
      31 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
      34 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
      35 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
           filter("L"."LINEAGE_ID"<=115)
      38 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
      39 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
           filter("A"."SDE_STATE_ID"<=115)
      41 - access("V__96"."OBJECTID"="V__97"."CONNECTION_OBJECTID")
      42 - access("TMP_TRACE"."EQUIPMENT_OBJECT_ID"="V__96"."TO_OBJECTID")
           filter((LNNVL("TMP_TRACE"."TRANSMEDIA_OBJECT_ID"="V__96"."TO_OBJECTID") OR
                  LNNVL("V__96"."TO_CLASSID"=5)) AND ("V__96"."TO_FIRSTUNIT">="TMP_TRACE"."FIRST_UNIT" AND
                  "V__96"."TO_FIRSTUNIT"<="TMP_TRACE"."LAST_UNIT" OR "TMP_TRACE"."FIRST_UNIT">="V__96"."TO_FIRSTUNIT"
                  AND "TMP_TRACE"."FIRST_UNIT"<="V__96"."TO_FIRSTUNIT"+"V__96"."NUMBER_OF_UNITS"-1))
      43 - filter("TMP_TRACE"."SESSION_ID"=(-1234))
      44 - filter("V__96"."TO_CLASSID"=9)
      47 - filter("B"."ANSWERS"=0)
      50 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
      51 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
                  "SDE_STATE_ID"=0)
           filter("DELETED_AT"<=115)
      52 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
      55 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
      56 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
           filter("L"."LINEAGE_ID"<=115)
      59 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
      60 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
           filter("A"."SDE_STATE_ID"<=115)
      61 - filter("A"."ANSWERS"=0)
      68 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
      69 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
                  "SDE_STATE_ID"=0)
           filter("DELETED_AT"<=115)
      70 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
      73 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
      74 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
           filter("L"."LINEAGE_ID"<=115)
      77 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
      78 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
           filter("A"."SDE_STATE_ID"<=115)
    Note
       - dynamic sampling used for this statementThe TKPROF output for this statement looks like the following:
    TKPROF: Release 11.1.0.6.0 - Production on Thu Sep 24 09:30:01 2009
    Copyright (c) 1982, 2007, Oracle.  All rights reserved.
    Trace file: pro                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           &

    The TKPROF output for this statement looks like the following:
    TKPROF: Release 11.1.0.6.0 - Production on Thu Sep 24 09:30:01 2009
    Copyright (c) 1982, 2007, Oracle.  All rights reserved.
    Trace file: problem.trc
    Sort options: default
    count    = number of times OCI procedure was executed
    cpu      = cpu time in seconds executing
    elapsed  = elapsed time in seconds executing
    disk     = number of physical reads of buffers from disk
    query    = number of buffers gotten for consistent read
    current  = number of buffers gotten in current mode (usually for update)
    rows     = number of rows processed by the fetch or execute call
    SELECT  V__96.CONNECTOR_OBJECTID,  V__96.CONNECTOR_CLASSID,  V__96.FROM_OBJECTID,  V__96.TO_OBJECTID,  V__96.FROM_CLASSID,  V__96.TO_CLASSID, 
    V__96.FROM_FIRSTUNIT,  V__96.TO_FIRSTUNIT,  V__96.NUMBER_OF_UNITS,  TMP_TRACE.FIRST_UNIT,  TMP_TRACE.LAST_UNIT,  V__96.INV_STATUS_NUMBER, 
    TMP_TRACE.FIRST_UNIT,  TMP_TRACE.LAST_UNIT,  V__96.ANSWERS,  V__96.PRIORITY,  V__97.FIRST_UNIT,  V__97.N_UNITS,  V__97.MID_SPAN_DISTANCE  FROM 
    NE.TMP_TRACE,(SELECT
    b.OBJECTID,b.ANSWERS,b.CONNECTOR_CLASSID,b.CONNECTOR_OBJECTID,b.FROM_CLASSID,b.FROM_OBJECTID,b.TO_CLASSID,b.TO_OBJECTID,b.FROM_FIRSTUNIT,b.TO_FIRSTUNIT,b.NUM
    BER_OF_UNITS,b.INV_STATUS_NUMBER,b.SPLICE_CLOSURE_NAME,b.WORK_ORDER_NAME,b.WORK_ORDER_ITEM_NUMBER,b.INVENTORY_STATUS_CODE,b.PRIORITY  FROM NE.connection b
    WHERE b.OBJECTID NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID FROM NE.D96 WHERE DELETED_AT IN (SELECT l.lineage_id FROM SDE.state_lineages l WHERE
    l.lineage_name = :"SYS_B_00" AND l.lineage_id <= :"SYS_B_01") AND SDE_STATE_ID = :"SYS_B_02") UNION ALL SELECT
    a.OBJECTID,a.ANSWERS,a.CONNECTOR_CLASSID,a.CONNECTOR_OBJECTID,a.FROM_CLASSID,a.FROM_OBJECTID,a.TO_CLASSID,a.TO_OBJECTID,a.FROM_FIRSTUNIT,a.TO_FIRSTUNIT,a.NUM
    BER_OF_UNITS,a.INV_STATUS_NUMBER,a.SPLICE_CLOSURE_NAME,a.WORK_ORDER_NAME,a.WORK_ORDER_ITEM_NUMBER,a.INVENTORY_STATUS_CODE,a.PRIORITY  FROM NE.A96
    a,SDE.state_lineages SL WHERE (a.OBJECTID, a.SDE_STATE_ID) NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID,SDE_STATE_ID  FROM NE.D96 WHERE DELETED_AT IN
    (SELECT l.lineage_id FROM SDE.state_lineages l WHERE l.lineage_name = :"SYS_B_03" AND l.lineage_id <= :"SYS_B_04") AND SDE_STATE_ID > :"SYS_B_05") AND
    a.SDE_STATE_ID = SL.lineage_id AND SL.lineage_name = :"SYS_B_06" AND SL.lineage_id <= :"SYS_B_07") V__96,(SELECT
    b.OBJECTID,b.TRAY_NUMBER,b.DB_LOSS,b.FIRST_UNIT,b.N_UNITS,b.CONNECTION_OBJECTID,b.CONNECTOR_TYPE_NAME,b.DEDICATED_STATUS,b.MID_SPAN_DISTANCE  FROM
    NE.connection_attributes b WHERE b.OBJECTID NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID FROM NE.D97 WHERE DELETED_AT IN (SELECT l.lineage_id FROM
    SDE.state_lineages l WHERE l.lineage_name = :"SYS_B_08" AND l.lineage_id <= :"SYS_B_09") AND SDE_STATE_ID = :"SYS_B_10") UNION ALL SELECT
    a.OBJECTID,a.TRAY_NUMBER,a.DB_LOSS,a.FIRST_UNIT,a.N_UNITS,a.CONNECTION_OBJECTID,a.CONNECTOR_TYPE_NAME,a.DEDICATED_STATUS,a.MID_SPAN_DISTANCE  FROM NE.A97
    a,SDE.state_lineages SL WHERE (a.OBJECTID, a.SDE_STATE_ID) NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID,SDE_STATE_ID  FROM NE.D97 WHERE DELETED_AT IN
    (SELECT l.lineage_id FROM SDE.state_lineages l WHERE l.lineage_name = :"SYS_B_11" AND l.lineage_id <= :"SYS_B_12") AND SDE_STATE_ID > :"SYS_B_13") AND
    a.SDE_STATE_ID = SL.lineage_id AND SL.lineage_name = :"SYS_B_14" AND SL.lineage_id <= :"SYS_B_15") V__97  WHERE (((((   (
                                             NE.tmp_trace.equipment_object_id = V__96.to_objectid
                                              AND
                                             V__96.to_classid = :"SYS_B_16"
                                           OR
                                             NE.tmp_trace.transmedia_object_id = V__96.to_objectid
                                               AND
                                             V__96.to_classid = :"SYS_B_17"
                                             )) AND (
                                            (V__96.to_firstunit
                                                BETWEEN NE.tmp_trace.first_unit AND NE.tmp_trace.last_unit)
                                              OR
                                            (NE.tmp_trace.first_unit BETWEEN V__96.to_firstunit
                                                 AND V__96.to_firstunit + V__96.number_of_units - :"SYS_B_18")
                                          )) AND V__96.answers = :"SYS_B_19") AND V__96.objectid = V__97.connection_objectid) AND (NE.tmp_trace.session_id =
    :"SYS_B_20"))
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1      5.98       5.99          0      22652          0          10
    total        3      5.98       5.99          0      22652          0          10
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 45 
    Rows     Row Source Operation
         10  NESTED LOOPS  (cr=22652 pr=0 pw=0 time=654515 us cost=67 size=282 card=1)
         10   NESTED LOOPS  (cr=22436 pr=0 pw=0 time=653673 us cost=61 size=235 card=1)
         10    TABLE ACCESS FULL TMP_TRACE (cr=5 pr=0 pw=0 time=7 us cost=2 size=65 card=1)
         10    VIEW  (cr=22431 pr=0 pw=0 time=0 us cost=59 size=170 card=1)
    1773000     UNION-ALL  (cr=22431 pr=0 pw=0 time=93649 us)
          0      NESTED LOOPS ANTI (cr=30 pr=0 pw=0 time=0 us cost=3 size=185 card=1)
          0       TABLE ACCESS FULL CONNECTION (cr=30 pr=0 pw=0 time=0 us cost=2 size=181 card=1)
          0       VIEW PUSHED PREDICATE  VW_NSO_3 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)
          0        NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=1 size=20 card=1)
          0         INDEX RANGE SCAN LINEAGES_PK (cr=0 pr=0 pw=0 time=0 us cost=1 size=7 card=1)(object id 34021)
          0         INDEX UNIQUE SCAN D96_PK (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)(object id 35121)
    1773000      HASH JOIN RIGHT ANTI (cr=22401 pr=0 pw=0 time=75084 us cost=56 size=46948 card=484)
          0       VIEW  VW_NSO_4 (cr=180 pr=0 pw=0 time=0 us cost=2 size=26 card=1)
          0        FILTER  (cr=180 pr=0 pw=0 time=0 us)
          0         NESTED LOOPS  (cr=180 pr=0 pw=0 time=0 us cost=2 size=20 card=1)
          0          INDEX FAST FULL SCAN D96_PK (cr=180 pr=0 pw=0 time=0 us cost=2 size=13 card=1)(object id 35121)
          0          INDEX UNIQUE SCAN LINEAGES_PK (cr=0 pr=0 pw=0 time=0 us cost=0 size=7 card=1)(object id 34021)
    1773000       NESTED LOOPS  (cr=22221 pr=0 pw=0 time=56155 us)
    1773000        NESTED LOOPS  (cr=3231 pr=0 pw=0 time=15078 us cost=53 size=34364 card=484)
         50         INDEX RANGE SCAN LINEAGES_PK (cr=10 pr=0 pw=0 time=7 us cost=1 size=7 card=1)(object id 34021)
    1773000         INDEX RANGE SCAN A96_STATEID_IX1 (cr=3221 pr=0 pw=0 time=6810 us cost=32 size=0 card=1774)(object id 35116)
    1773000        TABLE ACCESS BY INDEX ROWID A96 (cr=18990 pr=0 pw=0 time=0 us cost=52 size=82560 card=1290)
         10   VIEW  (cr=216 pr=0 pw=0 time=0 us cost=7 size=47 card=1)
         10    UNION ALL PUSHED PREDICATE  (cr=216 pr=0 pw=0 time=0 us)
          0     NESTED LOOPS ANTI (cr=1 pr=0 pw=0 time=0 us cost=2 size=82 card=1)
          0      TABLE ACCESS BY INDEX ROWID CONNECTION_ATTRIBUTES (cr=1 pr=0 pw=0 time=0 us cost=1 size=78 card=1)
          0       INDEX RANGE SCAN GDB_59_CONNECTIO (cr=1 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 34346)
          0      VIEW PUSHED PREDICATE  VW_NSO_1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)
          0       NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=1 size=20 card=1)
          0        INDEX RANGE SCAN LINEAGES_PK (cr=0 pr=0 pw=0 time=0 us cost=1 size=7 card=1)(object id 34021)
          0        INDEX UNIQUE SCAN D97_PK (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)(object id 35127)
         10     HASH JOIN ANTI (cr=215 pr=0 pw=0 time=0 us cost=5 size=55 card=1)
         10      NESTED LOOPS  (cr=35 pr=0 pw=0 time=0 us cost=2 size=29 card=1)
         10       TABLE ACCESS BY INDEX ROWID A97 (cr=25 pr=0 pw=0 time=0 us cost=2 size=22 card=1)
         10        INDEX RANGE SCAN GDB_59_CONNECTIO_A (cr=15 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 35122)
         10       INDEX UNIQUE SCAN LINEAGES_PK (cr=10 pr=0 pw=0 time=0 us cost=0 size=7 card=1)(object id 34021)
          0      VIEW  VW_NSO_2 (cr=180 pr=0 pw=0 time=0 us cost=2 size=26 card=1)
          0       FILTER  (cr=180 pr=0 pw=0 time=0 us)
          0        NESTED LOOPS  (cr=180 pr=0 pw=0 time=0 us cost=2 size=20 card=1)
          0         INDEX FAST FULL SCAN D97_PK (cr=180 pr=0 pw=0 time=0 us cost=2 size=13 card=1)(object id 35127)
          0         INDEX UNIQUE SCAN LINEAGES_PK (cr=0 pr=0 pw=0 time=0 us cost=0 size=7 card=1)(object id 34021)
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       2        0.00          0.00
      SQL*Net message from client                     2        0.00          0.00After manually rewrite query in TOAD it produces nested loops on business table and than access v__96, v__97 produce desired quick performance.
    I can use stored outlines but this is the last chance. I am playing with hints right now to produce desired plan with no result yet.
    Does anybody know how to insist Oracle to merge internal views to bigger query block, so Oracle can choose better plan?
    Or any guide what hints to use from ol$hints to get desired result via hints addition to original sql query (thanks God application don't cut hints just pass-through to Oracle)?
    Thanks,
    Sergiy

  • MKPF & MSEG Performance issue : Join on table  MKPF & MSEG  taking too much time ..

    Hello Experts,
    I had a issue where we are executing one custom report in which  i used inner join on table  MKPF & MSEG,  some time join statement  took  9-10 min to excute and some time execute within  1-2 min with same test data .
    i am not able to understand what the actaully happing .
    please help.
    code :
       SELECT f~mblnr f~mjahr f~usnam f~bktxt  p~bukrs
        INTO TABLE itab
        FROM mkpf AS f INNER JOIN mseg AS p
            ON f~mblnr = p~mblnr AND f~mjahr = p~mjahr
         WHERE f~vgart = 'WE'
           AND f~budat IN p_budat
           AND f~usnam IN p_sgtxt
           AND p~bwart IN ('101','105')
           AND p~werks IN p_werks
           AND p~lgort IN p_lgort.
    Regards,
    Dipendra Panwar.

    Hi Dipendra,
    if you call a report twice after another with the same test data for data selection, then the second run should be faster, because some data are remaining in memory and needn't to be caught from database. This will be also for the following third und further runs, until the data in the SAP memory will be removed by other programs.
    For performance traces you should try to test with a first run.
    Regards,
    Klaus

  • Performance during joining large tables

    Hi,
    I have to maintain a report which gets data from many large tables as below. Currently it is using join statement to join all 8 tables and causing a very slow performance.
    SELECT
        into corresponding fields of table equip
        FROM caufv
                  join afih on afih~aufnr = caufv~aufnr
                  join iloa on iloa~iloan = afih~iloan
                  join iflos  on iflos~tplnr = iloa~tplnr
                  join iflotx on iflos~tplnr = iflotx~tplnr
                  join vbak on vbak~aufnr = caufv~aufnr
                  join equz on equz~equnr = afih~equnr
                  join equi on equi~equnr = equz~equnr
                  join vbap on vbak~vbeln = vbap~vbeln
        WHERE
    Please suggest me another way, I'm newbie in ABAP. I tried using FOR ALL ENTRIES IN but it did not work. I would very appreciate if you can leave me some sample lines of code.
    Thanks,

    Hi Dear ,
    I will suggest you not to use inner join for such i.e. 8 number of table and that too huge tables. Instead use For All entries wherever possible. But before using for all entries check initial for base table and if its not possible to avoid inner join then try to minimise it. Use inner join between header and item.
    Hope this will help you to solve your problem . Feel free to ask if you have any doubt.
    Regards,
    Vijay

  • Poor query performance when joining CONTAINS to another table

    We just recently began evaluating Oracle Text for a search solution. We need to be able to search a table that can have over 20+ million rows. Each user may only have visibility to a tiny fraction of those rows. The goal is to have a single Oracle Text index that represents all of the searchable columns in the table (multi column datastore) and provide a score for each search result so that we can sort the search results in descending order by score. What we're seeing is that query performance from TOAD is extremely fast when we write a simple CONTAINS query against the Oracle Text indexed table. However, when we attempt to first reduce the rows the CONTAINS query needs to search by using a WITH we find that the query performance degrades significantly.
    For example, we can find all the records a user has access to from our base table by the following query:
    SELECT d.duns_loc
    FROM duns d
    JOIN primary_contact pc
    ON d.duns_loc = pc.duns_loc
    AND pc.emp_id = :employeeID;
    This query can execute in <100 ms. In the working example, this query returns around 1200 rows of the primary key duns_loc.
    Our search query looks like this:
    SELECT score(1), d.*
    FROM duns d
    WHERE CONTAINS(TEXT_KEY, :search,1) > 0
    ORDER BY score(1) DESC;
    The :search value in this example will be 'highway'. The query can return 246k rows in around 2 seconds.
    2 seconds is good, but we should be able to have a much faster response if the search query did not have to search the entire table, right? Since each user can only "view" records they are assigned to we reckon that if the search operation only had to scan a tiny tiny percent of the TEXT index we should see faster (and more relevant) results. If we now write the following query:
    WITH subset
    AS
    (SELECT d.duns_loc
    FROM duns d
    JOIN primary_contact pc
    ON d.duns_loc = pc.duns_loc
    AND pc.emp_id = :employeeID
    SELECT score(1), d.*
    FROM duns d
    JOIN subset s
    ON d.duns_loc = s.duns_loc
    WHERE CONTAINS(TEXT_KEY, :search,1) > 0
    ORDER BY score(1) DESC;
    For reasons we have not been able to identify this query actually takes longer to execute than the sum of the durations of the contributing parts. This query takes over 6 seconds to run. We nor our DBA can seem to figure out why this query performs worse than a wide open search. The wide open search is not ideal as the query would end up returning records to the user they don't have access to view.
    Has anyone ever ran into something like this? Any suggestions on what to look at or where to go? If anyone would like more information to help in diagnosis than let me know and i'll be happy to produce it here.
    Thanks!!

    Sometimes it can be good to separate the tables into separate sub-query factoring (with) clauses or inline views in the from clause or an in clause as a where condition. Although there are some differences, using a sub-query factoring (with) clause is similar to using an inline view in the from clause. However, you should avoid duplication. You should not have the same table in two different places, as in your original query. You should have indexes on any columns that the tables are joined on, your statistics should be current, and your domain index should have regular synchronization, optimization, and periodically rebuild or drop and recreate to keep it performing with maximum efficiency. The following demonstration uses a composite domain index (cdi) with filter by, as suggested by Roger, then shows the explained plans for your original query, and various others. Your original query has nested loops. All of the others have the same plan without the nested loops. You could also add index hints.
    SCOTT@orcl_11gR2> -- tables:
    SCOTT@orcl_11gR2> CREATE TABLE duns
      2    (duns_loc  NUMBER,
      3       text_key  VARCHAR2 (30))
      4  /
    Table created.
    SCOTT@orcl_11gR2> CREATE TABLE primary_contact
      2    (duns_loc  NUMBER,
      3       emp_id       NUMBER)
      4  /
    Table created.
    SCOTT@orcl_11gR2> -- data:
    SCOTT@orcl_11gR2> INSERT INTO duns VALUES (1, 'highway')
      2  /
    1 row created.
    SCOTT@orcl_11gR2> INSERT INTO primary_contact VALUES (1, 1)
      2  /
    1 row created.
    SCOTT@orcl_11gR2> INSERT INTO duns
      2  SELECT object_id, object_name
      3  FROM   all_objects
      4  WHERE  object_id > 1
      5  /
    76027 rows created.
    SCOTT@orcl_11gR2> INSERT INTO primary_contact
      2  SELECT object_id, namespace
      3  FROM   all_objects
      4  WHERE  object_id > 1
      5  /
    76027 rows created.
    SCOTT@orcl_11gR2> -- indexes:
    SCOTT@orcl_11gR2> CREATE INDEX duns_duns_loc_idx
      2  ON duns (duns_loc)
      3  /
    Index created.
    SCOTT@orcl_11gR2> CREATE INDEX primary_contact_duns_loc_idx
      2  ON primary_contact (duns_loc)
      3  /
    Index created.
    SCOTT@orcl_11gR2> -- composite domain index (cdi) with filter by clause
    SCOTT@orcl_11gR2> -- as suggested by Roger:
    SCOTT@orcl_11gR2> CREATE INDEX duns_text_key_idx
      2  ON duns (text_key)
      3  INDEXTYPE IS CTXSYS.CONTEXT
      4  FILTER BY duns_loc
      5  /
    Index created.
    SCOTT@orcl_11gR2> -- gather statistics:
    SCOTT@orcl_11gR2> EXEC DBMS_STATS.GATHER_TABLE_STATS (USER, 'DUNS')
    PL/SQL procedure successfully completed.
    SCOTT@orcl_11gR2> EXEC DBMS_STATS.GATHER_TABLE_STATS (USER, 'PRIMARY_CONTACT')
    PL/SQL procedure successfully completed.
    SCOTT@orcl_11gR2> -- variables:
    SCOTT@orcl_11gR2> VARIABLE employeeid NUMBER
    SCOTT@orcl_11gR2> EXEC :employeeid := 1
    PL/SQL procedure successfully completed.
    SCOTT@orcl_11gR2> VARIABLE search VARCHAR2(100)
    SCOTT@orcl_11gR2> EXEC :search := 'highway'
    PL/SQL procedure successfully completed.
    SCOTT@orcl_11gR2> -- original query:
    SCOTT@orcl_11gR2> SET AUTOTRACE ON EXPLAIN
    SCOTT@orcl_11gR2> WITH
      2    subset AS
      3        (SELECT d.duns_loc
      4         FROM      duns d
      5         JOIN      primary_contact pc
      6         ON      d.duns_loc = pc.duns_loc
      7         AND      pc.emp_id = :employeeID)
      8  SELECT score(1), d.*
      9  FROM   duns d
    10  JOIN   subset s
    11  ON     d.duns_loc = s.duns_loc
    12  WHERE  CONTAINS (TEXT_KEY, :search,1) > 0
    13  ORDER  BY score(1) DESC
    14  /
      SCORE(1)   DUNS_LOC TEXT_KEY
            18          1 highway
    1 row selected.
    Execution Plan
    Plan hash value: 4228563783
    | Id  | Operation                      | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT               |                   |     2 |    84 |   121   (4)| 00:00:02 |
    |   1 |  SORT ORDER BY                 |                   |     2 |    84 |   121   (4)| 00:00:02 |
    |*  2 |   HASH JOIN                    |                   |     2 |    84 |   120   (3)| 00:00:02 |
    |   3 |    NESTED LOOPS                |                   |    38 |  1292 |    50   (2)| 00:00:01 |
    |   4 |     TABLE ACCESS BY INDEX ROWID| DUNS              |    38 |  1102 |    11   (0)| 00:00:01 |
    |*  5 |      DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
    |*  6 |     INDEX RANGE SCAN           | DUNS_DUNS_LOC_IDX |     1 |     5 |     1   (0)| 00:00:01 |
    |*  7 |    TABLE ACCESS FULL           | PRIMARY_CONTACT   |  4224 | 33792 |    70   (3)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("D"."DUNS_LOC"="PC"."DUNS_LOC")
       5 - access("CTXSYS"."CONTAINS"("D"."TEXT_KEY",:SEARCH,1)>0)
       6 - access("D"."DUNS_LOC"="D"."DUNS_LOC")
       7 - filter("PC"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
    SCOTT@orcl_11gR2> -- queries with better plans (no nested loops):
    SCOTT@orcl_11gR2> -- subquery factoring (with) clauses:
    SCOTT@orcl_11gR2> WITH
      2    subset1 AS
      3        (SELECT pc.duns_loc
      4         FROM      primary_contact pc
      5         WHERE  pc.emp_id = :employeeID),
      6    subset2 AS
      7        (SELECT score(1), d.*
      8         FROM      duns d
      9         WHERE  CONTAINS (TEXT_KEY, :search,1) > 0)
    10  SELECT subset2.*
    11  FROM   subset1, subset2
    12  WHERE  subset1.duns_loc = subset2.duns_loc
    13  ORDER  BY score(1) DESC
    14  /
      SCORE(1)   DUNS_LOC TEXT_KEY
            18          1 highway
    1 row selected.
    Execution Plan
    Plan hash value: 153618227
    | Id  | Operation                     | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT              |                   |    38 |  1406 |    83   (5)| 00:00:01 |
    |   1 |  SORT ORDER BY                |                   |    38 |  1406 |    83   (5)| 00:00:01 |
    |*  2 |   HASH JOIN                   |                   |    38 |  1406 |    82   (4)| 00:00:01 |
    |   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 |  1102 |    11   (0)| 00:00:01 |
    |*  4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
    |*  5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   |  4224 | 33792 |    70   (3)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("PC"."DUNS_LOC"="D"."DUNS_LOC")
       4 - access("CTXSYS"."CONTAINS"("TEXT_KEY",:SEARCH,1)>0)
       5 - filter("PC"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
    SCOTT@orcl_11gR2> -- inline views (sub-queries in the from clause):
    SCOTT@orcl_11gR2> SELECT subset2.*
      2  FROM   (SELECT pc.duns_loc
      3            FROM   primary_contact pc
      4            WHERE  pc.emp_id = :employeeID) subset1,
      5           (SELECT score(1), d.*
      6            FROM   duns d
      7            WHERE  CONTAINS (TEXT_KEY, :search,1) > 0) subset2
      8  WHERE  subset1.duns_loc = subset2.duns_loc
      9  ORDER  BY score(1) DESC
    10  /
      SCORE(1)   DUNS_LOC TEXT_KEY
            18          1 highway
    1 row selected.
    Execution Plan
    Plan hash value: 153618227
    | Id  | Operation                     | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT              |                   |    38 |  1406 |    83   (5)| 00:00:01 |
    |   1 |  SORT ORDER BY                |                   |    38 |  1406 |    83   (5)| 00:00:01 |
    |*  2 |   HASH JOIN                   |                   |    38 |  1406 |    82   (4)| 00:00:01 |
    |   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 |  1102 |    11   (0)| 00:00:01 |
    |*  4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
    |*  5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   |  4224 | 33792 |    70   (3)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("PC"."DUNS_LOC"="D"."DUNS_LOC")
       4 - access("CTXSYS"."CONTAINS"("TEXT_KEY",:SEARCH,1)>0)
       5 - filter("PC"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
    SCOTT@orcl_11gR2> -- ansi join:
    SCOTT@orcl_11gR2> SELECT SCORE(1), duns.*
      2  FROM   duns
      3  JOIN   primary_contact
      4  ON     duns.duns_loc = primary_contact.duns_loc
      5  WHERE  CONTAINS (duns.text_key, :search, 1) > 0
      6  AND    primary_contact.emp_id = :employeeid
      7  ORDER  BY SCORE(1) DESC
      8  /
      SCORE(1)   DUNS_LOC TEXT_KEY
            18          1 highway
    1 row selected.
    Execution Plan
    Plan hash value: 153618227
    | Id  | Operation                     | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT              |                   |    38 |  1406 |    83   (5)| 00:00:01 |
    |   1 |  SORT ORDER BY                |                   |    38 |  1406 |    83   (5)| 00:00:01 |
    |*  2 |   HASH JOIN                   |                   |    38 |  1406 |    82   (4)| 00:00:01 |
    |   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 |  1102 |    11   (0)| 00:00:01 |
    |*  4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
    |*  5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   |  4224 | 33792 |    70   (3)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("DUNS"."DUNS_LOC"="PRIMARY_CONTACT"."DUNS_LOC")
       4 - access("CTXSYS"."CONTAINS"("DUNS"."TEXT_KEY",:SEARCH,1)>0)
       5 - filter("PRIMARY_CONTACT"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
    SCOTT@orcl_11gR2> -- old join:
    SCOTT@orcl_11gR2> SELECT SCORE(1), duns.*
      2  FROM   duns, primary_contact
      3  WHERE  CONTAINS (duns.text_key, :search, 1) > 0
      4  AND    duns.duns_loc = primary_contact.duns_loc
      5  AND    primary_contact.emp_id = :employeeid
      6  ORDER  BY SCORE(1) DESC
      7  /
      SCORE(1)   DUNS_LOC TEXT_KEY
            18          1 highway
    1 row selected.
    Execution Plan
    Plan hash value: 153618227
    | Id  | Operation                     | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT              |                   |    38 |  1406 |    83   (5)| 00:00:01 |
    |   1 |  SORT ORDER BY                |                   |    38 |  1406 |    83   (5)| 00:00:01 |
    |*  2 |   HASH JOIN                   |                   |    38 |  1406 |    82   (4)| 00:00:01 |
    |   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 |  1102 |    11   (0)| 00:00:01 |
    |*  4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
    |*  5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   |  4224 | 33792 |    70   (3)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("DUNS"."DUNS_LOC"="PRIMARY_CONTACT"."DUNS_LOC")
       4 - access("CTXSYS"."CONTAINS"("DUNS"."TEXT_KEY",:SEARCH,1)>0)
       5 - filter("PRIMARY_CONTACT"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
    SCOTT@orcl_11gR2> -- in clause:
    SCOTT@orcl_11gR2> SELECT SCORE(1), duns.*
      2  FROM   duns
      3  WHERE  CONTAINS (duns.text_key, :search, 1) > 0
      4  AND    duns.duns_loc IN
      5           (SELECT primary_contact.duns_loc
      6            FROM   primary_contact
      7            WHERE  primary_contact.emp_id = :employeeid)
      8  ORDER  BY SCORE(1) DESC
      9  /
      SCORE(1)   DUNS_LOC TEXT_KEY
            18          1 highway
    1 row selected.
    Execution Plan
    Plan hash value: 3825821668
    | Id  | Operation                     | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT              |                   |    38 |  1406 |    83   (5)| 00:00:01 |
    |   1 |  SORT ORDER BY                |                   |    38 |  1406 |    83   (5)| 00:00:01 |
    |*  2 |   HASH JOIN SEMI              |                   |    38 |  1406 |    82   (4)| 00:00:01 |
    |   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 |  1102 |    11   (0)| 00:00:01 |
    |*  4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
    |*  5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   |  4224 | 33792 |    70   (3)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("DUNS"."DUNS_LOC"="PRIMARY_CONTACT"."DUNS_LOC")
       4 - access("CTXSYS"."CONTAINS"("DUNS"."TEXT_KEY",:SEARCH,1)>0)
       5 - filter("PRIMARY_CONTACT"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
    SCOTT@orcl_11gR2>

  • Spatial Performance with join

    I have a Oracle Spatial table with 3.5 million rows plus another auxillary table with 3.5 million rows. A query over these two tables joined returns a full result (250 rows) based on one to one join - here's an example:
    Select count(*)
    from F, N
    where F.id = n.id and (F.GEOM,mdsys.sdo_geometry (2003,8307, null, mdsys.sdo_elem_info_array (1,1003,1), mdsys.sdo_ordinate_array(-120.0,49.5,-119.0,49.5,-119.0,60.35,-120.0,60.35,-120.0,49.5)),
    'mask= ANYINTERACT querytype=WINDOW') = 'TRUE') AND N.PNUM = '4';
    It takes an average of 35 seconds to get the full result set back. I've gathered statistics, tweaked memory parameters and this is the best I can get. Does anyone have any suggestions?

    This is an interesting problem. It looks like Oracle is doing the right thing for each of the table accesses - use the index and fetch by rowid.
    The only thing you have to play with if you don't go to materialized views or temp tables is how the results of the two table queries are joined.
    You don't have a lot of options. Hash join seems to be slow, but you don't know if it is faster or slower compared with nested loops or merge join.
    I'd compare what you have done with something like the following to test nested loops:
    select /*+ no_merge use_nl (f1,n1) */ count(*)
    from
    (select id
    from f
    where sdo_anyinteract ( F.GEOM,
    sdo_geometry (2003,8307, null, sdo_elem_info_array (1,1003,1),
    sdo_ordinate_array (-120.0,49.5,-119.0,49.5,-119.0,60.35,
    -120.0,60.35,-120.0,49.5))) = 'TRUE') f1,
    (select id
    from n
    where n.pnum='4') n1
    where f1.id=n1.id ;
    and presort with a merge join hint to see how it performs:
    select /*+ no_merge use_merge (f1,n1) */ count(*)
    from
    (select id
    from f
    where sdo_anyinteract ( F.GEOM,
    sdo_geometry (2003,8307, null, sdo_elem_info_array (1,1003,1),
    sdo_ordinate_array (-120.0,49.5,-119.0,49.5,-119.0,60.35,
    -120.0,60.35,-120.0,49.5))) = 'TRUE'
    order by id) f1,
    (select id
    from n
    where n.pnum='4'
    order by id) n1
    where f1.id=n1.id ;
    It might be that you already have the best Oracle can do, but I'd be curious to know how you make out.
    Dan Abugov
    VP Software Support and Services
    Acquis Inc.

  • Performance- Hash Joins ?

    Hi everyone,
    Version :- 10.1.0.5.0
    Below is the query and it takes long time to execute due to hash joins. Is there ant other way to change change the join approach or rewrite the SQL.
    Tables used
    rhs_premium :- 830 GB with partitons.
    bu_res_line_map :- small table 4 MB
    mgt_unit_res_line_map :- small table with 4 MB
    mgt_unit_reserving_lines :- View
    bu_reserving_lines :- View
    SELECT  prem.business_unit,
            prem.direct_assumed_ceded_code,
            prem.ledger_currency_code,
            prem.mcc_code,
            prem.management_unit,
            prem.product,
            prem.financial_product,
            nvl(prem.premium_in_ledger_currency,0) premium_in_ledger_currency,      -- NVL added Aug 21, 2008
            nvl(prem.premium_in_original_currency,0) premium_in_original_currency,  -- Added Aug 21, 2008  M4640
            nvl(prem.premium_in_us_dollars,0) premium_in_us_dollars,                -- NVL added Aug 21, 2008
            prem.rcc,
            prem.pre_explosion_rcc,                               -- Issue M1997 Laks 09/15
            prem.acc_code,
            prem.transaction_code,
            prem.accounting_period,
            prem.exposure_period,
            prem.policy_effective_month,
            prem.policy_key,
            prem.policy_line_of_business,
            prem.producer_code,
            prem.underwriting_year,
            prem.ledger_key,
            prem.account_key,
            prem.policy_coverage_key,
            nvl(prem.original_currency_code,' ') original_currency_code,   -- NVL added Issue M4640  Aug 21, 2008
            prem.authorized_unauthorized,
            prem.transaction_effective_date,
            prem.transaction_expiration_date,
            prem.exposure_year,
            prem.reinsurance_mask,
            prem.rcccategory,
            prem.rccclassification,
            prem.detail_level_indicator,
            prem.bermbase_level_indicator,
            prem.padb_level_indicator,
            prem.sas_level_indicator,                             -- Issue 443
            prem.cnv_adjust_indicator,                            -- Issue 413
            prem.originating_business_unit,
            prem.actuarial_blend_indicator,
            ml1.management_line_of_business_id management_lob_id_act,
            mu1.reserving_line_id mgt_unit_reserving_lob_id_act,
            bu1.reserving_line_id business_unit_lob_id_act,
            ml1.reserving_class_id mgt_unit_res_class_lob_id_act, -- added A12
            bl1.reserving_class_id business_unit_class_lob_id_act,-- added A12
            ml2.management_line_of_business_id management_lob_id_fin,
            mu2.reserving_line_id mgt_unit_reserving_lob_id_fin,
            bu2.reserving_line_id business_unit_lob_id_fin,
            ml2.reserving_class_id mgt_unit_res_class_lob_id_fin, -- added A12
            bl2.reserving_class_id business_unit_class_lob_id_fin -- added A12
      FROM rhs_premium prem,
            bu_res_line_map bu1,
            mgt_unit_res_line_map mu1,
            mgt_unit_reserving_lines ml1,
            bu_reserving_lines bl1,                               -- added A12
            bu_res_line_map bu2,
            mgt_unit_res_line_map mu2,
            mgt_unit_reserving_lines ml2,
            bu_reserving_lines bl2                                -- added A12
       WHERE  (      prem.business_unit = bu1.business_unit (+)
              AND  prem.product = bu1.product (+)
       AND  (      prem.management_unit = mu1.management_unit (+)
              AND  prem.product = mu1.product(+)
       AND  mu1.reserving_line_id = ml1.reserving_line_id (+)
       AND  bu1.reserving_line_id = bl1.reserving_line_id (+)    -- added A12
       AND  (      prem.business_unit = bu2.business_unit (+)
              AND  prem.financial_product = bu2.product (+)
       AND  (      prem.management_unit = mu2.management_unit (+)
              AND  prem.financial_product = mu2.product(+)
       AND  mu2.reserving_line_id = ml2.reserving_line_id (+)
       AND  bu2.reserving_line_id = bl2.reserving_line_id (+);
    PLAN_TABLE_OUTPUT
    Plan hash value: 3475794837
    | Id  | Operation                         | Name                     | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ  |IN-OUT| PQ Distrib |
    |   0 | SELECT STATEMENT                  |                          |   346M|   124G|   416K  (2)| 01:37:13 |       |       |        |      |            |
    |   1 |  PX COORDINATOR                   |                          |       |       |            |          |       |       |        |      |            |
    |   2 |   PX SEND QC (RANDOM)             | :TQ10008                 |   346M|   124G|   416K  (2)| 01:37:13 |       |       |  Q1,08 | P->S | QC (RAND)  |
    |*  3 |    HASH JOIN RIGHT OUTER          |                          |   346M|   124G|   416K  (2)| 01:37:13 |       |       |  Q1,08 | PCWP |            |
    |   4 |     BUFFER SORT                   |                          |       |       |            |          |       |       |  Q1,08 | PCWC |            |
    |   5 |      PX RECEIVE                   |                          |    46 |  1196 |     7   (0)| 00:00:01 |       |       |  Q1,08 | PCWP |            |
    |   6 |       PX SEND BROADCAST           | :TQ10000                 |    46 |  1196 |     7   (0)| 00:00:01 |       |       |        | S->P | BROADCAST  |
    |   7 |        VIEW                       | BU_RESERVING_LINES       |    46 |  1196 |     7   (0)| 00:00:01 |       |       |        |      |            |
    |   8 |         NESTED LOOPS OUTER        |                          |    46 |  1748 |     7   (0)| 00:00:01 |       |       |        |      |            |
    |*  9 |          TABLE ACCESS FULL        | RESERVING_LINES          |    46 |  1564 |     7   (0)| 00:00:01 |       |       |        |      |            |
    |* 10 |          INDEX UNIQUE SCAN        | RESERVING_CLASSES_PK     |     1 |     4 |     0   (0)| 00:00:01 |       |       |        |      |            |
    |* 11 |     HASH JOIN RIGHT OUTER         |                          |   346M|   116G|   415K  (2)| 01:37:04 |       |       |  Q1,08 | PCWP |            |
    |  12 |      BUFFER SORT                  |                          |       |       |            |          |       |       |  Q1,08 | PCWC |            |
    |  13 |       PX RECEIVE                  |                          |   124K|  2182K|    87   (2)| 00:00:02 |       |       |  Q1,08 | PCWP |            |
    |  14 |        PX SEND BROADCAST          | :TQ10001                 |   124K|  2182K|    87   (2)| 00:00:02 |       |       |        | S->P | BROADCAST  |
    |  15 |         TABLE ACCESS FULL         | BU_RES_LINE_MAP          |   124K|  2182K|    87   (2)| 00:00:02 |       |       |        |      |            |
    |* 16 |      HASH JOIN RIGHT OUTER        |                          |   346M|   110G|   415K  (2)| 01:36:54 |       |       |  Q1,08 | PCWP |            |
    |  17 |       BUFFER SORT                 |                          |       |       |            |          |       |       |  Q1,08 | PCWC |            |
    |  18 |        PX RECEIVE                 |                          |    46 |  1196 |     7   (0)| 00:00:01 |       |       |  Q1,08 | PCWP |            |
    |  19 |         PX SEND BROADCAST         | :TQ10002                 |    46 |  1196 |     7   (0)| 00:00:01 |       |       |        | S->P | BROADCAST  |
    |  20 |          VIEW                     | BU_RESERVING_LINES       |    46 |  1196 |     7   (0)| 00:00:01 |       |       |        |      |            |
    |  21 |           NESTED LOOPS OUTER      |                          |    46 |  1748 |     7   (0)| 00:00:01 |       |       |        |      |            |
    |* 22 |            TABLE ACCESS FULL      | RESERVING_LINES          |    46 |  1564 |     7   (0)| 00:00:01 |       |       |        |      |            |
    |* 23 |            INDEX UNIQUE SCAN      | RESERVING_CLASSES_PK     |     1 |     4 |     0   (0)| 00:00:01 |       |       |        |      |            |
    |* 24 |       HASH JOIN RIGHT OUTER       |                          |   346M|   101G|   414K  (1)| 01:36:45 |       |       |  Q1,08 | PCWP |            |
    |  25 |        BUFFER SORT                |                          |       |       |            |          |       |       |  Q1,08 | PCWC |            |
    |  26 |         PX RECEIVE                |                          |   124K|  2182K|    87   (2)| 00:00:02 |       |       |  Q1,08 | PCWP |            |
    |  27 |          PX SEND BROADCAST        | :TQ10003                 |   124K|  2182K|    87   (2)| 00:00:02 |       |       |        | S->P | BROADCAST  |
    |  28 |           TABLE ACCESS FULL       | BU_RES_LINE_MAP          |   124K|  2182K|    87   (2)| 00:00:02 |       |       |        |      |            |
    |* 29 |        HASH JOIN RIGHT OUTER      |                          |   346M|    96G|   413K  (1)| 01:36:35 |       |       |  Q1,08 | PCWP |            |
    |  30 |         BUFFER SORT               |                          |       |       |            |          |       |       |  Q1,08 | PCWC |            |
    |  31 |          PX RECEIVE               |                          |    46 |  1794 |    11  (10)| 00:00:01 |       |       |  Q1,08 | PCWP |            |
    |  32 |           PX SEND BROADCAST       | :TQ10004                 |    46 |  1794 |    11  (10)| 00:00:01 |       |       |        | S->P | BROADCAST  |
    |  33 |            VIEW                   | MGT_UNIT_RESERVING_LINES |    46 |  1794 |    11  (10)| 00:00:01 |       |       |        |      |            |
    |* 34 |             HASH JOIN OUTER       |                          |    46 |  1886 |    11  (10)| 00:00:01 |       |       |        |      |            |
    |* 35 |              TABLE ACCESS FULL    | RESERVING_LINES          |    46 |  1564 |     7   (0)| 00:00:01 |       |       |        |      |            |
    |  36 |              TABLE ACCESS FULL    | RESERVING_CLASSES        |   107 |   749 |     3   (0)| 00:00:01 |       |       |        |      |            |
    |* 37 |         HASH JOIN RIGHT OUTER     |                          |   346M|    83G|   413K  (1)| 01:36:26 |       |       |  Q1,08 | PCWP |            |
    |  38 |          BUFFER SORT              |                          |       |       |            |          |       |       |  Q1,08 | PCWC |            |
    |  39 |           PX RECEIVE              |                          | 93763 |  1648K|    59   (0)| 00:00:01 |       |       |  Q1,08 | PCWP |            |
    |  40 |            PX SEND BROADCAST      | :TQ10005                 | 93763 |  1648K|    59   (0)| 00:00:01 |       |       |        | S->P | BROADCAST  |
    |  41 |             INDEX FAST FULL SCAN  | MGT_UNIT_RES_LINE_MAP_UK | 93763 |  1648K|    59   (0)| 00:00:01 |       |       |        |      |            |
    |* 42 |          HASH JOIN RIGHT OUTER    |                          |   346M|    77G|   412K  (1)| 01:36:17 |       |       |  Q1,08 | PCWP |            |
    |  43 |           BUFFER SORT             |                          |       |       |            |          |       |       |  Q1,08 | PCWC |            |
    |  44 |            PX RECEIVE             |                          |    46 |  1794 |    11  (10)| 00:00:01 |       |       |  Q1,08 | PCWP |            |
    |  45 |             PX SEND BROADCAST     | :TQ10006                 |    46 |  1794 |    11  (10)| 00:00:01 |       |       |        | S->P | BROADCAST  |
    |  46 |              VIEW                 | MGT_UNIT_RESERVING_LINES |    46 |  1794 |    11  (10)| 00:00:01 |       |       |        |      |            |
    |* 47 |               HASH JOIN OUTER     |                          |    46 |  1886 |    11  (10)| 00:00:01 |       |       |        |      |            |
    |* 48 |                TABLE ACCESS FULL  | RESERVING_LINES          |    46 |  1564 |     7   (0)| 00:00:01 |       |       |        |      |            |
    |  49 |                TABLE ACCESS FULL  | RESERVING_CLASSES        |   107 |   749 |     3   (0)| 00:00:01 |       |       |        |      |            |
    |* 50 |           HASH JOIN RIGHT OUTER   |                          |   346M|    65G|   411K  (1)| 01:36:08 |       |       |  Q1,08 | PCWP |            |
    |  51 |            BUFFER SORT            |                          |       |       |            |          |       |       |  Q1,08 | PCWC |            |
    |  52 |             PX RECEIVE            |                          | 93763 |  1648K|    59   (0)| 00:00:01 |       |       |  Q1,08 | PCWP |            |
    |  53 |              PX SEND BROADCAST    | :TQ10007                 | 93763 |  1648K|    59   (0)| 00:00:01 |       |       |        | S->P | BROADCAST  |
    |  54 |               INDEX FAST FULL SCAN| MGT_UNIT_RES_LINE_MAP_UK | 93763 |  1648K|    59   (0)| 00:00:01 |       |       |        |      |            |
    |  55 |            PX BLOCK ITERATOR      |                          |   346M|    59G|   411K  (1)| 01:35:58 |     1 |   385 |  Q1,08 | PCWC |            |
    |  56 |             TABLE ACCESS FULL     | RHS_PREMIUM_1            |   346M|    59G|   411K  (1)| 01:35:58 |     1 |   385 |  Q1,08 | PCWP |            |
    Predicate Information (identified by operation id):
       3 - access("BU2"."RESERVING_LINE_ID"="BL2"."RESERVING_LINE_ID"(+))
       9 - filter("RL"."RESERVING_LINE_TYPE"='BU')
      10 - access("RL"."RESERVING_CLASS_ID"="RC"."RESERVING_CLASS_ID"(+))
      11 - access("PREM"."BUSINESS_UNIT"="BU2"."BUSINESS_UNIT"(+) AND "PREM"."FINANCIAL_PRODUCT"="BU2"."PRODUCT"(+))
      16 - access("BU1"."RESERVING_LINE_ID"="BL1"."RESERVING_LINE_ID"(+))
      22 - filter("RL"."RESERVING_LINE_TYPE"='BU')
      23 - access("RL"."RESERVING_CLASS_ID"="RC"."RESERVING_CLASS_ID"(+))
      24 - access("PREM"."BUSINESS_UNIT"="BU1"."BUSINESS_UNIT"(+) AND "PREM"."PRODUCT"="BU1"."PRODUCT"(+))
      29 - access("MU2"."RESERVING_LINE_ID"="ML2"."RESERVING_LINE_ID"(+))
      34 - access("RL"."RESERVING_CLASS_ID"="RC"."RESERVING_CLASS_ID"(+))
      35 - filter("RL"."RESERVING_LINE_TYPE"='MCC')
      37 - access("PREM"."MANAGEMENT_UNIT"="MU2"."MANAGEMENT_UNIT"(+) AND "PREM"."FINANCIAL_PRODUCT"="MU2"."PRODUCT"(+))
      42 - access("MU1"."RESERVING_LINE_ID"="ML1"."RESERVING_LINE_ID"(+))
      47 - access("RL"."RESERVING_CLASS_ID"="RC"."RESERVING_CLASS_ID"(+))
      48 - filter("RL"."RESERVING_LINE_TYPE"='MCC')
      50 - access("PREM"."MANAGEMENT_UNIT"="MU1"."MANAGEMENT_UNIT"(+) AND "PREM"."PRODUCT"="MU1"."PRODUCT"(+))Please let me know if there is any possibilty.
    Regards,
    Sandy

    Big query - 9 tables, outer joins, parallel query option. Reading/joining views - steps 7, 20, etc?
    if you are reading most of the rows in both tables then hash joins are probably the most efficient way to read the data. The parallel query option may or may not be helping.
    Outer joins usually make queries slower. Views can also have th same effect, and will probably affect the execution plan.
    If you are reading views you can eliminate them by using the base tables to see how that affects performance. You can change the session parameter for DB_FILE_MULTIBLOCK_READ COUNT for more efficient full table scans if its set (the documentation and blog articles claim leaving it unset in the database is the most efficient use).
    Edited by: riedelme on Jun 6, 2011 8:26 AM

  • Performance with join

    Hi,
    Could you please give me tips to improve the performmance of the following joins.
    SELECT ekbe~ebeln
               ekbe~ebelp
               ekbe~vgabe
               ekbe~matnr
               ekbe~menge
               ekbe~shkzg
               ekpo~werks
               ekpo~meins
               ekpo~afnam
               ekpo~lgort
               INTO TABLE i_temp
               FROM ekbe
               INNER JOIN ekpo ON  ekpoebeln = ekbeebeln AND
                                   ekpoebelp = ekbeebelp
                            WHERE  ekbe~cpudt IN s_date    AND
                                   ekpo~werks IN s_werks   AND
                                   ekbe~ebeln IN s_ebeln   AND
                                   ( ekbe~vgabe EQ '1' )   OR
                                   ( ekbe~vgabe EQ '6' )
                                    GROUP BY
                                    ekbe~ebeln
                                    ekbe~ebelp
                                    ekbe~vgabe
                                    ekbe~matnr
                                    ekbe~menge
                                    ekbe~shkzg
                                    ekpo~werks
                                    ekpo~meins
                                    ekpo~afnam
                                    ekpo~lgort.
      DELETE i_temp WHERE werks NOT IN s_werks  .
      DELETE i_temp WHERE ebeln NOT IN s_ebeln.
    Thanks & regards
    Frank

    Hi frank,
    1. why do you want to use GROUP By ?
    2. u are not using any aggregate functions in sql
       like sum, count etc.
    3. so if not required, you may remove
      group by,
       it will improve the performance a lot.
    4.Further i think that
      the BRACKETS for OR
      are misplace. it should be like this :
    ekpo~lgort
    INTO TABLE i_temp
    FROM ekbe
    INNER JOIN ekpo ON ekpoebeln = ekbeebeln AND
    ekpoebelp = ekbeebelp
    WHERE ekbe~cpudt IN s_date AND
    ekpo~werks IN s_werks AND
    ekbe~ebeln IN s_ebeln AND
    <b>( ekbevgabe EQ '1'  OR  ekbevgabe EQ '6' )</b>
    GROUP BY
    regards,
    amit m.

  • How does one perform Cursor joins in DPL?

    How does one navigate the API to do cursor joins? Can one do it and still exploit DPL concepts, or must one keep open a separate low-level BDB Database?

    Hi Jdf,
    Since you said "cursor joins" I assume you are familiar with the base BDB API that provides joins via cursors. In DPL the same functionality is provided by using the EntityJoin class. Instead of cursors, you specify the secondary key values, but the result is the same. An underlying cursor join is performed for you.
    Mark

  • Joining datasets in template

    Hi all,
    I have a requirement of joining two data sets in a template.
    I have to create a table in template with the combined xml output of 2 queries.
    I need to join one column(say 'idnumber' ) in one data set to the column('sidnumber') in another dataset and so that idname should appear in one of the fields in the template after joining.
    can any one throw light on this issue asap please

    I have a requirement this way:
    I have xml as shown below:
    <DATA>
    <SQL>
    <SQL_ROW>
    <c1>99384</c1>
    <c2>QWEHJ</c2>
    <c3>737272</c3>
    <c4>-2342345</c4>
    </SQl_ROW>
    <SQL_ROW>
    <c1>34535</c1>
    <c2>dfgsdf</c2>
    <c3>737272</c3>
    <c4>-2342345</c4>
    </SQl_ROW>
    <SQL_ROW>
    <c1>99384</c1>
    <c2>QWEHJ</c2>
    <c3>737272</c3>
    <c4>-2342345</c4>
    </SQl_ROW>
    <SQL>
    <fc_map>
    <fc_map_row>
    <f1>34535</f1>
    <f2>ABCD</f2>
    </fc_map_row>
    <fc_map_row>
    <f1>34534</f1>
    <f2>DFDF</f2>
    </fc_map_row>
    <fc_map_row>
    <f1>4524</f1>
    <f2>FSSDSFDFWE</f2>
    </fc_map_row>
    </fc_map>
    </DATA>
    I have to put a condition for a field to match the f1,c1 columns
    I need to join the columns f1 and c1 such that the field in the rtf gives the name after joining. its is in such a way that, the customer id lies in one data set and customer name lies in other dataset and we need to join the two datasets by customerid and hence the name of the customer is displayed in the report.

  • Performing multiple joins on table

    Hi all,
       I would like to know if performing joins on more than 10 tables has some performance issues? If so, is there any limit on the joins that can be done?
    Is there another way out for this problem?

    Rob Burbank wrote:>
    > >
    Thomas Zloch wrote:
    > > If I had to bet, I'd say no, not included...do you have time to try out with a little test program?
    > Probably not so little, but maybe sometime. I know there are standard SAP views with upwards of 13 or 14 tables, but I doubt if they would be compatable for joining.
    >
    > Rob
    How about a self join? 

  • How to retrieve data from a dimension that is not directly joined to a fact

    Hi,
    In my case I have 2 dimensions and one fact. I need to runa report collecting data from all the three tables.
    I need to do the following.
    DIMA DIMB FACT1
    FACT1 is joined with DIMA
    DIMA is joined with DIMB
    FACT1 is not Joined with DIMB.
    My report should still retrieve information from DIMB by connecting FACT1 with DIMA and retrieve corresponding data from DIMB.
    Please suggest how can I do this .
    I am using 10.1.3 version of OBIEE
    You help will be much appreciated.

    Hi,
    I think your data model is snow-flake schema,we can get the data from snow-flake schema also.Pull the columns from both fact and DIMB into criteria.It will display the result.
    mark if helpful/correct...
    thanks,
    prassu

  • Why oh why, weird performance on joining large tables

    Hello.
    I have a large table cotaining dates and customer data. Organised as:
    DATE CUSTOMER_ID INFOCOLUMN1 INFOCOLUMN2 etc...
    Rows per date are a couple of million.
    What I'm trying to do is to make a comparison between date a and date b and track changes in the database.
    When I do a:
    SELECT stuff
    FROM table t1
    INNER JOIN table t2
      ON t1.CUSTOMER_ID = t2.CUSTOMER_ID
    WHERE t1.date = TO_DATE(SOME_DATE)
    AND t2.date = TO_DATE(SOME_OTHER_DATE)I get a result in about 40 seconds which is acceptable.
    Then I try doing:
    SELECT stuff
    FROM (SELECT TO_DATE(LAST_DAY(ADD_MONTHS(SYSDATE, 0 - r.l))) AS DATE FROM dual INNER JOIN (SELECT level l FROM dual CONNECT BY LEVEL <= 1) r ON 1 = 1) time
    INNER JOIN table t1
      ON t1.date = time.date
    INNER JOIN table t2
      ON t1.CUSTOMER_ID = t2.CUSTOMER_ID
    WHERE t2.date = ADD_MONTHS(time.date, -1)Ie i generate a datefield from a subselect which I then use to join the tables with.
    When I try that the query takes an hour or two to complete with the same resultset as the first example.
    THe only difference is that in the first case I give the dates literally but in the other case I generate them in the subselect. It's the same dates and they are formatted as dates in both cases.
    Any ideas?
    Thanks
    Edited by: user1970293 on 2010-apr-29 00:52
    Edited by: user1970293 on 2010-apr-29 00:59

    When I try that the query takes an hour or two to complete with the same resultset as the first example.If you get the same results, than why change the query to the second one?
    THe only difference is that in the first case I give the dates literally but in the other case I generate them in the subselect. It's the same dates and they are formatted as dates in both cases.Dates are dates,... the formatting is just "pretty"
    This
    select to_date(last_day(add_months(sysdate
                                      ,0 - r.l)))
      from dual
    inner join (select level l from dual connect by level <= 1) r on 1 = 1doesn't make much sense... what is it supposed to do?
    (by the way: you are doing a TO_DATE on a DATE...)

Maybe you are looking for

  • What is the best photo paper 4'x6' for HP Officejet Pro 8500A Plus e-All-in-one Printer?

    1.-HP Officejet Pro 8500A Plus e-All-in-One Printer 2.-OS: Windows 7-64 3.-No error messages 4.-No changes have been made 5.-I have been printing in my with old "hp premium plus glossyphoto paper" and getting very dark photos and too much  wasted ink

  • Flash page scrollbar.

    Pleeeeeeaaaaaaseeeeeee Help! I have a flash movie which is taller than the browser window, but rather than it being scrolled by the browsers default scrollbar I want to create a scrollbar swf file which will control the scrolling of the movie within

  • Kernel Upgrade for old SAP Ides system

    HI, How I need to install 4.6c Kernel 4.6d patch level 948 on the following system SAP Ides - R/3 4.C SAP Package level 534 Support Package Manager  version 4.6c/0028 Oracle 8.1.7.0.0 ABAB Load 1258 Kernel 46D Could someone please tell me what I need

  • How to trasnfer my PhonePower number to my skype?

    Hi There, I have a number with another provided  (phone power). I do not use the number other than forward the calls to my skype number. So I am paying for phone power service every month and also paying for my skype number. I need to keep the PhoneP

  • External Definations

    I want to add one extra field in one  particular message in External defination,how I should go for it? I want detail process to go forward with it.