Query help, join 3 times
Hi Friends,
the example table is:
EMP : columns are emp_id (primary Key), name
STORES_REQUISITION_MASTER: columns are
req_id,
req_date,
requested_by(referes to emp_id of EMP),
approved_by(refers to emp_id of EMP),
authorised_by (refers to emp_id of EMP)
and i want a report of all requisitions like this.
req_id,req_date,name_of_the_reuested_employee,name_of_approved_employee,name_of_authorised_employee.
what is the best way to get this format.
thanks in advance.
SELECT S.req_id, S.req_date, R.name, A.name, T.name
FROM Stores_Requisition_Master S,
EMP R,
EMP A,
EMP T
WHERE S.requested_by = R.id
AND S.approved_by = A.id
AND S.authorised_by = T.id;
Similar Messages
-
Seibel Query help : - Joining Order table with Asset or CX_ACTION table.
Hi Team
I need help joining the Order table with the Asset table
or the Order table with CX_ACTION table to
Can i get reference on this .
select x.x_msisdn,
x.x_product_name,
x.x_action,
x.x_status_outcome,
a.recovered_dt,
x.x_amount,
x.created,
x.x_number_retries,
o.ORDER_NUM "FMW Order No",
DECODE(FULFLMNT_STATUS_CD , 'Failed','Failed', o.STATUS_CD) "Order Status"
from
siebel.cx_action x,
siebel.s_order o,
siebel.s_asset a
where a.row_id = x.x_asset_id
and x.created > to_date('08/01/2013 08:00:00', 'dd/mm/yyyy hh24:mi:ss')
and x.created < to_date('09/04/2013 07:50:00', 'dd/mm/yyyy hh24:mi:ss')
RegardsI'm not familiar with Seibel or any of these tables but right off the bat I'd suggest you're missing a join predicate to your s_order table. This could give you far more rows than you're expecting.
Aside from that you haven't told us what problems you are having. An error? Wrong results? Performance? -
Pagination query help needed for large table - force a different index
I'm using a slight modification of the pagination query from over at Ask Tom's: [http://www.oracle.com/technology/oramag/oracle/07-jan/o17asktom.html]
Mine looks like this when fetching the first 100 rows of all members with last name Smith, ordered by join date:
SELECT members.*
FROM members,
SELECT RID, rownum rnum
FROM
SELECT rowid as RID
FROM members
WHERE last_name = 'Smith'
ORDER BY joindate
WHERE rownum <= 100
WHERE rnum >= 1
and RID = members.rowidThe difference between this and the one at Ask Tom's is that my innermost query just returns the ROWID. Then in the outermost query we join the ROWIDs returned to the members table, after we have pruned the ROWIDs down to only the chunk of 100 we want. This makes it MUCH faster (verifiably) on our large tables, as it is able to use the index on the innermost query (well... read on).
The problem I have is this:
SELECT rowid as RID
FROM members
WHERE last_name = 'Smith'
ORDER BY joindateThis will use the index for the predicate column (last_name) instead of the unique index I have defined for the joindate column (joindate, sequence). (Verifiable with explain plan). It is much slower this way on a large table. So I can hint it using either of the following methods:
SELECT /*+ index(members, joindate_idx) */ rowid as RID
FROM members
WHERE last_name = 'Smith'
ORDER BY joindate
SELECT /*+ first_rows(100) */ rowid as RID
FROM members
WHERE last_name = 'Smith'
ORDER BY joindateEither way, it now uses the index of the ORDER BY column (joindate_idx), so now it is much faster as it does not have to do a sort (remember, VERY large table, millions of records). So that seems good. But now, on my outermost query, I join the rowid with the meaningful columns of data from the members table, as commented below:
SELECT members.* -- Select all data from members table
FROM members, -- members table added to FROM clause
SELECT RID, rownum rnum
FROM
SELECT /*+ index(members, joindate_idx) */ rowid as RID -- Hint is ignored now that I am joining in the outer query
FROM members
WHERE last_name = 'Smith'
ORDER BY joindate
WHERE rownum <= 100
WHERE rnum >= 1
and RID = members.rowid -- Merge the members table on the rowid we pulled from the inner queriesOnce I do this join, it goes back to using the predicate index (last_name) and has to perform the sort once it finds all matching values (which can be a lot in this table, there is high cardinality on some columns).
So my question is, in the full query above, is there any way I can get it to use the ORDER BY column for indexing to prevent it from having to do a sort? The join is what causes it to revert back to using the predicate index, even with hints. Remove the join and just return the ROWIDs for those 100 records and it flies, even on 10 million records.
It'd be great if there was some generic hint that could accomplish this, such that if we change the table/columns/indexes, we don't need to change the hint (the FIRST_ROWS hint is a good example of this, while the INDEX hint is the opposite), but any help would be appreciated. I can provide explain plans for any of the above if needed.
Thanks!Lakmal Rajapakse wrote:
OK here is an example to illustrate the advantage:
SQL> set autot traceonly
SQL> select * from (
2 select a.*, rownum x from
3 (
4 select a.* from aoswf.events a
5 order by EVENT_DATETIME
6 ) a
7 where rownum <= 1200
8 )
9 where x >= 1100
10 /
101 rows selected.
Execution Plan
Plan hash value: 3711662397
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1200 | 521K| 192 (0)| 00:00:03 |
|* 1 | VIEW | | 1200 | 521K| 192 (0)| 00:00:03 |
|* 2 | COUNT STOPKEY | | | | | |
| 3 | VIEW | | 1200 | 506K| 192 (0)| 00:00:03 |
| 4 | TABLE ACCESS BY INDEX ROWID| EVENTS | 253M| 34G| 192 (0)| 00:00:03 |
| 5 | INDEX FULL SCAN | EVEN_IDX02 | 1200 | | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("X">=1100)
2 - filter(ROWNUM<=1200)
Statistics
0 recursive calls
0 db block gets
443 consistent gets
0 physical reads
0 redo size
25203 bytes sent via SQL*Net to client
281 bytes received via SQL*Net from client
8 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
101 rows processed
SQL>
SQL>
SQL> select * from aoswf.events a, (
2 select rid, rownum x from
3 (
4 select rowid rid from aoswf.events a
5 order by EVENT_DATETIME
6 ) a
7 where rownum <= 1200
8 ) b
9 where x >= 1100
10 and a.rowid = rid
11 /
101 rows selected.
Execution Plan
Plan hash value: 2308864810
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1200 | 201K| 261K (1)| 00:52:21 |
| 1 | NESTED LOOPS | | 1200 | 201K| 261K (1)| 00:52:21 |
|* 2 | VIEW | | 1200 | 30000 | 260K (1)| 00:52:06 |
|* 3 | COUNT STOPKEY | | | | | |
| 4 | VIEW | | 253M| 2895M| 260K (1)| 00:52:06 |
| 5 | INDEX FULL SCAN | EVEN_IDX02 | 253M| 4826M| 260K (1)| 00:52:06 |
| 6 | TABLE ACCESS BY USER ROWID| EVENTS | 1 | 147 | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter("X">=1100)
3 - filter(ROWNUM<=1200)
Statistics
8 recursive calls
0 db block gets
117 consistent gets
0 physical reads
0 redo size
27539 bytes sent via SQL*Net to client
281 bytes received via SQL*Net from client
8 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
101 rows processed
Lakmal (and OP),
Not sure what advantage you are trying to show here. But considering that we are talking about pagination query here and order of records is important, your 2 queries will not always generate output in same order. Here is the test case:
SQL> select * from v$version ;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for Linux: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
SQL> show parameter optimizer
NAME TYPE VALUE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.2.0.1
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
SQL> show parameter pga
NAME TYPE VALUE
pga_aggregate_target big integer 103M
SQL> create table t nologging as select * from all_objects where 1 = 2 ;
Table created.
SQL> create index t_idx on t(last_ddl_time) nologging ;
Index created.
SQL> insert /*+ APPEND */ into t (owner, object_name, object_id, created, last_ddl_time) select owner, object_name, object_id, created, sysdate - dbms_random.value(1, 100) from all_objects order by dbms_random.random;
40617 rows created.
SQL> commit ;
Commit complete.
SQL> exec dbms_stats.gather_table_stats(user, 'T', cascade=>true);
PL/SQL procedure successfully completed.
SQL> select object_id, object_name, created from t, (select rid, rownum rn from (select rowid rid from t order by created desc) where rownum <= 1200) t1 where rn >= 1190 and t.rowid = t1.rid ;
OBJECT_ID OBJECT_NAME CREATED
47686 ALL$OLAP2_JOIN_KEY_COLUMN_USES 28-JUL-2009 08:08:39
47672 ALL$OLAP2_CUBE_DIM_USES 28-JUL-2009 08:08:39
47681 ALL$OLAP2_CUBE_MEASURE_MAPS 28-JUL-2009 08:08:39
47682 ALL$OLAP2_FACT_LEVEL_USES 28-JUL-2009 08:08:39
47685 ALL$OLAP2_AGGREGATION_USES 28-JUL-2009 08:08:39
47692 ALL$OLAP2_CATALOGS 28-JUL-2009 08:08:39
47665 ALL$OLAPMR_FACTTBLKEYMAPS 28-JUL-2009 08:08:39
47688 ALL$OLAP2_DIM_LEVEL_ATTR_MAPS 28-JUL-2009 08:08:39
47689 ALL$OLAP2_DIM_LEVELS_KEYMAPS 28-JUL-2009 08:08:39
47669 ALL$OLAP9I2_HIER_DIMENSIONS 28-JUL-2009 08:08:39
47666 ALL$OLAP9I1_HIER_DIMENSIONS 28-JUL-2009 08:08:39
11 rows selected.
SQL> select object_id, object_name, last_ddl_time from t, (select rid, rownum rn from (select rowid rid from t order by last_ddl_time desc) where rownum <= 1200) t1 where rn >= 1190 and t.rowid = t1.rid ;
OBJECT_ID OBJECT_NAME LAST_DDL_TIME
11749 /b9fe5b99_OraRTStatementComman 06-FEB-2010 03:43:49
13133 oracle/jdbc/driver/OracleLog$3 06-FEB-2010 03:45:44
37534 com/sun/mail/smtp/SMTPMessage 06-FEB-2010 03:46:14
36145 /4e492b6f_SerProfileToClassErr 06-FEB-2010 03:11:09
26815 /7a628fb8_DefaultHSBChooserPan 06-FEB-2010 03:26:55
16695 /2940a364_RepIdDelegator_1_3 06-FEB-2010 03:38:17
36539 sun/io/ByteToCharMacHebrew 06-FEB-2010 03:28:57
14044 /d29b81e1_OldHeaders 06-FEB-2010 03:12:12
12920 /25f8f3a5_BasicSplitPaneUI 06-FEB-2010 03:11:06
42266 SI_GETCLRHSTGRFTR 06-FEB-2010 03:40:20
15752 /2f494dce_JDWPThreadReference 06-FEB-2010 03:09:31
11 rows selected.
SQL> select object_id, object_name, last_ddl_time from (select t1.*, rownum rn from (select * from t order by last_ddl_time desc) t1 where rownum <= 1200) where rn >= 1190 ;
OBJECT_ID OBJECT_NAME LAST_DDL_TIME
37534 com/sun/mail/smtp/SMTPMessage 06-FEB-2010 03:46:14
13133 oracle/jdbc/driver/OracleLog$3 06-FEB-2010 03:45:44
11749 /b9fe5b99_OraRTStatementComman 06-FEB-2010 03:43:49
42266 SI_GETCLRHSTGRFTR 06-FEB-2010 03:40:20
16695 /2940a364_RepIdDelegator_1_3 06-FEB-2010 03:38:17
36539 sun/io/ByteToCharMacHebrew 06-FEB-2010 03:28:57
26815 /7a628fb8_DefaultHSBChooserPan 06-FEB-2010 03:26:55
14044 /d29b81e1_OldHeaders 06-FEB-2010 03:12:12
36145 /4e492b6f_SerProfileToClassErr 06-FEB-2010 03:11:09
12920 /25f8f3a5_BasicSplitPaneUI 06-FEB-2010 03:11:06
15752 /2f494dce_JDWPThreadReference 06-FEB-2010 03:09:31
11 rows selected.
SQL> select object_id, object_name, last_ddl_time from t, (select rid, rownum rn from (select rowid rid from t order by last_ddl_time desc) where rownum <= 1200) t1 where rn >= 1190 and t.rowid = t1.rid order by last_ddl_time desc ;
OBJECT_ID OBJECT_NAME LAST_DDL_TIME
37534 com/sun/mail/smtp/SMTPMessage 06-FEB-2010 03:46:14
13133 oracle/jdbc/driver/OracleLog$3 06-FEB-2010 03:45:44
11749 /b9fe5b99_OraRTStatementComman 06-FEB-2010 03:43:49
42266 SI_GETCLRHSTGRFTR 06-FEB-2010 03:40:20
16695 /2940a364_RepIdDelegator_1_3 06-FEB-2010 03:38:17
36539 sun/io/ByteToCharMacHebrew 06-FEB-2010 03:28:57
26815 /7a628fb8_DefaultHSBChooserPan 06-FEB-2010 03:26:55
14044 /d29b81e1_OldHeaders 06-FEB-2010 03:12:12
36145 /4e492b6f_SerProfileToClassErr 06-FEB-2010 03:11:09
12920 /25f8f3a5_BasicSplitPaneUI 06-FEB-2010 03:11:06
15752 /2f494dce_JDWPThreadReference 06-FEB-2010 03:09:31
11 rows selected.
SQL> set autotrace traceonly
SQL> select object_id, object_name, last_ddl_time from t, (select rid, rownum rn from (select rowid rid from t order by last_ddl_time desc) where rownum <= 1200) t1 where rn >= 1190 and t.rowid = t1.rid order by last_ddl_time desc
2 ;
11 rows selected.
Execution Plan
Plan hash value: 44968669
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1200 | 91200 | 180 (2)| 00:00:03 |
| 1 | SORT ORDER BY | | 1200 | 91200 | 180 (2)| 00:00:03 |
|* 2 | HASH JOIN | | 1200 | 91200 | 179 (2)| 00:00:03 |
|* 3 | VIEW | | 1200 | 30000 | 98 (0)| 00:00:02 |
|* 4 | COUNT STOPKEY | | | | | |
| 5 | VIEW | | 40617 | 475K| 98 (0)| 00:00:02 |
| 6 | INDEX FULL SCAN DESCENDING| T_IDX | 40617 | 793K| 98 (0)| 00:00:02 |
| 7 | TABLE ACCESS FULL | T | 40617 | 2022K| 80 (2)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("T".ROWID="T1"."RID")
3 - filter("RN">=1190)
4 - filter(ROWNUM<=1200)
Statistics
1 recursive calls
0 db block gets
348 consistent gets
0 physical reads
0 redo size
1063 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
11 rows processed
SQL> select object_id, object_name, last_ddl_time from (select t1.*, rownum rn from (select * from t order by last_ddl_time desc) t1 where rownum <= 1200) where rn >= 1190 ;
11 rows selected.
Execution Plan
Plan hash value: 882605040
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1200 | 62400 | 80 (2)| 00:00:01 |
|* 1 | VIEW | | 1200 | 62400 | 80 (2)| 00:00:01 |
|* 2 | COUNT STOPKEY | | | | | |
| 3 | VIEW | | 40617 | 1546K| 80 (2)| 00:00:01 |
|* 4 | SORT ORDER BY STOPKEY| | 40617 | 2062K| 80 (2)| 00:00:01 |
| 5 | TABLE ACCESS FULL | T | 40617 | 2062K| 80 (2)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("RN">=1190)
2 - filter(ROWNUM<=1200)
4 - filter(ROWNUM<=1200)
Statistics
0 recursive calls
0 db block gets
343 consistent gets
0 physical reads
0 redo size
1063 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
11 rows processed
SQL> select object_id, object_name, last_ddl_time from t, (select rid, rownum rn from (select rowid rid from t order by last_ddl_time desc) where rownum <= 1200) t1 where rn >= 1190 and t.rowid = t1.rid ;
11 rows selected.
Execution Plan
Plan hash value: 168880862
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1200 | 91200 | 179 (2)| 00:00:03 |
|* 1 | HASH JOIN | | 1200 | 91200 | 179 (2)| 00:00:03 |
|* 2 | VIEW | | 1200 | 30000 | 98 (0)| 00:00:02 |
|* 3 | COUNT STOPKEY | | | | | |
| 4 | VIEW | | 40617 | 475K| 98 (0)| 00:00:02 |
| 5 | INDEX FULL SCAN DESCENDING| T_IDX | 40617 | 793K| 98 (0)| 00:00:02 |
| 6 | TABLE ACCESS FULL | T | 40617 | 2022K| 80 (2)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("T".ROWID="T1"."RID")
2 - filter("RN">=1190)
3 - filter(ROWNUM<=1200)
Statistics
0 recursive calls
0 db block gets
349 consistent gets
0 physical reads
0 redo size
1063 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
11 rows processed
SQL> select object_id, object_name, last_ddl_time from (select t1.*, rownum rn from (select * from t order by last_ddl_time desc) t1 where rownum <= 1200) where rn >= 1190 order by last_ddl_time desc ;
11 rows selected.
Execution Plan
Plan hash value: 882605040
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1200 | 62400 | 80 (2)| 00:00:01 |
|* 1 | VIEW | | 1200 | 62400 | 80 (2)| 00:00:01 |
|* 2 | COUNT STOPKEY | | | | | |
| 3 | VIEW | | 40617 | 1546K| 80 (2)| 00:00:01 |
|* 4 | SORT ORDER BY STOPKEY| | 40617 | 2062K| 80 (2)| 00:00:01 |
| 5 | TABLE ACCESS FULL | T | 40617 | 2062K| 80 (2)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("RN">=1190)
2 - filter(ROWNUM<=1200)
4 - filter(ROWNUM<=1200)
Statistics
175 recursive calls
0 db block gets
388 consistent gets
0 physical reads
0 redo size
1063 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
4 sorts (memory)
0 sorts (disk)
11 rows processed
SQL> set autotrace off
SQL> spool offAs you will see, the join query here has to have an ORDER BY clause at the end to ensure that records are correctly sorted. You can not rely on optimizer choosing NESTED LOOP join method and, as above example shows, when optimizer chooses HASH JOIN, oracle is free to return rows in no particular order.
The query that does not involve join always returns rows in the desired order. Adding an ORDER BY does add a step in the plan for the query using join but does not affect the other query. -
Approach to tune a query in short time
Hi All,
Oracle 10g I know this question is asked number of times and there are many good replies to them.
But I just want to know how to approach a completely new query ( like the task given to me to fine tume a query in 1 day when I dont have even the slightest idea about how to proceed) if the timeline is very stringent and by just looking at the explain plan, you have to take the decision.
I am just posting my query here and what I am looking for is some lead on how to identify the congetion point which is where this query takes long time ( in my case some 15 mins as reported to me)
select
"LEGAL ENTITY",
"Legal Entity Description",
"Cluster",
"Sub_Cluster",
"Account",
rownum,
"Moody_Rating",
"Process_Date",
"Merge_Description",
rownum,
"Merge_Description",
"is_id_ic",
"is_n",
"cusip",
"isin",
"credit_spread_PV01",
"amount",
"Market_Value",
"Currency",
"Sensitivity_Type",
"maturity_Date",
"Exception_Flag",
"Base_Security_Id",
DECODE(sign("Market_Value"),-1,DeCode(SigN("Recovery"),-1,"Recovery",('-'||"Recovery")), ABS("Recovery")) as "Recovery"
from
select
le.name "LEGAL ENTITY",
le.display_name "Legal Entity Description",
mn4.display_name "Cluster",
mn3.display_name "Sub_Cluster",
bookname.display_name "Account",
(SELECT RATING_NAME
FROM moody_rating
where moody_rating_id = i.moody_rating_id) "Moody_Rating",
to_char(to_date(:v_cob_date,'DD-MM-YY'),'YYYYMMDD') "Process_Date",
ss.issuer "Merge_Description",
PART.MARS_ISSUER "is_id_ic",
PART.PARTICIPANT_NAME "is_n",
NULL "cusip",
NULL "isin",
NULL "credit_spread_PV01",
NULL "amount",
sum(mtmsens.sensitivity_value) "Market_Value",
(SELECT distinct cc.CCY
FROM legacy_country CC
INNER JOIN MARSNODE MN ON CC.countryisocode = MN.NAME
and mn.close_date is null
INNER JOIN MARSNODETYPE MNT ON MN.TYPE_ID =
MNT.NODE_TYPE_ID
AND MNT.NAME = 'COUNTRY'
and mnt.close_date is null
where MN.NODE_ID = part.country_domicile_id
and cc.begin_cob_date <= :v_cob_date
and cc.end_cob_date > :v_cob_date
and rownum < 2) "Currency",
'CREDITSPREADMARKETVALUE' "Sensitivity_Type",
NULL "maturity_Date",
NULL "Exception_Flag",
NULL "Base_Security_Id",
sum(ss.sensitivity_value) "Recovery"
from staging_position sp
left JOIN position p on (
p.feed_instance_id = sp.feed_instance_id
AND p.feed_row_id = sp.feed_row_id)
left JOIN staging_instrument si on (si.feed_instance_id =
sp.feed_instance_id AND
si.position_key =
sp.position_key)
left join book b on (b.book_id = p.book_id and
b.begin_cob_date <= :v_cob_date and
b.end_cob_date > :v_cob_date)
left join marsnode bk on (b.book_id = bk.node_id and
bk.close_date is null)
left join marsnode le on (b.leg_ent_id = le.node_id and
le.close_date is null)
left join marsnode bookname on (bookname.node_id = p.book_id and
bookname.close_date is null)
left join marsnodelink mnl on p.book_id = mnl.node_id
and :v_bus_org_hier_id =
mnl.hierarchy_id
and mnl.close_date is null
and :v_cob_date >= mnl.begin_cob_date
and :v_cob_date < mnl.end_cob_date
left join marsnode mn on mn.node_id = mnl.parent_id
and mn.close_date is null
left join marsnodelink mnl2 on mn.node_id = mnl2.node_id
and :v_bus_org_hier_id =
mnl2.hierarchy_id
and mnl2.close_date is null
and :v_cob_date >= mnl2.begin_cob_date
and :v_cob_date < mnl2.end_cob_date
left join marsnode mn2 on mn2.node_id = mnl2.parent_id
and mn2.close_date is null
left join marsnodelink mnl3 on mn2.node_id = mnl3.node_id
and :v_bus_org_hier_id =
mnl3.hierarchy_id
and mnl3.close_date is null
and :v_cob_date >= mnl3.begin_cob_date
and :v_cob_date < mnl3.end_cob_date
left join marsnode mn3 on mn3.node_id = mnl3.parent_id
and mn3.close_date is null
left join marsnodelink mnl4 on mn3.node_id = mnl4.node_id
and :v_bus_org_hier_id =
mnl4.hierarchy_id
and mnl4.close_date is null
and :v_cob_date >= mnl4.begin_cob_date
and :v_cob_date < mnl4.end_cob_date
left join marsnode mn4 on mn4.node_id = mnl4.parent_id
and mn4.close_date is null
--sensitivity data
left JOIN STAGING_SENSITIVITY ss ON (ss.FEED_INSTANCE_ID =
sp.FEED_INSTANCE_ID AND
ss.FEED_ROW_ID =
sp.FEED_ROW_ID)
--sensitivity data
left JOIN STAGING_SENSITIVITY mtmsens ON (mtmsens.FEED_INSTANCE_ID =
sp.FEED_INSTANCE_ID AND
mtmsens.FEED_ROW_ID =
sp.FEED_ROW_ID)
LEFT join xref_domain_value_map XREF on (XREF.Src_Value =
ss.issuer and
XREF.close_action_id is null and
XREF.Begin_Cob_Date <=
:v_cob_date and
XREF.End_Cob_Date >
:v_cob_date AND
xref.domain_map_id = 601 AND
xref.source_system_id = 307 AND xref.ISSUE_ID is not null)
Left join ISSUE i on (i.issue_id = xref.issue_id)
LEFT join participant PART ON (PART.PARTICIPANT_ID =
XREF.TGT_VALUE and
PART.Close_Action_Id is null and
PART.Begin_Cob_Date <= :v_cob_date and
PART.End_Cob_Date > :v_cob_date)
left join moody_rating RATING on (rating.moody_rating_id =
i.MOODY_RATING_ID)
where sp.feed_instance_id in
(select fbi.feed_instance_id
from feed_book_status fbi ,
feed_instance fi
where fbi.cob_date = :v_cob_date
and fbi.feed_instance_id = fi.feed_instance_id
and fi.feed_id in (
select feed_id from feed_group_xref where feed_group_id in (
select feed_group_id from feed_group where description like 'CDO Feeds')
and close_action_id is null
and sp.Feed_Row_Status_Id = 1
and ss.sensitivity_type = 'CREDITSPREADDEFAULT'
and mtmsens.sensitivity_type = 'MTMVALUE'
and le.name='161'
group by le.name,
le.display_name,
mn3.display_name,
mn4.display_name,
mn.display_name,
i.moody_rating_id,
ss.issuer,
PART.MARS_ISSUER,
PART.PARTICIPANT_NAME,
sp.feed_instance_id,
part.country_domicile_id,
bookname.display_name) And the explain plan
SELECT STATEMENT, GOAL = CHOOSE Cost=19365 Cardinality=1 Bytes=731
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MOODY_RATING Cost=1 Cardinality=1 Bytes=9
INDEX UNIQUE SCAN Object owner=MARS Object name=PK_MOODY_RATING Cost=0 Cardinality=1
HASH UNIQUE Cost=77 Cardinality=1 Bytes=488
COUNT STOPKEY
HASH JOIN Cost=76 Cardinality=1 Bytes=488
NESTED LOOPS Cost=68 Cardinality=1 Bytes=460
HASH JOIN Cost=66 Cardinality=1 Bytes=450
HASH JOIN Cost=59 Cardinality=1 Bytes=412
NESTED LOOPS Cost=51 Cardinality=1 Bytes=402
HASH JOIN Cost=49 Cardinality=1 Bytes=392
NESTED LOOPS Cost=42 Cardinality=1 Bytes=359
NESTED LOOPS Cost=40 Cardinality=1 Bytes=349
NESTED LOOPS Cost=37 Cardinality=1 Bytes=300
NESTED LOOPS Cost=34 Cardinality=1 Bytes=251
HASH JOIN Cost=32 Cardinality=1 Bytes=241
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODE Cost=3 Cardinality=1 Bytes=27
NESTED LOOPS Cost=24 Cardinality=1 Bytes=231
NESTED LOOPS Cost=21 Cardinality=1 Bytes=204
NESTED LOOPS Cost=18 Cardinality=1 Bytes=171
NESTED LOOPS Cost=16 Cardinality=1 Bytes=136
NESTED LOOPS Cost=13 Cardinality=1 Bytes=86
NESTED LOOPS Cost=10 Cardinality=1 Bytes=37
VIEW Object owner=MARS Cost=7 Cardinality=1 Bytes=10
FILTER
CONNECT BY WITH FILTERING
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODELINK
INDEX RANGE SCAN Object owner=MARS Object name=FKI_15632_PARENT_ID Cost=3 Cardinality=250 Bytes=2500
HASH JOIN Cost=5 Cardinality=1 Bytes=62
TABLE ACCESS FULL Object owner=MARS Object name=MARSHIERARCHY Cost=2 Cardinality=1 Bytes=27
TABLE ACCESS FULL Object owner=MARS Object name=MARSHIERARCHYROOT Cost=2 Cardinality=5 Bytes=175
NESTED LOOPS
CONNECT BY PUMP
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODELINK Cost=7 Cardinality=1 Bytes=39
INDEX RANGE SCAN Object owner=MARS Object name=IDX_MNL_HI_PI_NI Cost=3 Cardinality=4
TABLE ACCESS FULL Object owner=MARS Object name=MARSHIERARCHY Cost=2 Cardinality=1 Bytes=27
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODE Cost=3 Cardinality=1 Bytes=27
INDEX RANGE SCAN Object owner=MARS Object name=PK_MARSNODE Cost=2 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODE Cost=3 Cardinality=1 Bytes=49
INDEX RANGE SCAN Object owner=MARS Object name=PK_MARSNODE Cost=2 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODE Cost=3 Cardinality=1 Bytes=50
INDEX RANGE SCAN Object owner=MARS Object name=PK_MARSNODE Cost=2 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODETYPE Cost=2 Cardinality=1 Bytes=35
INDEX RANGE SCAN Object owner=MARS Object name=PK_MARSNODETYPE Cost=1 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=NODE_ASSOC Cost=3 Cardinality=1 Bytes=33
INDEX RANGE SCAN Object owner=MARS Object name=PK_NODE_ASSOC Cost=1 Cardinality=3
INDEX RANGE SCAN Object owner=MARS Object name=PK_MARSNODE Cost=2 Cardinality=1
VIEW Object owner=MARS Cost=7 Cardinality=1 Bytes=10
FILTER
CONNECT BY WITH FILTERING
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODELINK
INDEX RANGE SCAN Object owner=MARS Object name=FKI_15632_PARENT_ID Cost=3 Cardinality=250 Bytes=2500
HASH JOIN Cost=5 Cardinality=1 Bytes=62
TABLE ACCESS FULL Object owner=MARS Object name=MARSHIERARCHY Cost=2 Cardinality=1 Bytes=27
TABLE ACCESS FULL Object owner=MARS Object name=MARSHIERARCHYROOT Cost=2 Cardinality=5 Bytes=175
NESTED LOOPS
CONNECT BY PUMP
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODELINK Cost=7 Cardinality=1 Bytes=39
INDEX RANGE SCAN Object owner=MARS Object name=IDX_MNL_HI_PI_NI Cost=3 Cardinality=4
TABLE ACCESS FULL Object owner=MARS Object name=MARSHIERARCHY Cost=2 Cardinality=1 Bytes=27
INDEX RANGE SCAN Object owner=MARS Object name=PK_MARSNODE Cost=2 Cardinality=1 Bytes=10
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=NODE_ASSOC Cost=3 Cardinality=1 Bytes=49
INDEX RANGE SCAN Object owner=MARS Object name=PK_NODE_ASSOC Cost=1 Cardinality=3
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODE Cost=3 Cardinality=1 Bytes=49
INDEX RANGE SCAN Object owner=MARS Object name=PK_MARSNODE Cost=2 Cardinality=1
INDEX RANGE SCAN Object owner=MARS Object name=PK_MARSNODE Cost=2 Cardinality=1 Bytes=10
VIEW Object owner=MARS Cost=7 Cardinality=1 Bytes=33
FILTER
CONNECT BY WITH FILTERING
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODELINK
INDEX RANGE SCAN Object owner=MARS Object name=FKI_15632_PARENT_ID Cost=3 Cardinality=250 Bytes=2500
HASH JOIN Cost=5 Cardinality=1 Bytes=62
TABLE ACCESS FULL Object owner=MARS Object name=MARSHIERARCHY Cost=2 Cardinality=1 Bytes=27
TABLE ACCESS FULL Object owner=MARS Object name=MARSHIERARCHYROOT Cost=2 Cardinality=5 Bytes=175
NESTED LOOPS
CONNECT BY PUMP
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODELINK Cost=7 Cardinality=1 Bytes=39
INDEX RANGE SCAN Object owner=MARS Object name=IDX_MNL_HI_PI_NI Cost=3 Cardinality=4
TABLE ACCESS FULL Object owner=MARS Object name=MARSHIERARCHY Cost=2 Cardinality=1 Bytes=27
INDEX RANGE SCAN Object owner=MARS Object name=PK_MARSNODE Cost=2 Cardinality=1 Bytes=10
VIEW Object owner=MARS Cost=7 Cardinality=1 Bytes=10
FILTER
CONNECT BY WITH FILTERING
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODELINK
INDEX RANGE SCAN Object owner=MARS Object name=FKI_15632_PARENT_ID Cost=3 Cardinality=250 Bytes=2500
HASH JOIN Cost=5 Cardinality=1 Bytes=62
TABLE ACCESS FULL Object owner=MARS Object name=MARSHIERARCHY Cost=2 Cardinality=1 Bytes=27
TABLE ACCESS FULL Object owner=MARS Object name=MARSHIERARCHYROOT Cost=2 Cardinality=5 Bytes=175
NESTED LOOPS
CONNECT BY PUMP
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODELINK Cost=7 Cardinality=1 Bytes=39
INDEX RANGE SCAN Object owner=MARS Object name=IDX_MNL_HI_PI_NI Cost=3 Cardinality=4
TABLE ACCESS FULL Object owner=MARS Object name=MARSHIERARCHY Cost=2 Cardinality=1 Bytes=27
VIEW Object owner=MARS Cost=7 Cardinality=1 Bytes=38
FILTER
CONNECT BY WITH FILTERING
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODELINK
INDEX RANGE SCAN Object owner=MARS Object name=FKI_15632_PARENT_ID Cost=3 Cardinality=250 Bytes=2500
HASH JOIN Cost=5 Cardinality=1 Bytes=62
TABLE ACCESS FULL Object owner=MARS Object name=MARSHIERARCHY Cost=2 Cardinality=1 Bytes=27
TABLE ACCESS FULL Object owner=MARS Object name=MARSHIERARCHYROOT Cost=2 Cardinality=5 Bytes=175
NESTED LOOPS
CONNECT BY PUMP
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODELINK Cost=7 Cardinality=1 Bytes=57
INDEX RANGE SCAN Object owner=MARS Object name=IDX_MNL_HI_PI_NI Cost=3 Cardinality=4
TABLE ACCESS FULL Object owner=MARS Object name=MARSHIERARCHY Cost=2 Cardinality=1 Bytes=36
INDEX RANGE SCAN Object owner=MARS Object name=PK_MARSNODE Cost=2 Cardinality=1 Bytes=10
VIEW Object owner=MARS Cost=7 Cardinality=1 Bytes=28
FILTER
CONNECT BY WITH FILTERING
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODELINK
INDEX RANGE SCAN Object owner=MARS Object name=FKI_15632_PARENT_ID Cost=3 Cardinality=250 Bytes=2500
HASH JOIN Cost=5 Cardinality=1 Bytes=62
TABLE ACCESS FULL Object owner=MARS Object name=MARSHIERARCHY Cost=2 Cardinality=1 Bytes=27
TABLE ACCESS FULL Object owner=MARS Object name=MARSHIERARCHYROOT Cost=2 Cardinality=5 Bytes=175
NESTED LOOPS
CONNECT BY PUMP
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODELINK Cost=7 Cardinality=1 Bytes=57
INDEX RANGE SCAN Object owner=MARS Object name=IDX_MNL_HI_PI_NI Cost=3 Cardinality=4
TABLE ACCESS FULL Object owner=MARS Object name=MARSHIERARCHY Cost=2 Cardinality=1 Bytes=27
COUNT
VIEW Object owner=MARS Cost=19365 Cardinality=1 Bytes=731
HASH GROUP BY Cost=19365 Cardinality=1 Bytes=1112
NESTED LOOPS OUTER Cost=19364 Cardinality=1 Bytes=1112
NESTED LOOPS OUTER Cost=19361 Cardinality=1 Bytes=1040
NESTED LOOPS OUTER Cost=19361 Cardinality=1 Bytes=1037
NESTED LOOPS OUTER Cost=19360 Cardinality=1 Bytes=1019
NESTED LOOPS OUTER Cost=19357 Cardinality=1 Bytes=951
NESTED LOOPS OUTER Cost=19354 Cardinality=1 Bytes=914
NESTED LOOPS OUTER Cost=19351 Cardinality=1 Bytes=877
NESTED LOOPS OUTER Cost=19337 Cardinality=1 Bytes=820
NESTED LOOPS OUTER Cost=19334 Cardinality=1 Bytes=783
NESTED LOOPS OUTER Cost=19320 Cardinality=1 Bytes=726
NESTED LOOPS OUTER Cost=19317 Cardinality=1 Bytes=707
NESTED LOOPS OUTER Cost=19303 Cardinality=1 Bytes=650
NESTED LOOPS OUTER Cost=19300 Cardinality=1 Bytes=613
NESTED LOOPS Cost=19285 Cardinality=1 Bytes=556
NESTED LOOPS Cost=19280 Cardinality=1 Bytes=443
NESTED LOOPS OUTER Cost=19275 Cardinality=1 Bytes=330
HASH JOIN RIGHT SEMI Cost=17457 Cardinality=1 Bytes=248
VIEW Object owner=SYS Object name=VW_NSO_1 Cost=1119 Cardinality=30 Bytes=150
HASH JOIN Cost=1119 Cardinality=30 Bytes=2040
TABLE ACCESS FULL Object owner=MARS Object name=FEED_GROUP Cost=2 Cardinality=5 Bytes=120
HASH JOIN Cost=1116 Cardinality=1607 Bytes=70708
TABLE ACCESS FULL Object owner=MARS Object name=FEED_GROUP_XREF Cost=13 Cardinality=701 Bytes=14721
HASH JOIN Cost=1102 Cardinality=3602 Bytes=82846
INDEX RANGE SCAN Object owner=MARS Object name=IDX_FBS_CD_FII_BI Cost=22 Cardinality=3602 Bytes=46826
TABLE ACCESS FULL Object owner=MARS Object name=FEED_INSTANCE Cost=1024 Cardinality=670264 Bytes=6702640
NESTED LOOPS Cost=16337 Cardinality=324 Bytes=78732
HASH JOIN Cost=14324 Cardinality=1977 Bytes=302481
NESTED LOOPS OUTER Cost=11 Cardinality=1 Bytes=114
NESTED LOOPS Cost=8 Cardinality=1 Bytes=95
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODE Cost=5 Cardinality=1 Bytes=59
INDEX RANGE SCAN Object owner=MARS Object name=IDX_NODE1 Cost=3 Cardinality=2
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=BOOK Cost=3 Cardinality=2 Bytes=72
INDEX RANGE SCAN Object owner=MARS Object name=IDX_BOOK_LEI_BCD Cost=2 Cardinality=4
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODE Cost=3 Cardinality=1 Bytes=19
INDEX RANGE SCAN Object owner=MARS Object name=PK_MARSNODE Cost=2 Cardinality=1
PARTITION RANGE ALL Cost=13995 Cardinality=3854299 Bytes=150317661
TABLE ACCESS FULL Object owner=MARS Object name=POSITION Cost=13995 Cardinality=3854299 Bytes=150317661
PARTITION RANGE ITERATOR Cost=2 Cardinality=1 Bytes=90
PARTITION HASH ITERATOR Cost=2 Cardinality=1 Bytes=90
TABLE ACCESS BY LOCAL INDEX ROWID Object owner=MARS Object name=STAGING_POSITION Cost=2 Cardinality=1 Bytes=90
INDEX UNIQUE SCAN Object owner=MARS Object name=PK_STAGINGPOSITON Cost=1 Cardinality=1
PARTITION HASH ITERATOR Cost=1819 Cardinality=1 Bytes=82
TABLE ACCESS BY LOCAL INDEX ROWID Object owner=MARS Object name=STAGING_INSTRUMENT Cost=1819 Cardinality=1 Bytes=82
INDEX RANGE SCAN Object owner=MARS Object name=PK_STAGINGINSTRUMENT Cost=9 Cardinality=2551
PARTITION RANGE ITERATOR Cost=5 Cardinality=1 Bytes=113
PARTITION HASH ITERATOR Cost=5 Cardinality=1 Bytes=113
TABLE ACCESS BY LOCAL INDEX ROWID Object owner=MARS Object name=STAGING_SENSITIVITY Cost=5 Cardinality=1 Bytes=113
INDEX RANGE SCAN Object owner=MARS Object name=IDX_SENSITIVITY_FEED_ROW_ID Cost=3 Cardinality=8
PARTITION RANGE ITERATOR Cost=5 Cardinality=1 Bytes=113
PARTITION HASH ITERATOR Cost=5 Cardinality=1 Bytes=113
TABLE ACCESS BY LOCAL INDEX ROWID Object owner=MARS Object name=STAGING_SENSITIVITY Cost=5 Cardinality=1 Bytes=113
INDEX RANGE SCAN Object owner=MARS Object name=IDX_SENSITIVITY_FEED_ROW_ID Cost=3 Cardinality=8
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODELINK Cost=14 Cardinality=1 Bytes=57
INDEX RANGE SCAN Object owner=MARS Object name=FKI_15632_NODE_ID Cost=2 Cardinality=14
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODE Cost=3 Cardinality=1 Bytes=37
INDEX RANGE SCAN Object owner=MARS Object name=PK_MARSNODE Cost=2 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODELINK Cost=14 Cardinality=1 Bytes=57
INDEX RANGE SCAN Object owner=MARS Object name=FKI_15632_NODE_ID Cost=2 Cardinality=14
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODE Cost=3 Cardinality=1 Bytes=19
INDEX RANGE SCAN Object owner=MARS Object name=PK_MARSNODE Cost=2 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODELINK Cost=14 Cardinality=1 Bytes=57
INDEX RANGE SCAN Object owner=MARS Object name=FKI_15632_NODE_ID Cost=2 Cardinality=14
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODE Cost=3 Cardinality=1 Bytes=37
INDEX RANGE SCAN Object owner=MARS Object name=PK_MARSNODE Cost=2 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODELINK Cost=14 Cardinality=1 Bytes=57
INDEX RANGE SCAN Object owner=MARS Object name=FKI_15632_NODE_ID Cost=2 Cardinality=14
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODE Cost=3 Cardinality=1 Bytes=37
INDEX RANGE SCAN Object owner=MARS Object name=PK_MARSNODE Cost=2 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=MARSNODE Cost=3 Cardinality=1 Bytes=37
INDEX RANGE SCAN Object owner=MARS Object name=PK_MARSNODE Cost=2 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=XREF_DOMAIN_VALUE_MAP Cost=3 Cardinality=1 Bytes=68
INDEX RANGE SCAN Object owner=MARS Object name=IDX_XDVM_DMI_SV_BCD Cost=2 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=ISSUE Cost=1 Cardinality=1 Bytes=18
INDEX UNIQUE SCAN Object owner=MARS Object name=PK_ISSUE Cost=0 Cardinality=1
INDEX UNIQUE SCAN Object owner=MARS Object name=PK_MOODY_RATING Cost=0 Cardinality=1 Bytes=3
TABLE ACCESS BY INDEX ROWID Object owner=MARS Object name=PARTICIPANT Cost=3 Cardinality=1 Bytes=72
INDEX RANGE SCAN Object owner=MARS Object name=PK_PARTICIPANT Cost=2 Cardinality=1Hi,
in your explain plan:
HASH JOIN RIGHT SEMI Cost=17457 Cardinality=1 Bytes=248
VIEW Object owner=SYS Object name=VW_NSO_1 Cost=1119 Cardinality=30 Bytes=150
HASH JOIN Cost=1119 Cardinality=30 Bytes=2040
TABLE ACCESS FULL Object owner=MARS Object name=FEED_GROUP Cost=2 Cardinality=5 Bytes=120
HASH JOIN Cost=1116 Cardinality=1607 Bytes=70708
TABLE ACCESS FULL Object owner=MARS Object name=FEED_GROUP_XREF Cost=13 Cardinality=701 Bytes=14721
HASH JOIN Cost=1102 Cardinality=3602 Bytes=82846
INDEX RANGE SCAN Object owner=MARS Object name=IDX_FBS_CD_FII_BI Cost=22 Cardinality=3602 Bytes=46826
TABLE ACCESS FULL Object owner=MARS Object name=FEED_INSTANCEThis part has the highest costs (this doesn't always mean it is slow). So this leads me to the WHERE clause where feed_group, feed_group_xref and feed_instance full are used. Maybe this can be improved, although the cardinality is not that high, so a full table can be the best. So the question is can indexes help here?
Furthermore there is the full table scan on POSITION:
TABLE ACCESS FULL Object owner=MARS Object name=POSITION Cost=13995 Cardinality=3854299 Bytes=150317661This looks also a large tabel (3 million + records), so is it possible to get this part smaller?
Herald ten Dam
http://htendam.wordpress.com -
Stopping a Query taking more time to execute in runtime in Oracle Forms.
Hi,
In the present application one of the oracle form screen is taking long time to execute a query, user wanted an option to stop the query in between and browse the result (whatever has been fetched before stopping the query).
We have tried three approach.
1. set max fetch record in form and block level.
2. set max fetch time in form and block level.
in above two method does not provide the appropiate solution for us.
3. the third approach we applied is setting the interaction mode to "NON BLOCKING" at the form level.
It seems to be worked, while the query took long time to execute, oracle app server prompts an message to press Esc to cancel the query and it a displaying the results fetched upto that point.
But the drawback is one pressing esc, its killing the session itself. which is causing the entire application to collapse.
Please suggest if there is any alternative approach for this or how to overcome this perticular scenario.
This kind of facility is alreday present in TOAD and PL/SQL developer where we can stop an executing query and browse the results fetched upto that point, is the similar facility is avialable in oracle forms ,please suggest.
Thanks and Regards,
Suraj
Edited by: user10673131 on Jun 25, 2009 4:55 AMHello Friend,
You query will definitely take more time or even fail in PROD,becuase the way it is written. Here are my few observations, may be it can help :-
1. XLA_AR_INV_AEL_SL_V XLA_AEL_SL_V : Never use a view inside such a long query , becuase View is just a window to the records.
and when used to join other table records, then all those tables which are used to create a view also becomes part of joining conition.
First of all please check if you really need this view. I guess you are using to check if the records have been created as Journal entries or not ?
Please check the possbility of finding it through other AR tables.
2. Remove _ALL tables instead use the corresponding org specific views (if you are in 11i ) or the sysnonymns ( in R12 )
For example : For ra_cust_trx_types_all use ra_cust_trx_types.
This will ensure that the query will execute only for those ORG_IDs which are assigned to that responsibility.
3. Check with the DBA whether the GATHER SCHEMA STATS have been run atleast for ONT and RA tables.
You can also check the same using
SELECT LAST_ANALYZED FROM ALL_TABLES WHERE TABLE_NAME = 'ra_customer_trx_all'.
If the tables are not analyzed , the CBO will not be able to tune your query.
4. Try to remove the DISTINCT keyword. This is the MAJOR reason for this problem.
5. If its a report , try to separate the logic in separate queries ( using a procedure ) and then populate the whole data in custom table, and use this custom table for generating the
report.
Thanks,
Neeraj Shrivastava
[email protected]
Edited by: user9352949 on Oct 1, 2010 8:02 PM
Edited by: user9352949 on Oct 1, 2010 8:03 PM -
Linked Server - Getting Error when performing Cross Instance Query with joins
Hi Guys,
I've successfully created a Linked Server that connects a local DB Engine with another DB Engine through an ip over an extranet. I am able to run simple Select statement queries on the Local DB
Engine and get results from the linked server. However when attempting to perform more complex queries that join tables from
the linked server with tables from the local DB server, I get the following error message after several minutes of execution:
OLE DB provider "SQLNCLI11" for linked server "<ip of Linked Server>" returned message "Protocol error in TDS stream".
OLE DB provider "SQLNCLI11" for linked server "<ip of Linked Server>"
returned message "Communication link failure".
Msg -1, Level 16, State 1, Line 0
Session Provider: Physical connection is not usable [xFFFFFFFF].
OLE DB provider "SQLNCLI11" for linked server "<ip of Linked Server>"
returned message "Communication link failure".
Msg -1, Level 16, State 1, Line 0
Session Provider: Physical connection is not usable [xFFFFFFFF].
OLE DB provider "SQLNCLI11" for linked server "<ip of Linked Server>"
returned message "Communication link failure".
Msg 10054, Level 16, State 1, Line 0
TCP Provider: An existing connection was forcibly closed by the remote host.
Grateful if you could advise what may be causing this issue and how I can resolve it. I've read on Distributed Transactions but I understand that it only applies to manipulation statements?
Both are SQL servers. Linked Server is SQL2008R2 if not mistaken. Local DB Engine is SQL2014.
Thanks and Regards,
Rhyan.Thank you for your insight Erland. Can you advise how I can check the SQL Server errorlog pls?
I just got word from a user that the query ran successfully this morning but took 15 mins to complete.. does it ring a bell to you in terms of issues that may be causing this?
This kind of behaviour would suggest something makes the query "time out" or stop abruptly.. How can I further investigate it pls? Can a BEGIN DISTRIBUTED TRANSACTION statement in the query help me mitigate or resolve the error? ref: https://msdn.microsoft.com/en-us/library/ms188386.aspx?f=255&MSPPError=-2147217396
SQL Version for Remote Server is :
Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64) Oct 19 2012 13:38:57 Copyright
(c) Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.2 <X64> (Build 9200: ) (Hypervisor)
SQL Version for Local Server is:
Microsoft SQL Server 2014 - 12.0.2000.8 (X64) Feb 20 2014 20:04:26 Copyright
(c) Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: ) (Hypervisor)
Thanks and Regards,
Rhyan -
Select query running long time
Hi,
DB version : 10g
platform : sunos
My select sql query running long time (more than 20hrs) .Still running .
Is there any way to find sql query completion time approximately. (Pending time)
Also is there any possibilities to increase the speed of sql query (already running) like adding hints.
Please help me on this .
ThanksHi Sathish thanks for your reply,
I have already checked in V$SESSION_LONGOPS .But it's showing TIME_REMAINING -->0
select TOTALWORK,SOFAR,START_TIME,TIME_REMAINING from V$SESSION_LONGOPS where SID='10'
TOTALWORK SOFAR START_TIME TIME_REMAINING
1099759 1099759 27-JAN-11 0Any idea ?
Thanks. -
Hi All,
I have cloned KSB1 tcode to custom one as required by business.
Below query takes more time than excepted.
Here V_DB_TABLE = COVP.
Values in Where clause are as follows
OBNJR in ( KSBB010000001224 BT KSBB012157221571)
GJAHR in blank
VERSN in '000'
WRTTP in '04' and '11'
all others are blank
VT_VAR_COND = ( CPUDT BETWEEN '20091201' and '20091208' )
SELECT (VT_FIELDS) INTO CORRESPONDING FIELDS OF GS_COVP_EXT
FROM (V_DB_TABLE)
WHERE LEDNR = '00'
AND OBJNR IN LR_OBJNR
AND GJAHR IN GR_GJAHR
AND VERSN IN GR_VERSN
AND WRTTP IN GR_WRTTP
AND KSTAR IN LR_KSTAR
AND PERIO IN GR_PERIO
AND BUDAT IN GR_BUDAT
AND PAROB IN GR_PAROB
AND (VT_VAR_COND).
Checked in table for this condition it has only 92 entries.
But when i execute program takes long time as 3 Hrs.
Could any one help me on this>1.Dont use SELECT/ENDSELECT instead use INTO TABLE addition .
> 2.Avoid using corresponding addition.create a type and reference it.
> If the select is going for dump beacause of storage limitations ,then use Cursors.
you got three large NOs .... all three recommendations are wrong!
The SE16 test is going in the right direction ... but what was filled. Nobody knows!!!!
Select options:
Did you ever try to trace the SE16? The generic statement has for every field an in-condition!
Without the information what was actually filled, nobody can say something there
are at least 2**n combinations possible!
Use ST05 for SE16 and check actual statement plus explain! -
Query taking long time for EXTRACTING the data more than 24 hours
Hi ,
Query taking long time for EXTRACTING the data more than 24 hours please find the query and explain plan details below even indexes avilable on table's goe's to FULL TABLE SCAN. please suggest me.......
SQL> explain plan for select a.account_id,round(a.account_balance,2) account_balance,
2 nvl(ah.invoice_id,ah.adjustment_id) transaction_id,
to_char(ah.effective_start_date,'DD-MON-YYYY') transaction_date,
to_char(nvl(i.payment_due_date,
to_date('30-12-9999','dd-mm-yyyy')),'DD-MON-YYYY')
due_date, ah.current_balance-ah.previous_balance amount,
decode(ah.invoice_id,null,'A','I') transaction_type
3 4 5 6 7 8 from account a,account_history ah,invoice i_+
where a.account_id=ah.account_id
and a.account_type_id=1000002
and round(a.account_balance,2) > 0
and (ah.invoice_id is not null or ah.adjustment_id is not null)
and ah.CURRENT_BALANCE > ah.previous_balance
and ah.invoice_id=i.invoice_id(+)
AND a.account_balance > 0
order by a.account_id,ah.effective_start_date desc; 9 10 11 12 13 14 15 16
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)|
| 0 | SELECT STATEMENT | | 544K| 30M| | 693K (20)|
| 1 | SORT ORDER BY | | 544K| 30M| 75M| 693K (20)|
|* 2 | HASH JOIN | | 544K| 30M| | 689K (20)|
|* 3 | TABLE ACCESS FULL | ACCOUNT | 20080 | 294K| | 6220 (18)|
|* 4 | HASH JOIN OUTER | | 131M| 5532M| 5155M| 678K (20)|
|* 5 | TABLE ACCESS FULL| ACCOUNT_HISTORY | 131M| 3646M| | 197K (25)|
| 6 | TABLE ACCESS FULL| INVOICE | 262M| 3758M| | 306K (18)|
Predicate Information (identified by operation id):
2 - access("A"."ACCOUNT_ID"="AH"."ACCOUNT_ID")
3 - filter("A"."ACCOUNT_TYPE_ID"=1000002 AND "A"."ACCOUNT_BALANCE">0 AND
ROUND("A"."ACCOUNT_BALANCE",2)>0)
4 - access("AH"."INVOICE_ID"="I"."INVOICE_ID"(+))
5 - filter("AH"."CURRENT_BALANCE">"AH"."PREVIOUS_BALANCE" AND ("AH"."INVOICE_ID"
IS NOT NULL OR "AH"."ADJUSTMENT_ID" IS NOT NULL))
22 rows selected.
Index Details:+_
SQL> select INDEX_OWNER,INDEX_NAME,COLUMN_NAME,TABLE_NAME from dba_ind_columns where
2 table_name in ('INVOICE','ACCOUNT','ACCOUNT_HISTORY') order by 4;
INDEX_OWNER INDEX_NAME COLUMN_NAME TABLE_NAME
OPS$SVM_SRV4 P_ACCOUNT ACCOUNT_ID ACCOUNT
OPS$SVM_SRV4 U_ACCOUNT_NAME ACCOUNT_NAME ACCOUNT
OPS$SVM_SRV4 U_ACCOUNT CUSTOMER_NODE_ID ACCOUNT
OPS$SVM_SRV4 U_ACCOUNT ACCOUNT_TYPE_ID ACCOUNT
OPS$SVM_SRV4 I_ACCOUNT_ACCOUNT_TYPE ACCOUNT_TYPE_ID ACCOUNT
OPS$SVM_SRV4 I_ACCOUNT_INVOICE INVOICE_ID ACCOUNT
OPS$SVM_SRV4 I_ACCOUNT_PREVIOUS_INVOICE PREVIOUS_INVOICE_ID ACCOUNT
OPS$SVM_SRV4 U_ACCOUNT_NAME_ID ACCOUNT_NAME ACCOUNT
OPS$SVM_SRV4 U_ACCOUNT_NAME_ID ACCOUNT_ID ACCOUNT
OPS$SVM_SRV4 I_LAST_MODIFIED_ACCOUNT LAST_MODIFIED ACCOUNT
OPS$SVM_SRV4 I_ACCOUNT_INVOICE_ACCOUNT INVOICE_ACCOUNT_ID ACCOUNT
OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ACCOUNT ACCOUNT_ID ACCOUNT_HISTORY
OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ACCOUNT SEQNR ACCOUNT_HISTORY
OPS$SVM_SRV4 I_ACCOUNT_HISTORY_INVOICE INVOICE_ID ACCOUNT_HISTORY
OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ADINV INVOICE_ID ACCOUNT_HISTORY
OPS$SVM_SRV4 I_ACCOUNT_HISTORY_CIA CURRENT_BALANCE ACCOUNT_HISTORY
OPS$SVM_SRV4 I_ACCOUNT_HISTORY_CIA INVOICE_ID ACCOUNT_HISTORY
OPS$SVM_SRV4 I_ACCOUNT_HISTORY_CIA ADJUSTMENT_ID ACCOUNT_HISTORY
OPS$SVM_SRV4 I_ACCOUNT_HISTORY_CIA ACCOUNT_ID ACCOUNT_HISTORY
OPS$SVM_SRV4 I_ACCOUNT_HISTORY_LMOD LAST_MODIFIED ACCOUNT_HISTORY
OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ADINV ADJUSTMENT_ID ACCOUNT_HISTORY
OPS$SVM_SRV4 I_ACCOUNT_HISTORY_PAYMENT PAYMENT_ID ACCOUNT_HISTORY
OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ADJUSTMENT ADJUSTMENT_ID ACCOUNT_HISTORY
OPS$SVM_SRV4 I_ACCOUNT_HISTORY_APPLIED_DT APPLIED_DATE ACCOUNT_HISTORY
OPS$SVM_SRV4 P_INVOICE INVOICE_ID INVOICE
OPS$SVM_SRV4 U_INVOICE CUSTOMER_INVOICE_STR INVOICE
OPS$SVM_SRV4 I_LAST_MODIFIED_INVOICE LAST_MODIFIED INVOICE
OPS$SVM_SRV4 U_INVOICE_ACCOUNT ACCOUNT_ID INVOICE
OPS$SVM_SRV4 U_INVOICE_ACCOUNT BILL_RUN_ID INVOICE
OPS$SVM_SRV4 I_INVOICE_BILL_RUN BILL_RUN_ID INVOICE
OPS$SVM_SRV4 I_INVOICE_INVOICE_TYPE INVOICE_TYPE_ID INVOICE
OPS$SVM_SRV4 I_INVOICE_CUSTOMER_NODE CUSTOMER_NODE_ID INVOICE
32 rows selected.
Regards,
Bathula
Oracle-DBAI have some suggestions. But first, you realize that you have some redundant indexes, right? You have an index on account(account_name) and also account(account_name, account_id), and also account_history(invoice_id) and account_history(invoice_id, adjustment_id). No matter, I will suggest some new composite indexes.
Also, you do not need two lines for these conditions:
and round(a.account_balance, 2) > 0
AND a.account_balance > 0
You can just use: and a.account_balance >= 0.005
So the formatted query isselect a.account_id,
round(a.account_balance, 2) account_balance,
nvl(ah.invoice_id, ah.adjustment_id) transaction_id,
to_char(ah.effective_start_date, 'DD-MON-YYYY') transaction_date,
to_char(nvl(i.payment_due_date, to_date('30-12-9999', 'dd-mm-yyyy')),
'DD-MON-YYYY') due_date,
ah.current_balance - ah.previous_balance amount,
decode(ah.invoice_id, null, 'A', 'I') transaction_type
from account a, account_history ah, invoice i
where a.account_id = ah.account_id
and a.account_type_id = 1000002
and (ah.invoice_id is not null or ah.adjustment_id is not null)
and ah.CURRENT_BALANCE > ah.previous_balance
and ah.invoice_id = i.invoice_id(+)
AND a.account_balance >= .005
order by a.account_id, ah.effective_start_date desc;You will probably want to select:
1. From ACCOUNT first (your smaller table), for which you supply a literal on account_type_id. That should limit the accounts retrieved from ACCOUNT_HISTORY
2. From ACCOUNT_HISTORY. We want to limit the records as much as possible on this table because of the outer join.
3. INVOICE we want to access last because it seems to be least restricted, it is the biggest, and it has the outer join condition so it will manufacture rows to match as many rows as come back from account_history.
Try the query above after creating the following composite indexes. The order of the columns is important:create index account_composite_i on account(account_type_id, account_balance, account_id);
create index acct_history_comp_i on account_history(account_id, invoice_id, adjustment_id, current_balance, previous_balance, effective_start_date);
create index invoice_composite_i on invoice(invoice_id, payment_due_date);All the columns used in the where clause will be indexed, in a logical order suited to the needs of the query. Plus each selected column is indexed as well so that we should not need to touch the tables at all to satisfy the query.
Try the query after creating these indexes.
A final suggestion is to try larger sort and hash area sizes and a manual workarea policy.alter session set workarea_size_policy = manual;
alter session set sort_area_size = 2147483647;
alter session set hash_area_size = 2147483647; -
How to build a query to join on two tables without mapping
I did Automatic mapping by the workbench Directofield mapping with the table and java object.
Wanted to build a simple join query by joining on the same field on both the tables.Not the sql query through the toplink using expression builder.
Please help.............
Spent one full day for this................Thanks Don for the reply,sorry to bug you,but i need help.....
SELECT A.AGNCY_C,
A.TYPE_C,
A.RESN_C,
A.S_TYPE_C,
A.SUB_ID_C,
A.RY_C
FROM RATING A, REF B
WHERE A.ID_C = B._ID_C
AND A.ALPHA_C = B.ALPHA_C
AND A.EFF_D >= B.MATURITY_D
This is the real query i was talking about.I did mapping automatically through the workbench,generated java classes also throught the workbench.
Now they don't want to execute the raw sql.They wanted to get all the RATING objects with the where condition.
So how to build a query by using toplink.
tried your example
ExpressionBuilder builder = new ExpressionBuilder();
Expression creditRating = builder.getTable("RATING").getField("ID_C");
Expression issue_ref = builder.getTable("REF").getField("ID_C");
Expression join = creditRating.equal(issue_ref);
I am getting java.lang.OutOfMemoryError
error.
I selected the option generate classes and descriptors
from the tables (RATING,REF).,so it created the classes and dscriptors automatically.
In Database script for the table RATING like this
ALTER TABLE RATING ADD (
CONSTRAINT RATING_F1 FOREIGN KEY (ID_C, ALPHA_C)
REFERENCES REF (ID_C,ALPHA_C));
I think when i generate descriptor automatically it is keeping this association.
Please help me......... -
F4 help for Time field in webdynpro abap
Hi Guru's,
how to get f4 help for time field in webdynpro abap.
thanks in advance,
narendraHi Narendra,
Check this link:
Re: Time Search Help
Also few more links here:
http://forumsa.sdn.sap.com/search.jspa?forumID=249&threadID=&q=time+help&objID=f249&dateRange=lastyear&numResults=15&rankBy=10001
Also check if this example helps you: WDR_TEST_HELP
If your query is not yet answered then its advisable to post in webdynpro for abap (Web Dynpro ABAP). You may get some quick repliy.
Regards,
Swarna Munukoti. -
Query to join 2 tables by interval of value
Hi all
I need your help in creating a query to join 2 tables by interval of values.
The thing i want to d ois like this: i have 2 tables the first one containing list of serial number and the secon is containing interval of serial number (startnumber and end number) and other information like the user creating the serial number.
I want to list all serial numbers from the first table and the user creating each serial number from the second one if the serial number is between each interval of the second table.
here is an example>
SQL> create table test1 (code varchar2(1), serial number);
Table created.
SQL> create table test2 (requester varchar2(10),startno number, endno number);
Table created.
SQL> insert into test1 values('A',1);
1 row created.
SQL> insert into test1 values('B',3);
1 row created.
SQL> insert into test1 values('C',8);
1 row created.
SQL> insert into test1 values('D',12);
1 row created.
SQL> insert into test1 values('E',20);
1 row created.
SQL> commit;
Commit complete.
SQL> insert into test2 values('TATA',1,5);
1 row created.
SQL> insert into test2 values('TOTO',6,10);
1 row created.
SQL> commit;
Commit complete.
The result i want to get are:
TESt1.CODE TEST2.REQUESTER
A TATA
B TATA
C TOTO
D null
E nullUse outer join:
select code,
requester
from test1,
test2
where serial between startno(+) and endno(+)
order by code
C REQUESTER
A TATA
B TATA
C TOTO
D
E
SQL> SY. -
Need complex query with joins and AGGREGATE functions.
Hello Everyone ;
Good Morning to all ;
I have 3 tables with 2 lakhs record. I need to check query performance.. How CBO rewrites my query in materialized view ?
I want to make complex join with AGGREGATE FUNCTION.
my table details
SQL> select from tab;*
TNAME TABTYPE CLUSTERID
DEPT TABLE
PAYROLL TABLE
EMP TABLE
SQL> desc emp
Name
EID
ENAME
EDOB
EGENDER
EQUAL
EGRADUATION
EDESIGNATION
ELEVEL
EDOMAIN_ID
EMOB_NO
SQL> desc dept
Name
EID
DNAME
DMANAGER
DCONTACT_NO
DPROJ_NAME
SQL> desc payroll
Name
EID
PF_NO
SAL_ACC_NO
SALARY
BONUS
I want to make complex query with joins and AGGREGATE functions.
Dept names are : IT , ITES , Accounts , Mgmt , Hr
GRADUATIONS are : Engineering , Arts , Accounts , business_applications
I want to select records who are working in IT and ITES and graduation should be "Engineering"
salary > 20000 and < = 22800 and bonus > 1000 and <= 1999 with count for males and females Separately ;
Please help me to make a such complex query with joins ..
Thanks in advance ..
Edited by: 969352 on May 25, 2013 11:34 AM969352 wrote:
why do you avoid providing requested & NEEDED details?I do NOT understand what do you expect ?
My Goal is :
1. When executing my own query i need to check expalin plan.please proceed to do so
http://docs.oracle.com/cd/E11882_01/server.112/e26088/statements_9010.htm#SQLRF01601
2. IF i enable query rewrite option .. i want to check explain plan ( how optimizer rewrites my query ) ? please proceed to do so
http://docs.oracle.com/cd/E11882_01/server.112/e16638/ex_plan.htm#PFGRF009
3. My only aim is QUERY PERFORMANCE with QUERY REWRITE clause in materialized view.It is an admirable goal.
Best Wishes on your quest for performance improvements. -
Is index range scan the reason for query running long time
I would like to know whether index range scan is the reason for the query running long time. Below is the explain plan. If so, how to optimise it? Please help
Operation Object COST CARDINALITY BYTES
SELECT STATEMENT () 413 1000 265000
COUNT (STOPKEY)
FILTER ()
TABLE ACCESS (BY INDEX ROWID) ORDERS 413 58720 15560800
INDEX (RANGE SCAN) IDX_SERV_PROV_ID 13 411709
TABLE ACCESS (BY INDEX ROWID) ADDRESSES 2 1 14
INDEX (UNIQUE SCAN) SYS_C004605 1 1
TABLE ACCESS (BY INDEX ROWID) ADDRESSES 2 1 14
INDEX (UNIQUE SCAN) SYS_C004605 1 1
TABLE ACCESS (BY INDEX ROWID) ADDRESSES 2 1 14
INDEX (UNIQUE SCAN) SYS_C004605 1 1The index range scan means that the optimiser has determined that it is better to read the index rather than perform a full table scan. So in answer to your question - quite possibly but the alternative might take even longer!
The best thing to do is to review your query and check that you need every table included in the query and that you are accessing the tables via the best route. For example if you can access a table via primary key index that would be better than using a non-unique index. But the best way of reducing the time the query takes to run is to give it less tables (and indexes) to read.
John Seaman
http://www.asktheoracle.net -
SQL Query taking longer time as seen from Trace file
Below Query Execution timings:
Any help will be benefitial as its affecting business needs.
SELECT MATERIAL_DETAIL_ID
FROM
GME_MATERIAL_DETAILS WHERE BATCH_ID = :B1 FOR UPDATE OF ACTUAL_QTY NOWAIT
call count cpu elapsed disk query current rows
Parse 1 0.00 0.70 0 0 0 0
Execute 2256 8100.00 24033.51 627 12298 31739 0
Fetch 2256 900.00 949.82 0 12187 0 30547
total 4513 9000.00 24984.03 627 24485 31739 30547
Thanks and RegardsThanks Buddy.
Data Collected from Trace file:
SELECT STEP_CLOSE_DATE
FROM
GME_BATCH_STEPS WHERE BATCH_ID
IN (SELECT
DISTINCT BATCH_ID FROM
GME_MATERIAL_DETAILS START WITH BATCH_ID = :B2 CONNECT BY PRIOR PHANTOM_ID=BATCH_ID)
AND NVL(STEP_CLOSE_DATE, :B1) > :B1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.54 0 0 0 0
Execute 2256 800.00 1120.32 0 0 0 0
Fetch 2256 9100.00 13551.45 396 77718 0 0
total 4513 9900.00 14672.31 396 77718 0 0
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 66 (recursive depth: 1)
Rows Row Source Operation
0 TABLE ACCESS BY INDEX ROWID GME_BATCH_STEPS
13160 NESTED LOOPS
6518 VIEW
6518 SORT UNIQUE
53736 CONNECT BY WITH FILTERING
30547 NESTED LOOPS
30547 INDEX RANGE SCAN GME_MATERIAL_DETAILS_U1 (object id 146151)
30547 TABLE ACCESS BY USER ROWID GME_MATERIAL_DETAILS
23189 NESTED LOOPS
53736 BUFFER SORT
53736 CONNECT BY PUMP
23189 TABLE ACCESS BY INDEX ROWID GME_MATERIAL_DETAILS
23189 INDEX RANGE SCAN GME_MATERIAL_DETAILS_U1 (object id 146151)
4386 INDEX RANGE SCAN GME_BATCH_STEPS_U1 (object id 146144)
In the Package there are lots of SQL Statements using CONNECT BY CLAUSE.
Does the use of CONNECT BY Clause degrades performance?
As you can see the Rows Section is 0 but the Query and elapsed time is taking longer
Regards
Maybe you are looking for
-
I have a 1st generation MacBook Pro and I recently downloaded OS X Maverick. My iTunes will not open because it says i need a 64 bit version. Already followed the promted instructions but no luck. Any suggestions??
-
I was helping a friend with a Mac purchase over the weekend and the salesperson said something that alarmed me, since I've been shopping around for a new (bigger) internal hard drive for my MacBook. The Apple salesperson mentioned in passing that Mac
-
Spatial 9.0.1.2 SDO_DISTANCE never returns
Query: select sdo_geom.SDO_DISTANCE (mdsys.sdo_geometry(2001, 8307, mdsys.sdo_point_type(28,235 -26,NULL), NULL, NULL), mdsys.sdo_geometry(2001, 8307, mdsys.sdo_point_type(28, -26,NULL), NULL, NULL), 0.005
-
Why is there no responses when i install the oracle8i?
I want to install oracle8i in my computer,but everytime when i double_clicked the setup.exe file(I just copied it from a disk),there is no responses.My o/s is windows2000 advance server. I have tried in another computer(os is windows2000 professional
-
External Drves Not accepting Final Cut Files?
After attempting to save my files in my ext. HD (usb 300 gig) it will not open the file and states file unable to open. when I look in the info tab it shows nothing. If I change the storage default to the internal drive, it saves it and it can be ret