BPEL fault policy takes more time, when rethrowing

Hi All,
I have a scenario where BPEL fault policy is taking more time to re-throw the fault back to BPEL
Scenario:
1) Partner link service throws as business exception
2) This exception is first caught by BPEL fault policy, this in-turn will invoke "oracle.apps.aia.core.eh.BPELJavaAction" & then it is re-throw's back to BPEL process. Then time while rethrow'n back to BPEL process it taking too much time.
Environment:
SOA suite : Version 10.1.3.4.0 with AIA
Hi all , any updates on this
Edited by: user535670 on Aug 19, 2009 7:43 PM

Abap team debugged and found out that there was an issue with RFC in ECC system.
RFC connection was not working. it was causing the flow to wait for 1 mins. Basis fixed the issue to make RFC working. now interface works without connection time out.

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 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

BSEG Table takes more time

Hi Experts,
Users raising bill using MIRO it takes more time when i check throuh SM50 and st03 i found that the data fectching from the table BSEG takes more time kinldy let me know whether i need to increase table parameter.....size if so how can i do that ?
Regards...
Venki

The famous BSEG table is a cluster table.
It holds the Accounting Document Segment. It is part of the Pool cluster RFBLG and lives in the package: FBAS (Financial accounting 'Basis').
You can't read a cluster table exactly the way you read a database (old speak, transparent table).
You can use a program to read called RFPPWF05
Note 435694: Display BSEG item by calling FB09D (modified FB09)
Other possiblity: Other possibility: CALL DIALOG 'RF_ZEILEN_ANZEIGE', but since this is a dialog I don't think this would work.
In any event go to FBAS Package (development class) to see your business objects, class library and functions.
Having such criticality, you set to tablepsace to 'autogrow'
Regards
Sekhar

A block of code takes more time in JRE 6_20 but less in the previous versio

