You were brought to this page based on an internet search
and as a free service to Oracle DBAs.
The text below is an except from the book,
Oracle Performance Firefighting, written by
Craig Shallahamer of
OraPub, Inc.
Figures and tables are not included on this page, only their reference.
To order the book in either print or PDF form, click
here.
©2009, 2010 by Craig Shallahamer. This is copyrighted material.
PleaseOut of respect for those involved in the creation of the book and also for
their familes, we ask you to respect the copyright both in intent and deed. Thank you.
-------------------------------
If you are monitoring a specific session or a user you can actually see, it's obvious when to turn off collection. But when using DBMS_MONITOR, it is common to not be physically watching the user. Therefore, you will likely need to set some event to disable collection, wait for the session(s) to disconnect, or when you feel enough data has been collected, manually disable collection. The disabling procedure names and their parameters are very similar to their corresponding enabling procedures. See Table 5-1 for a list of the collection disabling procedures
Depending on the identification criteria, Oracle architecture, and number of sessions, a few minutes of collection could potentially result in hundreds of trace files. With any luck, your criteria are very specific, but it all depends on what is needed.
The $ORACLE_HOME/bin/trcsess program consolidates trace files. You can even specify identification criteria, although when using DBMS_MONITOR, you probably have already effectively done this. The result is a single trace file ready to be formatted by tkprof, or whatever trace file parser/formatter you choose to use.
©2009, 2010 by Craig Shallahamer. This is copyrighted material.
PleaseOut of respect for those involved in the creation of the book and also for
their familes, we ask you to respect the copyright both in intent and deed. Thank you.
|