Jdbc takes more time then sqlplus

Hi,
I am using type 4 jdbc driver(classes12.jar) to access the oracle10.0.2.
The table is quite huge having total rows 33,213,317,702.
The problem I am facing is, the same query If i runs on TOAD takes time of the order of 30-40 seconds.
And If I run using JDBC it take around 250 seconds.
Which is significantly larger. Has anbody have clues on that
The query return just 30 rows. I am using Prepared Statement. and the time mentioned above is just the time taken to execute query. It doesn't include the time to get the connection or to get data from the result set.

>
I have removed this from the sql query /*+ ORDERED parallel(a11) use_hash(a11)
*******************************SQLPlus Log *********************
Execution Plan
Plan hash value: 690042758
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 1 | 1253 | 32188 (40)| 00:09:40 | | | | | |
|* 1 | COUNT STOPKEY | | | | | | | | | | |
| 2 | TEMP TABLE TRANSFORMATION | | | | | | | | | | |
| 3 | PX COORDINATOR | | | | | | | | | | |
| 4 | PX SEND QC (RANDOM) | :TQ10001 | 1 | 18 | 1 (0)| 00:00:01 | | | Q1,01 | P->S | QC (RAND) |
| 5 | LOAD AS SELECT | | | | | | | | Q1,01 | PCWP | |
| 6 | PX RECEIVE | | 1 | 18 | 1 (0)| 00:00:01 | | | Q1,01 | PCWP | |
| 7 | PX SEND ROUND-ROBIN | :TQ10000 | 1 | 18 | 1 (0)| 00:00:01 | | | Q1,00 | P->P | RND-ROBIN |
| 8 | PX PARTITION HASH ALL | | 1 | 18 | 1 (0)| 00:00:01 | 1 | 64 | Q1,00 | PCWC | |
| 9 | TABLE ACCESS BY LOCAL INDEX ROWID | DIM_COM_ADVERTISER_ACCOUNT | 1 | 18 | 1 (0)| 00:00:01 | 1 | 64 | Q1,00 | PCWP | |
| 10 | BITMAP CONVERSION TO ROWIDS | | | | | | | | Q1,00 | PCWP | |
|* 11 | BITMAP INDEX SINGLE VALUE | DIM_ADV_ACCOUNT_BIDX29 | | | | | 1 | 64 | Q1,00 | PCWP | |
| 12 | PX COORDINATOR | | | | | | | | | | |
| 13 | PX SEND QC (ORDER) | :TQ20004 | 1 | 1253 | 32188 (40)| 00:09:40 | | | Q2,04 | P->S | QC (ORDER) |
| 14 | VIEW | | 1 | 1253 | 32188 (40)| 00:09:40 | | | Q2,04 | PCWP | |
|* 15 | SORT ORDER BY STOPKEY | | 1 | 214 | 32186 (40)| 00:09:40 | | | Q2,04 | PCWP | |
| 16 | PX RECEIVE | | 1 | 1253 | | | | | Q2,04 | PCWP | |
| 17 | PX SEND RANGE | :TQ20003 | 1 | 1253 | | | | | Q2,03 | P->P | RANGE |
|* 18 | SORT ORDER BY STOPKEY | | 1 | 1253 | | | | | Q2,03 | PCWP | |
| 19 | SORT GROUP BY | | 1 | 214 | 32186 (40)| 00:09:40 | | | Q2,03 | PCWP | |
| 20 | PX RECEIVE | | 1 | 34 | 3 (0)| 00:00:01 | | | Q2,03 | PCWP | |
| 21 | PX SEND HASH | :TQ20002 | 1 | 34 | 3 (0)| 00:00:01 | | | Q2,02 | P->P | HASH |
| 22 | BUFFER SORT | | 1 | 1253 | | | | | Q2,02 | PCWP | |
| 23 | TABLE ACCESS BY LOCAL INDEX ROWID | DIM_COM_ACCOUNT_TERM | 1 | 34 | 3 (0)| 00:00:01 | 1 | 1 | Q2,02 | PCWC | |
| 24 | NESTED LOOPS | | 1 | 214 | 32184 (40)| 00:09:40 | | | Q2,02 | PCWP | |
| 25 | NESTED LOOPS | | 1 | 180 | 32183 (40)| 00:09:40 | | | Q2,02 | PCWP | |
|* 26 | HASH JOIN | | 1 | 61 | 32183 (40)| 00:09:40 | | | Q2,02 | PCWP | |
| 27 | PX RECEIVE | | 1 | 7 | 2 (0)| 00:00:01 | | | Q2,02 | PCWP | |
| 28 | PX SEND HASH | :TQ20000 | 1 | 7 | 2 (0)| 00:00:01 | | | Q2,00 | P->P | HASH |
| 29 | PX BLOCK ITERATOR | | 1 | 7 | 2 (0)| 00:00:01 | | | Q2,00 | PCWC | |
| 30 | TABLE ACCESS FULL | SYS_TEMP_0FDAE1E8A_59FE93DB | 1 | 7 | 2 (0)| 00:00:01 | | | Q2,00 | PCWP | |
| 31 | PX RECEIVE | | 7855 | 414K| 32180 (40)| 00:09:40 | | | Q2,02 | PCWP | |
| 32 | PX SEND HASH | :TQ20001 | 7855 | 414K| 32180 (40)| 00:09:40 | | | Q2,01 | P->P | HASH |
| 33 | PX PARTITION HASH SUBQUERY | | 7855 | 414K| 32180 (40)| 00:09:40 |KEY(SQ)|KEY(SQ)| Q2,01 | PCWC | |
| 34 | TABLE ACCESS BY LOCAL INDEX ROWID| FACT_TRF_ADV_TERM_DAILY | 7855 | 414K| 32180 (40)| 00:09:40 | KEY | KEY | Q2,01 | PCWP | |
| 35 | BITMAP CONVERSION TO ROWIDS | | | | | | | | Q2,01 | PCWP | |
| 36 | BITMAP MINUS | | | | | | | | Q2,01 | PCWP | |
| 37 | BITMAP MINUS | | | | | | | | Q2,01 | PCWP | |
| 38 | BITMAP AND | | | | | | | | Q2,01 | PCWP | |
| 39 | BITMAP MINUS | | | | | | | | Q2,01 | PCWP | |
| 40 | BITMAP MINUS | | | | | | | | Q2,01 | PCWP | |
| 41 | BITMAP MERGE | | | | | | | | Q2,01 | PCWP | |
| 42 | BITMAP KEY ITERATION | | | | | | | | Q2,01 | PCWP | |
| 43 | BUFFER SORT | | | | | | | | Q2,01 | PCWP | |
| 44 | TABLE ACCESS FULL | SYS_TEMP_0FDAE1E8A_59FE93DB | 1 | 13 | 2 (0)| 00:00:01 | | | Q2,01 | PCWP | |
|* 45 | BITMAP INDEX RANGE SCAN | FACT_TRF_ADVTD_NEW2_BDX16 | | | | | KEY | KEY | Q2,01 | PCWP | |
|* 46 | BITMAP INDEX SINGLE VALUE | FACT_TRF_ADVTD_NEW2_BDX14 | | | | | KEY | KEY | Q2,01 | PCWP | |
|* 47 | BITMAP INDEX SINGLE VALUE | FACT_TRF_ADVTD_NEW2_BDX14 | | | | | KEY | KEY | Q2,01 | PCWP | |
| 48 | BITMAP MERGE | | | | | | | | Q2,01 | PCWP | |
| 49 | BITMAP KEY ITERATION | | | | | | | | Q2,01 | PCWP | |
| 50 | BUFFER SORT | | | | | | | | Q2,01 | PCWP | |
|* 51 | TABLE ACCESS FULL | DIM_COM_DATE | 371 | 5194 | 4 (0)| 00:00:01 | | | Q2,01 | PCWP | |
|* 52 | BITMAP INDEX RANGE SCAN | FACT_TRF_ADTD_NEW2_BDX1 | | | | | KEY | KEY | Q2,01 | PCWP | |
|* 53 | BITMAP INDEX SINGLE VALUE | FACT_TRF_ADVTD_NEW2_BDX14 | | | | | KEY | KEY | Q2,01 | PCWP | |
|* 54 | BITMAP INDEX SINGLE VALUE | FACT_TRF_ADVTD_NEW2_BDX14 | | | | | KEY | KEY | Q2,01 | PCWP | |
| 55 | PARTITION RANGE SINGLE | | 1 | 119 | 3 (0)| 00:00:01 | 1 | 1 | Q2,02 | PCWP | |
| 56 | PARTITION HASH ALL | | 1 | 119 | 3 (0)| 00:00:01 | 1 | 64 | Q2,02 | PCWP | |
| 57 | TABLE ACCESS BY LOCAL INDEX ROWID | DIM_COM_URL | 1 | 119 | 3 (0)| 00:00:01 | 1 | 64 | Q2,02 | PCWP | |
|* 58 | INDEX RANGE SCAN | IX_DIM_COM_URL_BID_URLSID | 1 | | 2 (0)| 00:00:01 | 1 | 64 | Q2,02 | PCWP | |
| 59 | PARTITION RANGE SINGLE | | 1 | | 2 (0)| 00:00:01 | 1 | 1 | Q2,02 | PCWP | |
| 60 | PARTITION HASH ITERATOR | | 1 | | 2 (0)| 00:00:01 | KEY | KEY | Q2,02 | PCWP | |
|* 61 | INDEX RANGE SCAN | DIM_COM_ACCOUNT_TERM_IDX1 | 1 | | 2 (0)| 00:00:01 | KEY | KEY | Q2,02 | PCWP | |
Predicate Information (identified by operation id):
1 - filter(ROWNUM<=30)
11 - access("ACCOUNT_KEY"='6270741410')
15 - filter(ROWNUM<=30)
18 - filter(ROWNUM<=30)
26 - access("A11"."ACCOUNT_SID"="C0")
45 - access("A11"."ACCOUNT_SID"="C0")
46 - access("A11"."PRODUCT_SID" IS NULL)
47 - access("A11"."PRODUCT_SID" IS NULL)
51 - filter("A13"."DATE_KEY">=TO_DATE('2007-06-13 00:00:00', 'yyyy-mm-dd hh24:mi:ss'))
52 - access("A11"."DATE_SID"="A13"."DATE_SID")
53 - access("A11"."PRODUCT_SID"=1)
54 - access("A11"."PRODUCT_SID"=8)
58 - access("A11"."URL_SID"="URL_SID")
61 - access("A11"."TERM_SID"="TERM_SID")
Statistics
559 recursive calls
185 db block gets
140470 consistent gets
704 physical reads
72528 redo size
3230 bytes sent via SQL*Net to client
349 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
123 sorts (memory)
0 sorts (disk)
29 rows processed
SQL>
JDBC Log is
Is something like this
BCV FUNC CharacterSet.convertAL32UTF8BytesToJavaChars: return=28
DBCV FUNC DBConversion._CHARBytesToJavaChars(bytes[], nbytes[], chars[], cs): returned 28
DBCV FUNC DBConversion.CHARBytesToJavaChars(bytes[]= (6000 bytes):
68 74 74 70 3a 2f 2f 77 77 77 2e 70 69 6e 6f 75 74 6c 65 74
2e 63 6f 6d 2f 70 69 6e 72 74 73 2e 61 73 70 78 3f 67 61 64
3d 43 4b 62 4c 69 36 63 43 45 67 69 71 72 35 33 58 6b 66 48
52 48 52 69 4f 79 4a 6e 39 41 79 44 4f 2d 70 49 4e 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
... last 5800 bytes were not printed to limit the output size byteOffset=0, chars[]= (136020 bytes):
00 22 00 63 00 75 00 73 00 74 00 6f 00 6d 00 20 00 6c 00 61
00 70 00 65 00 6c 00 20 00 70 00 69 00 6e 00 73 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
... last 135820 bytes were not printed to limit the output sizecharOffset=65009, nbytes[0]=25, charSize=1500)
DBCV FUNC DBConversion._CHARBytesToJavaChars(bytes[]= (6000 bytes):
68 74 74 70 3a 2f 2f 77 77 77 2e 70 69 6e 6f 75 74 6c 65 74
2e 63 6f 6d 2f 70 69 6e 72 74 73 2e 61 73 70 78 3f 67 61 64
3d 43 4b 62 4c 69 36 63 43 45 67 69 71 72 35 33 58 6b 66 48
52 48 52 69 4f 79 4a 6e 39 41 79 44 4f 2d 70 49 4e 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
... last 5800 bytes were not printed to limit the output size, byteOffset=0, chars[]= (136020 bytes):
00 22 00 63 00 75 00 73 00 74 00 6f 00 6d 00 20 00 6c 00 61
00 70 00 65 00 6c 00 20 00 70 00 69 00 6e 00 73 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
... last 135820 bytes were not printed to limit the output size, charOffset=65009, cs=873, nbytes[0]=25,charSize=1500)
DBCV FUNC CharacterSet.convertAL32UTF8BytesToJavaChars(bytes (length=6000),offsetBytes=0,chars (length=68010), offsetChars=65009, countArr[0]=25,convertWithReplacement=true,charSize=1500)
DBCV FUNC CharacterSet.convertAL32UTF8BytesToJavaChars: return=25
DBCV FUNC DBConversion._CHARBytesToJavaChars(bytes[], nbytes[], chars[], cs): returned 25
JTTC FUNC oracle.jdbc.driver.T4CPreparedStatement.execute_for_rows:return: validRows = 29
DRVR FUNC OracleStatement.execute_maybe_describe():return validRows = 29, needToPrepareDefineBuffer = false
DRVR FUNC OracleStatement.doExecuteWithTimeout():return validRows = 29, needToPrepareDefineBuffer = false
I am using literals.
If you need any more info pl. let me know.
Thanks much
* Sorry - The sqlplus log is not going in correct format.

Similar Messages

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.

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

'BAPI_GOODSMVT_CREATE' takes more time for creating material document for the 1st time

Hi Experts,
I am doing goods movement using BAPI_GOODSMVT_CREATE in my custom code.
Then there is some functional configuration such that, material documents and TR and TO are getting created.
Now I need to get TO and TR numbers from LTAK table passing material documnt number and year, which I got from above used BAPI.
The problem I am facing is very strange.
Only for the 1st time, I am not finding TR and TO values in LTAK table. And subsequent runs I get entries in LTAK in there is a wait time of 5 seconds after bapi call.
I have found 'BAPI_GOODSMVT_CREATE' takes more time for creating material document with similar issue, but no solution or explanation.
Note 838036 says something similar, but it seems obsolete.
Kindly share your expertise and opinions.
Thanks,
Anil

Hi,
please check if some of following OSS notes are not valid for your problem:
[Note 838036 - AFS: Performance issues during GR with ref. to PO|https://service.sap.com/sap/support/notes/838036]
[Note 391142 - Performance: Goods receipt for inbound delivery|https://service.sap.com/sap/support/notes/391142]
[Note 1414418 - Goods receipt for customer returns: Various corrections|https://service.sap.com/sap/support/notes/1414418]
The other idea is not to commit each call, but executing commit of packages e.g. after 1000 BAPI calls.
But otherwise, I am afraid you can not do a lot about performance of standard BAPI. Maybe there is some customer enhancement which is taking too long inside the BAPI, but this has to be analysed by you. To analyse performance, just execute your program via tr. SE30.
Regards
Adrian

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!

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.

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

Calc takes more time than previous

Hi All,
I have a problem with the calc as this calc take more time to execute please help!!!
I have included calc cache high in the .cfg file.
FIX (&As, &Af, &C,&RM, @RELATIVE("Pr",0), @RELATIVE("MS",0), @RELATIVE("Pt",0), @RELATIVE("Rn",0),@RELATIVE("Ll",0))
CLEARDATA "RI";
/* 22 Comment */
FIX("100")
"RI" = @ROUND ((("RDL")/("SBE"->"RDL"->"TMS"->"TP"->"TR"->"AF"->"Boom")),8);
ENDFIX
FIX("200")
"RI" = @ROUND ((("RDL")/("ODE"->"RDL"->"TMS"->"T_P"->"TR"->"AF"->"Boom")),8);
ENDFIX
Appriciate your help.
Regards,
Mink.

