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

Similar Messages

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

Publishing EJBs takes more time in Oracle Weblogic 10.3 workshop

Hi,
We recently migrated from Weblogic 9.2 to Oracle Weblogic 10.3 workshop.
I have a ejb project which has more than 30 ejb's(both entity and session ejbs).
The problem is: whenever I modify the code inside a method and save, it builds the project automatically. After that when I try to publish the module, it takes around 5 - 10 minutes for publishing.
Points to note are : The ejb I am modifying has reference to other (10 - 20) ejbs. Hence it takes more time for even for single ejb change.
however, when i modify an ejb which has no reference to ejb, takes less time to publish.
My question is : is there a way to reduce the publishing time in this scenario.
Thanks in advance!

There is a special forum for Workshop issues:
Workshop
Try there.

NFC tags read/write operations on low level

Hi,
I know this is little bit offtopic question - but since you are experts in the area I will try to ask you probably a pretty simple question:
1/ I would like to know which protocol is used for the read/write operations to the NFC tags are used. According to my understanding after the tag is placed on the NFC reader (NFC phone, USB reader), it is powered and set to the ready state. Then the application protocol for read/write operation is used. As I think the exact format and the content of commands used for read/write is not specified in ISO 14443 and it is dependent on a tag hardware/manufacturer and will be different for FeliCa/Mifare/Innovision/etc. tags, so there is no way how to handle NFC tags read/write operations with the single implementation. Is that assumption correct?
2/ Are there any tags, which supports the APDU 7816-4 commands for read/write operations?
Thank you for reply
Kind regards,
STeN

hello,
you have to read the NFC forum specs. all of this will be better explained than by me.
more than one protocol are used according the the contactless front end configuration and abilities. It includes ISO14443-A, ISO14443-B and Felica. Sometimes other protocols are also available, for example Innovatron (not Innovision lol)
Mifare is not a protocol, it is a line of NXP products. These products use the lower layers of the ISO14443-A protocol specification.
There are 4 types of tags
1) using the lower layers of ISO14443-A
2) using the lower layers of ISO14443-B
3) something related to felica?
not sure exactly about these 3, you have to read the specs. Everything is clearly understandable, not like ETSI.
4) something using ISO7816-4 commands on top of ISO14443 A or B or others. You have SELECT, READ BINARY, UPDATE BINARY. You can implement that using javacard, I did it and it works. You need two binary files, that can be hardcoded.
Regards
Sebastien

Automatic DOP take more time to execute query