while (entries.hasMoreElements()) {
ZipEntry zipEntry = (ZipEntry) entries.nextElement();
is = zipFile.getInputStream(zipEntry);
File file = new File(unzipDir, zipEntry.getName());
if (is.available() == 0) {
file.mkdir();
is.close();
} else {
file.createNewFile();
fos = new FileOutputStream(file);
CommonUtils.connectIO(is, fos, -1, true);
}

Sorry a type,. The above code takes more time when I run withJDK 6_20. But its less time if the previous version is used. Cannot figure whats wrong. Here is the full method.
* Unzips the specified file into the specified directory. The optional file names list allows the caller
* to specify the actual files that get unzipped.
* @param srcFile the file to unzip
* @param unzipDir the directory where the unzipped files will be put
* @param fileNames the optional list of name strings for the zip entries to unzip or <code>null</code> to unzip
* all entries
* @throws NullPointerException if either the source file or the unzip directory is <code>null</code>
* @throws javax.faces.FacesException if the
public static void unzipFile(File srcFile, File unzipDir, List fileNames) {
if (srcFile == null) {
throw new NullPointerException("The zip file argument is null");
if (unzipDir == null) {
throw new NullPointerException("The unzip directory argument is null");
ZipFile zipFile = null;
InputStream is = null;
FileOutputStream fos = null;
try {
zipFile = new ZipFile(srcFile);
Enumeration entries = null;
if (fileNames != null) {
// Use a vector only so we can abstract away the zip entries enumeration...
Vector v = new Vector();
Iterator it = fileNames.iterator();
while (it.hasNext()) {
String name = (String) it.next();
v.add(new ZipEntry(name));
entries = v.elements();
} else {
entries = zipFile.entries();
while (entries.hasMoreElements()) {
ZipEntry zipEntry = (ZipEntry) entries.nextElement();
is = zipFile.getInputStream(zipEntry);
File file = new File(unzipDir, zipEntry.getName());
if (is.available() == 0) {
file.mkdir();
is.close();
} else {
file.createNewFile();
fos = new FileOutputStream(file);
CommonUtils.connectIO(is, fos, -1, true);
catch (IOException e) {
throw new FacesException("Problem unzipping file " + srcFile.getAbsolutePath(), e);
finally {
try {
if (is != null) {
is.close();
if (fos != null) {
fos.close();
if (zipFile != null) {
zipFile.close();
catch (IOException e) {
throw new FacesException("Problem closing resources when unzipping file " + srcFile.getAbsolutePath(), e);
}

Fault policy does not work when throwing remoteFault in bpel

Hi
I have a BPEL-proces in which I throw a remoteFault.
In the fault-policy there is a condition for this fault
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
name="bpelx:remoteFault">
<condition>
<action ref="ora-java"/>
</condition>
</faultName>
But the fault-policy does not work if I throw this remoteFault in de bpel. But when I invoke another service (which is shutdown), then I get a remoteFault and for this remoteFault the fault-policy works well.
Any idea why the fault-policy does not work when I throw the remoteFault?
Regards

BPEL fault works only on invocation failures.
Fault management will work based on the remote fault from the remote service, you cannot throw remote fault from bpel and capture that in fault management and process.
The following are the actions that we can take on faults.
1. Human Intervention
2. Rethrow [rethrowFault]
3. Termination [abort]
4. Replay Fault [replayScope]
5. Custom Java Action [javaAction]
6. Retry [retry]
Hope this helps !!!
Thanks,
Vijay

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 M

Hi,
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

PDF Form Takes More Time To Open when using designer 7.1.3129.1.296948 + Reader 8 above

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 M

Hi,
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

Saving a book as PDF takes significantly more time when the file binary *.fm rater than *.mif?

Is it possible, that saving a book (with FrameMaker 10) as PDF takes significantly more time when the file is formatted in the binary *.fm rather than the *.mif format?
We have books (+160p) that take about 20 min to be saved as PDF, whereas the same book in MIF format can be saved as PDF within about 4 minutes. Is this a known issue?
Or could that be a problem with our books?
Does anyone know how to speed up the process (how to tweak) or are there any special adjustments in the books or documents that might slowdown the process of saving them as PDF?
The distiller seems not to be the problem. The distiller takes equally long for both formats.
best regards

Strikes me as peculiar. I would expect that FM is rendering from the data structures in memory, which I would expect to be essentially identical whether originally opened as .fm or .mif.
If return-to-UI time is important, the fastest path is:
print to local .ps file
Distill separately.
And it sounds like you have the full Acrobat product, and thus have full Distiller.
I don't have sufficient experience with Print-to-PDF vs. Save-as-PDF to opine on potential time differences for those paths.

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).

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.

Oracle coherence first read/write operation take more time

I'm currently testing with oracle coherence Java and C++ version and from both versions for writing to any local or distributed or near cache first read/write operation take more time compared to next consecutive read/write operation. Is this because of boost operations happening inside actual HashMap or serialization or memory mapped implementation. What are the techniques which we can use to improve the performance with this first read/write operation?
Currently I'm doing a single read/write operation after fetching the NamedCache Instance. Please let me know whether there's any other boosting coherence cache techniques available.

In which case, why bother using Coherence? You're not really gaining anything, are you?
What I'm trying to explain is that you're probably not going to get that "micro-second" level performance on a fully configured Coherence cluster, running across multiple machines, going via proxies for c++ clients. Coherence is designed to be a scalable, fault-tolerant, distributed caching/processing system. It's not really designed for real-time, guaranteed, nano-second/micro-second level processing. There are much better product stacks out there for that type of processing if that is your ultimate goal, IMHO.
As you say, just writing to a small, local Map (or array, List, Set, etc.) in a local JVM is always going to be very fast - literally as fast as the processor running in the machine. But that's not really the focus of a product like Coherence. It isn't trying to "out gun" what you can achieve on one machine doing simple processing; Coherence is designed for scalability rather than outright performance. Of course, the use of local caches (including Coherence's near caching or replicated caching), can get you back some of the performance you've "lost" in a distributed system, but it's all relative.
If you wander over to a few of the CUG presentations and attend a few CUG meetings, one of the first things the support guys will tell you is "benchmark on a proper cluster" and not "on a localised development machine". Why? Because the difference in scalability and performance will be huge. I'm not really trying to deter you from Coherence, but I don't think it's going to meet you requirements when fully configured in a cluster of "1 Micro seconds for 100000 data collection" on a continuous basis.
Just my two cents.
Cheers,
Steve
NB. I don't work for Oracle, so maybe they have a different opinion. :)

How to do Query optimization?It takes more time to fetch the record from db. Very urgent, I need your assistance

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_description

Hi,
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.

Select Query Takes more time

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!

Bind variable code takes more time to complete?

Hello, My database is oracle11g.
I have same plsql code and first one is without bind variable and second one is with bind variable. Usually, bind variable should take less time. But here
the bind variable takes more time than the regular code... Can any one please explain why?
SQL> alter system flush shared_pool;
System altered.
SQL> declare
2 cursor c1 is select * from emp where rownum < 50;
3 l_start NUMBER DEFAULT DBMS_UTILITY.GET_TIME;
4 v_cnt number;
5 begin
6 for i in c1 loop
7 SELECT count(*) into v_cnt
8 FROM rate
9 WHERE rate_id IN (SELECT rate_id
10 FROM ratedetail
11 WHERE benefit_id = i.benefit_id)
12 AND effective_date =
13 TO_DATE ('2011-01-23 00:00:00', 'yyyy-MM-dd HH24:MI:SS')
14 AND rate_type_id = 1;
15 end loop;
16 DBMS_OUTPUT.PUT_LINE('total minutes....'||ROUND(ROUND((DBMS_UTILITY.GET_TIME - l_start)/100, 2)
/60,3));
17 end;
18 /
total minutes.....06
PL/SQL procedure successfully completed.
SQL> alter system flush shared_pool;
System altered.
SQL>
SQL> declare
2 cursor c1 is select benefit_id from emp where rownum < 50;
3 l_start NUMBER DEFAULT DBMS_UTILITY.GET_TIME;
4 v_cnt number;
5 begin
6 for i in c1 loop
7 execute immediate 'SELECT count(*)
8 FROM rate
9 WHERE rate_id IN (SELECT rate_id
10 FROM ratedetail
11 WHERE benefit_id = :x)
12 AND effective_date = trunc(sysdate)-202
13 AND rate_type_id = 1'
14 into v_cnt using i.benefit_id;
15 end loop;
16 DBMS_OUTPUT.PUT_LINE('total minutes....'||ROUND(ROUND((DBMS_UTILITY.GET_TIME - l_start)/100, 2)
/60,3));
17 end;
18 /
total minutes.....061
PL/SQL procedure successfully completed.
SQL>

Shrinika wrote:
Thanks for the clarification.. Now i understand...
One final question on this thread before i close this thread....
My database is set to CURSOR_SHARING=FORCE for some reason. It seems somebody applied a "quick and dirty fix" to "database is slow" problem. BAD PRACTICE
My question is, when we use bind variable, does it parse the sql code every time? or does it reuse the execution plan?
In my database, it reuse the execution plan... Just checking... When we set CURSOR_SHARING=FORCE, it should generate the execution plan
for every unqiue sql code... Is that correct? Am i confusing?If by "parse" you mean a "hard parse" (which generates execution plan), then the answer is NO. As you observed, it reuses execution plan.
For e.g. with CURSOR_SHARING=FORCE setting, following SQLs
select employee_no, first_name, last_name from employees where dept_no = 10 ;and
select employee_no, first_name, last_name from employees where dept_no = 20 ;would tend to reuse the same execution plan since both of these will be rewritten by oracle (before execution) as
select employee_no, first_name, last_name from employees where dept_no = :SYS01 ;Hope this helps.
Edited by: user503699 on Aug 14, 2010 3:55 AM

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,
PCR

Hi 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

BPEL fault policy takes more time, when rethrowing

Similar Messages

Maybe you are looking for