Query response time takes more time when calling from package
SELECT
/* UTILITIES_PKG.GET_COUNTRY_CODE(E.EMP_ID,E.EMP_NO) COUNTRY_ID */
(SELECT DISTINCT IE.COUNTRY_ID
FROM DOCUMENT IE
WHERE IE.EMP_ID =E.EMP_ID
AND IE.EMP_NO = E.EMP_NO
AND IE.STATUS = 'OPEN' ) COUNTRY_ID
FROM EMPLOYEE E
CREATE OR REPLACE PACKAGE BODY UTILITIES_PKG AS
FUNCTION GET_COUNTRY_CODE(P_EMP_ID IN VARCHAR2, P_EMP_NO IN VARCHAR2)
RETURN VARCHAR2 IS
L_COUNTRY_ID VARCHAR2(25) := '';
BEGIN
SELECT DISTINCT IE.COUNTRY_ID
INTO L_COUNTRY_ID
FROM DOCUMENT IE
WHERE IE.EMP_ID = P_EMP_ID
AND IE.EMP_NO = P_EMP_NO
AND IE.STATUS = 'OPEN';
RETURN L_COUNTRY_ID;
EXCEPTION
WHEN OTHERS THEN
RETURN 'CONT';
END;
END UTILITIES_PKG;
when I run above query its coming in 1.2 seconds.but when comment subquery and call from package its taking 9 seconds.query returns more than 2000 records.i am not able to find the reason why it is taking more time when calling from package?
You are getting a different plan when you run it as PL/SQL most likely. Comment your statement:
SELECT /* your comment here */then find them in V$SQL and get the SQL IDs. You can then use DBMS_XPLAN.DISPLAY_CURSOR to see what is actually happening.
http://www.psoug.org/reference/dbms_xplan.html
Similar Messages
-
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 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 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. -
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! -
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 -
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" -
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 -
PDF Form Takes More Time To Open when using designer 7.1.3129.1.296948
Hi All,
Adobe Reader Version : 8 and above.
designer : 7.1.3129.1.296948
When i am devloping the adobe interactive form Using designer 7.1.3129.1.296948, When I open the same in the adobe reader 8.1.2 and 9.1 its take more time (Nearly 20 mins).
When I am opening the same in the adobe reader 7.1 its opening fine.
How to resolve This problem in adobe reader 8.1.2,9.0 and 9.1 ?
Regards,
Boopathi MHi,
I have seen this exact same problem happening when, I created/developed a adobe form, on a PC which had adobe livecycle designer 7.1, but had adobe reader 7.
Once the form is created on a machine which had reader 7, then it does not matter whether u try to open that pdf in reader 8 or 9, it will take 20-30min to open, it will freeze your pc, etc.
Please ensure that when/where ever the form was first created, that machine had adobe reader 8 or higher installed it.
I hope this helps,
Regards,
Hanoz -
Hi All,
When i am developing the adobe interactive form Using designer 7.1.3129.1.296948,After that I converted to PDF.
When I am opening the PDF form its takes more time(Using reader version 8.1.2).
How to resolve This problem ?
Regards,
Boopathi MHi,
I have seen this exact same problem happening when, I created/developed a adobe form, on a PC which had adobe livecycle designer 7.1, but had adobe reader 7.
Once the form is created on a machine which had reader 7, then it does not matter whether u try to open that pdf in reader 8 or 9, it will take 20-30min to open, it will freeze your pc, etc.
Please ensure that when/where ever the form was first created, that machine had adobe reader 8 or higher installed it.
I hope this helps,
Regards,
Hanoz -
When i put my Mac for sleep it takes more time than normal (>20 secs). Sometimes, coming back from sleep the system is not responding (freeze).
Perform SMC and NVRAM resets:
http://support.apple.com/en-us/HT201295
http://support.apple.com/en-us/HT204063
The try a safe boot:
http://support.apple.com/en-us/HT201262
Any change?
Ciao. -
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 -
Query in timesten taking more time than query in oracle database
Hi,
Can anyone please explain me why query in timesten taking more time
than query in oracle database.
I am mentioning in detail what are my settings and what have I done
step by step.........
1.This is the table I created in Oracle datababase
(Oracle Database 10g Enterprise Edition Release 10.2.0.1.0)...
CREATE TABLE student (
id NUMBER(9) primary keY ,
first_name VARCHAR2(10),
last_name VARCHAR2(10)
2.THIS IS THE ANONYMOUS BLOCK I USE TO
POPULATE THE STUDENT TABLE(TOTAL 2599999 ROWS)...
declare
firstname varchar2(12);
lastname varchar2(12);
catt number(9);
begin
for cntr in 1..2599999 loop
firstname:=(cntr+8)||'f';
lastname:=(cntr+2)||'l';
if cntr like '%9999' then
dbms_output.put_line(cntr);
end if;
insert into student values(cntr,firstname, lastname);
end loop;
end;
3. MY DSN IS SET THE FOLLWING WAY..
DATA STORE PATH- G:\dipesh3repo\db
LOG DIRECTORY- G:\dipesh3repo\log
PERM DATA SIZE-1000
TEMP DATA SIZE-1000
MY TIMESTEN VERSION-
C:\Documents and Settings\dipesh>ttversion
TimesTen Release 7.0.3.0.0 (32 bit NT) (tt70_32:17000) 2007-09-19T16:04:16Z
Instance admin: dipesh
Instance home directory: G:\TimestTen\TT70_32
Daemon home directory: G:\TimestTen\TT70_32\srv\info
THEN I CONNECT TO THE TIMESTEN DATABASE
C:\Documents and Settings\dipesh> ttisql
command>connect "dsn=dipesh3;oraclepwd=tiger";
4. THEN I START THE AGENT
call ttCacheUidPwdSet('SCOTT','TIGER');
Command> CALL ttCacheStart();
5.THEN I CREATE THE READ ONLY CACHE GROUP AND LOAD IT
create readonly cache group rc_student autorefresh
interval 5 seconds from student
(id int not null primary key, first_name varchar2(10), last_name varchar2(10));
load cache group rc_student commit every 100 rows;
6.NOW I CAN ACCESS THE TABLES FROM TIMESTEN AND PERFORM THE QUERY
I SET THE TIMING..
command>TIMING 1;
consider this query now..
Command> select * from student where first_name='2155666f';
< 2155658, 2155666f, 2155660l >
1 row found.
Execution time (SQLExecute + Fetch Loop) = 0.668822 seconds.
another query-
Command> SELECT * FROM STUDENTS WHERE FIRST_NAME='2340009f';
2206: Table SCOTT.STUDENTS not found
Execution time (SQLPrepare) = 0.074964 seconds.
The command failed.
Command> SELECT * FROM STUDENT where first_name='2093434f';
< 2093426, 2093434f, 2093428l >
1 row found.
Execution time (SQLExecute + Fetch Loop) = 0.585897 seconds.
Command>
7.NOW I PERFORM THE SIMILAR QUERIES FROM SQLPLUS...
SQL> SELECT * FROM STUDENT WHERE FIRST_NAME='1498671f';
ID FIRST_NAME LAST_NAME
1498663 1498671f 1498665l
Elapsed: 00:00:00.15
Can anyone please explain me why query in timesten taking more time
that query in oracle database.
Message was edited by: Dipesh Majumdar
user542575
Message was edited by:
user542575TimesTen
Hardware: Windows Server 2003 R2 Enterprise x64; 8 x Dual-core AMD 8216 2.41GHz processors; 32 GB RAM
Version: 7.0.4.0.0 64 bit
Schema:
create usermanaged cache group factCache from
MV_US_DATAMART
ORDER_DATE DATE,
IF_SYSTEM VARCHAR2(32) NOT NULL,
GROUPING_ID TT_BIGINT,
TIME_DIM_ID TT_INTEGER NOT NULL,
BUSINESS_DIM_ID TT_INTEGER NOT NULL,
ACCOUNT_DIM_ID TT_INTEGER NOT NULL,
ORDERTYPE_DIM_ID TT_INTEGER NOT NULL,
INSTR_DIM_ID TT_INTEGER NOT NULL,
EXECUTION_DIM_ID TT_INTEGER NOT NULL,
EXEC_EXCHANGE_DIM_ID TT_INTEGER NOT NULL,
NO_ORDERS TT_BIGINT,
FILLED_QUANTITY TT_BIGINT,
CNT_FILLED_QUANTITY TT_BIGINT,
QUANTITY TT_BIGINT,
CNT_QUANTITY TT_BIGINT,
COMMISSION BINARY_FLOAT,
CNT_COMMISSION TT_BIGINT,
FILLS_NUMBER TT_BIGINT,
CNT_FILLS_NUMBER TT_BIGINT,
AGGRESSIVE_FILLS TT_BIGINT,
CNT_AGGRESSIVE_FILLS TT_BIGINT,
NOTIONAL BINARY_FLOAT,
CNT_NOTIONAL TT_BIGINT,
TOTAL_PRICE BINARY_FLOAT,
CNT_TOTAL_PRICE TT_BIGINT,
CANCELLED_ORDERS_COUNT TT_BIGINT,
CNT_CANCELLED_ORDERS_COUNT TT_BIGINT,
ROUTED_ORDERS_NO TT_BIGINT,
CNT_ROUTED_ORDERS_NO TT_BIGINT,
ROUTED_LIQUIDITY_QTY TT_BIGINT,
CNT_ROUTED_LIQUIDITY_QTY TT_BIGINT,
REMOVED_LIQUIDITY_QTY TT_BIGINT,
CNT_REMOVED_LIQUIDITY_QTY TT_BIGINT,
ADDED_LIQUIDITY_QTY TT_BIGINT,
CNT_ADDED_LIQUIDITY_QTY TT_BIGINT,
AGENT_CHARGES BINARY_FLOAT,
CNT_AGENT_CHARGES TT_BIGINT,
CLEARING_CHARGES BINARY_FLOAT,
CNT_CLEARING_CHARGES TT_BIGINT,
EXECUTION_CHARGES BINARY_FLOAT,
CNT_EXECUTION_CHARGES TT_BIGINT,
TRANSACTION_CHARGES BINARY_FLOAT,
CNT_TRANSACTION_CHARGES TT_BIGINT,
ORDER_MANAGEMENT BINARY_FLOAT,
CNT_ORDER_MANAGEMENT TT_BIGINT,
SETTLEMENT_CHARGES BINARY_FLOAT,
CNT_SETTLEMENT_CHARGES TT_BIGINT,
RECOVERED_AGENT BINARY_FLOAT,
CNT_RECOVERED_AGENT TT_BIGINT,
RECOVERED_CLEARING BINARY_FLOAT,
CNT_RECOVERED_CLEARING TT_BIGINT,
RECOVERED_EXECUTION BINARY_FLOAT,
CNT_RECOVERED_EXECUTION TT_BIGINT,
RECOVERED_TRANSACTION BINARY_FLOAT,
CNT_RECOVERED_TRANSACTION TT_BIGINT,
RECOVERED_ORD_MGT BINARY_FLOAT,
CNT_RECOVERED_ORD_MGT TT_BIGINT,
RECOVERED_SETTLEMENT BINARY_FLOAT,
CNT_RECOVERED_SETTLEMENT TT_BIGINT,
CLIENT_AGENT BINARY_FLOAT,
CNT_CLIENT_AGENT TT_BIGINT,
CLIENT_ORDER_MGT BINARY_FLOAT,
CNT_CLIENT_ORDER_MGT TT_BIGINT,
CLIENT_EXEC BINARY_FLOAT,
CNT_CLIENT_EXEC TT_BIGINT,
CLIENT_TRANS BINARY_FLOAT,
CNT_CLIENT_TRANS TT_BIGINT,
CLIENT_CLEARING BINARY_FLOAT,
CNT_CLIENT_CLEARING TT_BIGINT,
CLIENT_SETTLE BINARY_FLOAT,
CNT_CLIENT_SETTLE TT_BIGINT,
CHARGEABLE_TAXES BINARY_FLOAT,
CNT_CHARGEABLE_TAXES TT_BIGINT,
VENDOR_CHARGE BINARY_FLOAT,
CNT_VENDOR_CHARGE TT_BIGINT,
ROUTING_CHARGES BINARY_FLOAT,
CNT_ROUTING_CHARGES TT_BIGINT,
RECOVERED_ROUTING BINARY_FLOAT,
CNT_RECOVERED_ROUTING TT_BIGINT,
CLIENT_ROUTING BINARY_FLOAT,
CNT_CLIENT_ROUTING TT_BIGINT,
TICKET_CHARGES BINARY_FLOAT,
CNT_TICKET_CHARGES TT_BIGINT,
RECOVERED_TICKET_CHARGES BINARY_FLOAT,
CNT_RECOVERED_TICKET_CHARGES TT_BIGINT,
PRIMARY KEY(ORDER_DATE, TIME_DIM_ID, BUSINESS_DIM_ID, ACCOUNT_DIM_ID, ORDERTYPE_DIM_ID, INSTR_DIM_ID, EXECUTION_DIM_ID,EXEC_EXCHANGE_DIM_ID),
READONLY);
No of rows: 2228558
Config:
< CkptFrequency, 600 >
< CkptLogVolume, 0 >
< CkptRate, 0 >
< ConnectionCharacterSet, US7ASCII >
< ConnectionName, tt_us_dma >
< Connections, 64 >
< DataBaseCharacterSet, AL32UTF8 >
< DataStore, e:\andrew\datacache\usDMA >
< DurableCommits, 0 >
< GroupRestrict, <NULL> >
< LockLevel, 0 >
< LockWait, 10 >
< LogBuffSize, 65536 >
< LogDir, e:\andrew\datacache\ >
< LogFileSize, 64 >
< LogFlushMethod, 1 >
< LogPurge, 0 >
< Logging, 1 >
< MemoryLock, 0 >
< NLS_LENGTH_SEMANTICS, BYTE >
< NLS_NCHAR_CONV_EXCP, 0 >
< NLS_SORT, BINARY >
< OracleID, NYCATP1 >
< PassThrough, 0 >
< PermSize, 4000 >
< PermWarnThreshold, 90 >
< PrivateCommands, 0 >
< Preallocate, 0 >
< QueryThreshold, 0 >
< RACCallback, 0 >
< SQLQueryTimeout, 0 >
< TempSize, 514 >
< TempWarnThreshold, 90 >
< Temporary, 1 >
< TransparentLoad, 0 >
< TypeMode, 0 >
< UID, OS_OWNER >
ORACLE:
Hardware: Sunos 5.10; 24x1.8Ghz (unsure of type); 82 GB RAM
Version 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
Schema:
CREATE MATERIALIZED VIEW OS_OWNER.MV_US_DATAMART
TABLESPACE TS_OS
PARTITION BY RANGE (ORDER_DATE)
PARTITION MV_US_DATAMART_MINVAL VALUES LESS THAN (TO_DATE(' 2007-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
NOCOMPRESS
TABLESPACE TS_OS,
PARTITION MV_US_DATAMART_07_NOV_D1 VALUES LESS THAN (TO_DATE(' 2007-11-11 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
NOCOMPRESS
TABLESPACE TS_OS,
PARTITION MV_US_DATAMART_07_NOV_D2 VALUES LESS THAN (TO_DATE(' 2007-11-21 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
NOCOMPRESS
TABLESPACE TS_OS,
PARTITION MV_US_DATAMART_07_NOV_D3 VALUES LESS THAN (TO_DATE(' 2007-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
NOCOMPRESS
TABLESPACE TS_OS,
PARTITION MV_US_DATAMART_07_DEC_D1 VALUES LESS THAN (TO_DATE(' 2007-12-11 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
NOCOMPRESS
TABLESPACE TS_OS,
PARTITION MV_US_DATAMART_07_DEC_D2 VALUES LESS THAN (TO_DATE(' 2007-12-21 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
NOCOMPRESS
TABLESPACE TS_OS,
PARTITION MV_US_DATAMART_07_DEC_D3 VALUES LESS THAN (TO_DATE(' 2008-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
NOCOMPRESS
TABLESPACE TS_OS,
PARTITION MV_US_DATAMART_08_JAN_D1 VALUES LESS THAN (TO_DATE(' 2008-01-11 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
NOCOMPRESS
TABLESPACE TS_OS,
PARTITION MV_US_DATAMART_08_JAN_D2 VALUES LESS THAN (TO_DATE(' 2008-01-21 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
NOCOMPRESS
TABLESPACE TS_OS,
PARTITION MV_US_DATAMART_08_JAN_D3 VALUES LESS THAN (TO_DATE(' 2008-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
NOCOMPRESS
TABLESPACE TS_OS,
PARTITION MV_US_DATAMART_MAXVAL VALUES LESS THAN (MAXVALUE)
LOGGING
NOCOMPRESS
TABLESPACE TS_OS
NOCACHE
NOCOMPRESS
NOPARALLEL
BUILD DEFERRED
USING INDEX
TABLESPACE TS_OS_INDEX
REFRESH FAST ON DEMAND
WITH PRIMARY KEY
ENABLE QUERY REWRITE
AS
SELECT order_date, if_system,
GROUPING_ID (order_date,
if_system,
business_dim_id,
time_dim_id,
account_dim_id,
ordertype_dim_id,
instr_dim_id,
execution_dim_id,
exec_exchange_dim_id
) GROUPING_ID,
/* ============ DIMENSIONS ============ */
time_dim_id, business_dim_id, account_dim_id, ordertype_dim_id,
instr_dim_id, execution_dim_id, exec_exchange_dim_id,
/* ============ MEASURES ============ */
-- o.FX_RATE /* FX_RATE */,
COUNT (*) no_orders,
-- SUM(NO_ORDERS) NO_ORDERS,
-- COUNT(NO_ORDERS) CNT_NO_ORDERS,
SUM (filled_quantity) filled_quantity,
COUNT (filled_quantity) cnt_filled_quantity, SUM (quantity) quantity,
COUNT (quantity) cnt_quantity, SUM (commission) commission,
COUNT (commission) cnt_commission, SUM (fills_number) fills_number,
COUNT (fills_number) cnt_fills_number,
SUM (aggressive_fills) aggressive_fills,
COUNT (aggressive_fills) cnt_aggressive_fills,
SUM (fx_rate * filled_quantity * average_price) notional,
COUNT (fx_rate * filled_quantity * average_price) cnt_notional,
SUM (fx_rate * fills_number * average_price) total_price,
COUNT (fx_rate * fills_number * average_price) cnt_total_price,
SUM (CASE
WHEN order_status = 'C'
THEN 1
ELSE 0
END) cancelled_orders_count,
COUNT (CASE
WHEN order_status = 'C'
THEN 1
ELSE 0
END
) cnt_cancelled_orders_count,
-- SUM(t.FX_RATE*t.NO_FILLS*t.AVG_PRICE) AVERAGE_PRICE,
-- SUM(FILLS_NUMBER*AVERAGE_PRICE) STAGING_AVERAGE_PRICE,
-- COUNT(FILLS_NUMBER*AVERAGE_PRICE) CNT_STAGING_AVERAGE_PRICE,
SUM (routed_orders_no) routed_orders_no,
COUNT (routed_orders_no) cnt_routed_orders_no,
SUM (routed_liquidity_qty) routed_liquidity_qty,
COUNT (routed_liquidity_qty) cnt_routed_liquidity_qty,
SUM (removed_liquidity_qty) removed_liquidity_qty,
COUNT (removed_liquidity_qty) cnt_removed_liquidity_qty,
SUM (added_liquidity_qty) added_liquidity_qty,
COUNT (added_liquidity_qty) cnt_added_liquidity_qty,
SUM (agent_charges) agent_charges,
COUNT (agent_charges) cnt_agent_charges,
SUM (clearing_charges) clearing_charges,
COUNT (clearing_charges) cnt_clearing_charges,
SUM (execution_charges) execution_charges,
COUNT (execution_charges) cnt_execution_charges,
SUM (transaction_charges) transaction_charges,
COUNT (transaction_charges) cnt_transaction_charges,
SUM (order_management) order_management,
COUNT (order_management) cnt_order_management,
SUM (settlement_charges) settlement_charges,
COUNT (settlement_charges) cnt_settlement_charges,
SUM (recovered_agent) recovered_agent,
COUNT (recovered_agent) cnt_recovered_agent,
SUM (recovered_clearing) recovered_clearing,
COUNT (recovered_clearing) cnt_recovered_clearing,
SUM (recovered_execution) recovered_execution,
COUNT (recovered_execution) cnt_recovered_execution,
SUM (recovered_transaction) recovered_transaction,
COUNT (recovered_transaction) cnt_recovered_transaction,
SUM (recovered_ord_mgt) recovered_ord_mgt,
COUNT (recovered_ord_mgt) cnt_recovered_ord_mgt,
SUM (recovered_settlement) recovered_settlement,
COUNT (recovered_settlement) cnt_recovered_settlement,
SUM (client_agent) client_agent,
COUNT (client_agent) cnt_client_agent,
SUM (client_order_mgt) client_order_mgt,
COUNT (client_order_mgt) cnt_client_order_mgt,
SUM (client_exec) client_exec, COUNT (client_exec) cnt_client_exec,
SUM (client_trans) client_trans,
COUNT (client_trans) cnt_client_trans,
SUM (client_clearing) client_clearing,
COUNT (client_clearing) cnt_client_clearing,
SUM (client_settle) client_settle,
COUNT (client_settle) cnt_client_settle,
SUM (chargeable_taxes) chargeable_taxes,
COUNT (chargeable_taxes) cnt_chargeable_taxes,
SUM (vendor_charge) vendor_charge,
COUNT (vendor_charge) cnt_vendor_charge,
SUM (routing_charges) routing_charges,
COUNT (routing_charges) cnt_routing_charges,
SUM (recovered_routing) recovered_routing,
COUNT (recovered_routing) cnt_recovered_routing,
SUM (client_routing) client_routing,
COUNT (client_routing) cnt_client_routing,
SUM (ticket_charges) ticket_charges,
COUNT (ticket_charges) cnt_ticket_charges,
SUM (recovered_ticket_charges) recovered_ticket_charges,
COUNT (recovered_ticket_charges) cnt_recovered_ticket_charges
FROM us_datamart_raw
GROUP BY order_date,
if_system,
business_dim_id,
time_dim_id,
account_dim_id,
ordertype_dim_id,
instr_dim_id,
execution_dim_id,
exec_exchange_dim_id;
-- Note: Index I_SNAP$_MV_US_DATAMART will be created automatically
-- by Oracle with the associated materialized view.
CREATE UNIQUE INDEX OS_OWNER.MV_US_DATAMART_UDX ON OS_OWNER.MV_US_DATAMART
(ORDER_DATE, TIME_DIM_ID, BUSINESS_DIM_ID, ACCOUNT_DIM_ID, ORDERTYPE_DIM_ID,
INSTR_DIM_ID, EXECUTION_DIM_ID, EXEC_EXCHANGE_DIM_ID)
NOLOGGING
NOPARALLEL
COMPRESS 7;
No of rows: 2228558
The query (taken Mondrian) I run against each of them is:
select sum("MV_US_DATAMART"."NOTIONAL") as "m0"
--, sum("MV_US_DATAMART"."FILLED_QUANTITY") as "m1"
--, sum("MV_US_DATAMART"."AGENT_CHARGES") as "m2"
--, sum("MV_US_DATAMART"."CLEARING_CHARGES") as "m3"
--, sum("MV_US_DATAMART"."EXECUTION_CHARGES") as "m4"
--, sum("MV_US_DATAMART"."TRANSACTION_CHARGES") as "m5"
--, sum("MV_US_DATAMART"."ROUTING_CHARGES") as "m6"
--, sum("MV_US_DATAMART"."ORDER_MANAGEMENT") as "m7"
--, sum("MV_US_DATAMART"."SETTLEMENT_CHARGES") as "m8"
--, sum("MV_US_DATAMART"."COMMISSION") as "m9"
--, sum("MV_US_DATAMART"."RECOVERED_AGENT") as "m10"
--, sum("MV_US_DATAMART"."RECOVERED_CLEARING") as "m11"
--,sum("MV_US_DATAMART"."RECOVERED_EXECUTION") as "m12"
--,sum("MV_US_DATAMART"."RECOVERED_TRANSACTION") as "m13"
--, sum("MV_US_DATAMART"."RECOVERED_ROUTING") as "m14"
--, sum("MV_US_DATAMART"."RECOVERED_ORD_MGT") as "m15"
--, sum("MV_US_DATAMART"."RECOVERED_SETTLEMENT") as "m16"
--, sum("MV_US_DATAMART"."RECOVERED_TICKET_CHARGES") as "m17"
--,sum("MV_US_DATAMART"."TICKET_CHARGES") as "m18"
--, sum("MV_US_DATAMART"."VENDOR_CHARGE") as "m19"
from "OS_OWNER"."MV_US_DATAMART" "MV_US_DATAMART"
where I uncomment a column at a time and rerun. I improved the TimesTen results since my first post, by retyping the NUMBER columns to BINARY_FLOAT. The results I got were:
No Columns ORACLE TimesTen
1 1.05 0.94
2 1.07 1.47
3 2.04 1.8
4 2.06 2.08
5 2.09 2.4
6 3.01 2.67
7 4.02 3.06
8 4.03 3.37
9 4.04 3.62
10 4.06 4.02
11 4.08 4.31
12 4.09 4.61
13 5.01 4.76
14 5.02 5.06
15 5.04 5.25
16 5.05 5.48
17 5.08 5.84
18 6 6.21
19 6.02 6.34
20 6.04 6.75 -
Count (*) for select stmt take more time than execute a that sql stmt
HI
count (*) for select stmt take more time than execute a that sql stmt
executing particular select stmt take 2.47 mins but select stmt is using the /*+parallel*/ (sql optimer) in that sql command for faster execute .
but if i tried to find out total number of rows in that query it takes more time ..
almost 2.30 hrs still running to find count(col)
please help me to get count of row faster.
thanks in advance...797525 wrote:
HI
count (*) for select stmt take more time than execute a that sql stmt
executing particular select stmt take 2.47 mins but select stmt is using the /*+parallel*/ (sql optimer) in that sql command for faster execute .
but if i tried to find out total number of rows in that query it takes more time ..
almost 2.30 hrs still running to find count(col)
please help me to get count of row faster.
thanks in advance...That may be because your client is displaying only the first few records when you are running the "SELECT *". But when you run "COUNT(*)", the whole records has to be counted.
As already mentined please read teh FAQ to post tuning questions. -
Setting ECHO ON takes more time?
Hi all,
Recently, we had to run a huge file with INSERTs in production database. But before that when the same file was run in testing database, we set the ECHO on in SQL*PLUS and it took more time, I mean, the difference was huge, in fact. I wish to know if setting ECHO to ON takes more time than setting ECHO to OFF. Does this have an effect on time it takes to make the INSERTs.
Regards,
...Yingkuan,
Thanks for the reply. In fact, I know the function what ECHO does. Now suppose I have 121,000 lines of INSERT statements in a file called "inserts.sql" and I am going to execute it in SQL*PLUS to a remote server, the server being 9.2.0.8.0. Will there be a time difference in completing the scripts if I set the ECHO to ON and if I set the ECHO to OFF. Consider the following scenario:
Scenario 1
========
SQL> SET ECHO ON;
SQL> @inserts.sql;
Elapsed: 02:00:00.00
Scenario 2
========
SQL> SET ECHO OFF;
SQL> @inserts.sql;
Elapsed: 01:00:00.00
Please note the "Elapsed" time between the 2 scenarios. Will the ECHO setting impact the elapsed time? I think this setting will not cause the file to take long time to complete as it is just a client side setting. Please clarify.
Regards,
...
Maybe you are looking for
-
Cost center in GR/IR line item
Hi, I found in invoice verification of fixed asset purchasing, cost center is not always posted for GR/IR clearing account. In ACSET, cost center and internal order type is both activated for APC value posting. Can anyone give me any guide? Thanks f
-
How do you avoid unneccesary "array copies"?
Hello - I have been having significant difficulty trying to optimize my code as I have been finding that LabView tends to make copies of variables almost everytime you access them. This may not be a big deal some times, but in my case, I am using arr
-
Smartform output as Email from CRM order
HI There, I would like to send my smartform as PDF attachment from an action. Right now CL_DOC_PROCESSING_CRM_ORDER class and CRM_ORDER_EXEC_SMART_FORM method is configured in my Action profile. Do I need to take a clone of this standard method and m
-
STA100-3 10.2.1.2991 I notice that sometimes the File Manager is slow or does seem to work. In particular, SMS Backup app (which has worked for over a year) has started to fail when it calls the File Manager. The app developer doesn't see this, but
-
Problem using an SAP Web service??
Hi I am currently trying to use a Web Dynpro interface to link into an SAP Web Service and search for some data. However this is not working at the moment as I believe there is an issue with my system landscape and i don't know how to resolve it. I g