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 Regardsyou 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> -
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 -
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,
SandyBig 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 -
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
FrankHi 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 aboveHi,
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,
ArshadArshad,
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
-
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
-
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
-
Does anyone know of, or have any instructions on performing an upgrade from a 4402 to 5508?