Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 







Oracle Business Intelligence, OLAP and BI training and consulting tips . . .

Click here for more
Oracle News Headlines


Oracle Performance Tuning Using Event 10046

Mark Rittman

If you've got an interest in Oracle performance tuning, you'll probably have seen references to something called event 10046. Event 10046 is an undocumented, but well known feature within the Oracle database that generates detailed information on how a statement is parsed, what the values of bind variables are, and what wait events occurred during a particular session. Activating Event 10046 gives us a more detailed trace that that provided by alter session set sql_trace=true
and lets the DBA determine exactly why the database is performing in a certain way, by documenting how a statement is parsed and noting what wait events occured during the statement execution.

Wait events are the things that stop your SQL statement being processed quickly, and are typically caused by statements being hard parsed, data having to be retrieved or written to disks which are suffering from contention, and other such events which in theory can be minimised in a well designed and tuned system. You've probably come across the top five wait events section in STATSPACK which gives you an idea which parts of your system are causing bottlenecks, and activating extended trace using event 10046 allows us to analyze each individual wait event, in the context of the set of SQL statements executed in a particular session.

Two of the main advocates for using event 10046 are Cary Millsap and Jeff Holt, who's company, has kindly made available a detailed paper on analysing Oracle performance using event 10046. Entitled "Oracle System Performance Analysis Using Oracle Event 10046", the paper introduces the technique as:

"The Oracle database kernel is instrumented with over four hundred so-called “pseudo-error debugging events.” [1] One of the most important of these events for the system performance analyst is event 10046, “enable SQL statement timing.” Activating this event for an Oracle session instructs the Oracle kernel to print detailed timing information for that session to an Oracle trace file. A sample of 10046 data is provided later in this document.

Event 10046 is an attribute of an Oracle session that you may set at different levels, depending upon the type of diagnostic output you wish to obtain. Many database administrators are already familiar with Oracle's sql_trace facility, which emits performance information about Oracle parse, execute, fetch, commit, and rollback database calls. Using sql_trace is actually the equivalent of using event 10046 set at level 1.

However, there are entire categories of system performance problems that cannot be diagnosed with level-1 data alone. For example, you cannot unambiguously diagnose and repair a system plagued by contention for latches, locks, networks, or even storage devices by looking only at SQL trace data. Event 10046 takes Oracle performance instrumentation a significant step further by detailing the Oracle kernel's executions of over two hundred internal function calls."

Activating event 10046 is actually quite straightforward for your current session, and takes the form of

alter session set events '10046 trace name context forever, level num';

Where num is either 1,4,8 or 12, with 1 being the same as a normal set sql_trace=true, 4 including values of bind variables, 12 including wait events, and 12 including both bind variables and wait events.

The paper then goes on to explain how event 10046 is activated and deactivated, and then how to find and interpret the trace file. Interpreting the trace file seems to be the interesting bit, with several approaches possible. The most basic way is to go through the raw trace files manually, with the article pointing to a useful MOSC note No. 39817.1 entitled "Interpreting Raw SQL_TRACE and DBMS_SUPPORT.START_TRACE output" which goes through the basics of interpreting the file. Also, If you've got Tom Kyte's "Expert One-On-One" book, turn to Chapter 10 page 464 where there's a whole section on using and interpreting raw trace files. Of course you can also put the results through TKPROF, which from version 9.0.1 also processes trace results generated using the 10046 event. Interpreting the trace file is of course where the skill lies and beyond the scope of this article, but take a look through the article and Tom's book if you've got it, or just do a google search for "10046 event interpreting" and you'll come across plenty of useful examples.

The reason that so much attention has been placed on the event 10046 is that it gives us an opportunity to tune performance by examining individual wait events, rather than relying on the traditional tuning ratios that often hide the real cause of poor database performance. As such, it's quite a revolutionary approach and not one you'll generally find in official Oracle documentation. However, if you're interesting in reading more about event 10046, take a look at Cary Millsap's and Jeff Holt's book "Optimizing Oracle Performance" which is the reference text for wait event tuning, together with a forthcoming book by Stephen Andert called "Oracle Wait Event Tuning" which looks due out in October 2004. OTN also ran an article by Robin Schumacher entitled "Exploring the Oracle Database 10g Wait Interface" on some new V$ views in Oracle Database 10g that provide an interface into database wait events, and this article by Thiru Vadivelu gives a nice introduction to SQL tracing in general.

Lastly, as an alternative to generating and interpreting (what can be) cumbersome raw trace files, Don Burleson recently wrote an Oramag article entitled "Perfect Pitch" which advocates an additiona system wait tuning approach that carries out real-time analysis of physical I/O wait events using views such as V$SYSTEM_EVENT and V$SESSION_WAIT, capturing details about the objects that experience physical read waits, which, when identified, can then be used together with Statspack to identify problem SQL for tuning. According to the article,

"System wait tuning has become very popular because it can show you those wait events that are the primary bottleneck for your system. Some experts like the 10046 wait event (level 8 and higher) analysis technique and Oracle MOSC now has an analysis tool called trcanlzr.sql (see Next Steps) to interpret bottlenecks via 10046 trace dumps. However, some Oracle professionals find dumps cumbersome and prefer to sample real-time wait events.

When doing wait analysis, it is critical to remember that all Oracle databases experience wait events, and that the presence of waits does not always indicate a problem. In fact, all well-tuned databases have some bottleneck. (For example, a computationally intensive database may be CPU-bound and a data warehouse may be bound by disk-read waits.) In theory, any Oracle database will run faster if access to hardware resources associated with waits is increased.

This article explores a small subset of wait analysis, but it illustrates a critical concept of Oracle tuning: the fact that all Oracle databases wait on some kind of system resource, and it's the Oracle professional's job to determine whether the database is I/O bound, CPU bound, memory bound, or bound waiting on latches or locks. When the source of the bottleneck has been identified, the savvy Oracle professional must then determine the causes of these events and attempt to remove them."

All in all, it's an interesting area and it certainly seems that system wait tuning, using the event 10046 and the real-time v$ wait event views, is the preferred 'scientific approach' for diagnosing and improving system performance. If you're interested in tuning, take a look at the articles when you get a chance, and see whether the event 10046 could help you in diagnosing system bottlenecks.

UPDATE: I've just remembered that Nicholas Goodman dropped me a line the other day to let me know that Veritas are making several chapters from "Optimizing Oracle Performance" available as a free download. It's a marketing exercise so you'll probably need to register, but it's a good chance to take a look at part of the book for free.



Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational