Top 5 event class slave wait

Dear Support,
I run the AWR report. It show the top 5 event is class slave wait 70second then follow by CPU time. May i know what is class slave wait event. Thanks
Regard
William

10g is a marketing label not a version number.
SELECT * FROM v$version;Don't describe the AWR report part your are seeing ... Ctrl-C then Ctrl-V ... and post it between tags so we can read it.

Similar Messages

Sessions with Event "class slave wait" taking 100% CPU

Hi experts,
I have an issue in an 11.2.0.2 RAC database with 2 standby nodes that are driving me nuts.
All started when I've been told there are 2 Oracle processes consuming too much CPU in the environment.
I found 2 processes which takes 100% CPU each. These processes are Oracle processes into the DB and checking them out although they are registered in v$process and v$session, there is nothing related to them in v$bgprocess so I could not find out which oracle processes started these 2 OS processes.
The view v$session shows them ACTIVE in the event "class slave wait". There aren't too much information about this event, at least I failed to find...
Using dbms_monitor and dbms_system to create trace events did not create any tracefile. Only ORADEBUG was able to create events but with nearly no information inside the trace files.
Questions I need to have answered or at least hints that I can follow to find the answer:
1) what is causing the CPUs to be consumed at 100%? Which process?
2) Why does these processes are using that much of CPU?
3) What can be done to safely get over it?
Honestly I don't know where else to look at except trying to get some help. Could someone give me a hand please?
BR,
Lauro Ojeda
Edited by: LauroOjeda on 26/01/2013 06:44

Hi Pal, thanks for your reply!
Here are the answers:
1. If it is RAC there is no such construct as a "standby node" and you say you have two of them. Please be specific ... is this RAC or Data Guard or a combination? Or do you have a three node cluster with all services pointing to only a single server wasting all of the resources of the other three?
A: This is a combination of them. We have 2 nodes in a RAC environment shipping logs to two physical standby databases in another site.
2. Two processes can not be at 100% of CPU any more than I can be 200% awake. Please show us how you arrived at this conclusion, on what hardware and operating system, and include a formatted (read the FAQ to learn how) extract showing what you are seeing.
A: top in Linux shows two oracle processes consuming 100% (or nearly of it) of 1 CPU each. This is a 16 cores server (each primary node) so 2 of these are working on full capacity to service the described processes.
3. What processes? Name them and again run a SQL statement and post the output so we can see what you are looking at.
A: Like I said before I failed to find which background process they belongs to as there are no indications of them in v$bgprocess and in v$session/v$process either. I can see them in v$process and v$session but again, there are no indications of for which bg process they belong to.
4. Is anything slow? Are there any problems with the system or are you only reacting to two numbers you think are too high?
A: No, system is not slow because of that but the client wants to investigate and have it sorted as it is not normal.
Additionally I found a bug in metalink which seems to be the culprit, but I'm unsure yet. This is Bug 12929268 : HIGH CPU ON ORA_O00N PROCESS
Is any other information that I may provide you?
Thanks for help!
Lauro Ojeda

Lot of sessions with wait event - jobq slave wait

Hi All,
My db version is 10.2.0.4.0
I have scheduled jobs through dbms_scheduler with repeat_interval of 20 mins(this for refresh of mviews).
Now the job is in running state for a long time. then i checked the sessions..
I have five session with wait event - "jobq slave wait"
I check job_queue_parameter - 10
select count(1) from dba_jobs;
COUNT(1)
8
Now the job is in running state for a long time...
Can someone help me how to proceed...
Thanks,
Suresh S.

Post Operating System (OS) name & version for DB server system.
Post results of
SELECT * from v$version
does following SQL return any rows? If so, they point to problem area.
SELECT DECODE(request,0,'Holder: ','Waiter: ')||sid sess,
id1, id2, lmode, request, type
FROM V$LOCK
WHERE (id1, id2, type) IN
(SELECT id1, id2, type FROM V$LOCK WHERE request>0)
ORDER BY id1, request
/

Metrics "Database Time Spent Waiting (%) is ar 100 for event class "Applica

Metrics "Database Time Spent Waiting (%) is ar 100 for event class "Application".
i get this error in database. help me regarding this error.

Streams AQ: qmn coordinator idle wait     31     16     42598     1374.12     425976281     989870553     2723168908     6     Idle
Streams AQ: qmn slave idle wait     15     0     41599     2773.27     415990747     1830121438     2723168908     6     Idle
Streams AQ: waiting for messages in the queue     83     83     41478     499.73     414776290     3955192389     2723168908     6     Idle
jobq slave wait     134     131     39906     297.8     399055017     782339817     2723168908     6     Idle
Streams AQ: waiting for time management or cleanup tasks     7     4     3778     539.71     37779540     3702640206     2723168908     6     Idle
class slave wait     3     3     1499     499.54     14986144     1055154682     2723168908     6     Idle
Streams AQ: qmn coordinator waiting for slave to start     2     1     500     249.95     4999066     1565566389     1893977003     0     Other
LGWR wait for redo copy     1     0     0     0     1     4266849434     1893977003     0     Other

Jobq slave wait taking too long

Dear all,
On our production database server, I often see certain sessions taking way too long with the wait event "jobq slave wait".
how can I prevent "jobq slave wait" events ? (or at least make it shorter or less frequent)
I tried to search about this but could not find a good source that could help me in this regard.
Please help.
DB Version : 10.1.0.5 using Real Application Clusters
OS Version : Windows 2003
Thanks in advance.

Hi Can you check how may jobs have scheduled or there may materialized views which keeps refreshing and their refresh interval
You will get clear picture of number of jobs from below sql
select count(*) from dba_jobs;
and how many job_queue_procesess you have in your database ,use below sql
show parameter job_quere-
If you have more scheduled jobs than above parameter and which keep repeating after some time then better increase the parameter job_queue_process .
Its dyanamic parameter.No need to restart the d/b

Jobq slave wait

Hi All,
I have scheduled a job through a 3rd party software, where it actually triggers a job in the database. For some reason the job is running successfully for many months and we are facing issue these days, when i went into the database and searched for the session from v$session, the session is still active, but it is in "waiting" state.
After further research, i found that the event name is "jobq slave wait". The event name itself tells us that, it is idle process and doing nothing.
I want to still further know about the event "jobq slave wait".
Thanks,
!!!!venkat!!!!

Ok, that means that, if at all we receive this kind of events in future, we simply need to kill the session (sid).
Or is there any other thing which needs to be done. But we need to know why the session went to idle state, is it becuase it is not doing any activity from DB/application??
or is it like its activity complete but waiting to come out of the session??

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.

Metrics "Database Time Spent Waiting (%)" is at 23,02268 for event class "C

Hi,
on 10g,
I have this alerte in DB control home page :
Metrics "Database Time Spent Waiting (%)" is at 23,02268 for event class "Commit"
Should I do any action/correction ?
Thank you.

user522961 wrote:
Thank you.
Here is the result :
SQL> select sid, event, p1, p2, p3 from v$session_wait where event not in ('SQL*Net message from client', 'rdbms ipc message', 'pipe get', 'PL/SQL lock timer',
'pmon timer');
SID EVENT                                                                    P1         P2      P3
163 jobq slave wait                                                           0          0       0
165 Streams AQ: waiting for messages in the queue                          8808 875118900       5
166 SQL*Net message to client                                        1413697536          1       0
167 wait for unread message on broadcast channel                      865275080 865241852       0
169 Streams AQ: qmn slave idle wait                                           0          0       0
170 Streams AQ: waiting for time management or cleanup tasks                  0          0       0
179 Streams AQ: qmn coordinator idle wait                                     0          0       0
194 smon timer                                                              300          0       0
8 rows selected.Regards.As per above result, it seems there was no critical wait event or something occurs during frequent commits.
If you know which application or batch processing caused this, for the best result, you should rerun this query during that workload.

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.

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

Top Event: LNS wait for LGWR redo

CONFIGURATION: 10.1.0.5.0 with DataGuard On RedHat.
We often find the wait event called "LNS wait for LGWR redo" into the "Top 5 Timed Events" section of the AWR report.
I'm unable to find a complete descrition of this event.
Can I minimize this kind of wait?

