Performance over join..

me using these three select
this taking hell lot of time.. any ways to improve these..
for all entries taking more then tht.. so please dont suggest tht.
its critial issue help me out..
SELECT BWERKS AVBELN B~MATNR
           AFKDAT ASPART AVTWEG AERDAT A~ERZET
           BVGBEL BAUBEL
           A~FKART              "Added by Arun pandey 08/05/2007
           BNETWR BFKIMG B~MWSBP
           FROM VBRP AS B
           JOIN VBRK AS A ON AVBELN = BVBELN INTO TABLE IT_INV
           WHERE A~FKART IN S_FKART
             AND ( ASPART IN S_SPART AND ASPART <> 'ST' )
             AND A~FKDAT IN S_FKDAT
             AND ( AVTWEG IN S_VTWEG AND AVTWEG <> 'ST' )
             AND A~FKSTO <> 'X'
             AND A~KUNAG IN S_CUST
             AND B~WERKS = S_WERKS.
SELECT AVBELN BPOSNR BMATNR BVGBEL AKUNNR AERDAT A~ERZET
           ALFDAT BLFIMG
           FROM LIKP AS A JOIN LIPS AS B ON AVBELN = BVBELN
           INTO TABLE IT_DELV
           FOR ALL ENTRIES IN IT_INV
           WHERE A~VBELN = IT_INV-VGBEL
           AND B~MATNR = IT_INV-MATNR.
SELECT AVBELN ABSTNK AAUART AKUNNR
             AVKBUR AVKGRP BNAME1 BORT01
             FROM VBAK AS A JOIN KNA1 AS B ON AKUNNR = BKUNNR
             INTO TABLE IT_ORDER
             FOR ALL ENTRIES IN IT_DELVHEAD
             WHERE A~VBELN = IT_DELVHEAD-VGBEL.

