Query Takes 43 seconds to retrieve 650 records

Hi,
We have Query which takes 43 seconds to retrieve 650 records.We are on 10.2.0.4 version.Kindly Suggest me any changes is required.
SELECT InstrumentID, MEGroupID, MessageSequence FROM TIBEX_msgseqbyinstrumentbymeid WHERE MEGroupID = 'ME1';
PLAN_TABLE_OUTPUT
Plan hash value: 1364023912
| Id | Operation                 | Name                        | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT          |                             |    25 | 1550 | 56585   (2)| 00:11:20 |
|   1 | HASH GROUP BY            |                             |    25 | 1550 | 56585   (2)| 00:11:20 |
|* 2 |   HASH JOIN               |                             | 3272 |   198K| 56584   (2)| 00:11:20 |
|* 3 |    TABLE ACCESS FULL      | TIBEX_INSTRUMENT            |   677 | 14894 |    18   (0)| 00:00:01 |
|   4 |    VIEW                   |                             | 5689 |   222K| 56565   (2)| 00:11:19 |
|   5 |     UNION-ALL             |                             |       |       |            |          |
|   6 |      HASH GROUP BY        |                             |   614 | 11052 | 4587   (2)| 00:00:56 |
|   7 |       TABLE ACCESS FULL   | TIBEX_QUOTE                 |   455K| 8008K| 4564   (1)| 00:00:55 |
|   8 |      HASH GROUP BY        |                             |   108 | 1944 | 50283   (2)| 00:10:04 |
|   9 |       TABLE ACCESS FULL   | TIBEX_ORDER                 | 4926K|    84M| 50001   (1)| 00:10:01 |
| 10 |      HASH GROUP BY        |                             |    52 |   936 |     8 (13)| 00:00:01 |
|* 11 |       TABLE ACCESS FULL   | TIBEX_EXECUTION             |   307 | 5526 |     7   (0)| 00:00:01 |
| 12 |      HASH GROUP BY        |                             |     1 |    40 |     3 (34)| 00:00:01 |
|* 13 |       TABLE ACCESS FULL   | TIBEX_TSTRADE               |     1 |    40 |     2   (0)| 00:00:01 |
| 14 |      HASH GROUP BY        |                             |   396 | 7128 |    13   (8)| 00:00:01 |
| 15 |       INDEX FAST FULL SCAN| IX_BESTEXREL                | 3310 | 59580 |    12   (0)| 00:00:01 |
| 16 |      HASH GROUP BY        |                             | 1125 | 20250 |    12   (9)| 00:00:01 |
|* 17 |       TABLE ACCESS FULL   | TIBEX_MERESUMEPRDTRANSITION | 1981 | 35658 |    11   (0)| 00:00:01 |
| 18 |      HASH GROUP BY        |                             |     1 |    17 |     4 (25)| 00:00:01 |
| 19 |       TABLE ACCESS FULL   | TIBEX_EDPUPDATEREJECT       |    10 |   170 |     3   (0)| 00:00:01 |
| 20 |      HASH GROUP BY        |                             | 1126 | 32654 |   822   (1)| 00:00:10 |
| 21 |       NESTED LOOPS        |                             | 8640 |   244K|   821   (1)| 00:00:10 |
| 22 |        TABLE ACCESS FULL | TIBEX_INSTRUMENTADMIN       | 17280 |   421K|   820   (1)| 00:00:10 |
|* 23 |        INDEX UNIQUE SCAN | XPKTIBEX_CONFIGMEGROUP      |     1 |     4 |     0   (0)| 00:00:01 |
| 24 |      HASH GROUP BY        |                             |    17 |   306 |    70   (3)| 00:00:01 |
| 25 |       TABLE ACCESS FULL   | TIBEX_BESTEXECPRICELOG      | 12671 |   222K|    68   (0)| 00:00:01 |
| 26 |      HASH GROUP BY        |                             |     1 |    40 |     3 (34)| 00:00:01 |
|* 27 |       TABLE ACCESS FULL   | TIBEX_AUCTIONPRICE          |     1 |    40 |     2   (0)| 00:00:01 |
| 28 |      HASH GROUP BY        |                             | 1126 | 19142 |   618   (1)| 00:00:08 |
|* 29 |       TABLE ACCESS FULL   | TIBEX_ADMINACK              | 18121 |   300K|   616   (1)| 00:00:08 |
| 30 |      HASH GROUP BY        |                             | 1122 | 20196 |   142   (2)| 00:00:02 |
| 31 |       INDEX FAST FULL SCAN| INSTRUMENTSTATEMSGSEQ       | 23588 |   414K|   140   (0)| 00:00:02 |
Predicate Information (identified by operation id):
   2 - access("INSTRUMENTID"="B"."INSTRUMENTID")
   3 - filter("B"."MEGROUPID"='ME1')
11 - filter("INSTRUMENTID" IS NOT NULL)
13 - filter("INSTRUMENTID" IS NOT NULL)
17 - filter("INSTRUMENTID" IS NOT NULL)
23 - access("ADMINUSER"="MEGROUPID")
27 - filter("INSTRUMENTID" IS NOT NULL)
29 - filter("INSTRUMENTID" IS NOT NULL)
50 rows selected.
654 rows selected.
Elapsed: 00:00:43.67
CREATE OR REPLACE VIEW TIBEX_MSGSEQBYINSTRUMENTBYMEID
(INSTRUMENTID, MESSAGESEQUENCE, MEGROUPID)
AS
SELECT a.*, b.megroupid
    FROM TIBEX_MSGSEQBYINSTRUMENT a
    JOIN tibex_instrument b
      ON a.instrumentid=b.instrumentid
