Optimization of select query
How to optimize the below select query
SELECT mvke~matnr "Material Number
mbew~bwkey "Plant
mvke~mvgr1 "Line of Business
mara~meins "Unit of measure
mara~ntgew "Net weight
mara~mhdrz "Remaining shelf life
mara~zzmax_exp_days "Max expiry days
makt~maktx "Material Description
tvm1t~bezei "Line of Business description
mbew~stprs "Standard price
mbew~vprsv "Price control (S/V)
mbew~verpr "Variable Price
FROM mvke INNER JOIN mara
ON maramatnr EQ mvkematnr
INNER JOIN makt
ON maktmatnr EQ mvkematnr
INNER JOIN tvm1t
ON tvm1tmvgr1 EQ mvkemvgr1
INNER JOIN mbew
ON mbewmatnr EQ maramatnr
AND
mbewbwkey EQ mvkevkorg
INTO TABLE gt_matdata
WHERE mbew~matnr IN s_matnr AND
mbew~bwkey IN s_werks AND
mvke~mvgr1 IN s_mvgr1 AND
makt~spras EQ sy-langu AND
tvm1t~spras EQ sy-langu.
Please advice.
Thanks and Regards
Syed Samdani
Hi,
You are taking different fields of data from five different tables it seems.
Well you can take separate internal tables and fire five separate select queries using the 'For All Entries' condition after the first select stmnt, so that u get all the related data. Then take your final internal table and merge all data from all these five internal tables into you final table.
Regards,
Jayadeep
Similar Messages
-
Performance optimization on select query for all entries
Hi All,
I want to optimize the select query in my Program.
The select query is taking lot of time to search the records for the given condition in the where clause
and more interestingly there are no records fetched from the database as the where condition does not matches.
It is taking more than 30 min to search the record and the result is no record found.
Below is my select query. I have also created the secondary Index for the same.
In My opinion FOR ALL ENTRIES is taking lot of time. Because there are more than 1200 records in internal table t_ajot
select banfn bnfpo bsart txz01 matnr Werks lgort matkl reswk menge meins flief ekorg
INTO CORRESPONDING FIELDS OF TABLE t_req
FROM eban
FOR ALL ENTRIES IN t_ajot
WHERE matkl >= t_ajot-matkl_low
AND matkl <= t_ajot-matkl_high
AND werks = t_ajot-werks
AND loekz = ' '
AND badat IN s_badat
AND bsart = 'NB'.
Please suggest.Hi,
that,
FOR ALL ENTRIES IN t_ajot
WHERE matkl >= t_ajot-matkl_low
AND matkl <= t_ajot-matkl_high
AND werks = t_ajot-werks
AND loekz = ' '
AND badat IN s_badat
AND bsart = 'NB'.
looks strange.
However:
How does your index look like?
What executoin plan do you get?
How do the statistics look like?
Whats the content of the variables t_ajot-... and s_badata?
Kind regards,
Hermann -
How to optimize the select query that is executed in a cursor for loop?
Hi Friends,
I have executed the code below and clocked the times for every line of the code using DBMS_PROFILER.
CREATE OR REPLACE PROCEDURE TEST
AS
p_file_id NUMBER := 151;
v_shipper_ind ah_item.shipper_ind%TYPE;
v_sales_reserve_ind ah_item.special_sales_reserve_ind%TYPE;
v_location_indicator ah_item.exe_location_ind%TYPE;
CURSOR activity_c
IS
SELECT *
FROM ah_activity_internal
WHERE status_id = 30
AND file_id = p_file_id;
BEGIN
DBMS_PROFILER.start_profiler ('TEST');
FOR rec IN activity_c
LOOP
SELECT DISTINCT shipper_ind, special_sales_reserve_ind, exe_location_ind
INTO v_shipper_ind, v_sales_reserve_ind, v_location_indicator
FROM ah_item --464000 rows in this table
WHERE item_id_edw IN (
SELECT item_id_edw
FROM ah_item_xref --700000 rows in this table
WHERE item_code_cust = rec.item_code_cust
AND facility_num IN (
SELECT facility_code
FROM ah_chain_div_facility --17 rows in this table
WHERE chain_id = ah_internal_data_pkg.get_chain_id (p_file_id)
AND div_id = (SELECT div_id
FROM ah_div --8 rows in this table
WHERE division = rec.division)));
END LOOP;
DBMS_PROFILER.stop_profiler;
EXCEPTION
WHEN NO_DATA_FOUND
THEN
NULL;
WHEN TOO_MANY_ROWS
THEN
NULL;
END TEST;The SELECT query inside the cursor FOR LOOP took 773 seconds.
I have tried using BULK COLLECT instead of cursor for loop but it did not help.
When I took out the select query separately and executed with a sample value then it gave the results in a flash of second.
All the tables have primary key indexes.
Any ideas what can be done to make this code perform better?
Thanks,
Raj.As suggested I'd try merging the queries into a single SQL. You could also rewrite your IN clauses as JOINs and see if that helps, e.g.
SELECT DISTINCT ai.shipper_ind, ai.special_sales_reserve_ind, ai.exe_location_ind
INTO v_shipper_ind, v_sales_reserve_ind, v_location_indicator
FROM ah_item ai, ah_item_xref aix, ah_chain_div_facility acdf, ah_div ad
WHERE ai.item_id_edw = aix.item_id_edw
AND aix.item_code_cust = rec.item_code_cust
AND aix.facility_num = acdf.facility_code
AND acdf.chain_id = ah_internal_data_pkg.get_chain_id (p_file_id)
AND acdf.div_id = ad.div_id
AND ad.division = rec.division;ALSO: You are calling ah_internal_data_pkg.get_chain_id (p_file_id) every time. Why not do it outside the loop and just use a variable in the inner query? That will prevent context switching and improve speed.
Edited by: Dave Hemming on Dec 3, 2008 9:34 AM -
Hi,
Following query is taking about 30-40 mins to fetch the data in a procedure.I tried using the hints and ran the explain plan but the cost is still the same (151,894) . Can anyone please help me in tuning the query.
SELECT SYSDATE c_creation_date, glcc.code_combination_id c_ccid,
glcc.segment1 c_funding, glcc.segment2 c_resp_ctr,
glcc.segment3 c_account, glcc.segment4 c_pgm_phase,
glcc.segment5 c_project_cd, null c_vendor_id,
null c_vendor_num, null c_vendor_name,
null c_site_code,
null c_vendor_type,
null c_project_id, null c_project,
null c_project_name,
null c_organization_id,
null c_organization, null c_expenditure_type_id,
null c_expenditure_type,
null c_task_id, null c_task,
null c_task_name, null c_award_id,
null c_award, null c_award_name,
jel.je_header_id c_document_batch_id,
jeh.name c_document_batch_name,
-- jel.reference_2 c_document_id, --- Note: reference_2 invoice_id,po_header_id,req_header_id
case
when je_source = 'Purchasing'
then jel.reference_2
when je_source = 'Payables'
then jel.reference_2
else null
end c_document_id,
case
when je_source = 'Purchasing'
then 'GLJE-'||je_source||' '||jel.reference_1
else 'GLJE-'||je_source
end c_document_type,
case
when je_source = 'Payables'
then jel.reference_5
when je_source = 'Purchasing'
then reference_4
else
reference_4
end c_document_number,
NULL c_document_release_id, NULL c_document_release,
NULL c_document_line_id,
null c_document_line_num,
case
when je_source = 'Purchasing'
then jel.reference_3
else null
end c_document_dist_id,
case
when je_source = 'Payables'
then jel.reference_3
else null
end c_document_dist_num,
0 c_distr_amount,
(nvl(accounted_dr,0) - nvl(accounted_cr,0)) c_encumbered_amount,
0,0,0,0,0,0,NULL,jel.je_line_num c_je_line_num
FROM gl_je_lines jel,
gl_je_headers jeh,
gl_encumbrance_types jee ,
gl_code_combinations glcc
WHERE jel.je_header_id = jeh.je_header_id
AND jel.CODE_COMBINATION_ID = glcc.CODE_COMBINATION_ID
AND jee.encumbrance_type_id = jeh.encumbrance_type_id
AND actual_flag = 'E'
and glcc.segment1
|| '-'
|| glcc.segment2
|| '-'
|| glcc.segment3
|| '-'
|| glcc.segment4
|| '-'
|| glcc.segment5
|| '-'
|| glcc.segment6
|| '-'
|| glcc.segment7 between nvl(:p_min_flex, :l_min_flex) and nvl(:p_max_flex,: l_max_flex )
and encumbrance_type = nvl(:l_enc_type,encumbrance_type)
and jel.EFFECTIVE_DATE between nvl(:p_encumbrance_date_from,:l_date_low)
and nvl(:p_encumbrance_date_to,:l_date_high)
and decode(je_source,'Purchasing',jel.reference_4,'Payables',jel.reference_5)
=nvl(:l_doc_number,decode(je_source,'Purchasing',jel.reference_4,'Payables',jel.reference_5))
and je_source != 'Payables';
I will appreciate the help!
Regards,
DarshiniHi,
Thanks Sundar and Miguel for the article, it is very helpful.
I was able to get the output from explain plan as well as sql_trace.But I could not understand how to compare the files and optimize the query. follwing are the outputs
select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 2 | 336 | 151K|
| 1 | CONCATENATION | | | | |
| 2 | FILTER | | | | |
| 3 | NESTED LOOPS | | 1 | 168 | 54873 |
| 4 | NESTED LOOPS | | 1 | 155 | 54872 |
| 5 | NESTED LOOPS | | 1633 | 180K| 53237 |
| 6 | TABLE ACCESS FULL | GL_CODE_COMBINATIONS | 1387 | 77672 | 3713 |
| 7 | TABLE ACCESS BY INDEX ROWID| GL_JE_LINES | 1 | 57 | 66 |
| 8 | INDEX RANGE SCAN | GL_JE_LINES_N1 | 135 | | 3 |
| 9 | TABLE ACCESS BY INDEX ROWID | GL_JE_HEADERS | 1 | 42 | 1 |
| 10 | INDEX UNIQUE SCAN | GL_JE_HEADERS_U1 | 1 | | 0 |
| 11 | TABLE ACCESS BY INDEX ROWID | GL_ENCUMBRANCE_TYPES | 1 | 13 | 1 |
| 12 | INDEX UNIQUE SCAN | GL_ENCUMBRANCE_TYPES_U1 | 1 | | 0 |
| 13 | FILTER | | | | |
| 14 | NESTED LOOPS | | 1 | 168 | 97021 |
| 15 | NESTED LOOPS | | 1633 | 200K| 95386 |
| 16 | NESTED LOOPS | | 1387 | 95703 | 3714 |
PLAN_TABLE_OUTPUT
| 17 | TABLE ACCESS BY INDEX ROWID| GL_ENCUMBRANCE_TYPES | 1 | 13 | 1 |
| 18 | INDEX UNIQUE SCAN | GL_ENCUMBRANCE_TYPES_U2 | 1 | | 0 |
| 19 | TABLE ACCESS FULL | GL_CODE_COMBINATIONS | 1387 | 77672 | 3713 |
| 20 | TABLE ACCESS BY INDEX ROWID | GL_JE_LINES | 1 | 57 | 66 |
| 21 | INDEX RANGE SCAN | GL_JE_LINES_N1 | 135 | | 3 |
| 22 | TABLE ACCESS BY INDEX ROWID | GL_JE_HEADERS | 1 | 42 | 1 |
| 23 | INDEX UNIQUE SCAN | GL_JE_HEADERS_U1 | 1 | | 0 |
sql_trace
PARSING IN CURSOR #2 len=3812 dep=0 uid=173 oct=3 lid=173 tim=3338840240188 hv=2038351921 ad='aaf94e98'
SELECT SYSDATE c_creation_date, glcc.code_combination_id c_ccid ,
glcc.segment1 c_funding, glcc.segment2 c_resp_ctr,
glcc.segment3 c_account, glcc.segment4 c_pgm_phase,
glcc.segment5 c_project_cd, null c_vendor_id,
null c_vendor_num, null c_vendor_name,
null c_site_code,
null c_vendor_type,
null c_project_id, null c_project,
null c_project_name,
null c_organization_id,
null c_organization, null c_expenditure_type_id,
null c_expenditure_type,
null c_task_id, null c_task,
null c_task_name, null c_award_id,
null c_award, null c_award_name,
jel.je_header_id c_document_batch_id,
jeh.name c_document_batch_name,
case
when je_source = 'Purchasing'
then jel.reference_2
when je_source = 'Payables'
then jel.reference_2
else null
end c_document_id,
case
when je_source = 'Purchasing'
then 'GLJE-'||je_source||' '||jel.reference_1
else 'GLJE-'||je_source
end c_document_type,
case
when je_source = 'Payables'
then jel.reference_5
when je_source = 'Purchasing'
then reference_4
else
reference_4
end c_document_number,
NULL c_document_release_id, NULL c_document_release,
NULL c_document_line_id,
null c_document_line_num,
case
when je_source = 'Purchasing'
then jel.reference_3
else null
end c_document_dist_id,
case
when je_source = 'Payables'
then jel.reference_3
else null
end c_document_dist_num,
0 c_distr_amount,
(nvl(accounted_dr,0) - nvl(accounted_cr,0)) c_encumbered_amount,
0,0,0,0,0,0,NULL,jel.je_line_num c_je_line_num
FROM gl_je_lines jel,
gl_je_headers jeh,
gl_encumbrance_types jee ,
gl_code_combinations glcc
WHERE jel.je_header_id = jeh.je_header_id
AND jel.CODE_COMBINATION_ID = glcc.CODE_COMBINATION_ID
AND jee.encumbrance_type_id = jeh.encumbrance_type_id
AND actual_flag = 'E'
and glcc.segment1
|| '-'
|| glcc.segment2
|| '-'
|| glcc.segment3
|| '-'
|| glcc.segment4
|| '-'
|| glcc.segment5
|| '-'
|| glcc.segment6
|| '-'
|| glcc.segment7 between nvl(null,'F017-M029300-1980200200-CF2004-000000-00000-00000')
and nvl(null,'F017-M029300-1980200200-CF2004-000000-00000-00000' )
and encumbrance_type = nvl('Obligation',encumbrance_type)
and jel.EFFECTIVE_DATE between nvl(null,'01-JAN-1900')
and nvl(null,'31-DEC-4712')
and decode(je_source,'Purchasing',jel.reference_4,'Payables',jel.reference_5)
=nvl('5013794',decode(je_source,'Purchasing',jel.reference_4,'Payables',jel.reference_5))
and je_source != 'Payables'
END OF STMT
PARSE #2:c=50000,e=42317,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=3338840240172
EXEC #2:c=0,e=621,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=3338840243240
FETCH #2:c=5910000,e=5837875,p=13246,cr=19198,cu=0,mis=0,r=1,dep=0,og=1,tim=3338846081769
FETCH #2:c=0,e=1166,p=0,cr=8,cu=0,mis=0,r=15,dep=0,og=1,tim=3338846086521
*** 2008-08-06 12:24:18.016
FETCH #2:c=10000,e=2155,p=0,cr=21,cu=0,mis=0,r=15,dep=0,og=1,tim=3338854116887
FETCH #2:c=0,e=1812,p=0,cr=14,cu=0,mis=0,r=15,dep=0,og=1,tim=3338860800729
*** 2008-08-06 12:24:31.298
FETCH #2:c=10000,e=1729,p=0,cr=10,cu=0,mis=0,r=15,dep=0,og=1,tim=3338867087393
FETCH #2:c=0,e=1810,p=0,cr=14,cu=0,mis=0,r=15,dep=0,og=1,tim=3338872996057
*** 2008-08-06 12:24:43.317
FETCH #2:c=0,e=1728,p=0,cr=9,cu=0,mis=0,r=15,dep=0,og=1,tim=3338878825390
FETCH #2:c=0,e=2058,p=0,cr=12,cu=0,mis=0,r=15,dep=0,og=1,tim=3338884698870
*** 2008-08-06 12:24:57.286
FETCH #2:c=0,e=2095,p=0,cr=10,cu=0,mis=0,r=10,dep=0,og=1,tim=3338892467618
STAT #2 id=1 cnt=116 pid=0 pos=1 obj=0 op='HASH JOIN (cr=19296 pr=13246 pw=0 time=5837597 us)'
STAT #2 id=2 cnt=5464 pid=1 pos=1 obj=33979 op='TABLE ACCESS FULL GL_JE_HEADERS (cr=6120 pr=183 pw=0 time=796948 us)'
STAT #2 id=3 cnt=174 pid=1 pos=2 obj=34028 op='TABLE ACCESS BY INDEX ROWID GL_JE_LINES (cr=13176 pr=13063 pw=0 time=5576761 us)'
STAT #2 id=4 cnt=176 pid=3 pos=1 obj=0 op='NESTED LOOPS (cr=13088 pr=13063 pw=0 time=487814114 us)'
STAT #2 id=5 cnt=1 pid=4 pos=1 obj=0 op='MERGE JOIN CARTESIAN (cr=13076 pr=13063 pw=0 time=5575083 us)'
STAT #2 id=6 cnt=1 pid=5 pos=1 obj=34354 op='TABLE ACCESS FULL GL_ENCUMBRANCE_TYPES (cr=6 pr=0 pw=0 time=453 us)'
STAT #2 id=7 cnt=1 pid=5 pos=2 obj=0 op='BUFFER SORT (cr=13070 pr=13063 pw=0 time=5574591 us)'
STAT #2 id=8 cnt=1 pid=7 pos=1 obj=33834 op='TABLE ACCESS FULL GL_CODE_COMBINATIONS (cr=13070 pr=13063 pw=0 time=5573921 us)'
STAT #2 id=9 cnt=174 pid=4 pos=2 obj=34055 op='INDEX RANGE SCAN GL_JE_LINES_N1 (cr=12 pr=0 pw=0 time=349 us)'
=====================
I will greatly appreciate if any one can help me further.
Thanks,
Darshini -
Performance optimization in Select query
Hi All,
Please suggest good performance practice for the below code.
SELECT * FROM BKPF WHERE BUKRS IN SO_BUKRS
AND BELNR IN SO_BELNR
AND GJAHR IN SO_GJAHR
AND BLART IN SO_BLART
AND BUDAT IN SO_BUDAT
AND USNAM IN SO_USNAM.
CLEAR BSEG.
SELECT * FROM BSEG WHERE BUKRS EQ BKPF-BUKRS
AND BELNR EQ BKPF-BELNR
AND GJAHR EQ BKPF-GJAHR
AND KOART EQ 'K'.
SELECT SINGLE * FROM LFA1 WHERE LIFNR EQ BSEG-LIFNR
AND KTOKK IN SO_KTOKK.
CHECK SY-SUBRC EQ 0.
MOVE-CORRESPONDING BKPF TO ITAB2.
MOVE BSEG-LIFNR TO ITAB2-LIFNR.
APPEND ITAB2.
ENDSELECT.
PERFORM CHECK_FOR_REVERSAL.
ENDSELECT.
Thanks
Sonaldeclare internal table for BKPF, BSEG & LFA1 separately.
instead of using Select & End select, use for all entries.
SELECT * FROM BKPF into table itab1 WHERE BUKRS IN SO_BUKRS
AND BELNR IN SO_BELNR
AND GJAHR IN SO_GJAHR
AND BLART IN SO_BLART
AND BUDAT IN SO_BUDAT
AND USNAM IN SO_USNAM.
if not itab1[] is initial.
sort bkpf by belnr.
SELECT * FROM BSEG into table itab2
for all entries in itab1
WHERE BUKRS EQ itab1-BUKRS
AND BELNR EQ itab1-BELNR
AND GJAHR EQ itab1-GJAHR
AND KOART EQ 'K'.
if not itab2[] is initial.
sort itab2 by lifnr
SELECT SINGLE * FROM LFA1 into table itab3
for all entries in itab2
WHERE LIFNR EQ itab2-LIFNR
AND KTOKK IN SO_KTOKK.
endif.
endif.
endif.
sort itab1 by belnr.
sort itab2 by belnr.
sort itab3 by lifnr.
loop at itab1.
move-corresponding itab1 to itfinal.
loop at itab2 where belnr = itab1-belnr.
move-corresponding itab2 to itfinal.
read itab3 with key lifnr = itab2-lifnr.
if sy-subrc = 0.
move-corresponding itab3 to itfinal.
endif.
endloop.
append itfinal.
clear itfinal.
endloop. -
How can I optimize this select query? Basically, how can I factor out the common codes in the query below
(i.e. r.batch_id is null AND r.rpt_type='Child' is a common criteria for the two filter conditions)
SQL:
SELECT DISTINCT rpt_id, rpt_name, emp_id
FROM REPORT r
WHERE r.batch_id is null
AND r.rpt_type='Child'
--filter by BU only
AND (r.BU IN (SELECT BU FROM BUnit WHERE Active='Y'))
--filter by BU/OU combination
OR r.batch_id is null
AND r.rpt_type='Child'
AND (r.BU || ' ' || R.OU IN (SELECT BU || ' ' || OU FROM BUnit WHERE Active='Y'))
Thank you.
Edited by: 874976 on Jul 25, 2011 5:53 PM874976 wrote:
How can I optimize this select query? Basically, how can I factor out the common codes in the query below
(i.e. r.batch_id is null AND r.rpt_type='Child' is a common criteria for the two filter conditions)
SQL:
SELECT DISTINCT rpt_id, rpt_name, emp_id
FROM REPORT r
WHERE r.batch_id is null
AND r.rpt_type='Child'
--filter by BU only
AND (r.BU IN (SELECT BU FROM BUnit WHERE Active='Y'))
--filter by BU/OU combination
OR r.batch_id is null
AND r.rpt_type='Child'
AND (r.BU || ' ' || R.OU IN (SELECT BU || ' ' || OU FROM BUnit WHERE Active='Y'))
Thank you.
Edited by: 874976 on Jul 25, 2011 5:53 PM
How can I optimize this select query? query is already optimized.
If you disagree, then prove me wrong. -
Hi..
The below select query is causing performance issue in production , it is taking much time.
Please suggest how to optimize it .
SELECT belnr bukrs gjahr awkey blart FROM bkpf
INTO TABLE t_bkpf
WHERE bukrs IN s_bukrs AND
gjahr IN r_year.
Regards
chetan
Moderator message - Please see Please Read before Posting in the Performance and Tuning Forum before posting - post locked
Edited by: Rob Burbank on Oct 13, 2009 10:49 AMHi Chetan,
I suggest the following to optimize your performance.
- Change the order of the fields (belnr bukrs gjahr awkey blart), so that they're in the same order than showned in SE11 table data definition (you may need to change the order in t_bkpf definiton also).
- Add the client in your select statement.
Something like this:
SELECT bukrs belnr gjahr blart awkey FROM bkpf CLIENT SPECIFIED
INTO TABLE t_bkpf
WHERE mandt = sy-mandt
AND bukrs IN s_bukrs
AND gjahr IN r_year.
Your statement it's very simple. I don't think that there is much more to do.
Hope that helps.
Kind regards.
Edited by: Bruno Garcia on Oct 10, 2009 10:48 AM -
Oracle SQL Select query takes long time than expected.
Hi,
I am facing a problem in SQL select query statement. There is a long time taken in select query from the Database.
The query is as follows.
select /*+rule */ f1.id,f1.fdn,p1.attr_name,p1.attr_value from fdnmappingtable f1,parametertable p1 where p1.id = f1.id and ((f1.object_type ='ne_sub_type.780' )) and ( (f1.id in(select id from fdnmappingtable where fdn like '0=#1#/14=#S0058-3#/17=#S0058-3#/18=#1#/780=#5#%')))order by f1.id asc
This query is taking more than 4 seconds to get the results in a system where the DB is running for more than 1 month.
The same query is taking very few milliseconds (50-100ms) in a system where the DB is freshly installed and the data in the tables are same in both the systems.
Kindly advice what is going wrong??
Regards,
PurushothamSQL> @/alcatel/omc1/data/query.sql
2 ;
9 rows selected.
Execution Plan
Plan hash value: 3745571015
| Id | Operation | Name |
| 0 | SELECT STATEMENT | |
| 1 | SORT ORDER BY | |
| 2 | NESTED LOOPS | |
| 3 | NESTED LOOPS | |
| 4 | TABLE ACCESS FULL | PARAMETERTABLE |
|* 5 | TABLE ACCESS BY INDEX ROWID| FDNMAPPINGTABLE |
|* 6 | INDEX UNIQUE SCAN | PRIMARY_KY_FDNMAPPINGTABLE |
|* 7 | TABLE ACCESS BY INDEX ROWID | FDNMAPPINGTABLE |
|* 8 | INDEX UNIQUE SCAN | PRIMARY_KY_FDNMAPPINGTABLE |
Predicate Information (identified by operation id):
5 - filter("F1"."OBJECT_TYPE"='ne_sub_type.780')
6 - access("P1"."ID"="F1"."ID")
7 - filter("FDN" LIKE '0=#1#/14=#S0058-3#/17=#S0058-3#/18=#1#/780=#5#
8 - access("F1"."ID"="ID")
Note
- rule based optimizer used (consider using cbo)
Statistics
0 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
0 bytes sent via SQL*Net to client
0 bytes received via SQL*Net from client
0 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
9 rows processed
SQL> -
Getting deadlock detected while waiting for resource error for select Query.....
Hi all,
i am getting a below error whenever executing the below select query....
some times it will show dead lock detected while waiting for resource and terminated...
some times it executes and gives result..
but all the time it writes an alert to alert log
Plesae suggest how to resolve the issue..........
Thanks in advance
Env: Linux / Oracle 11.2.0.3.3
Error from alert log:
Errors in file /u01/oracle/oracle/diag/rdbms/bdrdb/bdrdb/trace/bdrdb_p017_6076.trc:
ORA-00060: deadlock detected while waiting for resource
ORA-10387: parallel query server interrupt (normal)
Trace file info... bdrdb_p017_6076.trc:
Trace file /u01/oracle/oracle/diag/rdbms/bdrdb/bdrdb/trace/bdrdb_p017_6076.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /u01/oracle/oracle/product/11.2.0/dbhome_1
System name: Linux
Node name: bdrdb.cteplindia.com
Release: 2.6.18-308.el5PAE
Version: #1 SMP Fri Jan 27 17:40:09 EST 2012
Machine: i686
Instance name: bdrdb
Redo thread mounted by this instance: 1
Oracle process number: 92
Unix process pid: 6076, image: [email protected] (P017)
*** 2013-11-04 23:18:57.915
*** SESSION ID:(423.59970) 2013-11-04 23:18:57.915
*** CLIENT ID:() 2013-11-04 23:18:57.915
*** SERVICE NAME:(bdrdb) 2013-11-04 23:18:57.915
*** MODULE NAME:() 2013-11-04 23:18:57.915
*** ACTION NAME:() 2013-11-04 23:18:57.915
*** 2013-11-04 23:18:57.915
DEADLOCK DETECTED ( ORA-00060 )
[Transaction Deadlock]
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
PS-00000001-00000011 92 423 S 33 128 S X
BF-2ed08c01-00000000 33 128 S 92 423 S X
session 423: DID 0001-005C-00081126 session 128: DID 0001-0021-00067D23
session 128: DID 0001-0021-00067D23 session 423: DID 0001-005C-00081126
DEADLOCK DETECTED ( ORA-00060 )
[Transaction Deadlock]
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
PS-00000001-00000011 92 423 S 33 128 S X
BF-2ed08c01-00000000 33 128 S 92 423 S X
session 423: DID 0001-005C-00081126 session 128: DID 0001-0021-00067D23
session 128: DID 0001-0021-00067D23 session 423: DID 0001-005C-00081126
Rows waited on:
Session 423: no row
Session 128: obj - rowid = 00021DC1 - AAAh3BAAVAAAQL/AAA
(dictionary objn - 138689, file - 21, block - 66303, slot - 0)
----- Information for the OTHER waiting sessions -----
Session 128:
sid: 128 ser: 46176 audsid: 1836857 user: 102/DBLOCAL
flags: (0x8000041) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
flags2: (0x40009) -/-/INC
pid: 33 O/S info: user: oracle, term: UNKNOWN, ospid: 31611
image: [email protected]
client details:
O/S info: user: masked, term: masked, ospid: 5924:568
machine: masked program: Toad.exe
application name: TOAD background query session, hash value=526966934
current SQL:
application name: TOAD background query session, hash value=526966934
current SQL:
SELECT DISTINCT B_FP_TEST.TEST_ID
FROM B_FP_TEST,
B_USER_INFO,
J_FP_INVESTIGATOR,
L_TEST_STATUS,
L_ATMS_TEST_TYPE,
j_op_test_anml
WHERE B_FP_TEST.TEST_ID = J_FP_INVESTIGATOR.TEST_ID
AND B_FP_TEST.TEST_TYPE_ID = L_ATMS_TEST_TYPE.ATMS_TEST_TYPE_ID
AND B_USER_INFO.B_USER_INFO_ID = J_FP_INVESTIGATOR.INVESTIGATOR_ID
AND B_FP_TEST.STATUS_ID = L_TEST_STATUS.STATUS_ID
AND B_FP_TEST.IS_DELETED = :"SYS_B_00"
AND B_FP_TEST.TEST_NUM NOT IN (:"SYS_B_01", :"SYS_B_02", :"SYS_B_03")
AND L_ATMS_TEST_TYPE.IS_DELETED = :"SYS_B_04"
AND J_FP_INVESTIGATOR.is_pi = :"SYS_B_05"
AND L_TEST_STATUS.STATUS IN (:"SYS_B_06", :"SYS_B_07", :"SYS_B_08")
AND j_op_test_anml.test_id = B_FP_TEST.TEST_ID
----- End of information for the OTHER waiting sessions -----
*** 2013-11-04 23:18:57.916
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=3, mask=0x0)
----- Error Stack Dump -----
ORA-00060: deadlock detected while waiting for resource
ORA-10387: parallel query server interrupt (normal)
----- SQL Statement (None) -----
Current SQL information unavailable - no cursor.
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
More......
Query:
SELECT DISTINCT B_FP_TEST.TEST_ID
FROM B_FP_TEST,
B_USER_INFO,
J_FP_INVESTIGATOR,
L_TEST_STATUS,
L_ATMS_TEST_TYPE,
j_op_test_anml
WHERE B_FP_TEST.TEST_ID = J_FP_INVESTIGATOR.TEST_ID
AND B_FP_TEST.TEST_TYPE_ID = L_ATMS_TEST_TYPE.ATMS_TEST_TYPE_ID
AND B_USER_INFO.B_USER_INFO_ID = J_FP_INVESTIGATOR.INVESTIGATOR_ID
AND B_FP_TEST.STATUS_ID = L_TEST_STATUS.STATUS_ID
AND B_FP_TEST.IS_DELETED = 0
AND B_FP_TEST.TEST_NUM NOT IN (1, 2, 99)
AND L_ATMS_TEST_TYPE.IS_DELETED = 0
AND J_FP_INVESTIGATOR.is_pi = 1
AND L_TEST_STATUS.STATUS IN ('Scheduled', 'In-Progress', 'Completed')
AND j_op_test_anml.test_id = B_FP_TEST.TEST_ID
AND ( (j_op_test_anml.end_date BETWEEN TO_DATE ('28-Oct-2013') - 1
AND TO_DATE ('04-Nov-2013') + 1)
OR (j_op_test_anml.start_date BETWEEN TO_DATE ('28-Oct-2013') - 1
AND TO_DATE ('04-Nov-2013') + 1)
OR (TO_DATE ('28-Oct-2013') BETWEEN j_op_test_anml.start_date
AND j_op_test_anml.end_date)
OR (TO_DATE ('04-Nov-2013') BETWEEN j_op_test_anml.start_date
AND j_op_test_anml.end_date))
AND L_ATMS_TEST_TYPE.IS_DELETED = 0
AND B_FP_TEST.DATASOURCE_ID = 9
Query Exp plan:
Plan hash value: 3398228788
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 1501 | 102K| 1929 (1)| 00:00:24 | | | | | |
| 1 | HASH UNIQUE | | 1501 | 102K| 1929 (1)| 00:00:24 | | | | | |
| 2 | CONCATENATION | | | | | | | | | | |
| 3 | PX COORDINATOR | | | | | | | | | | |
| 4 | PX SEND QC (RANDOM) | :TQ30005 | 241 | 16870 | 800 (1)| 00:00:10 | | | Q3,05 | P->S | QC (RAND) |
|* 5 | HASH JOIN | | 241 | 16870 | 800 (1)| 00:00:10 | | | Q3,05 | PCWP | |
| 6 | PX RECEIVE | | 246 | 15990 | 797 (1)| 00:00:10 | | | Q3,05 | PCWP | |
| 7 | PX SEND HASH | :TQ30004 | 246 | 15990 | 797 (1)| 00:00:10 | | | Q3,04 | P->P | HASH |
|* 8 | HASH JOIN | | 246 | 15990 | 797 (1)| 00:00:10 | | | Q3,04 | PCWP | |
| 9 | PX RECEIVE | | 573 | 29223 | 793 (1)| 00:00:10 | | | Q3,04 | PCWP | |
| 10 | PX SEND HASH | :TQ30003 | 573 | 29223 | 793 (1)| 00:00:10 | | | Q3,03 | P->P | HASH |
|* 11 | HASH JOIN | | 573 | 29223 | 793 (1)| 00:00:10 | | | Q3,03 | PCWP | |
| 12 | BUFFER SORT | | | | | | | | Q3,03 | PCWC | |
| 13 | PX RECEIVE | | | | | | | | Q3,03 | PCWP | |
| 14 | PX SEND BROADCAST | :TQ30000 | | | | | | | | S->P | BROADCAST |
| 15 | NESTED LOOPS | | | | | | | | | | |
| 16 | NESTED LOOPS | | 485 | 20855 | 781 (0)| 00:00:10 | | | | | |
| 17 | TABLE ACCESS BY GLOBAL INDEX ROWID| J_OP_TEST_ANML | 485 | 10185 | 296 (0)| 00:00:04 | ROWID | ROWID | | | |
|* 18 | INDEX RANGE SCAN | IDX$$_2D190001 | 485 | | 4 (0)| 00:00:01 | | | | | |
|* 19 | INDEX UNIQUE SCAN | FT_TEST_ID_PK | 1 | | 0 (0)| 00:00:01 | | | | | |
|* 20 | TABLE ACCESS BY GLOBAL INDEX ROWID | B_FP_TEST | 1 | 22 | 1 (0)| 00:00:01 | ROWID | ROWID | | | |
| 21 | PX BLOCK ITERATOR | | 70382 | 549K| 11 (0)| 00:00:01 | | | Q3,03 | PCWC | |
|* 22 | TABLE ACCESS FULL | J_FP_INVESTIGATOR | 70382 | 549K| 11 (0)| 00:00:01 | | | Q3,03 | PCWP | |
| 23 | BUFFER SORT | | | | | | | | Q3,04 | PCWC | |
| 24 | PX RECEIVE | | 3 | 42 | 3 (0)| 00:00:01 | | | Q3,04 | PCWP | |
| 25 | PX SEND HASH | :TQ30001 | 3 | 42 | 3 (0)| 00:00:01 | | | | S->P | HASH |
|* 26 | TABLE ACCESS FULL | L_TEST_STATUS | 3 | 42 | 3 (0)| 00:00:01 | | | | | |
| 27 | BUFFER SORT | | | | | | | | Q3,05 | PCWC | |
| 28 | PX RECEIVE | | 30 | 150 | 3 (0)| 00:00:01 | | | Q3,05 | PCWP | |
| 29 | PX SEND HASH | :TQ30002 | 30 | 150 | 3 (0)| 00:00:01 | | | | S->P | HASH |
|* 30 | TABLE ACCESS FULL | L_ATMS_TEST_TYPE | 30 | 150 | 3 (0)| 00:00:01 | | | | | |
| 31 | NESTED LOOPS | | | | | | | | | | |
| 32 | NESTED LOOPS | | 3 | 210 | 329 (1)| 00:00:04 | | | | | |
| 33 | NESTED LOOPS | | 3 | 195 | 329 (1)| 00:00:04 | | | | | |
|* 34 | HASH JOIN | | 2 | 114 | 325 (1)| 00:00:04 | | | | | |
| 35 | NESTED LOOPS | | | | | | | | | | |
| 36 | NESTED LOOPS | | 6 | 258 | 322 (1)| 00:00:04 | | | | | |
| 37 | PARTITION RANGE SINGLE | | 6 | 126 | 316 (1)| 00:00:04 | 7 | 7 | | | |
|* 38 | TABLE ACCESS FULL | J_OP_TEST_ANML | 6 | 126 | 316 (1)| 00:00:04 | 7 | 7 | | | |
|* 39 | INDEX UNIQUE SCAN | FT_TEST_ID_PK | 1 | | 0 (0)| 00:00:01 | | | | | |
|* 40 | TABLE ACCESS BY GLOBAL INDEX ROWID | B_FP_TEST | 1 | 22 | 1 (0)| 00:00:01 | ROWID | ROWID | | | |
|* 41 | TABLE ACCESS FULL | L_TEST_STATUS | 3 | 42 | 3 (0)| 00:00:01 | | | | | |
|* 42 | TABLE ACCESS BY INDEX ROWID | J_FP_INVESTIGATOR | 1 | 8 | 2 (0)| 00:00:01 | | | | | |
|* 43 | INDEX RANGE SCAN | FI_TEST_ID_PK | 1 | | 1 (0)| 00:00:01 | | | | | |
|* 44 | INDEX UNIQUE SCAN | L_ATMS_TEST_TYPE_PK | 1 | | 0 (0)| 00:00:01 | | | | | |
|* 45 | TABLE ACCESS BY INDEX ROWID | L_ATMS_TEST_TYPE | 1 | 5 | 1 (0)| 00:00:01 | | | | | |
| 46 | PX COORDINATOR | | | | | | | | | | |
| 47 | PX SEND QC (RANDOM) | :TQ20003 | | | | | | | Q2,03 | P->S | QC (RAND) |
| 48 | NESTED LOOPS | | | | | | | | Q2,03 | PCWP | |
| 49 | NESTED LOOPS | | 33 | 2310 | 399 (2)| 00:00:05 | | | Q2,03 | PCWP | |
|* 50 | HASH JOIN | | 33 | 2145 | 397 (2)| 00:00:05 | | | Q2,03 | PCWP | |
| 51 | PX RECEIVE | | 78 | 3978 | 393 (1)| 00:00:05 | | | Q2,03 | PCWP | |
| 52 | PX SEND HASH | :TQ20002 | 78 | 3978 | 393 (1)| 00:00:05 | | | Q2,02 | P->P | HASH |
|* 53 | HASH JOIN | | 78 | 3978 | 393 (1)| 00:00:05 | | | Q2,02 | PCWP | |
| 54 | BUFFER SORT | | | | | | | | Q2,02 | PCWC | |
| 55 | PX RECEIVE | | | | | | | | Q2,02 | PCWP | |
| 56 | PX SEND BROADCAST | :TQ20000 | | | | | | | | S->P | BROADCAST |
| 57 | NESTED LOOPS | | | | | | | | | | |
| 58 | NESTED LOOPS | | 66 | 2838 | 382 (1)| 00:00:05 | | | | | |
| 59 | PARTITION RANGE SINGLE | | 66 | 1386 | 316 (1)| 00:00:04 | 7 | 7 | | | |
|* 60 | TABLE ACCESS FULL | J_OP_TEST_ANML | 66 | 1386 | 316 (1)| 00:00:04 | 7 | 7 | | | |
|* 61 | INDEX UNIQUE SCAN | FT_TEST_ID_PK | 1 | | 0 (0)| 00:00:01 | | | | | |
|* 62 | TABLE ACCESS BY GLOBAL INDEX ROWID | B_FP_TEST | 1 | 22 | 1 (0)| 00:00:01 | ROWID | ROWID | | | |
| 63 | PX BLOCK ITERATOR | | 70382 | 549K| 11 (0)| 00:00:01 | | | Q2,02 | PCWC | |
|* 64 | TABLE ACCESS FULL | J_FP_INVESTIGATOR | 70382 | 549K| 11 (0)| 00:00:01 | | | Q2,02 | PCWP | |
| 65 | BUFFER SORT | | | | | | | | Q2,03 | PCWC | |
| 66 | PX RECEIVE | | 3 | 42 | 3 (0)| 00:00:01 | | | Q2,03 | PCWP | |
| 67 | PX SEND HASH | :TQ20001 | 3 | 42 | 3 (0)| 00:00:01 | | | | S->P | HASH |
|* 68 | TABLE ACCESS FULL | L_TEST_STATUS | 3 | 42 | 3 (0)| 00:00:01 | | | | | |
|* 69 | INDEX UNIQUE SCAN | L_ATMS_TEST_TYPE_PK | 1 | | 0 (0)| 00:00:01 | | | Q2,03 | PCWP | |
|* 70 | TABLE ACCESS BY INDEX ROWID | L_ATMS_TEST_TYPE | 1 | 5 | 1 (0)| 00:00:01 | | | Q2,03 | PCWP | |
| 71 | PX COORDINATOR | | | | | | | | | | |
| 72 | PX SEND QC (RANDOM) | :TQ10003 | | | | | | | Q1,03 | P->S | QC (RAND) |
| 73 | NESTED LOOPS | | | | | | | | Q1,03 | PCWP | |
| 74 | NESTED LOOPS | | 33 | 2310 | 399 (2)| 00:00:05 | | | Q1,03 | PCWP | |
|* 75 | HASH JOIN | | 34 | 2210 | 397 (2)| 00:00:05 | | | Q1,03 | PCWP | |
| 76 | PX RECEIVE | | 78 | 3978 | 393 (1)| 00:00:05 | | | Q1,03 | PCWP | |
| 77 | PX SEND HASH | :TQ10002 | 78 | 3978 | 393 (1)| 00:00:05 | | | Q1,02 | P->P | HASH |
|* 78 | HASH JOIN | | 78 | 3978 | 393 (1)| 00:00:05 | | | Q1,02 | PCWP | |
| 79 | BUFFER SORT | | | | | | | | Q1,02 | PCWC | |
| 80 | PX RECEIVE | | | | | | | | Q1,02 | PCWP | |
| 81 | PX SEND BROADCAST | :TQ10000 | | | | | | | | S->P | BROADCAST |
| 82 | NESTED LOOPS | | | | | | | | | | |
| 83 | NESTED LOOPS | | 66 | 2838 | 382 (1)| 00:00:05 | | | | | |
| 84 | PARTITION RANGE SINGLE | | 66 | 1386 | 316 (1)| 00:00:04 | 7 | 7 | | | |
|* 85 | TABLE ACCESS FULL | J_OP_TEST_ANML | 66 | 1386 | 316 (1)| 00:00:04 | 7 | 7 | | | |
|* 86 | INDEX UNIQUE SCAN | FT_TEST_ID_PK | 1 | | 0 (0)| 00:00:01 | | | | | |
|* 87 | TABLE ACCESS BY GLOBAL INDEX ROWID | B_FP_TEST | 1 | 22 | 1 (0)| 00:00:01 | ROWID | ROWID | | | |
| 88 | PX BLOCK ITERATOR | | 70382 | 549K| 11 (0)| 00:00:01 | | | Q1,02 | PCWC | |
|* 89 | TABLE ACCESS FULL | J_FP_INVESTIGATOR | 70382 | 549K| 11 (0)| 00:00:01 | | | Q1,02 | PCWP | |
| 90 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 91 | PX RECEIVE | | 3 | 42 | 3 (0)| 00:00:01 | | | Q1,03 | PCWP | |
| 92 | PX SEND HASH | :TQ10001 | 3 | 42 | 3 (0)| 00:00:01 | | | | S->P | HASH |
|* 93 | TABLE ACCESS FULL | L_TEST_STATUS | 3 | 42 | 3 (0)| 00:00:01 | | | | | |
|* 94 | INDEX UNIQUE SCAN | L_ATMS_TEST_TYPE_PK | 1 | | 0 (0)| 00:00:01 | | | Q1,03 | PCWP | |
|* 95 | TABLE ACCESS BY INDEX ROWID | L_ATMS_TEST_TYPE | 1 | 5 | 1 (0)| 00:00:01 | | | Q1,03 | PCWP | |
Predicate Information (identified by operation id):
5 - access("B_FP_TEST"."TEST_TYPE_ID"="L_ATMS_TEST_TYPE"."ATMS_TEST_TYPE_ID")
8 - access("B_FP_TEST"."STATUS_ID"="L_TEST_STATUS"."STATUS_ID")
11 - access("B_FP_TEST"."TEST_ID"="J_FP_INVESTIGATOR"."TEST_ID")
18 - access("J_OP_TEST_ANML"."START_DATE">=TO_DATE(' 2013-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-05
00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
19 - access("J_OP_TEST_ANML"."TEST_ID"="B_FP_TEST"."TEST_ID")
20 - filter("B_FP_TEST"."DATASOURCE_ID"=9 AND "B_FP_TEST"."IS_DELETED"=0 AND "B_FP_TEST"."TEST_NUM"<>1 AND "B_FP_TEST"."TEST_NUM"<>2 AND
"B_FP_TEST"."TEST_NUM"<>99)
22 - filter("J_FP_INVESTIGATOR"."IS_PI"=1)
26 - filter("L_TEST_STATUS"."STATUS"='Completed' OR "L_TEST_STATUS"."STATUS"='In-Progress' OR "L_TEST_STATUS"."STATUS"='Scheduled')
30 - filter("L_ATMS_TEST_TYPE"."IS_DELETED"=0)
34 - access("B_FP_TEST"."STATUS_ID"="L_TEST_STATUS"."STATUS_ID")
38 - filter("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "J_OP_TEST_ANML"."END_DATE"<=TO_DATE(' 2013-11-05
00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND (LNNVL("J_OP_TEST_ANML"."START_DATE">=TO_DATE(' 2013-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR
LNNVL("J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-05 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))))
39 - access("J_OP_TEST_ANML"."TEST_ID"="B_FP_TEST"."TEST_ID")
40 - filter("B_FP_TEST"."DATASOURCE_ID"=9 AND "B_FP_TEST"."IS_DELETED"=0 AND "B_FP_TEST"."TEST_NUM"<>1 AND "B_FP_TEST"."TEST_NUM"<>2 AND
"B_FP_TEST"."TEST_NUM"<>99)
41 - filter("L_TEST_STATUS"."STATUS"='Completed' OR "L_TEST_STATUS"."STATUS"='In-Progress' OR "L_TEST_STATUS"."STATUS"='Scheduled')
42 - filter("J_FP_INVESTIGATOR"."IS_PI"=1)
43 - access("B_FP_TEST"."TEST_ID"="J_FP_INVESTIGATOR"."TEST_ID")
44 - access("B_FP_TEST"."TEST_TYPE_ID"="L_ATMS_TEST_TYPE"."ATMS_TEST_TYPE_ID")
45 - filter("L_ATMS_TEST_TYPE"."IS_DELETED"=0)
50 - access("B_FP_TEST"."STATUS_ID"="L_TEST_STATUS"."STATUS_ID")
53 - access("B_FP_TEST"."TEST_ID"="J_FP_INVESTIGATOR"."TEST_ID")
60 - filter("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-11-04 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-04
00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND (LNNVL("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR
LNNVL("J_OP_TEST_ANML"."END_DATE"<=TO_DATE(' 2013-11-05 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))) AND (LNNVL("J_OP_TEST_ANML"."START_DATE">=TO_DATE(' 2013-10-27
00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR LNNVL("J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-05 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))))
61 - access("J_OP_TEST_ANML"."TEST_ID"="B_FP_TEST"."TEST_ID")
62 - filter("B_FP_TEST"."DATASOURCE_ID"=9 AND "B_FP_TEST"."IS_DELETED"=0 AND "B_FP_TEST"."TEST_NUM"<>1 AND "B_FP_TEST"."TEST_NUM"<>2 AND
"B_FP_TEST"."TEST_NUM"<>99)
64 - filter("J_FP_INVESTIGATOR"."IS_PI"=1)
68 - filter("L_TEST_STATUS"."STATUS"='Completed' OR "L_TEST_STATUS"."STATUS"='In-Progress' OR "L_TEST_STATUS"."STATUS"='Scheduled')
69 - access("B_FP_TEST"."TEST_TYPE_ID"="L_ATMS_TEST_TYPE"."ATMS_TEST_TYPE_ID")
70 - filter("L_ATMS_TEST_TYPE"."IS_DELETED"=0)
75 - access("B_FP_TEST"."STATUS_ID"="L_TEST_STATUS"."STATUS_ID")
78 - access("B_FP_TEST"."TEST_ID"="J_FP_INVESTIGATOR"."TEST_ID")
85 - filter("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-10-28 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-10-28
00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND (LNNVL("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-11-04 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR
LNNVL("J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-04 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))) AND (LNNVL("J_OP_TEST_ANML"."END_DATE">=TO_DATE(' 2013-10-27
00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR LNNVL("J_OP_TEST_ANML"."END_DATE"<=TO_DATE(' 2013-11-05 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))) AND
(LNNVL("J_OP_TEST_ANML"."START_DATE">=TO_DATE(' 2013-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR LNNVL("J_OP_TEST_ANML"."START_DATE"<=TO_DATE(' 2013-11-05
00:00:00', 'syyyy-mm-dd hh24:mi:ss'))))
86 - access("J_OP_TEST_ANML"."TEST_ID"="B_FP_TEST"."TEST_ID")
87 - filter("B_FP_TEST"."DATASOURCE_ID"=9 AND "B_FP_TEST"."IS_DELETED"=0 AND "B_FP_TEST"."TEST_NUM"<>1 AND "B_FP_TEST"."TEST_NUM"<>2 AND
"B_FP_TEST"."TEST_NUM"<>99)
89 - filter("J_FP_INVESTIGATOR"."IS_PI"=1)
93 - filter("L_TEST_STATUS"."STATUS"='Completed' OR "L_TEST_STATUS"."STATUS"='In-Progress' OR "L_TEST_STATUS"."STATUS"='Scheduled')
94 - access("B_FP_TEST"."TEST_TYPE_ID"="L_ATMS_TEST_TYPE"."ATMS_TEST_TYPE_ID")
95 - filter("L_ATMS_TEST_TYPE"."IS_DELETED"=0)Excellent piece of follow-up on my first suggestion.
I nearly made a comment about how the plan doesn't show Bloom filter pruning either - and then I realised why not. The plan you've shown us comes from Explain Plan with literal values present; the trace file shows bind variables with names that are generated when cursor_sharing is set to force or similar - so the run-time plan and the plan from explain plan are almost guaranteed to be different.
Oracle support will need you to supply the plan you get from trying to run the query and then making a call to dbms_xplan.display_cursor() - dbms_xplan in 10g | Oracle Scratchpad If you do this I think you'll find that the pstart/pstop columns contain entries like :BF0000, and you may even find operations link PX JOIN FILTER CREATE / PX JOIN FILTER USE
A couple of generic notes:
if a query does sufficient work to merit parallel execution, then it's usually better to supply the best possible information to the optimizer, which means using literals rather than bind variables - you could try executing the query with the hint /*+ cursor_sharing_exact */ to stop Oracle from turning your literals into binds; it might be the presence of bind variables that's making the optimizer choose a path that has to include bloom filter pruning in your case.
Where you have the to_date() call you've used a four-digit year - which is a very good thing and helps the optimizer - but it's also a good idea to include an explicit format string as well: with a four-digit year this probably won't make any difference, but it avoids any risk of ambiguity for the optimizer.
I made a comment about the P->S stage and bottlenecks - I spent a couple more minutes looking at the plan, and I see the optimizer has used concatentation: in effect it has run three query blocks one after the other and fed the results to the query co-ordinator - in this case the P->S would make no difference to the end-user response time there's always a final P->S to the coordinator, you just happen to have three of them.
Regards
Jonathan Lewis -
Performance Problem in Select query
Hi,
I have performance Problem in following Select Query :
SELECT VBELN POSNR LFIMG VRKME VGBEL VGPOS
FROM LIPS INTO CORRESPONDING FIELDS OF TABLE GT_LIPS
FOR ALL ENTRIES IN GT_EKPO1
WHERE VGBEL = GT_EKPO1-EBELN
AND VGPOS = GT_EKPO1-EBELP.
as per trace i have analysed that it is fetch the complete table scan from the LIPS table and table contants almost 3 lakh records.
Kindly Suggest what we can do to optimize this query.
Regards,
Harshtypes: begin of line,
vbeln type lips-vbeln
posnr type lips-posnr
lfimg type lips-lfimg
vrkme type lips-vrkme
vgbel type lips- vgbel
vgpos type lips-vgpos
end of line.
data: itab type standard table of line,
wa type line.
IF GT_EKPO1[] IS NOT INITIAL.
SELECT VBELN POSNR LFIMG VRKME VGBEL VGPOS
FROM LIPS INTO TABLE ITAB
FOR ALL ENTRIES IN GT_EKPO1
WHERE VGBEL = GT_EKPO1-EBELN
AND VGPOS = GT_EKPO1-EBELP.
ENDIF. -
Select query with secondary index
hi,
i have a report which is giving performance issues on a perticular select query on KONH table.
the select query doesnt use the primary key fields and table already has around 19 million entries.So there was a secondary index created for the fields in the table.
now, KONH is a client specific table, and hence has MANDT as the first field. when the table is not indexed it is sorted according to the order of fields, like first MANDT, then primary key fields and then remaining fields.. (correct me if i am wrong)
but the secondary index created doesnt has MANDT in it..(yea, a mistake! )...
but instead of correccting the secondary index, i am told to change the select query..
so, i used a "client specific" syntax to sort the issue.. but i dont understand whre i should put the "where mandt eq sy-mandt" clause..
should i put it right after all my secondary index fields are over? or what happens to the order of fields which are not present in the list of secondary index?
kindaly help.
thanx.Hi chinmay kulkarni,
its better if you can ask concerned person to add MANDT field in your index as well....
Indexes and MANDT
If a table begins with the mandt field, so should its indexes. If a table begins with mandt and an index doesn't, the optimizer might not use the index.
Remember, if you will, Open SQL's automatic client handling feature. When select * from ztxlfa1 where land1 = 'US' is executed, the actual SQL sent to the database is select * from ztxlfa1 where mandt = sy-mandt and land1 = 'US'. Sy-mandt contains the current logon client. When you select rows from a table using Open SQL, the system automatically adds sy-mandt to the where clause, which causes only those rows pertaining to the current logon client to be found.
When you create an index on a table containing mandt, therefore, you should also include mandt in the index. It should come first in the index, because it will always appear first in the generated SQL.
Index: Technical key of a database table.
Primary index: The primary index contains the key fields of the table and a pointer to the non-key fields of the table. The primary index is created automatically when the table is created in the database.
Secondary index: Additional indexes could be created considering the most frequently accessed dimensions of the table.
Structure of an Index
An index can be used to speed up the selection of data records from a table.
An index can be considered to be a copy of a database table reduced to certain fields. The data is stored in sorted form in this copy. This sorting permits fast access to the records of the table (for example using a binary search). Not all of the fields of the table are contained in the index. The index also contains a pointer from the index entry to the corresponding table entry to permit all the field contents to be read.
When creating indexes, please note that:
An index can only be used up to the last specified field in the selection! The fields which are specified in the WHERE clause for a large number of selections should be in the first position.
Only those fields whose values significantly restrict the amount of data are meaningful in an index.
When you change a data record of a table, you must adjust the index sorting. Tables whose contents are frequently changed therefore should not have too many indexes.
Make sure that the indexes on a table are as disjunctive as possible.
(That is they should contain as few fields in common as possible. If two indexes on a table have a large number of common fields, this could make it more difficult for the optimizer to choose the most selective index.)
For Example...
SELECT KUNNR KUNN2 INTO TABLE T_CUST_TERR
FROM KNVP CLIENT SPECIFIED
WHERE MANDT = SY-MANDT " here MANDT shd be first
AND KUNN2 IN S_TERR
AND PARVW LIKE 'Z%'.
Accessing tables using Indexes
The database optimizer decides which index on the table should be used by the database to access data records.
You must distinguish between the primary index and secondary indexes of a table. The primary index contains the key fields of the table. The primary index is automatically created in the database when the table is activated. If a large table is frequently accessed such that it is not possible to apply primary index sorting, you should create secondary indexes for the table.
The indexes on a table have a three-character index ID. '0' is reserved for the primary index. Customers can create their own indexes on SAP tables; their IDs must begin with Y or Z.
If the index fields have key function, i.e. they already uniquely identify each record of the table, an index can be called a unique index. This ensures that there are no duplicate index fields in the database.
When you define a secondary index in the ABAP Dictionary, you can specify whether it should be created on the database when it is activated. Some indexes only result in a gain in performance for certain database systems. You can therefore specify a list of database systems when you define an index. The index is then only created on the specified database systems when activated
Also pls have a look on below link
http://www.sapfans.com/sapfans/forum/devel/messages/30240.html
Hope it will solve your problem..
Reward points if useful...
Thanks & Regards
ilesh 24x7 -
Select query performance improvement - Index on EDIDC table
Hi Experts,
I have a scenario where in I have to select data from the table EDIDC. The select query being used is given below.
SELECT docnum
direct
mestyp
mescod
rcvprn
sndprn
upddat
updtim
INTO CORRESPONDING FIELDS OF TABLE t_edidc
FROM edidc
FOR ALL ENTRIES IN t_error_idoc
WHERE
upddat GE gv_date1 AND
upddat LE gv_date2 AND
updtim GE p_time AND
status EQ t_error_idoc-status.
As the volume of the data is very high, our client requested to put up some index or use an existing one to improve the performance of the data selection query.
Question:
4. How do we identify the index to be used.
5. On which fields should the indexing be done to improve the performance (if available indexes donu2019t cater to our case).
6. What will be the impact on the table performance if we create a new index.
Regards ,
RaghavQuestion:
1. How do we identify the index to be used.
Generally the index is automatically selected by SAP (DB Optimizer ) ( You can still mention the index name in your select query by changing the syntax)
For your select Query the second Index will be called automatically by the Optimizer, ( Because the select query has u2018Updatu2019 , u2018uptimu2019 in the sequence before the u2018statusu2019 ) .
2. On which fields should the indexing be done to improve the performance (if available indexes donu2019t cater to our case).
(Create a new Index with MANDT and the 4 fields which are in the where clause in sequence )
3. What will be the impact on the table performance if we create a new index.
( Since the index which will be newly created is only the 4th index for the table, there shouldnu2019t be any side affects)
After creation of index , Check the change in performance of the current program and also some other programs which are having the select queries on EDIDC ( Various types of where clauses preferably ) to verify that the newly created index is not having the negative impact on the performance. Additionally, if possible , check if you can avoid into corresponding fields .
Regards ,
Seth -
Select Query failing on a table that has per sec heavy insertions.
Hi
Problem statement
1- We are using 11g as an database.
2- We have a table that is partitioned on the date as range partition.
3- The insertion of data is very high.i.e. several hundreds records per sec. in the current partitioned.
4- The data is continuously going in the current partitioned as and when buffer is full or per sec timer expires.
5-- We have to make also select query on the same table and on the current partitioned say for the latest 500 records.
6- Effecient indexes are also created on the table.
Solutions Tried.
1- After analyzing by tkprof it is observed that select and execute is working fine but fetch is taking too much time to show the out put. Say it takes 1 hour.
2- Using the 11g sql advisior and SPM several baseline is created but the success rate of them is observed also too low.
please suggest any solution to this issue
1- i.e. Redisgn of table.
2- Any better way to quey to fix the fetch issue.
3- Any oracle seetings or parameter changes to fix the fetch issue.
Thanks in advance.
Regards
Vishal SharmaI am uploading the latest stats please let me know how can improve as this is taking 25 minutes
####TKPROF output#########
SQL ID : 2j5w6bv437cak
select almevttbl.AlmEvtId, almevttbl.AlmType, almevttbl.ComponentId,
almevttbl.TimeStamp, almevttbl.Severity, almevttbl.State,
almevttbl.Category, almevttbl.CauseCode, almevttbl.UnitType,
almevttbl.UnitId, almevttbl.UnitName, almevttbl.ServerName,
almevttbl.StrParam, almevttbl.ExtraStrParam, almevttbl.ExtraStrParam2,
almevttbl.ExtraStrParam3, almevttbl.ParentCustId, almevttbl.ExtraParam1,
almevttbl.ExtraParam2, almevttbl.ExtraParam3,almevttbl.ExtraParam4,
almevttbl.ExtraParam5, almevttbl.SRCIPADDRFAMILY,almevttbl.SrcIPAddress11,
almevttbl.SrcIPAddress12,almevttbl.SrcIPAddress13,almevttbl.SrcIPAddress14,
almevttbl.DESTIPADDRFAMILY,almevttbl.DestIPAddress11,
almevttbl.DestIPAddress12,almevttbl.DestIPAddress13,
almevttbl.DestIPAddress14, almevttbl.DestPort, almevttbl.SrcPort,
almevttbl.SessionDir, almevttbl.CustomerId, almevttbl.ProfileId,
almevttbl.ParentProfileId, almevttbl.CustomerName, almevttbl.AttkDir,
almevttbl.SubCategory, almevttbl.RiskCategory, almevttbl.AssetValue,
almevttbl.IPSAction, almevttbl.l4Protocol,almevttbl.ExtraStrParam4 ,
almevttbl.ExtraStrParam5,almevttbl.username,almevttbl.ExtraStrParam6,
IpAddrFamily1,IPAddrValue11,IPAddrValue12,IPAddrValue13,IPAddrValue14,
IpAddrFamily2,IPAddrValue21,IPAddrValue22,IPAddrValue23,IPAddrValue24
FROM
AlmEvtTbl PARTITION(ALMEVTTBLP20100323) WHERE AlmEvtId IN ( SELECT * FROM
( SELECT /*+ FIRST_ROWS(1000) INDEX (AlmEvtTbl AlmEvtTbl_Index) */AlmEvtId
FROM AlmEvtTbl PARTITION(ALMEVTTBLP20100323) where ((AlmEvtTbl.Customerid
= 0 or AlmEvtTbl.ParentCustId = 0)) ORDER BY AlmEvtTbl.TIMESTAMP DESC)
WHERE ROWNUM < 602) order by timestamp desc
call count cpu elapsed disk query current rows
Parse 1 0.10 0.17 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 42 1348.25 1521.24 1956 39029545 0 601
total 44 1348.35 1521.41 1956 39029545 0 601
Misses in library cache during parse: 1
Optimizer mode: FIRST_ROWS
Parsing user id: 82
Rows Row Source Operation
601 PARTITION RANGE SINGLE PARTITION: 24 24 (cr=39029545 pr=1956 pw=1956 time=11043 us cost=0 size=7426 card=1)
601 TABLE ACCESS BY LOCAL INDEX ROWID ALMEVTTBL PARTITION: 24 24 (cr=39029545 pr=1956 pw=1956 time=11030 us cost=0 size=7426 card=1)
601 INDEX FULL SCAN ALMEVTTBL_INDEX PARTITION: 24 24 (cr=39029377 pr=1956 pw=1956 time=11183 us cost=0 size=0 card=1)(object id 72557)
601 FILTER (cr=39027139 pr=0 pw=0 time=0 us)
169965204 COUNT STOPKEY (cr=39027139 pr=0 pw=0 time=24859073 us)
169965204 VIEW (cr=39027139 pr=0 pw=0 time=17070717 us cost=0 size=13 card=1)
169965204 PARTITION RANGE SINGLE PARTITION: 24 24 (cr=39027139 pr=0 pw=0 time=13527031 us cost=0 size=48 card=1)
169965204 TABLE ACCESS BY LOCAL INDEX ROWID ALMEVTTBL PARTITION: 24 24 (cr=39027139 pr=0 pw=0 time=10299895 us cost=0 size=48 card=1)
169965204 INDEX FULL SCAN ALMEVTTBL_INDEX PARTITION: 24 24 (cr=1131414 pr=0 pw=0 time=3222624 us cost=0 size=0 card=1)(object id 72557)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 42 0.00 0.00
SQL*Net message from client 42 11.54 133.54
db file sequential read 1956 0.20 28.00
latch free 21 0.00 0.01
latch: cache buffers chains 9 0.01 0.02
SQL ID : 0ushr863b7z39
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE
NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false')
NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),0), NVL(SUM(C2),0)
FROM
(SELECT /*+ IGNORE_WHERE_CLAUSE NO_PARALLEL("PLAN_TABLE") FULL("PLAN_TABLE")
NO_PARALLEL_INDEX("PLAN_TABLE") */ 1 AS C1, CASE WHEN
"PLAN_TABLE"."STATEMENT_ID"=:B1 THEN 1 ELSE 0 END AS C2 FROM
"SYS"."PLAN_TABLE$" "PLAN_TABLE") SAMPLESUB
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 0.00 0.01 1 3 0 1
total 3 0.00 0.01 1 3 0 1
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 82 (recursive depth: 1)
Rows Row Source Operation
1 SORT AGGREGATE (cr=3 pr=1 pw=1 time=0 us)
0 TABLE ACCESS FULL PLAN_TABLE$ (cr=3 pr=1 pw=1 time=0 us cost=29 size=138856 card=8168)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 1 0.01 0.01
SQL ID : bjkdb51at8dnb
EXPLAIN PLAN SET STATEMENT_ID='PLUS30350011' FOR select almevttbl.AlmEvtId,
almevttbl.AlmType, almevttbl.ComponentId, almevttbl.TimeStamp,
almevttbl.Severity, almevttbl.State, almevttbl.Category,
almevttbl.CauseCode, almevttbl.UnitType, almevttbl.UnitId,
almevttbl.UnitName, almevttbl.ServerName, almevttbl.StrParam,
almevttbl.ExtraStrParam, almevttbl.ExtraStrParam2, almevttbl.ExtraStrParam3,
almevttbl.ParentCustId, almevttbl.ExtraParam1, almevttbl.ExtraParam2,
almevttbl.ExtraParam3,almevttbl.ExtraParam4,almevttbl.ExtraParam5,
almevttbl.SRCIPADDRFAMILY,almevttbl.SrcIPAddress11,almevttbl.SrcIPAddress12,
almevttbl.SrcIPAddress13,almevttbl.SrcIPAddress14,
almevttbl.DESTIPADDRFAMILY,almevttbl.DestIPAddress11,
almevttbl.DestIPAddress12,almevttbl.DestIPAddress13,
almevttbl.DestIPAddress14, almevttbl.DestPort, almevttbl.SrcPort,
almevttbl.SessionDir, almevttbl.CustomerId, almevttbl.ProfileId,
almevttbl.ParentProfileId, almevttbl.CustomerName, almevttbl.AttkDir,
almevttbl.SubCategory, almevttbl.RiskCategory, almevttbl.AssetValue,
almevttbl.IPSAction, almevttbl.l4Protocol,almevttbl.ExtraStrParam4 ,
almevttbl.ExtraStrParam5,almevttbl.username,almevttbl.ExtraStrParam6,
IpAddrFamily1,IPAddrValue11,IPAddrValue12,IPAddrValue13,IPAddrValue14,
IpAddrFamily2,IPAddrValue21,IPAddrValue22,IPAddrValue23,IPAddrValue24 FROM
AlmEvtTbl PARTITION(ALMEVTTBLP20100323) WHERE AlmEvtId IN ( SELECT * FROM
( SELECT /*+ FIRST_ROWS(1000) INDEX (AlmEvtTbl AlmEvtTbl_Index) */AlmEvtId
FROM AlmEvtTbl PARTITION(ALMEVTTBLP20100323) where ((AlmEvtTbl.Customerid
= 0 or AlmEvtTbl.ParentCustId = 0)) ORDER BY AlmEvtTbl.TIMESTAMP DESC)
WHERE ROWNUM < 602) order by timestamp desc
call count cpu elapsed disk query current rows
Parse 1 0.28 0.26 0 0 0 0
Execute 1 0.01 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.29 0.27 0 0 0 0
Misses in library cache during parse: 1
Optimizer mode: FIRST_ROWS
Parsing user id: 82
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 0.00 0.00
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 13 0.71 0.96 3 10 0 0
Execute 14 0.20 0.29 4 304 26 21
Fetch 92 2402.17 2714.85 3819 70033708 0 1255
total 119 2403.09 2716.10 3826 70034022 26 1276
Misses in library cache during parse: 10
Misses in library cache during execute: 6
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 49 0.00 0.00
SQL*Net message from client 48 29.88 163.43
db file sequential read 1966 0.20 28.10
latch free 21 0.00 0.01
latch: cache buffers chains 9 0.01 0.02
latch: session allocation 1 0.00 0.00
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 940 0.51 0.73 1 2 38 0
Execute 3263 1.93 2.62 7 1998 43 23
Fetch 6049 1.32 4.41 214 12858 36 13724
total 10252 3.78 7.77 222 14858 117 13747
Misses in library cache during parse: 172
Misses in library cache during execute: 168
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 88 0.04 0.62
latch: shared pool 8 0.00 0.00
latch: row cache objects 2 0.00 0.00
latch free 1 0.00 0.00
latch: session allocation 1 0.00 0.00
34 user SQL statements in session.
3125 internal SQL statements in session.
3159 SQL statements in session.
Trace file: ora11g_ora_2064.trc
Trace file compatibility: 11.01.00
Sort options: default
6 sessions in tracefile.
98 user SQL statements in trace file.
9111 internal SQL statements in trace file.
3159 SQL statements in trace file.
89 unique SQL statements in trace file.
30341 lines in trace file.
6810 elapsed seconds in trace file.
###################################### AutoTrace Output#################
Statistics
3901 recursive calls
0 db block gets
39030275 consistent gets
1970 physical reads
140 redo size
148739 bytes sent via SQL*Net to client
860 bytes received via SQL*Net from client
42 SQL*Net roundtrips to/from client
73 sorts (memory)
0 sorts (disk)
601 rows processed -
Select query in routing(operation,sequence)
Hello frds,
i am into change routing BDC actually i want a select query .....for like existing of operation for a particular sequence in routing....
if i will found operation for particular sequence i will run the bdc code lese i will exit...any one can help me...
just provide me a query....to check existnece of operation for a particular sequence......ASAP...Why on earth would you want to keep the queries separate? As Tom Kyte would say, databases are born to join!
Providing emp_id has an index on it (and it should, assuming it's the table's primary key!) your "complex" (or, what I would call simple*), it'll most likely be faster than doing it separately. You've not got the context switches for one thing.
If you want to see what the optimizer does with your query, you should run a trace on the query. An explain plan would give you an idea of what it's going to do, too.
In general, doing something like this procedurally is going to almost certainly be worse than doing it in SQL (and by worse, I mean slower).
* I'd hate to see what you'd call some of the monster queries I work with, if you think that query is complex! -
Secondary Index Picked with one field short in select query
Hi,
We have a select query as follows
select single lgort vgbel vgpos
into (lips-lgort,lips-vgbel,lips-vgpos)
from lips
where vbeln Eq p_zlcpp-vbeln
and matnr Eq p_zlcpp-matnr
and charg Eq p_zlcpp-charg
The secondary index ZB has the fields as follows:
MANDT Client
MATNR Material Number
CHARG Batch Number
BWART Movement Type (Inventory Management)
When seen in the trace it seems the select query picks this secondary index. Whether it is correct? since i find no BWART in the select query. Because of this index the query take large time. I used the Hint statement as follows:
select single lgort vgbel vgpos
into (lips-lgort,lips-vgbel,lips-vgpos)
from lips
where vbeln Eq p_zlcpp-vbeln
and matnr Eq p_zlcpp-matnr
and charg Eq p_zlcpp-charg %_HINTS ORACLE 'INDEX("LIPS" "LIPS~0")' .
and it now works fast. Please advice the best way to make the select query work on itself without using the hint statement to pick the index LIPS~0 instead of the invalid secondary index ZB.
Thanks & Regards,
Selvakumar M.
Edited by: Selva on Jun 17, 2011 7:35 PMHello Selva,
your problem here is the decision of the optimizer that does not exactly know the selectivity of the fields.
If your deliveries are normally small (not too many items), then selecting via the document number will be relatively fast.
And selecting via the material number + batch will be slow in case if many deliveries are having same product from the same batch delivered.
I assume that the latest is the case in your system. That's why the selection with ZB index is slow.
If the data distribution is as I described above, then your hint is quite OK and I advise you to stick to the hint.
From my PoV this is the better solution rather changing the coding and throwing out MATNR field from the WHERE clause to filter later in ABAP.
Another solution would be trying to play with histograms. But you'll need %SUBSTITUTE VALUES% or %SUBSTITUTE LITERALS% hint anyway, so I find your solution better.
So, please stay with hint. Even SAP standard development does it for some select statements.
Regards,
Yuri
Maybe you are looking for
-
Hi, i want to connect to a SAP Portal Webservice with a widget, after i used the SAP Widget Foundation to execute some RFC calls. I wonder if there is a possiblitity to get the mysapsoo2 ticket from the SAP RFC response, which i can use than for con
-
Unit prie column disabled while doing miscellaneous issue.
Hi, I'm doing miscellaneous issue on an item. but while doing the entry, the unit price column is disabled from entering the value. What could have gone wrong? But for some items the field was enabled to enter the unit price value. Both the items are
-
Clustering in EP SP4 Sneak Preview
Hi Portal Gurus, Can we install a clustering setup in EP SP4 Sneak preview. Regardless,can anyone pls send me some "How To"s related to clustering e.g. configuring cluster id,fail safe etc. I would reward good points for your help. Thanks. Harsha
-
Imported Pic Blurs halfway through Clip - How do I fix this?
For some time now I have been able to import a rather long .png clip, generated in Photoshop, as a background for my news and events stories. I scroll the background bottom to top and new items 'pop' out as I chat about them. (See http://cdn.traint
-
Executing /usr/bin/mail From Within Daemon
I've created a script that, among other things, sends an email to an external email address and it works fine from the command line. When the same script is run periodically from within a daemon (i.e. launchctl), the email functionality of the scrip