Query take more time
hi all ,
can you please advice me in my plans
i have query run daily as a job it take 3 minute always
but today it takes 1:10 hours why this happen i see the jobs there is no other job running in the time of this query run
by the way can you tell me what i need to check ??????
MANY THANKS
Hi,
when query's performance changes like that, the primary suspect is a change in the execution plan. You can use this query to check this:
select begin_interval_time, plan_hash_value
from dba_hist_snapshot sn,
dba_hist_sqlstat st
where sn.snap_id = st.snap_id
and sql_id = <sql_id here>
order by begin_interval_time desc;Once you confirm that this is due to a change in the execution plan (there other scenarios possible, but less likely), you can start looking why the change
occured.
Most common causes are change in statistics, appearance or removal of histograms, or bind variables peeking unusual values.
Best regards,
Nikolay
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 -
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 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 -
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). -
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? -
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> -
Function returning query takes more time to run in Apex4.0
Hi All,
I created a report using function returning query. The function returns query based the parameters which returns dynamic columns. When I run the query in sql developer the query generates and returns the result in 3mins. But in apex it takes maximum of 35mins to return.
The query will return around 10000 rows.
Is it a performance issue in the query or in Apex?can anyone please help
Regards
RajRajEndiran wrote:
Hi Roel,
Thanks much for your suggestion. I run in TOAD and got the result as
Row 1 of 500 fetched so far in 3.31 minutes which means it queried for 500 records alone ? is that not the actual time taken to run the fulll query?That reflects the time to return the first 500 records...
Please suggest.With all the best will in the world, if I was your user and I had to wait 3 minutes for the page to refresh, I'd steadily lose the will to live!
As this is primarily an SQL tuning question, have a look at this message in the FAQ thread in the {forum:id=75} forum:
{message:id=9360003}
That should give you some pointers on the right approach. -
Hi all
I want to fetch just twenty thousands records from table. My query take more time to fetch twenty thousands records. I post my working query, Could you correct the query for me. thanks in advance.
Query
select
b.Concatenated_account Account,
b.Account_description description,
SUM(case when(Bl.ACTUAL_FLAG='B') then
((NVL(Bl.PERIOD_NET_DR, 0)- NVL(Bl.PERIOD_NET_CR, 0)) + (NVL(Bl.PROJECT_TO_DATE_DR, 0)- NVL(Bl.PROJECT_TO_DATE_CR, 0)))end) "Budget_2011"
from
gl_balances Bl,
gl_code_combinations GCC,
psb_ws_line_balances_i b ,
gl_budget_versions bv,
gl_budgets_v gv
where
b.CODE_COMBINATION_ID=gcc.CODE_COMBINATION_ID and bl.CODE_COMBINATION_ID=gcc.CODE_COMBINATION_ID and
bl.budget_version_id =bv.BUDGET_VERSION_ID and gv.budget_version_id= bv.budget_version_id
and gv.latest_opened_year in (select latest_opened_year-3 from gl_budgets_v where latest_opened_year=:BUDGET_YEAR )
group by b.Concatenated_account ,b.Account_descriptionHi,
If this question is related to SQL then please post in SQL forum.
Otherwise provide more information how this sql is being used and do you want to tune the SQL or the way it fetches the information from DB and display in OAF.
Regards,
Sandeep M. -
Optimizing the query - which takes more time
Hi,
Am having a query which was returning the results pretty fast one week back but now the same query takes more time to respond, nothing much changed in the table data, what could be the problem. Am using IN in the where clause, whether that could be an issue? if so what is the best method of rewriting the query.
SELECT RI.RESOURCE_NAME,TR.MSISDN,MAX(TR.ADDRESS1_GOOGLE) KEEP(DENSE_RANK LAST ORDER BY TR.MSG_DATE_INFO) ADDRESS1_GOOGLE,
MAX(TR.TIME_STAMP) MSG_DATE_INFO FROM TRACKING_REPORT TR, RESOURCE_INFO RI
WHERE TR.MSISDN IN ( SELECT MSISDN FROM RESOURCE_INFO WHERE GROUP_ID ='4'
AND COM_ID='12') AND RI.MSISDN = TR.MSISDN
GROUP BY RI.RESOURCE_NAME,TR.MSISDN ORDER BY MSG_DATE_INFO DESCHi
i have followed this link http://www.lorentzcenter.nl/awcourse/oracle/server.920/a96533/sqltrace.htm in enabling the trace and found out the following trace output, can you explain the problem here and its remedial action pls.
SELECT RI.RESOURCE_NAME,TR.MSISDN,MAX(TR.ADDRESS1_GOOGLE) KEEP(DENSE_RANK
LAST ORDER BY TR.MSG_DATE_INFO) ADDRESS1_GOOGLE, MAX(TR.TIME_STAMP)
MSG_DATE_INFO
FROM
TRACKING_REPORT TR, RESOURCE_INFO RI WHERE RI.GROUP_ID ='426' AND
RI.COM_ID='122' AND RI.MSISDN = TR.MSISDN GROUP BY RI.RESOURCE_NAME,
TR.MSISDN
call count cpu elapsed disk query current rows
Parse 1 0.01 0.02 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 6 13.69 389.03 81747 280722 0 72
total 8 13.70 389.05 81747 280722 0 72
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 281
Rows Row Source Operation
72 SORT GROUP BY
276558 NESTED LOOPS
79 TABLE ACCESS FULL RESOURCE_INFO
276558 TABLE ACCESS BY INDEX ROWID TRACKING_REPORT
276558 INDEX RANGE SCAN TR_INDX_ON_MSISDN_TIME (object id 60507)
********************************************************************************and the plan_table output is
STATEMENT_ID TIMESTAMP REMARKS OPERATION OPTIONS OBJECT_NODE OBJECT_OWNER OBJECT_NAME OBJECT_INSTANCE OBJECT_TYPE OPTIMIZER SEARCH_COLUMNS ID PARENT_ID POSITION COST CARDINALITY BYTES OTHER_TAG PARTITION_START PARTITION_STOP PARTITION_ID OTHER DISTRIBUTION CPU_COST IO_COST TEMP_SPACE ACCESS_PREDICATES FILTER_PREDICATES
23-Mar-11 23:36:45 SELECT STATEMENT CHOOSE 0 115 115 1058 111090 115
23-Mar-11 23:36:45 SORT GROUP BY 1 0 1 115 1058 111090 115
23-Mar-11 23:36:45 NESTED LOOPS 2 1 1 9 4603 483315 9
23-Mar-11 23:36:45 TABLE ACCESS FULL BSNL_RTMS RESOURCE_INFO 2 ANALYZED 3 2 1 8 1 30 8 "RI"."GROUP_ID"=426 AND "RI"."COM_ID"='122'
23-Mar-11 23:36:45 TABLE ACCESS BY INDEX ROWID BSNL_RTMS TRACKING_REPORT 1 ANALYZED 4 2 2 1 3293 246975 1
23-Mar-11 23:36:45 INDEX RANGE SCAN BSNL_RTMS TR_INDX_ON_MSISDN_TIME NON-UNIQUE 1 5 4 1 1 3293 1 "RI"."MSISDN"="TR"."MSISDN" -
Automatic DOP take more time to execute query
We upgraded database to oracle 11gR2. While testing Automatic DOP feature with our existing query it takes more time than with parallel.
Note: No constrains or Index created on table to gain performance while loading data (5000records / sec)
Os : Sun Solaris 64bit
CPU = 8
RAM = 7456M
Default parameter settings:
parallel_degree_policy string MANUAL
parallel_degree_limit string CPU
parallel_threads_per_cpu integer 2
arallel_degree_limit string CPU
cpu_count integer 8
parallel_threads_per_cpu integer 2
resource_manager_cpu_allocation integer 8
Query:
SELECT COUNT(*)
from (
SELECT
/*+ FIRST_ROWS(50), PARALLEL */
Query gets executed in 22minutes : execution plan
COUNT(*)
9600
Elapsed: 00:22:10.71
Execution Plan
Plan hash value: 3765539975
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 21 | 2164K (1)| 07:12:52 | | |
| 1 | SORT AGGREGATE | | 1 | 21 | | | | |
| 2 | PARTITION RANGE OR| | 89030 | 1825K| 2164K (1)| 07:12:52 |KEY(OR)|KEY(OR)|
|* 3 | TABLE ACCESS FULL| SUBSCRIBER_EVENT | 89030 | 1825K| 2164K (1)| 07:12:52 |KEY(OR)|KEY(OR)|Automatic DOP Query: parameters set
alter session set PARALLEL_DEGREE_POLICY = limited;
alter session force parallel query ;Query:
SELECT COUNT(*)
from (
SELECT /*+ FIRST_ROWS(50), PARALLEL*/
This query takes more than 2hrs to execute
COUNT(*)
9600
Elapsed: 02:07:48.81
Execution Plan
Plan hash value: 127536830
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart|Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 1 | 21 | 150K (1)| 00:30:01 | | | | | |
| 1 | SORT AGGREGATE | | 1 | 21 | | | | | | | |
| 2 | PX COORDINATOR | | | | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10000 | 1 | 21 | | | | | Q1,00 | P->S | QC (RAND) |
| 4 | SORT AGGREGATE | | 1 | 21 | | | | | Q1,00 | PCWP | |
| 5 | PX BLOCK ITERATOR | | 89030 | 1825K| 150K (1)| 00:30:01 |KEY(OR)|KEY(OR)| Q1,00 | PCWC | |
|* 6 | TABLE ACCESS FULL| SUBSCRIBER_EVENT | 89030 | 1825K| 150K (1)| 00:30:01 |KEY(OR)|KEY(OR)| Q1,00 | PCWP | |
Note
- automatic DOP: Computed Degree of Parallelism is 16 because of degree limitcan some one help us to find out where we did wrong or any pointer will really helpful to resolve an issue.
Edited by: Sachin B on May 11, 2010 4:05 AMGenerated AWR report for ADOP
Foreground Wait Events DB/Inst: HDB/hdb Snaps: 158-161
-> s - second, ms - millisecond - 1000th of a second
-> Only events with Total Wait Time (s) >= .001 are shown
-> ordered by wait time desc, waits desc (idle events last)
-> %Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0
Avg
%Time Total Wait wait Waits % DB
Event Waits -outs Time (s) (ms) /txn time
direct path read 522,173 0 125,051 239 628.4 99.3
db file sequential read 663 0 156 235 0.8 .1
log file sync 165 0 117 712 0.2 .1
Disk file operations I/O 267 0 63 236 0.3 .1
db file scattered read 251 0 36 145 0.3 .0
control file sequential re 217 0 32 149 0.3 .0
library cache load lock 2 0 10 4797 0.0 .0
cursor: pin S wait on X 3 0 9 3149 0.0 .0
read by other session 5 0 2 429 0.0 .0
kfk: async disk IO 613,170 0 2 0 737.9 .0
sort segment request 1 100 1 1007 0.0 .0
os thread startup 16 0 1 43 0.0 .0
direct path write temp 1 0 1 527 0.0 .0
latch free 51 0 0 2 0.1 .0
kksfbc child completion 1 100 0 59 0.0 .0
latch: cache buffers chain 19 0 0 2 0.0 .0
latch: shared pool 36 0 0 1 0.0 .0
PX Deq: Slave Session Stat 21 0 0 1 0.0 .0
library cache: mutex X 45 0 0 1 0.1 .0
CSS initialization 2 0 0 6 0.0 .0
enq: KO - fast object chec 1 0 0 11 0.0 .0
buffer busy waits 3 0 0 1 0.0 .0
cursor: pin S 9 0 0 0 0.0 .0
CSS operation: action 2 0 0 1 0.0 .0
direct path write 1 0 0 2 0.0 .0
jobq slave wait 17,554 100 8,942 509 21.1
PX Deq: Execute Reply 4,060 95 7,870 1938 4.9
SQL*Net message from clien 96 0 5,756 59962 0.1
PX Deq: Execution Msg 618 56 712 1152 0.7
KSV master wait 11 0 0 2 0.0
PX Deq: Join ACK 16 0 0 1 0.0
PX Deq: Parse Reply 14 0 0 1 0.0
Background Wait Events DB/Inst: HDB/hdb Snaps: 158-161
-> ordered by wait time desc, waits desc (idle events last)
-> Only events with Total Wait Time (s) >= .001 are shown
-> %Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0
Avg
%Time Total Wait wait Waits % bg
Event Waits -outs Time (s) (ms) /txn time
control file sequential re 6,249 0 2,375 380 7.5 55.6
control file parallel writ 2,003 0 744 371 2.4 17.4
db file parallel write 1,604 0 503 313 1.9 11.8
log file parallel write 861 0 320 371 1.0 7.5
db file sequential read 363 0 151 415 0.4 3.5
db file scattered read 152 0 64 421 0.2 1.5
Disk file operations I/O 276 0 21 77 0.3 .5
os thread startup 316 0 15 48 0.4 .4
ADR block file read 24 0 11 450 0.0 .3
rdbms ipc reply 17 12 7 403 0.0 .2
Data file init write 6 0 6 1016 0.0 .1
direct path write 21 0 6 287 0.0 .1
log file sync 7 0 6 796 0.0 .1
ADR block file write 10 0 4 414 0.0 .1
enq: JS - queue lock 1 0 3 2535 0.0 .1
ASM file metadata operatio 1,801 0 2 1 2.2 .0
db file parallel read 30 0 1 40 0.0 .0
kfk: async disk IO 955 0 1 1 1.1 .0
db file single write 1 0 0 415 0.0 .0
reliable message 10 0 0 23 0.0 .0
latch: shared pool 75 0 0 2 0.1 .0
latch: call allocation 26 0 0 2 0.0 .0
CSS initialization 7 0 0 6 0.0 .0
asynch descriptor resize 352 100 0 0 0.4 .0
undo segment extension 2 100 0 5 0.0 .0
CSS operation: action 9 0 0 1 0.0 .0
CSS operation: query 42 0 0 0 0.1 .0
latch: parallel query allo 4 0 0 0 0.0 .0
rdbms ipc message 37,948 97 104,599 2756 45.7
DIAG idle wait 16,762 100 16,927 1010 20.2
ASM background timer 1,724 0 8,467 4912 2.1
shared server idle wait 282 100 8,465 30019 0.3
pmon timer 3,123 90 8,465 2711 3.8
wait for unread message on 8,381 100 8,465 1010 10.1
dispatcher timer 141 100 8,463 60019 0.2
Streams AQ: qmn coordinato 604 50 8,462 14010 0.7
Streams AQ: qmn slave idle 304 0 8,462 27836 0.4
smon timer 35 71 8,382 239496 0.0
Space Manager: slave idle 1,621 99 8,083 4986 2.0
PX Idle Wait 2,392 99 4,739 1981 2.9
class slave wait 46 0 623 13546 0.1
KSV master wait 2 0 0 27 0.0
SQL*Net message from clien 7 0 0 1 0.0
Wait Event Histogram DB/Inst: HDB/hdb Snaps: 158-161
-> Units for Total Waits column: K is 1000, M is 1000000, G is 1000000000
-> % of Waits: value of .0 indicates value was <.05%; value of null is truly 0
-> % of Waits: column heading of <=1s is truly <1024ms, >1s is truly >=1024ms
-> Ordered by Event (idle events last)
% of Waits
Total
Event Waits <1ms <2ms <4ms <8ms <16ms <32ms <=1s >1s
ADR block file read 24 100.0
ADR block file write 10 100.0
ADR file lock 12 100.0
ASM file metadata operatio 1812 99.0 .3 .4 .2 .1
CSS initialization 9 100.0
CSS operation: action 11 90.9 9.1
CSS operation: query 54 100.0
Data file init write 6 16.7 16.7 16.7 50.0
Disk file operations I/O 533 88.7 2.6 .6 1.5 .2 6.4
PX Deq: Signal ACK EXT 4 100.0
PX Deq: Signal ACK RSG 2 100.0
PX Deq: Slave Session Stat 21 42.9 28.6 28.6
SQL*Net break/reset to cli 6 100.0
SQL*Net message to client 102 100.0
SQL*Net more data to clien 4 100.0
asynch descriptor resize 527 100.0
buffer busy waits 4 75.0 25.0
control file parallel writ 2003 9.3 .5 .0 .1 90.0
control file sequential re 6466 10.6 .0 .0 .0 .1 .2 89.0
cursor: pin S 9 100.0
cursor: pin S wait on X 3 33.3 33.3 33.3
db file parallel read 30 6.7 30.0 63.3
db file parallel write 1604 7.4 .1 .6 16.5 75.5
db file scattered read 403 3.7 .2 2.5 13.6 14.9 3.5 61.5
db file sequential read 1017 12.3 .8 2.3 7.3 6.6 2.0 68.8
db file single write 1 100.0
direct path read 522.2 2.2 2.1 .1 .0 1.8 17.9 75.9
direct path write 22 4.5 4.5 90.9
direct path write temp 1 100.0
enq: JS - queue lock 1 100.0
enq: KO - fast object chec 1 100.0
enq: PS - contention 1 100.0
kfk: async disk IO 614.1 100.0 .0
kksfbc child completion 1 100.0
latch free 58 46.6 27.6 15.5 10.3
latch: cache buffers chain 19 36.8 10.5 52.6
latch: call allocation 26 76.9 11.5 7.7 3.8
latch: parallel query allo 4 100.0
latch: shared pool 111 44.1 28.8 27.0
library cache load lock 2 100.0
library cache: mutex X 45 84.4 8.9 4.4 2.2
log file parallel write 861 10.0 .1 .1 89.5 .2
log file sync 172 6.4 90.1 3.5
os thread startup 332 100.0
rdbms ipc reply 18 72.2 11.1 16.7
read by other session 5 100.0
reliable message 11 81.8 9.1 9.1
sort segment request 1 100.0
undo segment extension 2 50.0 50.0
ASM background timer 1724 .8 .6 .1 .6 97.9
DIAG idle wait 16.8K 100.0
KSV master wait 13 7.7 23.1 61.5 7.7
PX Deq: Execute Reply 4060 .4 .0 .0 .1 3.4 96.0
PX Deq: Execution Msg 617 34.7 1.5 2.4 1.5 1.5 .2 .8 57.5
PX Deq: Join ACK 16 93.8 6.3
PX Deq: Parse Reply 14 71.4 7.1 14.3 7.1
PX Idle Wait 2384 .0 .6 99.3
SQL*Net message from clien 103 82.5 1.0 1.9 1.0 13.6
Space Manager: slave idle 1621 .2 99.8
Streams AQ: qmn coordinato 604 50.0 50.0
Wait Event Histogram DB/Inst: HDB/hdb Snaps: 158-161
-> Units for Total Waits column: K is 1000, M is 1000000, G is 1000000000
-> % of Waits: value of .0 indicates value was <.05%; value of null is truly 0
-> % of Waits: column heading of <=1s is truly <1024ms, >1s is truly >=1024ms
-> Ordered by Event (idle events last)Edited by: Sachin B on May 11, 2010 4:52 AM -
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 -
How the implementation differs between BW and BI , Is BI takes more time fo
Hi All,
I would like to know difference between implemenation and time lines for MM as mentioned below.
How the implementation differs between BW and BI , Is BI takes more time for implementing MM module than on BW?
Thanks in advanced. (Full points will be awarded)
With Regards,
PCRHi Timo,
Thanks for response!
But as i read from the following url: http://docs.oracle.com/cd/E15051_01/apirefs.1111/e10653/oracle/jbo/ViewObject.html, the setQueryTimeOut(int timeOutMills), the timeOut is mentioned in milliseconds. Please correct me if I am wrong.
and i have overriden the executeQuery() method in the View Object Impl class as shown below:
public void executeQuery() {
Map sessionScope = ADFContext.getCurrent().getSessionScope();
sessionScope.put("MyQuery", this);
try {
super.executeQuery();
} finally {
sessionScope.remove("MyQuery");
throw new JboException("Query Taking too long to respond");
and in the JAVA class i am calling the above method like this:
monitor.setQueryTimeOut(6);
monitor.executeQuery();
But the issue is:
1. The above exception message is getting carried forward to other pages as well. I mean somewhere in the session/ADFContext this message is being saved and error comes up/pops up when i click on other tabs of the page. How do i clear this?
2. The above exception message is coming for the first time but when i click the 'Submit' button second time, i am getting the results and also the message that 'Query is taking too long to respond'. This should not be the case, everytime it should show the same message as the timeout limit is less and the query should end without fetching the results.
Kindly let me know how to resolve the above issues, any pointers will be helpful.
Thanks in advance.
Edited by: user9223904 on Nov 3, 2012 4:42 AM
Maybe you are looking for
-
Send .vdu,.txt files (File adapter)
Hi Everyone, I have a bunch of text files with different extensions (.TXT,.VDU ETC) Would like to FTP these files to different server. Here is the problem "I want to send these files directly to the receiving file server". Should I use File con
-
Problems skipping on dvd player
Hello, I made a movie with imovie & burned 30+ dvds for clients and tested just the first few min of each, figuring they would be good to go. Turns out they ALL skip in the same spots 16+ min into the movie. Arggg! Why is this doing this and how can
-
Firefox Crashes ever time I open it.
Firefox Crashes ever time I open it. It will not even launch into safe mode anymore. I have tried uninstall and re-installing it. My computer has been rebooted. Here is a list of my crash ID's. Crash ID: bp-ea0e9622-0ccd-4ff4-aff4-5b3d12140216 Crash
-
Calling Oracle Procedure in Parallel
Is it Possible to call two Oracle Procedures in Parallel. Begin call Procedure a; call Procedure b; end; When I will run the above block, I want that Oracle will call the Procedure a and then oracle will not wait for the procedure a to complete, Orac
-
Linkedin for Dynamics CRM - several Premium accounts necessary?
Hi, We have integrated the Linkedin Plugin to our Dynamics CRM 2013 for our company. The installation is ok, however we can have access to Lindekin interesting functionnalities only if we have a premium account. Can the company have just one premium