About wait events of awr

is there anyone who can helip to advise me the meaning of
1.SQL*Net break/reset to client
2. Streams AQ: waiting for messages in the queue
3. wait for unread message on broadcast channel
we are processing a performence test , tks for your kind advise

You can ignore these events as they are IDLE events, not WAIT events. In short, they mean user is connected but is not doing anything.

Similar Messages

Top wait events in awr

hi,
We are using 11.2.0.3.0 on solaris 10 facing slow performance, following are the Wait Events in AWR report, need assistance to overcome it. Also if any specific document to analyze AWR report and to pin point the performance bottleneck.
Foreground Wait Events
Avg
%Time Total Wait
wait
Waits   % DB
Event
Waits -outs   Time (s)
(ms)
/txn   time
direct path read
308,729
0
21,191
69
58.0   39.5
db file sequential read
208,754
0
3,742
18
39.2
7.0
cursor: pin S
19,541,899
0
2,561
0 3,668.5
4.8
Background Wait Events
Avg
%Time Total Wait
wait
Waits   % bg
Event
Waits -outs   Time (s)
(ms)
/txn   time
log file parallel write
26,479
0
942
36
5.0   40.3
db file parallel write
216,823
0
809
4
40.7   34.6
control file sequential re
11,673
0
56
5
2.2
2.4
control file parallel writ
6,280
0
35
6
1.2
1.5
direct path read
534
0
26
49
0.1
1.1

You need to identify if you are excessively running Parallel Query -- too many queries being parallelised and doing direct path reads bypassing the buffer cache.
In 11gR2, you might also find full table scans of large tables becoming direct path reads.
See this thread : https://forums.oracle.com/thread/2552571
Hemant K Chitale

Top 5 wait events in AWR Repprt

Hi,
The following is top 5 wait event in my AWR reports...
Whenever I take reports this are always top 5 events
Top 5 Timed Events
=============================================================================================================
Event
CPU time
Waits               4,717
% Total Call Time     62.0
log file sync
Waits                64,963
Time(s)               1,362
Avg Wait(ms)          21
% Total Call Time     17.9
Wait Class          Commit
log file parallel write
Waits               63,485
Time(s)               1,004
Avg Wait(ms)          16
% Total Call Time     13.2
Wait Class          System I/O
enq: TX - row lock contention
Waits               348
Time(s)               984
Avg Wait(ms)          2,828
% Total Call Time     12.9
Wait Class          Application
db file parallel write
Waits               29,305
Time(s)               561
Avg Wait(ms)          19
% Total Call Time     7.4
Wait Class          System I/O
------------------------------------------------------------------------------------------------------------

Start with Performance Tuning Guide
10.2.3 Table of Wait Events and Potential Causes

RAC specific Wait events in AWR

DB version: 10.2.0.4
OS : Solaris x86
What are the most frequent RAC specific Wait events that appear in AWR reports ?

Hi Pete,
This depends on your environment. You can identify them as follows:
Monitoring Oracle RAC Statistics and Wait Events
http://download.oracle.com/docs/cd/E11882_01/rac.112/e16795/monitor.htm#i1010220
ASH Report for Oracle RAC: Top Cluster Events
The ASH report Top Cluster Events section is part of the Top Events report that is specific to Oracle RAC. The Top Cluster Events report lists events that account for the highest percentage of session activity in the cluster wait class event along with the instance number of the affected instances. You can use this information to identify which events and instances caused a high percentage of cluster wait events.
http://download.oracle.com/docs/cd/E11882_01/rac.112/e16795/monitor.htm
Regards,
Levi Pereira
Please close your thread when you get the solution to your problem. 
Mark the replies answered "helpful" answer and/or "correct" answer that will help others with same problem. 
Thanks for doing your part to make this community as valuable as possible for everyone!

Enq: TX - row lock contention in TOP 5 wait event

DB version:11.1.0.7.0
I am having enq: TX - row lock contention in top 5 wait event.
AWR analyze period - 9-10(pm). During this time only one sql loader is running to insert the data. No other job are running. So there is no chance of other session blocking this session. is there any chance of row lock contention happen by same session.
SQL> SELECT INDEX_NAME,INDEX_TYPE,UNIQUENESS FROM DBA_INDEXES WHERE TABLE_NAME='DATA_DATA';
INDEX_NAME INDEX_TYPE UNIQUENES
CIDX BITMAP NONUNIQUE
VIDX BITMAP NONUNIQUE
Thanks.