Mink,
If the calculation script ,which you are using is the same which performed better before and data being processes is same ( i mean data might not have exceptionally grown more).Then, there must be other reasons like server side OS , processor or memory issues.Consult sys admin .Atleast you ll be sure that there is nothing wrong with systems.
To fine tune the calc , i think , you can minimise fix statements . But,thats not the current issue though
Sandeep Reddy Enti
HCC
http://analytiks.blogspot.com

Why import of change request in production takes more time than quality?

Hello All,
why import of change request in production takes more time than import into quality?

Hi jahangeer,
I believe it takes same time to import a request in both quality and production as they will be in sync.
Even then if it takes more time in production that may depend on the change request.
Thanks
Pavan

Af:commandNavigationItem takes more time to perform action on screen

For my project there is a dynamic implementation of af:commandNavigationItem and the actions also will be binded during runtime.
This code was working fine with the JDeveloper 11.1.1.0.2 (OWS 10.3.0) Version, but after migrating the code to JDeveloper 11.1.1.2.0 (OWS 10.3.2), it shows hourglass for a longer time (which was unusual) and then it perform the operation.
I ran the project in Debug mode and I found it takes more time to come to the breakpoint.
It writes the below information in console
<UnifiedDialogTag><setVisible> property "visible" setter is using a no-op implementation. Used in extreme cases when the property value, beyond the default value, results in unwanted behavior.
Experts: Please through some light to proceed with this issue as I am looking some lead information from where I have to look into the issue.