Hi,
Check for not initial condition of internal tables before your select statements which use "For all entries in" , else if its initial, its going to pick up the complete table entries.
Shruthi

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.

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

  • Looking for help to improve Airport performance over LAN (WAN is fine)

    Ok, I've read through several threads on this forum that address problems people are having with slow performance with Airport. I've also checked out all of the Apple KBs that address Airport, recommended settings. Unfortunately my issue isn't addressed by anything I've read to date.
    The bottom line is that both download and upload performance between any of my devices and the internet is fine, no problems. I am paying for 30MBps download from Verizon FIOS, I routinely get 20, and I'm guessing that the delta is Verizon's problem, not my network's. However, streaming from my media server to another device on the wireless LAN is a different story entirely. I get somewhere between 1 and 2 MBps, tops, and this poses big problems for streaming music and movies.
    My network is comprised of 3 Airport Expresses. One of them is a MC414LL/A model. This one is connected to my Verizon FIOS Actiontec MI424WR router (which I have set to bridge-mode according to the instructions provided at http://www.dslreports.com/forum/r17679150-Howto-make-ActionTec-MI424WR-a-network -bridge) via CAT5 ethernet. This Airport Express is set to "create a network" network mode, "802.11 only (5GHz) - 802.11b/g/n" radio mode (although I have also tried "802.11 only (5GHz) - 802.11/n only (2.4 GHz)" radio mode, and this didn't solve the problem). Finally, I have chosen 2.4 and 5GHz channels that have little interference (2 and 161 respectively). My other two Airport Expresses are MB321LL/A models and are set to "Extend a wireless network" network mode, with the 5GHz network chosen as the network that they extend. (I have tried switching over to having them extend the 2.4GHz network, and performance gets worse, not better.)
    I am using a late 2009 Mac Mini as a media server. It is connected to the 5GHz network (though I've tried the 2.4GHz network), and it runs XBMC and JRiver media servers (not simultaneously, either one or the other.) I have a PS3 and a Sony Blu Ray player, each plugged into one of the MB321LL/A Airport Expresses via CAT5 ethernet, and I stream media to each of these devices via one or the other media server (both devices are DNLA-enabled). My Mac Mini has a 3TB external hard drive connected via FireWire 800, which is where all of my media resides. In addition to streaming media over the network, I have a TV plugged directly into the Mac Mini. When I play media to this TV, performance is outstanding, so I'm confident my poor performance to the PS3 and Sony BDP is a network issue, not an issue with the external drive.
    Although my building has several other wireless networks, only one of them is 5 GHz, and it isn't using channel 161. The 2.4 GHz band is crowded with several networks, although channel 2 is usually in the clear. I have tried switching let Airport choose a channel automatically, and I haven't noticed a difference. It has occurred to me that the problem could be with how I bridged the Verizon Actiontec router and not with any of the Airports, but I don't get any errors (e.g. double NAT errors, which some people who have bridged improperly get), and I am pleased with my download and upload speeds to the internet. The issue is only on my LAN. Finally, yes, all of my firmware is up to date, version 7.6.3 on all three Airport Expresses.
    Can anyone offer me suggestions for how I can get better performance streaming media from my server to the two playback devices? Since all 3 Airport Expresses support 5GHz, I'd have thought I'd be able to take advantage of 802.11n speeds when streaming between them. (MB321LL/A  supports "Draft N", but does this matter?) With the settings that I'm currently using, I can't stream faster than 2MBps (and that's on a good day), which is below what I ought to be able to get rom 802.11g. This is especially problematic when I try to stream hi res (96 MHz / 24 bit or higher)  music files, whether uncompressed or compressed. I hear awful pulsing sounds through my speakers. If I pause the track and let my streaming device buffer, I might get 10 or 15 seconds of clean playback, but then it starts the pulsing again as soon as the buffered music is finished playing. On occasion when I stream music from my iPhone via Airplay to one of the Airport Expresses, I get clean playback most of the time, but on occasion the music cuts out. (It's my understanding the Airplay requires ~800 Kbps, which seems consistent with my LAN speed usually being between 1 and 2 Mbps but sometimes dropping).
    I have iStubler and I've used the Apple network diagnostics -- these are the tools that led me to choose channels 2 and 161 for 2.4 and 5GHz respectively. I'm sure I could be using these tools to learn more about my network's performance, but I'm sure what to look for.
    Thanks for your suggestions.

    Ok, cool. I'm really glad that the issue has been isolated. Thanks a ton for your insight!
    Hopefully I can find a spot where the signal strength of the hub is noticably better but that isn't too inconvenient for an ethernet run. My Sony BDP, which is the device connected to the problem basestation, has wifi capability, so I could always ditch the ethernet cable if the best spot for the basestation doesn't permit a cable run. But I'm aware that ethernet usually offers faster transfer speeds than wifi. Moreover, I'm not sure that the Sony BDP supports 5GHz. It might be a 2.4GHz-only device, in which case I'll have new interference issues to contend with, since like I said in my original post, there are several other 2.4GHz networks in my building.
    Anyhow, now that I understand the problem, I can figure out a solution. Thanks again.

  • How can I improve performance over a Branch Office IPsec vpn tunnel between and SA540 and an SA520

    Hello,
    I just deployed one Cisco SA540 and three SA520s.
    The SA540 is at the Main Site.
    The three SA520s are the the spoke sites.
    Main Site:
    Downstream Speed: 32 Mbps
    Upstream Speed: 9.4 Mbps
    Spoke Site#1:
    Downstream Speed: 3.6 Mbps
    Upstream Speed: 7.2 Mbps (yes, the US is faster than the DS at the time the speed test was taken).
    The SA tunnels are "Established"
    I see packets being tranmsitted and received.
    Pinging across the tunnel has an average speed of 32 ms (which is good).
    DNS resolves names to ip addresses flawlessly and quickly across the Inter-network.
    But it takes from 10 to 15 minutes to log on to the domain from the Spoke Site#1 to the Main Site across the vpn tunnel.
    It takes about 15 minutes to print across the vpn tunnel.
    The remedy this, we have implemented Terminal Services across the Internet.
    Printing takes about 1 minute over the Terminal Service Connection, while it takes about 15 minutes over the VPN.
    Logging on to the network takes about 10 minutes over the vpn tunnel.
    Using an LOB application takes about 2 minutes per transaction across the vpn tunnel; it takes seconds using Terminal Services.
    I have used ASAs before in other implementation without any issues at all.
    I am wondering if I replaced the SAs with ASAs, that they may fix my problem.
    I wanted to go Small Business Pro, to take advantage of the promotions and because I am a Select Certified Partner, but from my experience, these SA vpn tunnels are unuseable.
    I opened a case with Small Business Support on Friday evening, but they couldnt even figure out how to rename an IKE Policy Name (I figured out that you had to delete the IKE Policy; you cannot rename them once they are created).
    Maybe the night weekend shift has a skeleton crew, and the best engineers are available at that time or something....i dont know.
    I just know that my experience with the Cisco TAC has been great for the last 10 years.
    My short experience with the Cisco Small Business Support Center has not been as great at all.
    Bottom Line:
    I am going to open another case with the Day Shift tomorrow and see if they can find a way to speed things up.
    Now this is not just happening between the Main Site and Spoke Site #1 above. It is also happeninng between the Main Site and Spoke #2 (I think Spoke#2 has a Download Speed of about 3Mbps and and Upload Speed of about 0.5 Mbps.
    Please help.
    I would hate to dismiss SA5xx series without making sure it is not just a simple configuration setting.

    Hi Anthony,
    I agree!.  My partner wants to just replace the SA5xxs with ASAs, as we have never had problems with ASA vpn performance.
    But I want to know WHY this is happening too.
    I will definitely run a sniffer trace to see what is happening.
    Here are some other things I have learned from the Cisco Small Business Support Center (except for Item 1 which I learned from you!)
    1.  Upgrade the SA540 at the Main Site to 2.1.45.
    2a. For cable connections, use the standard MTU of 1500 bytes.
    2.b For DSL, use the following command to determine the largets MTU that will be sent without packet fragmentation:
    ping -f -l packetsize
    Perform the items below to see if this increases performance:
    I was told by the Cisco Small Business Support Center that setting up a Manual Policy is not recommended; I am not sure why they stated this.
    3a. Lower the IKE encryption algorithm from "AES-128" to DES.
    3b. Lower the IKE authentication algorithm to MD5
    3c. Also do the above for the VPN Policy
    Any input is welcome!

  • 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

  • Performance over DG from mysql to oracle very slow for inserts

    configured het services over gateway from oracle 11.2.0.4 to mysql 5.6
    Have a table I want to pull over into oracle.  1000 rows.
    On mysql : create view vw_mysql_t1 as select columns from my_mysql_table.    
    On Oracle:  create view vw_ora as select columns from  vw_mysql_t1@mysql_link
    On oracle: select * from vw_ora data returns data in 3-4 seconds. 
    however, try an insert to get the data over
         insert into a_table_on_oracle
             (select * from vw_ora)
    takes 11-12 minutes.     
    create table as or insert into same performance.  Tried just inserting 1 row  and same performance 11-12 minutes.  any ideas?

    cant seem to get the trace file to generate.  any ideas, I have the config as below, the gateway is working, I can select data no problem from table@dcv   , just performance is terrible
    logfile not in $ORACLE_HOME/hs/log
    or
    /tmp
    this is my tns
    dcv =
      (DESCRIPTION =
        (ADDRESS = (PROTOCOL = tcp)(HOST = <IP of server>)(PORT = 1521))
        (CONNECT_DATA =
          (SID = dcv)
        (HS = OK)
    this is my init file
    # HS init parameters
    HS_FDS_CONNECT_INFO=dcv
    HS_FDS_TRACE_LEVEL=255
    HS_FDS_SHAREABLE_NAME = /usr/lib64/libmyodbc5a.so
    HS_RPC_FETCH_SIZE=50000               
    HS_ROWID_CACHE_SIZE=10000
    #HS_LONG_PIECE_TRANSFER_SIZE=1024
    HS_LONG_PIECE_TRANSFER_SIZE=65536
    HS_LANGUAGE=AMERICAN_AMERICA.WE8ISO8859P15    ## The Oracle RDBMS is using a Unicode characterset [ID 756186.1]
    HS_FDS_FETCH_ROWS=1                           ## This is select int datatype
    HS_FDS_SQLLEN_INTERPRETATION=32               ## This is to select NULL values via DB Link [ID 554409.1]
    # ODBC specific environment variables
    set ODBCINI=/etc/odbc.ini
    more /etc/odbc.ini
    [dcv]
    Driver       = /usr/lib64/libmyodbc5a.so
    SERVER       = <IP of mysql server>
    PORT         = 3306
    USER         = un
    Password     = pw
    Database     = dcv
    OPTION       = 3
    CHARSET      = latin1
    [ODBC]
    TRACE        = ON     # also tried 0 and 1 and DEBUG and USER
    TraceFile    = /tmp/odbc.trace
    10:11:19 SQL> select count(*) from "vw_t1"@dcv;
      COUNT(*)
         24794
    Elapsed: 00:00:00.23
    10:11:45 SQL>
    10:11:57 SQL>
    10:11:57 SQL>
    10:11:57 SQL>
    10:11:57 SQL>
    10:11:58 SQL> create table backup_data.delete_me as
    10:11:59   2  select   * from
    10:11:59   3        "vw_t1"@dcv;
    Table created.
    Elapsed: 00:09:47.07
    10:21:49 SQL>
    Theres around 130 columns, varchars, numerics and floats.  Is there a conversion going on that would take that long?

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

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

  • Efficiency of using Views over Joins

    Hi All,
    Which is the most efficient way for selecting data for the following scenario :
    Selecting data from three tables using JOINs alongwith FOR ALL ENTRIES or using the View for the same(as the View is available).
    Performance wise, which is better?
    Thanks,
    Arshad

    Arshad,
    Inner Join VS Outer Join:
    TABEL1 inner join TABLE2:
    only entries found in TABLE1 and TABLE2 are the result.
    TABEL1 outher join TABLE2:
    all entries found in TABLE1 and, if found the corresponding data from TABLE2 are the result.
    For inner and outer join see the below thread:
    difference..inner join and outer join
    Views : Data about an application object is often distributed on several tables. By defining a view, you can define an application-dependent view that combines this data. The structure of such a view is defined by specifying the tables and fields used in the view. Fields that are not required can be hidden, thereby minimizing interfaces. A view can be used in ABAP programs for data selection.
    For View see the below thread:
    Regarding Creating views
    http://help.sap.com/saphelp_nw2004s/helpdata/en/cf/21ec77446011d189700000e8322d00/frameset.htm
    ex for inner join:
    Table 1 Table 2
    A
    B
    C
    D
    D
    E
    F
    G
    H
    a1
    b1
    c1
    1
    1
    e1
    f1
    g1
    h1
    a2
    b2
    c2
    1
    3
    e2
    f2
    g2
    h2
    a3
    b3
    c3
    2
    4
    e3
    f3
    g3
    h3
    | a4 | b4 | c4 | 3 | |--||||--|
    Inner Join
    A
    B
    C
    D
    D
    E
    F
    G
    H
    a1
    b1
    c1
    1
    1
    e1
    f1
    g1
    h1
    a2
    b2
    c2
    1
    1
    e1
    f1
    g1
    h1
    | a4 | b4 | c4 | 3 | 3 | e2 | f2 | g2 | h2 |
    here common field is 'D' in both tables. after the inner join only the records from both the tables come where the D values in both the tables are same.
    ex for outer join:
    Table 1 Table 2
    A
    B
    C
    D
    D
    E
    F
    G
    H
    a1
    b1
    c1
    1
    1
    e1
    f1
    g1
    h1
    a2
    b2
    c2
    1
    3
    e2
    f2
    g2
    h2
    a3
    b3
    c3
    2
    4
    e3
    f3
    g3
    h3
    | a4 | b4 | c4 | 3 | |--||||--|
    Left Outer Join
    A
    B
    C
    D
    D
    E
    F
    G
    H
    a1
    b1
    c1
    1
    1
    e1
    f1
    g1
    h1
    a2
    b2
    c2
    1
    1
    e1
    f1
    g1
    h1
    a3
    b3
    c3
    2
    NULL
    NULL
    NULL
    NULL
    NULL
    | a4 | b4 | c4 | 3 | 3 | e2 | f2 | g2 | h2 |
    here all the records of table 1 come and if D value does not match in table 2 it is filled with NULL value.
    View is a combination of 2 or more tables, only in the run time it contains data.
    Pls. Mark if useful

  • 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

Maybe you are looking for

  • Problems after transfering Cost centers with LSMW

    Hi, I have a problem after transfering Cost Centers with LSMW. The first Batch input run created all cost centers in one CC Group erroneously - cause they should be placed in different CC groups. I changed LSMW settings and made another batch input r

  • Oracle forms display bright white flash when transitioning between forms.

    We recently migrated an application from Oracle Application Server to WebLogic and we are noticing that in the WebLogic environment while transitioning between forms there is a quick bright white flash that has caused several complaints. We are not s

  • Handling big files

    i have file sizes over 100MB to process some transactions. when i open it at one shot, it runs out of memory. i tried opening and splitting it into 1MB each. Even then since the memory is accumulated, it runs out of memory. Is there a way i can open

  • Link Icon in AVL grid

    Hai all,    I want to display a icon or link in AVL grid . In that icon click i want to navigate to another view. Could any body tell me how to do this Regards, Arun

  • Upgrading from 4402 to 5508

    Does anyone know of, or have any instructions on performing an upgrade from a 4402 to 5508?