Gathering Real-Time System Waits Events

The wait-based analysis method discussed so far is the 10046 trace events. Another way of using waits to tune database performance is to use real-time system wait events. Wait Events are the events that are causing the database system to wait or not complete work as quickly as otherwise possible. These events are recorded by the system as they happen, or in real time. There are plenty of v$ views that contain information about waits. For example, a simple query on an OLTP database with several hundred concurrent sessions would look like this:

select

event ,

count(*)

from

See Code Depot

This gives a count of how many occurrences of each type of wait have occurred recently. There are 2 problems with this query. The first is that knowing how many times a given wait has happened provides nothing useful about how long the session has waited. Knowing that there were 7 waits for “rdbms ipc message” does not mean that is what is making the system slow. Going back to the commuting example, it would be like saying “there were 10 red lights.” The wait for each light could vary in length.

The second problem is that this data is of very short duration. Constant monitoring would be necessary to capture the waits that are causing the users to complain. These problems highlight the importance of understanding the methodology behind the tools. Someone with a basic understanding of the wait interface could start making tuning decisions using the value returned by the above query.

One way to overcome this problem is to capture this information and save it periodically to a table that can be referenced to see what was going on at an earlier time. There are various ways to accomplish this. Each way has its own advantages and drawbacks.

The above book excerpt is from:

Oracle Wait Event Tuning

High Performance with Wait Event Interface Analysis

ISBN 0-9745993-7-9

Stephen Andert

http://www.rampant-books.com/book_2004_2_wait_tuning.htm