SQL> SELECT INDEX_NAME,INDEX_TYPE,UNIQUENESS FROM DBA_INDEXES WHERE TABLE_NAME='DATA_DATA';
INDEX_NAME INDEX_TYPE UNIQUENES
CIDX BITMAP NONUNIQUE
VIDX BITMAP NONUNIQUEYou have bitmap indexes here on a table being inserted into. Bitmap Indexes are another source of lock(and deadlock) in OLTP application. You said that the SQLloader was the unique active program but may be you are also triggering another procedure after the load. Procedure in which you might be using also automomous transactions and so on...
Check first if your table is subject to DML operation in a a multi-user concurrent accesss and in which case you have to get rid of those bitmap indexes
http://hourim.wordpress.com/2011/03/14/deadlock-%e2%80%93-part-1-bitmap-index/
Best regards
Mohamed Houri
www.hourim.wordpress.com

Awr report showing "Undo segment recovery" in top 1st wait event.

Hi all.
Today evening oracle.exe is hitting 100% cpu in windows server 2003.
In the awr report "undo segment recovery" listed in the top 5 wait event (1st place) and
also in the enterprise manager it shows the details like,
ACTION 1:
Action Investigate the cause for high "undo segment recovery" waits. Refer to Oracle's "Database Reference" for the description of this wait event. Use given SQL for further investigation.
Rationale The SQL statement with SQL_ID "0x63ctfjb1m1j" was found waiting for "undo segment recovery" wait event.
SQL Text UPDATE PF_SubjectVEChapterPage SET NeedsRecalcState = NULL, NeedsUnsignState = ...
SQL ID 0x63ctfjb1m1j
Rationale The SQL statement with SQL_ID "0x6uvufcw5umh" was found waiting for "undo segment recovery" wait event.
SQL Text
SQL ID 0x6uvufcw5umh
Rationale The SQL statement with SQL_ID "2dvmt5mhr3m10" was found waiting for "undo segment recovery" wait event.
SQL Text UPDATE PF_SubjectVEChapterPage SET NeedsRecalcState = NULL, NeedsUnsignState = ...
SQL ID 2dvmt5mhr3m10
Rationale The SQL statement with SQL_ID "gx5pummu20jzb" was found waiting for "undo segment recovery" wait event.
SQL Text UPDATE PF_SubjectVEChapterPage SET NeedsRecalcState = NULL, NeedsUnsignState = ...
SQL ID gx5pummu20jzb
Rationale The SQL statement with SQL_ID "1rxk3vt41zg1u" was found waiting for "undo segment recovery" wait event.
SQL Text
SQL ID 1rxk3vt41zg1u
ACTION 2:
Investigate the cause for high "undo segment recovery" waits in Module "dllhost.exe".
ACTION 3:
Investigate the cause for high "undo segment recovery" waits in Service "SYS$USERS".
I'm not sure what action i need to take exactly.Please provide your valuable suggestions to proceed further.
Thanks, Muhammed Thameem.

http://download.oracle.com/docs/cd/A97630_01/server.920/a96536/apa5.htm
"undo segment recovery
PMON is rolling back a dead transaction. The wait continues until rollback finishes.
Wait Time: 3 seconds
Parameters:
segment# -> The ID of the rollback segment that contains the transaction that is being rolled back
tx flags -> The transaction flags (options) set for the transaction that is being rolled back?

DB CPU wait event is high in AWR

Hello Experts,
Could you please tell me what are the causes of increasing DB CPU wait event ? I mentioned below which i know. please guide me
1. When Buffer cache is more than required then DB CPU wait event occur.
Regards,
Sachin

Sachin.Ichake wrote:
Currently in my database DB CPU has taken 90% DB time . in accordance to resolve it I will gonna follow steps
1. Tune the query which has taken more cpu
2. Decrease Buffer cache size by referring buffer cache advisory.Solve what? You must understand that DB CPU is not shown as a Wait Event but as a Timed Event and so are the other events that are shown in the Top 5 Timed Events category. This is an indication of how much you have used in the comparison of the total DB Time but not necessarily , it's an issue as to do anything in the system, you would need to burn the CPU only. You need to check that how much total CPU time you have with you and then compare it with your DB CPU seconds. In addition to this, you also need to check the CPU consumption from the o/s commands like Top etc. Combining all of such information only would be able to help to understand that whether any tuning needs to be done or not.
Post here the AWR/Statspack report. That would give more clear picture of the things.
Aman....