Hi,
can you file a bug or provide a testcase ?
Frank

MRP job takes more time (Duration / Sec)

Hello PP Guru’s,
I have below situation in production environment,
MRP job for plant – A (Takes more time – 14.650)
MRP job for plant – B (Takes less time – 4.512)
When I compare the variant / attributes with plant A and B, I observe only difference in attribute is scheduling (2 - Lead Time Scheduling and Capacity Planning) for plant A.
For plant B scheduling (1- Determination of Basic Dates for Planned) it was updated.
So in my observation this scheduling is playing a major role for MRB job which takes more time in plant – A.
I am in process of changing the variant attribute for plant – A from scheduling 2 to scheduling 1.
I wanted to know from experts whether if I change any impact / problem will happen in future for plant A or not.
Please let me know what all the hidden impacts are there if I change the scheduling in variant attribute.
I look forward to your valuable input to reduce time for my MRP related job.
Regards,
Kumar S

Hi Kumar,
You have no need to change the inhouse production time you just need to update the Lot size dependent inhouse production time in work scheduling view of material master. That you can do by scheduling the routing/recipe.
Transactions CA97 or CA97N can be used to update the in-house production time with the information from the routing.
If business don't want to have the capacity planning for planned orders then you change the scheduling from 2 to 1 basic date scheduling.
Expert Caetano already answer you query
The reports listed below can be used to compare the MRP past executions regarding the runtime:
RMMDMONI: This report compares the runtime of the MRP execution and also provides the total of planning elements (planned orders, purchase requisitions, etc) changed, created or deleted. It also shows which planning parameters where used and how much time MRP spent on each step (database read, BOM explosion, MRP calculation, scheduling, BAdIs, etc). With this information is possible to observe the relation of runtime and number of elements changed/created/deleted and also to see on which step MRP is taking more time.
RMMDPERF: This report shows the "material hit list", that means, which materials had the highest runtime during the MRP execution and also on which step MRP is taking more time. Knowing which materials have the highest runtime, allow you to isolate the problem and reproduce it on MD03, where it is possible to run an ABAP or SQL trace for a more detailed analysis.
Regards,
R.Brahmankar

