Index - Sequential Read

Dear friends,
In one of our client oracle is used as SAP DB.
Here the major problem is, even though the reports made use of primary and secondary indexs, they are going to sequential read instead of direct read and the performance is badly affected.
Kindly suggest.
Praveen Lobo

Here the major problem is, even though the reports made use of primary and secondary indexs, they are going to sequential read instead of direct read and the performance is badly affected.
First: don´t rely on information on SM50/SM66.
Second: did you do an SQL trace in ST05 for the statement and see what execution plan is used?
Markus

Similar Messages

  • Direct Path Reads instead of Sequential Reads for index range scan

    Database is 11.2. I have two development schemas, with the same table loaded in each schema - a 5 million row table. The execution path for the sql statement is the same against both tables; it's doing an index range scan.
    But it would appear Oracle performs a direct path read against one schema, and performs sequential reads against the other schema. I don't understand why I'm seeing different behavior when the execution plan is the same. Any ideas? These are two different schemas in the same database.

    There is not enough information.So you even these tables located same database and you gathered statistics it is not mean both run time wait event statistics must be same.Really they are different tables.If both query use INDEX RANGE SCAN the it is not mean these plans are same.What about table and their index statistics? are they same? for example num_row or num_blocks of both tables are same? also about indexes.In additionally if you want to get exact reason you can enable sql trace(using dbms_monitor or setting sql_trace parameter to true according session) and need analyze result trace file using tkprof utility.In additionally in 11g here when query execution time oracle automatically choose direct read path(serial) based on size of tables and size of buffer cache(also here is available some hidden parameter to controlling this behavior).

  • Select using Indexed field, still using sequential read

    Hi Experts,
    I am selecting from CATSDB table
    SELECT SINGLE *  FROM catsdb
              WHERE belnr = var.
    BELNR is indexed so I am expecting that this statement will do a direct read.
    But when this statement is run, SAP message indicates that
    it is performing a sequential read.  Anybody knows why this is?  And how do I make direct read happen?
    Thank you very much for your help.
    Bes Regards,
    Rose

    Hi,
    may be you need to update the database statistics for that table or you need to recreate the index. Check out db02 for the table or make some check using se14.
    regards
    Siggi
    PS: Also fm rsdu_analyze_tables will be of some help. do a test run in se37 and enter the name of the table.
    Message was edited by:
            Siegfried Szameitat

  • Query running very slow with db file sequential read waits which all indexes would be recommended

    My query is doing lot of db file sequential reads I want to create few indexes and extended stats please help me with your suggestions.
    Can anybody suggest I am unable to paste my query here -don't know why it's not getting pasted--is it not permitted ? 
    thank you.

    The simplest way to find it out is using Oracle Enterprise Manager. Just locate the SQL ID for the SQL and run "SQL tuning advisor". This will exactly pinpoint where do you need to create indexes etc. Another option is manually running explain plan for the SQL and finding out which predicate is causing full scans with high i/o
    Regards
    Tushar

  • Update Statement Simply hanged but doing db file sequential read

    Hi,
    Last night we had issue with one of the prod server where we updating one of table which contains large number records in millions.Same identical machine completed in1 hour and other box never completed but doing db file sequential read but in the long ops the last statement it was done 20:16 after that nothing is happening but i ran few trace on that user.
    /u01/app/oracle/admin/SURV2/udump/surv2_ora_10048.trc
    Oracle Database 10g Release 10.2.0.4.0 - Production
    ORACLE_HOME = /u01/app/oracle/product/10.2.0/db
    System name:     SunOS
    Node name:     prdfa001
    Release:     5.10
    Version:     Generic_139556-08
    Machine:     i86pc
    Instance name: SURV2
    Redo thread mounted by this instance: 1
    Oracle process number: 18
    Unix process pid: 10048, image: oracle@prdfa001
    *** 2010-09-09 23:37:07.484
    *** ACTION NAME:() 2010-09-09 23:37:07.473
    *** MODULE NAME:(SQL*Plus) 2010-09-09 23:37:07.473
    *** SERVICE NAME:(SURV2) 2010-09-09 23:37:07.473
    *** SESSION ID:(289.54) 2010-09-09 23:37:07.473
    Received ORADEBUG command 'unlimit' from process Unix process pid: 3983, image:
    *** 2010-09-09 23:37:20.315
    Received ORADEBUG command 'event 10046 trace name context forever, level 12' from process Unix process pid: 3983, image:
    WAIT #7: nam='db file sequential read' ela= 11160 file#=13 block#=2252349 blocks=1 obj#=166421 tim=12499462835161
    WAIT #7: nam='db file sequential read' ela= 2857 file#=13 block#=2249751 blocks=1 obj#=166421 tim=12499462838137
    WAIT #7: nam='db file sequential read' ela= 3810 file#=13 block#=2251361 blocks=1 obj#=166421 tim=12499462842048
    WAIT #7: nam='db file sequential read' ela= 4459 file#=13 block#=2247059 blocks=1 obj#=166421 tim=12499462846564
    WAIT #7: nam='db file sequential read' ela= 2841 file#=13 block#=2247507 blocks=1 obj#=166421 tim=12499462849468
    WAIT #7: nam='db file sequential read' ela= 427 file#=13 block#=2247568 blocks=1 obj#=166421 tim=12499462850032
    WAIT #7: nam='db file sequential read' ela= 1187 file#=13 block#=2248264 blocks=1 obj#=166421 tim=12499462851327
    WAIT #7: nam='db file sequential read' ela= 2687 file#=13 block#=2250707 blocks=1 obj#=166421 tim=12499462854178
    WAIT #7: nam='db file sequential read' ela= 3657 file#=13 block#=2249697 blocks=1 obj#=166421 tim=12499462857896
    WAIT #7: nam='db file sequential read' ela= 4139 file#=13 block#=2247074 blocks=1 obj#=166421 tim=12499462862093
    WAIT #7: nam='db file sequential read' ela= 4180 file#=47 block#=3649690 blocks=1 obj#=166421 tim=12499509270445
    WAIT #7: nam='db file sequential read' ela= 4802 file#=47 block#=3649309 blocks=1 obj#=166421 tim=12499509275327
    WAIT #7: nam='db file sequential read' ela= 2459 file#=47 block#=3652697 blocks=1 obj#=166421 tim=12499509277859
    WAIT #7: nam='db file sequential read' ela= 4015 file#=47 block#=3652826 blocks=1 obj#=166421 tim=12499509281948
    WAIT #7: nam='db file sequential read' ela= 2248 file#=47 block#=3651610 blocks=1 obj#=166421 tim=12499509284269
    WAIT #7: nam='db file sequential read' ela= 4824 file#=47 block#=3654297 blocks=1 obj#=166421 tim=12499509289166
    WAIT #7: nam='db file sequential read' ela= 2008 file#=47 block#=3652312 blocks=1 obj#=166421 tim=12499509291248
    WAIT #7: nam='db file sequential read' ela= 1925 file#=47 block#=3654490 blocks=1 obj#=166421 tim=12499509293246
    WAIT #7: nam='db file sequential read' ela= 2859 file#=47 block#=3648458 blocks=1 obj#=166421 tim=12499509296178
    WAIT #7: nam='db file sequential read' ela= 1740 file#=47 block#=3648212 blocks=1 obj#=166421 tim=12499509297991
    WAIT #7: nam='db file sequential read' ela= 2566 file#=47 block#=3648411 blocks=1 obj#=166421 tim=12499509300631
    WAIT #7: nam='db file sequential read' ela= 50772 file#=5 block#=480749 blocks=1 obj#=166421 tim=12499509351477
    WAIT #7: nam='db file sequential read' ela= 12928 file#=5 block#=477177 blocks=1 obj#=166421 tim=12499509364482
    WAIT #7: nam='db file sequential read' ela= 11116 file#=5 block#=479412 blocks=1 obj#=166421 tim=12499509375672
    WAIT #7: nam='db file sequential read' ela= 4803 file#=5 block#=483440 blocks=1 obj#=166421 tim=12499509380549
    WAIT #7: nam='db file sequential read' ela= 6900 file#=5 block#=481454 blocks=1 obj#=166421 tim=12499509387522
    Received ORADEBUG command 'event 10046 trace name context off' from process Unix process pid: 3983, image:
    /u01/app/oracle/admin/SURV2/udump/surv2_ora_1545.trc
    Oracle Database 10g Release 10.2.0.4.0 - Production
    ORACLE_HOME = /u01/app/oracle/product/10.2.0/db
    System name:     SunOS
    Node name:     prdfa001
    Release:     5.10
    Version:     Generic_139556-08
    Machine:     i86pc
    Instance name: SURV2
    Redo thread mounted by this instance: 1
    Oracle process number: 22
    Unix process pid: 1545, image: oracle@prdfa001 (TNS V1-V3)
    *** ACTION NAME:() 2010-09-09 23:20:13.485
    *** MODULE NAME:(sqlplus@prdfa001 (TNS V1-V3)) 2010-09-09 23:20:13.485
    *** SERVICE NAME:(SYS$USERS) 2010-09-09 23:20:13.485
    *** SESSION ID:(290.697) 2010-09-09 23:20:13.485
    ===================================================
    SYSTEM STATE
    System global information:
         processes: base 47819b480, size 300, cleanup 4781a5638
         allocation: free sessions 47f1d6148, free calls 0
         control alloc errors: 0 (process), 0 (session), 0 (call)
         PMON latch cleanup depth: 0
         seconds since PMON's last scan for dead processes: 20
         system statistics:
    1171 logons cumulative
    19 logons current
    89219 opened cursors cumulative
    86 opened cursors current
    15095069 user commits
    5 user rollbacks
    58632904 user calls
    44023255 recursive calls
    224311 recursive cpu usage
    201424173 session logical reads
    0 session stored procedure space
    901812 CPU used when call started
    995437 CPU used by this session
    6814196 DB time
    0 cluster wait time
    22542300822 concurrency wait time
    3095 application wait time
    16479074661 user I/O wait time
    1284052668 session connect time
    1284067190 process last non-idle time
    189018343568 session uga memory
    1249667216 session uga memory max
    26059216 messages sent
    26059220 messages received
    239739 background timeouts
    162399896 session pga memory
    189662872 session pga memory max
    4 enqueue timeouts
    901146 enqueue waits
    0 enqueue deadlocks
    32122711 enqueue requests
    17819 enqueue conversions
    32122676 enqueue releases
    0 global enqueue gets sync
    0 global enqueue gets async
    0 global enqueue get time
    0 global enqueue releases
    2865667 physical read total IO requests
    262620 physical read total multi block requests
    270093476864 physical read total bytes
    select SYS_CONTEXT('USERENV', 'SERVER_HOST'), SYS_CONTEXT('USERENV', 'DB_UNIQUE_NAME'), SYS_CONTEXT('USERENV', 'INSTANCE_NAME'), SYS_CONTEXT('USERENV', 'SERVICE_NAME'), INSTANCE_NUMBER, STARTUP_TIME, SYS_CONTEXT('USERENV', 'DB_DOMAIN') from v$instance where INSTANCE_NAME=SYS_CONTEXT('USERENV', 'INSTANCE_NAME')
          hash=550c95f3d0cfa8290e60ea8382d3a2ca timestamp=09-09-2010 04:24:19
          namespace=CRSR flags=RON/KGHP/TIM/PN0/LRG/KST/DBN/MTX/[100100d1]
          kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=9 hpc=0582 hlc=0582
          lwt=47df576e8[47df576e8,47df576e8] ltm=47df576f8[47df576f8,47df576f8]
          pwt=47df576b0[47df576b0,47df576b0] ptm=47df576c0[47df576c0,47df576c0]
          ref=47df57718[47df57718,47df57718] lnd=47df57730[47df57730,47df57730]
            LIBRARY OBJECT: object=471ee1d38
            type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
            CHILDREN: size=16
            child#    table reference   handle
                 0 471ee1800 471ee1470 47df7dce0
            DATA BLOCKS:
            data#     heap  pointer    status pins change whr
                0 47df7de48 471ee1e50 I/P/A/-/-    0 NONE   00
          SO: 473691d60, type: 53, owner: 47924e810, flag: INIT/-/-/0x00
          LIBRARY OBJECT LOCK: lock=473691d60 handle=47bb22fa0 mode=N
          call pin=0 session pin=0 hpc=0000 hlc=0000
          htl=473691de0[4735dbcb8,476cfbf58] htb=476cfbf58 ssga=476cfb6a0
          user=47924e810 session=47f2310f0 count=1 flags=[0000] savepoint=0x0
          LIBRARY OBJECT HANDLE: handle=47bb22fa0 mtx=47bb230d0(0) cdp=0
          namespace=CRSR flags=RON/KGHP/PN0/EXP/[10010100]
          kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=3 hpc=fd84 hlc=fd84
          lwt=47bb23048[47bb23048,47bb23048] ltm=47bb23058[47bb23058,47bb23058]
          pwt=47bb23010[47bb23010,47bb23010] ptm=47bb23020[47bb23020,47bb23020]
          ref=47bb23078[472f8de18,472f8de18] lnd=47bb23090[47bb23090,47bb23090]
            LIBRARY OBJECT: object=472f8d9d8
            type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
            DEPENDENCIES: count=1 size=16
            AUTHORIZATIONS: count=1 size=16 minimum entrysize=16
            ACCESSES: count=1 size=16
            TRANSLATIONS: count=1 size=16
            DATA BLOCKS:
            data#     heap  pointer    status pins change whr
                0 47bb22ee0 472f8daf0 I/P/A/-/-    0 NONE   00
                6 472f8e508 46be86250 I/-/A/-/E    0 NONE   00
          SO: 4735dbc38, type: 53, owner: 47924e810, flag: INIT/-/-/0x00
          LIBRARY OBJECT LOCK: lock=4735dbc38 handle=47bb231c8 mode=N
          call pin=0 session pin=0 hpc=0000 hlc=0000
          htl=4735dbcb8[476cfbf58,473691de0] htb=476cfbf58 ssga=476cfb6a0
          user=47924e810 session=47f2310f0 count=1 flags=[0000] savepoint=0x4c894f8b
          LIBRARY OBJECT HANDLE: handle=47bb231c8 mtx=47bb232f8(1) cdp=1
          name=select value$ from props$ where name = 'GLOBAL_DB_NAME'
          hash=4bb432d65c5a391a42a5c3fa74472c7a timestamp=09-09-2010 04:24:12
          namespace=CRSR flags=RON/KGHP/TIM/PN0/SML/KST/DBN/MTX/[120100d0]
          kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=3 hpc=0584 hlc=0584
          lwt=47bb23270[47bb23270,47bb23270] ltm=47bb23280[47bb23280,47bb23280]
          pwt=47bb23238[47bb23238,47bb23238] ptm=47bb23248[47bb23248,47bb23248]
          ref=47bb232a0[47bb232a0,47bb232a0] lnd=47bb232b8[47bb232b8,47bb232b8]
            LIBRARY OBJECT: object=472f8e6e0
            type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
            CHILDREN: size=16
            child#    table reference   handle
                 0 472f8e1a8 472f8de18 47bb22fa0
            DATA BLOCKS:
            data#     heap  pointer    status pins change whr
                0 47bb23108 472f8e7f8 I/P/A/-/-    0 NONE   00
          SO: 473644348, type: 53, owner: 47924e810, flag: INIT/-/-/0x00
          LIBRARY OBJECT LOCK: lock=473644348 handle=47bbde418 mode=N
          call pin=0 session pin=0 hpc=0000 hlc=0000
          htl=4736443c8[476cfc0b8,476cfc0b8] htb=476cfc0b8 ssga=476cfb6a0
          user=47924e810 session=47924e810 count=1 flags=[0000] savepoint=0x4c894f8b
          LIBRARY OBJECT HANDLE: handle=47bbde418 mtx=47bbde548(0) cdp=0
          name=ALTER SESSION SET TIME_ZONE='+02:00'
          hash=3878dff8839e71e3dd05a2e75fbd6390 timestamp=09-09-2010 04:24:04
          namespace=CRSR flags=RON/KGHP/TIM/PN0/SML/DBN/[12010040]
          kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=11 hpc=04e8 hlc=04e8
          lwt=47bbde4c0[47bbde4c0,47bbde4c0] ltm=47bbde4d0[47bbde4d0,47bbde4d0]
          pwt=47bbde488[47bbde488,47bbde488] ptm=47bbde498[47bbde498,47bbde498]
          ref=47bbde4f0[47bbde4f0,47bbde4f0] lnd=47bbde508[47bbde508,47bbde508]
            LIBRARY OBJECT: object=472fffc08
            type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
            DATA BLOCKS:
            data#     heap  pointer    status pins change whr
                0 47bbde320 472fffd20 I/P/A/-/-    0 NONE   00
          SO: 47aecf9e8, type: 41, owner: 47924e810, flag: INIT/-/-/0x00
          (dummy) nxc=0, nlb=0  
        SO: 47f290540, type: 11, owner: 4781a7dc0, flag: INIT/-/-/0x00
        (broadcast handle) flag: (2) ACTIVE SUBSCRIBER, owner: 4781a7dc0,
                           event: 1132, last message event: 1132,
                           last message waited event: 1132,                        next message: 0(0), messages read: 0
                           channel: (47a2df4f8) system events broadcast channel
                                    scope: 2, event: 1132, last mesage event: 18,
                                    publishers/subscribers: 0/17,
                                    messages published: 1
        SO: 47826b228, type: 3, owner: 4781a7dc0, flag: INIT/-/-/0x00
        (call) sess: cur 47924e810, rec 0, usr 47924e810; depth: 0
        SO: 476c52968, type: 16, owner: 4781a7dc0, flag: INIT/-/-/0x00
        (osp req holder)
    PSEUDO PROCESS for group DEFAULT:
      SO: 47a1eb7d0, type: 2, owner: 0, flag: INIT/-/-/0x00
      (process) Oracle pid=0, calls cur/top: 0/0, flag: (20) PSEUDO
                int error: 0, call error: 0, sess error: 0, txn error 0
      (post info) last post received: 0 0 0
                  last post received-location: No post
                  last process to post me: none
                  last post sent: 0 0 0
                  last post sent-location: No post
                  last process posted by me: none
        (latch info) wait_event=0 bits=0
        Process Group: DEFAULT, pseudo proc: 47a1eb7d0
        O/S info: user: , term: , ospid:  (DEAD)
        OSD pid info: Unix process pid: 0, image: PSEUDO
    Dump of memory from 0x00000004791BF538 to 0x00000004791BF740
    4791BF530                   00000000 00000000          [........]
    4791BF540 00000000 00000000 00000000 00000000  [................]
      Repeat 31 times
    NO DETACHED BRANCHES.
    NO DETACHED NETWORK CONNECTIONS.
    CLEANUP STATE OBJECTS:
    SO: 47f0cd038, type: 1, owner: 0, flag: INIT/-/-/0x00
    (cleanup state object) description: instance enqueue anchor state
    latch: 0x380009890
      SO: 4782cf080, type: 5, owner: 47f0cd038, flag: INIT/-/-/0x00
      (enqueue) TA-00000006-00000001     DID: 0001-000F-0000000B
      lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  res_flag: 0x2
      res: 0x47a28d020, mode: X, lock_flag: 0x0
      own: 0x0, sess: 0x0, prv: 0x47a28d030
    SO: 47f0cd098, type: 1, owner: 0, flag: INIT/-/-/0x00
    (cleanup state object) description: switchable channel handle anch
    latch: 0x38000ac98
      SO: 47f28f868, type: 11, owner: 47f0cd098, flag: INIT/-/-/0x00
      (broadcast handle) flag: (c2) ACTIVE SUBSCRIBER, owner: 0,
                         event: 1, last message event: 1,
                         last message waited event: 1,                      next message: 0(0), messages read: 0
                         channel: (47a2e4190) KPON channel
                                  scope: 2, event: 1, last mesage event: 0,
                                  publishers/subscribers: 0/1,
                                  messages published: 0
    SO: 47f0cd0f8, type: 1, owner: 0, flag: INIT/-/-/0x00
    (cleanup state object) description: TT shared object cleanup SO
    latch: 0x38001c6b8
    SO: 47f0cd158, type: 1, owner: 0, flag: INIT/-/-/0x00
    (cleanup state object) description: SS shared object cleanup SO
    latch: 0x38001cd48
    END OF SYSTEM STATE
    Top 5 Timed Events                                         Avg %Total
    ~~~~~~~~~~~~~~~~~~                                        wait   Call
    Event                                 Waits    Time (s)   (ms)   Time Wait Class
    db file sequential read           2,347,652       9,215      4   64.5   User I/O
    db file scattered read              245,687       4,199     17   29.4   User I/O
    CPU time                                            974           6.8
    db file parallel write               50,082         408      8    2.9 System I/O
    log file parallel write               6,963          52      7    0.4 System I/O
    Time Model Statistics                DB/Inst: SURV2/SURV2  Snaps: 19172-19178
    -> Total time in database user-calls (DB Time): 14286.4s
    -> Statistics including the word "background" measure background process
       time, and so do not contribute to the DB time statistic
    -> Ordered by % or DB time desc, Statistic name
    Statistic Name                                       Time (s) % of DB Time
    sql execute elapsed time                             14,280.3        100.0
    DB CPU                                                  974.5          6.8
    PL/SQL execution elapsed time                           531.8          3.7
    parse time elapsed                                       30.5           .2
    hard parse elapsed time                                  27.1           .2
    connection management call elapsed time                  14.9           .1
    hard parse (sharing criteria) elapsed time                3.4           .0
    hard parse (bind mismatch) elapsed time                   3.1           .0
    PL/SQL compilation elapsed time                           2.4           .0
    failed parse elapsed time                                 0.0           .0
    repeated bind elapsed time                                0.0           .0
    sequence load elapsed time                                0.0           .0
    DB time                                              14,286.4          N/A
    background elapsed time                                 670.2          N/A
    background cpu time                                     186.1          N/A
    Wait Class                            DB/Inst: SURV2/SURV2  Snaps: 19172-19178
    -> s  - second
    -> cs - centisecond -     100th of a second
    -> ms - millisecond -    1000th of a second
    -> us - microsecond - 1000000th of a second
    -> ordered by wait time desc, waits desc
                                                                      Avg
                                           %Time       Total Wait    wait     Waits
    Wait Class                      Waits  -outs         Time (s)    (ms)      /txn
    User I/O                    2,593,484     .0           13,415       5     150.0
    System I/O                     87,506     .0              515       6       5.1
    Other                             839   11.4                6       7       0.0
    Commit                          3,225     .1                6       2       0.2
    Concurrency                     1,033     .0                5       5       0.1
    Configuration                   2,514   99.4                0       0       0.1
    Network                        47,559     .0                0       0       2.8
    Application                         7     .0                0       0       0.0
    Wait Events                          DB/Inst: SURV2/SURV2  Snaps: 19172-19178
    -> s  - second
    -> cs - centisecond -     100th of a second
    -> ms - millisecond -    1000th of a second
    -> us - microsecond - 1000000th of a second
    -> ordered by wait time desc, waits desc (idle events last)
                                                                       Avg
                                                 %Time  Total Wait    wait     Waits
    Event                                 Waits  -outs    Time (s)    (ms)      /txn
    db file sequential read           2,347,652     .0       9,215       4     135.8
    db file scattered read              245,687     .0       4,199      17      14.2
    db file parallel write               50,082     .0         408       8       2.9
    log file parallel write               6,963     .0          52       7       0.4
    control file parallel write           6,203     .0          44       7       0.4
    control file sequential read         24,242     .0          11       0       1.4
    log file sync                         3,225     .1           6       2       0.2
    latch free                               84     .0           4      47       0.0
    os thread startup                        25     .0           3     120       0.0
    latch: session allocation                39     .0           1      33       0.0
    db file parallel read                    12     .0           1      92       0.0
    enq: TX - index contention              186     .0           1       3       0.0
    latch: shared pool                       47     .0           1      11       0.0
    LGWR wait for redo copy                 319    3.1           0       1       0.0
    library cache load lock                   2     .0           0     172       0.0
    buffer busy waits                       590     .0           0       0       0.0
    log file switch completion                6     .0           0      29       0.0
    SGA: allocation forcing comp             11   54.5           0      14       0.0
    latch: library cache lock                50     .0           0       3       0.0
    read by other session                    38     .0           0       4       0.0
    direct path read                         42     .0           0       3       0.0
    SQL*Net message to client            44,807     .0           0       0       2.6
    rdbms ipc reply                         207     .0           0       0       0.0
    SQL*Net more data from clien          1,014     .0           0       0       0.1
    latch: cache buffers chains              24     .0           0       1       0.0
    latch: library cache                     29     .0           0       1       0.0
    log file sequential read                  8     .0           0       3       0.0
    direct path write                        50     .0           0       0       0.0
    SQL*Net more data to client             398     .0           0       0       0.0
    latch: object queue header o             12     .0           0       1       0.0
    latch: In memory undo latch              78     .0           0       0       0.0
    undo segment extension                2,507   99.7           0       0       0.1
    latch: cache buffers lru cha              4     .0           0       1       0.0
    log file single write                     8     .0           0       0       0.0
    local write wait                          3     .0           0       1       0.0
    enq: RO - fast object reuse               3     .0           0       1       0.0
    buffer deadlock                          87   92.0           0       0       0.0
    enq: JS - queue lock                      1     .0           0       1       0.0
    cursor: pin S                            70     .0           0       0       0.0
    latch: row cache objects                  2     .0           0       1       0.0
    SQL*Net message to dblink             1,338     .0           0       0       0.1
    latch: checkpoint queue latc              2     .0           0       0       0.0
    reliable message                          3     .0           0       0       0.0
    log buffer space                          1     .0           0       1       0.0
    SQL*Net break/reset to clien              4     .0           0       0       0.0
    SQL*Net more data from dblin              2     .0           0       0       0.0
    SQL*Net message from client          44,949     .0     155,701    3464       2.6
    virtual circuit status                  621  100.0      18,156   29237       0.0
    Streams AQ: qmn slave idle w            664     .0      18,127   27299       0.0
    Streams AQ: qmn coordinator           1,339   50.4      18,099   13517       0.1
    Streams AQ: waiting for time             12  100.0       8,741  728394       0.0
    jobq slave wait                         130  100.0         380    2927       0.0
    PL/SQL lock timer                         1  100.0           1     978       0.0
    SQL*Net message from dblink           1,338     .0           0       0       0.1
    single-task message                       1     .0           0      38       0.0
    class slave wait                         11     .0           0       1       0.0
    SQL ordered by Elapsed Time          DB/Inst: SURV2/SURV2  Snaps: 19172-19178
    -> Resources reported for PL/SQL code includes the resources used by all SQL
       statements called by the code.
    -> % Total DB Time is the Elapsed Time of the SQL statement divided
       into the Total Database Time multiplied by 100
      Elapsed      CPU                  Elap per  % Total
      Time (s)   Time (s)  Executions   Exec (s)  DB Time    SQL Id
        13,664        906            0        N/A    95.6 gr2cx6athc5j5
    Module: SQL*Plus
    BEGIN DBMS_OUTPUT.PUT_LINE(equiduct.eod(NULL,NULL)); END;
         8,792        195            0        N/A    61.5 986fzxtzr52u5
    Module: SQL*Plus
    UPDATE TIBEX_ORDER SET INSTRUMENTID=:"SYS_B_0" WHERE INSTRUMENTID=:"SYS_B_1"
         2,524        368            1     2524.1    17.7 c4uf0x6hdgnwq
    Module: SQL*Plus
    UPDATE TIBEX_FIXSESSIONSTATE SET INSTRUMENTID=:"SYS_B_0" WHERE INSTRUMENTID=:"
    SYS_B_1"
         1,414        177            1     1414.4     9.9 cbg09ma34kq8w
    Module: SQL*Plus
    SELECT count(*) FROM TIBEX_ORDER WHERE INSTRUMENTID=:"SYS_B_0"
           742        137            1      742.2     5.2 g0sg6v994wssq
    Module: SQL*Plus
    SELECT count(*) FROM TIBEX_FIXSESSIONSTATE WHERE INSTRUMENTID=:"SYS_B_0"
           274         11            1      274.2     1.9 6mcpb06rctk0x
    Module: DBMS_SCHEDULER
    call dbms_space.auto_space_advisor_job_proc ( )
           264          8           27        9.8     1.8 8szmwam7fysa3
    Module: DBMS_SCHEDULER
    insert into wri$_adv_objspace_trend_data select timepoint, space_usage, space_a
    lloc, quality from table(dbms_space.object_growth_trend(:1, :2, :3, :4, NULL, N
    ULL, NULL, 'FALSE', :5, 'FALSE'))
            99          1            1       99.4     0.7 1z0x41f66nvjr
    Module: SQL*Plus
    UPDATE TIBEX_INSTRUMENTADMIN SET INSTRUMENTID=:"SYS_B_0" WHERE INSTRUMENTID=:"
    SYS_B_1"
            21         10            1       21.5     0.2 bbc1ck8594kvj
    Module: SQL*Plus
    UPDATE TIBEX_INSTRUMENTDAILYHIST SET ADJOPEN=NVL(ADJOPEN,OPEN), ADJHIGH=NVL(ADJH
    IGH,HIGH), ADJLOW=NVL(ADJLOW,LOW), ADJMID=NVL(ADJMID,MID), ADJCLOSE=NVL(ADJCLOSE
    ,CLOSE), ADJVOLUME=NVL(ADJVOLUME,VOLUME), ADJCLOSINGBID=NVL(ADJCLOSINGBID,CLOSIN
    GBID), ADJCLOSINGOFFER=NVL(ADJCLOSINGOFFER,CLOSINGOFFER)
            12          0            1       12.5     0.1 6xm9p9uy5kaap
    Module: SQL*Plus
    SELECT count(*) FROM TIBEX_INSTRUMENTSTATE WHERE INSTRUMENTID=:"SYS_B_0"
    SQL ordered by CPU Time              DB/Inst: SURV2/SURV2  Snaps: 19172-19178
    -> Resources reported for PL/SQL code includes the resources used by all SQL
       statements called by the code.
    -> % Total DB Time is the Elapsed Time of the SQL statement divided
       into the Total Database Time multiplied by 100
        CPU      Elapsed                  CPU per  % Total
      Time (s)   Time (s)  Executions     Exec (s) DB Time    SQL Id
           906     13,664            0         N/A    95.6 gr2cx6athc5j5
    Module: SQL*Plus
    BEGIN DBMS_OUTPUT.PUT_LINE(equiduct.eod(NULL,NULL)); END;
           368      2,524            1      367.51    17.7 c4uf0x6hdgnwq
    Module: SQL*Plus
    UPDATE TIBEX_FIXSESSIONSTATE SET INSTRUMENTID=:"SYS_B_0" WHERE INSTRUMENTID=:"
    SYS_B_1"
           195      8,792            0         N/A    61.5 986fzxtzr52u5
    Module: SQL*Plus
    UPDATE TIBEX_ORDER SET INSTRUMENTID=:"SYS_B_0" WHERE INSTRUMENTID=:"SYS_B_1"
           177      1,414            1      176.93     9.9 cbg09ma34kq8w
    Module: SQL*Plus
    SELECT count(*) FROM TIBEX_ORDER WHERE INSTRUMENTID=:"SYS_B_0"
           137        742            1      137.38     5.2 g0sg6v994wssq
    Module: SQL*Plus
    SELECT count(*) FROM TIBEX_FIXSESSIONSTATE WHERE INSTRUMENTID=:"SYS_B_0"
            11        274            1       10.82     1.9 6mcpb06rctk0x
    Module: DBMS_SCHEDULER
    call dbms_space.auto_space_advisor_job_proc ( )
            10         21            1        9.65     0.2 bbc1ck8594kvjEdited by: NM on 10-Sep-2010 07:39

    Hi,
    Last night we had issue with one of the prod server where we updating one of table which contains large number records in millions.Same identical machine completed in1 hour and other box never completed but doing db file sequential read but in the long ops the last statement it was done 20:16 after that nothing is happening but i ran few trace on that user.
    /u01/app/oracle/admin/SURV2/udump/surv2_ora_10048.trc
    Oracle Database 10g Release 10.2.0.4.0 - Production
    ORACLE_HOME = /u01/app/oracle/product/10.2.0/db
    System name:     SunOS
    Node name:     prdfa001
    Release:     5.10
    Version:     Generic_139556-08
    Machine:     i86pc
    Instance name: SURV2
    Redo thread mounted by this instance: 1
    Oracle process number: 18
    Unix process pid: 10048, image: oracle@prdfa001
    *** 2010-09-09 23:37:07.484
    *** ACTION NAME:() 2010-09-09 23:37:07.473
    *** MODULE NAME:(SQL*Plus) 2010-09-09 23:37:07.473
    *** SERVICE NAME:(SURV2) 2010-09-09 23:37:07.473
    *** SESSION ID:(289.54) 2010-09-09 23:37:07.473
    Received ORADEBUG command 'unlimit' from process Unix process pid: 3983, image:
    *** 2010-09-09 23:37:20.315
    Received ORADEBUG command 'event 10046 trace name context forever, level 12' from process Unix process pid: 3983, image:
    WAIT #7: nam='db file sequential read' ela= 11160 file#=13 block#=2252349 blocks=1 obj#=166421 tim=12499462835161
    WAIT #7: nam='db file sequential read' ela= 2857 file#=13 block#=2249751 blocks=1 obj#=166421 tim=12499462838137
    WAIT #7: nam='db file sequential read' ela= 3810 file#=13 block#=2251361 blocks=1 obj#=166421 tim=12499462842048
    WAIT #7: nam='db file sequential read' ela= 4459 file#=13 block#=2247059 blocks=1 obj#=166421 tim=12499462846564
    WAIT #7: nam='db file sequential read' ela= 2841 file#=13 block#=2247507 blocks=1 obj#=166421 tim=12499462849468
    WAIT #7: nam='db file sequential read' ela= 427 file#=13 block#=2247568 blocks=1 obj#=166421 tim=12499462850032
    WAIT #7: nam='db file sequential read' ela= 1187 file#=13 block#=2248264 blocks=1 obj#=166421 tim=12499462851327
    WAIT #7: nam='db file sequential read' ela= 2687 file#=13 block#=2250707 blocks=1 obj#=166421 tim=12499462854178
    WAIT #7: nam='db file sequential read' ela= 3657 file#=13 block#=2249697 blocks=1 obj#=166421 tim=12499462857896
    WAIT #7: nam='db file sequential read' ela= 4139 file#=13 block#=2247074 blocks=1 obj#=166421 tim=12499462862093
    WAIT #7: nam='db file sequential read' ela= 4180 file#=47 block#=3649690 blocks=1 obj#=166421 tim=12499509270445
    WAIT #7: nam='db file sequential read' ela= 4802 file#=47 block#=3649309 blocks=1 obj#=166421 tim=12499509275327
    WAIT #7: nam='db file sequential read' ela= 2459 file#=47 block#=3652697 blocks=1 obj#=166421 tim=12499509277859
    WAIT #7: nam='db file sequential read' ela= 4015 file#=47 block#=3652826 blocks=1 obj#=166421 tim=12499509281948
    WAIT #7: nam='db file sequential read' ela= 2248 file#=47 block#=3651610 blocks=1 obj#=166421 tim=12499509284269
    WAIT #7: nam='db file sequential read' ela= 4824 file#=47 block#=3654297 blocks=1 obj#=166421 tim=12499509289166
    WAIT #7: nam='db file sequential read' ela= 2008 file#=47 block#=3652312 blocks=1 obj#=166421 tim=12499509291248
    WAIT #7: nam='db file sequential read' ela= 1925 file#=47 block#=3654490 blocks=1 obj#=166421 tim=12499509293246
    WAIT #7: nam='db file sequential read' ela= 2859 file#=47 block#=3648458 blocks=1 obj#=166421 tim=12499509296178
    WAIT #7: nam='db file sequential read' ela= 1740 file#=47 block#=3648212 blocks=1 obj#=166421 tim=12499509297991
    WAIT #7: nam='db file sequential read' ela= 2566 file#=47 block#=3648411 blocks=1 obj#=166421 tim=12499509300631
    WAIT #7: nam='db file sequential read' ela= 50772 file#=5 block#=480749 blocks=1 obj#=166421 tim=12499509351477
    WAIT #7: nam='db file sequential read' ela= 12928 file#=5 block#=477177 blocks=1 obj#=166421 tim=12499509364482
    WAIT #7: nam='db file sequential read' ela= 11116 file#=5 block#=479412 blocks=1 obj#=166421 tim=12499509375672
    WAIT #7: nam='db file sequential read' ela= 4803 file#=5 block#=483440 blocks=1 obj#=166421 tim=12499509380549
    WAIT #7: nam='db file sequential read' ela= 6900 file#=5 block#=481454 blocks=1 obj#=166421 tim=12499509387522
    Received ORADEBUG command 'event 10046 trace name context off' from process Unix process pid: 3983, image:
    /u01/app/oracle/admin/SURV2/udump/surv2_ora_1545.trc
    Oracle Database 10g Release 10.2.0.4.0 - Production
    ORACLE_HOME = /u01/app/oracle/product/10.2.0/db
    System name:     SunOS
    Node name:     prdfa001
    Release:     5.10
    Version:     Generic_139556-08
    Machine:     i86pc
    Instance name: SURV2
    Redo thread mounted by this instance: 1
    Oracle process number: 22
    Unix process pid: 1545, image: oracle@prdfa001 (TNS V1-V3)
    *** ACTION NAME:() 2010-09-09 23:20:13.485
    *** MODULE NAME:(sqlplus@prdfa001 (TNS V1-V3)) 2010-09-09 23:20:13.485
    *** SERVICE NAME:(SYS$USERS) 2010-09-09 23:20:13.485
    *** SESSION ID:(290.697) 2010-09-09 23:20:13.485
    ===================================================
    SYSTEM STATE
    System global information:
         processes: base 47819b480, size 300, cleanup 4781a5638
         allocation: free sessions 47f1d6148, free calls 0
         control alloc errors: 0 (process), 0 (session), 0 (call)
         PMON latch cleanup depth: 0
         seconds since PMON's last scan for dead processes: 20
         system statistics:
    1171 logons cumulative
    19 logons current
    89219 opened cursors cumulative
    86 opened cursors current
    15095069 user commits
    5 user rollbacks
    58632904 user calls
    44023255 recursive calls
    224311 recursive cpu usage
    201424173 session logical reads
    0 session stored procedure space
    901812 CPU used when call started
    995437 CPU used by this session
    6814196 DB time
    0 cluster wait time
    22542300822 concurrency wait time
    3095 application wait time
    16479074661 user I/O wait time
    1284052668 session connect time
    1284067190 process last non-idle time
    189018343568 session uga memory
    1249667216 session uga memory max
    26059216 messages sent
    26059220 messages received
    239739 background timeouts
    162399896 session pga memory
    189662872 session pga memory max
    4 enqueue timeouts
    901146 enqueue waits
    0 enqueue deadlocks
    32122711 enqueue requests
    17819 enqueue conversions
    32122676 enqueue releases
    0 global enqueue gets sync
    0 global enqueue gets async
    0 global enqueue get time
    0 global enqueue releases
    2865667 physical read total IO requests
    262620 physical read total multi block requests
    270093476864 physical read total bytes
    select SYS_CONTEXT('USERENV', 'SERVER_HOST'), SYS_CONTEXT('USERENV', 'DB_UNIQUE_NAME'), SYS_CONTEXT('USERENV', 'INSTANCE_NAME'), SYS_CONTEXT('USERENV', 'SERVICE_NAME'), INSTANCE_NUMBER, STARTUP_TIME, SYS_CONTEXT('USERENV', 'DB_DOMAIN') from v$instance where INSTANCE_NAME=SYS_CONTEXT('USERENV', 'INSTANCE_NAME')
          hash=550c95f3d0cfa8290e60ea8382d3a2ca timestamp=09-09-2010 04:24:19
          namespace=CRSR flags=RON/KGHP/TIM/PN0/LRG/KST/DBN/MTX/[100100d1]
          kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=9 hpc=0582 hlc=0582
          lwt=47df576e8[47df576e8,47df576e8] ltm=47df576f8[47df576f8,47df576f8]
          pwt=47df576b0[47df576b0,47df576b0] ptm=47df576c0[47df576c0,47df576c0]
          ref=47df57718[47df57718,47df57718] lnd=47df57730[47df57730,47df57730]
            LIBRARY OBJECT: object=471ee1d38
            type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
            CHILDREN: size=16
            child#    table reference   handle
                 0 471ee1800 471ee1470 47df7dce0
            DATA BLOCKS:
            data#     heap  pointer    status pins change whr
                0 47df7de48 471ee1e50 I/P/A/-/-    0 NONE   00
          SO: 473691d60, type: 53, owner: 47924e810, flag: INIT/-/-/0x00
          LIBRARY OBJECT LOCK: lock=473691d60 handle=47bb22fa0 mode=N
          call pin=0 session pin=0 hpc=0000 hlc=0000
          htl=473691de0[4735dbcb8,476cfbf58] htb=476cfbf58 ssga=476cfb6a0
          user=47924e810 session=47f2310f0 count=1 flags=[0000] savepoint=0x0
          LIBRARY OBJECT HANDLE: handle=47bb22fa0 mtx=47bb230d0(0) cdp=0
          namespace=CRSR flags=RON/KGHP/PN0/EXP/[10010100]
          kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=3 hpc=fd84 hlc=fd84
          lwt=47bb23048[47bb23048,47bb23048] ltm=47bb23058[47bb23058,47bb23058]
          pwt=47bb23010[47bb23010,47bb23010] ptm=47bb23020[47bb23020,47bb23020]
          ref=47bb23078[472f8de18,472f8de18] lnd=47bb23090[47bb23090,47bb23090]
            LIBRARY OBJECT: object=472f8d9d8
            type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
            DEPENDENCIES: count=1 size=16
            AUTHORIZATIONS: count=1 size=16 minimum entrysize=16
            ACCESSES: count=1 size=16
            TRANSLATIONS: count=1 size=16
            DATA BLOCKS:
            data#     heap  pointer    status pins change whr
                0 47bb22ee0 472f8daf0 I/P/A/-/-    0 NONE   00
                6 472f8e508 46be86250 I/-/A/-/E    0 NONE   00
          SO: 4735dbc38, type: 53, owner: 47924e810, flag: INIT/-/-/0x00
          LIBRARY OBJECT LOCK: lock=4735dbc38 handle=47bb231c8 mode=N
          call pin=0 session pin=0 hpc=0000 hlc=0000
          htl=4735dbcb8[476cfbf58,473691de0] htb=476cfbf58 ssga=476cfb6a0
          user=47924e810 session=47f2310f0 count=1 flags=[0000] savepoint=0x4c894f8b
          LIBRARY OBJECT HANDLE: handle=47bb231c8 mtx=47bb232f8(1) cdp=1
          name=select value$ from props$ where name = 'GLOBAL_DB_NAME'
          hash=4bb432d65c5a391a42a5c3fa74472c7a timestamp=09-09-2010 04:24:12
          namespace=CRSR flags=RON/KGHP/TIM/PN0/SML/KST/DBN/MTX/[120100d0]
          kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=3 hpc=0584 hlc=0584
          lwt=47bb23270[47bb23270,47bb23270] ltm=47bb23280[47bb23280,47bb23280]
          pwt=47bb23238[47bb23238,47bb23238] ptm=47bb23248[47bb23248,47bb23248]
          ref=47bb232a0[47bb232a0,47bb232a0] lnd=47bb232b8[47bb232b8,47bb232b8]
            LIBRARY OBJECT: object=472f8e6e0
            type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
            CHILDREN: size=16
            child#    table reference   handle
                 0 472f8e1a8 472f8de18 47bb22fa0
            DATA BLOCKS:
            data#     heap  pointer    status pins change whr
                0 47bb23108 472f8e7f8 I/P/A/-/-    0 NONE   00
          SO: 473644348, type: 53, owner: 47924e810, flag: INIT/-/-/0x00
          LIBRARY OBJECT LOCK: lock=473644348 handle=47bbde418 mode=N
          call pin=0 session pin=0 hpc=0000 hlc=0000
          htl=4736443c8[476cfc0b8,476cfc0b8] htb=476cfc0b8 ssga=476cfb6a0
          user=47924e810 session=47924e810 count=1 flags=[0000] savepoint=0x4c894f8b
          LIBRARY OBJECT HANDLE: handle=47bbde418 mtx=47bbde548(0) cdp=0
          name=ALTER SESSION SET TIME_ZONE='+02:00'
          hash=3878dff8839e71e3dd05a2e75fbd6390 timestamp=09-09-2010 04:24:04
          namespace=CRSR flags=RON/KGHP/TIM/PN0/SML/DBN/[12010040]
          kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=11 hpc=04e8 hlc=04e8
          lwt=47bbde4c0[47bbde4c0,47bbde4c0] ltm=47bbde4d0[47bbde4d0,47bbde4d0]
          pwt=47bbde488[47bbde488,47bbde488] ptm=47bbde498[47bbde498,47bbde498]
          ref=47bbde4f0[47bbde4f0,47bbde4f0] lnd=47bbde508[47bbde508,47bbde508]
            LIBRARY OBJECT: object=472fffc08
            type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
            DATA BLOCKS:
            data#     heap  pointer    status pins change whr
                0 47bbde320 472fffd20 I/P/A/-/-    0 NONE   00
          SO: 47aecf9e8, type: 41, owner: 47924e810, flag: INIT/-/-/0x00
          (dummy) nxc=0, nlb=0  
        SO: 47f290540, type: 11, owner: 4781a7dc0, flag: INIT/-/-/0x00
        (broadcast handle) flag: (2) ACTIVE SUBSCRIBER, owner: 4781a7dc0,
                           event: 1132, last message event: 1132,
                           last message waited event: 1132,                        next message: 0(0), messages read: 0
                           channel: (47a2df4f8) system events broadcast channel
                                    scope: 2, event: 1132, last mesage event: 18,
                                    publishers/subscribers: 0/17,
                                    messages published: 1
        SO: 47826b228, type: 3, owner: 4781a7dc0, flag: INIT/-/-/0x00
        (call) sess: cur 47924e810, rec 0, usr 47924e810; depth: 0
        SO: 476c52968, type: 16, owner: 4781a7dc0, flag: INIT/-/-/0x00
        (osp req holder)
    PSEUDO PROCESS for group DEFAULT:
      SO: 47a1eb7d0, type: 2, owner: 0, flag: INIT/-/-/0x00
      (process) Oracle pid=0, calls cur/top: 0/0, flag: (20) PSEUDO
                int error: 0, call error: 0, sess error: 0, txn error 0
      (post info) last post received: 0 0 0
                  last post received-location: No post
                  last process to post me: none
                  last post sent: 0 0 0
                  last post sent-location: No post
                  last process posted by me: none
        (latch info) wait_event=0 bits=0
        Process Group: DEFAULT, pseudo proc: 47a1eb7d0
        O/S info: user: , term: , ospid:  (DEAD)
        OSD pid info: Unix process pid: 0, image: PSEUDO
    Dump of memory from 0x00000004791BF538 to 0x00000004791BF740
    4791BF530                   00000000 00000000          [........]
    4791BF540 00000000 00000000 00000000 00000000  [................]
      Repeat 31 times
    NO DETACHED BRANCHES.
    NO DETACHED NETWORK CONNECTIONS.
    CLEANUP STATE OBJECTS:
    SO: 47f0cd038, type: 1, owner: 0, flag: INIT/-/-/0x00
    (cleanup state object) description: instance enqueue anchor state
    latch: 0x380009890
      SO: 4782cf080, type: 5, owner: 47f0cd038, flag: INIT/-/-/0x00
      (enqueue) TA-00000006-00000001     DID: 0001-000F-0000000B
      lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  res_flag: 0x2
      res: 0x47a28d020, mode: X, lock_flag: 0x0
      own: 0x0, sess: 0x0, prv: 0x47a28d030
    SO: 47f0cd098, type: 1, owner: 0, flag: INIT/-/-/0x00
    (cleanup state object) description: switchable channel handle anch
    latch: 0x38000ac98
      SO: 47f28f868, type: 11, owner: 47f0cd098, flag: INIT/-/-/0x00
      (broadcast handle) flag: (c2) ACTIVE SUBSCRIBER, owner: 0,
                         event: 1, last message event: 1,
                         last message waited event: 1,                      next message: 0(0), messages read: 0
                         channel: (47a2e4190) KPON channel
                                  scope: 2, event: 1, last mesage event: 0,
                                  publishers/subscribers: 0/1,
                                  messages published: 0
    SO: 47f0cd0f8, type: 1, owner: 0, flag: INIT/-/-/0x00
    (cleanup state object) description: TT shared object cleanup SO
    latch: 0x38001c6b8
    SO: 47f0cd158, type: 1, owner: 0, flag: INIT/-/-/0x00
    (cleanup state object) description: SS shared object cleanup SO
    latch: 0x38001cd48
    END OF SYSTEM STATE
    Top 5 Timed Events                                         Avg %Total
    ~~~~~~~~~~~~~~~~~~                                        wait   Call
    Event                                 Waits    Time (s)   (ms)   Time Wait Class
    db file sequential read           2,347,652       9,215      4   64.5   User I/O
    db file scattered read              245,687       4,199     17   29.4   User I/O
    CPU time                                            974           6.8
    db file parallel write               50,082         408      8    2.9 System I/O
    log file parallel write               6,963          52      7    0.4 System I/O
    Time Model Statistics                DB/Inst: SURV2/SURV2  Snaps: 19172-19178
    -> Total time in database user-calls (DB Time): 14286.4s
    -> Statistics including the word "background" measure background process
       time, and so do not contribute to the DB time statistic
    -> Ordered by % or DB time desc, Statistic name
    Statistic Name                                       Time (s) % of DB Time
    sql execute elapsed time                             14,280.3        100.0
    DB CPU                                                  974.5          6.8
    PL/SQL execution elapsed time                           531.8          3.7
    parse time elapsed                                       30.5           .2
    hard parse elapsed time                                  27.1           .2
    connection management call elapsed time                  14.9           .1
    hard parse (sharing criteria) elapsed time                3.4           .0
    hard parse (bind mismatch) elapsed time                   3.1           .0
    PL/SQL compilation elapsed time                           2.4           .0
    failed parse elapsed time                                 0.0           .0
    repeated bind elapsed time                                0.0           .0
    sequence load elapsed time                                0.0           .0
    DB time                                              14,286.4          N/A
    background elapsed time                                 670.2          N/A
    background cpu time                                     186.1          N/A
    Wait Class                            DB/Inst: SURV2/SURV2  Snaps: 19172-19178
    -> s  - second
    -> cs - centisecond -     100th of a second
    -> ms - millisecond -    1000th of a second
    -> us - microsecond - 1000000th of a second
    -> ordered by wait time desc, waits desc
                                                                      Avg
                                           %Time       Total Wait    wait     Waits
    Wait Class                      Waits  -outs         Time (s)    (ms)      /txn
    User I/O                    2,593,484     .0           13,415       5     150.0
    System I/O                     87,506     .0              515       6       5.1
    Other                             839   11.4                6       7       0.0
    Commit                          3,225     .1                6       2       0.2
    Concurrency                     1,033     .0                5       5       0.1
    Configuration                   2,514   99.4                0       0       0.1
    Network                        47,559     .0                0       0       2.8
    Application                         7     .0                0       0       0.0
    Wait Events                          DB/Inst: SURV2/SURV2  Snaps: 19172-19178
    -> s  - second
    -> cs - centisecond -     100th of a second
    -> ms - millisecond -    1000th of a second
    -> us - microsecond - 1000000th of a second
    -> ordered by wait time desc, waits desc (idle events last)
                                                                       Avg
                                                 %Time  Total Wait    wait     Waits
    Event                                 Waits  -outs    Time (s)    (ms)      /txn
    db file sequential read           2,347,652     .0       9,215       4     135.8
    db file scattered read              245,687     .0       4,199      17      14.2
    db file parallel write               50,082     .0         408       8       2.9
    log file parallel write               6,963     .0          52       7       0.4
    control file parallel write           6,203     .0          44       7       0.4
    control file sequential read         24,242     .0          11       0       1.4
    log file sync                         3,225     .1           6       2       0.2
    latch free                               84     .0           4      47       0.0
    os thread startup                        25     .0           3     120       0.0
    latch: session allocation                39     .0           1      33       0.0
    db file parallel read                    12     .0           1      92       0.0
    enq: TX - index contention              186     .0           1       3       0.0
    latch: shared pool                       47     .0           1      11       0.0
    LGWR wait for redo copy                 319    3.1           0       1       0.0
    library cache load lock                   2     .0           0     172       0.0
    buffer busy waits                       590     .0           0       0       0.0
    log file switch completion                6     .0           0      29       0.0
    SGA: allocation forcing comp             11   54.5           0      14       0.0
    latch: library cache lock                50     .0           0       3       0.0
    read by other session                    38     .0           0       4       0.0
    direct path read                         42     .0           0       3       0.0
    SQL*Net message to client            44,807     .0           0       0       2.6
    rdbms ipc reply                         207     .0           0       0       0.0
    SQL*Net more data from clien          1,014     .0           0       0       0.1
    latch: cache buffers chains              24     .0           0       1       0.0
    latch: library cache                     29     .0           0       1       0.0
    log file sequential read                  8     .0           0       3       0.0
    direct path write                        50     .0           0       0       0.0
    SQL*Net more data to client             398     .0           0       0       0.0
    latch: object queue header o             12     .0           0       1       0.0
    latch: In memory undo latch              78     .0           0       0       0.0
    undo segment extension                2,507   99.7           0       0       0.1
    latch: cache buffers lru cha              4     .0           0       1       0.0
    log file single write                     8     .0           0       0       0.0
    local write wait                          3     .0           0       1       0.0
    enq: RO - fast object reuse               3     .0           0       1       0.0
    buffer deadlock                          87   92.0           0       0       0.0
    enq: JS - queue lock                      1     .0           0       1       0.0
    cursor: pin S                            70     .0           0       0       0.0
    latch: row cache objects                  2     .0           0       1       0.0
    SQL*Net message to dblink             1,338     .0           0       0       0.1
    latch: checkpoint queue latc              2     .0           0       0       0.0
    reliable message                          3     .0           0       0       0.0
    log buffer space                          1     .0           0       1       0.0
    SQL*Net break/reset to clien              4     .0           0       0       0.0
    SQL*Net more data from dblin              2     .0           0       0       0.0
    SQL*Net message from client          44,949     .0     155,701    3464       2.6
    virtual circuit status                  621  100.0      18,156   29237       0.0
    Streams AQ: qmn slave idle w            664     .0      18,127   27299       0.0
    Streams AQ: qmn coordinator           1,339   50.4      18,099   13517       0.1
    Streams AQ: waiting for time             12  100.0       8,741  728394       0.0
    jobq slave wait                         130  100.0         380    2927       0.0
    PL/SQL lock timer                         1  100.0           1     978       0.0
    SQL*Net message from dblink           1,338     .0           0       0       0.1
    single-task message                       1     .0           0      38       0.0
    class slave wait                         11     .0           0       1       0.0
    SQL ordered by Elapsed Time          DB/Inst: SURV2/SURV2  Snaps: 19172-19178
    -> Resources reported for PL/SQL code includes the resources used by all SQL
       statements called by the code.
    -> % Total DB Time is the Elapsed Time of the SQL statement divided
       into the Total Database Time multiplied by 100
      Elapsed      CPU                  Elap per  % Total
      Time (s)   Time (s)  Executions   Exec (s)  DB Time    SQL Id
        13,664        906            0        N/A    95.6 gr2cx6athc5j5
    Module: SQL*Plus
    BEGIN DBMS_OUTPUT.PUT_LINE(equiduct.eod(NULL,NULL)); END;
         8,792        195            0        N/A    61.5 986fzxtzr52u5
    Module: SQL*Plus
    UPDATE TIBEX_ORDER SET INSTRUMENTID=:"SYS_B_0" WHERE INSTRUMENTID=:"SYS_B_1"
         2,524        368            1     2524.1    17.7 c4uf0x6hdgnwq
    Module: SQL*Plus
    UPDATE TIBEX_FIXSESSIONSTATE SET INSTRUMENTID=:"SYS_B_0" WHERE INSTRUMENTID=:"
    SYS_B_1"
         1,414        177            1     1414.4     9.9 cbg09ma34kq8w
    Module: SQL*Plus
    SELECT count(*) FROM TIBEX_ORDER WHERE INSTRUMENTID=:"SYS_B_0"
           742        137            1      742.2     5.2 g0sg6v994wssq
    Module: SQL*Plus
    SELECT count(*) FROM TIBEX_FIXSESSIONSTATE WHERE INSTRUMENTID=:"SYS_B_0"
           274         11            1      274.2     1.9 6mcpb06rctk0x
    Module: DBMS_SCHEDULER
    call dbms_space.auto_space_advisor_job_proc ( )
           264          8           27        9.8     1.8 8szmwam7fysa3
    Module: DBMS_SCHEDULER
    insert into wri$_adv_objspace_trend_data select timepoint, space_usage, space_a
    lloc, quality from table(dbms_space.object_growth_trend(:1, :2, :3, :4, NULL, N
    ULL, NULL, 'FALSE', :5, 'FALSE'))
            99          1            1       99.4     0.7 1z0x41f66nvjr
    Module: SQL*Plus
    UPDATE TIBEX_INSTRUMENTADMIN SET INSTRUMENTID=:"SYS_B_0" WHERE INSTRUMENTID=:"
    SYS_B_1"
            21         10            1       21.5     0.2 bbc1ck8594kvj
    Module: SQL*Plus
    UPDATE TIBEX_INSTRUMENTDAILYHIST SET ADJOPEN=NVL(ADJOPEN,OPEN), ADJHIGH=NVL(ADJH
    IGH,HIGH), ADJLOW=NVL(ADJLOW,LOW), ADJMID=NVL(ADJMID,MID), ADJCLOSE=NVL(ADJCLOSE
    ,CLOSE), ADJVOLUME=NVL(ADJVOLUME,VOLUME), ADJCLOSINGBID=NVL(ADJCLOSINGBID,CLOSIN
    GBID), ADJCLOSINGOFFER=NVL(ADJCLOSINGOFFER,CLOSINGOFFER)
            12          0            1       12.5     0.1 6xm9p9uy5kaap
    Module: SQL*Plus
    SELECT count(*) FROM TIBEX_INSTRUMENTSTATE WHERE INSTRUMENTID=:"SYS_B_0"
    SQL ordered by CPU Time              DB/Inst: SURV2/SURV2  Snaps: 19172-19178
    -> Resources reported for PL/SQL code includes the resources used by all SQL
       statements called by the code.
    -> % Total DB Time is the Elapsed Time of the SQL statement divided
       into the Total Database Time multiplied by 100
        CPU      Elapsed                  CPU per  % Total
      Time (s)   Time (s)  Executions     Exec (s) DB Time    SQL Id
           906     13,664            0         N/A    95.6 gr2cx6athc5j5
    Module: SQL*Plus
    BEGIN DBMS_OUTPUT.PUT_LINE(equiduct.eod(NULL,NULL)); END;
           368      2,524            1      367.51    17.7 c4uf0x6hdgnwq
    Module: SQL*Plus
    UPDATE TIBEX_FIXSESSIONSTATE SET INSTRUMENTID=:"SYS_B_0" WHERE INSTRUMENTID=:"
    SYS_B_1"
           195      8,792            0         N/A    61.5 986fzxtzr52u5
    Module: SQL*Plus
    UPDATE TIBEX_ORDER SET INSTRUMENTID=:"SYS_B_0" WHERE INSTRUMENTID=:"SYS_B_1"
           177      1,414            1      176.93     9.9 cbg09ma34kq8w
    Module: SQL*Plus
    SELECT count(*) FROM TIBEX_ORDER WHERE INSTRUMENTID=:"SYS_B_0"
           137        742            1      137.38     5.2 g0sg6v994wssq
    Module: SQL*Plus
    SELECT count(*) FROM TIBEX_FIXSESSIONSTATE WHERE INSTRUMENTID=:"SYS_B_0"
            11        274            1       10.82     1.9 6mcpb06rctk0x
    Module: DBMS_SCHEDULER
    call dbms_space.auto_space_advisor_job_proc ( )
            10         21            1        9.65     0.2 bbc1ck8594kvjEdited by: NM on 10-Sep-2010 07:39

  • Possible Sequential Read Access for a Sorted Table

    Hi All,
    I have the following warnings in Code inspector check.
    'Possible Sequential Read Access for a Sorted Table'
    Kindly provide me the solution to overcome this warning message.
    This is my code in BAdi : CRM_ORDER_FIELDCHECK , Method : FIELDCHECK
    I am getting the above warning at
      READ TABLE lt_status INTO ls_status WITH KEY status = 'E0001'
                                                   user_stat_proc = 'ZITRHDQT'
                                                   object_type = 'BUS2000114'.
    and at
        MODIFY ct_input_field_names FROM ls_input_field_names
                                    TRANSPORTING changeable
                                    WHERE fieldname NE lv_field.
    Please see the below code .
      DATA : lt_header_guid TYPE crmt_object_guid_tab,
             lt_item_guid TYPE crmt_object_guid_tab,
             lt_order_i     TYPE crmt_orderadm_i_wrkt,
             ls_order_i     LIKE LINE OF lt_order_i,
             lt_status      TYPE crmt_status_wrkt,
             ls_status      LIKE LINE OF lt_status,
             ls_input_field_names  TYPE crmt_input_field_names.
      DATA : lv_header_guid TYPE crmt_fieldcheck_com-guid,
             lv_chng_no   TYPE c VALUE 'A',
             lv_field(10)  TYPE c VALUE 'ACT_STATUS'.
      DATA: lv_status_completed     TYPE crmt_boolean.
    To Get GUID
      IF is_fieldcheck_com-guid IS NOT INITIAL.
        lv_header_guid = is_fieldcheck_com-guid.
      ELSE.
        lv_header_guid = is_fieldcheck_com-ref_guid.
      ENDIF.
      IF is_fieldcheck_com-ref_kind EQ 'A'.
        INSERT lv_header_guid INTO TABLE lt_header_guid.
        ELSE.
          SELECT SINGLE header FROM crmd_orderadm_i INTO lv_header_guid
                                WHERE guid = is_fieldcheck_com-ref_guid.
          INSERT lv_header_guid INTO TABLE lt_header_guid.
      ENDIF.
    *To Get the required details
      CALL FUNCTION 'CRM_ORDER_READ'
        EXPORTING
          it_header_guid       = lt_header_guid
        IMPORTING
          et_status            = lt_status
        EXCEPTIONS
          document_not_found   = 1
          error_occurred       = 2
          document_locked      = 3
          no_change_authority  = 4
          no_display_authority = 5
          no_change_allowed    = 6
          OTHERS               = 7.
      IF sy-subrc <> 0.
    MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
            WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
      ENDIF.
      READ TABLE lt_status INTO ls_status WITH KEY status = 'E0001'
                                                   user_stat_proc = 'ZITRHDQT'
                                                   object_type = 'BUS2000114'.
      IF sy-subrc = 0.
        ls_input_field_names-changeable = lv_chng_no.
        MODIFY ct_input_field_names FROM ls_input_field_names
                                    TRANSPORTING changeable
                                    WHERE fieldname NE lv_field.
      ENDIF.
    ENDMETHOD.
    Regards
    Venkat

    Hello Blake,
    Try this:
    READ TABLE lt_action_fld WITH KEY STATUS = '0' BINARY SEARCH.
    wf_index = sy-tabix.
    loop at lt_action_fld from wf_index.
    if lt_action_fld-status ne '0'.
    exit.
    endif.
    delete lt_action_fld index wf_index.
    endloop.
    Let us know, if this helps.
    Rgds,
    Raghu.

  • 0FI_AR_4 - Slow Sequential Read in ECC on Initial Load

    Hi everyone,
    We are using DataSource 0FI_AR_4. Our plug-in is PI2004.1.500. Support
    pack level is 18. When we execute the initialisation from BW then we
    experience poor run times against table BSAD. Through SM50 in ECC we
    can see that this is doing a sequential read on view BKPF_BSAD as per
    below. We have reviewed notes 641977, 760973 and 798536 and created
    index 6 as instructed. This has made no difference.
    The DataSource only allows us to select on Company Code and Fiscal
    Year/Period so we can understand why the extract would be slow as the ECC read uses BUDAT and CPUDT. Unless the Fiscal Year/Period is somehow translated to BUDAT.
    An extract of 80000 records takes 1hr 10 mins. We may have 4 to 5 million records to load.
    Has anyone come across this problem before?
    SELECT
    "AUGBL" , "AUGDT" , "BELNR" , "BLART" , "BLDAT" , "BSCHL" , "BSTAT" ,
    "BUDAT" , "BUKRS" , "BUZEI" ,
    "CPUDT" , "DMBTR" , "FILKD" , "GJAHR" , "HKONT" , "KKBER" , "KUNNR" ,
    "MABER" , "MADAT" , "MANSP" ,
    "MANST" , "MONAT" , "MSCHL" , "REBZG" , "REBZJ" , "REBZZ" , "RSTGR" ,
    "SAKNR" , "SGTXT" , "SHKZG" ,
    "SKFBT" , "SKNTO" , "UMSKS" , "UMSKZ" , "VBELN" , "WAERS" , "WRBTR" ,
    "WSKTO" , "XARCH" , "XBLNR" ,
    "XNEGP" , "XREF1" , "XREF2" , "XREF3" , "ZBD1P" , "ZBD1T" , "ZBD2P" ,
    "ZBD2T" , "ZBD3T" , "ZFBDT" ,
    "ZLSCH" , "ZLSPR" , "ZTERM" , "ZUONR"
    FROM
    "BKPF_BSAD"
    WHERE
    "MANDT" = :A0 AND "BUKRS" IN ( :A1 , :A2 ) AND "BUDAT" BETWEEN :A3
    AND :A4 AND "CPUDT" BETWEEN :A5 AND
    :A6#

    Hi,
    you could try to trace the database access and check if the index is used for reading. Depending on that you can create an more appropriate index.
    Did you also activate index 5?
    Also an option would be to do paralell initializations based on company code.

  • Query Tuning (sequential read + direct path read/write temp)

    Following query takes nearly 10 minutes under 10.2.0.2 on WIN2K3 to execute but I am sure there would be an alternate to tune it further.
    Major waits are 'db file sequential read' and 'direct path read temp' in addition to 'direct path write temp'
    Increasing/tuning the work_area_policy/sort_area_size would help? moving the tables to faster disk would reduce PIO causing sequential read, query re-writing would prove to be helpful?.
    Below is the tkprof:
    SELECT
      P.PER_ID
      , CL.DESCR
      , P.ENG_NAME
      , P.ARA_NAME
      , P.NATION
      , P.ADDR
      , ('Mob:' || NVL(P.MOB, '') || ', Home:' || NVL(P.HOME, '') || ', Bus.:' || NVL(P.BUS, '') || ', Fax:' || NVL(P.FAX, '')) PHONE
      , SUM(CASE
              WHEN FT.FT_TYPE_FLG IN ('BS','BX','AD','AX') THEN FT.CUR_AMT
            ELSE 0
            END) BILL
      , SUM(CASE
              WHEN FT.FT_TYPE_FLG IN ('PS','PX') THEN FT.CUR_AMT * -1
            ELSE 0
            END) PAY
      , SUM(FT.CUR_AMT) DUE
      , SUM(CASE
              WHEN FT.FREEZE_DTTM > '03-JUN-08' THEN
                  CASE WHEN FT.FT_TYPE_FLG IN ('PS','PX') THEN FT.CUR_AMT * -1
                  ELSE 0
                  END
            ELSE 0
            END) PAY_02JUN
    FROM
      CI_FT FT
      , CI_SA SA 
      , CI_ACCT_CHAR AC
      , CI_CUST_CL_L CL
      , CI_ACCT A
      , CI_ACCT_PER AP
          SELECT
            P.PER_ID
            , (P.CITY || ', ' || P.STATE || ',' || P.COUNTRY) ADDR
            , MAX(DECODE(PP.PHONE_TYPE_CD, 'MOB         ', PP.PHONE)) MOB
            , MAX(DECODE(PP.PHONE_TYPE_CD, 'BUSN        ', PP.PHONE)) BUS
            , MAX(DECODE(PP.PHONE_TYPE_CD, 'HOME        ', PP.PHONE)) HOME
            , MAX(DECODE(PP.PHONE_TYPE_CD, 'FAX         ', PP.PHONE)) FAX
            , MAX(DECODE(PN.NAME_TYPE_FLG, 'PRIM', PN.ENTITY_NAME)) ENG_NAME
            , MAX(DECODE(PN.NAME_TYPE_FLG, 'ALT ', PN.ENTITY_NAME)) ARA_NAME
            , MAX(DECODE(PC.CHAR_TYPE_CD, 'NATION  ', PC.CHAR_VAL)) NATION
          FROM
            CI_PER P
            , CI_PER_PHONE PP
            , CI_PER_NAME PN
            , CI_PER_CHAR PC
          WHERE
            P.PER_ID = PP.PER_ID (+)
          AND P.PER_ID = PN.PER_ID (+)
          AND P.PER_ID = PC.PER_ID (+)
          GROUP BY
            P.PER_ID
            , (P.CITY || ', ' || P.STATE || ',' || P.COUNTRY)
        ) P
    WHERE
      P.PER_ID = AP.PER_ID
    AND AP.ACCT_ID = AC.ACCT_ID
    AND AP.ACCT_ID = SA.ACCT_ID
    AND AP.MAIN_CUST_SW = 'Y'
    AND A.ACCT_ID = SA.ACCT_ID
    AND A.ACCT_ID = AP.ACCT_ID
    AND AC.CHAR_TYPE_CD = 'ACCTYPE' 
    AND AC.CHAR_VAL IN ('UOS', 'DEFAULT') 
    AND AC.ACCT_ID = SA.ACCT_ID
    AND CL.LANGUAGE_CD = 'ENG'
    AND A.ACCT_ID = AC.ACCT_ID
    AND A.CUST_CL_CD = CL.CUST_CL_CD
    AND SA.SA_ID = FT.SA_ID
    AND FT.FREEZE_DTTM IS NOT NULL 
    GROUP BY
      P.PER_ID
      , CL.DESCR
      , P.ENG_NAME
      , P.ARA_NAME
      , P.NATION
      , P.ADDR
      , ('Mob:' || NVL(P.MOB, '') || ', Home:' || NVL(P.HOME, '') || ', Bus.:' || NVL(P.BUS, '') || ', Fax:' || NVL(P.FAX, ''))
    HAVING
      SUM(FT.CUR_AMT) > 0
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.64       0.64          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch      304    353.09     430.04      21720   52997832          0        4543
    total      306    353.73     430.69      21720   52997832          0        4543
    Misses in library cache during parse: 1
    Optimizer mode: CHOOSE
    Parsing user id: 79  (CISADM)
    Rows     Row Source Operation
       4543  FILTER  (cr=52997832 pr=21720 pw=10311 time=430019418 us)
       5412   HASH GROUP BY (cr=52997832 pr=21720 pw=10311 time=430015729 us)
    199471    VIEW  (cr=52997832 pr=21720 pw=10311 time=423392346 us)
    199471     HASH GROUP BY (cr=52997832 pr=21720 pw=10311 time=423192867 us)
    4013304      TABLE ACCESS BY INDEX ROWID CI_FT (cr=52997832 pr=11409 pw=0 time=140469508 us)
    17717785       NESTED LOOPS  (cr=49295470 pr=8987 pw=0 time=407554071 us)
    13704480        NESTED LOOPS  (cr=21818135 pr=7655 pw=0 time=287797921 us)
    2782119         NESTED LOOPS OUTER (cr=3915432 pr=2950 pw=0 time=38953485 us)
    571492          NESTED LOOPS OUTER (cr=2545763 pr=2711 pw=0 time=7433194 us)
    286061           NESTED LOOPS OUTER (cr=2253263 pr=2671 pw=0 time=26607373 us)
    123411            NESTED LOOPS  (cr=1989056 pr=2642 pw=0 time=22711194 us)
    123411             NESTED LOOPS  (cr=1864959 pr=2642 pw=0 time=20860026 us)
    123411              NESTED LOOPS  (cr=1494040 pr=1754 pw=0 time=15553373 us)
    243088               NESTED LOOPS  (cr=29540 pr=1754 pw=0 time=10213331 us)
      13227                TABLE ACCESS FULL CI_PER (cr=251 pr=49 pw=0 time=43331 us)
    243088                INDEX RANGE SCAN XM150S1 (cr=29289 pr=1705 pw=0 time=6178159 us)(object id 97173)
    123411               INLIST ITERATOR  (cr=1464500 pr=0 pw=0 time=7220251 us)
    123411                INDEX RANGE SCAN CM064S0 (cr=1464500 pr=0 pw=0 time=5631936 us)(object id 108631)
    123411              TABLE ACCESS BY INDEX ROWID CI_ACCT (cr=370919 pr=888 pw=0 time=7241286 us)
    123411               INDEX UNIQUE SCAN XM148P0 (cr=247508 pr=0 pw=0 time=1198649 us)(object id 97147)
    123411             TABLE ACCESS BY INDEX ROWID CI_CUST_CL_L (cr=124097 pr=0 pw=0 time=1391837 us)
    123411              INDEX UNIQUE SCAN XC523P0 (cr=686 pr=0 pw=0 time=595005 us)(object id 97745)
    283749            TABLE ACCESS BY INDEX ROWID CI_PER_PHONE (cr=264207 pr=29 pw=0 time=3549713 us)
    283749             INDEX RANGE SCAN XM172P0 (cr=125886 pr=4 pw=0 time=1307395 us)(object id 98733)
    571492           INDEX RANGE SCAN XM171S2 (cr=292500 pr=40 pw=0 time=2976807 us)(object id 98728)
    2777066          TABLE ACCESS BY INDEX ROWID CI_PER_CHAR (cr=1369669 pr=239 pw=0 time=23084761 us)
    2777066           INDEX RANGE SCAN XM168P0 (cr=596156 pr=53 pw=0 time=7394319 us)(object id 98719)
    13704480         TABLE ACCESS BY INDEX ROWID CI_SA (cr=17902703 pr=4705 pw=0 time=163320548 us)
    13704480          INDEX RANGE SCAN XM199S1 (cr=5688247 pr=104 pw=0 time=51063061 us)(object id 98973)
    4013304        INDEX RANGE SCAN CM112S1 (cr=27477335 pr=1332 pw=0 time=124063022 us)(object id 116797)
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                     304        0.00          0.00
      db file sequential read                     11366        0.34         65.63
      direct path write temp                       1473        0.06          2.91
      latch: cache buffers chains                    17        0.00          0.00
      db file scattered read                          7        0.01          0.03
      read by other session                           2        0.00          0.00
      direct path read temp                        1473        0.03          6.85
      SQL*Net message from client                   304        0.02          2.74
      SQL*Net more data to client                   292        0.00          0.00
    ********************************************************************************

    Luckys
    I've just realised that I mis-read part of your plan:
      199471     HASH GROUP BY (cr=52997832 pr=21720 pw=10311 time=423192867 us)
    4013304      TABLE ACCESS BY INDEX ROWID CI_FT (cr=52997832 pr=11409 pw=0 time=140469508 us)
    17717785       NESTED LOOPS  (cr=49295470 pr=8987 pw=0 time=407554071 us)The time component for a line is the time it supplies, plus the sum of the time from its direct descendents.
    In this case I looked at the HASH GROUP BY and TABLE ACCESS and got a difference of about 283 seconds. In fact I should have taken more notice of the other lines in the plan - comparing the HASH GROUP BY with the NESTED LOOP for a difference of about 16 seconds and assuming that the time in the TABLE ACCESS line was not to be trusted. (See http://jonathanlewis.wordpress.com/2007/04/26/heisenberg/ for a couple of comments on the timing issue).
    So the grouping is responsible for relatively little of the excess time - most of the time goes into the nested loop.
    I shall be using the Hints as advised, when we say we
    have to "rewrite the query"
    given the current context excluding the HINTS, what
    exactly should I be
    considering in terms of query rewrite, what
    additional intelligence I can add to the
    query in question so that CBO produces a different
    plan.
    The main consideration is what the query is supposed to report. Compare this with the way the optimizer is running the query and see if it makes sense.
    When are talking about high intermediate rows
    processing are we referring to this
    section of the plan?;
    4013304      TABLE ACCESS BY INDEX ROWID CI_FT
    (cr=52997832 pr=11409 pw=0 time=140469508 us)
    17717785       NESTED LOOPS  (cr=49295470 pr=8987
    pw=0 time=407554071 us)
    13704480        NESTED LOOPS  (cr=21818135 pr=7655
    pw=0 time=287797921 us)
    2782119         NESTED LOOPS OUTER (cr=3915432
    pr=2950 pw=0 time=38953485 us)
    2777066          TABLE ACCESS BY INDEX ROWID
    CI_PER_CHAR (cr=1369669 pr=239 pw=0 time=23084761
    us)
    2777066           INDEX RANGE SCAN XM168P0 (cr=596156
    pr=53 pw=0 time=7394319 us)(object id 98719)
    13704480         TABLE ACCESS BY INDEX ROWID CI_SA
    (cr=17902703 pr=4705 pw=0 time=163320548 us)
    13704480          INDEX RANGE SCAN XM199S1
    (cr=5688247 pr=104 pw=0 time=51063061 us)(object id
    98973)
    4013304        INDEX RANGE SCAN CM112S1 (cr=27477335
    pr=1332 pw=0 time=124063022 us)(object id 116797)
    Correct - one of the nested loops returns 2.78M rows - but as you run the next join you end up collecting 13.7M entires from the next index and table. That step is responsible for quite a lot of your work and time (as is the following step where you USE the 13.7M rows to probe the next index/table combination). If the optimizer had not grown the data set by merging the P view earlier on, the data sizes would be significantly smaller at that point.
    Your inline view looks as if it is trying to turn rows into columns (the max(decode()) trick) - which is why I think it might be a good idea to stop Oracle from merging the view. So, as I suggested, look at the query withouth that bit of complexity and work out a sensible way to walk through the tables - bearing in mind the statistics below and the available indexes, and the amount of data your predicates identify at each stage.
    Moreover tables have been analyzed:
    CI_ACCT                            243068
    CI_ACCT_CHAR                       222320
    CI_ACCT_PER                        242971
    CI_FT                              794510
    CI_PER                              13227
    CI_PER_CHAR                         42555
    CI_PER_PHONE                        18488
    CI_SA                             1082301
    Parameters:
    optimizer_features_enable string 10.2.0.2
    optimizer_index_caching integer 100
    optimizer_index_cost_adj integer 1
    Unless you've been given strict instructions by a 3rd-part supplier, those settings for the optimizer_index_caching and optimizer_index_cost_adj are particularly bad - especially in 10g. With those settings, the optimizer is quite likely to choose stupid plans with excessive use of indexes - and pick the wrong index while doing it.
    It's not appropriate to fiddle with system parameters to address one query - but at some stage you need to rethink your entire set of parameter settings to do things the 10g way. See this note from the Optimizer Group: http://www.oracle.com/technology/products/bi/db/10g/pdf/twp_bidw_optimizer_10gr2_0208.pdf
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    "The greatest enemy of knowledge is not ignorance,
    it is the illusion of knowledge." Stephen Hawking.

  • Object name, segment advisor and db sequential read

    oracle 10.2.0.4:
    I am looking at our ADDM and AWR report. It's complaining about db file sequential read waits and also "Segment Advisor" on LOB SYS_LOB.... I have couple of questions:
    1. When select is fired (from JDBC/hibernate) with the column that is of type BLOB does the blob gets extracted at that point or just the reference is returned to the BLOB. And only when that column is accessed then the blob is fetched. Or does it get fetched right away in the "Select statemement"?
    2. I see Sedgment Advisor on object name LOB SYS_LOB000000012511C000006$$. How do I know which column/table it's referring to.
    3. db file sequential read waits means that something is wrong with disk layout?
    4. Even though our IO is not that high ADDM keeps complaining about increasing SGA to 64G. Currently as it is 32G and it's huge. Could it be because of above reasons that it thinks that it needs larger SGA?

    We are expecting a very high load in coming days. So I was looking at the system to check if somethings needs to be improved beforehand. I see things like 'User I/O waiting on Hot Objects", "db file sequential read waits". I read about it but I am not sure how to really see if it's going to be a problem or if it's a problem. We have indexes but one of the queries selects blob and is not always used so I was wondering if db file sequential read is being caused by that. I am not sure why we would have waiting on Hot objects because currently our system in not very busy. Hot object is a LOB and it's partitioned. It says database object with id XXXX, 0 full object scansm 25336 physical and direct reds. I know the table by looking up in DBA_LOBS.

  • Sequential read in sm66 - Database size 550GB - system slow for users

    Hello,
    Currently when we use any standard transactions  or custom program, it is going to sequential read in sm66.
    We are getting slowness in system due to this issue for users.
    Sm66 log:
    sapXX01_XXX_00  0  DIA     12873 Running            Yes                  6 XIRFC    ZCL_WM_S Sequential Read MARD
    sapXX01_XXX_00 20  BTC     16155 Running            Yes                 15 Zuser1  ZCL_SD_D Sequential Read LTAP
    sapXX01_XXX_00 29  SPO     12018 Running            Yes                 12 Zuser1   print 35
    sapXX01_XXX_00 30  SPO     12037 Running            Yes                 12 Zuser1   print 35
    sapXX01_XXX_00 31  SPO     12041 Running            Yes                 12 SAPSYS   querying
    sapXX02_XXX_02  3  DIA     15098 Running            Yes                714 Zuser2  ZCL_IM_B
    sapXX02_XXX_02  4  DIA      8158 Running            Yes                 38 Zuser2  RWRPLPRO Sequential Read WRPL
    sapXX02_XXX_02  6  DIA      8160 Running            Yes                555 Zuser3  ZCL_IM_B
    sapXX03_XXX_03  0  DIA      1969 Running            Yes               2390 Zuser5 SAPLFAGL Sequential Read BSIS
    sapXX03_XXX_04  0  BTC     10811 Running            Yes                209 Zuser6   ZCL_SD_D Sequential Read LTA
    Database: Maxdb
    OS: Linux
    I understand that if you create Index on these table ( whichever it shows as sequential read ), it will improve the report performance.
    Most of the time, system process shows that sequential read on VBAP, VKPA (sales tables), purchase tables, Finance tables and etc.
    If sm66 shows as sequential read for few table, that means that corresponding user will get slowness on getting report/transaction output. I agree on that.
    Is there any reason other user will get slowness ie if i run Va03 transaction, WE02 transaction which is not relevant to sm66 process over view.
    I appreciate, if you give some recommendations reg. this performance improvement and to avoid this kind of sequential read.
    I posted the Same question in DB forum also.
    I want to get some more idea from this forum also. That is reason, i posted here again.
    Thanks
    Praba

    Hi Volker,
    Thanks for your reply.
    We have three application server instance ie 00, 02, 03,   -
    04 (enque server)
    1) This parameter value on 00 instance ie : rdisp/wp_no_spo -  Number of spool work processes
    Dflt value - 0
    ProfileVa - 1
    Current value - 1
    Minimum - Nothing
    Maximum - 100
    2) his parameter value on 02 instance ie : rdisp/wp_no_spo -  Number of spool work processes
    Dflt value - 0
    ProfileVa - 1
    Current value - 1
    Minimum - Nothing
    Maximum - 100
    3) his parameter value on 03 instance ie : rdisp/wp_no_spo -  Number of spool work processes
    Dflt value - 0
    ProfileVa - 1
    Current value - 1
    Minimum - Nothing
    Maximum - 100

  • Sequential Read     in  EKUB table

    Hi,
    I have go to transaction CNV_MBT_TDMS in the Central system and all the prerequisites step is done ,now at  data transfer phase in activiry "Start Data Selection for Header Tables" in process.
    we have  already completed 55 tables  out of 56.The last table "EKUB" is running more than 5 days. in sender system SM50 it is shown "/1CADMC/SA 239 CPICTDMS     Sequential Read           EKUB" .    the central system is shown
    "Access plan for X_EKUB is being calculated (ID 00001, 16,777,216 blocks)
    Message no. DMCLG262"
    me doubt is this job is running or not.If yes mean when it will be completed.If no mean what is the next soluttion??
    please help me.
    Regards,
    V.shunmuga Sundaram

    Hello Dmitriy Fomin,
    To improve the data section for the object X_EKUB we have below options -
    1. Create a secondary index on the table EKUB in the sender system with below fields-
       MANDT
       EBELN
    2. Exclude the migration object X_EKUB from the current transfer using the troubleshooter 'Exclude Migration Objects from Current Transfer '.
       Now use the troubleshooter 'Create New Flat Migration Objects ' and create a new object for the table EKUB. This will select and transfer all data for the table EKUB.
    In most cases EKUB has not much data so it should be okay to copy this table in full and would be very fast.
    Thanks,
    Rajesh

  • Sequential read of DD03L table is taking forever during SP install

    Hello SDN
    I'm applying some SP to my vanilla ECC install with Max DB.
    Whenever I apply another set of SP or even SPAM update it inevitable hits a sequential read of table DD03L. And it takes forever to go throught it. It is a 1.5 Gb table.
    I updated statistics for the DB in DB50 and applied notes 791984, 1015068 and 1022755 as described in note 822379.
    I am running the latest kernel, dw set, tp and r3trans files
    I still need to apply the whole Stack 7 and 8 for the whole ECC 6.0 and I'm afraid the table will keep growing.
    Has anyone ran into the same issue?
    Any suggestions how to make this process faster?
    Thanks
    MR

    Hey,
    The table DD03L is quite large,
    however the upgrade should not take forever.
    I think you should create a DB trace,
    and find the problematic SQL statements,
    When you have those long running statements,
    you might be able to improve their performance (for example, create an index).

  • Sequential Read on table BSAD

    Hello All
    Our custom program job when observed thru SM51 is spending over 4 hours at a single point showing SEQUENTIAL READ on table BSAD. DB2 provided us with the queries that were executed during runtime trying to fetch data from table BSAD
    SELECT * FROM BSAD
    WHERE XBLNR EQ <value>
    AND BUKRS EQ <value>
    AND KUNNR IN L_KUNNR [] (which has around 400 KUNNR values)
    SELECT bukrs belnr xblnr blart zuonr kidno
    FROM bsad
    UP TO 1 ROWS
    INTO CORRESPONDING FIELDS OF <name>
    WHERE kunnr IN L_kunnr[] ((which has more than 400 KUNNR values)
    AND ( zuonr EQ <value> OR kidno EQ <value> ).
    We have indexes for both combinations specified above - still during the execution of the program the above query is being observed to clock for over 5 hours. This program had not been giving issues all along - and we are seeing issues lately. DB2 team mentions that IN statement is expensive. When DB2 observes during run-time - they see a lot of values been used in L_KUNNR[] range. The table re-org or index re-build has not been done for a while too. We are trying to interpret the possibilities
    Edited by: Vasantharaman Viswanathan on Jan 29, 2011 5:49 PM

    THanks for your inputs John
    Whenever we tried putting a trace- we do it during the execution of the statement - and only for a few times we have been able to capture trace - sometimes Basis team says that they did not capture any. In the traces that we have i was able to see at the statement being executed for 10 mins or so - which may not make sense if the program is stuck for hours.
    Also in the trace - i believe you are asking if we are able to deduce if it would use index based on the values provided?\or is there a field / param in the trace that provides this info? Please clarify
    Also when i tried having around 400 values in the IN statement and tried executing the query in non-prod - it took atleast 600 secs (since thats the max time i could keep it active as Dialog process in non-prod). Also do you think the above SELECT statement warrants a change?

  • Log file sequential read  and RFS ping/write - among Top 5 event

    I have situation here to discuss. In a 3-node RAC setup which is Logical standby DB; one node is showing high CPU utilization around 40~50%. The CPU utilization was less than 20% 10 days back but from 9th oldest day it jumped and consistently shows the double figure. I ran AWR reports on all three nodes and found one node with high CPU utilization and shows below tops events-
    EVENT WAITS TIME(S) AVG WAIT(MS) %TOTAL CALL TIME WAIT CLASS
    CPU time 5,802 34.9
    RFS ping 15 5,118 33,671 30.8 Other
    Log file sequential read 234,831 5,036 21 30.3 System I/O
    Sql*Net more data from
    client 24,171 1,087 45 6.5 Network
    Db file sequential read 130,939 453 3 2.7 User I/O
    Findings:-
    On AWR report(file attached) for node= sipd207; we can see that "RFS PING" wait event takes 30% of the waits and "log file sequential read" wait event takes 30% of the waits that occurs in database.
    Environment :- (Oracle- 10.2.0.4.0, O/S - AIX .3)
    1)other node awr shows "log file sync" - is it due to oversized log buffer?
    2)Network wait events can be reduced by tweaking SDU & TDU values based on MDU.
    3) Why ARCH processes taking much to archives filled redo logs; is it issue with slow disk I/O?
    Regards
    WORKLOAD REPOSITORY report for<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<DB Name DB Id Instance Inst Num Release RAC Host
    XXXPDB 4123595889 XXX2p2 2 10.2.0.4.0 YES sipd207
    Snap Id Snap Time Sessions Curs/Sess
    Begin Snap: 1053 04-Apr-11 18:00:02 59 7.4
    End Snap: 1055 04-Apr-11 20:00:35 56 7.5
    Elapsed: 120.55 (mins)
    DB Time: 233.08 (mins)
    Cache Sizes
    ~~~~~~~~~~~ Begin End
    Buffer Cache: 3,728M 3,728M Std Block Size: 8K
    Shared Pool Size: 4,080M 4,080M Log Buffer: 14,332K
    Load Profile
    ~~~~~~~~~~~~ Per Second Per Transaction
    Redo size: 245,392.33 10,042.66
    Logical reads: 9,080.80 371.63
    Block changes: 1,518.12 62.13
    Physical reads: 7.50 0.31
    Physical writes: 44.00 1.80
    User calls: 36.44 1.49
    Parses: 25.84 1.06
    Hard parses: 0.59 0.02
    Sorts: 12.06 0.49
    Logons: 0.05 0.00
    Executes: 295.91 12.11
    Transactions: 24.43
    % Blocks changed per Read: 16.72 Recursive Call %: 94.18
    Rollback per transaction %: 4.15 Rows per Sort: 53.31
    Instance Efficiency Percentages (Target 100%)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Buffer Nowait %: 99.99 Redo NoWait %: 100.00
    Buffer Hit %: 99.92 In-memory Sort %: 100.00
    Library Hit %: 99.83 Soft Parse %: 97.71
    Execute to Parse %: 91.27 Latch Hit %: 99.79
    Parse CPU to Parse Elapsd %: 15.69 % Non-Parse CPU: 99.95
    Shared Pool Statistics Begin End
    Memory Usage %: 83.60 84.67
    % SQL with executions>1: 97.49 97.19
    % Memory for SQL w/exec>1: 97.10 96.67
    Top 5 Timed Events Avg %Total
    ~~~~~~~~~~~~~~~~~~ wait Call
    Event Waits Time (s) (ms) Time Wait Class
    CPU time 4,503 32.2
    RFS ping 168 4,275 25449 30.6 Other
    log file sequential read 183,537 4,173 23 29.8 System I/O
    SQL*Net more data from client 21,371 1,009 47 7.2 Network
    RFS write 25,438 343 13 2.5 System I/O
    RAC Statistics DB/Inst: UDAS2PDB/udas2p2 Snaps: 1053-1055
    Begin End
    Number of Instances: 3 3
    Global Cache Load Profile
    ~~~~~~~~~~~~~~~~~~~~~~~~~ Per Second Per Transaction
    Global Cache blocks received: 0.78 0.03
    Global Cache blocks served: 1.18 0.05
    GCS/GES messages received: 131.69 5.39
    GCS/GES messages sent: 139.26 5.70
    DBWR Fusion writes: 0.06 0.00
    Estd Interconnect traffic (KB) 68.60
    Global Cache Efficiency Percentages (Target local+remote 100%)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Buffer access - local cache %: 99.91
    Buffer access - remote cache %: 0.01
    Buffer access - disk %: 0.08
    Global Cache and Enqueue Services - Workload Characteristics
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Avg global enqueue get time (ms): 0.5
    Avg global cache cr block receive time (ms): 0.9
    Avg global cache current block receive time (ms): 1.0
    Avg global cache cr block build time (ms): 0.0
    Avg global cache cr block send time (ms): 0.1
    Global cache log flushes for cr blocks served %: 2.9
    Avg global cache cr block flush time (ms): 4.6
    Avg global cache current block pin time (ms): 0.0
    Avg global cache current block send time (ms): 0.1
    Global cache log flushes for current blocks served %: 0.1
    Avg global cache current block flush time (ms): 5.0
    Global Cache and Enqueue Services - Messaging Statistics
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Avg message sent queue time (ms): 0.1
    Avg message sent queue time on ksxp (ms): 0.6
    Avg message received queue time (ms): 0.0
    Avg GCS message process time (ms): 0.0
    Avg GES message process time (ms): 0.1
    % of direct sent messages: 31.57
    % of indirect sent messages: 5.17
    % of flow controlled messages: 63.26
    Time Model Statistics DB/Inst: UDAS2PDB/udas2p2 Snaps: 1053-1055
    -> Total time in database user-calls (DB Time): 13984.6s
    -> Statistics including the word "background" measure background process
    time, and so do not contribute to the DB time statistic
    -> Ordered by % or DB time desc, Statistic name
    Statistic Name Time (s) % of DB Time
    sql execute elapsed time 7,270.6 52.0
    DB CPU 4,503.1 32.2
    parse time elapsed 506.7 3.6
    hard parse elapsed time 497.8 3.6
    sequence load elapsed time 152.4 1.1
    failed parse elapsed time 19.5 .1
    repeated bind elapsed time 3.4 .0
    PL/SQL execution elapsed time 0.7 .0
    hard parse (sharing criteria) elapsed time 0.3 .0
    connection management call elapsed time 0.3 .0
    hard parse (bind mismatch) elapsed time 0.0 .0
    DB time 13,984.6 N/A
    background elapsed time 869.1 N/A
    background cpu time 276.6 N/A
    Wait Class DB/Inst: UDAS2PDB/udas2p2 Snaps: 1053-1055
    -> s - second
    -> cs - centisecond - 100th of a second
    -> ms - millisecond - 1000th of a second
    -> us - microsecond - 1000000th of a second
    -> ordered by wait time desc, waits desc
    Avg
    %Time Total Wait wait Waits
    Wait Class Waits -outs Time (s) (ms) /txn
    System I/O 529,934 .0 4,980 9 3.0
    Other 582,349 37.4 4,611 8 3.3
    Network 279,858 .0 1,009 4 1.6
    User I/O 54,899 .0 317 6 0.3
    Concurrency 136,907 .1 58 0 0.8
    Cluster 60,300 .0 41 1 0.3
    Commit 80 .0 10 130 0.0
    Application 6,707 .0 3 0 0.0
    Configuration 17,528 98.5 1 0 0.1
    Wait Events DB/Inst: UDAS2PDB/udas2p2 Snaps: 1053-1055
    -> s - second
    -> cs - centisecond - 100th of a second
    -> ms - millisecond - 1000th of a second
    -> us - microsecond - 1000000th of a second
    -> ordered by wait time desc, waits desc (idle events last)
    Avg
    %Time Total Wait wait Waits
    Event Waits -outs Time (s) (ms) /txn
    RFS ping 168 .0 4,275 25449 0.0
    log file sequential read 183,537 .0 4,173 23 1.0
    SQL*Net more data from clien 21,371 .0 1,009 47 0.1
    RFS write 25,438 .0 343 13 0.1
    db file sequential read 54,680 .0 316 6 0.3
    DFS lock handle 97,149 .0 214 2 0.5
    log file parallel write 104,808 .0 157 2 0.6
    db file parallel write 143,905 .0 149 1 0.8
    RFS random i/o 25,438 .0 86 3 0.1
    RFS dispatch 25,610 .0 56 2 0.1
    control file sequential read 39,309 .0 55 1 0.2
    row cache lock 130,665 .0 47 0 0.7
    gc current grant 2-way 35,498 .0 23 1 0.2
    wait for scn ack 50,872 .0 20 0 0.3
    enq: WL - contention 6,156 .0 14 2 0.0
    gc cr grant 2-way 16,917 .0 11 1 0.1
    log file sync 80 .0 10 130 0.0
    Log archive I/O 3,986 .0 9 2 0.0
    control file parallel write 3,493 .0 8 2 0.0
    latch free 2,356 .0 6 2 0.0
    ksxr poll remote instances 278,473 49.4 6 0 1.6
    enq: XR - database force log 2,890 .0 4 1 0.0
    enq: TX - index contention 325 .0 3 11 0.0
    buffer busy waits 4,371 .0 3 1 0.0
    gc current block 2-way 3,002 .0 3 1 0.0
    LGWR wait for redo copy 9,601 .2 2 0 0.1
    SQL*Net break/reset to clien 6,438 .0 2 0 0.0
    latch: ges resource hash lis 23,223 .0 2 0 0.1
    enq: WF - contention 32 6.3 2 62 0.0
    enq: FB - contention 660 .0 2 2 0.0
    enq: PS - contention 1,088 .0 2 1 0.0
    library cache lock 869 .0 1 2 0.0
    enq: CF - contention 671 .1 1 2 0.0
    gc current grant busy 1,488 .0 1 1 0.0
    gc current multi block reque 1,072 .0 1 1 0.0
    reliable message 618 .0 1 2 0.0
    CGS wait for IPC msg 62,402 100.0 1 0 0.4
    gc current block 3-way 998 .0 1 1 0.0
    name-service call wait 18 .0 1 57 0.0
    cursor: pin S wait on X 78 100.0 1 11 0.0
    os thread startup 16 .0 1 53 0.0
    enq: RO - fast object reuse 193 .0 1 3 0.0
    IPC send completion sync 652 99.2 1 1 0.0
    local write wait 194 .0 1 3 0.0
    gc cr block 2-way 534 .0 0 1 0.0
    log file switch completion 17 .0 0 20 0.0
    SQL*Net message to client 258,483 .0 0 0 1.5
    undo segment extension 17,282 99.9 0 0 0.1
    gc cr block 3-way 286 .7 0 1 0.0
    enq: TM - contention 76 .0 0 4 0.0
    PX Deq: reap credit 15,246 95.6 0 0 0.1
    kksfbc child completion 5 100.0 0 49 0.0
    enq: TT - contention 141 .0 0 2 0.0
    enq: HW - contention 203 .0 0 1 0.0
    RFS create 2 .0 0 115 0.0
    rdbms ipc reply 339 .0 0 1 0.0
    PX Deq Credit: send blkd 452 20.1 0 0 0.0
    gcs log flush sync 128 32.8 0 2 0.0
    latch: cache buffers chains 128 .0 0 1 0.0
    library cache pin 441 .0 0 0 0.0
    Wait Events DB/Inst: UDAS2PDB/udas2p2 Snaps: 1053-1055
    -> s - second
    -> cs - centisecond - 100th of a second
    -> ms - millisecond - 1000th of a second
    -> us - microsecond - 1000000th of a second
    -> ordered by wait time desc, waits desc (idle events last)

    We only apply on one node in a cluster so I would expect that the node running SQL Apply would have much higher usage and waits. Is this what you are asking?
    Larry

  • Tables-Primary Key-Sequential read

    Hi Folks,
    Out of the following which imporves performace?
    1.Using all the primary keys of a table in the where clause of a select statement?
    2.Using any one or two (not all) primary keys of a table in the where clause of a select statement?
    Let me the know the same in the case of using an Secondary index.
    3.If we follow the second one,then it will go for a sequential read,how this sequential read mars the performance?
    4.How creating an index will affect the database as BASIS guys are not in favour to creating an index.
    Thanks,
    K.Kiran.

    1.Using all the primary keys of a table in the where clause of a select statement?
    2.Using any one or two (not all) primary keys of a table in the where clause of a select statement?
    Out of the above 2 first one will give more performance. Coming to primary key or Secondary indexses, anything.. it gives better performance if you give the key fileds in the order of DB declaration.
    I mean you are specifying some fields of primary key.. but not in the order .. i mean u have specified key1, key3, key4. It will give less performance than specifying only key1 and key2.
    in secondary indexes if you are not specifying all key completely that will take the key up to the order matches. i mean in key1, key3, key4 case.. it will consider only Key1.
    In Key1, Key2 case it will consider both.
    3.If we follow the second one,then it will go for a sequential read,how this sequential read mars the performance?
    4.How creating an index will affect the database as BASIS guys are not in favour to creating an index.
    Creating an secondary index will save the table contents in the format of starting with index fields in the DB. So number of indexes on the same table will need to craete more views in database. So leads to poor DB performance. i mean more space unnecesarily for a single table. That's why they will create indexes only for very frequently used fields on tables.

Maybe you are looking for

  • What is new in the latest Apple TV version?

    Is the March 2012 version of Apple TV the same as the latest version?  I'm thinking about purchasing a refurbished model (http://store.apple.com/us/browse/home/specialdeals/ipod/apple_tv) and wonder if there is any downside to that version vs. what i

  • Exception only occuring during stress test

    We are trying to get ready to release a beta version of the software I'm working on.. so part of getting ready for that was to try set up some stress tests and hit the server with multiple requests for the same page.... Not sure exactly how many it i

  • Why is the app store on my ipod touch 4g just close for no reason?

    I go to search in the app store and it closes the store, any one else got this problem sent the iso 6 update?

  • I desparately need to read a Japanese Clarisworks cwk file!

    Hello Folks; I am a volunteer with an anime convention. One of our japanese musical guests has sent us a list of tech requirements in a clarisworks file. I need to import it to something current (or find a place where i can buy something old ) that p

  • It's Almost 2011- According to Photo Booth and iStat!

    Sparking from a post on TUAW. http://www.tuaw.com/2009/12/29/beware-photo-booth-time-stamps-its-a-bug-not-a-fe ature/ Photo Booth is acting a bit weird when naming files. For example, I took a photo a few minutes ago, and the resulting file is named