Wait Class

Hi,
As per documents In general, the addition of wait classes helps direct the DBA more quickly toward the root cause of performance problems.
How could i trace the root cause of performence problems if it is related to wait class?
Thanks,

userpat wrote:
Hi,
As per documents In general, the addition of wait classes helps direct the DBA more quickly toward the root cause of performance problems.
How could i trace the root cause of performence problems if it is related to wait class?
Thanks,I am not completely sure that I understand your question. The wait class gives you an approximate idea of where the performance problem will be found. You must then further investigate the wait events in that wait class. There are of course potential problems with starting at the wait class (some wait classes have 2 wait events, while others have many - that could throw off the search for the problem that is impacting performance the most), but at least it provides a starting point. To give you an idea of the wait events in each wait class, here is a SQL statement that was executed on Oracle Database 11.1.0.7:
SQL> DESC V$EVENT_NAME
Name                                      Null?    Type
EVENT#                                             NUMBER
EVENT_ID                                           NUMBER
NAME                                               VARCHAR2(64)
PARAMETER1                                         VARCHAR2(64)
PARAMETER2                                         VARCHAR2(64)
PARAMETER3                                         VARCHAR2(64)
WAIT_CLASS_ID                                      NUMBER
WAIT_CLASS#                                        NUMBER
WAIT_CLASS                                         VARCHAR2(64)
SELECT
  SUBSTR(NAME,1,30) EVEMT_NAME,
  SUBSTR(WAIT_CLASS,1,20) WAIT_CLASS
FROM
  V$EVENT_NAME
ORDER BY
  SUBSTR(WAIT_CLASS,1,20),
  SUBSTR(NAME,1,30);