I cannot find the exact wait name into the note.
The most similar is:
"LNS wait on LGWR"
     This wait event monitors the amount of time spent by the network server
     waiting to receive messages on KSR channels from the log writer (LGWR)
     process.
Am I right?

Metrics "Database Time Spent Waiting (%)" is at 0 for event class

I am getting following warnings ,may anyone expalin it to me
Metrics "Database Time Spent Waiting (%)" is at 0 for event class "Configuration"
Metrics "Database Time Spent Waiting (%)" is at .40757 for event class "Network"
Metrics "Database Time Spent Waiting (%)" is at .40757 for event class "Cluster"

You should have a look into Database Performance Guide.
This metrics shows how much time your database is spending on waiting for wait events of folowing classes
Best Regards
Krystian Zieja / mob

Metrics "Database Time Spent Waiting (%)" is at 83.25965 for event class

Hello,
when i log into em console, i have alert below,
"Metrics "Database Time Spent Waiting (%)" is at 83.25965 for event class "Commit"
so, what do i need to do? i have no idea about this,
is it a critical error? is there any solution?
thank you
Ugur

Ugur MIHCI wrote:
Hello,
when i log into em console, i have alert below,
"Metrics "Database Time Spent Waiting (%)" is at 83.25965 for event class "Commit"
so, what do i need to do? i have no idea about this,
is it a critical error? is there any solution?
thank you
UgurProbably what you would want to do in this case is to first determine which wait events are in that event class:
{code}
SELECT
NAME
FROM
V$EVENT_NAME
WHERE
WAIT_CLASS='Commit';
NAME
log file sync
enq: BB - 2PC across RAC instances
{code}
If you are not using RAC, the second of the above wait events probably does not apply. Next, you need to determine what the "log file sync" wait means, so you might do a Google search of the Oracle documentation. Assume that you are using Oracle Database 10.2.0.x - you would then search for:
{code}
site:download.oracle.com "log file sync" 102
{code}
In my search, the first link was a page from the Oracle Database Performance Tuning Guide:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/instance_tune.htm
That page contained the following quote:
"log file sync
General area: I/O, over- committing
Possible cause: Slow disks that store the online logs, Un-batched commits
Look for: Check the disks that house the online redo logs for resource contention. Check the number of transactions (commits + rollbacks) each second, from V$SYSSTAT."
Excessive waits for log file sync may also be caused by lack of available CPU time - an overloaded CPU.
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.

Log file sync top event during performance test -av 36ms

Hi,
During the performance test for our product before deployment into product i see "log file sync" on top with Avg wait (ms) being 36 which i feel is too high.
                                                           Avg
                                                          wait   % DB
Event                                 Waits     Time(s)   (ms)   time Wait Class
log file sync                       208,327       7,406     36   46.6 Commit
direct path write                   646,833       3,604      6   22.7 User I/O
DB CPU                                            1,599          10.1
direct path read temp             1,321,596         619      0    3.9 User I/O
log buffer space                      4,161         558    134    3.5 ConfiguratAlthough testers are not complaining about the performance of the appplication , we ,DBAs, are expected to be proactive about the any bad signals from DB.
I am not able to figure out why "log file sync" is having such slow response.
Below is the snapshot from the load profile.
              Snap Id      Snap Time      Sessions Curs/Sess
Begin Snap:    108127 16-May-13 20:15:22       105       6.5
End Snap:    108140 16-May-13 23:30:29       156       8.9
   Elapsed:              195.11 (mins)
   DB Time:              265.09 (mins)
Cache Sizes                       Begin        End
~~~~~~~~~~~                  ---------- ----------
               Buffer Cache:     1,168M     1,136M Std Block Size:         8K
           Shared Pool Size:     1,120M     1,168M      Log Buffer:    16,640K
Load Profile              Per Second    Per Transaction   Per Exec   Per Call
~~~~~~~~~~~~         ---------------    --------------- ---------- ----------
      DB Time(s):                1.4                0.1       0.02       0.01
       DB CPU(s):                0.1                0.0       0.00       0.00
       Redo size:          607,512.1           33,092.1
   Logical reads:            3,900.4              212.5
   Block changes:            1,381.4               75.3