A clarification about block# wait event parameter ....

Hi ,
In Oracle Database Reference of 10g (Part Number B14237-02) about the block# wait event parameter is pointed out ... :
This is the block number of the block for which Oracle needs to wait. The block number is relative to the start of the file. To find the object to which this block belongs, enter the following SQL statements:
select name, kind
from ext_to_obj_view
where file# = file#
and lowb <= block#
and highb >= block#;Can you give me a simple example of using the above sql statement.... as ext_to_obj_view object does not exist.....
Many thanks ,
Simon

This view is created by $ORACLE_HOME/rdbms/admin/catclust.sql script (to be run by sys user).
http://download-uk.oracle.com/docs/cd/B19306_01/rac.102/b14197/monitor.htm#RACAD718
Nicolas.

Interpret DB CPUwait event (top 5 wait event AWR)

Hi,
Can anyone tell me how to read the table below especially the "DB CPU" section,
Is it right to say that 41.71% of time was consumed waiting for CPU?? this is urgent
Event                     Waits           Time(s)      Avg wait (ms)      % DB time      Wait Class
db file sequential read      300,835      1,483           5           58.42           User I/O
DB CPU                     1,059                     41.71
reliable message           9,499           18           2           0.71           Other
PX Deq: Slave Session Stats      6,506           11           2           0.43           Other
gc cr grant 2-way           26,218           6           0           0.25           Cluster

user589420 wrote:
Hi,
Can anyone tell me how to read the table below especially the "DB CPU" section,
Is it right to say that 41.71% of time was consumed waiting for CPU?? this is urgent
Event                           Waits Time(s) Avg wait (ms) % DB time Wait Class
db file sequential read       300,835    1,483              5      58.42 User I/O
DB CPU                                   1,059                     41.71
reliable message                9,499       18              2       0.71 Other
PX Deq: Slave Session Stats     6,506       11              2       0.43 Other
gc cr grant 2-way              26,218        6              0       0.25 Cluster
When posting information to the forum that includes critical spaces, like the above, use a { code } tag (without spaces) before and after the information.
I do not understand why this question is an urgent problem.
It is incorrect to state that 41.71% of the time was consumed waiting for the CPU. When an Oracle process is running on the CPU, it is officially not waiting. It causes a bit of confusion having the CPU time consumed listed among the top 5 wait events, but as long as you understand why it is in the top 5 list, it almost makes sense for it to be included.
The DB CPU statistic is listed as 1,059 seconds. If the duration of this report is 1 hour, that is 3,600 seconds of total time. If there is a single CPU in the server, there are 3,600 CPU seconds available in the time period, indicating that the server's CPU on average was 29.4% busy. If there were 12 CPUs in the server, there were 43,200 CPU seconds available in the time period, indicating that on average the CPUs were 2.5% busy. Does this mean that there was a problem, or was this OK, or is there not enough information? Just because on average the CPUs are not busy, that does not mean that there were not periods of intense CPU competion, where in fact there was a temporary shortage of available CPU time for processing.
The DB Time statistic is supposed to be an indication of work performed by the instance on behalf of the user sessions. It is the accumulation of CPU time consumed by foreground sessions plus the accumulated sum of all non-idle wait events consumed by foreground sessions. Blog articles that might be of interest to you:
http://hoopercharles.wordpress.com/2010/01/13/working-with-oracle-time-model-data/
http://hoopercharles.wordpress.com/2010/02/05/faulty-quotes-6-cpu-utilization/
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.

About single-task message wait event

Hello
I have several active users, some of them from 2 an 3 days ago with single-task message wait event and their last_call was many time ago. One of users, blocked to other users just a little while ago and Concurrency grow up to 20 % and was on increase. i had to kill this user and all were well, concurrency dessapeared.
How could I avoid this behavior??
How could I kill these type of user by automatic way??
Thanks

Hi,
according to me active user is different
according to me active user is session or oracle process is doing something else like dml or ddl execution or select stmt else session is idel.
trace the session what is doing? is may be problem with dead connection
use oradebug and set the 10046 at level 12 and format it with tkprof utility.
paste it thread
Kind Regards,
Rakesh jayappa