EVEMT_NAME                     WAIT_CLASS
ASM COD rollback operation com Administrative
ASM mount : wait for heartbeat Administrative
Backup: sbtbackup              Administrative
Backup: sbtbufinfo             Administrative
Backup: sbtclose               Administrative
Backup: sbtclose2              Administrative
OLAP DML Sleep                 Application
SQL*Net break/reset to client  Application
SQL*Net break/reset to dblink  Application
Streams capture: filter callba Application
Streams: apply reader waiting  Application
WCR: replay lock order         Application
Wait for Table Lock            Application
enq: KO - fast object checkpoi Application
enq: PW - flush prewarm buffer Application
enq: RC - Result Cache: Conten Application
enq: RO - contention           Application
enq: RO - fast object reuse    Application
enq: TM - contention           Application
enq: TX - row lock contention  Application
enq: UL - contention           Application
ASM PST query : wait for [PM][ Cluster
gc assume                      Cluster
gc block recovery request      Cluster
enq: BB - 2PC across RAC insta Commit
log file sync                  Commit
Shared IO Pool Memory          Concurrency
Streams apply: waiting for dep Concurrency
buffer busy waits              Concurrency
cursor: mutex S                Concurrency
cursor: mutex X                Concurrency
cursor: pin S wait on X        Concurrency
Global transaction acquire ins Configuration
Streams apply: waiting to comm Configuration
checkpoint completed           Configuration
enq: HW - contention           Configuration
enq: SQ - contention           Configuration
enq: SS - contention           Configuration
enq: ST - contention           Configuration
enq: TX - allocate ITL entry   Configuration
free buffer waits              Configuration
ASM background timer           Idle
DIAG idle wait                 Idle
EMON slave idle wait           Idle
HS message to agent            Idle
IORM Scheduler Slave Idle Wait Idle
JOX Jit Process Sleep          Idle
ARCH wait for flow-control     Network
ARCH wait for net re-connect   Network
ARCH wait for netserver detach Network
ARCH wait for netserver init 1 Network
ARCH wait for netserver init 2 Network
ARCH wait for netserver start  Network
ARCH wait on ATTACH            Network
ARCH wait on DETACH            Network
ARCH wait on SENDREQ           Network
LGWR wait on ATTACH            Network
LGWR wait on DETACH            Network
LGWR wait on LNS               Network
LGWR wait on SENDREQ           Network
LNS wait on ATTACH             Network
LNS wait on DETACH             Network
LNS wait on LGWR               Network
LNS wait on SENDREQ            Network
SQL*Net message from dblink    Network
SQL*Net message to client      Network
SQL*Net message to dblink      Network
SQL*Net more data from client  Network
SQL*Net more data from dblink  Network
AQ propagation connection      Other
ARCH wait for archivelog lock  Other
ARCH wait for process death 1  Other
ARCH wait for process death 2  Other
ARCH wait for process death 3  Other
ARCH wait for process death 4  Other
ARCH wait for process death 5  Other
ARCH wait for process start 1  Other
Streams AQ: enqueue blocked du Queueing
Streams AQ: enqueue blocked on Queueing
Streams capture: waiting for s Queueing
Streams: flow control          Queueing
Streams: resolve low memory co Queueing
resmgr:I/O prioritization      Scheduler
resmgr:become active           Scheduler
resmgr:cpu quantum             Scheduler
ARCH random i/o                System I/O
ARCH sequential i/o            System I/O
Archiver slave I/O             System I/O
DBWR slave I/O                 System I/O
LGWR random i/o                System I/O
BFILE read                     User I/O
DG Broker configuration file I User I/O
Data file init write           User I/O
Datapump dump file I/O         User I/O
Log file init write            User I/O
Shared IO Pool IO Completion   User I/O
buffer read retry              User I/O
cell multiblock physical read  User I/O
cell single block physical rea User I/O
cell smart file creation       User I/O
cell smart index scan          User I/O
cell smart table scan          User I/O
cell statistics gather         User I/O
db file parallel read          User I/O
db file scattered read         User I/O
db file sequential read        User I/O
db file single write           User I/O
...So, if the User I/O wait class floats to the top of the wait classes between a known start time and end time, and the Commit wait class is at the bottom of the wait classes when comparing accumulated time, it probably would not make much sense to spend time investigating the wait events in the Commit class... until you realize that there is a single event in the Commit wait class that typically contributes wait time, while there are many in the User I/O wait class.
Charles Hooper
Co-author of "Expert Oracle Practices: Oracle Database Administration from the Oak Table"
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

Similar Messages

  • Wait event "virtual circuit wait" in wait class "Network" was consuming sig

    Hello,
    We are facing this problem when there are 2 queries try to run at the same time.
    The first query takes longer to finish so 2nd has to wait for 1st to be finished and then only 2nd starts. It seems the jam is at netowork instead of server.
    I want to make sure before I start testing on network.
    I get following :
    Wait event "virtual circuit wait" in wait class "Network" was consuming significant database time. 98.4
    Wait class "Network" was consuming significant database time.
    and recommendations is stated as :
    Investigate the cause for high "virtual circuit wait" waits with P1 ("circuit#") value "21" and P2 ("type") value "2".
    I am checking OEM.
    Thanks,
    Shashi.

    Hello Sybrand,
    Can you suggest some changes to be done to test ?
    Here is my shared server config :
    SQL> show parameter SHARED
    NAME TYPE VALUE
    hi_shared_memory_address integer 0
    max_shared_servers integer
    shared_memory_address integer 0
    shared_pool_reserved_size big integer 135895449
    shared_pool_size big integer 0
    shared_server_sessions integer
    shared_servers integer 1
    Thanks,
    Shashi.

  • User I/O Wait class in Top 5 Timed Foreground Events

    Hi Mates
    In my awr report in Top 5 Timed Foreground Events, i get the below event list
    Event     Waits     Time(s)     Avg wait (ms)     % DB time     Wait Class
    DB CPU          25,721          58.29     
    db file sequential read     67,491,952     7,710     0     17.47     User I/O
    db file scattered read     7,147,112     2,560     0     5.8     User I/O
    log file sync     2,926,748     1,526     1     3.46     Commit
    direct path read     342,745     834     2     1.89     User I/O
    So does it means that there is a issue with disk I/O on my box. since the wait class is showing as User I/O.
    I am running the single instance database with oracle version 11.2 on IBM AIX server.

    huzaifa wrote:
    Hi Mates
    In my awr report in Top 5 Timed Foreground Events, i get the below event list
    Event                              Waits       Time(s)       Avg wait (ms)     % DB time      Wait Class
    DB CPU                                             25,721                               58.29     
    db file sequential read           67,491,952        7,710          0                         17.47      User I/O
    db file scattered read           7,147,112        2,560          0                          5.8      User I/O
    log file sync                           2,926,748        1,526          1                          3.46      Commit
    direct path read                   342,745        834          2                          1.89      User I/OSo does it means that there is a issue with disk I/O on my box. since the wait class is showing as User I/O.
    I am running the single instance database with oracle version 11.2 on IBM AIX server.Is this a standard one hour report on a machine with at least 8 CPUs available ?
    If so then take a look at Dom Brooks comment - your average read times are in the range of 0.1 to 0.3 milliseconds - they're mostly coming out of filesystem cache (but maybe you have some very good database flashcache installed).
    Your first move should probably be to take some of the memory from your file system cache and increase your buffer cache - this will probably decrease the number of reads reported and the amount of CPU used. I'd also look for statements that seem to be doing an unreasonable amount of I/O to get their end results, and check the "Segments by ... " section of the report to see which objects are seeing most I/O.
    Before you mess about with ASM, you should simply check for easy ways to do less work.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    Author: <b><em>Oracle Core</em></b>

  • Wait class 'commit' consuming significant database time.

    Hi
    My awr report was showing that the log file sync as the top wait event.I can also see additional message saying that wait class 'commit' consuming significant database time.Can any one suggest me what are the tuning things i need to consider for this wait class 'LOG FILE SYNC'
    Thanks

    Be very careful about this.
    Follow this only if you can afford to lose some data in case of instance failure
    (eg death of the instance from a bug, server panic/reboot, power failure etc).
    Oracle's normal behaviour is to guarantee that every committed transaction
    IS available by ensuring that it is in the redologs and reapplying it if necessary
    in case of an instance failure and recovery or media recovery.
    A Commit NOWAIT means that there is a possibility, however slight, that
    the last few transaction(s) might not have gotten into the redo logs at the time
    of instance failure.
    Your application / analysts must be able to identify transactions that are 'lost'
    and reapply them after you restart a crashed instance.

  • Database Time Spent Waiting (%): Wait Class Other nearly 100% all the time

    Don't understand why OEM is reporting that Database Time Spent Waiting (%): Wait Class Other is nearly 100% all the time. Database 10.1.0.4 just installed on Linux(RHEL4AS) and nobody use it for now except OEM and me for admin purpose.
    Any clue for that problem ?
    Regards
    Nicolas

    Seems like you are not the first to see this kind of behaviour.
    I've found another similar thread on metalink. I can't say the answer is terribly helpful, but thought you might be interested anyway:
    From: Jose Ramón Tourón 14-Sep-07 08:34
    Subject: Database Time Spent Waiting (%) at 100 in event class Commit
    RDBMS Version: Oracle 10g r2
    Operating System and Version: Suse Enterprise Linux 10
    Error Number (if applicable):
    Product (i.e. SQL*Loader, Import, etc.): database core
    Product Version: 10gR2
    Database Time Spent Waiting (%) at 100 in event class Commit
    Hi everyone, yesterday we create a new database instance with dbca, the creation process was ok, and the two instances are running ok, database stops and starts without any problem, and listeners are ok. In the enterprise manager of this new instance we found this message:
    Database Time Spent Waiting (%) at 100 in event class Commit, this event happend every 1 or 2 minutes sometimes at 100, the next 40%, the next 98, ... and so on.
    Do you know what's happend in this instance?
    Thanks in advance to everyone
    Santiago Pérez
    From: Oracle, Helmut Pfau 14-Sep-07 12:52
    Subject: Re : Database Time Spent Waiting (%) at 100 in event class Commit
    From Oracle Database Reference Manual:
    Commit
    This wait class only comprises one wait event - wait for redo log write confirmation after a commit (that is, 'log file sync')
    So you can't write fast enough into your log files.
    Did you check the frequency of log switches?
    From: Metalink TCS User Group TCS Uruguay 14-Sep-07 15:52
    Subject: Re : Database Time Spent Waiting (%) at 100 in event class Commit
    Hi José! Please don't get anxious because of this: Wait time must be SOMEWHERE, there's a saying "An OLTP DB is only as fast as its redo logs", but if you are not having any performance problem you don't need to do anything special.
    You say you've just created the DB. Now make it DO something: put it to the test by simulating production conditions as closely as you can, and after some hours ask the users whether there is some problem. If there is, take a look at the wait statistics... you'll probably see many other top events before this one!
    Bruno abate_at_adinet.com.uy

  • Other wait class

    can anyone tell me what are the wait events in wait class 'OTHER';

    Dear dbaforu,
    Short but indeed useful information here;
    http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/instance_tune.htm#PFGRF94504
    +"+
    +10.3.7 events in wait class other+
    +This event belong to Other wait class and typically should not occur on a system. This event is an aggregate of all other events in the Other wait class, such as latch free, and is used in the V$SESSION_EVENT and V$SERVICE_EVENT views only. In these views, the events in the Other wait class will not be maintained individually in every session. Instead, these events will be rolled up into this single event to reduce the memory used for maintaining statistics on events in the Other wait class.+
    +"+
    Regards.
    Ogan

  • Wait class Application

    what is Wait class Application?
    give guide me

    Hi,
    Application is one of a classification of Wait class events along with network,commit,idle,user i/o.
    Application: locks waits caused by row level locking or explicit lock commands
    Have a look into this link.
    http://youngcow.net/doc/oracle10g/server.102/b14211/autostat.htm
    Regards
    Jafar

  • Metrics "Database Time Spent Waiting (%)" is at ... for event class "Commit

    Hi guys
    I'm getting this warning every 20 minutes from Enterprise Manager 10g: Metrics "Database Time Spent Waiting (%)" is at 67.62891 for event class "Commit". My database is an Oracle 10g 10.2.0.4 (Linux x84_64) with dataguard, one physical and one standby networked at 100Mbit. I have 3 groups of 50M redo log with a low volume of transaction for now. Here are some metrics numbers:
    SQL> select sum(seconds_in_wait),event from v$session_wait group by event;
    SUM(SECONDS_IN_WAIT) EVENT
    121210 SQL*Net message from client
    0 Streams AQ: waiting for messages in the queue
    18 wait for unread message on broadcast channel
    6 LNS ASYNC end of log
    30 jobq slave wait
    37571 rdbms ipc message
    384 smon timer
    35090 pmon timer
    I tune the my listerners for Dataguard using the documentation. I don't know what to tune anymore, is someone has a clue.
    Thanks,
    Chris

    cprieur wrote:
    Metrics "Database Time Spent Waiting (%)" is at 67.62891 for event class "Commit"
    I'am also getting this message at a regular time:
    Metrics "Database Time Spent Waiting (%)" is at 64.09801 for event class "Network"
    The report, I was sent only to indicate the time spent on: SQL*Net message from client
    I believe that these metrics are explained here (near the bottom of the page):
    http://download.oracle.com/docs/cd/B19306_01/em.102/b25986/oracle_database.htm
    There are only two wait events in the Commit class (on 11.1.0.7):
    log file sync
    enq: BB - 2PC across RAC instances
    log file sync waits happen when sessions issue a COMMIT or ROLLBACK. Sessions will wait on this event until LGWR completes its writes to the redo logs (LGWR will likely wait on the event log file parallel wriite while waiting for the write to complete). I believe that your DataGuard configuration may contribute to the long waits experienced by LGWR, and it may be made worse by the network connection.
    http://download.oracle.com/docs/cd/B28359_01/server.111/b28294.pdf
    "Maximum availability - This protection mode provides the highest level of data protection that is possible without compromising the availability of a primary database. Transactions do not commit until all redo data needed to recover those transactions has been written to the online redo log and to at least one standby database."
    So, if Maximum availability is configured, the sessions will have to wait for the redo to be applied to the remote database.
    At the system-wide level you will almost always be able to ignore the SQL*Net message from client wait events. At the session level this wait event has a more significant meaning - the client computer is not actively waiting on a response from the database instance - the client is either sitting idle, or performing client-side processing.
    Sybrand, if he joins this thread, will likely be able to provide a more complete answer regarding DataGuard's contribution to the Commit wait class.
    Charles Hooper
    IT Manager/Oracle DBA
    K&M Machine-Fabricating, Inc.

  • Waiting (%)     Metrics "Database Time Spent Waiting (%)" is at 69.64818 for event class "Commit"

    Hi,
    Can any one help me on this warning, i got this warning on ORACLE ENTERPRISE MANAGER
    Waits by Wait Class
    Database Time Spent Waiting (%)
    Metrics "Database Time Spent Waiting (%)" is at 69.64818 for event class "Commit"
    Below are our environment details:
    RDBMS: 10.2.0.4
    Oracle E-Business suite: 12.0.6
    OS: Oracle Sun 10
    Please suggest.
    Thank you.

    Please see the following docs.
    How to Disable Alerts for The Database Time Spent Waiting (%) Metric? (Doc ID 1500074.1)
    "Database Time Spent Waiting (%)" at 100 for Event Class "Other" when Database is not Under Load (Doc ID 1526552.1)
    Thanks,
    Hussein

  • High library cache load lock waits in AWR

    Hi All,
    Today i faced a significant performance problem related to shared pool. I made some observations, thought it would be a nice idea to share them with Oracle experts. Please feel free to add your observations/recommendations and correct me where i am wrong.
    Here are the excerpts from AWR report created for the problem timing. Database server is on 10.2.0.3 and running with 2*16 configuration. DB cache size is 4,000M and shared pool size is of 3008M.
    Snap Id Snap Time Sessions Cursors/Session
    Begin Snap: 9994 29-Jun-09 10:00:07 672 66.3
    End Snap: 10001 29-Jun-09 17:00:49 651 64.4
    Elapsed:   420.70 (mins)    
    DB Time:   4,045.34 (mins)   -- Very poor response time visible from difference between DB time and elapsed time.
    Load Profile
    Per Second Per Transaction
    Redo size: 248,954.70 23,511.82
    Logical reads: 116,107.04 10,965.40
    Block changes: 1,357.13 128.17
    Physical reads: 125.49 11.85
    Physical writes: 51.49 4.86
    User calls: 224.69 21.22
    Parses: 235.22 22.21
    Hard parses: 4.83 0.46
    Sorts: 102.94 9.72
    Logons: 1.12 0.11
    Executes: 821.11 77.55
    Transactions: 10.59   -- User calls and Parse count are almost same, means most of the calls are for parse. Most of the parses are soft. Per transaction 22 parses are very high figure.
    -- Not much disk I/O activity. Most of the reads are being satisfy from memory.
    Instance Efficiency
    Buffer Nowait %: 100.00 Redo NoWait %: 100.00
    Buffer Hit %: 99.92 In-memory Sort %: 100.00
    Library Hit %: 98.92 Soft Parse %: 97.95
    Execute to Parse %: 71.35 Latch Hit %: 99.98
    Parse CPU to Parse Elapsd %: 16.82 % Non-Parse CPU: 91.41 -- Low execute to parse ratio denotes CPU is significantly busy in parsing. Soft Parse% showing, most of the parse are soft parses. It means we should concentrate on soft parsing activity.
    -- Parse CPU to Parse Elapsed % is quite low, means some bottleneck is there related to parsing. It could be a side-effect of huge parsing pressure. Like CPU cycles are not available.
    Shared Pool Statistics
    Begin End
    Memory Usage %: 81.01 81.92
    % SQL with executions>1: 88.51 86.93
    % Memory for SQL w/exec>1: 86.16 86.76 -- Shared Pool memory seems ok (in 80% range)
    -- 88% of the SQLs are repeating ones. It's a good sign.
    Top 5 Timed Events
    Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
    library cache load lock 24,243 64,286 2,652 26.5 Concurrency
    db file sequential read 1,580,769 42,267 27 17.4 User I/O
    CPU time   33,039   13.6  
    latch: library cache 53,013 29,194 551 12.0 Concurrency
    db file scattered read 151,669 13,550 89 5.6 User I/O Problem-1: Contention on Library cache: May be due to under-sized shared pool, incorrect parameters, poor application design, But since we already observed that most of the parses are soft parses and shared pool usgae in 80%, seems problem related to holding cursors. open_cursors/session_cached_cursors are red flags.
    Problem-2: User I/O, may be due to poor SQLs, I/O sub-system, or poor physical design (wrong indexes are being used as DB file seq reads)
    Wait Class
    Wait Class Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn
    Concurrency 170,577 44.58 109,020 639 0.64
    User I/O 2,001,978 0.00 59,662 30 7.49
    System I/O 564,771 0.00 8,069 14 2.11
    Application 145,106 1.25 6,352 44 0.54
    Commit 176,671 0.37 4,528 26 0.66
    Other 27,557 6.31 2,532 92 0.10
    Network 6,862,704 0.00 696 0 25.68
    Configuration 3,858 3.71 141 37 0.01
    Wait Events
    Event Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn
    library cache load lock 24,243 83.95 64,286 2652 0.09
    db file sequential read 1,580,769 0.00 42,267 27 5.91
    latch: library cache 53,013 0.00 29,194 551 0.20
    db file scattered read 151,669 0.00 13,550 89 0.57
    latch: shared pool 25,403 0.00 12,969 511 0.10
    log file sync 176,671 0.37 4,528 26 0.66
    enq: TM - contention 1,455 90.93 3,975 2732 0.01 Instance Activity Stats
    opened cursors cumulative 5,290,760 209.60 19.80
    parse count (failures) 6,181 0.24 0.02
    parse count (hard) 121,841 4.83 0.46
    parse count (total) 5,937,336 235.22 22.21
    parse time cpu 283,787 11.24 1.06
    parse time elapsed 1,687,096 66.84 6.31 Latch Activity
    library cache 85,042,375 0.15 0.43 29194 304,831 7.16
    library cache load lock 257,089 0.00 1.20 0 69,065 0.00
    library cache lock 41,467,300 0.02 0.07 6 2,714 0.07
    library cache lock allocation 730,422 0.00 0.44 0 0  
    library cache pin 28,453,986 0.01 0.16 8 167 0.00
    library cache pin allocation 509,000 0.00 0.38 0 0 Init.ora parameters
    cursor_sharing= EXACT
    open_cursors= 3000
    session_cached_cursors= 0
    -- open_cursors value is too high. I have checked that maximum usage by a single session is 12%.
    -- session_cached_cursors are 0 causing soft parsing. 500/600 is good number to start with.
    cursor_sharing exact may cause hard parses. But here, hard parsing is comparatively small, we can ignore this.
    From v$librarycache
    NAMESPACE             GETS    GETHITS GETHITRATIO       PINS PINHITRATIO    RELOADS INVALIDATIONS
    SQL AREA            162827      25127  .154317159  748901435  .999153087     107941         81886-- high invalidation count due to DDL like activities.
    -- high reloads due to small library cache.
    -- hit ratio too small.
    -- Need to pin frequently executed objects into library cache.
    P.S. Same question asked on Oracle_L, but due to formatting reasons, pasing duplicate contents here.
    Regards,
    Neeraj Bhatia
    Edited by: Neeraj.Bhatia2 on Jul 13, 2009 6:51 AM                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

    Thanks Charles. I really appreciate your efforts to diagnose the issue.
    I agree with you performance issue is caused by soft parsing, which can be solved by holding cursors (session_cached_cursors). It may be due to oversized shared pool, which is causing delay in searching child cursors.
    My second thought is, there is large number of reloads, which can be due to under-sized shared pool, if invalidation activities are not going (CBO statistics collection, DDL etc), cursors are being flushed frequently.
    CPU utilization is continuously high (above 90%). Pasting additional information from same AWR report.
    Namespace                Get Requests       Pct Miss        Pin Requests         Pct Miss      Reloads        Invalidations
    BODY                       225,345               0.76            4,965,541            0.15           5,533           0
    CLUSTER                   1,278                  1.41            2,542                  1.73           26                0
    INDEX                       5,982                  9.31            13,922                7.35           258               0
    SQL AREA                  141,465              54.10           27,831,235         1.21           69,863          19,085 Latch Miss Sources
    Latch Name             Where                                         NoWait Misses                 Sleeps             Waiter Sleeps
    library cache lock       kgllkdl: child: no lock handle             0                                   8,250                   5,792 Time Model Statistics
    Statistic Name                                                                           Time (s)                               % of DB Time
    sql execute elapsed time                                                           206,979.31                                      85.27
    PL/SQL execution elapsed time                                                    94,651.78                                      39.00
    DB CPU                                                                                     33,039.29                                      13.61
    parse time elapsed                                                                      22,635.47                                       9.33
    inbound PL/SQL rpc elapsed time                                                  14,763.48                                       6.08
    hard parse elapsed time                                                               14,136.77                                       5.82
    connection management call elapsed time                                        1,625.07                                       0.67
    PL/SQL compilation elapsed time                                                        760.76                                       0.31
    repeated bind elapsed time                                                               664.81                                       0.27
    hard parse (sharing criteria) elapsed time                                             500.11                                       0.21
    Java execution elapsed time                                                              252.95                                       0.10
    failed parse elapsed time                                                                   167.23                                       0.07
    hard parse (bind mismatch) elapsed time                                             124.11                                       0.05
    sequence load elapsed time                                                                23.34                                        0.01
    DB time                                                                                   242,720.12  
    background elapsed time                                                             11,645.52  
    background cpu time                                                                      247.25 According to this DB CPU is 65% utilization (DB CPU + Background CPU / Total Available CPU seconds). While at the same time DB host was 95% utilized (confirmed from DBA_HIST_SYSMETRIC_SUMMARY).
    Operating System Statistics
    Statistic                                         Total
    BUSY_TIME                             3,586,030
    IDLE_TIME                              1,545,064
    IOWAIT_TIME                              22,237
    NICE_TIME                                           0
    SYS_TIME                                  197,661
    USER_TIME                              3,319,452
    LOAD                                                 11
    RSRC_MGR_CPU_WAIT_TIME                  0
    PHYSICAL_MEMORY_BYTES          867,180
    NUM_CPUS                                           2

  • Busy buffer wait

    Hi
    I am getting huge buffer busy waits events on my database and its increasing
    following is the result of query on my database(9.2.0.8.0)
    SQL> select event,total_waits from v$system_event where event in ('free buffer waits','buffer busy waits')
    2 ;
    EVENT TOTAL_WAITS
    free buffer waits 118
    buffer busy waits 12827
    Also my "segment space management" is on "auto" on the tablespaces
    please someone let me know even when "segment space management" is on "auto" , why buffer busy waits is so huge
    And how to reduce this event
    Regards

    Hi,
    Try to post the out put for system wide if possible
    SELECT time, count, class
    FROM V$WAITSTAT
    ORDER BY time,count
    First of all check how many session till now impacted with this event. execute the below query and check
    SELECT count(*), event
    FROM v$session_wait
    WHERE wait_time = 0
         AND event NOT IN ('smon timer','pmon timer','rdbms ipc message',
                        'SQL*Net message from client')
    GROUP BY event
    ORDER BY 1 DESC;
    try to check p1, p2 and p3 value of below query, from there we can find the cause
    SELECT count(*) n_w , p1 FILE#, p2 BLK#, p3 CLASS
    FROM v$session_wait
    WHERE event = 'buffer busy waits'
    GROUP BY p1, p2, p3
    from the above query you will get the AFN and Block and wait class, use those inputs and check the actual segment cause, then we can seee what we need to do
    SELECT owner,segment_name,segment_type
    FROM dba_extents
    WHERE file_id=&file
    AND &blockid BETWEEN block_id AND block_id + blocks
    - Pavan Kumar N
    - Pavan Kumar N
    Updated with queries

  • Buffer busy waits after cnanging lob storage  to oracle securefiles

    Hi Everyone
    I need help resolving a problem with buffer busy waits in for a lob segment using securefiles for storage.
    During the load the application inserts a record into a table with the lob segment and update the record after, populating lob data. The block size on the table space holding the lob is 8 kb and the chunk size on the lob segment is set to 8kb. The average size of the lob record is 6 kb and the minimum size is 4.03 KB. The problem occurs only when running a job with a big number of relatively small inserts (4.03 Kb) in to the lob column . The table definition allow in-row storage and the ptcfree set to 10%. The same jobs runs without problem when using basicfiles storage for the lob column.
    According to [oracle white paper |http://www.oracle.com/technetwork/database/options/compression/overview/securefiles-131281.pdf] securefiles have a number of performance enhancements. I was particular interested to test Write Gather Cache as our application does a lot of relatively small inserts into a lob segment.
    Below is a fragment from the AWR report. It looks like all buffer busy waits belong to a free list class. The lob segment is located in an ASSM tablespace and I cannot increase freelists.
    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
    With the Partitioning option
    Host Name        Platform                         CPUs Cores Sockets Memory(GB)
    DB5              Microsoft Windows x86 64-bit        8     2              31.99
                  Snap Id      Snap Time      Sessions Curs/Sess
    Begin Snap:      1259 01-Apr-11 14:40:45       135       5.5
      End Snap:      1260 01-Apr-11 15:08:59       155      12.0
       Elapsed:               28.25 (mins)
       DB Time:              281.55 (mins)
    Cache Sizes                       Begin        End
    ~~~~~~~~~~~                  ---------- ----------
                   Buffer Cache:     2,496M     2,832M  Std Block Size:         8K
               Shared Pool Size:     1,488M     1,488M      Log Buffer:    11,888K
    Load Profile              Per Second    Per Transaction   Per Exec   Per Call
    ~~~~~~~~~~~~         ---------------    --------------- ---------- ----------
          DB Time(s):               10.0                0.1       0.01       0.00
           DB CPU(s):                2.8                0.0       0.00       0.00
           Redo size:        1,429,862.3            9,390.5
       Logical reads:          472,459.0            3,102.8
       Block changes:            9,849.7               64.7
      Physical reads:               61.1                0.4
    Physical writes:               98.6                0.7
          User calls:            2,718.8               17.9
              Parses:              669.8                4.4
         Hard parses:                2.2                0.0
    W/A MB processed:                1.1                0.0
              Logons:                0.1                0.0
            Executes:            1,461.0                9.6
           Rollbacks:                0.0                0.0
        Transactions:              152.3
    Top 5 Timed Foreground Events
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                               Avg
                                                              wait   % DB
    Event                                 Waits     Time(s)   (ms)   time Wait Class
    buffer busy waits                 1,002,549       8,951      9   53.0 Concurrenc
    DB CPU                                            4,724          28.0
    latch: cache buffers chains      11,927,297       1,396      0    8.3 Concurrenc
    direct path read                    121,767         863      7    5.1 User I/O
    enq: DW - contention                209,278         627      3    3.7 Other
    ?Host CPU (CPUs:    8 Cores:    2 Sockets: )
    ~~~~~~~~         Load Average
                   Begin       End     %User   %System      %WIO     %Idle
           38.7       3.5       57.9
    Instance CPU
    ~~~~~~~~~~~~
                  % of total CPU for Instance:      40.1
                  % of busy  CPU for Instance:      95.2
      %DB time waiting for CPU - Resource Mgr:       0.0
    Memory Statistics
    ~~~~~~~~~~~~~~~~~                       Begin          End
                      Host Mem (MB):     32,762.6     32,762.6
                       SGA use (MB):      4,656.0      4,992.0
                       PGA use (MB):        318.4        413.5
        % Host Mem used for SGA+PGA:        15.18        16.50
                                                                 Avg
                                            %Time Total Wait    wait    Waits   % DB
    Event                             Waits -outs   Time (s)    (ms)     /txn   time
    buffer busy waits             1,002,549     0      8,951       9      3.9   53.0
    latch: cache buffers chain   11,927,297     0      1,396       0     46.2    8.3
    direct path read                121,767     0        863       7      0.5    5.1
    enq: DW - contention            209,278     0        627       3      0.8    3.7
    log file sync                   288,785     0        118       0      1.1     .7
    SQL*Net more data from cli    1,176,770     0        103       0      4.6     .6
    Buffer Wait Statistics                DB/Inst: ORA11G/ora11g  Snaps: 1259-1260
    -> ordered by wait time desc, waits desc
    Class                    Waits Total Wait Time (s)  Avg Time (ms)
    free list              818,606               8,780             11
    undo header            512,358                 141              0
    2nd level bmb          105,816                  29              0
    -> Total Logical Reads:     800,688,490
    -> Captured Segments account for   19.8% of Total
               Tablespace                      Subobject  Obj.       Logical
    Owner         Name    Object Name            Name     Type         Reads  %Total
    EAG50NSJ   EAG50NSJ   SYS_LOB0000082335C00            LOB    127,182,208   15.88
    SYS        SYSTEM     TS$                             TABLE    7,641,808     .95
    Segments by Physical Reads            DB/Inst: ORA11G/ora11g  Snaps: 1259-1260
    -> Total Physical Reads:         103,481
    -> Captured Segments account for  224.4% of Total
               Tablespace                      Subobject  Obj.      Physical
    Owner         Name    Object Name            Name     Type         Reads  %Total
    EAG50NSJ   EAG50NSJ   SYS_LOB0000082335C00            LOB        218,858  211.50
    ....Best regards
    Yuri Kogun

    Hi Jonathan,
    I was puzzled by the number of logical reads as well. This hasn't happened when the lob was stored as a basic fille and I assumed that the database is able to store the records in-row when we switched to securefiles. With regards to ASSM, according to the documentation this is the only option when using securefiles.
    We did have high number of HW-enqueue waits in the database when running the test with basic files and had to set 44951 event
    alter system set EVENTS '44951 TRACE NAME CONTEXT FOREVER, LEVEL 1024' There are 2 application servers running 16 jobs each, so we should not have more than 32 sessions inserting the data in the same time but I need to check wheter jobs can be brocken to smaller peaces. I that case the number of concurrent session may be bigger. Each session is configured with bundle size of 30 and it will issue commit every 30 inserts.
    I am not sure how exactly the code does insert, as I've been told it should be straight insert and update I will be able to check this on Monday.
    Below is the extract from the AWR reports with top SQL, I could not find any SQL related to the $TS table in the report. The query to the V$SEGMENT_STATISTICS was executed by me during the job run.
    ?SQL ordered by Elapsed Time          DB/Inst: ORA11G/ora11g  Snaps: 1259-1260
    -> 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
    -> %Total - Elapsed Time  as a percentage of Total DB time
    -> %CPU   - CPU Time      as a percentage of Elapsed Time
    -> %IO    - User I/O Time as a percentage of Elapsed Time
    -> Captured SQL account for   91.3% of Total DB Time (s):          16,893
    -> Captured PL/SQL account for    0.1% of Total DB Time (s):          16,893
            Elapsed                  Elapsed Time
            Time (s)    Executions  per Exec (s)  %Total   %CPU    %IO    SQL Id
             7,837.5        119,351          0.07   46.4   28.3     .7 2zrh6mw372asz
    Module: JDBC Thin Client
    update JS_CHANNELDESTS set CHANNELID=:1, DESTID=:2, CHANNELDESTSTATUSDATE=:3, ST
    ATUS=:4, BINOFFSET=:5, BINNAME=:6, PAGECOUNT=:7, DATA=:8, SORTORDER=:9, PRINTFOR
    MAT=:10, ENVELOPEID=:11, DOCID=:12, CEENVELOPEID=:13, CHANNELTYPE=:14 where ID=:
    15
             7,119.0        115,997          0.06   42.1   23.1     .2 3vjx93vur4dw1
    Module: JDBC Thin Client
    insert into JS_CHANNELDESTS (CHANNELID, DESTID, CHANNELDESTSTATUSDATE, STATUS, B
    INOFFSET, BINNAME, PAGECOUNT, DATA, SORTORDER, PRINTFORMAT, ENVELOPEID, DOCID, C
    EENVELOPEID, CHANNELTYPE, ID) values (:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :
    11, :12, :13, :14, :15)
                85.6              2         42.80     .5   98.3     .0 cc19qha9pxsa4
    Module: SQL Developer
    select object_name, statistic_name, value from V$SEGMENT_STATISTICS
    where object_name = 'SYS_LOB0000082335C00011$$'
                35.0        111,900          0.00     .2   74.3    7.6 c5q15mpnbc43w
    Module: JDBC Thin Client
    insert into JS_ENVELOPES (BATCHID, TRANSACTIONNO, SPOOLID, JOBSETUPID, JOBSETUPN
    AME, SPOOLNAME, STEPNO, MASTERCHANNELJOBID, SORTKEY1, SORTKEY2, SORTKEY3, ID) va
    lues (:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12)
                34.9        111,902          0.00     .2   63.0    2.6 a0hmmbjwgwh1k
    Module: JDBC Thin Client
    insert into JS_CHANNELJOBPROPERTIES (NAME, VALUE, CHANNELJOBID, ID) values (:1,
    :2, :3, :4)
                29.2            950          0.03     .2   95.9     .1 du0hgjbn9vw0v
    Module: JDBC Thin Client
    SELECT * FROM JS_BATCHOVERVIEW WHERE BATCHID = :1
    ?SQL ordered by Executions            DB/Inst: ORA11G/ora11g  Snaps: 1259-1260
    -> %CPU   - CPU Time      as a percentage of Elapsed Time
    -> %IO    - User I/O Time as a percentage of Elapsed Time
    -> Total Executions:       2,476,038
    -> Captured SQL account for   96.0% of Total
                                                  Elapsed
    Executions   Rows Processed  Rows per Exec   Time (s)   %CPU    %IO    SQL Id
         223,581         223,540            1.0       22.4   63.7     .0 gz7n75pf57c
    Module: JDBC Thin Client
    SELECT SQ_CHANNELJOBPROPERTIES.NEXTVAL FROM DUAL
         120,624         120,616            1.0        8.1   99.0     .0 6y3ayqzubcb
    Module: JDBC Thin Client
    select batch0_.BATCHID as BATCHID0_0_, batch0_.BATCHNAME as BATCHNAME0_0_, batch
    0_.STARTDATE as STARTDATE0_0_, batch0_.PARFINDATE as PARFINDATE0_0_, batch0_.PRO
    CCOMPDATE as PROCCOMP5_0_0_, batch0_.BATCHSTATUS as BATCHSTA6_0_0_, batch0_.DATA
    FILE as DATAFILE0_0_, batch0_.BATCHCFG as BATCHCFG0_0_, batch0_.FINDATE as FINDA
         119,351         227,878            1.9    7,837.5   28.3     .7 2zrh6mw372a
    Module: JDBC Thin Client
    update JS_CHANNELDESTS set CHANNELID=:1, DESTID=:2, CHANNELDESTSTATUSDATE=:3, ST
    ATUS=:4, BINOFFSET=:5, BINNAME=:6, PAGECOUNT=:7, DATA=:8, SORTORDER=:9, PRINTFOR
    MAT=:10, ENVELOPEID=:11, DOCID=:12, CEENVELOPEID=:13, CHANNELTYPE=:14 where ID=:
    15
         116,033         223,892            1.9        8.0   92.2     .0 406wh6gd9nk
    Module: JDBC Thin Client
    select m_jobprope0_.CHANNELJOBID as CHANNELJ4_1_, m_jobprope0_.ID as ID1_, m_job
    prope0_.NAME as formula0_1_, m_jobprope0_.ID as ID4_0_, m_jobprope0_.NAME as NAM
    E4_0_, m_jobprope0_.VALUE as VALUE4_0_, m_jobprope0_.CHANNELJOBID as CHANNELJ4_4
    _0_ from JS_CHANNELJOBPROPERTIES m_jobprope0_ where m_jobprope0_.CHANNELJOBID=:1
         115,997         115,996            1.0    7,119.0   23.1     .2 3vjx93vur4d
    Module: JDBC Thin Client
    insert into JS_CHANNELDESTS (CHANNELID, DESTID, CHANNELDESTSTATUSDATE, STATUS, B
    INOFFSET, BINNAME, PAGECOUNT, DATA, SORTORDER, PRINTFORMAT, ENVELOPEID, DOCID, C
    EENVELOPEID, CHANNELTYPE, ID) values (:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :
    11, :12, :13, :14, :15)
         115,996         115,996            1.0       15.9   75.0    4.5 3h58syyk145
    Module: JDBC Thin Client
    insert into JS_DOCJOBS (CREATEDATE, EFFDATE, JURIST, LANG, IDIOM, DD, DDVID, USE
    RKEY1, USERKEY2, USERKEY3, USERKEY4, USERKEY5, USERKEY6, USERKEY7, USERKEY8, USE
    RKEY9, USERKEY10, USERKEY11, USERKEY12, USERKEY13, USERKEY14, USERKEY15, USERKEY
    16, USERKEY17, USERKEY18, USERKEY19, USERKEY20, REVIEWCASEID, ID) values (:1, :2
         115,440         115,422            1.0       11.5   63.3     .0 2vn581q83s6
    Module: JDBC Thin Client
    SELECT SQ_CHANNELDESTS.NEXTVAL FROM DUAL
    ...The tablespace holding the lob segment has system extent allocation and the number of blocks for the lob segments roughly the same as the number of blocks in allocated extents.
           select segment_name,  blocks, count (*)  
           from dba_extents where segment_name = 'SYS_LOB0000082335C00011$$'
           group by segment_name,  blocks
           order by blocks
    SEGMENT_NAME                                                                      BLOCKS                 COUNT(*)              
    SYS_LOB0000082335C00011$$                                                         8                      1                     
    SYS_LOB0000082335C00011$$                                                         16                     1                     
    SYS_LOB0000082335C00011$$                                                         128                    158                   
    SYS_LOB0000082335C00011$$                                                         256                    1                     
    SYS_LOB0000082335C00011$$                                                         1024                   120                   
    SYS_LOB0000082335C00011$$                                                         2688                   1                     
    SYS_LOB0000082335C00011$$                                                         8192                   117                   
    SELECT
        sum(ceil(dbms_lob.getlength(data)/8000))
        from EAG50NSJ.JS_CHANNELDESTS
    SUM(CEIL(DBMS_LOB.GETLENGTH(DATA)/8000))
    993216                                  
    select sum  (blocks)   from dba_extents where segment_name = 'SYS_LOB0000082335C00011$$'
    SUM(BLOCKS)           
    1104536                Below is the instance activity stats related to securefiles from the AWR report
    Statistic                                     Total     per Second     per Trans
    securefile allocation bytes           3,719,995,392    2,195,042.4      14,415.7
    securefile allocation chunks                380,299          224.4           1.5
    securefile bytes non-transformed      2,270,735,265    1,339,883.4       8,799.6
    securefile direct read bytes          1,274,585,088      752,089.2       4,939.3
    securefile direct read ops                  119,725           70.7           0.5
    securefile direct write bytes         3,719,995,392    2,195,042.4      14,415.7
    securefile direct write ops                 380,269          224.4           1.5
    securefile number of non-transfo            343,918          202.9           1.3Best regards
    Yuri
    Edited by: ykogun on 02-Apr-2011 13:33

  • Oracle 10.2.0.4 library cache contention,every event wait 64s! strange

    my database suddently very slow in a few seconds.After a while, all become normal.
    In awr report,I find no special sql.
    I paste two trouble time awr report here.
    If you have any more information for troubleshooting ,I will paste if you require.
    Thanks.
    AWR report1:
    WORKLOAD REPOSITORY report for
    DB Name DB Id Instance Inst Num Release RAC Host
    DB 3594421410 db2 2 10.2.0.4.0 YES db2
    Snap Id Snap Time Sessions Curs/Sess
    Begin Snap: 2342 17-Mar-09 21:30:23 521 1.1
    End Snap: 2344 17-Mar-09 22:30:25 498 1.0
    Elapsed: 60.03 (mins)
    DB Time: 750.95 (mins)
    Cache Sizes
    ~~~~~~~~~~~ Begin End
    Buffer Cache: 3,504M 3,504M Std Block Size: 8K
    Shared Pool Size: 1,200M 1,200M Log Buffer: 14,340K
    Load Profile
    ~~~~~~~~~~~~ Per Second Per Transaction
    Redo size: 18,182.64 2,754.51
    Logical reads: 326.19 49.41
    Block changes: 123.54 18.72
    Physical reads: 21.33 3.23
    Physical writes: 7.29 1.10
    User calls: 178.46 27.03
    Parses: 62.04 9.40
    Hard parses: 0.09 0.01
    Sorts: 2.00 0.30
    Logons: 0.20 0.03
    Executes: 63.12 9.56
    Transactions: 6.60
    % Blocks changed per Read: 37.87 Recursive Call %: 17.93
    Rollback per transaction %: 14.26 Rows per Sort: 44.63
    Instance Efficiency Percentages (Target 100%)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Buffer Nowait %: 99.99 Redo NoWait %: 99.95
    Buffer Hit %: 93.46 In-memory Sort %: 100.00
    Library Hit %: 99.52 Soft Parse %: 99.86
    Execute to Parse %: 1.70 Latch Hit %: 99.97
    Parse CPU to Parse Elapsd %: 0.82 % Non-Parse CPU: 98.60
    Shared Pool Statistics Begin End
    Memory Usage %: 78.60 78.77
    % SQL with executions>1: 99.38 99.27
    % Memory for SQL w/exec>1: 99.00 98.78
    Top 5 Timed Events Avg %Total
    ~~~~~~~~~~~~~~~~~~ wait Call
    Event Waits Time (s) (ms) Time Wait Class
    latch: library cache 736 47,078 63965 104.5 Concurrenc
    CPU time 236 0.5
    rdbms ipc reply 360 219 608 0.5 Other
    log file sync 20,469 137 7 0.3 Commit
    gc cr block 2-way 35,641 102 3 0.2 Cluster
    AWR report 2:
    DB Name DB Id Instance Inst Num Release RAC Host
    db 3594421410 db2 2 10.2.0.4.0 YES yt-db2
    Snap Id Snap Time Sessions Curs/Sess
    Begin Snap: 2364 18-Mar-09 08:30:29 497 1.1
    End Snap: 2365 18-Mar-09 08:42:28 511 1.0
    Elapsed: 11.99 (mins)
    DB Time: 277.14 (mins)
    Cache Sizes
    ~~~~~~~~~~~ Begin End
    Buffer Cache: 3,504M 3,504M Std Block Size: 8K
    Shared Pool Size: 1,200M 1,200M Log Buffer: 14,340K
    Load Profile
    ~~~~~~~~~~~~ Per Second Per Transaction
    Redo size: 23,306.73 2,556.74
    Logical reads: 337.31 37.00
    Block changes: 159.74 17.52
    Physical reads: 0.72 0.08
    Physical writes: 9.74 1.07
    User calls: 274.07 30.06
    Parses: 95.29 10.45
    Hard parses: 0.04 0.00
    Sorts: 2.52 0.28
    Logons: 0.19 0.02
    Executes: 95.71 10.50
    Transactions: 9.12
    % Blocks changed per Read: 47.36 Recursive Call %: 9.14
    Rollback per transaction %: 11.13 Rows per Sort: 32.48
    Instance Efficiency Percentages (Target 100%)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Buffer Nowait %: 98.81 Redo NoWait %: 100.00
    Buffer Hit %: 99.79 In-memory Sort %: 100.00
    Library Hit %: 99.86 Soft Parse %: 99.95
    Execute to Parse %: 0.44 Latch Hit %: 99.94
    Parse CPU to Parse Elapsd %: 40.91 % Non-Parse CPU: 81.90
    Shared Pool Statistics Begin End
    Memory Usage %: 79.91 80.01
    % SQL with executions>1: 99.52 99.52
    % Memory for SQL w/exec>1: 98.83 98.77
    Top 5 Timed Events Avg %Total
    ~~~~~~~~~~~~~~~~~~ wait Call
    Event Waits Time (s) (ms) Time Wait Class
    latch free 176 4,391 24950 26.4 Other
    gc buffer busy 3,726 3,335 895 20.1 Cluster
    gc cr multi block request 4,165 2,204 529 13.3 Cluster
    gc current grant busy 3,938 1,798 457 10.8 Cluster
    latch: cache buffers chains 124 1,548 12487 9.3 Concurrenc
    ^LRAC Statistics DB/Inst: db/db2 Snaps: 2364-2365
    Begin End
    Number of Instances: 2 2
    Global Cache Load Profile
    ~~~~~~~~~~~~~~~~~~~~~~~~~ Per Second Per Transaction
    Global Cache blocks received: 19.36 2.12
    Global Cache blocks served: 19.39 2.13
    GCS/GES messages received: 63.76 6.99
    GCS/GES messages sent: 63.64 6.98
    DBWR Fusion writes: 2.58 0.28
    Estd Interconnect traffic (KB) 334.84
    Edited by: gaoyafang on 2009-3-18 上午12:46

    my database suddently very slow in a few seconds.After a while, all become normal.
    In awr report,I find no special sql.
    I paste two trouble time awr report here.
    If you have any more information for troubleshooting ,I will paste if you require.
    Thanks.
    AWR report1:
    WORKLOAD REPOSITORY report for
    DB Name DB Id Instance Inst Num Release RAC Host
    DB 3594421410 db2 2 10.2.0.4.0 YES db2
    Snap Id Snap Time Sessions Curs/Sess
    Begin Snap: 2342 17-Mar-09 21:30:23 521 1.1
    End Snap: 2344 17-Mar-09 22:30:25 498 1.0
    Elapsed: 60.03 (mins)
    DB Time: 750.95 (mins)
    Cache Sizes
    ~~~~~~~~~~~ Begin End
    Buffer Cache: 3,504M 3,504M Std Block Size: 8K
    Shared Pool Size: 1,200M 1,200M Log Buffer: 14,340K
    Load Profile
    ~~~~~~~~~~~~ Per Second Per Transaction
    Redo size: 18,182.64 2,754.51
    Logical reads: 326.19 49.41
    Block changes: 123.54 18.72
    Physical reads: 21.33 3.23
    Physical writes: 7.29 1.10
    User calls: 178.46 27.03
    Parses: 62.04 9.40
    Hard parses: 0.09 0.01
    Sorts: 2.00 0.30
    Logons: 0.20 0.03
    Executes: 63.12 9.56
    Transactions: 6.60
    % Blocks changed per Read: 37.87 Recursive Call %: 17.93
    Rollback per transaction %: 14.26 Rows per Sort: 44.63
    Instance Efficiency Percentages (Target 100%)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Buffer Nowait %: 99.99 Redo NoWait %: 99.95
    Buffer Hit %: 93.46 In-memory Sort %: 100.00
    Library Hit %: 99.52 Soft Parse %: 99.86
    Execute to Parse %: 1.70 Latch Hit %: 99.97
    Parse CPU to Parse Elapsd %: 0.82 % Non-Parse CPU: 98.60
    Shared Pool Statistics Begin End
    Memory Usage %: 78.60 78.77
    % SQL with executions>1: 99.38 99.27
    % Memory for SQL w/exec>1: 99.00 98.78
    Top 5 Timed Events Avg %Total
    ~~~~~~~~~~~~~~~~~~ wait Call
    Event Waits Time (s) (ms) Time Wait Class
    latch: library cache 736 47,078 63965 104.5 Concurrenc
    CPU time 236 0.5
    rdbms ipc reply 360 219 608 0.5 Other
    log file sync 20,469 137 7 0.3 Commit
    gc cr block 2-way 35,641 102 3 0.2 Cluster
    AWR report 2:
    DB Name DB Id Instance Inst Num Release RAC Host
    db 3594421410 db2 2 10.2.0.4.0 YES yt-db2
    Snap Id Snap Time Sessions Curs/Sess
    Begin Snap: 2364 18-Mar-09 08:30:29 497 1.1
    End Snap: 2365 18-Mar-09 08:42:28 511 1.0
    Elapsed: 11.99 (mins)
    DB Time: 277.14 (mins)
    Cache Sizes
    ~~~~~~~~~~~ Begin End
    Buffer Cache: 3,504M 3,504M Std Block Size: 8K
    Shared Pool Size: 1,200M 1,200M Log Buffer: 14,340K
    Load Profile
    ~~~~~~~~~~~~ Per Second Per Transaction
    Redo size: 23,306.73 2,556.74
    Logical reads: 337.31 37.00
    Block changes: 159.74 17.52
    Physical reads: 0.72 0.08
    Physical writes: 9.74 1.07
    User calls: 274.07 30.06
    Parses: 95.29 10.45
    Hard parses: 0.04 0.00
    Sorts: 2.52 0.28
    Logons: 0.19 0.02
    Executes: 95.71 10.50
    Transactions: 9.12
    % Blocks changed per Read: 47.36 Recursive Call %: 9.14
    Rollback per transaction %: 11.13 Rows per Sort: 32.48
    Instance Efficiency Percentages (Target 100%)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Buffer Nowait %: 98.81 Redo NoWait %: 100.00
    Buffer Hit %: 99.79 In-memory Sort %: 100.00
    Library Hit %: 99.86 Soft Parse %: 99.95
    Execute to Parse %: 0.44 Latch Hit %: 99.94
    Parse CPU to Parse Elapsd %: 40.91 % Non-Parse CPU: 81.90
    Shared Pool Statistics Begin End
    Memory Usage %: 79.91 80.01
    % SQL with executions>1: 99.52 99.52
    % Memory for SQL w/exec>1: 98.83 98.77
    Top 5 Timed Events Avg %Total
    ~~~~~~~~~~~~~~~~~~ wait Call
    Event Waits Time (s) (ms) Time Wait Class
    latch free 176 4,391 24950 26.4 Other
    gc buffer busy 3,726 3,335 895 20.1 Cluster
    gc cr multi block request 4,165 2,204 529 13.3 Cluster
    gc current grant busy 3,938 1,798 457 10.8 Cluster
    latch: cache buffers chains 124 1,548 12487 9.3 Concurrenc
    ^LRAC Statistics DB/Inst: db/db2 Snaps: 2364-2365
    Begin End
    Number of Instances: 2 2
    Global Cache Load Profile
    ~~~~~~~~~~~~~~~~~~~~~~~~~ Per Second Per Transaction
    Global Cache blocks received: 19.36 2.12
    Global Cache blocks served: 19.39 2.13
    GCS/GES messages received: 63.76 6.99
    GCS/GES messages sent: 63.64 6.98
    DBWR Fusion writes: 2.58 0.28
    Estd Interconnect traffic (KB) 334.84
    Edited by: gaoyafang on 2009-3-18 上午12:46

  • Too much time on network wait!

    At peak time my apex pages are very very slow. I open Home>Utilities>Database Monitor>Sessions>Waits, and see all wait classes are network. I have already changed shared_servers to 100. But all waiting sessions are still waiting for network. How to improve it? Thank you!

    John,
    it was in the context of a cross-platform 9.2 to 11.1 migration that
    we decided to opt for EPG using the APEX bundle integral to the db
    packages (thus, we are still running 3.0.1). I think some documents
    mentioned certain advantages of this architecture, but meanwhile I
    have my doubts ...
    To install APEX, we simply followed Note:457621.1 (How to Configure
    Oracle Application Express (APEX) & the Embedded PL/SQL Gateway (EPG)
    in an 11G DB).
    We currently have a SR open for weeks, were it is tried to track down
    the reason for those numerous virtual circuit waits, and found that
    all sessions emenate from APEX sessions (with various users and
    various apps). Thus, it is quite difficult to track down the reason
    for those waits.
    Is there an easy procedure to switch to Apache instead of EPG?
    Regards, Thomas

  • Query on dba_free_space ends in wait by event db file sequential read

    Hello All,
    Env: 10gR2 on WinNT
    I gave the query
    select tablespace_name,sum(bytes)/1024/1024 from dba_free_space group by tablespace_name and its waiting for ever.
    I checked the wait event from v$session and its "db file sequential read".
    I put a trace on the session before the running the above query:
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.06       0.06          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        2      0.06       0.06          0          0          0           0
    Misses in library cache during parse: 1
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      db file sequential read                     13677        0.16        151.34
      SQL*Net message to client                       1        0.00          0.00
      db file scattered read                        281        0.01          0.53
      latch: cache buffers lru chain                  2        0.00          0.00
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse    13703      0.31       0.32          0          0          0           0
    Execute  14009      0.75       0.83          0          0          0           0
    Fetch    14139      0.48       0.74         26      56091          0       15496
    total    41851      1.54       1.89         26      56091          0       15496
    Misses in library cache during parse: 16
    Misses in library cache during execute: 16
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      db file sequential read                        26        0.00          0.12
        1  user  SQL statements in session.
    14010  internal SQL statements in session.
    14011  SQL statements in session.I took the AWR Report (for 1 hr time period) and the top 5 events came out as,
    Event                                 Waits    Time (s)   (ms)   Time Wait Class
    db file sequential read           1,134,643       7,580      7   56.8   User I/O
    db file scattered read              940,880       5,025      5   37.7   User I/O
    CPU time                                            967           7.2
    control file sequential read          4,987           3      1    0.0 System I/O
    control file parallel write           2,408           1      1    0.0 System I/O The PHYRDS(from dba_hist_filestatxs) on my system01.dbf is 161,028,980 for the latest snap.
    Could someone throw some light into what is happening here ?
    TIA,
    JJ

    Under some circumstances querying the dictionary can be slow, usually because of problems with bad execution plans related to bad statistics, try to gather statistics using dbms_stats.gather_fixed_objects_stats(); it has worked for me before.
    You can also read Note 414256.1 Poor Performance For Tablespace Page Display In Grid Control Console which in addition points to a possible problem with the recycle bin.
    HTH
    Enrique

Maybe you are looking for

  • Jumpy USB Mouse

    I've been using a USB mouse since I've had my laptop, and it's always worked fine until a week or so ago. When I turn my computer on the mouse will work just fine, but after a while it starts jumping around the screen whenever I move the mouse. I'm u

  • TDS certificate numbers according to Business Place for one key

    Dear all, I am trying to generated TDS certificates through J1INCERT.  I am able to generated certificate numbers also. But I want to generate the certificate numbers according to my business place.   EX: I assigned number range as 200001 to 299999.

  • Zen V

    Yesterday I bought a brand new Zen V. I connected it via USB, until it had its battery loaded 00%, then installed the CD and managed to upload 00~ songs until it froze. Then had to reset the player and the songs are still there and play ok. The thing

  • How do I make After Effects CS5.5 preview in full FPS?

    I have After Effects CS5.5 and whenever I put a clip into it and try to play the clip in a preview I get a message in the player that says its playing at a certain frame rate out of the frame rate it should be and then in parentheses (not realtime).

  • Problems with receiving emails

    I just got this phone for Christmas and set up both email accounts on my phone.  Up until now, I've been receiving my emails just fine on my phone and they've always loaded right, notified me, etc.  Yesterday, I got an email in both inboxes (on my ph