Physical reads:              134.5                7.3
Physical writes:              134.0                7.3
      User calls:              145.5                7.9
          Parses:               24.6                1.3
     Hard parses:                7.9                0.4
W/A MB processed:          915,418.7           49,864.2
          Logons:                0.1                0.0
        Executes:               85.2                4.6
       Rollbacks:                0.0                0.0
    Transactions:               18.4Some of the top background wait events:
^LBackground Wait Events       DB/Inst: Snaps: 108127-108140
-> ordered by wait time desc, waits desc (idle events last)
-> Only events with Total Wait Time (s) >= .001 are shown
-> %Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0
                                                             Avg
                                        %Time Total Wait    wait    Waits   % bg
Event                             Waits -outs   Time (s)    (ms)     /txn   time
log file parallel write         208,563     0      2,528      12      1.0   66.4
db file parallel write            4,264     0        785     184      0.0   20.6
Backup: sbtbackup                     1     0        516 516177      0.0   13.6
control file parallel writ        4,436     0         97      22      0.0    2.6
log file sequential read          6,922     0         95      14      0.0    2.5
Log archive I/O                   6,820     0         48       7      0.0    1.3
os thread startup                   432     0         26      60      0.0     .7
Backup: sbtclose2                     1     0         10   10094      0.0     .3
db file sequential read           2,585     0          8       3      0.0     .2
db file single write                560     0          3       6      0.0     .1
log file sync                        28     0          1      53      0.0     .0
control file sequential re       36,326     0          1       0      0.2     .0
log file switch completion            4     0          1     207      0.0     .0
buffer busy waits                     5     0          1     116      0.0     .0
LGWR wait for redo copy             924     0          1       1      0.0     .0
log file single write                56     0          1       9      0.0     .0
Backup: sbtinfo2                      1     0          1     500      0.0     .0During a previous perf test , things didnt look this bad for "log file sync. Few sections from the comparision report(awrddprt.sql)
{code}
Workload Comparison
~~~~~~~~~~~~~~~~~~~ 1st Per Sec 2nd Per Sec %Diff 1st Per Txn 2nd Per Txn %Diff
DB time: 0.78 1.36 74.36 0.02 0.07 250.00
CPU time: 0.18 0.14 -22.22 0.00 0.01 100.00
Redo size: 573,678.11 607,512.05 5.90 15,101.84 33,092.08 119.13
Logical reads: 4,374.04 3,900.38 -10.83 115.14 212.46 84.52
Block changes: 1,593.38 1,381.41 -13.30 41.95 75.25 79.38
Physical reads: 76.44 134.54 76.01 2.01 7.33 264.68
Physical writes: 110.43 134.00 21.34 2.91 7.30 150.86
User calls: 197.62 145.46 -26.39 5.20 7.92 52.31
Parses: 7.28 24.55 237.23 0.19 1.34 605.26
Hard parses: 0.00 7.88 100.00 0.00 0.43 100.00
Sorts: 3.88 4.90 26.29 0.10 0.27 170.00
Logons: 0.09 0.08 -11.11 0.00 0.00 0.00
Executes: 126.69 85.19 -32.76 3.34 4.64 38.92
Transactions: 37.99 18.36 -51.67
First Second Diff
1st 2nd
Event Wait Class Waits Time(s) Avg Time(ms) %DB time Event Wait Class Waits Time(s) Avg Time
(ms) %DB time
SQL*Net more data from client Network 2,133,486 1,270.7 0.6 61.24 log file sync Commit 208,355 7,407.6
35.6 46.57
CPU time N/A 487.1 N/A 23.48 direct path write User I/O 646,849 3,604.7
5.6 22.66
log file sync Commit 99,459 129.5 1.3 6.24 log file parallel write System I/O 208,564 2,528.4
12.1 15.90
log file parallel write System I/O 100,732 126.6 1.3 6.10 CPU time N/A 1,599.3
N/A 10.06
SQL*Net more data to client Network 451,810 103.1 0.2 4.97 db file parallel write System I/O 4,264 784.7 1
84.0 4.93
-direct path write User I/O 121,044 52.5 0.4 2.53 -SQL*Net more data from client Network 7,407,435 279.7
0.0 1.76
-db file parallel write System I/O 986 22.8 23.1 1.10 -SQL*Net more data to client Network 2,714,916 64.6
0.0 0.41
{code}
*To sum it sup:
1. Why is the IO response getting such an hit during the new perf test? Please suggest*
2. Does the number of DB writer impact "log file sync" wait event? We have only one DB writer as the number of cpu on the host is only 4
{code}
select *from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
PL/SQL Release 11.1.0.7.0 - Production
CORE 11.1.0.7.0 Production
TNS for HPUX: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - Production
{code}
Please let me know if you would like to see any other stats.
Edited by: Kunwar on May 18, 2013 2:20 PM

