<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>DBMS_MONITOR on Oracle Scripts</title><link>https://www.oraclescripts.com/tags/dbms_monitor/</link><description>Recent content in DBMS_MONITOR on Oracle Scripts</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>OracleScripts.com</copyright><lastBuildDate>Fri, 10 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://www.oraclescripts.com/tags/dbms_monitor/index.xml" rel="self" type="application/rss+xml"/><item><title>Enable a 10046 Trace for an Oracle Session</title><link>https://www.oraclescripts.com/post/oracle-enable-10046-trace/</link><pubDate>Fri, 10 Jul 2026 00:00:00 +0000</pubDate><guid>https://www.oraclescripts.com/post/oracle-enable-10046-trace/</guid><description>
&lt;h2 id="enable-a-10046-trace-for-an-oracle-session"&gt;Enable a 10046 Trace for an Oracle Session&lt;/h2&gt;
&lt;h2 id="purpose"&gt;Purpose&lt;/h2&gt;
&lt;p&gt;A 10046 trace returns wait events only if the level includes them. Enabling the trace at level 1 and then wondering why the file shows no waits is the most common 10046 mistake in production diagnosis — the output has elapsed times and call counts, but none of the &lt;code&gt;db file sequential read&lt;/code&gt;, &lt;code&gt;latch: cache buffers chains&lt;/code&gt;, or &lt;code&gt;enq: TX - row lock contention&lt;/code&gt; events that explain where those seconds actually went. Choosing the wrong level produces a trace file that answers a different question than the one being investigated.&lt;/p&gt;</description></item></channel></rss>