Same query takes different time to fetch result from Database
Hi all,
I am having a scenario in which a query is taking different time keeping other environmental variables constant.
When that query runs for 1 user it takes just 2 minutes to fetch result and the DB connection becomes inactive after fetching the result.
But if I run the same query after some time in similar environment it takes 25 minutes. sometimes 40 minutes to execute and give the result to the app server from the same database.
I am not able to understand this behavior from DB. Can anybody try to explain this behavior?
The details of the DB are,
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for 32-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
OS Details:
Windows 2008 server Enterprise Edition.
I tried analyzing that query in oracle, it recommended there are lots of hard parsing in that query.
Regards,
user10915512 wrote:
Hi all,
I am having a scenario in which a query is taking different time keeping other environmental variables constant.
When that query runs for 1 user it takes just 2 minutes to fetch result and the DB connection becomes inactive after fetching the result.
But if I run the same query after some time in similar environmentBut not exactly the same environment. So what is different that it is only "similar"?
it takes 25 minutes. sometimes 40 minutes to execute and give the result to the app server from the same database.
I am not able to understand this behavior from DB. Can anybody try to explain this behavior?Run a statspack on the 'well behaved' query and on the 'not well behaved' query. Compare and contrast the results.
>
The details of the DB are,
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for 32-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
OS Details:
Windows 2008 server Enterprise Edition. To paraphrase Forest Gump, "My momma always said Windows was like a box of chocolates ...."
>
>
I tried analyzing that query in oracle, it recommended there are lots of hard parsing in that query.
Regards,
Similar Messages
-
Same query takes different time for two different users with same privileges
Hi,
Just wanted to know if it is possible for an INSERT query to take different amount of time for two different users for the same volume of data. If so, what could be the reason? I would like to add that we are not executing the query simultaneously. But it is always faster for user1(within 10-20 seconds) and slower for user2(takes around 8-10 minutes).Show execution plan for each user. I think there is other reasons which you didn't not tell
-
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. -
Why same query takes different execution time in sql 2008
Hi!
With below query in SQL Server 2008 R2 when I change Book_ID to another value like '99000349' it takes very long time to execute while both result sets have same number of records!?
select Card_Serial,Asset_ID, Field_Name,Field_Value,Asset_Number,Field_ID,Book_ID from dbo.vw_InspectionReport where Book_ID='99000347'
I've test it more and more,A time I ran quickest one, or longest one first, restart Windows, but for some specific Book_ID values (although with same number of result set rows) it take multiple time slower than rest of Book_IDs.
Also showing state of the result set is different for these diffrent Book_IDs:
for fast ones it looks like below picture:
for slow ones it looks like below picture:
if you note, order of returned records are different!?
I'm waiting for your kindly reply!...Do you see any changes if you add a hint to the query?
select Card_Serial,Asset_ID, Field_Name,Field_Value,Asset_Number,Field_ID,Book_ID from dbo.vw_InspectionReport where Book_ID='99000347OPTION(RECOMPILE)
Best Regards,Uri Dimant SQL Server MVP,
http://sqlblog.com/blogs/uri_dimant/
MS SQL optimization: MS SQL Development and Optimization
MS SQL Consulting:
Large scale of database and data cleansing
Remote DBA Services:
Improves MS SQL Database Performance
SQL Server Integration Services:
Business Intelligence -
Query takes long time to return results.
I am on Oracle database 10g Enterprise Edition Release 10.2.0.4.0 – 64 bit
This query takes about 58 seconds to return 180 rows...
SELECT order_num,
order_date,
company_num,
customer_num,
address_type,
create_date as address_create_date,
contact_name,
first_name,
middle_init,
last_name,
company_name,
street_address_1,
customer_class,
city,
state,
zip_code,
country_code,
MAX(decode(media_type,
'PHH',
phone_area_code || '''' || phone_number,
NULL)) home_phone,
MAX(decode(media_type,
'PHW',
phone_area_code || '''' || phone_number,
NULL)) work_phone,
address_seq_num,
street_address_2
FROM (SELECT oh.order_num order_num,
oh.order_datetime order_date,
oh.company_num company_num,
oh.customer_num customer_num,
ad.address_type address_type,
c.create_date create_date,
con.first_name || '''' || con.last_name contact_name,
con.first_name first_name,
con.middle_init middle_init,
con.last_name last_name,
ad.company_name company_name,
ad.street_address_1 street_address_1,
c.customer_class customer_class,
ad.city city,
ad.state state,
ad.zip_code zip_code,
ad.country_code,
cph.media_type media_type,
cph.phone_area_code phone_area_code,
cph.phone_number phone_number,
ad.address_seq_num address_seq_num,
ad.street_address_2 street_address_2
FROM reporting_base.gt_gaft_orders gt,
doms.us_ordhdr oh,
doms.us_address ad,
doms.us_customer c,
doms.us_contact con,
doms.us_contph cph
WHERE oh.customer_num = c.customer_num(+)
AND oh.customer_num = ad.customer_num(+)
AND (
ad.customer_num = c.customer_num
AND
ad.address_type = 'B'
OR (
ad.customer_num = c.customer_num
AND
ad.address_type = 'S'
AND
ad.address_seq_num = oh.ship_to_seq_num
AND ad.customer_num = con.customer_num(+)
AND ad.address_type = con.address_type(+)
AND ad.address_seq_num = con.address_seq_num(+)
AND con.customer_num = cph.customer_num(+)
AND con.contact_id = cph.contact_id(+)
AND oh.order_num = gt.order_num
AND oh.business_unit_id = gt.business_unit_id)
GROUP BY order_num,
order_date,
company_num,
customer_num,
address_type,
create_date,
contact_name,
first_name,
middle_init,
last_name,
company_name,
street_address_1,
customer_class,
city,
state,
zip_code,
country_code,
address_seq_num,
street_address_2;This is the explain plan for the query:
Plan
SELECT STATEMENT FIRST_ROWS Cost: 21 Bytes: 207 Cardinality: 1
18 HASH GROUP BY Cost: 21 Bytes: 207 Cardinality: 1
17 NESTED LOOPS OUTER Cost: 20 Bytes: 207 Cardinality: 1
14 NESTED LOOPS OUTER Cost: 16 Bytes: 183 Cardinality: 1
11 FILTER
10 NESTED LOOPS OUTER Cost: 12 Bytes: 152 Cardinality: 1
7 NESTED LOOPS OUTER Cost: 8 Bytes: 74 Cardinality: 1
4 NESTED LOOPS OUTER Cost: 5 Bytes: 56 Cardinality: 1
1 TABLE ACCESS FULL TABLE (TEMP) REPORTING_BASE.GT_GAFT_ORDERS Cost: 2 Bytes: 26 Cardinality: 1
3 TABLE ACCESS BY INDEX ROWID TABLE DOMS.US_ORDHDR Cost: 3 Bytes: 30 Cardinality: 1
2 INDEX UNIQUE SCAN INDEX (UNIQUE) DOMS.USORDHDR_IXUPK_ORDNUMBUID Cost: 2 Cardinality: 1
6 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE DOMS.US_CUSTOMER Cost: 3 Bytes: 18 Cardinality: 1 Partition #: 11
5 INDEX UNIQUE SCAN INDEX (UNIQUE) DOMS.USCUSTOMER_IXUPK_CUSTNUM Cost: 2 Cardinality: 1
9 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE DOMS.US_ADDRESS Cost: 4 Bytes: 156 Cardinality: 2 Partition #: 13
8 INDEX RANGE SCAN INDEX (UNIQUE) DOMS.USADDR_IXUPK_CUSTATYPASEQ Cost: 3 Cardinality: 2
13 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE DOMS.US_CONTACT Cost: 4 Bytes: 31 Cardinality: 1 Partition #: 15
12 INDEX RANGE SCAN INDEX DOMS.USCONT_IX_CNATAS Cost: 3 Cardinality: 1
16 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE DOMS.US_CONTPH Cost: 4 Bytes: 24 Cardinality: 1 Partition #: 17
15 INDEX RANGE SCAN INDEX (UNIQUE) DOMS.USCONTPH_IXUPK_CUSTCONTMEDSEQ Cost: 3 Cardinality: 1 Cost is good. All indexes are used. However the time to return the data is very high.
Any ideas to make the query faster?.
ThanksHi, here is the tkprof output as requested by Rob..
TKPROF: Release 10.2.0.4.0 - Production on Mon Jul 13 09:07:09 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Trace file: axispr1_ora_15293.trc
Sort options: default
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 ORDER_NUM, ORDER_DATE, COMPANY_NUM, CUSTOMER_NUM, ADDRESS_TYPE,
CREATE_DATE AS ADDRESS_CREATE_DATE, CONTACT_NAME, FIRST_NAME, MIDDLE_INIT,
LAST_NAME, COMPANY_NAME, STREET_ADDRESS_1, CUSTOMER_CLASS, CITY, STATE,
ZIP_CODE, COUNTRY_CODE, MAX(DECODE(MEDIA_TYPE, 'PHH', PHONE_AREA_CODE ||
'''' || PHONE_NUMBER, NULL)) HOME_PHONE, MAX(DECODE(MEDIA_TYPE, 'PHW',
PHONE_AREA_CODE || '''' || PHONE_NUMBER, NULL)) WORK_PHONE, ADDRESS_SEQ_NUM,
STREET_ADDRESS_2
FROM
(SELECT OH.ORDER_NUM ORDER_NUM, OH.ORDER_DATETIME ORDER_DATE, OH.COMPANY_NUM
COMPANY_NUM, OH.CUSTOMER_NUM CUSTOMER_NUM, AD.ADDRESS_TYPE ADDRESS_TYPE,
C.CREATE_DATE CREATE_DATE, CON.FIRST_NAME || '''' || CON.LAST_NAME
CONTACT_NAME, CON.FIRST_NAME FIRST_NAME, CON.MIDDLE_INIT MIDDLE_INIT,
CON.LAST_NAME LAST_NAME, AD.COMPANY_NAME COMPANY_NAME, AD.STREET_ADDRESS_1
STREET_ADDRESS_1, C.CUSTOMER_CLASS CUSTOMER_CLASS, AD.CITY CITY, AD.STATE
STATE, AD.ZIP_CODE ZIP_CODE, AD.COUNTRY_CODE, CPH.MEDIA_TYPE MEDIA_TYPE,
CPH.PHONE_AREA_CODE PHONE_AREA_CODE, CPH.PHONE_NUMBER PHONE_NUMBER,
AD.ADDRESS_SEQ_NUM ADDRESS_SEQ_NUM, AD.STREET_ADDRESS_2 STREET_ADDRESS_2
FROM REPORTING_BASE.GT_GAFT_ORDERS GT, DOMS.US_ORDHDR OH, DOMS.US_ADDRESS
AD, DOMS.US_CUSTOMER C, DOMS.US_CONTACT CON, DOMS.US_CONTPH CPH WHERE
OH.ORDER_NUM = GT.ORDER_NUM AND OH.BUSINESS_UNIT_ID = GT.BUSINESS_UNIT_ID
AND OH.CUSTOMER_NUM = C.CUSTOMER_NUM(+) AND OH.CUSTOMER_NUM =
AD.CUSTOMER_NUM(+) AND AD.CUSTOMER_NUM = C.CUSTOMER_NUM AND (
AD.ADDRESS_TYPE = 'B' OR ( AD.ADDRESS_TYPE = 'S' AND AD.ADDRESS_SEQ_NUM =
OH.SHIP_TO_SEQ_NUM ) ) AND AD.CUSTOMER_NUM = CON.CUSTOMER_NUM(+) AND
AD.ADDRESS_TYPE = CON.ADDRESS_TYPE(+) AND AD.ADDRESS_SEQ_NUM =
CON.ADDRESS_SEQ_NUM(+) AND CON.CUSTOMER_NUM = CPH.CUSTOMER_NUM(+) AND
CON.CONTACT_ID = CPH.CONTACT_ID(+) ) GROUP BY ORDER_NUM, ORDER_DATE,
COMPANY_NUM, CUSTOMER_NUM, ADDRESS_TYPE, CREATE_DATE, CONTACT_NAME,
FIRST_NAME, MIDDLE_INIT, LAST_NAME, COMPANY_NAME, STREET_ADDRESS_1,
CUSTOMER_CLASS, CITY, STATE, ZIP_CODE, COUNTRY_CODE, ADDRESS_SEQ_NUM,
STREET_ADDRESS_2
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 257 0.04 0.05 45 0 0 6421
total 257 0.04 0.05 45 0 0 6421
Misses in library cache during parse: 0
Parsing user id: 126
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 257 0.04 0.05 45 0 0 6421
total 257 0.04 0.05 45 0 0 6421
Misses in library cache during parse: 0
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 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
1 user SQL statements in session.
0 internal SQL statements in session.
1 SQL statements in session.
Trace file: axispr1_ora_15293.trc
Trace file compatibility: 10.01.00
Sort options: default
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.
289 lines in trace file.
83 elapsed seconds in trace file.Thanks in advance! -
Query take long time in fetching when used within a procedure
The Database is : Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
Query just takes a second from toad but when used inside a procedure as a cursor it takes takes 3 to 5 minutes.
Following is the Tkprof information when running from procedure.
SELECT CHCLP.CLM_PRVDR_TYPE_LKPCD, CHCLP.PRVDR_LCTN_IID, TO_CHAR
(CHCLP.MODIFIED_DATE, 'MM-dd-yyyy hh24:mi:ss') MODIFIED_DATE,
CHCLP.PRVDR_LCTN_IDENTIFIER, CHCLP.CLM_HDR_CLM_LN_X_PVDR_LCTN_SID
FROM
CLM_HDR_CLM_LN_X_PRVDR_LCTN CHCLP WHERE CHCLP.CLAIM_HEADER_SID = :B1 AND
CHCLP.CLAIM_LINE_SID IS NULL AND CHCLP.IDNTFR_TYPE_CID = 7
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 110.79 247.79 568931 576111 0 3
total 2 110.79 247.79 568931 576111 0 3
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93 (CMSAPP) (recursive depth: 1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 PARTITION RANGE (SINGLE) PARTITION:KEYKEY
0 TABLE ACCESS MODE: ANALYZED (BY LOCAL INDEX ROWID) OF
'CLM_HDR_CLM_LN_X_PRVDR_LCTN' (TABLE) PARTITION:KEYKEY
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'XAK1CLM_HDR_CLM_LN_X_PRVDR_LCT' (INDEX (UNIQUE))
PARTITION:KEYKEY
Execution plan when running just the query from TOAD is: (it comes out in a second)
Plan
SELECT STATEMENT ALL_ROWSCost: 6 Bytes: 100 Cardinality: 2
3 PARTITION RANGE SINGLE Cost: 6 Bytes: 100 Cardinality: 2 Partition #: 1 Partitions accessed #13
2 TABLE ACCESS BY LOCAL INDEX ROWID TABLE CMSAPP.CLM_HDR_CLM_LN_X_PRVDR_LCTN Cost: 6 Bytes: 100 Cardinality: 2 Partition #: 2 Partitions accessed #13
Why would fetching take such a long time? Please let me know if you need any other information.
Thank You.
Edited by: spur230 on Apr 1, 2009 10:23 AM
Edited by: spur230 on Apr 1, 2009 10:26 AM
Edited by: spur230 on Apr 1, 2009 10:28 AM
Edited by: spur230 on Apr 1, 2009 10:30 AMQuery just takes a second from toad It's possible that the query starts returning rows in a second, but that's not the time required for the entire query.
-
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. -
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 with different parameter take different time to execute.
Hi,
I am a C/C++ programmer and newbie to database. I find weird case to my company database. oracle 10g.
I have a query (below). When I set GENRE_ID value to 20, query execution time only take *5* seconds. But when I change to 10, it take *54* seconds! The same query but different values GENRE_ID (20 or 10) -- it also happen to other GENRE_ID values.
on below query
WHERE substr(GENRE_ID,0,2) = 10 and GENRE_ID != 10) take 54 seconds
WHERE substr(GENRE_ID,0,2) = 20 and GENRE_ID != 20) take 5 seconds
The explain plan give exact same result for both queries.
I have follow Re: 3. How to improve the performance of my query? / My query is running slow. for optimizer but the problem still there.
And we have rebuilt all indexes.
Anyone can help me? I need any advises for this problem.
Note:
Song table only have 570K records and Song_vod table 1100 records.
Query:
select *
from(
select rownum rowno, a.*
from(
select a.SONG_VOD_ID, a.SONG_ID, a.VOD_TITLE, a.ALBUM_ID, a.ARTIST_ID, a.VOD_ISSUE_DATE, a.VOD_ORDER_ISSUE_DATE, a.VOD_ADULT_YN, a.VOD_L_IMG_PATH, a.VOD_M_IMG_PATH, a.VOD_S_IMG_PATH, a.RECOMMEND_CNT, a.OPPOSE_CNT, get_song_name(a.SONG_ID) SONG_NAME, get_album_name(a.ALBUM_ID) ALBUM_NAME, get_artist_name(a.ARTIST_ID) ARTIST_NAME, VOD_ISSUE_DATE vodIssueDate
from SONG_VOD a inner join SONG b on a.SONG_ID = b.SONG_ID
where a.LC_STATUS_CD = 'CS0006'
AND (b.GENRE_ID
in (
select GENRE_ID
from MD_GENRE
WHERE substr(GENRE_ID,0,2) = 10
and GENRE_ID != 10)
OR b.GENRE_ID
in (
select GENRE_ID
from MD_GENRE
WHERE substr(GENRE_ID,0,2) = '40'
and GENRE_ID != '40'
) order by a.REG_DATE desc, a.SONG_VOD_ID desc
) a WHERE rownum <= 0 + 30
Thank you,
Regards
-=Rika Chaniago=-907814 wrote:
I am a C/C++ programmer and newbie to database. I find weird case to my company database. oracle 10g.
I have a query (below). When I set GENRE_ID value to 20, query execution time only take *5* seconds. But when I change to 10, it take *54* seconds! The same query but different values GENRE_ID (20 or 10) -- it also happen to other GENRE_ID values.This is to be expected. Even an IDENTICAL query can (and often will) have DIFFERENT execution times.
The typical reason is how fast the query process can get to the data block(s) containing the relevant row(s). Is that data block still on disk and require expensive and slow physical I/O to move it into the buffer cache for use? Is that data block already cached for much faster logical I/O access? If in memory, is there any contention in getting a latch for the chain the data block hangs off from (how hot is that block)? Etc.
The run-time environment is not static. Thus execution times of queries (called cursors in Oracle) is not static. Execution times are expected to vary.
Some basics. SQL code is source code. SQL code needs to be parsed and converted into a set of instructions that the server can execute. So it is similar to C/C++. SQL source code needs to be compiled. This executable code in Oracle is called a cursor.
Like your code, the cursor can be executed with different input variables (bind variables). However, that code would have been compiled using certain assumptions about the data. And that executable code may work fine for some input data, and work not so okay for other input data. As the input parameter values are not not equal. E.g. there are a 1000 rows to process when employee type parameter is "employee" and only 10 rows when it is "manager". The code could have been compiled with the assumption that 10 rows would be the average for all input parameters - the Cost Based Optimiser needs to base its decision on the best execution path for that SQL source code on certain assumptions about the data. These may not always be correct. (usually due incorrect or stale stats about the data)
Thus you also need to look at what the execution plan is (the URL for which has already been supplied).
The Oracle® Database Performance Tuning Guide is at http://www.oracle.com/pls/db112/portal.all_books -
Same query giving different results
Hi
I m surprised to see the behaviour of oracle. I have two different sessions for same scheema on same server. In both sessions same query returns different results. The query involves some calculations like sum and divisions on number field.
I have imported this data from another server using export / import utility available with 9i server. Before export every thing was going fine. Is there some problem with this utility.
I m using Developer 6i as the front end for my client server application. The behaviour of my application is very surprizing as once it shows the correct data and if I close the screen and reopen, it shows wrong data.
I m really stucked with the abnormal behaviour. Please tell me the possiblities and corrective action for these conditions.
Regards
Asad.There is nothing uncommitted in both the sessions. But still different results are returned.
I m sending u the exact query and result returned in both sessions.
Session 1:
SQL> rollback;
Rollback complete.
SQL> SELECT CC.CREDIT_HRS,GP.GRADE_PTS
2 FROM GRADE G, COURSE_CODE CC, GRADE_POLICY GP
3 WHERE G.COURSE_CDE=CC.COURSE_CDE
4 AND G.SELECTION_ID=45 AND G.GRADE_TYP=GP.GRADE_TYP
5 AND G.TERM_PROG_ID=17 AND GP.TERM_ID=14
6 /
CREDIT_HRS GRADE_PTS
3 4
4 3.33
4 3.33
3 4
3 4
3 4
3 4
7 rows selected.
SQL>
SESSION 2:
SQL> rollback;
Rollback complete.
SQL> SELECT CC.CREDIT_HRS,GP.GRADE_PTS
2 FROM GRADE G, COURSE_CODE CC, GRADE_POLICY GP
3 WHERE G.COURSE_CDE=CC.COURSE_CDE
4 AND G.SELECTION_ID=45 AND G.GRADE_TYP=GP.GRADE_TYP
5 AND G.TERM_PROG_ID=17 AND GP.TERM_ID=14
6 /
CREDIT_HRS GRADE_PTS
3 4
4 3.33
3 4
3 4
3 4
3 4
6 rows selected.
SQL>
U can see in session 1, seven rows are returned while in session 2 six rows are returned. I have issued a rollback before query to be sure that data in both sessions is same. -
One query taking different time to execute on different environments
I am working on Oracle 10g. We have setup of two different environments - Development and Alpha.
I have written a query which gets some records from a table. This table contains around 1,000,000 records on both the environments.
This query takes 5 seconds to execute on Development environment to get 200 records but the same query takes around 50 seconds to execute on Alpha environment and to retrieve same number of records.
Data and indexes on the table is same on both environments. There are no joins in the query.
Please let me know what are the all possible reasons for this?
Edited by: 956610 on Sep 3, 2012 2:37 AMBelow is the trace on the two environments ---
-----------------------Development ------------------------------
CPU used by this session 1741
CPU used when call started 1741
Cached Commit SCN referenced 15634
DB time 1752
Effective IO time 7236
Number of read IOs issued 173
SQL*Net roundtrips to/from client 14
buffer is not pinned count 90474
buffer is pinned count 264554
bytes received via SQL*Net from client 4507
bytes sent via SQL*Net to client 28859
calls to get snapshot scn: kcmgss 6
calls to kcmgcs 13
cell physical IO interconnect bytes 165330944
cleanout - number of ktugct calls 5273
cleanouts only - consistent read gets 5273
commit txn count during cleanout 5273
consistent gets 202533
consistent gets - examination 101456
consistent gets direct 19686
consistent gets from cache 182847
consistent gets from cache (fastpath) 81013
enqueue releases 3
enqueue requests 3
execute count 6
file io wait time 1582
immediate (CR) block cleanout applications 5273
index fetch by key 36608
index scans kdiixs1 36582
no buffer to keep pinned count 8
no work - consistent read gets 95791
non-idle wait count 42
non-idle wait time 2
opened cursors cumulative 6
parse count (hard) 1
parse count (total) 6
parse time cpu 1
parse time elapsed 2
physical read IO requests 181
physical read bytes 163299328
physical read total IO requests 181
physical read total bytes 163299328
physical read total multi block requests 162
physical reads 19934
physical reads direct 19934
physical reads direct temporary tablespace 248
physical write IO requests 8
physical write bytes 2031616
physical write total IO requests 8
physical write total bytes 2031616
physical write total multi block requests 8
physical writes 248
physical writes direct 248
physical writes direct temporary tablespace 248
physical writes non checkpoint 248
recursive calls 31
recursive cpu usage 1
rows fetched via callback 23018
session cursor cache hits 4
session logical reads 202533
session uga memory max 65488
sorts (memory) 3
sorts (rows) 19516
sql area evicted 2
table fetch by rowid 140921
table scan blocks gotten 19686
table scan rows gotten 2012896
table scans (direct read) 2
table scans (long tables) 2
user I/O wait time 2
user calls 16
workarea executions - onepass 4
workarea executions - optimal 7
workarea memory allocated 17
------------------------------------------------------ For Alpha ------------------------------------------------------------------
CCursor + sql area evicted 1
CPU used by this session 5763
CPU used when call started 5775
Cached Commit SCN referenced 9264
Commit SCN cached 1
DB time 6999
Effective IO time 4262103
Number of read IOs issued 2155
OS All other sleep time 10397
OS Chars read and written 340383180
OS Involuntary context switches 18766
OS Other system trap CPU time 27
OS Output blocks 12445
OS Process stack size 24576
OS System call CPU time 223
OS System calls 20542
OS User level CPU time 5526
OS User lock wait sleep time 86045
OS Voluntary context switches 15739
OS Wait-cpu (latency) time 273
SQL*Net roundtrips to/from client 14
buffer is not pinned count 2111
buffer is pinned count 334
bytes received via SQL*Net from client 4486
bytes sent via SQL*Net to client 28989
calls to get snapshot scn: kcmgss 510
calls to kcmgas 4
calls to kcmgcs 119
cell physical IO interconnect bytes 340041728
cleanout - number of ktugct calls 1
cleanouts only - consistent read gets 1
cluster key scan block gets 179
cluster key scans 168
commit txn count during cleanout 1
consistent gets 41298
consistent gets - examination 722
consistent gets direct 30509
consistent gets from cache 10789
consistent gets from cache (fastpath) 9038
cursor authentications 2
db block gets 7
db block gets from cache 7
dirty buffers inspected 1
enqueue releases 58
enqueue requests 58
execute count 510
file io wait time 6841235
free buffer inspected 8772
free buffer requested 8499
hot buffers moved to head of LRU 27
immediate (CR) block cleanout applications 1
index fast full scans (full) 1
index fetch by key 196
index scans kdiixs1 331
no work - consistent read gets 40450
non-idle wait count 1524
non-idle wait time 1208
opened cursors cumulative 511
parse count (hard) 39
parse count (total) 44
parse time cpu 78
parse time elapsed 343
physical read IO requests 3293
physical read bytes 329277440
physical read total IO requests 3293
physical read total bytes 329277440
physical read total multi block requests 1951
physical reads 40195
physical reads cache 8498
physical reads cache prefetch 7467
physical reads direct 31697
physical reads direct temporary tablespace 1188
physical write IO requests 126
physical write bytes 10764288
physical write total IO requests 126
physical write total bytes 10764288
physical writes 1314
physical writes direct 1314
physical writes direct temporary tablespace 1314
physical writes non checkpoint 1314
prefetched blocks aged out before use 183
recursive calls 1329
recursive cpu usage 76
rows fetched via callback 7
session cursor cache count 8
session cursor cache hits 491
session logical reads 41305
session pga memory max 851968
session uga memory -660696
session uga memory max 3315160
shared hash latch upgrades - no wait 14
sorts (disk) 1
sorts (memory) 177
sorts (rows) 21371
sql area evicted 10
table fetch by rowid 613
table scan blocks gotten 30859
table scan rows gotten 3738599
table scans (direct read) 4
table scans (long tables) 8
table scans (short tables) 3
user I/O wait time 1208
user calls 16
workarea executions - onepass 7
workarea executions - optimal 113
workarea memory allocated -617 -
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 -
Why update query takes long time ?
Hello everyone;
My update query takes long time. In emp ( self testing) just having 2 records.
when i issue update query , it takes long time;
SQL> select * from emp;
EID ENAME EQUAL ESALARY ECITY EPERK ECONTACT_NO
2 rose mca 22000 calacutta 9999999999
1 sona msc 17280 pune 9999999999
Elapsed: 00:00:00.05
SQL> update emp set esalary=12000 where eid='1';
update emp set esalary=12000 where eid='1'
* ERROR at line 1:
ORA-01013: user requested cancel of current operation
Elapsed: 00:01:11.72
SQL> update emp set esalary=15000;
update emp set esalary=15000
* ERROR at line 1:
ORA-01013: user requested cancel of current operation
Elapsed: 00:02:22.27Hi BCV;
Thanks for your reply but it doesn't provide output, please see this.
SQL> update emp set esalary=15000;
........... Lock already occured.
>> trying to trace >>
SQL> select HOLDING_SESSION from dba_blockers;
HOLDING_SESSION
144
SQL> select sid , username, event from v$session where username='HR';
SID USERNAME EVENT
144 HR SQL*Net message from client
151 HR enq: TX - row lock contention
159 HR SQL*Net message from client
>> It does n 't provide clear output about transaction lock >>
SQL> SELECT username, v$lock.SID, TRUNC (id1 / POWER (2, 16)) rbs,
2 BITAND (id1, TO_NUMBER ('ffff', 'xxxx')) + 0 slot, id2 seq, lmode,
3 request
4 FROM v$lock, v$session
5 WHERE v$lock.TYPE = 'TX'
6 AND v$lock.SID = v$session.SID
7 AND v$session.username = USER;
no rows selected
SQL> select MACHINE from v$session where sid = :sid;
SP2-0552: Bind variable "SID" not declared. -
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! -
How to fetch data from database in javafx 2.2 table which is editable.
Dears!
I want to fetch data from database in javafx 2.2 tableformat with jdbc , which is also editable and i can add more records in this table also.
Can anybody help meI can vaguely recall some sort of JavaFX database connectivity feature, I'm not sure if it's valid anymore.The link is based on JavaFX Composer which only applied to NetBeans 6.9 and JavaFX 1.x (both of which are now dead techs).
There is a good chance you will have to write your own. There are several blogs describing other peoples' work. You could probably use them as a reference.Here is Narayan's basic [url http://blog.ngopal.com.np/2011/10/19/dyanmic-tableview-data-from-database/] tutorial for displaying data from a database in a TableView, you'll need to look elsewhere for the editing portion.
The [url http://docs.oracle.com/javafx/2/ui_controls/table-view.htm]JavaFX TableView tutorial gives info about how to handle edits in a TableView, but you will need to tie the updates back to the database yourself.
It is possible that [url http://www.javafxdata.org/]DataFX may provide some facilities to help support you.
Maybe you are looking for
-
Business Catalyst in Creative Cloud
I have a question regarding Business Catalyst. It seems that with my Creative Cloud subscription I can create 5 sites in either Dreamweaver or Muse, and upload to Business Catalyst. But when I log on to manage my site it seems I get parts of Busine
-
The question is in the topic sorry.
-
Remote streaming server is up for testing. Starting at 12:30pm EST Oct 31 2005
I have router configured I believe. So have at it. Time of testing starts at 1230 hours EST or 1730 UTC on Oct 31, 2005 Time of testing ends 3 hours later at 1530 hours EST Server is at: 66.177.25.115:8080 Server software: msipvs (intervideo WinDVR v
-
How do I keep table relations from Numbers when copying them to Pages ?
I have two tables within Numbers (because I need two different formats) and have connected them with a formula in Numbers. This works fine. But when I copy the two tables to a Pages document, the link between the tables is broken, i.e. if I modify a
-
I'm having trouble setting up an Anchor Controller on my DMZ. I have setup everything up and tested it out on my inside network and the Anchor Controller comes up with no problem. When I put the Anchor Controller on the DMZ the data path is up but th