1. A snapshot interval of 3 hours always generates meaningless results
Below are some details from the 1 hour interval AWR report.
Platform                         CPUs Cores Sockets Memory(GB)
HP-UX IA (64-bit)                   4     4       3      31.95
              Snap Id      Snap Time      Sessions Curs/Sess
Begin Snap:    108129 16-May-13 20:45:32       140       8.0
End Snap:    108133 16-May-13 21:45:53       150       8.8
   Elapsed:               60.35 (mins)
   DB Time:              140.49 (mins)
Cache Sizes                       Begin        End
~~~~~~~~~~~                  ---------- ----------
               Buffer Cache:     1,168M     1,168M Std Block Size:         8K
           Shared Pool Size:     1,120M     1,120M      Log Buffer:    16,640K
Load Profile              Per Second    Per Transaction   Per Exec   Per Call
~~~~~~~~~~~~         ---------------    --------------- ---------- ----------
      DB Time(s):                2.3                0.1       0.03       0.01
       DB CPU(s):                0.1                0.0       0.00       0.00
       Redo size:          719,553.5           34,374.6
   Logical reads:            4,017.4              191.9
   Block changes:            1,521.1               72.7
Physical reads:              136.9                6.5
Physical writes:              158.3                7.6
      User calls:              167.0                8.0
          Parses:               25.8                1.2
     Hard parses:                8.9                0.4
W/A MB processed:          406,220.0           19,406.0
          Logons:                0.1                0.0
        Executes:               88.4                4.2
       Rollbacks:                0.0                0.0
    Transactions:               20.9
Top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                           Avg
                                                          wait   % DB
Event                                 Waits     Time(s)   (ms)   time Wait Class
log file sync                        73,761       6,740     91   80.0 Commit
log buffer space                      3,581         541    151    6.4 Configurat
DB CPU                                              348           4.1
direct path write                   238,962         241      1    2.9 User I/O
direct path read temp               487,874         174      0    2.1 User I/O
Background Wait Events       DB/Inst: Snaps: 108129-108133
-> ordered by wait time desc, waits desc (idle events last)
-> Only events with Total Wait Time (s) >= .001 are shown
-> %Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0
                                                             Avg
                                        %Time Total Wait    wait    Waits   % bg
