Query consuming more time
Hi,
Db: Oracle 9.2.0
OS: AIX.
We are running the below report. and it takes around 6 hours.
I want to know exactly where the issue is. else, please refer me any gud doc id for query tuning.
SELECT FLT . MEANING "Bank Name" ,
PPV . EMPLOYEE_NUMBER "Emp Number" ,
PPV . FULL_NAME "Emp Name" ,
PEA . SEGMENT4 "Bank Account Number" ,
PPP . VALUE "Net Pay" ,
NVL ( COST . segment1 , '00000' ) "BU Code" ,
SELECT vl . description
FROM fnd_flex_values_vl vl
WHERE vl . flex_value_set_id = '1002603'
AND vl . flex_value = NVL ( COST . segment1 , '00000' )
"BU Name"
FROM PAY_ASSIGNMENT_ACTIONS PAC ,
PAY_PAYROLL_ACTIONS PPA ,
PAY_PRE_PAYMENTS PPP ,
PER_ASSIGNMENTS_V PAV ,
PER_PEOPLE_V PPV ,
PAY_PERSONAL_PAYMENT_METHODS_V PPPM ,
PAY_EXTERNAL_ACCOUNTS PEA ,
FND_LOOKUP_VALUES FLT ,
APPS . PER_TIME_PERIODS PTP ,
hr_all_organization_units org_us ,
pay_cost_allocation_keyflex COST
WHERE PAC . PAYROLL_ACTION_ID = PPA . PAYROLL_ACTION_ID
AND PAC . PRE_PAYMENT_ID = PPP . PRE_PAYMENT_ID
AND PAC . ASSIGNMENT_ID = PAV . ASSIGNMENT_ID
AND PAV . PERSON_ID = PPV . PERSON_ID
AND PPA . PAYROLL_ID = PPPM . PAYROLL_ID
AND PPA . PAYROLL_ID = : P_PAYROLL_ID
AND PPA . CONSOLIDATION_SET_ID = : P_CONSOLIDATION_SET_ID
AND PAV . ASSIGNMENT_ID = PPPM . ASSIGNMENT_ID
AND PPP . PERSONAL_PAYMENT_METHOD_ID = PPPM . PERSONAL_PAYMENT_METHOD_ID
AND PPPM . EXTERNAL_ACCOUNT_ID = PEA . EXTERNAL_ACCOUNT_ID
AND PEA . SEGMENT1 = FLT . LOOKUP_CODE
AND FLT . LOOKUP_TYPE = 'SA_BANKS'
AND FLT . LANGUAGE = USERENV ( 'LANG' )
AND FLT . LOOKUP_CODE = NVL ( : P_BANK_NAME , FLT . LOOKUP_CODE )
AND pay_assignment_actions_pkg . get_payment_status_code ( PPP . assignment_action_id , PPP .
pre_payment_id ) = 'P'
AND PTP . END_DATE = : P_PERIOD_END
AND PTP . PAYROLL_ID = PPA . PAYROLL_ID
AND PAV . organization_id = org_us . organization_id
AND org_us . cost_allocation_keyflex_id = COST . cost_allocation_keyflex_id (+)
AND ppa . effective_date BETWEEN ptp . start_date AND ptp . end_date
AND ppa . effective_date BETWEEN ppv . effective_start_date AND ppv . effective_end_date
AND ppa . effective_date BETWEEN pav . effective_start_date AND pav . effective_end_date
AND DECODE (hr_security.view_all,'Y', 'TRUE',hr_security.show_record ('PER_ALL_ASSIGNMENTS_F',
PAV.assignment_id,PAV.person_id,PAV.assignment_type)) = 'TRUE'
AND DECODE (hr_general.get_xbg_profile,'Y', PAV.business_group_id,hr_general.get_business_group_id)
= PAV.business_group_id
AND DECODE (hr_security.view_all,'Y', 'TRUE',hr_security.show_person (PPV.person_id,
PPV.current_applicant_flag,PPV.current_employee_flag,PPV.current_npw_flag,PPV.employee_number,
PPV.applicant_number,PPV.npw_number)) = 'TRUE'
AND DECODE (hr_general.get_xbg_profile,'Y', PPV.business_group_id,hr_general.get_business_group_id)
= PPV.business_group_id
ORDER BY 1 ,
regards,
For purely sql tuning questions, you can try PL/SQL Before posting there, please please read and follow HOW TO: Post a SQL statement tuning request - template posting
Sandeep Gandhi
Similar Messages
-
Hi All,
I have cloned KSB1 tcode to custom one as required by business.
Below query takes more time than excepted.
Here V_DB_TABLE = COVP.
Values in Where clause are as follows
OBNJR in ( KSBB010000001224 BT KSBB012157221571)
GJAHR in blank
VERSN in '000'
WRTTP in '04' and '11'
all others are blank
VT_VAR_COND = ( CPUDT BETWEEN '20091201' and '20091208' )
SELECT (VT_FIELDS) INTO CORRESPONDING FIELDS OF GS_COVP_EXT
FROM (V_DB_TABLE)
WHERE LEDNR = '00'
AND OBJNR IN LR_OBJNR
AND GJAHR IN GR_GJAHR
AND VERSN IN GR_VERSN
AND WRTTP IN GR_WRTTP
AND KSTAR IN LR_KSTAR
AND PERIO IN GR_PERIO
AND BUDAT IN GR_BUDAT
AND PAROB IN GR_PAROB
AND (VT_VAR_COND).
Checked in table for this condition it has only 92 entries.
But when i execute program takes long time as 3 Hrs.
Could any one help me on this>1.Dont use SELECT/ENDSELECT instead use INTO TABLE addition .
> 2.Avoid using corresponding addition.create a type and reference it.
> If the select is going for dump beacause of storage limitations ,then use Cursors.
you got three large NOs .... all three recommendations are wrong!
The SE16 test is going in the right direction ... but what was filled. Nobody knows!!!!
Select options:
Did you ever try to trace the SE16? The generic statement has for every field an in-condition!
Without the information what was actually filled, nobody can say something there
are at least 2**n combinations possible!
Use ST05 for SE16 and check actual statement plus explain! -
What is the reason for query take more time to execute
Hi,
What is the reason for the query take more time inside procedure.
but if i execute that query alone then it excute within a minutes.
query includes update and insert.I have a insert and update query when I execute
without Procedure then that query execute faster but
If I execute inside procedure then It takes 2 hours
to execute.Put you watch 2 hours back and the problem will disappear.
do you understand what I want to say?I understood what you wanted to say and I understood you didn't understood what I said.
What does the procedure, what does the query, how can you say the query does the same as the procedure that takes longer. You didn't say anything useful to have an idea of what you're talking about.
Everyone knows what means that something is slower than something else, but it means nothing if you don't say what you're talking about.
To begin with something take a look at this
When your query takes too long ...
especially the part regarding the trace.
Bye Alessandro -
Dear Gurus/Masters/All,
I request your valuble assistance in tuning one of my SQL.
We are using oracle 10.2.04 version and OS is HP-UX 11.23(ia64) version
In my production environment one SQL is taking more time to complete the task. According to EXPLAIN PLAN, i observed that one of it's WHERE condition execution is causing the issue.
I took the explain plan of the WHERE condition which is causing the issue. It is going for full table scan to satisfy the criteria. But a normal index exists on this column.
Main Query WHERE condition and Explain Plan.
SELECT column list ....
FROM
SIEBEL.S_ADDR_PER T1,
SIEBEL.S_PTY_PAY_PRFL T2,
SIEBEL.S_INVLOC T3,
SIEBEL.S_ORDER T4,
SIEBEL.S_ORG_EXT T5,
SIEBEL.S_POSTN T6,
SIEBEL.S_PARTY T7,
SIEBEL.S_PROJ T8,
SIEBEL.S_CON_ADDR T9,
SIEBEL.S_ORG_EXT T10,
SIEBEL.S_USER T11,
SIEBEL.S_DOC_QUOTE T12,
SIEBEL.S_ACCNT_POSTN T13,
SIEBEL.S_INS_CLAIM T14,
SIEBEL.S_USER T15,
SIEBEL.S_ORG_EXT T16,
SIEBEL.S_ASSET T17,
SIEBEL.S_ORDER_TNTX T18,
SIEBEL.S_ORG_EXT_TNTX T19,
SIEBEL.S_PERIOD T20,
SIEBEL.S_DEPOSIT_TNT T21,
SIEBEL.S_ADDR_PER T22,
SIEBEL.S_PAYMENT_TERM T23,
SIEBEL.S_ORG_EXT_X T24,
SIEBEL.S_ORG_EXT T25,
SIEBEL.S_INSCLM_ELMNT T26,
SIEBEL.S_INVOICE T27
WHERE
T25.BU_ID = T10.PAR_ROW_ID (+) AND
T26.INSCLM_ID = T14.ROW_ID (+) AND
T27.ELEMENT_ID = T26.ROW_ID (+) AND
T27.LAST_UPD_BY = T15.PAR_ROW_ID (+) AND
T4.QUOTE_ID = T12.ROW_ID (+) AND
T3.CG_ASSSET_ID = T17.ROW_ID (+) AND
T27.BL_ADDR_ID = T22.ROW_ID (+) AND
T8.BU_ID = T5.PAR_ROW_ID (+) AND
T27.PER_PAY_PRFL_ID = T2.ROW_ID (+) AND
T27.REMIT_ORG_EXT_ID = T16.PAR_ROW_ID (+) AND
T27.PROJ_ID = T8.ROW_ID (+) AND
T27.BL_PERIOD_ID = T20.ROW_ID (+) AND
T27.PAYMENT_TERM_ID = T23.ROW_ID (+) AND
T12.BU_ID = T19.PAR_ROW_ID (+) AND
T27.ACCNT_ID = T25.PAR_ROW_ID (+) AND
T27.ORDER_ID = T18.ROW_ID (+) AND
T4.SRC_INVLOC_ID = T3.ROW_ID (+) AND
T27.ORDER_ID = T4.ROW_ID (+) AND
T27.ACCNT_ID = T24.PAR_ROW_ID (+) AND
T18.PR_DEPOSIT_ID = T21.ROW_ID (+) AND
T27.BL_ADDR_ID = T9.ADDR_PER_ID (+) AND T27.ACCNT_ID = T9.ACCNT_ID (+) AND
T27.BL_ADDR_ID = T1.ROW_ID (+) AND
T25.PR_POSTN_ID = T13.POSITION_ID (+) AND T25.ROW_ID = T13.OU_EXT_ID (+) AND
T13.POSITION_ID = T7.ROW_ID (+) AND
T13.POSITION_ID = T6.PAR_ROW_ID (+) AND
T6.PR_EMP_ID = T11.PAR_ROW_ID (+) AND
(T27.INVC_TYPE_CD = :1)
ORDER BY
T27.INVC_DT;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 2576210427
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 39M| 71G| | 624M (1)|278:42:59 |
| 1 | SORT ORDER BY | | 39M| 71G| 150G| 624M (1)|278:42:59 |
| 2 | NESTED LOOPS OUTER | | 39M| 71G| | 610M (1)|272:11:24 |
| 3 | NESTED LOOPS OUTER | | 39M| 70G| | 515M (1)|229:48:41 |
| 4 | NESTED LOOPS OUTER | | 39M| 69G| | 483M (1)|215:41:04 |
| 5 | NESTED LOOPS OUTER | | 39M| 68G| | 483M (1)|215:41:04 |
| 6 | NESTED LOOPS OUTER | | 39M| 67G| | 483M (1)|215:41:04 |
| 7 | NESTED LOOPS OUTER | | 39M| 66G| | 406M (1)|181:17:50 |
| 8 | NESTED LOOPS OUTER | | 39M| 65G| | 343M (1)|153:12:57 |
| 9 | NESTED LOOPS OUTER | | 39M| 64G| | 311M (1)|139:04:56 |
| 10 | NESTED LOOPS OUTER | | 39M| 63G| | 185M (1)| 82:37:56 |
| 11 | NESTED LOOPS OUTER | | 39M| 54G| | 108M (1)| 48:11:29 |
| 12 | NESTED LOOPS OUTER | | 39M| 53G| | 108M (1)| 48:11:29 |
| 13 | NESTED LOOPS OUTER | | 39M| 51G| | 76M (1)| 34:03:51 |
| 14 | NESTED LOOPS OUTER | | 39M| 49G| | 76M (1)| 34:03:51 |
| 15 | NESTED LOOPS OUTER | | 39M| 46G| | 76M (1)| 34:03:51 |
| 16 | NESTED LOOPS OUTER | | 39M| 44G| | 76M (1)| 34:03:51 |
| 17 | NESTED LOOPS OUTER | | 39M| 40G| | 65M (1)| 29:25:49 |
| 18 | NESTED LOOPS OUTER | | 39M| 39G| | 65M (1)| 29:25:49 |
| 19 | NESTED LOOPS OUTER | | 39M| 38G| | 65M (1)| 29:25:49 |
| 20 | NESTED LOOPS OUTER | | 39M| 34G| | 65M (1)| 29:17:44 |
| 21 | NESTED LOOPS OUTER | | 39M| 32G| | 65M (1)| 29:17:08 |
| 22 | NESTED LOOPS OUTER | | 39M| 31G| | 65M (1)| 29:09:04 |
| 23 | NESTED LOOPS OUTER | | 39M| 30G| | 2043K (9)| 00:54:42 |
| 24 | NESTED LOOPS OUTER | | 39M| 30G| | 2043K (9)| 00:54:42 |
| 25 | NESTED LOOPS OUTER | | 39M| 25G| | 2015K (7)| 00:53:57 |
| 26 | NESTED LOOPS OUTER | | 39M| 22G| | 2015K (7)| 00:53:57 |
| 27 | NESTED LOOPS OUTER | | 39M| 16G| | 2015K (7)| 00:53:57 |
|* 28 | TABLE ACCESS FULL | S_INVOICE | 39M| 9G| | 2015K (7)| 00:53:57 |
| 29 | TABLE ACCESS BY INDEX ROWID| S_PROJ | 1 | 188 | | 1 (0)| 00:00:01 |
|* 30 | INDEX UNIQUE SCAN | S_PROJ_P1 | 1 | | | 1 (0)| 00:00:01 |
| 31 | TABLE ACCESS BY INDEX ROWID | S_PAYMENT_TERM | 1 | 156 | | 1 (0)| 00:00:01 |
|* 32 | INDEX UNIQUE SCAN | S_PAYMENT_TERM_P1 | 1 | | | 1 (0)| 00:00:01 |
| 33 | TABLE ACCESS BY INDEX ROWID | S_INSCLM_ELMNT | 1 | 77 | | 1 (0)| 00:00:01 |
|* 34 | INDEX UNIQUE SCAN | S_INSCLM_ELMNT_P1 | 1 | | | 1 (0)| 00:00:01 |
| 35 | TABLE ACCESS BY INDEX ROWID | S_INS_CLAIM | 1 | 134 | | 1 (0)| 00:00:01 |
|* 36 | INDEX UNIQUE SCAN | S_INS_CLAIM_P1 | 1 | | | 1 (0)| 00:00:01 |
| 37 | TABLE ACCESS BY INDEX ROWID | S_PERIOD | 1 | 19 | | 1 (0)| 00:00:01 |
|* 38 | INDEX UNIQUE SCAN | S_PERIOD_P1 | 1 | | | 1 (0)| 00:00:01 |
| 39 | TABLE ACCESS BY INDEX ROWID | S_USER | 1 | 25 | | 2 (0)| 00:00:01 |
|* 40 | INDEX UNIQUE SCAN | S_USER_U2 | 1 | | | 1 (0)| 00:00:01 |
| 41 | TABLE ACCESS BY INDEX ROWID | S_ORDER_TNTX | 1 | 26 | | 2 (0)| 00:00:01 |
|* 42 | INDEX UNIQUE SCAN | S_ORDER_TNTX_P1 | 1 | | | 1 (0)| 00:00:01 |
| 43 | TABLE ACCESS BY INDEX ROWID | S_DEPOSIT_TNT | 1 | 45 | | 1 (0)| 00:00:01 |
|* 44 | INDEX UNIQUE SCAN | S_DEPOSIT_TNT_P1 | 1 | | | 1 (0)| 00:00:01 |
| 45 | TABLE ACCESS BY INDEX ROWID | S_ORDER | 1 | 101 | | 2 (0)| 00:00:01 |
|* 46 | INDEX UNIQUE SCAN | S_ORDER_P1 | 1 | | | 1 (0)| 00:00:01 |
| 47 | TABLE ACCESS BY INDEX ROWID | S_INVLOC | 1 | 47 | | 1 (0)| 00:00:01 |
|* 48 | INDEX UNIQUE SCAN | S_INVLOC_P1 | 1 | | | 1 (0)| 00:00:01 |
| 49 | TABLE ACCESS BY INDEX ROWID | S_DOC_QUOTE | 1 | 21 | | 1 (0)| 00:00:01 |
|* 50 | INDEX UNIQUE SCAN | S_DOC_QUOTE_P1 | 1 | | | 1 (0)| 00:00:01 |
|* 51 | TABLE ACCESS FULL | S_ORG_EXT_TNTX | 1 | 94 | | 0 (0)| 00:00:01 |
| 52 | TABLE ACCESS BY INDEX ROWID | S_PTY_PAY_PRFL | 1 | 74 | | 1 (0)| 00:00:01 |
|* 53 | INDEX UNIQUE SCAN | S_PTY_PAY_PRFL_P1 | 1 | | | 1 (0)| 00:00:01 |
| 54 | TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 1 | 84 | | 2 (0)| 00:00:01 |
|* 55 | INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 1 | | | 1 (0)| 00:00:01 |
| 56 | TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 1 | 57 | | 1 (0)| 00:00:01 |
|* 57 | INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 1 | | | 1 (0)| 00:00:01 |
| 58 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 32 | | 1 (0)| 00:00:01 |
|* 59 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | | 1 (0)| 00:00:01 |
| 60 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 32 | | 1 (0)| 00:00:01 |
|* 61 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | | 1 (0)| 00:00:01 |
| 62 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 256 | | 2 (0)| 00:00:01 |
|* 63 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | | 1 (0)| 00:00:01 |
| 64 | TABLE ACCESS BY INDEX ROWID | S_ACCNT_POSTN | 1 | 32 | | 3 (0)| 00:00:01 |
|* 65 | INDEX RANGE SCAN | S_ACCNT_POSTN_U1 | 1 | | | 2 (0)| 00:00:01 |
| 66 | TABLE ACCESS BY INDEX ROWID | S_POSTN | 1 | 21 | | 1 (0)| 00:00:01 |
|* 67 | INDEX UNIQUE SCAN | S_POSTN_U2 | 1 | | | 1 (0)| 00:00:01 |
| 68 | TABLE ACCESS BY INDEX ROWID | S_USER | 1 | 25 | | 2 (0)| 00:00:01 |
|* 69 | INDEX UNIQUE SCAN | S_USER_U2 | 1 | | | 1 (0)| 00:00:01 |
| 70 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 32 | | 2 (0)| 00:00:01 |
|* 71 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | | 1 (0)| 00:00:01 |
| 72 | TABLE ACCESS BY INDEX ROWID | S_ASSET | 1 | 24 | | 2 (0)| 00:00:01 |
|* 73 | INDEX UNIQUE SCAN | S_ASSET_P1 | 1 | | | 2 (0)| 00:00:01 |
| 74 | TABLE ACCESS BY INDEX ROWID | S_CON_ADDR | 1 | 36 | | 3 (0)| 00:00:01 |
|* 75 | INDEX RANGE SCAN | S_CON_ADDR_U1 | 1 | | | 2 (0)| 00:00:01 |
|* 76 | INDEX UNIQUE SCAN | S_PARTY_P1 | 1 | 12 | | 1 (0)| 00:00:01 |
| 77 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT_X | 1 | 37 | | 2 (0)| 00:00:01 |
|* 78 | INDEX RANGE SCAN | S_ORG_EXT_X_U1 | 1 | | | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
28 - filter("T27"."INVC_TYPE_CD"=:1)
30 - access("T27"."PROJ_ID"="T8"."ROW_ID"(+))
32 - access("T27"."PAYMENT_TERM_ID"="T23"."ROW_ID"(+))
34 - access("T27"."ELEMENT_ID"="T26"."ROW_ID"(+))
36 - access("T26"."INSCLM_ID"="T14"."ROW_ID"(+))
38 - access("T27"."BL_PERIOD_ID"="T20"."ROW_ID"(+))
40 - access("T27"."LAST_UPD_BY"="T15"."PAR_ROW_ID"(+))
42 - access("T27"."ORDER_ID"="T18"."ROW_ID"(+))
44 - access("T18"."PR_DEPOSIT_ID"="T21"."ROW_ID"(+))
46 - access("T27"."ORDER_ID"="T4"."ROW_ID"(+))
48 - access("T4"."SRC_INVLOC_ID"="T3"."ROW_ID"(+))
50 - access("T4"."QUOTE_ID"="T12"."ROW_ID"(+))
51 - filter("T12"."BU_ID"="T19"."PAR_ROW_ID"(+))
53 - access("T27"."PER_PAY_PRFL_ID"="T2"."ROW_ID"(+))
55 - access("T27"."BL_ADDR_ID"="T1"."ROW_ID"(+))
57 - access("T27"."BL_ADDR_ID"="T22"."ROW_ID"(+))
59 - access("T8"."BU_ID"="T5"."PAR_ROW_ID"(+))
61 - access("T27"."REMIT_ORG_EXT_ID"="T16"."PAR_ROW_ID"(+))
63 - access("T27"."ACCNT_ID"="T25"."PAR_ROW_ID"(+))
65 - access("T25"."ROW_ID"="T13"."OU_EXT_ID"(+) AND "T25"."PR_POSTN_ID"="T13"."POSITION_ID"(+))
67 - access("T13"."POSITION_ID"="T6"."PAR_ROW_ID"(+))
69 - access("T6"."PR_EMP_ID"="T11"."PAR_ROW_ID"(+))
71 - access("T25"."BU_ID"="T10"."PAR_ROW_ID"(+))
73 - access("T3"."CG_ASSSET_ID"="T17"."ROW_ID"(+))
75 - access("T27"."BL_ADDR_ID"="T9"."ADDR_PER_ID"(+) AND "T27"."ACCNT_ID"="T9"."ACCNT_ID"(+))
filter("T27"."ACCNT_ID"="T9"."ACCNT_ID"(+))
76 - access("T13"."POSITION_ID"="T7"."ROW_ID"(+))
78 - access("T27"."ACCNT_ID"="T24"."PAR_ROW_ID"(+))
117 rows selected.SQL> EXPLAIN PLAN FOR
2 SELECT * FROM SIEBEL.S_INVOICE T27 WHERE T27.INVC_TYPE_CD=:1;
Explained.
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
Plan hash value: 1810797629
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 39M| 9G| 2016K (8)| 00:53:59 |
|* 1 | TABLE ACCESS FULL| S_INVOICE | 39M| 9G| 2016K (8)| 00:53:59 |
Predicate Information (identified by operation id):
1 - filter("T27"."INVC_TYPE_CD"=:1)
13 rows selected.Edited by: KODS on Feb 13, 2013 1:08 PMDear Ivan,
Please find the details below.
select * from dba_indexes where index_name = 'S_INVOICE_U1';
OWNER INDEX_NAME INDEX_TYPE TABLE_OWNER TABLE_NAME TABLE_TYPE UNIQUENESS COMPRESSION PREFIX_LENGTH TABLESPACE_NAME INI_TRANS MAX_TRANS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE PCT_THRESHOLD INCLUDE_COLUMN FREELISTS FREELIST_GROUPS PCT_FREE LOGGING BLEVEL LEAF_BLOCKS DISTINCT_KEYS AVG_LEAF_BLOCKS_PER_KEY AVG_DATA_BLOCKS_PER_KEY CLUSTERING_FACTOR STATUS NUM_ROWS SAMPLE_SIZE LAST_ANALYZED DEGREE INSTANCES PARTITIONED TEMPORARY GENERATED SECONDARY BUFFER_POOL USER_STATS DURATION PCT_DIRECT_ACCESS ITYP_OWNER ITYP_NAME PARAMETERS GLOBAL_STATS DOMIDX_STATUS DOMIDX_OPSTATUS FUNCIDX_STATUS JOIN_INDEX IOT_REDUNDANT_PKEY_ELIM DROPPED
SIEBEL S_INVOICE_U1 NORMAL SIEBEL S_INVOICE TABLE UNIQUE DISABLED CRMSBL_AEM_INDEX 2 255 65536 1 2147483645 10 NO 3 902796 196739390 1 1 125598294 VALID 196739390 196739390 10-02-13 1 1 NO N N N DEFAULT NO YES NO NO NO
select * from dba_ind_columns where index_name = 'S_INVOICE_U1' order by column_position;
INDEX_OWNER INDEX_NAME TABLE_OWNER TABLE_NAME COLUMN_NAME COLUMN_POSITION COLUMN_LENGTH CHAR_LENGTH DESCEND
SIEBEL S_INVOICE_U1 SIEBEL S_INVOICE INVC_NUM 1 200 50 ASC
SIEBEL S_INVOICE_U1 SIEBEL S_INVOICE INVC_TYPE_CD 2 120 30 ASC
SIEBEL S_INVOICE_U1 SIEBEL S_INVOICE CONFLICT_ID 3 60 15 ASC -
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 -
Stopping a Query taking more time to execute in runtime in Oracle Forms.
Hi,
In the present application one of the oracle form screen is taking long time to execute a query, user wanted an option to stop the query in between and browse the result (whatever has been fetched before stopping the query).
We have tried three approach.
1. set max fetch record in form and block level.
2. set max fetch time in form and block level.
in above two method does not provide the appropiate solution for us.
3. the third approach we applied is setting the interaction mode to "NON BLOCKING" at the form level.
It seems to be worked, while the query took long time to execute, oracle app server prompts an message to press Esc to cancel the query and it a displaying the results fetched upto that point.
But the drawback is one pressing esc, its killing the session itself. which is causing the entire application to collapse.
Please suggest if there is any alternative approach for this or how to overcome this perticular scenario.
This kind of facility is alreday present in TOAD and PL/SQL developer where we can stop an executing query and browse the results fetched upto that point, is the similar facility is avialable in oracle forms ,please suggest.
Thanks and Regards,
Suraj
Edited by: user10673131 on Jun 25, 2009 4:55 AMHello Friend,
You query will definitely take more time or even fail in PROD,becuase the way it is written. Here are my few observations, may be it can help :-
1. XLA_AR_INV_AEL_SL_V XLA_AEL_SL_V : Never use a view inside such a long query , becuase View is just a window to the records.
and when used to join other table records, then all those tables which are used to create a view also becomes part of joining conition.
First of all please check if you really need this view. I guess you are using to check if the records have been created as Journal entries or not ?
Please check the possbility of finding it through other AR tables.
2. Remove _ALL tables instead use the corresponding org specific views (if you are in 11i ) or the sysnonymns ( in R12 )
For example : For ra_cust_trx_types_all use ra_cust_trx_types.
This will ensure that the query will execute only for those ORG_IDs which are assigned to that responsibility.
3. Check with the DBA whether the GATHER SCHEMA STATS have been run atleast for ONT and RA tables.
You can also check the same using
SELECT LAST_ANALYZED FROM ALL_TABLES WHERE TABLE_NAME = 'ra_customer_trx_all'.
If the tables are not analyzed , the CBO will not be able to tune your query.
4. Try to remove the DISTINCT keyword. This is the MAJOR reason for this problem.
5. If its a report , try to separate the logic in separate queries ( using a procedure ) and then populate the whole data in custom table, and use this custom table for generating the
report.
Thanks,
Neeraj Shrivastava
[email protected]
Edited by: user9352949 on Oct 1, 2010 8:02 PM
Edited by: user9352949 on Oct 1, 2010 8:03 PM -
Query Takes more Time when i execute from the Instant client.
Hi,
Currently in our Env we have some Queries takes more time when we run from the Instant Client.
System Details
OS=Solaris 10 x86 64bit
Oracle 10.2.0.4
Client Side
$ sqlplus trd_trd_ro/trd_trd_ro@prdba001/TRADE1
SQL*Plus: Release 10.2.0.2.0 - Production on Mon Aug 9 16:26:25 2010
Copyright (c) 1982, 2005, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Release 10.2.0.4.0 - Production
SQL> set timing on
SQL> select mod(lastinstmessagesequence, 1000000000) LastInstIDSeqNo from tibex_msgseqbyuseralias where useralias='2221';
no rows selected
Elapsed: 00:01:54.19
SQL> Disconnected from Oracle Database 10g Release 10.2.0.4.0 - ProductionSame Query running on Server Side
^C130-oracle@prdba001 txt: sql
Database: trd_trd_owner/trd_trd_owner@prdba001/TRADE1
SQL*Plus: Release 10.2.0.4.0 - Production on Mon Aug 9 17:15:18 2010
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Release 10.2.0.4.0 - Production
trd_trd_owner@TRADE1> set timing on
trd_trd_owner@TRADE1> select mod(lastinstmessagesequence, 1000000000) LastInstIDSeqNo from tibex_msgseqbyuseralias where useralias='2221';
no rows selected
Elapsed: 00:00:00.12
trd_trd_owner@TRADE1> exitKindly help me what could be the Issues.Hi Charles,
Thanks for your Quick response.I pulled the info.
sys@TRADE1> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('bpxr7axhxaqvy',NULL,'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
SQL_ID bpxr7axhxaqvy, child number 0
select /*+ GATHER_PLAN_STATISTICS */ mod(lastinstmessagesequence, :"SYS_B_0") LastInstIDSeqNo from
tibex_msgseqbyuseralias where useralias=:"SYS_B_1"
Plan hash value: 1955857846
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
| 1 | SORT GROUP BY NOSORT | | 1 | 21 | 0 |00:00:00.06 | 6121 |
| 2 | VIEW | | 1 | 21 | 0 |00:00:00.06 | 6121 |
| 3 | UNION-ALL | | 1 | | 0 |00:00:00.06 | 6121 |
| 4 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.05 | 3073 |
|* 5 | TABLE ACCESS FULL | TIBEX_QUOTE | 1 | 30080 | 0 |00:00:00.05 | 3073 |
| 6 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
| 7 | TABLE ACCESS BY INDEX ROWID| TIBEX_ORDER | 1 | 971 | 0 |00:00:00.01 | 3 |
|* 8 | INDEX RANGE SCAN | TIBEX_ORDER_IDX_OLT | 1 | 971 | 0 |00:00:00.01 | 3 |
| 9 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
|* 10 | TABLE ACCESS FULL | TIBEX_TSTRADE | 1 | 1 | 0 |00:00:00.01 | 3 |
| 11 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
|* 12 | TABLE ACCESS FULL | TIBEX_IOIREQUEST | 1 | 1 | 0 |00:00:00.01 | 3 |
| 13 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 126 |
|* 14 | TABLE ACCESS FULL | TIBEX_BESTEXREL | 1 | 1 | 0 |00:00:00.01 | 126 |
| 15 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 2862 |
|* 16 | INDEX FAST FULL SCAN | SYS_C0058325 | 1 | 339 | 0 |00:00:00.01 | 2862 |
| 17 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 31 |
|* 18 | TABLE ACCESS FULL | TIBEX_EDPPULLORDERS | 1 | 1 | 0 |00:00:00.01 | 31 |
| 19 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 20 | INDEX RANGE SCAN | SYS_C0058803 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 21 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 22 | INDEX RANGE SCAN | SYS_C0057785 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 23 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 24 | INDEX RANGE SCAN | SYS_C0057827 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 25 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
|* 26 | TABLE ACCESS FULL | TIBEX_DELETEADMIN | 1 | 1 | 0 |00:00:00.01 | 3 |
| 27 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 28 | INDEX RANGE SCAN | SYS_C0058148 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 29 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 30 | INDEX RANGE SCAN | SYS_C0058264 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 31 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 32 | INDEX RANGE SCAN | SYS_C0058516 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 33 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 34 | INDEX RANGE SCAN | SYS_C0058561 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 35 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 36 | INDEX RANGE SCAN | SYS_C0058783 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 37 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 38 | INDEX RANGE SCAN | SYS_C0058977 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 39 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 40 | INDEX RANGE SCAN | SYS_C0058859 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 41 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 42 | INDEX RANGE SCAN | SYS_C0059197 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 43 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
|* 44 | TABLE ACCESS FULL | TIBEX_CANCELTRDADMIN | 1 | 1 | 0 |00:00:00.01 | 3 |
| 45 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
|* 46 | TABLE ACCESS FULL | TIBEX_BULKCANCELADMIN | 1 | 1 | 0 |00:00:00.01 | 3 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
5 - filter("LASTINSTUSERALIAS"=:SYS_B_1)
8 - access("LASTINSTUSERALIAS"=:SYS_B_1)
10 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
12 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
14 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
16 - filter("USERALIAS"=:SYS_B_1)
18 - filter("USERALIAS"=:SYS_B_1)
20 - access("USERALIAS"=:SYS_B_1)
22 - access("USERALIAS"=:SYS_B_1)
24 - access("USERALIAS"=:SYS_B_1)
26 - filter(("USERALIAS" IS NOT NULL AND "USERALIAS"=:SYS_B_1))
28 - access("USERALIAS"=:SYS_B_1)
30 - access("USERALIAS"=:SYS_B_1)
32 - access("USERALIAS"=:SYS_B_1)
34 - access("USERALIAS"=:SYS_B_1)
36 - access("USERALIAS"=:SYS_B_1)
38 - access("USERALIAS"=:SYS_B_1)
40 - access("USERALIAS"=:SYS_B_1)
42 - access("USERALIAS"=:SYS_B_1)
44 - filter("USERALIAS"=:SYS_B_1)
46 - filter("USERALIAS"=:SYS_B_1)
SQL_ID bpxr7axhxaqvy, child number 1
select /*+ GATHER_PLAN_STATISTICS */ mod(lastinstmessagesequence, :"SYS_B_0") LastInstIDSeqNo from
tibex_msgseqbyuseralias where useralias=:"SYS_B_1"
Plan hash value: 1955857846
Plan hash value: 1955857846
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
| 1 | SORT GROUP BY NOSORT | | 1 | 21 | 0 |00:00:00.12 | 8545 |
| 2 | VIEW | | 1 | 21 | 0 |00:00:00.12 | 8545 |
| 3 | UNION-ALL | | 1 | | 0 |00:00:00.12 | 8545 |
| 4 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.10 | 5496 |
|* 5 | TABLE ACCESS FULL | TIBEX_QUOTE | 1 | 21056 | 0 |00:00:00.10 | 5496 |
| 6 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 4 |
| 7 | TABLE ACCESS BY INDEX ROWID| TIBEX_ORDER | 1 | 660 | 0 |00:00:00.01 | 4 |
|* 8 | INDEX RANGE SCAN | TIBEX_ORDER_IDX_OLT | 1 | 660 | 0 |00:00:00.01 | 4 |
| 9 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
|* 10 | TABLE ACCESS FULL | TIBEX_TSTRADE | 1 | 1 | 0 |00:00:00.01 | 3 |
| 11 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
|* 12 | TABLE ACCESS FULL | TIBEX_IOIREQUEST | 1 | 1 | 0 |00:00:00.01 | 3 |
| 13 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 126 |
|* 14 | TABLE ACCESS FULL | TIBEX_BESTEXREL | 1 | 1 | 0 |00:00:00.01 | 126 |
| 15 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.02 | 2862 |
|* 16 | INDEX FAST FULL SCAN | SYS_C0058325 | 1 | 339 | 0 |00:00:00.02 | 2862 |
| 17 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 31 |
|* 18 | TABLE ACCESS FULL | TIBEX_EDPPULLORDERS | 1 | 1 | 0 |00:00:00.01 | 31 |
| 19 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 20 | INDEX RANGE SCAN | SYS_C0058803 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 21 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 22 | INDEX RANGE SCAN | SYS_C0057785 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 23 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 24 | INDEX RANGE SCAN | SYS_C0057827 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 25 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
|* 26 | TABLE ACCESS FULL | TIBEX_DELETEADMIN | 1 | 1 | 0 |00:00:00.01 | 3 |
| 27 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 28 | INDEX RANGE SCAN | SYS_C0058148 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 29 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
PLAN_TABLE_OUTPUT
|* 30 | INDEX RANGE SCAN | SYS_C0058264 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 31 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 32 | INDEX RANGE SCAN | SYS_C0058516 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 33 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 34 | INDEX RANGE SCAN | SYS_C0058561 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 35 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 36 | INDEX RANGE SCAN | SYS_C0058783 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 37 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 38 | INDEX RANGE SCAN | SYS_C0058977 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 39 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 40 | INDEX RANGE SCAN | SYS_C0058859 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 41 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 |
|* 42 | INDEX RANGE SCAN | SYS_C0059197 | 1 | 1 | 0 |00:00:00.01 | 1 |
| 43 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
|* 44 | TABLE ACCESS FULL | TIBEX_CANCELTRDADMIN | 1 | 1 | 0 |00:00:00.01 | 3 |
| 45 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 |
|* 46 | TABLE ACCESS FULL | TIBEX_BULKCANCELADMIN | 1 | 1 | 0 |00:00:00.01 | 3 |
Predicate Information (identified by operation id):
5 - filter("LASTINSTUSERALIAS"=:SYS_B_1)
8 - access("LASTINSTUSERALIAS"=:SYS_B_1)
10 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
12 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
14 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
16 - filter("USERALIAS"=:SYS_B_1)
18 - filter("USERALIAS"=:SYS_B_1)
20 - access("USERALIAS"=:SYS_B_1)
22 - access("USERALIAS"=:SYS_B_1)
24 - access("USERALIAS"=:SYS_B_1)
26 - filter(("USERALIAS" IS NOT NULL AND "USERALIAS"=:SYS_B_1))
28 - access("USERALIAS"=:SYS_B_1)
30 - access("USERALIAS"=:SYS_B_1)
32 - access("USERALIAS"=:SYS_B_1)
34 - access("USERALIAS"=:SYS_B_1)
36 - access("USERALIAS"=:SYS_B_1)
38 - access("USERALIAS"=:SYS_B_1)
40 - access("USERALIAS"=:SYS_B_1)
42 - access("USERALIAS"=:SYS_B_1)
44 - filter("USERALIAS"=:SYS_B_1)
46 - filter("USERALIAS"=:SYS_B_1)
SQL_ID bpxr7axhxaqvy, child number 2
select /*+ GATHER_PLAN_STATISTICS */ mod(lastinstmessagesequence, :"SYS_B_0") LastInstIDSeqNo from
tibex_msgseqbyuseralias where useralias=:"SYS_B_1"
Plan hash value: 1955857846
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads |
| 1 | SORT GROUP BY NOSORT | | 1 | 21 | 1 |00:00:00.13 | 8476 | 3 |
| 2 | VIEW | | 1 | 21 | 1 |00:00:00.13 | 8476 | 3 |
| 3 | UNION-ALL | | 1 | | 1 |00:00:00.13 | 8476 | 3 |
| 4 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.10 | 5283 | 0 |
|* 5 | TABLE ACCESS FULL | TIBEX_QUOTE | 1 | 21056 | 0 |00:00:00.10 | 5283 | 0 |
| 6 | SORT GROUP BY NOSORT | | 1 | 1 | 1 |00:00:00.01 | 148 | 3 |
| 7 | TABLE ACCESS BY INDEX ROWID| TIBEX_ORDER | 1 | 660 | 150 |00:00:00.01 | 148 | 3 |
PLAN_TABLE_OUTPUT
|* 8 | INDEX RANGE SCAN | TIBEX_ORDER_IDX_OLT | 1 | 660 | 150 |00:00:00.01 | 5 | 0 |
| 9 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 | 0 |
|* 10 | TABLE ACCESS FULL | TIBEX_TSTRADE | 1 | 1 | 0 |00:00:00.01 | 3 | 0 |
| 11 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 | 0 |
|* 12 | TABLE ACCESS FULL | TIBEX_IOIREQUEST | 1 | 1 | 0 |00:00:00.01 | 3 | 0 |
| 13 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 126 | 0 |
|* 14 | TABLE ACCESS FULL | TIBEX_BESTEXREL | 1 | 1 | 0 |00:00:00.01 | 126 | 0 |
| 15 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.02 | 2862 | 0 |
|* 16 | INDEX FAST FULL SCAN | SYS_C0058325 | 1 | 339 | 0 |00:00:00.02 | 2862 | 0 |
| 17 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 31 | 0 |
|* 18 | TABLE ACCESS FULL | TIBEX_EDPPULLORDERS | 1 | 1 | 0 |00:00:00.01 | 31 | 0 |
| 19 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 20 | INDEX RANGE SCAN | SYS_C0058803 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 21 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 22 | INDEX RANGE SCAN | SYS_C0057785 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 23 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 24 | INDEX RANGE SCAN | SYS_C0057827 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 25 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 | 0 |
|* 26 | TABLE ACCESS FULL | TIBEX_DELETEADMIN | 1 | 1 | 0 |00:00:00.01 | 3 | 0 |
| 27 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 28 | INDEX RANGE SCAN | SYS_C0058148 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 29 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 30 | INDEX RANGE SCAN | SYS_C0058264 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 31 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 32 | INDEX RANGE SCAN | SYS_C0058516 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 33 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 34 | INDEX RANGE SCAN | SYS_C0058561 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 35 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 36 | INDEX RANGE SCAN | SYS_C0058783 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 37 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 38 | INDEX RANGE SCAN | SYS_C0058977 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 39 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 40 | INDEX RANGE SCAN | SYS_C0058859 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 41 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
|* 42 | INDEX RANGE SCAN | SYS_C0059197 | 1 | 1 | 0 |00:00:00.01 | 1 | 0 |
| 43 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 | 0 |
|* 44 | TABLE ACCESS FULL | TIBEX_CANCELTRDADMIN | 1 | 1 | 0 |00:00:00.01 | 3 | 0 |
| 45 | SORT GROUP BY NOSORT | | 1 | 1 | 0 |00:00:00.01 | 3 | 0 |
|* 46 | TABLE ACCESS FULL | TIBEX_BULKCANCELADMIN | 1 | 1 | 0 |00:00:00.01 | 3 | 0 |
Predicate Information (identified by operation id):
5 - filter("LASTINSTUSERALIAS"=:SYS_B_1)
8 - access("LASTINSTUSERALIAS"=:SYS_B_1)
10 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
12 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
14 - filter(("LASTINSTUSERALIAS" IS NOT NULL AND "LASTINSTUSERALIAS"=:SYS_B_1))
16 - filter("USERALIAS"=:SYS_B_1)
18 - filter("USERALIAS"=:SYS_B_1)
20 - access("USERALIAS"=:SYS_B_1)
22 - access("USERALIAS"=:SYS_B_1)
24 - access("USERALIAS"=:SYS_B_1)
26 - filter(("USERALIAS" IS NOT NULL AND "USERALIAS"=:SYS_B_1))
28 - access("USERALIAS"=:SYS_B_1)
30 - access("USERALIAS"=:SYS_B_1)
32 - access("USERALIAS"=:SYS_B_1)
34 - access("USERALIAS"=:SYS_B_1)
36 - access("USERALIAS"=:SYS_B_1)
38 - access("USERALIAS"=:SYS_B_1)
PLAN_TABLE_OUTPUT
40 - access("USERALIAS"=:SYS_B_1)
42 - access("USERALIAS"=:SYS_B_1)
44 - filter("USERALIAS"=:SYS_B_1)
46 - filter("USERALIAS"=:SYS_B_1)
249 rows selected. -
Query take more time to execute
Hi
I am using in sql select statement two non exist statements it is taken more time to execute the query ,non exist is any impact query performance
thank's[email protected] wrote:
I am using in sql select statement two non exist statements it is taken more time to execute the query ,non exist is any impact query performanceI have a query that is using even more time to execute. Do I win? -
Hi,
My database in 10g(10.2.0.4), I fire delete query which deletes 5 Lacs records from the table but it is taking more time to delete.
My table and indexes on that table in Nologging mode, Database in Archive Log Mode.
Can you please help to minize the time?
Execution Plan
0 DELETE STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=62)
1 0 DELETE OF 'CORP_MESSAGEQUEUE'
2 1 INDEX (RANGE SCAN) OF 'INDEX_CORP_MESSAGEQUEUE_PROC' (IN
DEX) (Cost=2 Card=1 Bytes=62)
Statistics
754 recursive calls
635137 db block gets
4773 consistent gets
181579 physical reads
268073944 redo size
630 bytes sent via SQL*Net to client
608 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
1 sorts (memory)
4 sorts (disk)
483328 rows processed
AnandEven if the table is in nologing mode there will be redo generated for the DML. It is clear from your statistics that redo is being generated for the delete. Loging is only effective for few of the operations as given bellow. I think there is no issue with the query the redo and undo generation is taking time. Just tune your configuration like.
No redo log files.
size of redo log.
Undo tablespace size.
undo retentation.
Pga_aggrigate_target.
temporary tablespace sizing.
754 recursive calls
635137 db block gets
4773 consistent gets
181579 physical reads
**268073944 redo size**
630 bytes sent via SQL*Net to client
608 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
1 sorts (memory)
4 sorts (disk)
483328 rows processed
NOLOGGING: Oracle will generate a minimal number of redo log entries in order to protect the data dictionary, and the operation will probably run faster. Logging can be disabled at the table level or the tablespace level.
If it is done at the tablespace level then we create indexes or tables in this tablespace; they will be in NOLOGGING mode.
A table or an index can be created with NOLOGGING mode or it can be altered using ALTER TABLE/INDEX NOLOGGING.
NOLOGGING is active in the following situations and while running one of the following commands but not after that.
- DIRECT LOAD (SQL*Loader)
- DIRECT LOAD INSERT (using APPEND hint)
- CREATE TABLE ... AS SELECT
- CREATE INDEX
- ALTER TABLE MOVE
- ALTER TABLE ... MOVE PARTITION
- ALTER TABLE ... SPLIT PARTITION
- ALTER TABLE ... ADD PARTITION (if HASH partition)
- ALTER TABLE ... MERGE PARTITION
- ALTER TABLE ... MODIFY PARTITION, ADD SUBPARTITON, COALESCE SUBPARTITON, REBUILD UNUSABLE INDEXES
- ALTER INDEX ... SPLIT PARTITION
- ALTER INDEX ... REBUILD
- ALTER INDEX ... REBUILD PARTITION
Logging is stopped only while one of the commands above is running.
So if a user runs this:
ALTER INDEX new_index NOLOGGING.
The actual rebuild of the index does not generate redo (all data dictionary changes associated with the rebuild will do) but after that any DML on the index will generate redo this includes direct load insert on the table which the index belongs to.
All the following statements will generate redo despite the fact the table is in NOLOGGING mode:
- INSERT INTO new_table_nolog_test ...,
- UPDATE new_table_nolog_test SET ...,
- DELETE FROM new_table_nolog_test ..
The following will not generate redo (except from dictionary changes and indexes):
- INSERT /*APPEND/ ...
- ALTER TABLE new_table_nolog_test MOVE ...
- ALTER TABLE new_table_nolog_test MOVE PARTITION ...
practicle example:
SQL> select value OLD_VALUE
from v$mystat, v$statname
where v$mystat.statistic# = v$statname.statistic#
and v$statname.name = 'redo size'; 2 3 4
OLD_VALUE
0
SQL> /
OLD_VALUE
0
SQL>
SQL> create table T_NOLOG nologging as select * from all_objects;
Table created.
SQL> select (value - &OLD_VALUE) OLD_VALUE
from v$mystat, v$statname
where v$mystat.statistic# = v$statname.statistic#
and v$statname.name = 'redo size'; 2 3 4
Enter value for old_value: 0
old 1: select (value - &OLD_VALUE) OLD_VALUE
new 1: select (value - 0) OLD_VALUE
OLD_VALUE
91848
SQL> delete from T_NOLOG ;
106229 rows deleted.
SQL> select (value - &OLD_VALUE) OLD_VALUE
from v$mystat, v$statname
where v$mystat.statistic# = v$statname.statistic#
and v$statname.name = 'redo size'; 2 3 4
Enter value for old_value: 91848
old 1: select (value - &OLD_VALUE) OLD_VALUE
new 1: select (value - 91848) OLD_VALUE
OLD_VALUE
39389988
SQL> -
Hi,
My emp table contains one milion of records.
delete from emp;
commit;
select count(*)
from emp;
I had perform the above three queries parallely. After applying the commit operation, To retrive the no.of records
in that table it takes some more time after that it display the result zero.
I have faced this question recently in one of the interview. why it is taking some more time..
can any one help me?Did you read the link provided?
A high water mark is the set of blocks that have at one point contained data. You
might have 1000 blocks allocated to a table but only 500 are under the HWM.
The blocks under the HWM are the blocks that will be read when the table is full scanned. In your sample code, when you insert 1Milion records, the data will reside in some number of blocks - Say 1000. Now the HWM is 1000. When you delete the data, HWM will not get reset..
And after delete, when you count, a FULL TABLE SCAN will happen. Which will scan all the blocks under HWM. So, here 1000 blocks will get read, even if there is no "data". That way your query will take time..
Whats the solution? - Do a TRUNCATE or do a SHRINK.
NOW - Tell us - What is your concern? -
Iam having nearly 2 crores records at present in my table..
I want to get the avg of price from my table..
i put the query like
select avg(sum(price)) from table group by product_id
The query taking more than 5 mins to execute...
is that any other way i can simplify my query?Warren:
Your first query gives:
SQL> SELECT AVG(SUM(price)) sum_price
2 FROM t;
SELECT AVG(SUM(price)) sum_price
ERROR at line 1:
ORA-00978: nested group function without GROUP BYand your second gives:
SQL> SELECT product_id, AVG(SUM(price))
2 FROM t
3 GROUP BY product_id;
SELECT product_id, AVG(SUM(price))
ERROR at line 1:
ORA-00937: not a single-group group functionSymon:
What exactly are you ttrying to accomplish. Your query as posted will calculate the average of the sums of the prices for all product_id values. That is, it is equivalent to:
SELECT AVG(sum_price)
FROM (SELECT SUM(price) sum_price
FROM t
GROUP BY product_id)So given:
SQL> SELECT * FROM t;
PRODUCT_ID PRICE
PROD1 5
PROD1 7
PROD1 10
PROD2 3
PROD2 4
PROD2 5The sum of the prices per product_id is:
SQL> SELECT SUM(price) sum_price
2 FROM t
3 GROUP BY product_id;
SUM_PRICE
22
12 and the average of that is (22 + 12) / 2 = 17. Is that what you are looking for? If so, then the equivalent query I posted above is at least clearer, but may not be any faster. If this is not what you are looking for, then some sample data and expected results may help. Although, it appears that you need to full scan the table in either case, so that may be as good as it gets.
John -
BIREQU_* job consuming more time in R/3 Source system
Hi Experts,
I am performance issues while extracting data from SAP R/3, after upgrade to oracle.
R/3 job BIREQU_* takes more time in selection of data.
Particularly in step
**02.08.2008 15:32:38 ***************************************************************************
*02.08.2008 16:37:04 533 LUWs confirmed and 533 LUWs to be deleted with function module RSC2_QOUT_CONFIRM_DATA*
02.08.2008 15:32:38 Job started
02.08.2008 15:32:38 Step 001 started (program SBIE0001, variant &0000000013512, user ID BW_BG)
02.08.2008 15:32:38 Asynchronous transmission of info IDoc 2 in task 0001 (0 parallel tasks)
02.08.2008 15:32:38 DATASOURCE = 0UC_BILLORD
02.08.2008 15:32:38 *************************************************************************
02.08.2008 15:32:38 * Current Values for Selected Profile Parameters *
02.08.2008 15:32:38 *************************************************************************
02.08.2008 15:32:38 * abap/heap_area_nondia......... 2000683008 *
02.08.2008 15:32:38 * abap/heap_area_total.......... 2000683008 *
02.08.2008 15:32:38 * abap/heaplimit................ 40894464 *
02.08.2008 15:32:38 * zcsa/installed_languages...... DEN *
02.08.2008 15:32:38 * zcsa/system_language.......... N *
02.08.2008 15:32:38 * ztta/max_memreq_MB............ 2047 *
02.08.2008 15:32:38 * ztta/roll_area................ 6500352 *
02.08.2008 15:32:38 * ztta/roll_extension........... 2000683008 *
02.08.2008 15:32:38 *************************************************************************
02.08.2008 16:37:04 533 LUWs confirmed and 533 LUWs to be deleted with function module RSC2_QOUT_CONFIRM_DATA
02.08.2008 16:38:18 Call customer enhancement BW_BTE_CALL_BW204010_E (BTE) with 6.597 records
02.08.2008 16:38:18 Result of customer enhancement: 6.597 records
02.08.2008 16:38:18 Call customer enhancement EXIT_SAPLRSAP_001 (CMOD) with 6.597 records
02.08.2008 16:38:18 Result of customer enhancement: 6.597 records
02.08.2008 16:38:18 Asynchronous send of data package 1 in task 0002 (1 parallel tasks)
02.08.2008 16:38:18 IDOC: Info IDoc 2, IDoc No. 3256989, Duration 00:00:00
02.08.2008 16:38:18 IDoc: Start = 02.08.2008 15:32:38, End = 02.08.2008 15:32:38
02.08.2008 16:38:19 Altogether, 0 records were filtered out through selection conditions
02.08.2008 16:38:19 Asynchronous transmission of info IDoc 3 in task 0003 (1 parallel tasks)
02.08.2008 16:38:19 IDOC: Info IDoc 3, IDoc No. 3256996, Duration 00:00:00
02.08.2008 16:38:19 IDoc: Start = 02.08.2008 16:38:19, End = 02.08.2008 16:38:19
02.08.2008 16:38:28 tRFC: Data Package = 1, TID = 0AB50A6764EE4894715A019E, Duration = 00:00:10, ARFCSTATE =
02.08.2008 16:38:28 tRFC: Start = 02.08.2008 16:38:18, End = 02.08.2008 16:38:28
02.08.2008 16:38:28 Synchronized transmission of info IDoc 4 (0 parallel tasks)
02.08.2008 16:38:29 IDOC: Info IDoc 4, IDoc No. 3256997, Duration 00:00:01
02.08.2008 16:38:29 IDoc: Start = 02.08.2008 16:38:28, End = 02.08.2008 16:38:29
02.08.2008 16:38:29 Job finished
I am facing this problem while extracting data in case of Delta uploads.
for full uploads it is working fine.
What might be the problem,
Please advice.Hi all,
Does anyone of you got the solution for the original problem ?
Step taking too long to finish?
n LUWs confirmed and n LUWs to be deleted with function module RSC2_QOUT_CONFIRM_DATA
Regards,
Sanjyot
Edited by: Surekha Shembekar/ Sanjyot Mishra on Jul 14, 2009 9:07 AM -
Query Take more time on timesten
Hi
One query takes lot of time on timesten , while the same query takes less time on oracle
Query :-
select *
from (SELECT RELD_EM_ENTITY_ID,
RELD_EXM_EXCH_ID,
RELD_SEGMENT_TYPE,
NVL(RELD_ACC_TYPE, 0) ACC_TYPE, --END ASHA
ROUND(NVL(sum(RELD_RTO_EXP), -1), 2) RTO_EXP,
ROUND(NVL(sum(RELD_NE_EXP), -1), 2) NET_EXP,
ROUND(NVL(sum(RELD_MAR_UTILIZATION), -1),
2) MAR_EXP,
ROUND(decode(sign(sum(C.reld_m2m_exp)),
-1,
abs(sum(C.reld_m2m_exp)),
0),
2) M2M_EXP,
NVL(OLM_SUSPNSN_FLG, 'A') SUSPNSN_FLG,
EM_RP_PROFILE_ID
FROM ENTITY_MASTER A,
ORDER_LMT_MASTER B,
RMS_ENTITY_LIMIT_DTLS C
WHERE A.EM_CONTROLLER_ID = 100100010000
AND A.EM_ENTITY_ID = C.RELD_EM_ENTITY_ID
AND C.RELD_EM_ENTITY_ID = B.OLM_EPM_EM_ENTITY_ID(+)
AND C.RELD_SEGMENT_TYPE = 'E'
AND C.RELD_EXM_EXCH_ID = B.OLM_EXCH_ID(+)
AND C.RELD_EXM_EXCH_ID <> 'ALL'
AND B.OLM_SEM_SMST_SECURITY_ID(+) =
'ALL'
AND ((A.EM_ENTITY_TYPE IN ('CL') AND
A.EM_CLIENT_TYPE <> 'CC') OR
A.EM_ENTITY_TYPE <> 'CL')
AND B.OLM_PRODUCT_ID(+) = 'M' --Added by Harshit Shah on 4th June 09
GROUP BY RELD_EM_ENTITY_ID,
RELD_EXM_EXCH_ID,
RELD_SEGMENT_TYPE,
RELD_ACC_TYPE,
OLM_SUSPNSN_FLG,
EM_RP_PROFILE_ID,
OLM_PRODUCT_ID
UNION --union all removed by pramod on 08-jan-2012 as it was giving multiple rows
SELECT RELD_EM_ENTITY_ID,
RELD_EXM_EXCH_ID,
RELD_SEGMENT_TYPE SEGMENTID,
NVL(RELD_ACC_TYPE, 0) ACC_TYPE, --END ASHA
ROUND(NVL(SUM(RELD_RTO_EXP), -1), 2) RTO_EXP,
ROUND(NVL(SUM(RELD_NE_EXP), -1), 2) NET_EXP,
ROUND(NVL(SUM(RELD_MAR_UTILIZATION), -1),
2) MAR_EXP,
ROUND(decode(sign(SUM(C.reld_m2m_exp)),
-1,
abs(SUM(C.reld_m2m_exp)),
0),
2) M2M_EXP,
NVL(OLM_SUSPNSN_FLG, 'A') SUSPNSN_FLG,
EM_RP_PROFILE_ID
FROM ENTITY_MASTER A,
ORDER_LMT_MASTER B,
RMS_ENTITY_LIMIT_DTLS C
WHERE A.EM_CONTROLLER_ID = 100100010000
AND A.EM_ENTITY_ID = B.OLM_EPM_EM_ENTITY_ID
AND B.OLM_EPM_EM_ENTITY_ID = C.RELD_EM_ENTITY_ID(+)
AND C.RELD_SEGMENT_TYPE = 'E'
AND B.OLM_EXCH_ID = 'ALL'
AND B.OLM_SEM_SMST_SECURITY_ID(+) =
'ALL'
AND ((A.EM_ENTITY_TYPE IN ('CL') AND
A.EM_CLIENT_TYPE <> 'CC') OR
A.EM_ENTITY_TYPE <> 'CL')
AND B.OLM_PRODUCT_ID(+) = 'M' --Added by Harshit Shah on 4th June 09
GROUP BY RELD_EM_ENTITY_ID,
RELD_EXM_EXCH_ID,
RELD_SEGMENT_TYPE,
RELD_ACC_TYPE,
OLM_SUSPNSN_FLG,
EM_RP_PROFILE_ID,
OLM_PRODUCT_ID
UNION --union all removed by pramod on 08-jan-2012 as it was giving multiple rows
SELECT RELD_EM_ENTITY_ID,
RELD_EXM_EXCH_ID,
RELD_SEGMENT_TYPE,
NVL(RELD_ACC_TYPE, 0) ACC_TYPE, --END ASHA
ROUND(NVL(sum(RELD_RTO_EXP), -1), 2) RTO_EXP,
ROUND(NVL(sum(RELD_NE_EXP), -1), 2) NET_EXP,
ROUND(NVL(sum(RELD_MAR_UTILIZATION), -1),
2) MAR_EXP,
ROUND(decode(sign(sum(C.reld_m2m_exp)),
-1,
abs(sum(C.reld_m2m_exp)),
0),
2) M2M_EXP,
NVL(OLIM_SUSPNSN_FLG, 'A') SUSPNSN_FLG,
EM_RP_PROFILE_ID
FROM ENTITY_MASTER A,
DRV_ORDER_INST_LMT_MASTER B,
RMS_ENTITY_LIMIT_DTLS C
WHERE A.EM_CONTROLLER_ID = 100100010000
AND A.EM_ENTITY_ID = C.RELD_EM_ENTITY_ID
AND C.RELD_EM_ENTITY_ID =
B.OLIM_EPM_EM_ENTITY_ID(+)
AND C.RELD_SEGMENT_TYPE = 'D'
AND C.RELD_EXM_EXCH_ID = B.OLIM_EXCH_ID(+)
AND C.RELD_EXM_EXCH_ID <> 'ALL'
AND B.OLIM_INSTRUMENT_ID(+) = 'ALL'
AND ((A.EM_ENTITY_TYPE IN ('CL') AND
A.EM_CLIENT_TYPE <> 'CC') OR
A.EM_ENTITY_TYPE <> 'CL')
GROUP BY RELD_EM_ENTITY_ID,
RELD_EXM_EXCH_ID,
RELD_SEGMENT_TYPE,
RELD_ACC_TYPE,
OLIM_SUSPNSN_FLG,
EM_RP_PROFILE_ID
UNION --union all removed by pramod on 08-jan-2012 as it was giving multiple rows
SELECT RELD_EM_ENTITY_ID,
RELD_EXM_EXCH_ID,
RELD_SEGMENT_TYPE SEGMENTID,
NVL(RELD_ACC_TYPE, 0) ACC_TYPE, --END ASHA
ROUND(NVL(SUM(RELD_RTO_EXP), -1), 2) RTO_EXP,
ROUND(NVL(SUM(RELD_NE_EXP), -1), 2) NET_EXP,
ROUND(NVL(SUM(RELD_MAR_UTILIZATION), -1),
2) MAR_EXP,
ROUND(decode(sign(SUM(C.reld_m2m_exp)),
-1,
abs(SUM(C.reld_m2m_exp)),
0),
2) M2M_EXP,
NVL(OLIM_SUSPNSN_FLG, 'A') SUSPNSN_FLG,
EM_RP_PROFILE_ID
FROM ENTITY_MASTER A,
DRV_ORDER_INST_LMT_MASTER B,
RMS_ENTITY_LIMIT_DTLS C
WHERE A.EM_CONTROLLER_ID = 100100010000
AND A.EM_ENTITY_ID = B.OLIM_EPM_EM_ENTITY_ID
AND B.OLIM_EPM_EM_ENTITY_ID =
C.RELD_EM_ENTITY_ID(+)
AND C.RELD_SEGMENT_TYPE = 'D'
AND B.OLIM_EXCH_ID = 'ALL'
AND B.OLIM_INSTRUMENT_ID(+) = 'ALL'
AND ((A.EM_ENTITY_TYPE IN ('CL') AND
A.EM_CLIENT_TYPE <> 'CC') OR
A.EM_ENTITY_TYPE <> 'CL')
GROUP BY RELD_EM_ENTITY_ID,
RELD_EXM_EXCH_ID,
RELD_SEGMENT_TYPE,
RELD_ACC_TYPE,
OLIM_SUSPNSN_FLG,
EM_RP_PROFILE_ID)
ORDER BY RELD_EM_ENTITY_ID,
RELD_SEGMENT_TYPE,
RELD_EXM_EXCH_ID;
Please suggest what should i check for this.As always when examining SQL performance, start by checking the query execution plan. If you use ttIsql you can just prepend EXPLAIN to the query and the plan will be displayed. e.g.
EXPLAIN select ...........;
Check the plan is optimal and all necessary indexes are in place. You may need to add indexes depending o what the plan shows.
Please note that Oracle database can, and usually does, execute many types of query in parallel using multiple CPU cores. TimesTen does not currently support parallelisation of individual queries. Hence in some cases Oracle database may indeed be faster than TimesTen due to the parallel execution that occurs in Oracle.
Chris -
Oracle query taking more time in SSRS
Hi All
we have report which connects to Orale DB . the Query for the datset is running in 9 Secs in PL/sql developer but the same query is taking more than 150 secs in SSRS. we are using Oracleclient type provider.
Surendra ThotaHi Surendra,
Based on the current description, I understand that you may use Oracle Provider for OLE DB to connect Oracle database. If so, I suggest you using Microsoft OLE DB Provider for Oracle to compare the query time between SQLPlus and SSRS.
Here is a relative thread (SSRS Report with Oracle database performance problems) for your reference.
Hope this helps.
Regards,
Heidi Duan
If you have any feedback on our support, please click
here.
Heidi Duan
TechNet Community Support -
Query takes more time from client
Hi,
I have a select query (which refers to views and calls a function), which fetches results in 2 secs when executed from database. But takes more than 10 mins from the client.
The tkprof for the call from the client is given below. Could you please suggest, what is going wrong and how this can be addressed?
The index IDX_table1_1 is on col3.
Trace file: trace_file.trc
Sort options: exeela
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
SELECT ROUND(SUM(NVL((col1-col2),(SYSDATE - col2)
FROM
table1 WHERE col3 = :B1 GROUP BY col3
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 7402 0.27 7.40 0 0 0 0
Fetch 7402 1.13 59.37 1663 22535 0 7335
total 14804 1.40 66.77 1663 22535 0 7335
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 32 (ORADBA) (recursive depth: 1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 SORT (GROUP BY NOSORT)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'table1'
(TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'IDX_table1_1'
(INDEX)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 1663 1.37 57.71
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 0 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 16039 3.09 385.04
db file scattered read 34 0.21 1.42
latch: cache buffers chains 26 0.34 2.14
SQL*Net break/reset to client 2 0.05 0.05
SQL*Net message to client 2 0.00 0.00
SQL*Net message from client 2 79.99 79.99
SQL*Net message to dblink 1 0.00 0.00
SQL*Net message from dblink 1 0.00 0.00
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 7402 0.27 7.40 0 0 0 0
Fetch 7402 1.13 59.37 1663 22535 0 7335
total 14804 1.40 66.77 1663 22535 0 7335
Misses in library cache during parse: 0
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 1663 1.37 57.71
1 user SQL statements in session.
0 internal SQL statements in session.
1 SQL statements in session.
1 statement EXPLAINed in this session.
Trace file: trace_file.trc
Trace file compatibility: 10.01.00
Sort options: exeela
1 session in tracefile.
1 user SQL statements in trace file.
0 internal SQL statements in trace file.
1 SQL statements in trace file.
1 unique SQL statements in trace file.
1 SQL statements EXPLAINed using schema:
ORADBA.prof$plan_table
Default table was used.
Table was created.
Table was dropped.
84792 lines in trace file.
4152 elapsed seconds in trace file.Edited by: agathya on Feb 26, 2010 8:39 PMI have a select query (which refers to views and calls a function), which fetches results in 2 secs when >executed from database. But takes more than 10 mins from the client.You are providing proof for the latter part of your statement above.
But not for the former part (fetches in 2 secs when exec'd from db).
It would have been nice if you also provide the sql-trace information for that.
Without it we cannot help you much. Other than making the observation that you obviously have a query that is I/O bound, and that I/O on your system is rather slow: on average an I/O takes 0.04 seconds (66.77 divided by 1663).
Maybe you are looking for
-
Hello, I would like to find out if it possible to wipe out harddrive(format win8.1) on my new laptop GT72 Dom pro and install fresh windows 7 ultimate(i have dvd)? And if its possible how? Thank you
-
Home Sharing only HD TV shows. Possible?
I have a large (800GB+) iTunes library on one dedicated Mac mini. I have another, older Mac mini hooked up to one of my TVs as a makeshift AppleTV (my AppleTV video card died of heat failure - white spots). Since the older Mac mini only has a 250GB h
-
Why is this photo not staying where I place it?
I have a photo basically of a wood frame that I want to put around a youtube video. It works on all browsers except chrome. check it out http://logrenew.com/pictures-and-videos.html Does anyone know why this is happening?
-
Pages will only load as mobile
When I first upgraded to FF6 the problem started. Some sites (yahoo, foxsports, ehow, wikipedia) will only load as mobile pages. Ive recently upgraded to FF14 and still the problem persists. Ive uninstalled and reinstalled, reset to factory and check
-
Am I the oddball Mac Pro buyer?
I ordered a Mac Pro not for professional applications not for video editing but for games. I love gaming on a mac. I think its fun to head to a lan party and bring along my mac. Right now I have a MacBook Pro I got in Feb (replaced my PowerBook G4) W