Performance - direct joins vs joining datasets
Which is better way to build query and which would give better performance
select * from A, B
where A.id=B.id
or select * from
(select * from A), (select * from B)
join on A.id =B.id
Essentially, join directly on tables or get results and join the datasets. This might too simplistic a example above
Hi,
927740 wrote:
Which is better way to build query and which would give better performance
select * from A, B
where A.id=B.idThat's the best way to do it.
or select * from
(select * from A), (select * from B)
join on A.id =B.idThis won't work. Table A is only in scope in the first (unnamed) in-line view, and B is only in scope in the second (unnamed) in-line view, so neither can be refererenced in the main query. You would need to give table aliases to the in-line views if you need to reference a column name (like id) that exists in both.
Essentially, join directly on tables or get results and join the datasets. This might too simplistic a example aboveJoin the tables directly when you have a choice.
There's no point in using
FROM (SELECT * FROM a)rather than just
FROM aIf there is a difference in performance, the simpler way will probably be faster, but the optimizer will probably use the same plan either way. The more complicate way will just confuse whoever has to debug and maintain the code.
Similar Messages
-
Performance for join 9 custom table with native SQL ?
Hi Expert,
I need your opinion regarding performance to join 9 tables with native sql. Recently i have to tunning some customize extraction cost report. This report extract about 10 million cost of material everyday.
The current program actually, try to populate the condition data and insert into customize table and join all the table to get data using native sql.
SELECT /*+ ordered use_hash(mst,pg,rg,ps,rs,dpg,drg,dps,drs) */
mst.werks, ....................................
FROM
sapsr3.zab_info mst,
sapsr3.zab_pc pg,
sapsr3.zab_rc rg,
sapsr3.zab_pc ps,
sapsr3.zab_rc rs,
sapsr3.zab_g_pc dpg,
sapsr3.zab_g_rc drg,
sapsr3.zab_s_pc dps,
sapsr3.zab_s_rc drs
WHERE mst.zseq_no = :p_rep_run_id
AND mst.werks = :p_werks
AND mst.mandt = rg.mandt(+)
AND mst.ekorg = rg.ekorg(+)
AND mst.lifnr = rg.lifnr(+)
AND mst.matnr = rg.matnr(+)
............................................... unitl all table (9 tables)
AND ps.mandt = dps.mandt(+)
AND ps.knumh = dps.knumh(+)
AND ps.zseq_no = dps.zseq_no(+)
AND COALESCE (dps.kbetr, drs.kbetr, dpg.kbetr, drg.kbetr) <> 0
It seems the query ask for database to using hashed table. would that be it will burden the database ? and impacted to others sap process ?
Please advise
Thank You and Best 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. -
OAM11g - How to perform direct login without accessing protected resource?
Hi,
I think this should be a common requirement as website needs to provide a direct login page.
The OAM Documentation seems focus on the flow of starting from accessing protected resource then redirect to login page.
How can we perform direct login?
I tried from my custom login page directly, but it always gives me *"PolicyEvaluationException: OAMSSA-06191: The runtime request contains no resource"* once the login form submitted.
Anyone can advise? Thanks in advance.Thanks for the reply.
We need to cater for both the scenarios:
Scenario 1: User tries to access a protected page. He/she will be redirected to the login page. Once it is authenticated, he/she will be redirected back to the previously requested protected page
Scenario 2: User clicks the "Login" link on the homepage where the homepage is definitely unprotected. He/she will be redirected to the login page. Once it is authenticated, he/she will be redirected back to homepage.
I have tried to the "Success URL" parameter of the Authentication Policy. However, once "Success URL" is defined, Scenario 1 will NOT work...
Yes. There are some work around solution I can think about.
Example: use a intermediate page 'rediret.jsp' which is defined as the protected resource.
The flow is: clicks the "Login" link on the homepage -> a intermediate page 'rediret.jsp' -> login page -> redirect back to 'rediret.jsp' -> 'rediret.jsp' will redirect user to the Homepage...
But I think Scenario 2 should be very common and it should be a right solution for it. Please advise. Thanks -
Poor performance while join of 2 comprehensive large views and small table
Hi,
The following SQL statement has been identified to perform poorly. It currently takes up to 6 seconds to execute, but it's supposed to take ~30-40ms at most.
This is the statement(all bind variables change to numbers):
SELECT v__96.connector_objectid, v__96.connector_classid, v__96.from_objectid,
v__96.to_objectid, v__96.from_classid, v__96.to_classid,
v__96.from_firstunit, v__96.to_firstunit, v__96.number_of_units,
tmp_trace.first_unit, tmp_trace.last_unit, v__96.inv_status_number,
tmp_trace.first_unit, tmp_trace.last_unit, v__96.answers,
v__96.priority, v__97.first_unit, v__97.n_units,
v__97.mid_span_distance
FROM ne.tmp_trace,
(SELECT b.objectid, b.answers, b.connector_classid,
b.connector_objectid, b.from_classid, b.from_objectid,
b.to_classid, b.to_objectid, b.from_firstunit, b.to_firstunit,
b.number_of_units, b.inv_status_number, b.splice_closure_name,
b.work_order_name, b.work_order_item_number,
b.inventory_status_code, b.priority
FROM ne.connection b
WHERE b.objectid NOT IN (
SELECT /*+ HASH_AJ */
sde_deletes_row_id
FROM ne.d96
WHERE deleted_at IN (
SELECT l.lineage_id
FROM sde.state_lineages l
WHERE l.lineage_name = 2
AND l.lineage_id <= 115)
AND sde_state_id = 0)
UNION ALL
SELECT a.objectid, a.answers, a.connector_classid,
a.connector_objectid, a.from_classid, a.from_objectid,
a.to_classid, a.to_objectid, a.from_firstunit, a.to_firstunit,
a.number_of_units, a.inv_status_number, a.splice_closure_name,
a.work_order_name, a.work_order_item_number,
a.inventory_status_code, a.priority
FROM ne.a96 a, sde.state_lineages sl
WHERE (a.objectid, a.sde_state_id) NOT IN (
SELECT /*+ HASH_AJ */
sde_deletes_row_id, sde_state_id
FROM ne.d96
WHERE deleted_at IN (
SELECT l.lineage_id
FROM sde.state_lineages l
WHERE l.lineage_name = 2
AND l.lineage_id <= 115)
AND sde_state_id > 0)
AND a.sde_state_id = sl.lineage_id
AND sl.lineage_name = 2
AND sl.lineage_id <= 115) v__96,
(SELECT b.objectid, b.tray_number, b.db_loss, b.first_unit, b.n_units,
b.connection_objectid, b.connector_type_name,
b.dedicated_status, b.mid_span_distance
FROM ne.connection_attributes b
WHERE b.objectid NOT IN (
SELECT /*+ HASH_AJ */
sde_deletes_row_id
FROM ne.d97
WHERE deleted_at IN (
SELECT l.lineage_id
FROM sde.state_lineages l
WHERE l.lineage_name = 2
AND l.lineage_id <= 115)
AND sde_state_id = 0)
UNION ALL
SELECT a.objectid, a.tray_number, a.db_loss, a.first_unit, a.n_units,
a.connection_objectid, a.connector_type_name,
a.dedicated_status, a.mid_span_distance
FROM ne.a97 a, sde.state_lineages sl
WHERE (a.objectid, a.sde_state_id) NOT IN (
SELECT /*+ HASH_AJ */
sde_deletes_row_id, sde_state_id
FROM ne.d97
WHERE deleted_at IN (
SELECT l.lineage_id
FROM sde.state_lineages l
WHERE l.lineage_name = 2
AND l.lineage_id <= 115)
AND sde_state_id > 0)
AND a.sde_state_id = sl.lineage_id
AND sl.lineage_name = 2
AND sl.lineage_id <= 115) v__97
WHERE ( ( ( ( ( ( ne.tmp_trace.equipment_object_id =
v__96.to_objectid
AND v__96.to_classid = 9
OR ( ne.tmp_trace.transmedia_object_id =
v__96.to_objectid
AND v__96.to_classid = 5
AND ( (v__96.to_firstunit
BETWEEN ne.tmp_trace.first_unit
AND ne.tmp_trace.last_unit
OR (ne.tmp_trace.first_unit
BETWEEN v__96.to_firstunit
AND v__96.to_firstunit
+ v__96.number_of_units
- 1
AND v__96.answers = 0
AND v__96.objectid = v__97.connection_objectid
AND (ne.tmp_trace.session_id = -1234)
);It should return many values from 2 comprehensive views (v__96, v__97) and business table (tmp_trace). 2 comprehensive views ~1,000,000 recs each, business table ~ 10 recs.
The version of the database is 11.1.0.6.
These are the parameters relevant to the optimizer:
SQL> show parameter optimizer
NAME TYPE VALUE
optimizer_capture_sql_plan_baselines boolean FALSE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 11.1.0.6
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
optimizer_use_invisible_indexes boolean FALSE
optimizer_use_pending_statistics boolean FALSE
optimizer_use_sql_plan_baselines boolean TRUE
SQL> show parameter db_file_multi
NAME TYPE VALUE
db_file_multiblock_read_count integer 128
SQL> show parameter db_block_size
NAME TYPE VALUE
db_block_size integer 8192
SQL> show parameter cursor_sharing
NAME TYPE VALUE
cursor_sharing string FORCE
SQL> column sname format a20
SQL> column pname format a20
SQL> column pval2 format a20
SQL> select sname, pname, pval1, pval2 from sys.aux_stats$;
SNAME PNAME PVAL1 PVAL2
SYSSTATS_INFO STATUS COMPLETED
SYSSTATS_INFO DSTART 07-15-2009 10:27
SYSSTATS_INFO DSTOP 07-15-2009 10:27
SYSSTATS_INFO FLAGS 1
SYSSTATS_MAIN CPUSPEEDNW 1812.32129
SYSSTATS_MAIN IOSEEKTIM 10
SYSSTATS_MAIN IOTFRSPEED 4096
SYSSTATS_MAIN SREADTIM
SYSSTATS_MAIN MREADTIM
SYSSTATS_MAIN CPUSPEED
SYSSTATS_MAIN MBRC
SNAME PNAME PVAL1 PVAL2
SYSSTATS_MAIN MAXTHR
SYSSTATS_MAIN SLAVETHR
13 rows selected.Here is the output of EXPLAIN PLAN:
explain plan for -- statement above
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1005186751
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 282 | 268 (2)| 00:00:04 |
| 1 | NESTED LOOPS | | 1 | 282 | 268 (2)| 00:00:04 |
| 2 | MERGE JOIN CARTESIAN | | 1 | 119 | 260 (1)| 00:00:04 |
|* 3 | TABLE ACCESS FULL | TMP_TRACE | 1 | 65 | 2 (0)| 00:00:01 |
| 4 | BUFFER SORT | | 103K| 5467K| 258 (1)| 00:00:04 |
| 5 | VIEW | | 103K| 5467K| 258 (1)| 00:00:04 |
| 6 | UNION-ALL | | | | | |
| 7 | NESTED LOOPS ANTI | | 1 | 82 | 3 (0)| 00:00:01 |
| 8 | TABLE ACCESS FULL | CONNECTION_ATTRIBUTES | 1 | 78 | 2 (0)| 00:00:01 |
| 9 | VIEW PUSHED PREDICATE | VW_NSO_1 | 1 | 4 | 1 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 11 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 12 | INDEX UNIQUE SCAN | D97_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 13 | HASH JOIN RIGHT ANTI | | 103K| 5568K| 255 (1)| 00:00:04 |
| 14 | VIEW | VW_NSO_2 | 1 | 26 | 2 (0)| 00:00:01 |
| 15 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 16 | INDEX FAST FULL SCAN | D97_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 17 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 18 | NESTED LOOPS | | | | | |
| 19 | NESTED LOOPS | | 103K| 2936K| 252 (1)| 00:00:04 |
|* 20 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 21 | INDEX RANGE SCAN | A97_STATEID_IX1 | 17731 | | 32 (0)| 00:00:01 |
| 22 | TABLE ACCESS BY INDEX ROWID| A97 | 21491 | 461K| 123 (1)| 00:00:02 |
|* 23 | VIEW | | 1 | 163 | 8 (13)| 00:00:01 |
| 24 | UNION ALL PUSHED PREDICATE | | | | | |
| 25 | NESTED LOOPS ANTI | | 1 | 185 | 1 (0)| 00:00:01 |
|* 26 | TABLE ACCESS BY INDEX ROWID | CONNECTION | 1 | 181 | 0 (0)| 00:00:01 |
|* 27 | INDEX UNIQUE SCAN | R96_SDE_ROWID_UK | 1 | | 0 (0)| 00:00:01 |
| 28 | VIEW PUSHED PREDICATE | VW_NSO_3 | 1 | 4 | 1 (0)| 00:00:01 |
| 29 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 30 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 31 | INDEX UNIQUE SCAN | D96_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 32 | HASH JOIN ANTI | | 1 | 97 | 7 (15)| 00:00:01 |
| 33 | NESTED LOOPS | | 1 | 71 | 4 (0)| 00:00:01 |
|* 34 | TABLE ACCESS BY INDEX ROWID | A96 | 1 | 64 | 4 (0)| 00:00:01 |
|* 35 | INDEX RANGE SCAN | A96_PK | 1 | | 3 (0)| 00:00:01 |
|* 36 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 37 | VIEW | VW_NSO_4 | 1 | 26 | 2 (0)| 00:00:01 |
| 38 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 39 | INDEX FAST FULL SCAN | D96_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 40 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - filter("TMP_TRACE"."SESSION_ID"=(-1234))
11 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
12 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
"SDE_STATE_ID"=0)
filter("DELETED_AT"<=115)
13 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
16 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
17 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
filter("L"."LINEAGE_ID"<=115)
20 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
21 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
filter("A"."SDE_STATE_ID"<=115)
23 - filter(("TMP_TRACE"."EQUIPMENT_OBJECT_ID"="V__96"."TO_OBJECTID" AND "V__96"."TO_CLASSID"=9
OR "TMP_TRACE"."TRANSMEDIA_OBJECT_ID"="V__96"."TO_OBJECTID" AND "V__96"."TO_CLASSID"=5) AND
("V__96"."TO_FIRSTUNIT">="TMP_TRACE"."FIRST_UNIT" AND
"V__96"."TO_FIRSTUNIT"<="TMP_TRACE"."LAST_UNIT" OR "TMP_TRACE"."FIRST_UNIT">="V__96"."TO_FIRSTUNIT"
AND "TMP_TRACE"."FIRST_UNIT"<="V__96"."TO_FIRSTUNIT"+"V__96"."NUMBER_OF_UNITS"-1))
26 - filter("B"."ANSWERS"=0)
27 - access("B"."OBJECTID"="V__97"."CONNECTION_OBJECTID")
30 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
31 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
"SDE_STATE_ID"=0)
filter("DELETED_AT"<=115)
32 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
34 - filter("A"."ANSWERS"=0)
35 - access("A"."OBJECTID"="V__97"."CONNECTION_OBJECTID" AND "A"."SDE_STATE_ID"<=115)
36 - access("SL"."LINEAGE_NAME"=2 AND "A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
filter("SL"."LINEAGE_ID"<=115)
39 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND
"SDE_DELETES_ROW_ID"="V__97"."CONNECTION_OBJECTID" AND "SDE_STATE_ID">0)
40 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
filter("L"."LINEAGE_ID"<=115)
Note
- dynamic sampling used for this statement
87 rows selected.Here is the output of SQL*Plus AUTOTRACE including the TIMING information:
SQL> set autotrace traceonly arraysize 100
Elapsed: 00:00:01.64
Execution Plan
Plan hash value: 1198408274
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 876K| 238M| 1301 (2)| 00:00:16 |
| 1 | CONCATENATION | | | | | |
|* 2 | HASH JOIN | | 438K| 119M| 651 (2)| 00:00:08 |
|* 3 | HASH JOIN | | 423 | 98559 | 390 (2)| 00:00:05 |
|* 4 | TABLE ACCESS FULL | TMP_TRACE | 82 | 5330 | 29 (0)| 00:00:01 |
|* 5 | VIEW | | 103K| 16M| 360 (1)| 00:00:05 |
| 6 | UNION-ALL | | | | | |
| 7 | NESTED LOOPS ANTI | | 1 | 185 | 3 (0)| 00:00:01 |
|* 8 | TABLE ACCESS FULL | CONNECTION | 1 | 181 | 2 (0)| 00:00:01 |
| 9 | VIEW PUSHED PREDICATE | VW_NSO_3 | 1 | 4 | 1 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 11 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 12 | INDEX UNIQUE SCAN | D96_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 13 | HASH JOIN RIGHT ANTI | | 103K| 9820K| 357 (1)| 00:00:05 |
| 14 | VIEW | VW_NSO_4 | 1 | 26 | 2 (0)| 00:00:01 |
| 15 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 16 | INDEX FAST FULL SCAN | D96_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 17 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 18 | NESTED LOOPS | | | | | |
| 19 | NESTED LOOPS | | 103K| 7188K| 354 (1)| 00:00:05 |
|* 20 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 21 | INDEX RANGE SCAN | A96_STATEID_IX1 | 17731 | | 32 (0)| 00:00:01 |
|* 22 | TABLE ACCESS BY INDEX ROWID| A96 | 21491 | 1343K| 224 (1)| 00:00:03 |
| 23 | VIEW | | 103K| 5264K| 258 (1)| 00:00:04 |
| 24 | UNION-ALL | | | | | |
| 25 | NESTED LOOPS ANTI | | 1 | 82 | 3 (0)| 00:00:01 |
| 26 | TABLE ACCESS FULL | CONNECTION_ATTRIBUTES | 1 | 78 | 2 (0)| 00:00:01 |
| 27 | VIEW PUSHED PREDICATE | VW_NSO_1 | 1 | 4 | 1 (0)| 00:00:01 |
| 28 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 29 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 30 | INDEX UNIQUE SCAN | D97_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 31 | HASH JOIN RIGHT ANTI | | 103K| 5568K| 255 (1)| 00:00:04 |
| 32 | VIEW | VW_NSO_2 | 1 | 26 | 2 (0)| 00:00:01 |
| 33 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 34 | INDEX FAST FULL SCAN | D97_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 35 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 36 | NESTED LOOPS | | | | | |
| 37 | NESTED LOOPS | | 103K| 2936K| 252 (1)| 00:00:04 |
|* 38 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 39 | INDEX RANGE SCAN | A97_STATEID_IX1 | 17731 | | 32 (0)| 00:00:01 |
| 40 | TABLE ACCESS BY INDEX ROWID | A97 | 21491 | 461K| 123 (1)| 00:00:02 |
|* 41 | HASH JOIN | | 438K| 119M| 651 (2)| 00:00:08 |
|* 42 | HASH JOIN | | 423 | 98559 | 390 (2)| 00:00:05 |
|* 43 | TABLE ACCESS FULL | TMP_TRACE | 82 | 5330 | 29 (0)| 00:00:01 |
|* 44 | VIEW | | 103K| 16M| 360 (1)| 00:00:05 |
| 45 | UNION-ALL | | | | | |
| 46 | NESTED LOOPS ANTI | | 1 | 185 | 3 (0)| 00:00:01 |
|* 47 | TABLE ACCESS FULL | CONNECTION | 1 | 181 | 2 (0)| 00:00:01 |
| 48 | VIEW PUSHED PREDICATE | VW_NSO_3 | 1 | 4 | 1 (0)| 00:00:01 |
| 49 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 50 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 51 | INDEX UNIQUE SCAN | D96_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 52 | HASH JOIN RIGHT ANTI | | 103K| 9820K| 357 (1)| 00:00:05 |
| 53 | VIEW | VW_NSO_4 | 1 | 26 | 2 (0)| 00:00:01 |
| 54 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 55 | INDEX FAST FULL SCAN | D96_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 56 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 57 | NESTED LOOPS | | | | | |
| 58 | NESTED LOOPS | | 103K| 7188K| 354 (1)| 00:00:05 |
|* 59 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 60 | INDEX RANGE SCAN | A96_STATEID_IX1 | 17731 | | 32 (0)| 00:00:01 |
|* 61 | TABLE ACCESS BY INDEX ROWID| A96 | 21491 | 1343K| 224 (1)| 00:00:03 |
| 62 | VIEW | | 103K| 5264K| 258 (1)| 00:00:04 |
| 63 | UNION-ALL | | | | | |
| 64 | NESTED LOOPS ANTI | | 1 | 82 | 3 (0)| 00:00:01 |
| 65 | TABLE ACCESS FULL | CONNECTION_ATTRIBUTES | 1 | 78 | 2 (0)| 00:00:01 |
| 66 | VIEW PUSHED PREDICATE | VW_NSO_1 | 1 | 4 | 1 (0)| 00:00:01 |
| 67 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 68 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 69 | INDEX UNIQUE SCAN | D97_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 70 | HASH JOIN RIGHT ANTI | | 103K| 5568K| 255 (1)| 00:00:04 |
| 71 | VIEW | VW_NSO_2 | 1 | 26 | 2 (0)| 00:00:01 |
| 72 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 73 | INDEX FAST FULL SCAN | D97_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 74 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 75 | NESTED LOOPS | | | | | |
| 76 | NESTED LOOPS | | 103K| 2936K| 252 (1)| 00:00:04 |
|* 77 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 78 | INDEX RANGE SCAN | A97_STATEID_IX1 | 17731 | | 32 (0)| 00:00:01 |
| 79 | TABLE ACCESS BY INDEX ROWID | A97 | 21491 | 461K| 123 (1)| 00:00:02 |
Predicate Information (identified by operation id):
2 - access("V__96"."OBJECTID"="V__97"."CONNECTION_OBJECTID")
3 - access("TMP_TRACE"."TRANSMEDIA_OBJECT_ID"="V__96"."TO_OBJECTID")
filter("V__96"."TO_FIRSTUNIT">="TMP_TRACE"."FIRST_UNIT" AND
"V__96"."TO_FIRSTUNIT"<="TMP_TRACE"."LAST_UNIT" OR "TMP_TRACE"."FIRST_UNIT">="V__96"."TO_FIRSTUNIT"
AND "TMP_TRACE"."FIRST_UNIT"<="V__96"."TO_FIRSTUNIT"+"V__96"."NUMBER_OF_UNITS"-1)
4 - filter("TMP_TRACE"."SESSION_ID"=(-1234))
5 - filter("V__96"."TO_CLASSID"=5)
8 - filter("B"."ANSWERS"=0)
11 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
12 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
"SDE_STATE_ID"=0)
filter("DELETED_AT"<=115)
13 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
16 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
17 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
filter("L"."LINEAGE_ID"<=115)
20 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
21 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
filter("A"."SDE_STATE_ID"<=115)
22 - filter("A"."ANSWERS"=0)
29 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
30 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
"SDE_STATE_ID"=0)
filter("DELETED_AT"<=115)
31 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
34 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
35 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
filter("L"."LINEAGE_ID"<=115)
38 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
39 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
filter("A"."SDE_STATE_ID"<=115)
41 - access("V__96"."OBJECTID"="V__97"."CONNECTION_OBJECTID")
42 - access("TMP_TRACE"."EQUIPMENT_OBJECT_ID"="V__96"."TO_OBJECTID")
filter((LNNVL("TMP_TRACE"."TRANSMEDIA_OBJECT_ID"="V__96"."TO_OBJECTID") OR
LNNVL("V__96"."TO_CLASSID"=5)) AND ("V__96"."TO_FIRSTUNIT">="TMP_TRACE"."FIRST_UNIT" AND
"V__96"."TO_FIRSTUNIT"<="TMP_TRACE"."LAST_UNIT" OR "TMP_TRACE"."FIRST_UNIT">="V__96"."TO_FIRSTUNIT"
AND "TMP_TRACE"."FIRST_UNIT"<="V__96"."TO_FIRSTUNIT"+"V__96"."NUMBER_OF_UNITS"-1))
43 - filter("TMP_TRACE"."SESSION_ID"=(-1234))
44 - filter("V__96"."TO_CLASSID"=9)
47 - filter("B"."ANSWERS"=0)
50 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
51 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
"SDE_STATE_ID"=0)
filter("DELETED_AT"<=115)
52 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
55 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
56 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
filter("L"."LINEAGE_ID"<=115)
59 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
60 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
filter("A"."SDE_STATE_ID"<=115)
61 - filter("A"."ANSWERS"=0)
68 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
69 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
"SDE_STATE_ID"=0)
filter("DELETED_AT"<=115)
70 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
73 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
74 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
filter("L"."LINEAGE_ID"<=115)
77 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
78 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
filter("A"."SDE_STATE_ID"<=115)
Note
- dynamic sampling used for this statementThe TKPROF output for this statement looks like the following:
TKPROF: Release 11.1.0.6.0 - Production on Thu Sep 24 09:30:01 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Trace file: pro &The TKPROF output for this statement looks like the following:
TKPROF: Release 11.1.0.6.0 - Production on Thu Sep 24 09:30:01 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Trace file: problem.trc
Sort options: default
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
SELECT V__96.CONNECTOR_OBJECTID, V__96.CONNECTOR_CLASSID, V__96.FROM_OBJECTID, V__96.TO_OBJECTID, V__96.FROM_CLASSID, V__96.TO_CLASSID,
V__96.FROM_FIRSTUNIT, V__96.TO_FIRSTUNIT, V__96.NUMBER_OF_UNITS, TMP_TRACE.FIRST_UNIT, TMP_TRACE.LAST_UNIT, V__96.INV_STATUS_NUMBER,
TMP_TRACE.FIRST_UNIT, TMP_TRACE.LAST_UNIT, V__96.ANSWERS, V__96.PRIORITY, V__97.FIRST_UNIT, V__97.N_UNITS, V__97.MID_SPAN_DISTANCE FROM
NE.TMP_TRACE,(SELECT
b.OBJECTID,b.ANSWERS,b.CONNECTOR_CLASSID,b.CONNECTOR_OBJECTID,b.FROM_CLASSID,b.FROM_OBJECTID,b.TO_CLASSID,b.TO_OBJECTID,b.FROM_FIRSTUNIT,b.TO_FIRSTUNIT,b.NUM
BER_OF_UNITS,b.INV_STATUS_NUMBER,b.SPLICE_CLOSURE_NAME,b.WORK_ORDER_NAME,b.WORK_ORDER_ITEM_NUMBER,b.INVENTORY_STATUS_CODE,b.PRIORITY FROM NE.connection b
WHERE b.OBJECTID NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID FROM NE.D96 WHERE DELETED_AT IN (SELECT l.lineage_id FROM SDE.state_lineages l WHERE
l.lineage_name = :"SYS_B_00" AND l.lineage_id <= :"SYS_B_01") AND SDE_STATE_ID = :"SYS_B_02") UNION ALL SELECT
a.OBJECTID,a.ANSWERS,a.CONNECTOR_CLASSID,a.CONNECTOR_OBJECTID,a.FROM_CLASSID,a.FROM_OBJECTID,a.TO_CLASSID,a.TO_OBJECTID,a.FROM_FIRSTUNIT,a.TO_FIRSTUNIT,a.NUM
BER_OF_UNITS,a.INV_STATUS_NUMBER,a.SPLICE_CLOSURE_NAME,a.WORK_ORDER_NAME,a.WORK_ORDER_ITEM_NUMBER,a.INVENTORY_STATUS_CODE,a.PRIORITY FROM NE.A96
a,SDE.state_lineages SL WHERE (a.OBJECTID, a.SDE_STATE_ID) NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID,SDE_STATE_ID FROM NE.D96 WHERE DELETED_AT IN
(SELECT l.lineage_id FROM SDE.state_lineages l WHERE l.lineage_name = :"SYS_B_03" AND l.lineage_id <= :"SYS_B_04") AND SDE_STATE_ID > :"SYS_B_05") AND
a.SDE_STATE_ID = SL.lineage_id AND SL.lineage_name = :"SYS_B_06" AND SL.lineage_id <= :"SYS_B_07") V__96,(SELECT
b.OBJECTID,b.TRAY_NUMBER,b.DB_LOSS,b.FIRST_UNIT,b.N_UNITS,b.CONNECTION_OBJECTID,b.CONNECTOR_TYPE_NAME,b.DEDICATED_STATUS,b.MID_SPAN_DISTANCE FROM
NE.connection_attributes b WHERE b.OBJECTID NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID FROM NE.D97 WHERE DELETED_AT IN (SELECT l.lineage_id FROM
SDE.state_lineages l WHERE l.lineage_name = :"SYS_B_08" AND l.lineage_id <= :"SYS_B_09") AND SDE_STATE_ID = :"SYS_B_10") UNION ALL SELECT
a.OBJECTID,a.TRAY_NUMBER,a.DB_LOSS,a.FIRST_UNIT,a.N_UNITS,a.CONNECTION_OBJECTID,a.CONNECTOR_TYPE_NAME,a.DEDICATED_STATUS,a.MID_SPAN_DISTANCE FROM NE.A97
a,SDE.state_lineages SL WHERE (a.OBJECTID, a.SDE_STATE_ID) NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID,SDE_STATE_ID FROM NE.D97 WHERE DELETED_AT IN
(SELECT l.lineage_id FROM SDE.state_lineages l WHERE l.lineage_name = :"SYS_B_11" AND l.lineage_id <= :"SYS_B_12") AND SDE_STATE_ID > :"SYS_B_13") AND
a.SDE_STATE_ID = SL.lineage_id AND SL.lineage_name = :"SYS_B_14" AND SL.lineage_id <= :"SYS_B_15") V__97 WHERE ((((( (
NE.tmp_trace.equipment_object_id = V__96.to_objectid
AND
V__96.to_classid = :"SYS_B_16"
OR
NE.tmp_trace.transmedia_object_id = V__96.to_objectid
AND
V__96.to_classid = :"SYS_B_17"
)) AND (
(V__96.to_firstunit
BETWEEN NE.tmp_trace.first_unit AND NE.tmp_trace.last_unit)
OR
(NE.tmp_trace.first_unit BETWEEN V__96.to_firstunit
AND V__96.to_firstunit + V__96.number_of_units - :"SYS_B_18")
)) AND V__96.answers = :"SYS_B_19") AND V__96.objectid = V__97.connection_objectid) AND (NE.tmp_trace.session_id =
:"SYS_B_20"))
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 5.98 5.99 0 22652 0 10
total 3 5.98 5.99 0 22652 0 10
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 45
Rows Row Source Operation
10 NESTED LOOPS (cr=22652 pr=0 pw=0 time=654515 us cost=67 size=282 card=1)
10 NESTED LOOPS (cr=22436 pr=0 pw=0 time=653673 us cost=61 size=235 card=1)
10 TABLE ACCESS FULL TMP_TRACE (cr=5 pr=0 pw=0 time=7 us cost=2 size=65 card=1)
10 VIEW (cr=22431 pr=0 pw=0 time=0 us cost=59 size=170 card=1)
1773000 UNION-ALL (cr=22431 pr=0 pw=0 time=93649 us)
0 NESTED LOOPS ANTI (cr=30 pr=0 pw=0 time=0 us cost=3 size=185 card=1)
0 TABLE ACCESS FULL CONNECTION (cr=30 pr=0 pw=0 time=0 us cost=2 size=181 card=1)
0 VIEW PUSHED PREDICATE VW_NSO_3 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=1 size=20 card=1)
0 INDEX RANGE SCAN LINEAGES_PK (cr=0 pr=0 pw=0 time=0 us cost=1 size=7 card=1)(object id 34021)
0 INDEX UNIQUE SCAN D96_PK (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)(object id 35121)
1773000 HASH JOIN RIGHT ANTI (cr=22401 pr=0 pw=0 time=75084 us cost=56 size=46948 card=484)
0 VIEW VW_NSO_4 (cr=180 pr=0 pw=0 time=0 us cost=2 size=26 card=1)
0 FILTER (cr=180 pr=0 pw=0 time=0 us)
0 NESTED LOOPS (cr=180 pr=0 pw=0 time=0 us cost=2 size=20 card=1)
0 INDEX FAST FULL SCAN D96_PK (cr=180 pr=0 pw=0 time=0 us cost=2 size=13 card=1)(object id 35121)
0 INDEX UNIQUE SCAN LINEAGES_PK (cr=0 pr=0 pw=0 time=0 us cost=0 size=7 card=1)(object id 34021)
1773000 NESTED LOOPS (cr=22221 pr=0 pw=0 time=56155 us)
1773000 NESTED LOOPS (cr=3231 pr=0 pw=0 time=15078 us cost=53 size=34364 card=484)
50 INDEX RANGE SCAN LINEAGES_PK (cr=10 pr=0 pw=0 time=7 us cost=1 size=7 card=1)(object id 34021)
1773000 INDEX RANGE SCAN A96_STATEID_IX1 (cr=3221 pr=0 pw=0 time=6810 us cost=32 size=0 card=1774)(object id 35116)
1773000 TABLE ACCESS BY INDEX ROWID A96 (cr=18990 pr=0 pw=0 time=0 us cost=52 size=82560 card=1290)
10 VIEW (cr=216 pr=0 pw=0 time=0 us cost=7 size=47 card=1)
10 UNION ALL PUSHED PREDICATE (cr=216 pr=0 pw=0 time=0 us)
0 NESTED LOOPS ANTI (cr=1 pr=0 pw=0 time=0 us cost=2 size=82 card=1)
0 TABLE ACCESS BY INDEX ROWID CONNECTION_ATTRIBUTES (cr=1 pr=0 pw=0 time=0 us cost=1 size=78 card=1)
0 INDEX RANGE SCAN GDB_59_CONNECTIO (cr=1 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 34346)
0 VIEW PUSHED PREDICATE VW_NSO_1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=1 size=20 card=1)
0 INDEX RANGE SCAN LINEAGES_PK (cr=0 pr=0 pw=0 time=0 us cost=1 size=7 card=1)(object id 34021)
0 INDEX UNIQUE SCAN D97_PK (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)(object id 35127)
10 HASH JOIN ANTI (cr=215 pr=0 pw=0 time=0 us cost=5 size=55 card=1)
10 NESTED LOOPS (cr=35 pr=0 pw=0 time=0 us cost=2 size=29 card=1)
10 TABLE ACCESS BY INDEX ROWID A97 (cr=25 pr=0 pw=0 time=0 us cost=2 size=22 card=1)
10 INDEX RANGE SCAN GDB_59_CONNECTIO_A (cr=15 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 35122)
10 INDEX UNIQUE SCAN LINEAGES_PK (cr=10 pr=0 pw=0 time=0 us cost=0 size=7 card=1)(object id 34021)
0 VIEW VW_NSO_2 (cr=180 pr=0 pw=0 time=0 us cost=2 size=26 card=1)
0 FILTER (cr=180 pr=0 pw=0 time=0 us)
0 NESTED LOOPS (cr=180 pr=0 pw=0 time=0 us cost=2 size=20 card=1)
0 INDEX FAST FULL SCAN D97_PK (cr=180 pr=0 pw=0 time=0 us cost=2 size=13 card=1)(object id 35127)
0 INDEX UNIQUE SCAN LINEAGES_PK (cr=0 pr=0 pw=0 time=0 us cost=0 size=7 card=1)(object id 34021)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
SQL*Net message from client 2 0.00 0.00After manually rewrite query in TOAD it produces nested loops on business table and than access v__96, v__97 produce desired quick performance.
I can use stored outlines but this is the last chance. I am playing with hints right now to produce desired plan with no result yet.
Does anybody know how to insist Oracle to merge internal views to bigger query block, so Oracle can choose better plan?
Or any guide what hints to use from ol$hints to get desired result via hints addition to original sql query (thanks God application don't cut hints just pass-through to Oracle)?
Thanks,
Sergiy -
Hello Experts,
I had a issue where we are executing one custom report in which i used inner join on table MKPF & MSEG, some time join statement took 9-10 min to excute and some time execute within 1-2 min with same test data .
i am not able to understand what the actaully happing .
please help.
code :
SELECT f~mblnr f~mjahr f~usnam f~bktxt p~bukrs
INTO TABLE itab
FROM mkpf AS f INNER JOIN mseg AS p
ON f~mblnr = p~mblnr AND f~mjahr = p~mjahr
WHERE f~vgart = 'WE'
AND f~budat IN p_budat
AND f~usnam IN p_sgtxt
AND p~bwart IN ('101','105')
AND p~werks IN p_werks
AND p~lgort IN p_lgort.
Regards,
Dipendra Panwar.Hi Dipendra,
if you call a report twice after another with the same test data for data selection, then the second run should be faster, because some data are remaining in memory and needn't to be caught from database. This will be also for the following third und further runs, until the data in the SAP memory will be removed by other programs.
For performance traces you should try to test with a first run.
Regards,
Klaus -
Performance during joining large tables
Hi,
I have to maintain a report which gets data from many large tables as below. Currently it is using join statement to join all 8 tables and causing a very slow performance.
SELECT
into corresponding fields of table equip
FROM caufv
join afih on afih~aufnr = caufv~aufnr
join iloa on iloa~iloan = afih~iloan
join iflos on iflos~tplnr = iloa~tplnr
join iflotx on iflos~tplnr = iflotx~tplnr
join vbak on vbak~aufnr = caufv~aufnr
join equz on equz~equnr = afih~equnr
join equi on equi~equnr = equz~equnr
join vbap on vbak~vbeln = vbap~vbeln
WHERE
Please suggest me another way, I'm newbie in ABAP. I tried using FOR ALL ENTRIES IN but it did not work. I would very appreciate if you can leave me some sample lines of code.
Thanks,Hi Dear ,
I will suggest you not to use inner join for such i.e. 8 number of table and that too huge tables. Instead use For All entries wherever possible. But before using for all entries check initial for base table and if its not possible to avoid inner join then try to minimise it. Use inner join between header and item.
Hope this will help you to solve your problem . Feel free to ask if you have any doubt.
Regards,
Vijay -
Poor query performance when joining CONTAINS to another table
We just recently began evaluating Oracle Text for a search solution. We need to be able to search a table that can have over 20+ million rows. Each user may only have visibility to a tiny fraction of those rows. The goal is to have a single Oracle Text index that represents all of the searchable columns in the table (multi column datastore) and provide a score for each search result so that we can sort the search results in descending order by score. What we're seeing is that query performance from TOAD is extremely fast when we write a simple CONTAINS query against the Oracle Text indexed table. However, when we attempt to first reduce the rows the CONTAINS query needs to search by using a WITH we find that the query performance degrades significantly.
For example, we can find all the records a user has access to from our base table by the following query:
SELECT d.duns_loc
FROM duns d
JOIN primary_contact pc
ON d.duns_loc = pc.duns_loc
AND pc.emp_id = :employeeID;
This query can execute in <100 ms. In the working example, this query returns around 1200 rows of the primary key duns_loc.
Our search query looks like this:
SELECT score(1), d.*
FROM duns d
WHERE CONTAINS(TEXT_KEY, :search,1) > 0
ORDER BY score(1) DESC;
The :search value in this example will be 'highway'. The query can return 246k rows in around 2 seconds.
2 seconds is good, but we should be able to have a much faster response if the search query did not have to search the entire table, right? Since each user can only "view" records they are assigned to we reckon that if the search operation only had to scan a tiny tiny percent of the TEXT index we should see faster (and more relevant) results. If we now write the following query:
WITH subset
AS
(SELECT d.duns_loc
FROM duns d
JOIN primary_contact pc
ON d.duns_loc = pc.duns_loc
AND pc.emp_id = :employeeID
SELECT score(1), d.*
FROM duns d
JOIN subset s
ON d.duns_loc = s.duns_loc
WHERE CONTAINS(TEXT_KEY, :search,1) > 0
ORDER BY score(1) DESC;
For reasons we have not been able to identify this query actually takes longer to execute than the sum of the durations of the contributing parts. This query takes over 6 seconds to run. We nor our DBA can seem to figure out why this query performs worse than a wide open search. The wide open search is not ideal as the query would end up returning records to the user they don't have access to view.
Has anyone ever ran into something like this? Any suggestions on what to look at or where to go? If anyone would like more information to help in diagnosis than let me know and i'll be happy to produce it here.
Thanks!!Sometimes it can be good to separate the tables into separate sub-query factoring (with) clauses or inline views in the from clause or an in clause as a where condition. Although there are some differences, using a sub-query factoring (with) clause is similar to using an inline view in the from clause. However, you should avoid duplication. You should not have the same table in two different places, as in your original query. You should have indexes on any columns that the tables are joined on, your statistics should be current, and your domain index should have regular synchronization, optimization, and periodically rebuild or drop and recreate to keep it performing with maximum efficiency. The following demonstration uses a composite domain index (cdi) with filter by, as suggested by Roger, then shows the explained plans for your original query, and various others. Your original query has nested loops. All of the others have the same plan without the nested loops. You could also add index hints.
SCOTT@orcl_11gR2> -- tables:
SCOTT@orcl_11gR2> CREATE TABLE duns
2 (duns_loc NUMBER,
3 text_key VARCHAR2 (30))
4 /
Table created.
SCOTT@orcl_11gR2> CREATE TABLE primary_contact
2 (duns_loc NUMBER,
3 emp_id NUMBER)
4 /
Table created.
SCOTT@orcl_11gR2> -- data:
SCOTT@orcl_11gR2> INSERT INTO duns VALUES (1, 'highway')
2 /
1 row created.
SCOTT@orcl_11gR2> INSERT INTO primary_contact VALUES (1, 1)
2 /
1 row created.
SCOTT@orcl_11gR2> INSERT INTO duns
2 SELECT object_id, object_name
3 FROM all_objects
4 WHERE object_id > 1
5 /
76027 rows created.
SCOTT@orcl_11gR2> INSERT INTO primary_contact
2 SELECT object_id, namespace
3 FROM all_objects
4 WHERE object_id > 1
5 /
76027 rows created.
SCOTT@orcl_11gR2> -- indexes:
SCOTT@orcl_11gR2> CREATE INDEX duns_duns_loc_idx
2 ON duns (duns_loc)
3 /
Index created.
SCOTT@orcl_11gR2> CREATE INDEX primary_contact_duns_loc_idx
2 ON primary_contact (duns_loc)
3 /
Index created.
SCOTT@orcl_11gR2> -- composite domain index (cdi) with filter by clause
SCOTT@orcl_11gR2> -- as suggested by Roger:
SCOTT@orcl_11gR2> CREATE INDEX duns_text_key_idx
2 ON duns (text_key)
3 INDEXTYPE IS CTXSYS.CONTEXT
4 FILTER BY duns_loc
5 /
Index created.
SCOTT@orcl_11gR2> -- gather statistics:
SCOTT@orcl_11gR2> EXEC DBMS_STATS.GATHER_TABLE_STATS (USER, 'DUNS')
PL/SQL procedure successfully completed.
SCOTT@orcl_11gR2> EXEC DBMS_STATS.GATHER_TABLE_STATS (USER, 'PRIMARY_CONTACT')
PL/SQL procedure successfully completed.
SCOTT@orcl_11gR2> -- variables:
SCOTT@orcl_11gR2> VARIABLE employeeid NUMBER
SCOTT@orcl_11gR2> EXEC :employeeid := 1
PL/SQL procedure successfully completed.
SCOTT@orcl_11gR2> VARIABLE search VARCHAR2(100)
SCOTT@orcl_11gR2> EXEC :search := 'highway'
PL/SQL procedure successfully completed.
SCOTT@orcl_11gR2> -- original query:
SCOTT@orcl_11gR2> SET AUTOTRACE ON EXPLAIN
SCOTT@orcl_11gR2> WITH
2 subset AS
3 (SELECT d.duns_loc
4 FROM duns d
5 JOIN primary_contact pc
6 ON d.duns_loc = pc.duns_loc
7 AND pc.emp_id = :employeeID)
8 SELECT score(1), d.*
9 FROM duns d
10 JOIN subset s
11 ON d.duns_loc = s.duns_loc
12 WHERE CONTAINS (TEXT_KEY, :search,1) > 0
13 ORDER BY score(1) DESC
14 /
SCORE(1) DUNS_LOC TEXT_KEY
18 1 highway
1 row selected.
Execution Plan
Plan hash value: 4228563783
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2 | 84 | 121 (4)| 00:00:02 |
| 1 | SORT ORDER BY | | 2 | 84 | 121 (4)| 00:00:02 |
|* 2 | HASH JOIN | | 2 | 84 | 120 (3)| 00:00:02 |
| 3 | NESTED LOOPS | | 38 | 1292 | 50 (2)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| DUNS | 38 | 1102 | 11 (0)| 00:00:01 |
|* 5 | DOMAIN INDEX | DUNS_TEXT_KEY_IDX | | | 4 (0)| 00:00:01 |
|* 6 | INDEX RANGE SCAN | DUNS_DUNS_LOC_IDX | 1 | 5 | 1 (0)| 00:00:01 |
|* 7 | TABLE ACCESS FULL | PRIMARY_CONTACT | 4224 | 33792 | 70 (3)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("D"."DUNS_LOC"="PC"."DUNS_LOC")
5 - access("CTXSYS"."CONTAINS"("D"."TEXT_KEY",:SEARCH,1)>0)
6 - access("D"."DUNS_LOC"="D"."DUNS_LOC")
7 - filter("PC"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2> -- queries with better plans (no nested loops):
SCOTT@orcl_11gR2> -- subquery factoring (with) clauses:
SCOTT@orcl_11gR2> WITH
2 subset1 AS
3 (SELECT pc.duns_loc
4 FROM primary_contact pc
5 WHERE pc.emp_id = :employeeID),
6 subset2 AS
7 (SELECT score(1), d.*
8 FROM duns d
9 WHERE CONTAINS (TEXT_KEY, :search,1) > 0)
10 SELECT subset2.*
11 FROM subset1, subset2
12 WHERE subset1.duns_loc = subset2.duns_loc
13 ORDER BY score(1) DESC
14 /
SCORE(1) DUNS_LOC TEXT_KEY
18 1 highway
1 row selected.
Execution Plan
Plan hash value: 153618227
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 38 | 1406 | 83 (5)| 00:00:01 |
| 1 | SORT ORDER BY | | 38 | 1406 | 83 (5)| 00:00:01 |
|* 2 | HASH JOIN | | 38 | 1406 | 82 (4)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID| DUNS | 38 | 1102 | 11 (0)| 00:00:01 |
|* 4 | DOMAIN INDEX | DUNS_TEXT_KEY_IDX | | | 4 (0)| 00:00:01 |
|* 5 | TABLE ACCESS FULL | PRIMARY_CONTACT | 4224 | 33792 | 70 (3)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("PC"."DUNS_LOC"="D"."DUNS_LOC")
4 - access("CTXSYS"."CONTAINS"("TEXT_KEY",:SEARCH,1)>0)
5 - filter("PC"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2> -- inline views (sub-queries in the from clause):
SCOTT@orcl_11gR2> SELECT subset2.*
2 FROM (SELECT pc.duns_loc
3 FROM primary_contact pc
4 WHERE pc.emp_id = :employeeID) subset1,
5 (SELECT score(1), d.*
6 FROM duns d
7 WHERE CONTAINS (TEXT_KEY, :search,1) > 0) subset2
8 WHERE subset1.duns_loc = subset2.duns_loc
9 ORDER BY score(1) DESC
10 /
SCORE(1) DUNS_LOC TEXT_KEY
18 1 highway
1 row selected.
Execution Plan
Plan hash value: 153618227
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 38 | 1406 | 83 (5)| 00:00:01 |
| 1 | SORT ORDER BY | | 38 | 1406 | 83 (5)| 00:00:01 |
|* 2 | HASH JOIN | | 38 | 1406 | 82 (4)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID| DUNS | 38 | 1102 | 11 (0)| 00:00:01 |
|* 4 | DOMAIN INDEX | DUNS_TEXT_KEY_IDX | | | 4 (0)| 00:00:01 |
|* 5 | TABLE ACCESS FULL | PRIMARY_CONTACT | 4224 | 33792 | 70 (3)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("PC"."DUNS_LOC"="D"."DUNS_LOC")
4 - access("CTXSYS"."CONTAINS"("TEXT_KEY",:SEARCH,1)>0)
5 - filter("PC"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2> -- ansi join:
SCOTT@orcl_11gR2> SELECT SCORE(1), duns.*
2 FROM duns
3 JOIN primary_contact
4 ON duns.duns_loc = primary_contact.duns_loc
5 WHERE CONTAINS (duns.text_key, :search, 1) > 0
6 AND primary_contact.emp_id = :employeeid
7 ORDER BY SCORE(1) DESC
8 /
SCORE(1) DUNS_LOC TEXT_KEY
18 1 highway
1 row selected.
Execution Plan
Plan hash value: 153618227
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 38 | 1406 | 83 (5)| 00:00:01 |
| 1 | SORT ORDER BY | | 38 | 1406 | 83 (5)| 00:00:01 |
|* 2 | HASH JOIN | | 38 | 1406 | 82 (4)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID| DUNS | 38 | 1102 | 11 (0)| 00:00:01 |
|* 4 | DOMAIN INDEX | DUNS_TEXT_KEY_IDX | | | 4 (0)| 00:00:01 |
|* 5 | TABLE ACCESS FULL | PRIMARY_CONTACT | 4224 | 33792 | 70 (3)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("DUNS"."DUNS_LOC"="PRIMARY_CONTACT"."DUNS_LOC")
4 - access("CTXSYS"."CONTAINS"("DUNS"."TEXT_KEY",:SEARCH,1)>0)
5 - filter("PRIMARY_CONTACT"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2> -- old join:
SCOTT@orcl_11gR2> SELECT SCORE(1), duns.*
2 FROM duns, primary_contact
3 WHERE CONTAINS (duns.text_key, :search, 1) > 0
4 AND duns.duns_loc = primary_contact.duns_loc
5 AND primary_contact.emp_id = :employeeid
6 ORDER BY SCORE(1) DESC
7 /
SCORE(1) DUNS_LOC TEXT_KEY
18 1 highway
1 row selected.
Execution Plan
Plan hash value: 153618227
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 38 | 1406 | 83 (5)| 00:00:01 |
| 1 | SORT ORDER BY | | 38 | 1406 | 83 (5)| 00:00:01 |
|* 2 | HASH JOIN | | 38 | 1406 | 82 (4)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID| DUNS | 38 | 1102 | 11 (0)| 00:00:01 |
|* 4 | DOMAIN INDEX | DUNS_TEXT_KEY_IDX | | | 4 (0)| 00:00:01 |
|* 5 | TABLE ACCESS FULL | PRIMARY_CONTACT | 4224 | 33792 | 70 (3)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("DUNS"."DUNS_LOC"="PRIMARY_CONTACT"."DUNS_LOC")
4 - access("CTXSYS"."CONTAINS"("DUNS"."TEXT_KEY",:SEARCH,1)>0)
5 - filter("PRIMARY_CONTACT"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2> -- in clause:
SCOTT@orcl_11gR2> SELECT SCORE(1), duns.*
2 FROM duns
3 WHERE CONTAINS (duns.text_key, :search, 1) > 0
4 AND duns.duns_loc IN
5 (SELECT primary_contact.duns_loc
6 FROM primary_contact
7 WHERE primary_contact.emp_id = :employeeid)
8 ORDER BY SCORE(1) DESC
9 /
SCORE(1) DUNS_LOC TEXT_KEY
18 1 highway
1 row selected.
Execution Plan
Plan hash value: 3825821668
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 38 | 1406 | 83 (5)| 00:00:01 |
| 1 | SORT ORDER BY | | 38 | 1406 | 83 (5)| 00:00:01 |
|* 2 | HASH JOIN SEMI | | 38 | 1406 | 82 (4)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID| DUNS | 38 | 1102 | 11 (0)| 00:00:01 |
|* 4 | DOMAIN INDEX | DUNS_TEXT_KEY_IDX | | | 4 (0)| 00:00:01 |
|* 5 | TABLE ACCESS FULL | PRIMARY_CONTACT | 4224 | 33792 | 70 (3)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("DUNS"."DUNS_LOC"="PRIMARY_CONTACT"."DUNS_LOC")
4 - access("CTXSYS"."CONTAINS"("DUNS"."TEXT_KEY",:SEARCH,1)>0)
5 - filter("PRIMARY_CONTACT"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2> -
I have a Oracle Spatial table with 3.5 million rows plus another auxillary table with 3.5 million rows. A query over these two tables joined returns a full result (250 rows) based on one to one join - here's an example:
Select count(*)
from F, N
where F.id = n.id and (F.GEOM,mdsys.sdo_geometry (2003,8307, null, mdsys.sdo_elem_info_array (1,1003,1), mdsys.sdo_ordinate_array(-120.0,49.5,-119.0,49.5,-119.0,60.35,-120.0,60.35,-120.0,49.5)),
'mask= ANYINTERACT querytype=WINDOW') = 'TRUE') AND N.PNUM = '4';
It takes an average of 35 seconds to get the full result set back. I've gathered statistics, tweaked memory parameters and this is the best I can get. Does anyone have any suggestions?This is an interesting problem. It looks like Oracle is doing the right thing for each of the table accesses - use the index and fetch by rowid.
The only thing you have to play with if you don't go to materialized views or temp tables is how the results of the two table queries are joined.
You don't have a lot of options. Hash join seems to be slow, but you don't know if it is faster or slower compared with nested loops or merge join.
I'd compare what you have done with something like the following to test nested loops:
select /*+ no_merge use_nl (f1,n1) */ count(*)
from
(select id
from f
where sdo_anyinteract ( F.GEOM,
sdo_geometry (2003,8307, null, sdo_elem_info_array (1,1003,1),
sdo_ordinate_array (-120.0,49.5,-119.0,49.5,-119.0,60.35,
-120.0,60.35,-120.0,49.5))) = 'TRUE') f1,
(select id
from n
where n.pnum='4') n1
where f1.id=n1.id ;
and presort with a merge join hint to see how it performs:
select /*+ no_merge use_merge (f1,n1) */ count(*)
from
(select id
from f
where sdo_anyinteract ( F.GEOM,
sdo_geometry (2003,8307, null, sdo_elem_info_array (1,1003,1),
sdo_ordinate_array (-120.0,49.5,-119.0,49.5,-119.0,60.35,
-120.0,60.35,-120.0,49.5))) = 'TRUE'
order by id) f1,
(select id
from n
where n.pnum='4'
order by id) n1
where f1.id=n1.id ;
It might be that you already have the best Oracle can do, but I'd be curious to know how you make out.
Dan Abugov
VP Software Support and Services
Acquis Inc. -
Performance- Hash Joins ?
Hi everyone,
Version :- 10.1.0.5.0
Below is the query and it takes long time to execute due to hash joins. Is there ant other way to change change the join approach or rewrite the SQL.
Tables used
rhs_premium :- 830 GB with partitons.
bu_res_line_map :- small table 4 MB
mgt_unit_res_line_map :- small table with 4 MB
mgt_unit_reserving_lines :- View
bu_reserving_lines :- View
SELECT prem.business_unit,
prem.direct_assumed_ceded_code,
prem.ledger_currency_code,
prem.mcc_code,
prem.management_unit,
prem.product,
prem.financial_product,
nvl(prem.premium_in_ledger_currency,0) premium_in_ledger_currency, -- NVL added Aug 21, 2008
nvl(prem.premium_in_original_currency,0) premium_in_original_currency, -- Added Aug 21, 2008 M4640
nvl(prem.premium_in_us_dollars,0) premium_in_us_dollars, -- NVL added Aug 21, 2008
prem.rcc,
prem.pre_explosion_rcc, -- Issue M1997 Laks 09/15
prem.acc_code,
prem.transaction_code,
prem.accounting_period,
prem.exposure_period,
prem.policy_effective_month,
prem.policy_key,
prem.policy_line_of_business,
prem.producer_code,
prem.underwriting_year,
prem.ledger_key,
prem.account_key,
prem.policy_coverage_key,
nvl(prem.original_currency_code,' ') original_currency_code, -- NVL added Issue M4640 Aug 21, 2008
prem.authorized_unauthorized,
prem.transaction_effective_date,
prem.transaction_expiration_date,
prem.exposure_year,
prem.reinsurance_mask,
prem.rcccategory,
prem.rccclassification,
prem.detail_level_indicator,
prem.bermbase_level_indicator,
prem.padb_level_indicator,
prem.sas_level_indicator, -- Issue 443
prem.cnv_adjust_indicator, -- Issue 413
prem.originating_business_unit,
prem.actuarial_blend_indicator,
ml1.management_line_of_business_id management_lob_id_act,
mu1.reserving_line_id mgt_unit_reserving_lob_id_act,
bu1.reserving_line_id business_unit_lob_id_act,
ml1.reserving_class_id mgt_unit_res_class_lob_id_act, -- added A12
bl1.reserving_class_id business_unit_class_lob_id_act,-- added A12
ml2.management_line_of_business_id management_lob_id_fin,
mu2.reserving_line_id mgt_unit_reserving_lob_id_fin,
bu2.reserving_line_id business_unit_lob_id_fin,
ml2.reserving_class_id mgt_unit_res_class_lob_id_fin, -- added A12
bl2.reserving_class_id business_unit_class_lob_id_fin -- added A12
FROM rhs_premium prem,
bu_res_line_map bu1,
mgt_unit_res_line_map mu1,
mgt_unit_reserving_lines ml1,
bu_reserving_lines bl1, -- added A12
bu_res_line_map bu2,
mgt_unit_res_line_map mu2,
mgt_unit_reserving_lines ml2,
bu_reserving_lines bl2 -- added A12
WHERE ( prem.business_unit = bu1.business_unit (+)
AND prem.product = bu1.product (+)
AND ( prem.management_unit = mu1.management_unit (+)
AND prem.product = mu1.product(+)
AND mu1.reserving_line_id = ml1.reserving_line_id (+)
AND bu1.reserving_line_id = bl1.reserving_line_id (+) -- added A12
AND ( prem.business_unit = bu2.business_unit (+)
AND prem.financial_product = bu2.product (+)
AND ( prem.management_unit = mu2.management_unit (+)
AND prem.financial_product = mu2.product(+)
AND mu2.reserving_line_id = ml2.reserving_line_id (+)
AND bu2.reserving_line_id = bl2.reserving_line_id (+);
PLAN_TABLE_OUTPUT
Plan hash value: 3475794837
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 346M| 124G| 416K (2)| 01:37:13 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10008 | 346M| 124G| 416K (2)| 01:37:13 | | | Q1,08 | P->S | QC (RAND) |
|* 3 | HASH JOIN RIGHT OUTER | | 346M| 124G| 416K (2)| 01:37:13 | | | Q1,08 | PCWP | |
| 4 | BUFFER SORT | | | | | | | | Q1,08 | PCWC | |
| 5 | PX RECEIVE | | 46 | 1196 | 7 (0)| 00:00:01 | | | Q1,08 | PCWP | |
| 6 | PX SEND BROADCAST | :TQ10000 | 46 | 1196 | 7 (0)| 00:00:01 | | | | S->P | BROADCAST |
| 7 | VIEW | BU_RESERVING_LINES | 46 | 1196 | 7 (0)| 00:00:01 | | | | | |
| 8 | NESTED LOOPS OUTER | | 46 | 1748 | 7 (0)| 00:00:01 | | | | | |
|* 9 | TABLE ACCESS FULL | RESERVING_LINES | 46 | 1564 | 7 (0)| 00:00:01 | | | | | |
|* 10 | INDEX UNIQUE SCAN | RESERVING_CLASSES_PK | 1 | 4 | 0 (0)| 00:00:01 | | | | | |
|* 11 | HASH JOIN RIGHT OUTER | | 346M| 116G| 415K (2)| 01:37:04 | | | Q1,08 | PCWP | |
| 12 | BUFFER SORT | | | | | | | | Q1,08 | PCWC | |
| 13 | PX RECEIVE | | 124K| 2182K| 87 (2)| 00:00:02 | | | Q1,08 | PCWP | |
| 14 | PX SEND BROADCAST | :TQ10001 | 124K| 2182K| 87 (2)| 00:00:02 | | | | S->P | BROADCAST |
| 15 | TABLE ACCESS FULL | BU_RES_LINE_MAP | 124K| 2182K| 87 (2)| 00:00:02 | | | | | |
|* 16 | HASH JOIN RIGHT OUTER | | 346M| 110G| 415K (2)| 01:36:54 | | | Q1,08 | PCWP | |
| 17 | BUFFER SORT | | | | | | | | Q1,08 | PCWC | |
| 18 | PX RECEIVE | | 46 | 1196 | 7 (0)| 00:00:01 | | | Q1,08 | PCWP | |
| 19 | PX SEND BROADCAST | :TQ10002 | 46 | 1196 | 7 (0)| 00:00:01 | | | | S->P | BROADCAST |
| 20 | VIEW | BU_RESERVING_LINES | 46 | 1196 | 7 (0)| 00:00:01 | | | | | |
| 21 | NESTED LOOPS OUTER | | 46 | 1748 | 7 (0)| 00:00:01 | | | | | |
|* 22 | TABLE ACCESS FULL | RESERVING_LINES | 46 | 1564 | 7 (0)| 00:00:01 | | | | | |
|* 23 | INDEX UNIQUE SCAN | RESERVING_CLASSES_PK | 1 | 4 | 0 (0)| 00:00:01 | | | | | |
|* 24 | HASH JOIN RIGHT OUTER | | 346M| 101G| 414K (1)| 01:36:45 | | | Q1,08 | PCWP | |
| 25 | BUFFER SORT | | | | | | | | Q1,08 | PCWC | |
| 26 | PX RECEIVE | | 124K| 2182K| 87 (2)| 00:00:02 | | | Q1,08 | PCWP | |
| 27 | PX SEND BROADCAST | :TQ10003 | 124K| 2182K| 87 (2)| 00:00:02 | | | | S->P | BROADCAST |
| 28 | TABLE ACCESS FULL | BU_RES_LINE_MAP | 124K| 2182K| 87 (2)| 00:00:02 | | | | | |
|* 29 | HASH JOIN RIGHT OUTER | | 346M| 96G| 413K (1)| 01:36:35 | | | Q1,08 | PCWP | |
| 30 | BUFFER SORT | | | | | | | | Q1,08 | PCWC | |
| 31 | PX RECEIVE | | 46 | 1794 | 11 (10)| 00:00:01 | | | Q1,08 | PCWP | |
| 32 | PX SEND BROADCAST | :TQ10004 | 46 | 1794 | 11 (10)| 00:00:01 | | | | S->P | BROADCAST |
| 33 | VIEW | MGT_UNIT_RESERVING_LINES | 46 | 1794 | 11 (10)| 00:00:01 | | | | | |
|* 34 | HASH JOIN OUTER | | 46 | 1886 | 11 (10)| 00:00:01 | | | | | |
|* 35 | TABLE ACCESS FULL | RESERVING_LINES | 46 | 1564 | 7 (0)| 00:00:01 | | | | | |
| 36 | TABLE ACCESS FULL | RESERVING_CLASSES | 107 | 749 | 3 (0)| 00:00:01 | | | | | |
|* 37 | HASH JOIN RIGHT OUTER | | 346M| 83G| 413K (1)| 01:36:26 | | | Q1,08 | PCWP | |
| 38 | BUFFER SORT | | | | | | | | Q1,08 | PCWC | |
| 39 | PX RECEIVE | | 93763 | 1648K| 59 (0)| 00:00:01 | | | Q1,08 | PCWP | |
| 40 | PX SEND BROADCAST | :TQ10005 | 93763 | 1648K| 59 (0)| 00:00:01 | | | | S->P | BROADCAST |
| 41 | INDEX FAST FULL SCAN | MGT_UNIT_RES_LINE_MAP_UK | 93763 | 1648K| 59 (0)| 00:00:01 | | | | | |
|* 42 | HASH JOIN RIGHT OUTER | | 346M| 77G| 412K (1)| 01:36:17 | | | Q1,08 | PCWP | |
| 43 | BUFFER SORT | | | | | | | | Q1,08 | PCWC | |
| 44 | PX RECEIVE | | 46 | 1794 | 11 (10)| 00:00:01 | | | Q1,08 | PCWP | |
| 45 | PX SEND BROADCAST | :TQ10006 | 46 | 1794 | 11 (10)| 00:00:01 | | | | S->P | BROADCAST |
| 46 | VIEW | MGT_UNIT_RESERVING_LINES | 46 | 1794 | 11 (10)| 00:00:01 | | | | | |
|* 47 | HASH JOIN OUTER | | 46 | 1886 | 11 (10)| 00:00:01 | | | | | |
|* 48 | TABLE ACCESS FULL | RESERVING_LINES | 46 | 1564 | 7 (0)| 00:00:01 | | | | | |
| 49 | TABLE ACCESS FULL | RESERVING_CLASSES | 107 | 749 | 3 (0)| 00:00:01 | | | | | |
|* 50 | HASH JOIN RIGHT OUTER | | 346M| 65G| 411K (1)| 01:36:08 | | | Q1,08 | PCWP | |
| 51 | BUFFER SORT | | | | | | | | Q1,08 | PCWC | |
| 52 | PX RECEIVE | | 93763 | 1648K| 59 (0)| 00:00:01 | | | Q1,08 | PCWP | |
| 53 | PX SEND BROADCAST | :TQ10007 | 93763 | 1648K| 59 (0)| 00:00:01 | | | | S->P | BROADCAST |
| 54 | INDEX FAST FULL SCAN| MGT_UNIT_RES_LINE_MAP_UK | 93763 | 1648K| 59 (0)| 00:00:01 | | | | | |
| 55 | PX BLOCK ITERATOR | | 346M| 59G| 411K (1)| 01:35:58 | 1 | 385 | Q1,08 | PCWC | |
| 56 | TABLE ACCESS FULL | RHS_PREMIUM_1 | 346M| 59G| 411K (1)| 01:35:58 | 1 | 385 | Q1,08 | PCWP | |
Predicate Information (identified by operation id):
3 - access("BU2"."RESERVING_LINE_ID"="BL2"."RESERVING_LINE_ID"(+))
9 - filter("RL"."RESERVING_LINE_TYPE"='BU')
10 - access("RL"."RESERVING_CLASS_ID"="RC"."RESERVING_CLASS_ID"(+))
11 - access("PREM"."BUSINESS_UNIT"="BU2"."BUSINESS_UNIT"(+) AND "PREM"."FINANCIAL_PRODUCT"="BU2"."PRODUCT"(+))
16 - access("BU1"."RESERVING_LINE_ID"="BL1"."RESERVING_LINE_ID"(+))
22 - filter("RL"."RESERVING_LINE_TYPE"='BU')
23 - access("RL"."RESERVING_CLASS_ID"="RC"."RESERVING_CLASS_ID"(+))
24 - access("PREM"."BUSINESS_UNIT"="BU1"."BUSINESS_UNIT"(+) AND "PREM"."PRODUCT"="BU1"."PRODUCT"(+))
29 - access("MU2"."RESERVING_LINE_ID"="ML2"."RESERVING_LINE_ID"(+))
34 - access("RL"."RESERVING_CLASS_ID"="RC"."RESERVING_CLASS_ID"(+))
35 - filter("RL"."RESERVING_LINE_TYPE"='MCC')
37 - access("PREM"."MANAGEMENT_UNIT"="MU2"."MANAGEMENT_UNIT"(+) AND "PREM"."FINANCIAL_PRODUCT"="MU2"."PRODUCT"(+))
42 - access("MU1"."RESERVING_LINE_ID"="ML1"."RESERVING_LINE_ID"(+))
47 - access("RL"."RESERVING_CLASS_ID"="RC"."RESERVING_CLASS_ID"(+))
48 - filter("RL"."RESERVING_LINE_TYPE"='MCC')
50 - access("PREM"."MANAGEMENT_UNIT"="MU1"."MANAGEMENT_UNIT"(+) AND "PREM"."PRODUCT"="MU1"."PRODUCT"(+))Please let me know if there is any possibilty.
Regards,
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. -
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 -
Hi all,
I have a requirement of joining two data sets in a template.
I have to create a table in template with the combined xml output of 2 queries.
I need to join one column(say 'idnumber' ) in one data set to the column('sidnumber') in another dataset and so that idname should appear in one of the fields in the template after joining.
can any one throw light on this issue asap pleaseI have a requirement this way:
I have xml as shown below:
<DATA>
<SQL>
<SQL_ROW>
<c1>99384</c1>
<c2>QWEHJ</c2>
<c3>737272</c3>
<c4>-2342345</c4>
</SQl_ROW>
<SQL_ROW>
<c1>34535</c1>
<c2>dfgsdf</c2>
<c3>737272</c3>
<c4>-2342345</c4>
</SQl_ROW>
<SQL_ROW>
<c1>99384</c1>
<c2>QWEHJ</c2>
<c3>737272</c3>
<c4>-2342345</c4>
</SQl_ROW>
<SQL>
<fc_map>
<fc_map_row>
<f1>34535</f1>
<f2>ABCD</f2>
</fc_map_row>
<fc_map_row>
<f1>34534</f1>
<f2>DFDF</f2>
</fc_map_row>
<fc_map_row>
<f1>4524</f1>
<f2>FSSDSFDFWE</f2>
</fc_map_row>
</fc_map>
</DATA>
I have to put a condition for a field to match the f1,c1 columns
I need to join the columns f1 and c1 such that the field in the rtf gives the name after joining. its is in such a way that, the customer id lies in one data set and customer name lies in other dataset and we need to join the two datasets by customerid and hence the name of the customer is displayed in the report. -
Performing multiple joins on table
Hi all,
I would like to know if performing joins on more than 10 tables has some performance issues? If so, is there any limit on the joins that can be done?
Is there another way out for this problem?Rob Burbank wrote:>
> >
Thomas Zloch wrote:
> > If I had to bet, I'd say no, not included...do you have time to try out with a little test program?
> Probably not so little, but maybe sometime. I know there are standard SAP views with upwards of 13 or 14 tables, but I doubt if they would be compatable for joining.
>
> Rob
How about a self join? -
How to retrieve data from a dimension that is not directly joined to a fact
Hi,
In my case I have 2 dimensions and one fact. I need to runa report collecting data from all the three tables.
I need to do the following.
DIMA DIMB FACT1
FACT1 is joined with DIMA
DIMA is joined with DIMB
FACT1 is not Joined with DIMB.
My report should still retrieve information from DIMB by connecting FACT1 with DIMA and retrieve corresponding data from DIMB.
Please suggest how can I do this .
I am using 10.1.3 version of OBIEE
You help will be much appreciated.Hi,
I think your data model is snow-flake schema,we can get the data from snow-flake schema also.Pull the columns from both fact and DIMB into criteria.It will display the result.
mark if helpful/correct...
thanks,
prassu -
Why oh why, weird performance on joining large tables
Hello.
I have a large table cotaining dates and customer data. Organised as:
DATE CUSTOMER_ID INFOCOLUMN1 INFOCOLUMN2 etc...
Rows per date are a couple of million.
What I'm trying to do is to make a comparison between date a and date b and track changes in the database.
When I do a:
SELECT stuff
FROM table t1
INNER JOIN table t2
ON t1.CUSTOMER_ID = t2.CUSTOMER_ID
WHERE t1.date = TO_DATE(SOME_DATE)
AND t2.date = TO_DATE(SOME_OTHER_DATE)I get a result in about 40 seconds which is acceptable.
Then I try doing:
SELECT stuff
FROM (SELECT TO_DATE(LAST_DAY(ADD_MONTHS(SYSDATE, 0 - r.l))) AS DATE FROM dual INNER JOIN (SELECT level l FROM dual CONNECT BY LEVEL <= 1) r ON 1 = 1) time
INNER JOIN table t1
ON t1.date = time.date
INNER JOIN table t2
ON t1.CUSTOMER_ID = t2.CUSTOMER_ID
WHERE t2.date = ADD_MONTHS(time.date, -1)Ie i generate a datefield from a subselect which I then use to join the tables with.
When I try that the query takes an hour or two to complete with the same resultset as the first example.
THe only difference is that in the first case I give the dates literally but in the other case I generate them in the subselect. It's the same dates and they are formatted as dates in both cases.
Any ideas?
Thanks
Edited by: user1970293 on 2010-apr-29 00:52
Edited by: user1970293 on 2010-apr-29 00:59When I try that the query takes an hour or two to complete with the same resultset as the first example.If you get the same results, than why change the query to the second one?
THe only difference is that in the first case I give the dates literally but in the other case I generate them in the subselect. It's the same dates and they are formatted as dates in both cases.Dates are dates,... the formatting is just "pretty"
This
select to_date(last_day(add_months(sysdate
,0 - r.l)))
from dual
inner join (select level l from dual connect by level <= 1) r on 1 = 1doesn't make much sense... what is it supposed to do?
(by the way: you are doing a TO_DATE on a DATE...)
Maybe you are looking for
-
What is the best photo paper 4'x6' for HP Officejet Pro 8500A Plus e-All-in-one Printer?
1.-HP Officejet Pro 8500A Plus e-All-in-One Printer 2.-OS: Windows 7-64 3.-No error messages 4.-No changes have been made 5.-I have been printing in my with old "hp premium plus glossyphoto paper" and getting very dark photos and too much wasted ink
-
Pleeeeeeaaaaaaseeeeeee Help! I have a flash movie which is taller than the browser window, but rather than it being scrolled by the browsers default scrollbar I want to create a scrollbar swf file which will control the scrolling of the movie within
-
Kernel Upgrade for old SAP Ides system
HI, How I need to install 4.6c Kernel 4.6d patch level 948 on the following system SAP Ides - R/3 4.C SAP Package level 534 Support Package Manager version 4.6c/0028 Oracle 8.1.7.0.0 ABAB Load 1258 Kernel 46D Could someone please tell me what I need
-
How to trasnfer my PhonePower number to my skype?
Hi There, I have a number with another provided (phone power). I do not use the number other than forward the calls to my skype number. So I am paying for phone power service every month and also paying for my skype number. I need to keep the PhoneP
-
I want to add one extra field in one particular message in External defination,how I should go for it? I want detail process to go forward with it.