Why view have no stored data ? And what is the reason view take more time

Why view have no stored data ? And what is the reason view take more time to query ?
what happen if a view have stored data?

user12941450 wrote:
I want to know the reason that why querying view is slower then querying a normal table?..Untrue.
For example take a table with 2laks record and a view for that table.
If i make a query like( Select name,address from table) then it works fast then select(name,address)from view..Incorrectly interpreting the results.
A view is a SQL statement. Only difference is that the SQL statement is stored in the database's dictionary. Let's consider the following view:
create or replace view foo_view as select * from empWhen you use the view as follows:
select * from foo_viewOracle sees it as follows:
select * from (select * from emp)This is no slower, or no faster, than providing the following SQL to Oracle:
select * from empSo if you observe a difference in performance between using plain SQL versus using that same SQL via a view, there are other reasons for that difference in performance. The reason is NOT that views are slower.

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

Multithreaded File Copy takes more time 1.5 times than single thread.

import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.nio.channels.FileChannel;
public class TestMulti implements Runnable {
     public static Thread Th1;
     public static Thread Th2;
     String str = null;
     static int seqNumber = 1000000000;
     public static void main(String args[]) {
          Th1 = new Thread(new TestMulti("1_1"));
          Th2 = new Thread(new TestMulti("1_2"));
          Th1.start();
          Th2.start();
          try {
               Th1.join();
               Th2.join();
          } catch (Exception e) {
               e.printStackTrace();
     public TestMulti(String str) {
          this.str = str;
     public void run() {
          File f = new File("C:/Songs2/" + str);
          File files[] = f.listFiles();
          String fileName = "";
          String seqName = "";
          String seq = "";
          int sequenceNo = 0;
          try {
               for (int j = 0; j < files.length; j++) {
                    File musicFiles[] = files[j].listFiles();
                    for (int k = 0; k < musicFiles.length; k++) {
                         seq = "18072006";
                         seqName = seq + seqNumber;
                         sequenceNo = 10000 + seqNumber % 100;
                         seqNumber = seqNumber + 1;
                         fileName = musicFiles[k].getName();
                         String fileExt = fileName.substring(fileName.length() - 3,fileName.length());
                         String targetFile = "C:/Songs1/" + sequenceNo;
                         File fi = new File(targetFile);
                         if (!fi.exists()) { fi.mkdir(); }
                         targetFile = "C:/Songs1/" + sequenceNo + "/" + seqName+ "." + fileExt;
                         FileInputStream fin = new FileInputStream(musicFiles[k]);
                         FileChannel fcin = fin.getChannel();
                         FileOutputStream fout = new FileOutputStream(targetFile);
                         FileChannel fcout = fout.getChannel();
                         fcin.transferTo(0, fcin.size(), fcout);
                         fout.flush();
                         fcout.close();
                         fcin.close();
                         fout.close();
                         fin.close();
          } catch (Exception e) {
               e.printStackTrace();
Multithreaded File Copy takes more time 1.5 times than single thread.
Is there any issue with this code. Please help me.

If all of your threads are doing CPU-intensive work, or all are doing I/O to the same interface (for example, writing to the same physical disk), then multithreading would not be expected to help you.
Multithreading does not magically make your CPU able to do more work per unit time than it could otherwise.
Multithreading does not magically make your network interface or disk controller able to pump more bytes through than it could otherwise.
Where multithreading helps (some or all of this has already been mentioned):
* When you have multiple, independent CPU-bound tasks AND multiple CPUs available on which to execute them.
* When you have tasks that involve a mix of CPU-bound and I/O-bound work. The CPU-bound stuff can crank while the I/O-bound stuff waits for bytes to be written or read, thus making use of what would otherwise be CPU "dead time."
What you're doing does not fit either of those scenarios. Copying a file is pure I/O. If the source and destination file are on the same phsyical disk or controller, adding threads only adds overhead with no real possibility to do more work per unit time.
If your source and destination are on different disks or controllers, then it's possible that you could get some benefit from multithreading. While one thread is waiting for bytes to be written to the target disk, the other thread can be reading from the source disk.

Jdbc takes more time then sqlplus

Similar Messages

Maybe you are looking for