Select Query taking long time to run second time
Hi All,
I have Oracle 11gR1 in windows server 2008 R2 .
I have some tables with 10 million records . When i run the select query for those tables first time it gives me result in 15 seconds but if i am running the same script second time from the same session I am getting the result in 15 minutes to complete ..
Why it is happening? What may be the solution for this ?
Thanks & Regards,
Vikash jain(Junior DBA)
Hi Mohamed,
I just saw that both the times for the same query execution plan is different ..
here are the details :
First time Second Time
g84m3qqjv2p3q g84m3qqjv2p3q
2733045235 1310485984
So plz tell me how should i force database to use the first execution plan ?
I got this script for forcing the Db to use the same execution plan
accept sql_id -
prompt 'Enter value for sql_id: ' -
default 'X0X0X0X0'
accept plan_hash_value -
prompt 'Enter value for plan_hash_value: ' -
default 'X0X0X0X0'
accept fixed -
prompt 'Enter value for fixed (NO): ' -
default 'NO'
accept enabled -
prompt 'Enter value for enabled (YES): ' -
default 'YES'
accept plan_name -
prompt 'Enter value for plan_name (ID_sqlid_planhashvalue): ' -
default 'X0X0X0X0'
set feedback off
set sqlblanklines on
set serveroutput on
declare
l_plan_name varchar2(40);
l_old_plan_name varchar2(40);
l_sql_handle varchar2(40);
ret binary_integer;
l_sql_id varchar2(13);
l_plan_hash_value number;
l_fixed varchar2(3);
l_enabled varchar2(3);
major_release varchar2(3);
minor_release varchar2(3);
begin
select regexp_replace(version,'\..*'), regexp_substr(version,'[0-9]+',1,2) into major_release, minor_release from v$instance;
minor_release := 2;
l_sql_id := '&&sql_id';
l_plan_hash_value := to_number('&&plan_hash_value');
l_fixed := '&&fixed';
l_enabled := '&&enabled';
ret := dbms_spm.load_plans_from_cursor_cache(
sql_id=>l_sql_id,
plan_hash_value=>l_plan_hash_value,
fixed=>l_fixed,
enabled=>l_enabled);
if minor_release = '1' then
-- 11gR1 has a bug that prevents renaming Baselines
dbms_output.put_line(' ');
dbms_output.put_line('Baseline created.');
dbms_output.put_line(' ');
else
-- This statements looks for Baselines create in the last 4 seconds
select sql_handle, plan_name,
decode('&&plan_name','X0X0X0X0','SQLID_'||'&&sql_id'||'_'||'&&plan_hash_value','&&plan_name')
into l_sql_handle, l_old_plan_name, l_plan_name
from dba_sql_plan_baselines spb
where created > sysdate-(1/24/60/15);
ret := dbms_spm.alter_sql_plan_baseline(
sql_handle=>l_sql_handle,
plan_name=>l_old_plan_name,
attribute_name=>'PLAN_NAME',
attribute_value=>l_plan_name);
dbms_output.put_line(' ');
dbms_output.put_line('Baseline '||upper(l_plan_name)||' created.');
dbms_output.put_line(' ');
end if;
end;
undef sql_id
undef plan_hash_value
undef plan_name
undef fixed
set feedback on
Output:
Enter value for sql_id: g84m3qqjv2p3q
Enter value for plan_hash_value: 2733045235
Enter value for fixed (NO):
Enter value for enabled (YES):
Enter value for plan_name (ID_sqlid_planhashvalue): g84m3qqjv2p3q
old 16: l_sql_id := '&&sql_id';
new 16: l_sql_id := 'g84m3qqjv2p3q';
old 17: l_plan_hash_value := to_number('&&plan_hash_value');
new 17: l_plan_hash_value := to_number('2733045235');
old 18: l_fixed := '&&fixed';
new 18: l_fixed := 'NO';
old 19: l_enabled := '&&enabled';
new 19: l_enabled := 'YES';
old 40: decode('&&plan_name','X0X0X0X0','SQLID_'||'&&sql_id'||'_'||'&&plan_hash_value','&&plan_name')
new 40: decode('g84m3qqjv2p3q','X0X0X0X0','SQLID_'||'g84m3qqjv2p3q'||'_'||'2733045235','g84m3qqjv2p3q')
declare
ERROR at line 1:
ORA-01403: no data found
ORA-06512: at line 39
Kindly help me to resolve the issue ..
Thanks & Regards,
Vikash Jain(Junior DBA)
Similar Messages
-
Query taking longer to execute the second time.
Hello,
I have a query joing few tables and views and when i execute it the first them, it executes within a seconds, immediately if i execute it the second time it takes about 40 seconds to execute. I am using Oracle 11g [11.2.0.1.0].
Please find the TKPROF output.
call count cpu elapsed disk query current rows
Parse 1 0.26 0.24 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 23 0.81 0.82 0 5610 0 326
total 25 1.07 1.07 0 5610 0 326
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 127
call count cpu elapsed disk query current rows
Parse 1 0.23 0.23 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 23 41.01 41.00 0 38218 0 326
total 25 41.24 41.24 0 38218 0 326
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 127Hi Nicholay,
VPD is not being used in our application. ArcSDE Multi-Versionsed View uses some functions in VW_ objects. In Oracle 10g I dont have this issue.
Here is the output from V$SQL_SHARED_CURSOR.
"SQL_ID" "ADDRESS" "CHILD_ADDRESS" "CHILD_NUMBER" "UNBOUND_CURSOR" "SQL_TYPE_MISMATCH" "OPTIMIZER_MISMATCH" "OUTLINE_MISMATCH" "STATS_ROW_MISMATCH" "LITERAL_MISMATCH" "FORCE_HARD_PARSE" "EXPLAIN_PLAN_CURSOR" "BUFFERED_DML_MISMATCH" "PDML_ENV_MISMATCH" "INST_DRTLD_MISMATCH" "SLAVE_QC_MISMATCH" "TYPECHECK_MISMATCH" "AUTH_CHECK_MISMATCH" "BIND_MISMATCH" "DESCRIBE_MISMATCH" "LANGUAGE_MISMATCH" "TRANSLATION_MISMATCH" "BIND_EQUIV_FAILURE" "INSUFF_PRIVS" "INSUFF_PRIVS_REM" "REMOTE_TRANS_MISMATCH" "LOGMINER_SESSION_MISMATCH" "INCOMP_LTRL_MISMATCH" "OVERLAP_TIME_MISMATCH" "EDITION_MISMATCH" "MV_QUERY_GEN_MISMATCH" "USER_BIND_PEEK_MISMATCH" "TYPCHK_DEP_MISMATCH" "NO_TRIGGER_MISMATCH" "FLASHBACK_CURSOR" "ANYDATA_TRANSFORMATION" "INCOMPLETE_CURSOR" "TOP_LEVEL_RPI_CURSOR" "DIFFERENT_LONG_LENGTH" "LOGICAL_STANDBY_APPLY" "DIFF_CALL_DURN" "BIND_UACS_DIFF" "PLSQL_CMP_SWITCHS_DIFF" "CURSOR_PARTS_MISMATCH" "STB_OBJECT_MISMATCH" "CROSSEDITION_TRIGGER_MISMATCH""PQ_SLAVE_MISMATCH" "TOP_LEVEL_DDL_MISMATCH" "MULTI_PX_MISMATCH" "BIND_PEEKED_PQ_MISMATCH" "MV_REWRITE_MISMATCH" "ROLL_INVALID_MISMATCH" "OPTIMIZER_MODE_MISMATCH" "PX_MISMATCH" "MV_STALEOBJ_MISMATCH" "FLASHBACK_TABLE_MISMATCH" "LITREP_COMP_MISMATCH" "PLSQL_DEBUG" "LOAD_OPTIMIZER_STATS" "ACL_MISMATCH" "FLASHBACK_ARCHIVE_MISMATCH" "LOCK_USER_SCHEMA_FAILED" "REMOTE_MAPPING_MISMATCH" "LOAD_RUNTIME_HEAP_FAILED" "HASH_MATCH_FAILED" "PURGED_CURSOR" "BIND_LENGTH_UPGRADEABLE"
"7rtqvjtyp06k9" "000007FFABD3A918" "000007FFABD49C88" "1" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N"
"7rtqvjtyp06k9" "000007FFABD3A918" "000007FFABD3A7B8" "0" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N"
"7rtqvjtyp06k9" "000007FFABD3A918" "000007FFABD46A40" "2" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N"
"7rtqvjtyp06k9" "000007FFABD3A918" "000007FFABD3A7B8" "0" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N"
"7rtqvjtyp06k9" "000007FFABD3A918" "000007FFABD49C88" "1" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N"
"7rtqvjtyp06k9" "000007FFABD3A918" "000007FFABD46A40" "2" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N"
"7rtqvjtyp06k9" "000007FFABD3A918" "000007FFABD3A7B8" "0" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N"
"7rtqvjtyp06k9" "000007FFABD3A918" "000007FFABD49C88" "1" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N"
"7rtqvjtyp06k9" "000007FFABD3A918" "000007FFABD46A40" "2" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" "N" Edited by: 955237 on 29 Aug, 2012 1:57 AM -
Hi All,
I am trying to run one SELECT statement which uses 6 tables. That query generally take 25-30 minutes to generate output.
Today it is running from more than 2 hours. I have checked there are no locks on those tables and no other process is using them.
What else I should check in order to figure out why my SELECT statement is taking time?
Any help will be much appreciated.
Thanks!Please let me know if you still want me to provide all the information mentioned in the link.Yes, please.
Before you can even start optimizing, it should be clear what parts of the query are running slow.
The links contains the steps to take regarding how to identify the things that make the query run slow.
Ideally you post a trace/tkprof report with wait events, it'll show on what time is being spent, give an execution plan and a database version all in once...
Today it is running from more than 2 hours. I have checked there are no locks on those tables and no other process is using them.Well, something must have changed.
And you must indentify what exactly has changed, but it's a broad range you have to check:
- it could be outdated table statistics
- it could be data growth or skewness that makes Optimizer choose a wrong plan all of a sudden
- it could be a table that got modified with some bad index
- it could be ...
So, by posting the information in the link, you'll leave less room for guesses from us, so you'll get an explanation that makes sense faster or, while investigating by following the steps in the link, you'll get the explanation yourself. -
Select query taking long time (more then 6 min)
Dear experts,
DATA:IT_CHEQ2 TYPE TABLE OF TY_BSAS,
WA_CHEQ2 LIKE LINE OF IT_CHEQ2.
DATA : IT_CHEQ3 TYPE STANDARD TABLE OF TY_BSAS WITH HEADER LINE.
TYPES:BEGIN OF TY_BSAS,
BUKRS TYPE BSAS-BUKRS,
HKONT TYPE BSAS-HKONT,
AUGDT TYPE BSAS-AUGDT,
AUGBL TYPE BSAK-AUGBL,
ZUONR TYPE BSAK-ZUONR,
GJAHR TYPE BSAK-GJAHR,
BELNR TYPE BSAK-BELNR,
BUZEI TYPE BSAK-BUZEI,
BUDAT TYPE BSAK-BUDAT,
XBLNR TYPE BSAK-XBLNR,
BLART TYPE BSAK-BLART,
SHKZG TYPE BSAK-SHKZG,
DMBTR TYPE BSAK-DMBTR,
WMWST TYPE BSAK-WMWST,
AUGGJ TYPE BSAK-AUGGJ, " CLEARING FYSICAL YEAR
OT_TAX TYPE BSAK-DMBTR,
TDS TYPE BSAK-DMBTR,
VAT TYPE BSAK-DMBTR, "Vat amount
WCT TYPE BSAK-DMBTR,
ADV TYPE BSAK-DMBTR, "Advance
CHAMT TYPE BSAK-DMBTR,
CHNO TYPE PAYR-CHECT,
CHDATE TYPE PAYR-ZALDT,
DBIT_NOTE TYPE BSAK-DMBTR,
PAY_ADJ TYPE BSAK-DMBTR,
PEND_SES TYPE BSAK-DMBTR, "PENDING SES
CR_PARTY(50) TYPE C,
END OF TY_BSAS.
SELECT BUKRS HKONT AUGDT AUGBL ZUONR GJAHR BELNR BUZEI BUDAT XBLNR BLART SHKZG
DMBTR WMWST
FROM BSAS INTO " APPENDING
CORRESPONDING FIELDS OF TABLE IT_CHEQ3
FOR ALL ENTRIES IN IT_CHEQ2
WHERE AUGBL = IT_CHEQ2-AUGBL and
BUKRS = IT_CHEQ2-BUKRS AND
* AUGBL = IT_CHEQ2-AUGBL
GJAHR = IT_CHEQ2-GJAHR
AND XBLNR = IT_CHEQ2-XBLNR.
line company code hkont augdt augbl zuonr gjahr belnr buzei budat
1 1018 0012100030 20110831 2100009710 20110831 2011 2100009710 005 20110831
xblnr blart shkzg
RA03 KZ H 37067.00 0.00 2011 0.00 0.00
2 1018 0012100030 20110831 2100009710 20110831 2011 2100009710 006 20110831
RA03 KZ H 393850.00 0.00 2011 0.00 0.00
3 1018 0012100030 20110831 2100009710 20110831 2011 2100009710 004 20110831 RA03 KZ S 723589.13 0.00 2011 0.00 0.00
4 1018 0012100030 20110831 2100009710 20110823 2011 3900001250 001 20110823 RA03 RS H 712921.13 0.00 2011 0.00 0.00
5 1018 0023200000 20110831 2100009710 20110831 2011 2100009710 008 20110831 RA03 KZ H 21788.00 0.00 2011 0.00 0.00
6 1018 0023200000 20110831 2100009710 20110831 2011 2100009710 007 20110831 RA03 KZ H 1162821.00 0.00 2011 0.00 0.00
if i put same entry in se11 for bsas it takes 7 second
and in query takes more then 6 min ,kindly tell why
help me gurus
regards
victorTested point 2.
There is no difference.
REPORT Z_YZ_SELECT_ORDER.
types: begin of t_orderadm,
description type CRMT_PROCESS_DESCRIPTION,
created_at type COMT_CREATED_AT_USR,
LOGICAL_SYSTEM type CRMT_LOGSYS,
TEMPLATE_TYPE type CRMT_TEMPLATE_TYPE_DB,
VERIFY_DATE type CRMT_VERIFY_DATE,
GUID type CRMT_OBJECT_GUID,
end of t_orderadm.
types: begin of t_orderadm_1,
GUID type CRMT_OBJECT_GUID,
description type CRMT_PROCESS_DESCRIPTION,
LOGICAL_SYSTEM type CRMT_LOGSYS,
TEMPLATE_TYPE type CRMT_TEMPLATE_TYPE_DB,
created_at type COMT_CREATED_AT_USR,
VERIFY_DATE type CRMT_VERIFY_DATE,
end of t_orderadm_1.
data: lt_orders type table of t_orderadm,
lt_orders_1 type table of t_orderadm_1.
select description created_at logical_system template_type verify_date guid
into table lt_orders
from crmd_orderadm_h.
select guid description logical_system template_type created_at verify_date
into table lt_orders_1
from crmd_orderadm_h.
write 'done'.
First select - mixed order of fields. Response time: 82.155 microseconds for 39380 records selected.
Second select - fields in the order of the table. Response time: 81.061 microseconds for the same 39380 records selected.
Then I changed the order of SELECT statements. I have put first the select with ordered fields, and second - select with mixed order of fields. The runtimes were the following:
Ordered fields - 82.649 microseconds
Mixed order of fields - 80.270 microseconds.
So I'm going to change the Wiki page in order to avoid in future advices that make no sense. -
Select query takes long time....
Hi Experts,
I am using a select query in which inspection lot is in another table and order no. is in another table. this select query taking very long time, what is the problem in this query ? Pl. guide us.
select bPRUEFLOS bMBLNR bCPUDT aAUFNR amatnr aLGORT a~bwart
amenge aummat asgtxt axauto
into corresponding fields of table itab
*into table itab
from mseg as a inner join qamb as b
on amblnr = bmblnr
and azeile = bzeile
where b~PRUEFLOS in insp
and b~cpudt in date1
and b~typ = '3'
and a~bwart = '321'
and a~aufnr in aufnr1.
Yusufhi
instead of using 'move to corresponding of itab' fields use 'into table itab'.....
coz......if u use move to corresponding it will search for all the appropriate fields then it will place u r data........instead of that declare apprpiate internal table and use 'into table itab'.
and one more thing dont use joins ......coz joins will decrease u r performance .....so instead of that use 'for all entries' ....and mention all the key fields in where condition ........
ok
reward points for helpful answers -
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; -
Merge Query Taking Long time !!!
Hi all,
Im using loading type update/insert in one of my mappings.
mapping usually takes 3-4 mins to complete.
Suddenly It has taken 1 Hr to complete. If I take the select query from the mapping, its running fast and completes in 2 mins.
I Checked the source data count, Indexes in the source columns. Everything is the same
Mapping level, I didnt do any changes. Can anyone suggest what would be possible reason???
Thanks and Regards
ElaLots of things come into play when you're tuning a query.
An (unformatted) execution plan isn't enough.
Tuning takes time and understanding how (a lot of) things work, there is no ASAP in the world of tuning.
Please post other important details, like your database version, optimizer settings, how/when are table statistics gathered etc.
So, read the following informative threads (and please take your time, this really is important stuff), and adust your thread as needed.
That way you'll have a bigger chance of getting help that makes sense...
Your DBA should/ought to be able to help you in this as well.
Re: HOW TO: Post a SQL statement tuning request - template posting
http://oracle-randolf.blogspot.com/2009/02/basic-sql-statement-performance.html -
Query taking long time to run.
The following query is taking long time to run, is there anything can be done to make it run faster by changing the sql etc.
select distinct
A.DEPTID,
A.POSITION_NBR,
A.EMPLID,
A.EMPL_RCD_NBR,
A.EFFDT,
B.NAME,
A.EMPL_STATUS,
A.JOBCODE,
A.ANNUAL_RT,
A.STD_HOURS,
A.PRIMARY_JOB,
C.POSN_STATUS,
case when A.POSITION_NBR = ' ' then 0 else C.STD_HOURS end,
case when A.POSITION_NBR = ' ' then ' ' else C.DEPTID end
from PS_JOB A,
PS_PERSONAL_DATA B,
PS_POSITION_DATA C
where A.EMPLID = B.EMPLID
and
((A.POSITION_NBR = C.POSITION_NBR
and A.EFFSEQ = (select max(D.EFFSEQ)
from PS_JOB D
where D.EMPLID = A.EMPLID
and D.EMPL_RCD_NBR = A.EMPL_RCD_NBR
and D.EFFDT = A.EFFDT)
and C.POSN_STATUS <> 'G'
and C.EFFDT = (select max(E.EFFDT)
from PS_POSITION_DATA E
where E.POSITION_NBR = A.POSITION_NBR
and E.EFFDT <= A.EFFDT)
and C.EFFSEQ = (select max(F.EFFSEQ)
from PS_POSITION_DATA F
where F.POSITION_NBR = A.POSITION_NBR
and F.EFFDT = C.EFFDT))
or
(A.POSITION_NBR = C.POSITION_NBR
and A.EFFDT = (select max(D.EFFDT)
from PS_JOB D
where D.EMPLID = A.EMPLID
and D.EMPL_RCD_NBR = A.EMPL_RCD_NBR
and D.EFFDT <= C.EFFDT)
and A.EFFSEQ = (select max(E.EFFSEQ)
from PS_JOB E
where E.EMPLID = A.EMPLID
and E.EMPL_RCD_NBR = A.EMPL_RCD_NBR
and E.EFFDT = A.EFFDT)
and C.POSN_STATUS <> 'G'
and C.EFFSEQ = (select max(F.EFFSEQ)
from PS_POSITION_DATA F
where F.POSITION_NBR = A.POSITION_NBR
and F.EFFDT = C.EFFDT)))
or
(A.POSITION_NBR = ' '
and A.EFFSEQ = (select max(E.EFFSEQ)
from PS_JOB D
where D.EMPLID = A.EMPLID
and E.EMPL_RCD_NBR = A.EMPL_RCD_NBR
and D.EFFDT = A.EFFDT)))Using distributive law A and (B or C) = (A and B) or (A and C) from right to left we can have:
select distinct A.DEPTID,A.POSITION_NBR,A.EMPLID,A.EMPL_RCD_NBR,A.EFFDT,B.NAME,A.EMPL_STATUS,
A.JOBCODE,A.ANNUAL_RT,A.STD_HOURS,A.PRIMARY_JOB,C.POSN_STATUS,
case when A.POSITION_NBR = ' ' then 0 else C.STD_HOURS end,
case when A.POSITION_NBR = ' ' then ' ' else C.DEPTID end
from PS_JOB A,PS_PERSONAL_DATA B,PS_POSITION_DATA C
where A.EMPLID = B.EMPLID
and (
A.POSITION_NBR = C.POSITION_NBR
and A.EFFSEQ = (select max(D.EFFSEQ)
from PS_JOB D
where D.EMPLID = A.EMPLID
and D.EMPL_RCD_NBR = A.EMPL_RCD_NBR
and D.EFFDT = A.EFFDT
and C.EFFSEQ = (select max(F.EFFSEQ)
from PS_POSITION_DATA E
where E.POSITION_NBR = A.POSITION_NBR
and E.EFFDT = C.EFFDT
and C.POSN_STATUS != 'G'
and (
C.EFFDT = (select max(E.EFFDT)
from PS_POSITION_DATA E
where E.POSITION_NBR = A.POSITION_NBR
and E.EFFDT <= A.EFFDT
or
A.EFFDT = (select max(D.EFFDT)
from PS_JOB D
where D.EMPLID = A.EMPLID
and D.EMPL_RCD_NBR = A.EMPL_RCD_NBR
and D.EFFDT <= C.EFFDT
or
A.POSITION_NBR = ' '
and A.EFFSEQ = (select max(E.EFFSEQ)
from PS_JOB D
where D.EMPLID = A.EMPLID
and E.EMPL_RCD_NBR = A.EMPL_RCD_NBR
and D.EFFDT = A.EFFDT
)may not help much as the optimizer might have guessed it already
Regards
Etbin -
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> -
Select query taking more time..
Hi friends..
The below inner join statement is taking more time , can any body sugget me to improve the performance . I tried FOR ALL ENTRIES also but that also taking more time than inner join statement .
SELECT a~vbeln from vbap as a inner join vakpa as b
on avbeln = bvbeln
into corresponding fields of table IT_VAKPA
where a~WERKS IN S_IWERKS
and a~pstyv NE 'ZRS'
and b~vkorg = IVKORG
and b~audat IN IAUDAT
and b~vtweg IN IVTWEG.
Regards
ChetanHi Chetan ,
VAKPA is an index table. From the select query , it has been observed that you are not fetching any data from VAKPA. Only you have added some selection paramenters in where clause of select query.
My suggestion will be instead of using VAKPA in inner join you use VBAK along with VBAP. All the fields that you are using as selection condition from VAKPA are there in VBAK.
I am sure performance of query will be improved.
If still duo to business logic you need to use VAKPA, try to create secondary non unique index on fields VKORD,AUDATand VTWEG on table VAKPA.
However I will recommend you to go for first option only. If this does not work then go for second option.
Hopfully this will help you.
Regards,
Nikhil -
CDHDR table query taking long time
Hi all,
Select query from CDHDR table is taking long time,in where condition i am giving OBJECTCLASS = 'MAT_FULL' udate = sy-datum and langu = 'EN'.
any suggestion to improve the performance.i want to select all the article which got changed on current date
regards
shibuThis will always be slow for large data volumes, since CDHDR is designed for quick access by object ID (in this case material number), not by date.
I'm afraid you would need to introduce a secondary index on OBJECTCLAS and UDATE, if that query is crucial enough to warrant the additional disk space and processing time taken by the new index.
Greetings
Thomas -
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 -
Sap bi--query taking long time to exexute
Hi
When i try run the bex query ,its taking long time,please suggest
Thanks
sreedharHi
When i try run the bex query ,its taking long time,please suggest
Thanks
sreedhar -
Hi All.
When i execute select query from View it takes about 00:00:45:12 sec to pull the data , but when i execute same query in some other system(different database with same table structure) it takes about 00:00:02:05 sec.
1)I have tried by dropped and recreated the index then i tried by exec dbms_stats.gather_table_stats procedure still no luck.
Please help me to understand the reason difference in response time
Thanks
sankardid you run the EXPLAIN PLAN?
-
Dear all ,
I am fetching data from pool table a006. The select query is mentioned below.
select * from a005 into table i_a005 for all wntries in it_table
where kappl = 'V'
and kschl IN s_kschl
and vkorg in s_vkorg
and vtweg in s_vtgew
and matnr in s_matnr
and knumh = it_table-knumh .
here every fields are primary key fields except one field knumh which is comparing with table it_table. Because of these field this query is taking too much time as KNUMH is not primary key. And a005 is pool table . So , i cant create index for same. If there is alternate solutions , than please let me know..
Thank You ,
And in technical setting of table ITS Metioned as Fully buffered and size category is 0 .. But data are around 9000000. Is it issue or What ? Can somebody tell some genual reason ? Or improvement in my select query.........
Edited by: TVC6784 on Jun 30, 2011 3:31 PMTVC6784 wrote:
Hi Yuri ,
>
> Thanks for your reply....I will check as per your comment...
> bUT if i remove field KNUMH From selection condition and also for all entries in it_itab , than data fetch very fast As KNUMH is not primary key..
> . the example is below
>
> select * from a005 into table i_a005
> where kappl = 'V'
> and kschl IN s_kschl
> and vkorg in s_vkorg
> and vtweg in s_vtgew
> and matnr in s_matnr.
>
> Can you comment anything about it ?
>
> And can you please say how can i check its size as you mention that is 2-3 Mb More ?
>
> Edited by: TVC6784 on Jun 30, 2011 7:37 PM
I cannot see the trace and other information about the table so I cannot judge why the select w/o KNUMH is faster.
Basically, if the table is buffered and it's contents is in the SAP application server memory, the access should be really fast. Does not really matter if it is with KNUMH or without.
I would really like to see at least ST05 trace of your report that is doing this select. This would clarify many things.
You can check the size by multiplying the entries in A005 table by 138. This is (in my test system) the ABAP width of the structure.
If you have 9.000.000 records in A005, then it would take 1,24 Gb in the buffer (which is a clear sign to unbuffer).
Maybe you are looking for
-
Non-English character problem in Oracle 10g Express Edition
Hi There; I have a table. It's name is INSTITUTION. It has a NUMBER INS_ID and NVARCHAR2(50) INS_NAME . INS_NAME can contain Turkish characters, such as "ğ,ü,ş,ç,ö". According to business logic, there can not be a repetition on the INS_NAME. User wil
-
My MacBook hard drive crashed and had to be replaced. I am now running iPhoto 11 (9.3.2) which is a more recent version than my old iPhoto library (but i am not sure what version it was). I am now trying to restore some old photos from an external
-
Using External LCD as Camera Viewfinder?
Has anyone else been wanting this function? I have not seen one thread complaining about how inept the external LCD is. I know that some people consider this a low priority, but it sure would be nice to see yoruself when taking a pic with friends and
-
Reg plant related to a company code
hi, i need small code for a sigle delivery number related to a copmpany code and related a plant data.for retreiving data select statement should validate company code and delivery no,delivery date also
-
is it possible to assign a value to a pop up menu item say you have a product = bar of soap type 1 in cell A from a pop a menu but i want the price of "bar of soap type 1 " to appear in cell D in other words id like to impletment a product / and pri