CREATE OR REPLACE VIEW TIBEX_MSGSEQBYINSTRUMENT
(INSTRUMENTID, MESSAGESEQUENCE)
AS
SELECT instrumentID, NVL(max(MessageSequence),0) as MessageSequence
    FROM (SELECT instrumentID, max(MessageSequence) as MessageSequence
            FROM tibex_quote
            WHERE instrumentID IS NOT NULL
            GROUP BY instrumentID
          UNION ALL
          SELECT instrumentID, max(MessageSequence)
            FROM tibex_order
            WHERE instrumentID IS NOT NULL
            GROUP BY instrumentID
          UNION ALL
          SELECT instrumentID, max(MessageSequence)
            FROM tibex_execution
            WHERE instrumentID IS NOT NULL
            GROUP BY instrumentID
          UNION ALL
          SELECT instrumentID, max(MessageSequence)
            FROM tibex_TsTrade
            WHERE instrumentID IS NOT NULL
            GROUP BY instrumentID
          UNION ALL
          SELECT instrumentID, max(MessageSequence)
            FROM tibex_BestExRel
            WHERE instrumentID IS NOT NULL
            GROUP BY instrumentID
          UNION ALL
          SELECT instrumentID, max(MessageSequence)
            FROM tibex_MeResumePrdTransition
            WHERE instrumentID IS NOT NULL
            GROUP BY instrumentID
          UNION ALL
          SELECT instrumentID, max(MessageSequence)
            FROM tibex_EDPUpdateReject
            WHERE instrumentID IS NOT NULL
              GROUP BY instrumentID
          UNION ALL
          SELECT instrumentID, max(MessageSequence)
            FROM tibex_INSTRUMENTADMIN
            WHERE instrumentID IS NOT NULL
              AND adminuser IN (
                    SELECT megroupID
                      FROM tibex_configMeGroup
            GROUP by instrumentID
          UNION ALL
          SELECT instrumentID, max(MessageSequence)
            FROM tibex_BestExecPriceLog
            WHERE instrumentID IS NOT NULL
            GROUP BY instrumentID
          UNION ALL
          SELECT instrumentID, max(MessageSequence)
            FROM tibex_auctionPrice
            WHERE instrumentID IS NOT NULL
            GROUP BY instrumentID
          UNION ALL
          SELECT instrumentID, max(AckMessageSequence)
            FROM tibex_adminAck
            WHERE instrumentID IS NOT NULL
            GROUP BY instrumentID
          UNION ALL
          SELECT instrumentID, max(MessageSequence)
            FROM tibex_InstrumentState
            WHERE instrumentID IS NOT NULL
            GROUP BY instrumentID
    GROUP BY instrumentID
/Regards
Narasimha

Hi,
I dropped and recreated the stats without any modification(Eg adding new Indexes).The Query is hitting the indexes and it comes out in 00:00:16.86.But in the Production box the Same Query is doing Full tablescan.
The only difference in producation and Test Env is I collected the Fresh stats but in prod Kindly read below and give me suggestion
The Process Happens
In the Beginning of the Day Following tables contains Like 100 records and as the day process it will reach 1,2,3,4 millions records by the EOD.During the EOD day we generate stats and delete those records and Tables will have 100 or 200 records but the stats will be for 4 Million records.Kindly Suggest me the best option
tst_pre_eod@MIFEX3> set timing on
tst_pre_eod@MIFEX3> show parameter user_dump_dest
NAME                                 TYPE        VALUE
user_dump_dest                       string      /u01/app/oracle/admin/MIFEX3/u
                                                 dump
tst_pre_eod@MIFEX3>
tst_pre_eod@MIFEX3> show parameter optimizer
NAME                                 TYPE        VALUE
optimizer_dynamic_sampling           integer     2
optimizer_features_enable            string      10.2.0.4
optimizer_index_caching              integer     0
optimizer_index_cost_adj             integer     100
optimizer_mode                       string      ALL_ROWS
optimizer_secure_view_merging        boolean     TRUE
tst_pre_eod@MIFEX3>
tst_pre_eod@MIFEX3> show parameter db_file_multi
NAME                                 TYPE        VALUE
db_file_multiblock_read_count        integer     128
tst_pre_eod@MIFEX3>
tst_pre_eod@MIFEX3> show parameter db_block_size
NAME                                 TYPE        VALUE
db_block_size                        integer     8192
tst_pre_eod@MIFEX3>
tst_pre_eod@MIFEX3> show parameter cursor_sharing
NAME                                 TYPE        VALUE
cursor_sharing                       string      EXACT
tst_pre_eod@MIFEX3>
tst_pre_eod@MIFEX3> column sname format a20
tst_pre_eod@MIFEX3> column pname format a20
tst_pre_eod@MIFEX3> column pval2 format a20
tst_pre_eod@MIFEX3>
tst_pre_eod@MIFEX3> select
2 sname
3 , pname
4 , pval1
5 , pval2
6 from
7 sys.aux_stats$;
SNAME                PNAME                     PVAL1 PVAL2
SYSSTATS_INFO        STATUS                          COMPLETED
SYSSTATS_INFO        DSTART                          01-11-2010 17:16
SYSSTATS_INFO        DSTOP                           01-11-2010 17:16
SYSSTATS_INFO        FLAGS                         1
SYSSTATS_MAIN        CPUSPEEDNW           1489.10722
SYSSTATS_MAIN        IOSEEKTIM                    10
SYSSTATS_MAIN        IOTFRSPEED                 4096
SYSSTATS_MAIN        SREADTIM                    .71
SYSSTATS_MAIN        MREADTIM                 15.027
SYSSTATS_MAIN        CPUSPEED                   2141
SYSSTATS_MAIN        MBRC                         29
SYSSTATS_MAIN        MAXTHR
SYSSTATS_MAIN        SLAVETHR
13 rows selected.
Elapsed: 00:00:00.07
tst_pre_eod@MIFEX3> set timing on
tst_pre_eod@MIFEX3> explain plan for
2
tst_pre_eod@MIFEX3> SELECT InstrumentID, MEGroupID, MessageSequence FROM
2           TIBEX_msgseqbyinstrumentbymeid WHERE MEGroupID = 'ME1';
GLJd                                               ME1             2.9983E+18
TALKl                                              ME1             2.9983E+18
ENGl                                               ME1             2.9983E+18
AGRl                                               ME1             2.9983E+18
HHFAd                                              ME1             2.9983E+18
GWI1d                                              ME1             2.9983E+18
BIO3d                                              ME1             2.9983E+18
603 rows selected.
Elapsed: 00:00:16.72
tst_pre_eod@MIFEX3> SELECT InstrumentID, MEGroupID, MessageSequence FROM
2           TIBEX_msgseqbyinstrumentbymeid WHERE MEGroupID = 'ME1';
603 rows selected.
Elapsed: 00:00:16.86
Execution Plan
Plan hash value: 2206731661
| Id | Operation                   | Name                        | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |                             |    13 |   806 |   111K (5)| 00:01:20 |
|   1 | HASH GROUP BY              |                             |    13 |   806 |   111K (5)| 00:01:20 |
|* 2 |   HASH JOIN                 |                             | 3072 |   186K|   111K (5)| 00:01:20 |
|* 3 |    TABLE ACCESS FULL        | TIBEX_INSTRUMENT            |   626 | 13772 |    28   (0)| 00:00:01 |
|   4 |    VIEW                     |                             | 5776 |   225K|   111K (5)| 00:01:20 |
|   5 |     UNION-ALL               |                             |       |       |            |          |
|   6 |      HASH GROUP BY          |                             |   782 | 14076 | 10056   (5)| 00:00:08 |
|   7 |       TABLE ACCESS FULL     | TIBEX_QUOTE                 |   356K| 6260K| 9860   (3)| 00:00:08 |
|   8 |      HASH GROUP BY          |                             |   128 | 2304 |   101K (5)| 00:01:12 |
|   9 |       VIEW                  | index$_join$_007            | 3719K|    63M| 98846   (3)| 00:01:11 |
|* 10 |        HASH JOIN            |                             |       |       |            |          |
| 11 |         INDEX FAST FULL SCAN| IX_ORDERBOOK                | 3719K|    63M| 32019   (3)| 00:00:23 |
| 12 |         INDEX FAST FULL SCAN| TIBEX_ORDER_ID_ORD_INS      | 3719K|    63M| 24837   (3)| 00:00:18 |
| 13 |      HASH GROUP BY          |                             |    23 |   414 |     4 (25)| 00:00:01 |
| 14 |       VIEW                  | index$_join$_008            |   108 | 1944 |     3   (0)| 00:00:01 |
|* 15 |        HASH JOIN            |                             |       |       |            |          |
| 16 |         INDEX FAST FULL SCAN| TIBEX_EXECUTION_IDX1        |   108 | 1944 |     1   (0)| 00:00:01 |
|* 17 |         INDEX FAST FULL SCAN| TIBEX_EXECUTION_IDX4        |   108 | 1944 |     1   (0)| 00:00:01 |
| 18 |      HASH GROUP BY          |                             |     1 |    40 |     4 (25)| 00:00:01 |
|* 19 |       TABLE ACCESS FULL     | TIBEX_TSTRADE               |     1 |    40 |     3   (0)| 00:00:01 |
| 20 |      HASH GROUP BY          |                             |   394 | 7092 |    30 (10)| 00:00:01 |
| 21 |       INDEX FAST FULL SCAN | IX_BESTEXREL                | 4869 | 87642 |    28   (4)| 00:00:01 |
| 22 |      HASH GROUP BY          |                             | 1126 | 20268 |    19 (11)| 00:00:01 |
|* 23 |       TABLE ACCESS FULL     | TIBEX_MERESUMEPRDTRANSITION | 1947 | 35046 |    17   (0)| 00:00:01 |
| 24 |      HASH GROUP BY          |                             |     1 |    17 |     7 (15)| 00:00:01 |
| 25 |       TABLE ACCESS FULL     | TIBEX_EDPUPDATEREJECT       |     8 |   136 |     6   (0)| 00:00:01 |
| 26 |      HASH GROUP BY          |                             | 1099 | 31871 |   192   (6)| 00:00:01 |
|* 27 |       HASH JOIN             |                             | 6553 |   185K|   188   (4)| 00:00:01 |
| 28 |        INDEX FULL SCAN      | XPKTIBEX_CONFIGMEGROUP      |     4 |    16 |     1   (0)| 00:00:01 |
| 29 |        TABLE ACCESS FULL    | TIBEX_INSTRUMENTADMIN       | 14744 |   359K|   186   (4)| 00:00:01 |
| 30 |      HASH GROUP BY          |                             |    11 |   198 |    77   (7)| 00:00:01 |
| 31 |       TABLE ACCESS FULL     | TIBEX_BESTEXECPRICELOG      | 5534 | 99612 |    74   (3)| 00:00:01 |
| 32 |      HASH GROUP BY          |                             |     1 |    40 |     4 (25)| 00:00:01 |
|* 33 |       TABLE ACCESS FULL     | TIBEX_AUCTIONPRICE          |     1 |    40 |     3   (0)| 00:00:01 |
| 34 |      HASH GROUP BY          |                             | 1098 | 18666 |   193   (7)| 00:00:01 |
|* 35 |       TABLE ACCESS FULL     | TIBEX_ADMINACK              | 15836 |   262K|   185   (3)| 00:00:01 |
|* 35 |       TABLE ACCESS FULL     | TIBEX_ADMINACK              | 15836 |   262K|   185   (3)| 00:00:01 |
| 36 |      HASH GROUP BY          |                             | 1112 | 20016 |    76 (16)| 00:00:01 |
| 37 |       INDEX FAST FULL SCAN | INSTRUMENTSTATEMSGSEQ       | 20948 |   368K|    66   (4)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("INSTRUMENTID"="B"."INSTRUMENTID")
   3 - filter("B"."MEGROUPID"='ME1')
10 - access(ROWID=ROWID)
15 - access(ROWID=ROWID)
17 - filter("INSTRUMENTID" IS NOT NULL)
19 - filter("INSTRUMENTID" IS NOT NULL)
23 - filter("INSTRUMENTID" IS NOT NULL)
27 - access("ADMINUSER"="MEGROUPID")
33 - filter("INSTRUMENTID" IS NOT NULL)
35 - filter("INSTRUMENTID" IS NOT NULL)
Statistics
        175 recursive calls
          0 db block gets
      57737 consistent gets
      18915 physical reads
          0 redo size
      14908 bytes sent via SQL*Net to client
        558 bytes received via SQL*Net from client
          8 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
        603 rows processed
SELECT InstrumentID, MEGroupID, MessageSequence FROM
         TIBEX_msgseqbyinstrumentbymeid WHERE MEGroupID = 'ME1'
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.01       0.07          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        8     10.46      16.28      18915      57733          0         603
total       10     10.47      16.35      18915      57733          0         603
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 303
Rows     Row Source Operation
    603 HASH GROUP BY (cr=57733 pr=18915 pw=18900 time=16283336 us)
   2853   HASH JOIN (cr=57733 pr=18915 pw=18900 time=281784 us)
    626    TABLE ACCESS FULL TIBEX_INSTRUMENT (cr=38 pr=0 pw=0 time=120 us)
   5594    VIEW (cr=57695 pr=18915 pw=18900 time=278405 us)
   5594     UNION-ALL (cr=57695 pr=18915 pw=18900 time=278400 us)
    823      HASH GROUP BY (cr=12938 pr=0 pw=0 time=272798 us)
356197       TABLE ACCESS FULL TIBEX_QUOTE (cr=12938 pr=0 pw=0 time=41 us)
    136      HASH GROUP BY (cr=43989 pr=18915 pw=18900 time=15962878 us)
3718076       VIEW index$_join$_007 (cr=43989 pr=18915 pw=18900 time=13123768 us)
3718076        HASH JOIN (cr=43989 pr=18915 pw=18900 time=9405689 us)
3718076         INDEX FAST FULL SCAN IX_ORDERBOOK (cr=24586 pr=0 pw=0 time=65 us)(object id 387849)
3718076         INDEX FAST FULL SCAN TIBEX_ORDER_ID_ORD_INS (cr=19403 pr=0 pw=0 time=64 us)(object id 387867)
     23      HASH GROUP BY (cr=6 pr=0 pw=0 time=1265 us)
    108       VIEW index$_join$_008 (cr=6 pr=0 pw=0 time=1024 us)
    108        HASH JOIN (cr=6 pr=0 pw=0 time=914 us)
    108         INDEX FAST FULL SCAN TIBEX_EXECUTION_IDX1 (cr=3 pr=0 pw=0 time=155 us)(object id 386846)
    108         INDEX FAST FULL SCAN TIBEX_EXECUTION_IDX4 (cr=3 pr=0 pw=0 time=129 us)(object id 386845)
      0      HASH GROUP BY (cr=3 pr=0 pw=0 time=84 us)
      0       TABLE ACCESS FULL TIBEX_TSTRADE (cr=3 pr=0 pw=0 time=46 us)
    394      HASH GROUP BY (cr=39 pr=0 pw=0 time=2662 us)
   4869       INDEX FAST FULL SCAN IX_BESTEXREL (cr=39 pr=0 pw=0 time=22 us)(object id 386757)
   1126      HASH GROUP BY (cr=23 pr=0 pw=0 time=2338 us)
   1947       TABLE ACCESS FULL TIBEX_MERESUMEPRDTRANSITION (cr=23 pr=0 pw=0 time=29 us)
      1      HASH GROUP BY (cr=7 pr=0 pw=0 time=110 us)
      8       TABLE ACCESS FULL TIBEX_EDPUPDATEREJECT (cr=7 pr=0 pw=0 time=43 us)
    828      HASH GROUP BY (cr=249 pr=0 pw=0 time=6145 us)
    828       HASH JOIN (cr=249 pr=0 pw=0 time=1008 us)
      4        INDEX FULL SCAN XPKTIBEX_CONFIGMEGROUP (cr=1 pr=0 pw=0 time=21 us)(object id 386786)
14905        TABLE ACCESS FULL TIBEX_INSTRUMENTADMIN (cr=248 pr=0 pw=0 time=23 us)
     11      HASH GROUP BY (cr=99 pr=0 pw=0 time=3728 us)
   5556       TABLE ACCESS FULL TIBEX_BESTEXECPRICELOG (cr=99 pr=0 pw=0 time=32 us)
      0      HASH GROUP BY (cr=3 pr=0 pw=0 time=72 us)
      0       TABLE ACCESS FULL TIBEX_AUCTIONPRICE (cr=3 pr=0 pw=0 time=30 us)
   1126      HASH GROUP BY (cr=248 pr=0 pw=0 time=11102 us)
16069       TABLE ACCESS FULL TIBEX_ADMINACK (cr=248 pr=0 pw=0 time=18 us)
   1126      HASH GROUP BY (cr=91 pr=0 pw=0 time=11947 us)
21235       INDEX FAST FULL SCAN INSTRUMENTSTATEMSGSEQ (cr=91 pr=0 pw=0 time=38 us)(object id 386904)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                       8        0.00          0.00
direct path write temp                       1260        0.52          5.39
direct path read temp                        1261        0.04          2.95
SQL*Net message from client                     8        0.00          0.00
SQL*Net more data to client                     6        0.00          0.00
PARSE #8:c=15000,e=83259,p=0,cr=4,cu=0,mis=1,r=0,dep=0,og=1,tim=532014955506
EXEC #8:c=1000,e=170,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=532014955744
WAIT #8: nam='SQL*Net message to client' ela= 4 driver id=1413697536 #bytes=1 p3=0 obj#=572 tim=532014955794
WAIT #8: nam='direct path write temp' ela= 4090 file number=201 first dba=84873 block cnt=15 obj#=572 tim=532015639268
WAIT #8: nam='direct path write temp' ela= 2677 file number=201 first dba=84888 block cnt=15 obj#=572 tim=532015642558
WAIT #8: nam='direct path write temp' ela= 20 file number=201 first dba=84903 block cnt=15 obj#=572 tim=532015652372
WAIT #8: nam='direct path write temp' ela= 2190 file number=201 first dba=84918 block cnt=15 obj#=572 tim=532015656105
WAIT #8: nam='direct path write temp' ela= 2247 file number=201 first dba=84933 block cnt=15 obj#=572 tim=532015659146
WAIT #8: nam='direct path write temp' ela= 3386 file number=201 first dba=84948 block cnt=15 obj#=572 tim=532015662832
WAIT #8: nam='direct path write temp' ela= 3375 file number=201 first dba=84963 block cnt=15 obj#=572 tim=532015666444
WAIT #8: nam='direct path write temp' ela= 2796 file number=201 first dba=84978 block cnt=15 obj#=572 tim=532015670097
WAIT #8: nam='direct path write temp' ela= 2901 file number=201 first dba=53129 block cnt=15 obj#=572 tim=532015673308
WAIT #8: nam='direct path write temp' ela= 2933 file number=201 first dba=53144 block cnt=15 obj#=572 tim=532015676474
WAIT #8: nam='direct path write temp' ela= 15 file number=201 first dba=53159 block cnt=15 obj#=572 tim=532015686479
WAIT #8: nam='direct path write temp' ela= 2561 file number=201 first dba=53174 block cnt=15 obj#=572 tim=532015690084
WAIT #8: nam='direct path write temp' ela= 2297 file number=201 first dba=53189 block cnt=15 obj#=572 tim=532015693299
WAIT #8: nam='direct path write temp' ela= 3448 file number=201 first dba=53204 block cnt=15 obj#=572 tim=532015697026
WAIT #8: nam='direct path write temp' ela= 2633 file number=201 first dba=53219 block cnt=15 obj#=572 tim=532015700114
WAIT #8: nam='direct path write temp' ela= 2902 file number=201 first dba=53234 block cnt=15 obj#=572 tim=532015703743
WAIT #8: nam='direct path write temp' ela= 3219 file number=201 first dba=53001 block cnt=15 obj#=572 tim=532015707190
WAIT #8: nam='direct path write temp' ela= 2809 file number=201 first dba=53016 block cnt=15 obj#=572 tim=532015710215

Similar Messages

Simple query takes 18 minutes to retrieve data....

Hi,
I am facing this problem at the customer site where a simple query on a table takes 18 minutes or more. Please find below the details.
Table Structure
CREATE TABLE dsp_data
quantum_id NUMBER(11) NOT NULL,
src      NUMBER(11) NOT NULL,
call_status NUMBER(11) NOT NULL,
dst NUMBER(11) NOT NULL,
measurement_id NUMBER(11) NOT NULL,
is_originating NUMBER(1)     NOT NULL,
measurement_value NUMBER(15,4) NOT NULL,
data_type_id NUMBER(3) NOT NULL,
data VARCHAR2(200) NOT NULL
TABLESPACE dsp_data_tspace
STORAGE (PCTINCREASE 0 INITIAL 100K NEXT 1024K)
PARTITION BY RANGE (quantum_id)
(PARTITION dsp_data_default VALUES LESS THAN (100));
CREATE INDEX dsp_data_idx ON dsp_data
quantum_id,
src,
     call_status,
dst,
     measurement_id,
     is_originating,
measurement_value,
data_type_id
TABLESPACE dsp_data_idx_tspace
LOCAL;
CREATE INDEX dsp_data_src_idx ON dsp_data
src
TABLESPACE dsp_data_idx_tspace
LOCAL;
CREATE INDEX dsp_data_dst_idx ON dsp_data
dst
TABLESPACE dsp_data_idx_tspace
LOCAL;
ALTER TABLE dsp_data
ADD CONSTRAINT fk_dsp_data_1
FOREIGN KEY
quantum_id
REFERENCES mds_measurement_intervals
quantum_id
ALTER TABLE dsp_data
ADD CONSTRAINT fk_dsp_data_2
FOREIGN KEY
data_type_id
REFERENCES mds_drilldown_types
type_id
ALTER TABLE dsp_data
ADD CONSTRAINT pk_dsp_data
PRIMARY KEY
quantum_id,
src,
call_status,
dst,
          measurement_id,
          is_originating,
measurement_value,
data_type_id,
data
USING INDEX
TABLESPACE dsp_data_idx_tspace
LOCAL;
Table Space Creation
All table space creation is done using following command
CREATE TABLESPACE [tablespaceName]
DATAFILE [tablespaceDatafile] SIZE 500M REUSE
AUTOEXTEND ON NEXT 10240K
DEFAULT STORAGE ( INITIAL 1024K
NEXT 1024K
MINEXTENTS 10
MAXEXTENTS UNLIMITED
PCTINCREASE 0
Server Configuration on CUtsomer Site
(1)     2 x Dual PA8900 Proc = 4GHz
(2)     RAM = 16GB
(3)     3 x Internal HDDs
(4)     1 x External MSA-30 storage array (oracle db)
Record Information On Customer Site
select count(*) from dsp_data;
COUNT(*)
181931197
select min (quantum_id) from dsp_data where dst=2;
This takes 18 minutes or more....
SQL> SQL> SQL> explain plan for select min (quantum_id) from dsp_data where dst=2;
Explained.
SQL> @?/rdbms/admin/utlxpls
PLAN_TABLE_OUTPUT
Plan hash value: 999040277
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 14 | 1 (0)| 00:00:01 | | |
| 1 | SORT AGGREGATE | | 1 | 14 | | | | |
| 2 | FIRST ROW | | 92 | 1288 | 1 (0)| 00:00:01 | | |
| 3 | PARTITION RANGE ALL | | 92 | 1288 | 1 (0)| 00:00:01 | 1 | 29 |
|* 4 | INDEX FULL SCAN (MIN/MAX)| DSP_DATA_IDX | 92 | 1288 | 1 (0)| 00:00:01 | 1 | 29 |
As mentioned above the query takes 18 minutes or more. This is a critical issue at customer. Can you please give your suggestions how to improve and reduce the query time. Thanks in advance.

Hi,
I did the following changes in the indexes of table.
drop index DSP_DATA_IDX;
create index DSP_DATA_MEASUREMENT_ID_IDX on DSP_DATA (MEASUREMENT_ID) TABLESPACE dsp_data_idx_tspace LOCAL;
After that I did explain plan,
explain plan for select min(QUANTUM_ID) from mds.DSP_DATA where SRC=11;
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost (%CPU
| 0 | SELECT STATEMENT | | 1 | 11 | 3 (0
| 1 | SORT AGGREGATE | | 1 | 11 |
| 2 | FIRST ROW | | 430K| 4626K| 3 (0
| 3 | PARTITION RANGE ALL | | 430K| 4626K| 3 (0
| 4 | INDEX FULL SCAN (MIN/MAX)| PK_DSP_DATA | 430K| 4626K| 3 (0
Note
- 'PLAN_TABLE' is old version
14 rows selected
SELECT table_name, index_name, monitoring, used FROM v$object_usage;
TABLE_NAME INDEX_NAME MONITORING USED
DSP_DATA DSP_DATA_SRC_IDX YES NO
It seems that DSP_DATA_SRC_IDX is not getting used in query. What changes do i need to make so that DSP_DATA_SRC_IDX index gets used.
Also, you have stated that to create global index on src and dst. How do i create them.
Thanks in Advance.
Edited by: 780707 on Jul 8, 2010 11:58 PM

Zimbra login is very slow - SQL query takes 35+ seconds

Hi,
my Zimbra login process remains very slow, 35-40 seconds with only a single user using it. I have Beehive set up as directory synchronized, with about 6500 users in it. However, I and a couple of colleagues the only ones making any use of it for testing. With just one person logging in, the following SQL query takes about 35 seconds to execute:
SELECT /*+ LEADING(rf rf_pp) USE_NL(rf_pp) INDEX_ASC(@rf_connect_by rf@rf_connect_by (ws_real_folders.parent_eid ws_real_folders.eid)) */ RF.ENTERPRISE_ID AS
ENTERPRISE_ID, RF.SITE_ID AS SITE_ID, RF.ENTITY_TYPE AS ENTITY_TYPE, RF.EID AS EID, RF.LOCK_ID AS LOCK_ID, RF.CACHE_ID AS CACHE_ID, RF.CACHE_TS AS
CACHE_TS, RF.CACHE_SQ AS CACHE_SQ, FLOOR(RF.SECURE_CHECK/10) AS ACCESS_TYPES, RF.PARENT_ENTITY_TYPE AS PARENT_ENTITY_TYPE, RF.PARENT_EID AS
PARENT_EID, RF.NAME AS NAME, RF.OWNER_ENTITY_TYPE AS OWNER_ENTITY_TYPE, RF.OWNER_EID AS OWNER_EID, RF.CREATED_ON AS CREATED_ON,
RF.CREATOR_ENTITY_TYPE AS CREATOR_ENTITY_TYPE, RF.CREATOR_EID AS CREATOR_EID, RF.MODIFIEDON AS MODIFIED_ON, RF.MODIFIED_BY_ENTITY_TYPE AS
MODIFIED_BY_ENTITY_TYPE, RF.MODIFIED_BY_EID AS MODIFIED_BY_EID, RF.VISIBILITY AS VISIBILITY, CASE WHEN (BITAND(:B13 , :B12 ) = :B12 ) THEN CAST(MULTISET(
SELECT METADATA_CEN
FROM OCS_ENTITY_METADATA_CENS_2_V META
WHERE META.ENTITY_EID = RF.EID ) AS OCS_COLLAB_ID_TBL_T) ELSE CAST(NULL AS OCS_COLLAB_ID_TBL_T) END AS METADATA_CENS, CASE WHEN
RF_PP.LAST_ACCESSED IS NULL THEN 'N' WHEN RF.MODIFIEDON > RF_PP.LAST_ACCESSED THEN 'U' ELSE NVL(RF_PP.RELATIVE_STATUS, 'N') END AS CHANGE_STATUS,
RF.PROPERTIES AS PROPERTIES_CLOB, RF_PP.PROPERTIES AS VIEWERPROPERTIES_CLOB, RF.DESCRIPTION AS DESCRIPTION
FROM (
SELECT /*+ QB_NAME(rf_connect_by) no_connect_by_cost_based */ RF.ENTERPRISE_ID ENTERPRISE_ID, :B4 SITE_ID, :B3 ENTITY_TYPE, RF.EID EID, RF.LOCK_ID LOCK_ID,
RF.ORA_ROWSCN CACHE_ID, RF.CACHE_TS CACHE_TS, RF.CACHE_SQ CACHE_SQ, RF.PARENT_TYPE PARENT_ENTITY_TYPE, RF.PARENT_EID PARENT_EID, RF.NAME
NAME, RF.OWNER_TYPE OWNER_ENTITY_TYPE, RF.OWNER_EID OWNER_EID, RF.CREATED_ON CREATED_ON, RF.CREATOR_TYPE CREATOR_ENTITY_TYPE,
RF.CREATOR_EID CREATOR_EID, RF.MODIFIED_ON MODIFIEDON, RF.MODIFIED_BY_TYPE MODIFIED_BY_ENTITY_TYPE, RF.MODIFIED_BY_EID MODIFIED_BY_EID,
RF.VISIBILITY VISIBILITY, RF.PROPERTIES PROPERTIES, RF.DESCRIPTION DESCRIPTION, RF.IS_HIDDEN IS_HIDDEN, LEVEL LEVEL_NUM, COALESCE (
(SELECT :B10 * 10 + 1
FROM AC_ENTITIES AEI
WHERE RF.EID = AEI.EID AND ( 1 = DECODE(AEI.SENSITIVITY_EID, :B9 , 1, 0) AND 1 = DECODE(AEI.OWNER_EID, :B8 , 1, 0) AND 1 = DECODE(AEI.AT_READ, :B7 , 1, 0) AND 1 =
DECODE(AEI.AT_DISCOVER, :B6 , 1, 0) AND 1 = DECODE(AEI.LOCAL_ACL_ID, :B5 , 1, 0) ) ) ,
(SELECT ACV.ACCESS_TYPES * 10 + ACV.IS_ALLOWED
FROM AC_CHECK_ONE_OF_V ACV
WHERE ACV.EID = RF.EID ) ) SECURE_CHECK
FROM WS_REAL_FOLDERS RF
WHERE RF.IS_HIDDEN = :B2 START WITH RF.PARENT_EID = :B1 CONNECT BY PRIOR RF.EID = RF.PARENT_EID ) RF, WS_RF_PRVT_PROPERTIES RF_PP
WHERE RF.EID = RF_PP.EID (+) AND :B11 = RF_PP.VIEWER_EID (+) AND 1 = BITAND(RF.SECURE_CHECK, 1) ORDER BY RF.LEVEL_NUMIt has ID atrvjdrmz2v6d in Enterprise Manager, and I've tried tuning it with the SQL tuning advisor in EM. I did the statistics gathering mentioned in another thread yesterday, to see if that helped - doesn't seem liked it. I'm running Database 11.1.0.6 and Beehive 1.5.1 in the build from the day it released.
Any hints? I'll post this to MetaLink as well, unless someone has some immediate idea what's wrong :-)

No speedup, the 35-40 seconds is for normal logins - and it's very consistent, at least if the database is otherwise idle. Immediately logging out and back in gives me the same wait, and the same query shows up in the Enterprise Manager interface.
It seems it might be related to Workspaces - from EM:
"PL/SQL Source (Line Number) BEE_CODE.WS_REAL_FOLDER_PKG (2998)"

Re: cooL, it takes 14 seconds to insert 721 records to SQL Server 7.0

I'm always a little worried when someone is concerned about performance and then asks the question(s); how can I make this faster? or Is this normal?
There is no standard that can be applied to performance (although you may find limits and constraints published by vendors). I'm connected to a SUN 15000 with 16 processors 32 gigabytes of memory and several terabytes of storage spread across several hundred disk drives I'm guessing I could do inserts "faster" then what you are stating. But that doesn't really matter. What really matters is; how fast do you need the inserts to be? Answer that, and now you have a goal. Without that goal, performance tuning is a complete waste of time. So, what's your goal (and what are you willing to do about it)?
There are some general coding guidelines that can be used to make sure you are not hurting performance; things like using PreparedStatments, batching together inserts, using efficient string concatenation as described by a previous post, using multiple threads when inserting into multiple tables. There may be specific database procedures you can try, for instance, If you are inserting these into a table for the first time (an initial load), some database allow you to turn of logging which can increase your performance significantly. As mentioned, there may be 3rd party drivers that allow for enhanced performance of inserts. I don't know of any specific API calls that will categorically help insert statement performance, but that doesn't mean there isn't something there.
There are other things that can be done, usually from within the database itself, mostly to do with memory utilization, changes in checkpoint frequency and optimal logging that can also enhance insert performance, but that is probably beyond the scope of what you are asking and definitely out of the scope of this forum.
Once you know your goal (i.e. 200 inserts per second, or complete the process within 10 second ...) Then you need to determine where you are spending your time. Do you know how much time you are spending in the database vs. reading from the file system, or in the processing in between? Wouldn�t it be awkward if you spent time optimizing the code for inserts only to find out later that it was 2 seconds for the inserts and 12 for reading the records off the file system?
It's possible that someone may read this and say, this is ridiculous and way too much work, why would I do that? The answer is, if performance and tuning is too much work, then you simply don't require the additional performance so let it go. If you actually need better performance, and you always know when that's true, then these suggestions and the suggestions of the other posters are not nearly so onerous and may be helpful.
When talking about application performance, I sometimes say that people don't know how good it could be, and I think that results from people not setting and working towards specific performance goals. To be clear, faster, normal and optimized are not practical performance goals, "x% faster" and "less then x seconds and x inserts per second" are.

MartinHilpert,
You said that my response was �not really� nice, I guess implying that I was wrong or my reply was not of any value or maybe you just meant it wasn�t nice. I�m not really sure what you meant, I don�t know your background, and I mean no disrespect, but I disagree with what you wrote and I do have a couple of comments.
I do believe that working on performance initiatives without goals (as you described) can teach you a bit about performance and performance tuning techniques, but I do not consider an ungraded learning initiative to be an effective methodology for the tuning of an application.
but if it's just a little slow ...
they won't complain but just talk behind the backsI disagree that paranoia is a reason for looking at performance. If for some reason you are �worried� that performance is �slow� all you have to do is ask the users, there is no reason to assume anything. I�ve found users in my world to be very forthcoming about their perceptions of performance, and given the opportunity to voice their opinion, very willing to complain on even the smallest concern. I would be surprised that your users would not do the same unless you or your group is unusually unapproachable or perhaps intimidating for some reason. But I cannot imagine why that would be; we all serve at the pleasure of the users.
So, when your app works and you are finished and you
have time, try to improve performance anway.So when you are finished, you are not really finished? Sounds like you are using a consulting project methodology; the source for most never ending projects (please don't get prickly, I'm a consultant). To me this philosophy sounds a bit impractical and not at all trackable from a project management or funding perspective.
So, when your app works and you are finished and you
have time, try to improve performance anway.Your company has time and money to spend on never ending performance initiatives (without goals, they are by definition never ending), but no time to determine if the performance initiatives save money or enhance the user experience or more formally, moves application performance into SLA compliance?
That doesn't sound correct to me, and I doubt if a company would want to be perceived this way.
In retrospect, it is possible that yours is my dream company with my dream job, one without funding or time constraints, and no one holding me statistically responsible for the performance of my applications. Although I must admit I would not like people talking behind my back. :)
Regards.

Determine why query takes 30 seconds or longer

Hi. I've got an Oracle 9i procedure that takes some 30 seconds to run. It's for a Web app, so many users won't wait that long. How do I determine where the bottlenecks are in the code? Thanks.

Hi
Run it and watch in the OEM which sql statement's execution is the longest.
When you have the longest one, show us in a reply.
Ott Karesz
http://www.trendo-kft.hu

Insert query takes too much time

I have two select clauses as follows:
"select * from employee" This returns me 6000 rows.
& I have next clause as
"select * from employee where userid in(1,2,3,....,3000)"
This returns me 3000 rows.
Now i have to insert the result of above queries into same extended list view of Visual Basic. But the insert for first query takes 11 seconds while second takes 34 sec. We have evaluated this that this time is for insert query & not for select query.
I want to know that even if the Ist query returns 6000 rows it takes lesser time than the second which is
inserting 3000 rows.
We are using Oracle 8.1.7
Thanks in advance

The first query can do a straight dump of the table. The second select has to compare every userid to a hardcoded list of 3000 numbers. This will take quite a bit longer. Try rewriting it to
select * from employee where userid between 1 and 3000
It will run much faster then the other query.

Query takes 5 min when using Indexes and 1 Second without Indexes !!

Hi,
We have been using indexes on all tables until recently when we faced problems with queries like the one below:
SELECT a.std_id FROM students a, student_degree b, student_course c, course d
WHERE b.std_id = a.std_id
AND c.std_id = a.std_id
AND d.crn = c.crn
AND b.in_progress = 'Y'
AND b.major_code = 'ABTC'
AND a.program_code = 'DP'
AND a.level_code = 'S2'
AND a.campus_code = '05'
AND a.termcode = '200702';
This query takes more than 5 minutes to return a result, but as soon as we remove indexes on the columns termcode and campus_code,it shows result in 1 second.
What could be the problem ?, Is there an attribute that need to be set when creating these indexes ?
Thanks in advance
Madani

Thank you Karthik for your reply.Here are the explain plan report (as shown on Oracle 9i Enterprise Manager)
*1-Explain plan without Indexes:*
Execution Steps:
Step # Step Name
11 SELECT STATEMENT
10 MERGE JOIN
7 SORT [JOIN]
6 NESTED LOOPS
4 NESTED LOOPS
1 ERMS.STUDENT_DEGREE TABLE ACCESS [FULL]
3 ERMS.STUDENTS TABLE ACCESS [BY INDEX ROWID]
2 ERMS.SYS_C006642 INDEX [UNIQUE SCAN]
5 ERMS.SYS_C007065 INDEX [RANGE SCAN]
9 SORT [JOIN]
8 ERMS.COURSE TABLE ACCESS [FULL]
Step # Description
1 This plan step retrieves all rows from table STUDENT_DEGREE.
2 This plan step retrieves a single ROWID from the B*-tree index SYS_C006642.
3 This plan step retrieves rows from table STUDENTS through ROWID(s) returned by an index.
4 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause.
5 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index SYS_C007065.
6 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause.
7 This plan step accepts a row set (its only child) and sorts it in preparation for a merge-join operation.
8 This plan step retrieves all rows from table COURSE.
9 This plan step accepts a row set (its only child) and sorts it in preparation for a merge-join operation.
10 This plan step accepts two sets of rows sorted on the join key. By walking both sets of rows in the order of the join key, every distinct pair of rows satisfying the join condition in the WHERE clause is found through a single pass of the row sets.
11 This plan step designates this statement as a SELECT statement.
*2-Explain plan with Indexes:* (I added index on column campus_code which is a varchar2 column)
Execution Steps:
Step # Step Name
11 SELECT STATEMENT
10 MERGE JOIN
7 SORT [JOIN]
6 NESTED LOOPS
4 NESTED LOOPS
1 ERMS.COURSE TABLE ACCESS [FULL]
3 ERMS.STUDENTS TABLE ACCESS [BY INDEX ROWID]
2 ERMS.INDEX_STUDENTS_CAMPUS_CODE INDEX [RANGE SCAN]
5 ERMS.SYS_C007065 INDEX [RANGE SCAN]
9 SORT [JOIN]
8 ERMS.STUDENT_DEGREE TABLE ACCESS [FULL]
Step # Description
1 This plan step retrieves all rows from table COURSE.
2 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index INDEX_STUDENTS_CAMPUS_CODE.
3 This plan step retrieves rows from table STUDENTS through ROWID(s) returned by an index.
4 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause.
5 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index SYS_C007065.
6 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause.
7 This plan step accepts a row set (its only child) and sorts it in preparation for a merge-join operation.
8 This plan step retrieves all rows from table STUDENT_DEGREE.
9 This plan step accepts a row set (its only child) and sorts it in preparation for a merge-join operation.
10 This plan step accepts two sets of rows sorted on the join key. By walking both sets of rows in the order of the join key, every distinct pair of rows satisfying the join condition in the WHERE clause is found through a single pass of the row sets.
11 This plan step designates this statement as a SELECT statement.

Help: Selecting * from view takes minutes, query in view takes only seconds

Hello,
I have a view that i created that compiles ok and the query inside of the view only takes 2 seconds to return all the records. But if i try to select * from the view it takes 4-5 minutes to return the results. The explain plan is exactly the same, whether i select * from the view or run the query from within the view. Explain plan listed at bottom of post. Any ideas on where i might be going wrong? Thanks in advance.
The below query returns ~400 rows. If i limit the rows returned to ~200 with this additional line at the very end:
AND TEAM_CATEGORY LIKE '%FSM%'
the query runs in just a few seconds. So the rows returned is not the problem here.
Code:
SELECT /*+ PUSH_PRED( TEAM ) */ NP.ID_NUMBER,
       NP.PROSPECT_ID,
       NP.PREF_MAIL_NAME PROSPECT,
       NP.OFFICER_RATING RATING,
       NP.EVALUATION_RATING EVALUATION,
       P.ASK_AMT NEXT_ASK,
       P.ANTICIPATED_AMT EXPECT,
       NP.STRATEGY_DESCRIPTION STRATEGY,
       E1.LAST_NAME PROSPECT_MGR,
       TEAM.TEAM_CATEGORY,
       CASE
         WHEN TOPA.SHORT_DESC <> ' ' THEN
          'X'
       END TOPA,
       E.PREF_MAIL_NAME SPOUSE_NAME,
       PR.PROSPECT_NAME_SORT SORT_NAME
FROM ADVANCE_NU.NWU_PROSPECT NP,
       entity E,
       entity E1,
       assignment ASSI,
       prospect PR,
       (select p.proposal_id, p.prospect_id, p.ask_amt, p.anticipated_amt
          from proposal p
         where p.active_ind = 'Y'
           AND (p.stop_date IS NULL OR p.stop_date > sysdate)) P,
       (SELECT PC.PROSPECT_ID ID, TP.SHORT_DESC
          FROM PROSPECT_CATEGORY PC, TMS_PROSPECT_CATEGORY TP
         WHERE PC.PROSPECT_CATEGORY_CODE = TP.PROSPECT_CATEGORY_CODE
           AND pc.prospect_category_code = 'TOP') TOPS,
       (SELECT PC.PROSPECT_ID ID, TP.SHORT_DESC
          FROM PROSPECT_CATEGORY PC, TMS_PROSPECT_CATEGORY TP
         WHERE PC.PROSPECT_CATEGORY_CODE = TP.PROSPECT_CATEGORY_CODE
           AND pc.prospect_category_code = 'TFP') TOPA,
       (SELECT ID,
               CASE WHEN count(TEAM_CAT) >= 1 THEN MAX(DECODE(CT, 1, TEAM_CAT)) ELSE ' ' END
               || CASE WHEN count(TEAM_CAT) >= 2 THEN ', ' || MAX(DECODE(CT, 2, TEAM_CAT)) ELSE ' ' END
               || CASE WHEN count(TEAM_CAT) >= 3 THEN ', ' || MAX(DECODE(CT, 3, TEAM_CAT)) ELSE ' ' END
               || CASE WHEN count(TEAM_CAT) >= 4 THEN ', ' || MAX(DECODE(CT, 4, TEAM_CAT)) ELSE ' ' END
               || CASE WHEN count(TEAM_CAT) >= 5 THEN ', ' || MAX(DECODE(CT, 5, TEAM_CAT)) ELSE ' ' END
               || CASE WHEN count(TEAM_CAT) >= 6 THEN ', ' || MAX(DECODE(CT, 6, TEAM_CAT)) ELSE ' ' END
               TEAM_CATEGORY
          FROM (SELECT PC.PROSPECT_ID ID,
                       ROW_NUMBER() OVER(PARTITION BY PC.PROSPECT_ID ORDER BY PC.PROSPECT_CATEGORY_CODE ASC) CT,
                       TP.SHORT_DESC TEAM_CAT
                  FROM PROSPECT_CATEGORY PC, TMS_PROSPECT_CATEGORY TP
                 WHERE PC.PROSPECT_CATEGORY_CODE = TP.PROSPECT_CATEGORY_CODE
                   AND PC.PROSPECT_CATEGORY_CODE NOT IN ('TOP', 'TFP'))
         GROUP BY ID) TEAM
WHERE NP.PROSPECT_ID = P.PROSPECT_ID(+)
   AND NP.spouse_id = E.id_number(+)
   AND NP.prospect_id = PR.prospect_id
   AND NP.PROSPECT_ID = TOPS.ID
   AND NP.PROSPECT_ID = TEAM.ID(+)
   AND NP.prospect_id = TOPA.ID(+)
   AND NP.PROSPECT_ID = ASSI.PROSPECT_ID(+)
   AND ASSI.ASSIGNMENT_ID_NUMBER = E1.ID_NUMBER(+)
   AND ASSI.ASSIGNMENT_TYPE(+) = 'PM';Explain plan:
SELECT STATEMENT, GOAL = CHOOSE                              346     1     369          346
HASH JOIN OUTER                                   346     1     369          346
HASH JOIN OUTER                                   332     1     330          332
   NESTED LOOPS OUTER                                   326     1     190          326
    NESTED LOOPS OUTER                                   325     1     171          325
     NESTED LOOPS OUTER                                   323     1     152          323
      NESTED LOOPS OUTER                              322     1     119          322
       NESTED LOOPS                                   320     1     90          320
        NESTED LOOPS                                   319     1     67          319
         NESTED LOOPS                                   319     484568     24712968          319
          INDEX UNIQUE SCAN     ADVANCE     ZZ_ADV_TABLE_KEY0          1     1     8          1
          TABLE ACCESS FULL     ADVANCE_NU     NWU_PROSPECT          318     484568     20836424          318
         TABLE ACCESS BY INDEX ROWID     ADVANCE     PROSPECT_CATEGORY     1     16
          INDEX RANGE SCAN     ADVANCE     PROSPECT_CATEGORY_KEY2          1
        TABLE ACCESS BY INDEX ROWID     ADVANCE     PROSPECT          1     1     23          1
         INDEX UNIQUE SCAN     ADVANCE     PROSPECT_KEY0               1
       VIEW PUSHED PREDICATE     RPT_ACEPONIS                    2     1     29
        NESTED LOOPS                                   2     1     40          2
         TABLE ACCESS BY INDEX ROWID     ADVANCE     ZZ_ADV_TABLE          2     1     24          2
          INDEX UNIQUE SCAN     ADVANCE     ZZ_ADV_TABLE_KEY0          1     1               1
         TABLE ACCESS BY INDEX ROWID     ADVANCE     PROSPECT_CATEGORY     1     16
          INDEX RANGE SCAN     ADVANCE     PROSPECT_CATEGORY_KEY2          1
      TABLE ACCESS BY INDEX ROWID     ADVANCE     ENTITY               1     1     33          1
       INDEX UNIQUE SCAN     ADVANCE     ENTITY_KEY0               1
     TABLE ACCESS BY INDEX ROWID     ADVANCE     ASSIGNMENT          2     1     19          2
      INDEX RANGE SCAN     ADVANCE     ASSIGN_PROSPECT_KEY0               1     3               1
    TABLE ACCESS BY INDEX ROWID     ADVANCE     ENTITY                    1     1     19          1
     INDEX UNIQUE SCAN     ADVANCE     ENTITY_KEY0                    1
   VIEW     RPT_ACEPONIS                                   5     1     140
    SORT GROUP BY                                   5     1     48          5
     VIEW     RPT_ACEPONIS                              5     1     48
      WINDOW SORT                                   5     1     40          5
       NESTED LOOPS                                   2     1     40          2
        TABLE ACCESS FULL     ADVANCE     PROSPECT_CATEGORY          2     1     16          2
        TABLE ACCESS BY INDEX ROWID     ADVANCE     ZZ_ADV_TABLE          1     24
         INDEX UNIQUE SCAN     ADVANCE     ZZ_ADV_TABLE_KEY0          1
VIEW     RPT_ACEPONIS                                   13     170     6630
   SORT UNIQUE                                        13     170     32980          7
    UNION-ALL
     TABLE ACCESS FULL     ADVANCE     PROPOSAL                    3     125     24250          3
     TABLE ACCESS FULL     ADVANCE     PROPOSAL                    3     45     8730          3Message was edited by:
user624909
Message was edited by:
user624909
Message was edited by:
AndyCep

I'm no expert. Hopefully, someone else will chime in.
A couple points though:
1) (select p.*
from proposal p
where p.active_ind = 'Y'
AND p.stop_date > sysdate
union
select p.*
from proposal p
where p.active_ind = 'Y'
AND p.stop_date is null) P,
is using UNION. It should probably be a UNION ALL, or even better:
(select p.*
from proposal p
where p.active_ind = 'Y'
AND (p.stop_date IS NULL OR p.stop_date > sysdate)
2) select p.*
Do not use * in a VIEW. In fact, never use it outside EXISTS, COUNT(*) and ad hoc queries.
Use a COLUMN-list instead. Always use a COLUMN-list.
3)
The CASE statement has no ELSE, and is redundant.
     CASE
     WHEN count(TEAM_CAT) = 1 THEN MAX(DECODE(CT, 1, TEAM_CAT))
     WHEN count(TEAM_CAT) = 2 THEN MAX(DECODE(CT, 1, TEAM_CAT)) || ', ' || MAX(DECODE(CT, 2, TEAM_CAT))
     WHEN count(TEAM_CAT) = 3 THEN MAX(DECODE(CT, 1, TEAM_CAT)) || ', ' || MAX(DECODE(CT, 2, TEAM_CAT)) || ', ' || MAX(DECODE(CT, 3, TEAM_CAT))
     WHEN count(TEAM_CAT) = 4 THEN MAX(DECODE(CT, 1, TEAM_CAT)) || ', ' || MAX(DECODE(CT, 2, TEAM_CAT)) || ', ' || MAX(DECODE(CT, 3, TEAM_CAT)) || ', ' || MAX(DECODE(CT, 4, TEAM_CAT))
     WHEN count(TEAM_CAT) = 5 THEN MAX(DECODE(CT, 1, TEAM_CAT)) || ', ' || MAX(DECODE(CT, 2, TEAM_CAT)) || ', ' || MAX(DECODE(CT, 3, TEAM_CAT)) || ', ' || MAX(DECODE(CT, 4, TEAM_CAT)) || ', ' || MAX(DECODE(CT, 5, TEAM_CAT))
     WHEN count(TEAM_CAT) = 6 THEN MAX(DECODE(CT, 1, TEAM_CAT)) || ', ' || MAX(DECODE(CT, 2, TEAM_CAT)) || ', ' || MAX(DECODE(CT, 3, TEAM_CAT)) || ', ' || MAX(DECODE(CT, 4, TEAM_CAT)) || ', ' || MAX(DECODE(CT, 5, TEAM_CAT)) || ', ' || MAX(DECODE(CT, 6, TEAM_CAT))
     END TEAM_CATEGORY
How about something like:
     CASE WHEN count(TEAM_CAT) >= 1 THEN MAX(DECODE(CT, 1, TEAM_CAT)) ELSE ' ' END
     || CASE WHEN count(TEAM_CAT) >= 2 THEN ', ' || MAX(DECODE(CT, 2, TEAM_CAT)) ELSE ' ' END
     || CASE WHEN count(TEAM_CAT) >= 3 THEN ', ' || MAX(DECODE(CT, 3, TEAM_CAT)) ELSE ' ' END
     || CASE WHEN count(TEAM_CAT) >= 4 THEN ', ' || MAX(DECODE(CT, 4, TEAM_CAT)) ELSE ' ' END
     || CASE WHEN count(TEAM_CAT) >= 5 THEN ', ' || MAX(DECODE(CT, 5, TEAM_CAT)) ELSE ' ' END
     || CASE WHEN count(TEAM_CAT) >= 6 THEN ', ' || MAX(DECODE(CT, 6, TEAM_CAT)) ELSE ' ' END
     TEAM_CATEGORY
4) I have to ask. Have you run statistics lately?
5) Did you really alias a TABLE as "***"? Please tell me that is a formatting error.
6) Are you sure you need all those outer joins?

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.

Retrieve All records and display in Report using CAML query in Report Builder if Parameter value is blank

Hello Experts,
i have created a report where i have one parameter field where user will pass parameter(e.g. EmpId). As per parameter record will fetched to report if no parameter is passed then it will display all records. I have done it by taking SqlServer Database as datasource.
by using Following method
Now i would like to do it by taking Sharepoint List as Datasource. For that what would be the CAML Query.
Here is my existing CAML query.
<RSSharePointList xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<ListName>Employees</ListName>
<ViewFields>
<FieldRef Name="Title" />
<FieldRef Name="FirstName" />
<FieldRef Name="LastName" />
<FieldRef Name="FullName" />
<FieldRef Name="UserName" />
<FieldRef Name="Company" />
</ViewFields>
<Query>
<Where>
<Eq>
<FieldRef Name="Title" />
<Value Type="Text">
<Parameter Name="EmployeeId"/>
</Value>
</Eq>
</Where>
</Query>
</RSSharePointList>
The above code is working if i am passing an employeeId to Parameter. If nothing is passed, it is Not retrieving any record.
Please suggest
Thank you
saroj
saroj

Your problem follows the well-established pattern of using an "All" parameter filter in SSRS. There are a few approaches depending on the size of your data. The easiest one is to return all data from CAML and then filter it within SSRS, the following thread
provides some examples,
http://stackoverflow.com/questions/18203317/show-all-records-some-records-based-on-parameter-value.
Other options include passing all of the possible values within the CAML query when "All" is selected, using multiple Report Files to distinguish between both CAML queries, or to use multiple datasets with some logic to show/hide the correct one.
Dimitri Ayrapetov (MCSE: SharePoint)

Query takes too much time in fetching last records.

Hi,
I am using oracle 8.1 and trying to execute a SQL statement, it takes few minutes and display records.
When trying to fetch all the records, it is fast up to some level and takes much time to fetch last record.
Ex: If total records = 16336 , then it fetches records faster up to 16300 and takes app.500 sec to fetch last 36 records.
Could you kindly let me know the reason.
I have copied the explain plan below for your reference.Please let me know if anything is required.
SELECT STATEMENT, GOAL = RULE               4046     8     4048
NESTED LOOPS OUTER               4046     8     4048
NESTED LOOPS OUTER               4030     8     2952
   FILTER
    NESTED LOOPS OUTER
     NESTED LOOPS OUTER               4014     8     1728
      NESTED LOOPS               3998     8     936
       TABLE ACCESS BY INDEX ROWID     IFSAPP     CUSTOMER_ORDER_TAB     3966     8     440
        INDEX RANGE SCAN     IFSAPP     CUSTOMER_ORDER_1_IX     108     8
       TABLE ACCESS BY INDEX ROWID     IFSAPP     CUSTOMER_ORDER_LINE_TAB     4     30667     1901354
        INDEX RANGE SCAN     IFSAPP     CUSTOMER_ORDER_LINE_PK     3     30667
      TABLE ACCESS BY INDEX ROWID     IFSAPP     PWR_CONS_PARCEL_CONTENT_TAB     2     2000     198000
       INDEX RANGE SCAN     IFSAPP     PWR_CONS_PARCEL_CONTENT_1_IDX     1     2000
     TABLE ACCESS BY INDEX ROWID     IFSAPP     PWR_CONS_PARCEL_TAB     1     2000     222000
      INDEX UNIQUE SCAN     IFSAPP     PWR_CONS_PARCEL_PK          2000
   TABLE ACCESS BY INDEX ROWID     IFSAPP     CONSIGNMENT_PARCEL_TAB     1     2000     84000
    INDEX UNIQUE SCAN     IFSAPP     CONSIGNMENT_PARCEL_PK          2000
TABLE ACCESS BY INDEX ROWID     IFSAPP     PWR_OBJECT_CONNECTION_TAB     2     20     2740
   INDEX RANGE SCAN     IFSAPP     PWR_OBJECT_CONNECTION_IX1     1     20     Thanks.

We are using PL/SQL Developer tool. The time what we have mentioned in the post is approximated time.
Apologies for not mentioning these details in previous thread.Let it be approximate time but how did you arrive at that time? When a query fetches records how did you derived that one portion is fetched in x and the remaining in y time limit?
I would suggest this could be some issue with PL/SQL Developer (Never used this tool by myself) But for performance testing i would suggest you to use SQL Plus. Thats the best tool to test performance.

Ldap search query takes more than 10 seconds

LDAP query takes more than 10 seconds to execute.
For validating the policy configured, the Acess Manager(Sun Java System Access Manager) contacts the LDAP (Sun Java System Directory Server 6.2) to get the users in a dynamic group. The time out value configured in Access Manager for LDAP searches is 10 seconds.
Issue : The ldap query takes more than 10 seconds to execute at some times .
The query is executing with less than 10 seconds in most of the cases, but it takes more than 10 seconds in some cases. The total number of users available in the ldap is less than 1500.
7 etime =1
6 etime =1
102 etime=4
51 etime=5
26 etime=6
5 etime=7
4 etime=8
From the ldap access logs we can see the following entry,some times the query takes more than 10 seconds,
[28/May/2012:14:21:26 +0200] conn=281 op=41433 msgId=853995 - SRCH base="dc=****,dc=****,dc=com" scope=2 filter="(&(&(***=true)(**=true))(objectClass=vfperson))" attrs=ALL
[28/May/2012:14:21:36 +0200] conn=281 op=41434 msgId=854001 - ABANDON targetop=41433 msgid=853995 nentries=884 etime=10
The query was aborted by the access manger after 10 seconds.
Please post your suggestions to resolve this issue .
1.How we can find out , why the query is taking more than 10 seconds ?
2.Next steps to resolve this issue .

Hi Marco,
Thanks for your suggestions.
Sorry for replying late. I was out of office for few weeks.
1) Have you already tuned the caches? (entry cache, db cache, filesystem cache?)
We are using db cache and we have not done any turning for cache. The application was working fine and there was no much changes in the number of users .
2) Unfortunately we don't have direct access to the environment and we have contacted the responsible team to verify the server health during the issue .
Regarding the IO operations we can see that, load balancer is pinging the ldap sever every 15 seconds to check the status of ldap servers which yields a new connection on every hit. (on average per minute 8 connections - )
3) We using cn=dsameuser to bind the directory server. Other configuration details for ldap
LDAP Connection Pool Minimum Size: 1
LDAP Connection Pool Maximum Size:10
Maximum Results Returned from Search: 1700
Search Timeout: 10
Is the Search Timeout value configured is proper ? ( We have less than 1500 user in the ldap server).
Also is there any impact if the value Maximum Results Returned from Search = set to 1700. ( The Sun document for AM says that the ideal value for this is 1000 and if its higher than this it will impact performance.
The application was running without time out issue for last 2 years and there was no much increase in the number of users in the system. ( at the max 200 users added to the system in last 2 years.)
Thanks,
Jay

SQL Query to retrieve the records

Hi All,
I have one table. It contains millions of records.I gave the query as follows.
select * from emp where empnob in (1,1000)
it displays empnob
1 A 300000 Manager
6 B 120000 Analyst
87 C 32980 salsman
Now I want to retrieve remaining records. Pelase let me know the query which are not available in emp table between the given limit.
Thank you.

Hi ,
For example there are 10 records only.
I gave
select * from emp where empno in (1,10)
t displays the records having the empnos 1,3,4,6,8
Now I want to display the records 2,5,7,9,10 also...
Please let me know the query.Are use using an oracle database? My Oracle database would never return such a result for your query.
Please post some output from an sqlplus session where you show us exactly what you do.
Message was edited by:
Sven W.

Personnel Admin AdHoc Query not retrieving all records

Hi, I recently added a custom info type to a copy of the SAP ad hoc query for Personnel Admin by using the menu path in SQ02>Edit>Change Infotype selection . The query is picking up the new info type and runs fine but does not retrieve all records from the table for a given personnel id. It only retrieves 1 record per id.
Has anyone dealt with this before and have an easy/quick fix for this?

Have other users try the query, preferably a user with end user authorization.
I've had this issue before, I'm an IT person and I customized a Standard infoset.
During testing, I'm only getting 1 (in my case) Insurance record per employee.
The end user can see multiple record per employee.
Btw, did you customize a Global or a Standard Infoset?
Regards,
Olekan

Query to retrieve the records which have more than one assignment_id

Hello,
I am trying to write a query to retrieve all the records from the table per_all_assignments_f which has more than one different assignment_id for each person_id. Below is the query i have written but this retrieves the records even if a person_id has duplicate assignment_id's but i need records which have more than one assignement_id with no duplicates for each person_id
select assignment_id ,person_id, assignment_id
From per_all_assignments_f
having count(assignment_id) >1
group by person_id, assignment_id
Thank You.
PK

Maybe something like this?
select *
From   per_all_assignments_f f1
where exists (select 1
               from   per_all_assignments_f f2
               where f2.person_id = f1.person_id
               and    f2.assignment_id != f1.assignment_id
              );Edited by: SomeoneElse on May 7, 2010 2:23 PM
(you can add a DISTINCT to the outer query if you need to)

Query Takes 43 seconds to retrieve 650 records

Similar Messages

Maybe you are looking for