Wait Events "log file parallel write" / "log file sync" during CREATE INDEX

Hello guys,
at my current project i am performing some performance tests for oracle data guard. The question is "How does a LGWR SYNC transfer influences the system performance?"
To get some performance values, that i can compare i just built up a normal oracle database in the first step.
Now i am performing different tests like creating "large" indexes, massive parallel inserts/commits, etc. to get the bench mark.
My database is an oracle 10.2.0.4 with multiplexed redo log files on AIX.
I am creating an index on a "normal" table .. i execute "dbms_workload_repository.create_snapshot()" before and after the CREATE INDEX to get an equivalent timeframe for the AWR report.
After the index is built up (round about 9 GB) i perform an awrrpt.sql to get the AWR report.
And now take a look at these values from the AWR
 Avg
 %Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
log file parallel write 10,019 .0 132 13 33.5
log file sync 293 .7 4 15 1.0
......How can this be possible?
Regarding to the documentation
-> log file sync: http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents003.htm#sthref3120
Wait Time: The wait time includes the writing of the log buffer and the post.-> log file parallel write: http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents003.htm#sthref3104
Wait Time: Time it takes for the I/Os to complete. Even though redo records are written in parallel, the parallel write is not complete until the last I/O is on disk.This was also my understanding .. the "log file sync" wait time should be higher than the "log file parallel write" wait time, because of it includes the I/O and the response time to the user session.
I could accept it, if the values are close to each other (maybe round about 1 second in total) .. but the different between 132 seconds and 4 seconds is too noticeable.
Is the behavior of the log file sync/write different when performing a DDL like CREATE INDEX (maybe async .. like you can influence it with the initialization parameter COMMIT_WRITE??)?
Do you have any idea how these values come about?
Any thoughts/ideas are welcome.
Thanks and Regards

Surachart Opun (HunterX) wrote:
Thank you for Nice Idea.
In this case, How can we reduce "log file parallel write" and "log file sync" waited time?
CREATE INDEX with NOLOGGINGA NOLOGGING can help, can't it?Yes - if you create index nologging then you wouldn't be generating that 10GB of redo log, so the waits would disappear.
Two points on nologging, though:
<ul>
it's "only" an index, so you could always rebuild it in the event of media corruption, but if you had lots of indexes created nologging this might cause an unreasonable delay before the system was usable again - so you should decide on a fallback option, such as taking a new backup of the tablespace as soon as all the nologging operatons had completed.
If the database, or that tablespace, is in +"force logging"+ mode, the nologging will not work.
</ul>
Don't get too alarmed by the waits, though. My guess is that the +"log file sync"+ waits are mostly from other sessions, and since there aren't many of them the other sessions are probably not seeing a performance issue. The +"log file parallel write"+ waits are caused by your create index, but they are happeninng to lgwr in the background which is running concurrently with your session - so your session is not (directly) affected by them, so may not be seeing a performance issue.
The other sessions are seeing relatively high sync times because their log file syncs have to wait for one of the large writes that you have triggered to complete, and then the logwriter includes their (little) writes with your next (large) write.
There may be a performance impact, though, from the pure volume of I/O. Apart from the I/O to write the index you have LGWR writting (N copies) of the redo for the index and ARCH is reading and writing the completed log files caused by the index build. So the 9GB of index could easily be responsible for vastly more I/O than the initial 9GB.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan

A question about waits

Hi,
We are on Oracle 10.2.0.4 on Solaris 10.
In my awr report I have the following among top five top wait event:
Wait event
SQL*Net more data to client 14,022,144 3,758 0 17.7 Network
Edited by: orausern on Apr 15, 2010 5:07 AM