Event                             Waits -outs   Time (s)    (ms)     /txn   time
log file parallel write          61,049     0      1,891      31      0.8   87.8
db file parallel write            1,590     0        251     158      0.0   11.6
control file parallel writ        1,372     0         56      41      0.0    2.6
log file sequential read          2,473     0         50      20      0.0    2.3
Log archive I/O                   2,436     0         20       8      0.0     .9
os thread startup                   135     0          8      60      0.0     .4
db file sequential read             668     0          4       6      0.0     .2
db file single write                200     0          2       9      0.0     .1
log file sync                         8     0          1     152      0.0     .1
log file single write                20     0          0      21      0.0     .0
control file sequential re       11,218     0          0       0      0.1     .0
buffer busy waits                     2     0          0     161      0.0     .0
direct path write                     6     0          0      37      0.0     .0
LGWR wait for redo copy             380     0          0       0      0.0     .0
log buffer space                      1     0          0      89      0.0     .0
latch: cache buffers lru c            3     0          0       1      0.0     .0     2 The log file sync is a result of commit --> you are committing too often, maybe even every individual record.
Thanks for explanation. +Actually my question is WHY is it so slow (avg wait of 91ms)+3 Your IO subsystem hosting the online redo log files can be a limiting factor.
We don't know anything about your online redo log configuration
Below is my redo log configuration.
    GROUP# STATUS TYPE    MEMBER                                                       IS_
         1         ONLINE /oradata/fs01/PERFDB1/redo_1a.log                           NO
         1         ONLINE /oradata/fs02/PERFDB1/redo_1b.log                           NO
         2         ONLINE /oradata/fs01/PERFDB1/redo_2a.log                           NO
         2         ONLINE /oradata/fs02/PERFDB1/redo_2b.log                           NO
         3         ONLINE /oradata/fs01/PERFDB1/redo_3a.log                           NO
         3         ONLINE /oradata/fs02/PERFDB1/redo_3b.log                           NO
6 rows selected.
04:13:14 perf_monitor@PERFDB1> col FIRST_CHANGE# for 999999999999999999
04:13:26 perf_monitor@PERFDB1> select *from v$log;
    GROUP#    THREAD# SEQUENCE#      BYTES    MEMBERS ARC STATUS                 FIRST_CHANGE# FIRST_TIME
         1          1      40689 524288000          2 YES INACTIVE              13026185905545 18-MAY-13 01:00
         2          1      40690 524288000          2 YES INACTIVE              13026185931010 18-MAY-13 03:32
         3          1      40691 524288000          2 NO CURRENT               13026185933550 18-MAY-13 04:00Edited by: Kunwar on May 18, 2013 2:46 PM

AWR Top Events Report

Hi All,
11.2.0.1
Aix 6.1
I got this awr top events report.
Can you help me how to interpret this please. Or what value to watch out here? Thanks a lot
                                                                                                                   AWR Top Events Report
                         i
                         n
       Snap              s       Snap                                                                                                    A
Snap Start             t        Dur                                          Event                          Time    Avgwt DB Time      A
    ID Time              #        (m) Event                                     Rank          Waits            (s)     (ms)       %      S Wait Class
13902 13/09/16 09:00    1      60.05 os thread startup                            1         140.00          11.08    79.11      56    0.0 Concurrency
13902 13/09/16 09:00    1      60.05 CPU time                                     2           0.00           9.45     0.00      48    0.0 CPU
13902 13/09/16 09:00    1      60.05 log file parallel write                      3        1506.00           1.84     1.22       9    0.0 System I/O
13902 13/09/16 09:00    1      60.05 control file parallel write                  4        1291.00           1.41     1.09       7    0.0 System I/O
13902 13/09/16 09:00    1      60.05 log file sync                                5         721.00           1.03     1.43       5    0.0 Commit
13903 13/09/16 10:00    1      60.05 os thread startup                            1         138.00          10.36    75.10      47    0.0 Concurrency
13903 13/09/16 10:00    1      60.05 CPU time                                     2           0.00          10.28     0.00      47    0.0 CPU
13903 13/09/16 10:00    1      60.05 log file parallel write                      3        1575.00           1.73     1.10       8    0.0 System I/O
13903 13/09/16 10:00    1      60.05 direct path read                             3         486.00           1.73     3.56       8    0.0 User I/O
13903 13/09/16 10:00    1      60.05 control file parallel write                  4        1285.00           1.51     1.17       7    0.0 System I/O
13903 13/09/16 10:00    1      60.05 log file sync                                5         823.00           1.08     1.32       5    0.0 Commit
13904 13/09/16 11:00    1      60.05 CPU time                                     1           0.00          17.06     0.00      32    0.0 CPU
13904 13/09/16 11:00    1      60.05 os thread startup                            2         145.00          10.65    73.46      20    0.0 Concurrency

Thanks I just told the users there is no problem in the db, and the stats is normal and no suspiscious activity, and that the problem is in the users mind only.

Top 5 event class slave wait

Similar Messages

Maybe you are looking for