BC remote Oracle DBA - Call (800) 766-1884  
Oracle Consulting Oracle Training Development

Remote DBA

Remote DBA Plans  

Remote DBA Service

Remote DBA RAC

   
Remote DBA Oracle Home
Remote DBA Oracle Training
Remote DBA SQL Tuning Consulting
Remote DBA Oracle Tuning Consulting
Remote DBA Data Warehouse Consulting
Remote DBA Oracle Project Management
Remote DBA Oracle Security Assessment
Remote DBA Unix Consulting
Burleson Books
Burleson Articles
Burleson Web Courses
Burleson Qualifications
Oracle Links
Remote DBA Oracle Monitoring
Remote DBA Support Benefits
Remote DBA Plans & Prices
Our Automation Strategy
What We Monitor
Oracle Apps Support
Print Our Brochure
Contact Us (e-mail)
Oracle Job Opportunities
Oracle Consulting Prices





   

 

 

 

Remote DBA services

Remote DBA Support

Remote DBA RAC

Remote DBA Reasons

Remote Oracle Tuning

Remote DBA Links

Oracle DBA Support

Oracle DBA Forum

Oracle Disaster

Oracle Training

Oracle Tuning

Oracle Training

 Remote DBA SQL Server

Remote MSSQL Consulting

Oracle DBA Hosting

Oracle License Negotiation

 

 


 

 

 

 

   
  Oracle Tips by Burleson

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

Remote DBA Service
 

Oracle Tuning Book

 

Advance SQL Tuning Book 

BC Oracle support

Oracle books by Rampant

Oracle monitoring software

 

 

 

 

 

 

BC Remote Oracle Support

Remote DBA

Remote DBA Services

Copyright © 1996 -  2013 by Burleson. All rights reserved.

Oracle® is the registered trademark of Oracle Corporation.