Your average wait on "more data to client" is very small.
The number of calls is large - but you don't have any real measure of its significance and meaning.
You need to look at Instances statistics:
SQL*Net roundtrips to/from clien         17,407,740        9,876.1          32.6
bytes sent via SQL*Net to client      4,429,719,421    2,513,152.0       8,303.4A round-trip consists of one 'sql net data to client' plus ALL the ' more data to client' that took place at the same time, so:
Compare your count of 'more data to client' with roundtrips - if it is a large multiple you can infer that on average each round trip is a large chunk of data that has to be sent as several packets, and you probably need to make your SDU larger. If you look at 'bytes sent via SQL net to client' compared to roundtrips, you get an idea of the size of the the "average" packet - hence an indication of the necessary size of the SDU.
There are also a couple of tcp network configuration parameters that may need setting. I never remember the exact names, but it's something like 'tcp_transmit_buf' and 'tcp_recv_buf'. This is the volume of data that the tcp layer can send before it needs an ACK from the far end. So, for example, if your SDU is 32K and your tcp buffer size was only 4KB, then Oracle would send one packet of 32KB, tcp would handle as 8 chunks of 4KB - with 8 tcp ACKs from the far end, and the (because tcp works in line packets of about 1400 bytes - each 4KB would go as 3 packets with an ACK expected on the third). So you need the tcp buffer sizes to be slightly larger than the SDU for best effect.
(If your procsses parameter is large, though, the total tcp buffer memory needed is processes * tcp buffer size).
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan

CPU wait events on ADDM report

Hello,
My Oracle version is:
Connected to Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 Yesterday I was taking a look on an ADDM report and spot the following:
   Rationale
      SQL statement with SQL_ID "0mgk8gx9hj71d" was executed 777 times and had
      an average elapsed time of 42 seconds.
   Rationale
      Waiting for event "resmgr:cpu quantum" in wait class "Scheduler"
      accounted for 34% of the database time spent in processing the SQL
      statement with SQL_ID "0mgk8gx9hj71d".After that, I started looking for how ADDM could know that the SQL_ID "0mgk8gx9hj71d" waited 34% on "resmgr:cpu quantum" event. No lucky with that...
The only wait event information related to a given SQL_ID I've found on v$active_session_history (or the AWR persisted table for it), but in the ASH there is no information about CPU wait events like "cpu quantum". When the session is waiting for CPU, there is no event related in v$ash.
So, my question is: where ADDM got the information that the SQL waited 34% of the time on "resmgr:cpu quantum"?
Thanks,
Heitor Kirsten

Hi,
Is a session waiting for CPU resources ("res:cpu quantum") considered as an active session ? Maybe not.
I guess (I made no test) that this maybe the reason why this kind of wait is not shown in the active session history .
Regards
Maurice

Latch: session allocation in top 5 wait events

Hi,
This wait event session is coming in the top 5 timed events
How to proceed for solving this issue?
This database is only being used for migration activities currently,which means a lot of imports going on.
PFB the Top 5 Timed Foreground Events
++++++++++++++++++
Event     Waits     Time(s)     Avg wait (ms)     % DB time     Wait Class
DB CPU          8,437          57.95
latch: session allocation     2,035,326     3,671     2     25.22     Other
wait list latch free     243,511     2,448     10     16.81     Other
direct path write     504,262     363     1     2.49     User I/O
log file sync     39,396     156     4     1.07     Commit
++++++++++++++++++
Cheers,
Kunwar

user9131570 wrote:
This database is only being used for migration activities currently,which means a lot of imports going on.
PFB the Top 5 Timed Foreground Events
++++++++++++++++++
Event     Waits     Time(s)     Avg wait (ms)     % DB time     Wait Class
DB CPU          8,437          57.95
latch: session allocation     2,035,326     3,671     2     25.22     Other
wait list latch free     243,511     2,448     10     16.81     Other
direct path write     504,262     363     1     2.49     User I/O
log file sync     39,396     156     4     1.07     Commit
++++++++++++++++++
A little more information would help - you could start with the Load Profile section, and the summary of the number of sessions, CPU, and memory. Also OSSTATs might be helpful and the Time Model stats. The version of Oracle might also be relevant.
See the note below about using the "code" tag and preview option.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)
+"Science is more than a body of knowledge; it is a way of thinking"+
+Carl Sagan+

Wait event enq: JD - contention

Hi All,
In the top-5 wait events of the AWR-report i encounter a enq: JD contention wait event (wait class Other).
I only figured out that JD means Job Queue Date.
Can anybody tell me more about this wait event?
Thanks in advance,
Jeroen van Schaijk

Hi All,
I have additional information:
This wait event synchronizes dates between job queue coordinator and slave processes.
It appears that this wait event takes more than 10% of the total wait time!
Does anybody know how to deal with this wait event?
Thanks in advance,
Jeroen van Schaijk

About wait events of awr

Similar Messages

Maybe you are looking for