We upgraded database to oracle 11gR2. While testing Automatic DOP feature with our existing query it takes more time than with parallel.
Note: No constrains or Index created on table to gain performance while loading data (5000records / sec)
Os : Sun Solaris 64bit
CPU = 8
RAM = 7456M
Default parameter settings:
parallel_degree_policy               string      MANUAL
parallel_degree_limit                string      CPU
parallel_threads_per_cpu             integer     2
arallel_degree_limit                 string      CPU
cpu_count                            integer     8
parallel_threads_per_cpu             integer     2
resource_manager_cpu_allocation      integer     8
Query:
SELECT COUNT(*)
from (
SELECT
/*+ FIRST_ROWS(50), PARALLEL */
Query gets executed in 22minutes : execution plan
COUNT(*)
      9600
Elapsed: 00:22:10.71
Execution Plan
Plan hash value: 3765539975
| Id | Operation           | Name             | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT    |                  |     1 |    21 | 2164K (1)| 07:12:52 |       |   |
|   1 | SORT AGGREGATE     |                  |     1 |    21 |            |          |       |   |
|   2 |   PARTITION RANGE OR|                  | 89030 | 1825K| 2164K (1)| 07:12:52 |KEY(OR)|KEY(OR)|
|* 3 |    TABLE ACCESS FULL| SUBSCRIBER_EVENT | 89030 | 1825K| 2164K (1)| 07:12:52 |KEY(OR)|KEY(OR)|Automatic DOP Query: parameters set
alter session set PARALLEL_DEGREE_POLICY = limited;
alter session force parallel query ;Query:
SELECT COUNT(*)
from (
SELECT /*+ FIRST_ROWS(50), PARALLEL*/
This query takes more than 2hrs to execute
COUNT(*)
      9600
Elapsed: 02:07:48.81
Execution Plan
Plan hash value: 127536830
| Id | Operation              | Name             | Rows | Bytes | Cost (%CPU)| Time     | Pstart|Pstop |    TQ   |IN-OUT| PQ Distrib |
|   0 | SELECT STATEMENT       |                  |     1 |    21 |   150K (1)| 00:30:01 |       |      |         |      |            |
|   1 | SORT AGGREGATE        |                  |     1 |    21 |            |          |       |      |         |      |            |
|   2 |   PX COORDINATOR       |                  |       |       |            |          |       |      |         |      |            |
|   3 |    PX SEND QC (RANDOM) | :TQ10000         |     1 |    21 |            |          |       |      | Q1,00 | P->S | QC (RAND) |
|   4 |     SORT AGGREGATE     |                  |     1 |    21 |            |          |       |      | Q1,00 | PCWP |            |
|   5 |      PX BLOCK ITERATOR |                  | 89030 | 1825K|   150K (1)| 00:30:01 |KEY(OR)|KEY(OR)| Q1,00 | PCWC |            |
|* 6 |       TABLE ACCESS FULL| SUBSCRIBER_EVENT | 89030 | 1825K|   150K (1)| 00:30:01 |KEY(OR)|KEY(OR)| Q1,00 | PCWP |            |
Note
- automatic DOP: Computed Degree of Parallelism is 16 because of degree limitcan some one help us to find out where we did wrong or any pointer will really helpful to resolve an issue.
Edited by: Sachin B on May 11, 2010 4:05 AM

Generated AWR report for ADOP
Foreground Wait Events                       DB/Inst: HDB/hdb Snaps: 158-161
-> s - second, ms - millisecond -    1000th of a second
-> Only events with Total Wait Time (s) >= .001 are shown
-> ordered by wait time desc, waits desc (idle events last)
-> %Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0
                                                             Avg
                                        %Time Total Wait    wait    Waits   % DB
Event                             Waits -outs   Time (s)    (ms)     /txn   time
direct path read                522,173     0    125,051     239    628.4   99.3
db file sequential read             663     0        156     235      0.8     .1
log file sync                       165     0        117     712      0.2     .1
Disk file operations I/O            267     0         63     236      0.3     .1
db file scattered read              251     0         36     145      0.3     .0
control file sequential re          217     0         32     149      0.3     .0
library cache load lock               2     0         10    4797      0.0     .0
cursor: pin S wait on X               3     0          9    3149      0.0     .0
read by other session                 5     0          2     429      0.0     .0
kfk: async disk IO              613,170     0          2       0    737.9     .0
sort segment request                  1   100          1    1007      0.0     .0
os thread startup                    16     0          1      43      0.0     .0
direct path write temp                1     0          1     527      0.0     .0
latch free                           51     0          0       2      0.1     .0
kksfbc child completion               1   100          0      59      0.0     .0
latch: cache buffers chain           19     0          0       2      0.0     .0
latch: shared pool                   36     0          0       1      0.0     .0
PX Deq: Slave Session Stat           21     0          0       1      0.0     .0
library cache: mutex X               45     0          0       1      0.1     .0
CSS initialization                    2     0          0       6      0.0     .0
enq: KO - fast object chec            1     0          0      11      0.0     .0
buffer busy waits                     3     0          0       1      0.0     .0
cursor: pin S                         9     0          0       0      0.0     .0
CSS operation: action                 2     0          0       1      0.0     .0
direct path write                     1     0          0       2      0.0     .0
jobq slave wait                  17,554   100      8,942     509     21.1
PX Deq: Execute Reply             4,060    95      7,870    1938      4.9
SQL*Net message from clien           96     0      5,756   59962      0.1
PX Deq: Execution Msg               618    56        712    1152      0.7
KSV master wait                      11     0          0       2      0.0
PX Deq: Join ACK                     16     0          0       1      0.0
PX Deq: Parse Reply                  14     0          0       1      0.0
Background Wait Events                       DB/Inst: HDB/hdb Snaps: 158-161
-> ordered by wait time desc, waits desc (idle events last)
-> Only events with Total Wait Time (s) >= .001 are shown
-> %Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0
                                                             Avg
                                        %Time Total Wait    wait    Waits   % bg
Event                             Waits -outs   Time (s)    (ms)     /txn   time
control file sequential re        6,249     0      2,375     380      7.5   55.6
control file parallel writ        2,003     0        744     371      2.4   17.4
db file parallel write            1,604     0        503     313      1.9   11.8
log file parallel write             861     0        320     371      1.0    7.5
db file sequential read             363     0        151     415      0.4    3.5
db file scattered read              152     0         64     421      0.2    1.5
Disk file operations I/O            276     0         21      77      0.3     .5
os thread startup                   316     0         15      48      0.4     .4
ADR block file read                  24     0         11     450      0.0     .3
rdbms ipc reply                      17    12          7     403      0.0     .2
Data file init write                  6     0          6    1016      0.0     .1
direct path write                    21     0          6     287      0.0     .1
log file sync                         7     0          6     796      0.0     .1
ADR block file write                 10     0          4     414      0.0     .1
enq: JS - queue lock                  1     0          3    2535      0.0     .1
ASM file metadata operatio        1,801     0          2       1      2.2     .0
db file parallel read                30     0          1      40      0.0     .0
kfk: async disk IO                  955     0          1       1      1.1     .0
db file single write                  1     0          0     415      0.0     .0
reliable message                     10     0          0      23      0.0     .0
latch: shared pool                   75     0          0       2      0.1     .0
latch: call allocation               26     0          0       2      0.0     .0
CSS initialization                    7     0          0       6      0.0     .0
asynch descriptor resize            352   100          0       0      0.4     .0
undo segment extension                2   100          0       5      0.0     .0
CSS operation: action                 9     0          0       1      0.0     .0
CSS operation: query                 42     0          0       0      0.1     .0
latch: parallel query allo            4     0          0       0      0.0     .0
rdbms ipc message                37,948    97    104,599    2756     45.7
DIAG idle wait                   16,762   100     16,927    1010     20.2
ASM background timer              1,724     0      8,467    4912      2.1
shared server idle wait             282   100      8,465   30019      0.3
pmon timer                        3,123    90      8,465    2711      3.8
wait for unread message on        8,381   100      8,465    1010     10.1
dispatcher timer                    141   100      8,463   60019      0.2
Streams AQ: qmn coordinato          604    50      8,462   14010      0.7
Streams AQ: qmn slave idle          304     0      8,462   27836      0.4
smon timer                           35    71      8,382 239496      0.0
Space Manager: slave idle         1,621    99      8,083    4986      2.0
PX Idle Wait                      2,392    99      4,739    1981      2.9
class slave wait                     46     0        623   13546      0.1
KSV master wait                       2     0          0      27      0.0
SQL*Net message from clien            7     0          0       1      0.0
Wait Event Histogram                         DB/Inst: HDB/hdb Snaps: 158-161
-> Units for Total Waits column: K is 1000, M is 1000000, G is 1000000000
-> % of Waits: value of .0 indicates value was <.05%; value of null is truly 0
-> % of Waits: column heading of <=1s is truly <1024ms, >1s is truly >=1024ms
-> Ordered by Event (idle events last)
                                                    % of Waits
                           Total
Event                      Waits <1ms <2ms <4ms <8ms <16ms <32ms <=1s   >1s
ADR block file read           24                                     100.0
ADR block file write          10                                     100.0
ADR file lock                 12 100.0
ASM file metadata operatio 1812 99.0    .3    .4                      .2    .1
CSS initialization             9                   100.0
CSS operation: action         11 90.9   9.1
CSS operation: query          54 100.0
Data file init write           6        16.7 16.7                    16.7 50.0
Disk file operations I/O     533 88.7   2.6    .6               1.5    .2   6.4
PX Deq: Signal ACK EXT         4 100.0
PX Deq: Signal ACK RSG         2 100.0
PX Deq: Slave Session Stat    21 42.9 28.6 28.6
SQL*Net break/reset to cli     6 100.0
SQL*Net message to client    102 100.0
SQL*Net more data to clien     4 100.0
asynch descriptor resize     527 100.0
buffer busy waits              4 75.0        25.0
control file parallel writ 2003   9.3    .5          .0    .1        90.0
control file sequential re 6466 10.6    .0    .0    .0    .1    .2 89.0
cursor: pin S                  9 100.0
cursor: pin S wait on X        3                          33.3 33.3        33.3
db file parallel read         30                           6.7 30.0 63.3
db file parallel write      1604   7.4    .1                .6 16.5 75.5
db file scattered read       403   3.7    .2   2.5 13.6 14.9   3.5 61.5
db file sequential read     1017 12.3    .8   2.3   7.3   6.6   2.0 68.8
db file single write           1                                     100.0
direct path read           522.2   2.2   2.1    .1    .0   1.8 17.9 75.9
direct path write             22         4.5                     4.5 90.9
direct path write temp         1                                     100.0
enq: JS - queue lock           1                                           100.0
enq: KO - fast object chec     1                         100.0
enq: PS - contention           1 100.0
kfk: async disk IO         614.1 100.0                                  .0
kksfbc child completion        1                                     100.0
latch free                    58 46.6 27.6 15.5 10.3
latch: cache buffers chain    19 36.8 10.5 52.6
latch: call allocation        26 76.9 11.5         7.7         3.8
latch: parallel query allo     4 100.0
latch: shared pool           111 44.1 28.8 27.0
library cache load lock        2                                           100.0
library cache: mutex X        45 84.4   8.9   4.4   2.2
log file parallel write      861 10.0          .1    .1              89.5    .2
log file sync                172   6.4                                90.1   3.5
os thread startup            332                                     100.0
rdbms ipc reply               18 72.2                                11.1 16.7
read by other session          5                                     100.0
reliable message              11 81.8   9.1                           9.1
sort segment request           1                                     100.0
undo segment extension         2 50.0                    50.0
ASM background timer        1724    .8    .6    .1                      .6 97.9
DIAG idle wait             16.8K                                     100.0
KSV master wait               13   7.7 23.1 61.5                     7.7
PX Deq: Execute Reply       4060    .4          .0    .0          .1   3.4 96.0
PX Deq: Execution Msg        617 34.7   1.5   2.4   1.5   1.5    .2    .8 57.5
PX Deq: Join ACK              16 93.8                     6.3
PX Deq: Parse Reply           14 71.4   7.1 14.3   7.1
PX Idle Wait                2384    .0                                  .6 99.3
SQL*Net message from clien   103 82.5         1.0   1.9               1.0 13.6
Space Manager: slave idle   1621                                        .2 99.8
Streams AQ: qmn coordinato   604 50.0                                      50.0
Wait Event Histogram                         DB/Inst: HDB/hdb Snaps: 158-161
-> Units for Total Waits column: K is 1000, M is 1000000, G is 1000000000
-> % of Waits: value of .0 indicates value was <.05%; value of null is truly 0
-> % of Waits: column heading of <=1s is truly <1024ms, >1s is truly >=1024ms
-> Ordered by Event (idle events last)Edited by: Sachin B on May 11, 2010 4:52 AM

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.

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

Optimizing the query - which takes more time

Hi,
Am having a query which was returning the results pretty fast one week back but now the same query takes more time to respond, nothing much changed in the table data, what could be the problem. Am using IN in the where clause, whether that could be an issue? if so what is the best method of rewriting the query.
SELECT RI.RESOURCE_NAME,TR.MSISDN,MAX(TR.ADDRESS1_GOOGLE) KEEP(DENSE_RANK LAST ORDER BY TR.MSG_DATE_INFO) ADDRESS1_GOOGLE,
                MAX(TR.TIME_STAMP) MSG_DATE_INFO FROM TRACKING_REPORT TR, RESOURCE_INFO RI
                WHERE TR.MSISDN IN ( SELECT MSISDN FROM RESOURCE_INFO WHERE GROUP_ID ='4'
               AND COM_ID='12') AND RI.MSISDN = TR.MSISDN
               GROUP BY RI.RESOURCE_NAME,TR.MSISDN ORDER BY MSG_DATE_INFO DESC

Hi
i have followed this link http://www.lorentzcenter.nl/awcourse/oracle/server.920/a96533/sqltrace.htm in enabling the trace and found out the following trace output, can you explain the problem here and its remedial action pls.
SELECT RI.RESOURCE_NAME,TR.MSISDN,MAX(TR.ADDRESS1_GOOGLE) KEEP(DENSE_RANK
LAST ORDER BY TR.MSG_DATE_INFO) ADDRESS1_GOOGLE,                      MAX(TR.TIME_STAMP)
MSG_DATE_INFO
FROM
TRACKING_REPORT TR, RESOURCE_INFO RI                          WHERE RI.GROUP_ID ='426'                         AND
RI.COM_ID='122' AND RI.MSISDN = TR.MSISDN                      GROUP BY RI.RESOURCE_NAME,
TR.MSISDN
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.01       0.02          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        6     13.69     389.03      81747     280722          0          72
total        8     13.70     389.05      81747     280722          0          72
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 281
Rows     Row Source Operation
     72 SORT GROUP BY
276558   NESTED LOOPS
     79    TABLE ACCESS FULL RESOURCE_INFO
276558    TABLE ACCESS BY INDEX ROWID TRACKING_REPORT
276558     INDEX RANGE SCAN TR_INDX_ON_MSISDN_TIME (object id 60507)
********************************************************************************and the plan_table output is
STATEMENT_ID     TIMESTAMP     REMARKS     OPERATION     OPTIONS     OBJECT_NODE     OBJECT_OWNER     OBJECT_NAME     OBJECT_INSTANCE     OBJECT_TYPE     OPTIMIZER     SEARCH_COLUMNS     ID     PARENT_ID     POSITION     COST     CARDINALITY     BYTES     OTHER_TAG     PARTITION_START     PARTITION_STOP     PARTITION_ID     OTHER     DISTRIBUTION     CPU_COST     IO_COST     TEMP_SPACE     ACCESS_PREDICATES     FILTER_PREDICATES
     23-Mar-11 23:36:45          SELECT STATEMENT                                   CHOOSE          0          115     115     1058     111090                                        115
     23-Mar-11 23:36:45          SORT     GROUP BY                                        1     0     1     115     1058     111090                                        115
     23-Mar-11 23:36:45          NESTED LOOPS                                             2     1     1     9     4603     483315                                        9
     23-Mar-11 23:36:45          TABLE ACCESS     FULL          BSNL_RTMS     RESOURCE_INFO     2          ANALYZED          3     2     1     8     1     30                                        8               "RI"."GROUP_ID"=426 AND "RI"."COM_ID"='122'
     23-Mar-11 23:36:45          TABLE ACCESS     BY INDEX ROWID          BSNL_RTMS     TRACKING_REPORT     1          ANALYZED          4     2     2     1     3293     246975                                        1
     23-Mar-11 23:36:45          INDEX     RANGE SCAN          BSNL_RTMS     TR_INDX_ON_MSISDN_TIME          NON-UNIQUE          1     5     4     1     1     3293                                             1          "RI"."MSISDN"="TR"."MSISDN"

Zfs destroy command takes more time than usual

Hi,
When I run the destroy command it takes more than usual.
I have exported the lun form this zfs volume ealier.
Later I have removed the lun view and deleted the lun.After that when I run the below command it takes more time (more than 5mins and still running)
#zfs destroy storage/lu

Is there a way to quickly destroy the filesystem.
It looks it removing the allocated files.
              capacity     operations    bandwidth
pool        alloc   free   read write   read write
storage0     107G   116T 3.32K 2.52K 3.48M 37.7M
storage0     107G   116T    840    551 1.80M 6.01M
storage0     106G   116T    273      0   586K      0
storage0     106G   116T 1.19K      0 2.61M      0
storage0     106G   116T 1.47K      0 3.20M

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

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

Count (*) for select stmt take more time than execute a that sql stmt

HI
count (*) for select stmt take more time than execute a that sql stmt
executing particular select stmt take 2.47 mins but select stmt is using the /*+parallel*/ (sql optimer) in that sql command for faster execute .
but if i tried to find out total number of rows in that query it takes more time ..
almost 2.30 hrs still running to find count(col)
please help me to get count of row faster.
thanks in advance...

797525 wrote:
HI
count (*) for select stmt take more time than execute a that sql stmt
executing particular select stmt take 2.47 mins but select stmt is using the /*+parallel*/ (sql optimer) in that sql command for faster execute .
but if i tried to find out total number of rows in that query it takes more time ..
almost 2.30 hrs still running to find count(col)
please help me to get count of row faster.
thanks in advance...That may be because your client is displaying only the first few records when you are running the "SELECT *". But when you run "COUNT(*)", the whole records has to be counted.
As already mentined please read teh FAQ to post tuning questions.

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

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.

Reports take more time

hello experts,
i am using report builder(10g).i am working on a report.the report is ok but it takes more time to run.
.i already created indexing in columns but yet not its sufficient to improve the performance
so pls help me to improve the performance of my report.
Thanks And Regards]
Ravi

964900 wrote:
hello experts,
i am using report builder(10g).i am working on a report.the report is ok but it takes more time to run.
.i already created indexing in columns but yet not its sufficient to improve the performance
so pls help me to improve the performance of my report.
Hi Ravi
NO one can help you without giving idea.
first idea you already done.
secondly test your query with explain plan. How to run ?
explain plan for <your query>;
select * from table(dbms_xplan.display);more read SQL and PL/SQL FAQ
Lastly you can not get very good help from this forum. Better close it and post @ PL/SQL
Hope this helps
Hamid
Mark correct/helpful to help others to get right answer(s).*

Oracle coherence first read/write operation take more time

Similar Messages

Maybe you are looking for