trcsess Tips

When solving tuning problems, session traces are very useful and offer vital information.
Traces are simple and straightforward for dedicated server sessions, but for shared server
sessions, many processes are involved. The trace pertaining to the user session is scattered
across different trace files belonging to different processes. This makes it difficult to get a
complete picture of the life cycle of a session.
Now there is a new tool, a command line utility called trcsess to help read the trace files.
The trcsess command-line utility consolidates trace information from selected trace files,
based on specified criteria. The criteria include session id, client id, service name, action
name and module name.
The trcsess command-line utility offers the DBA a way to combine or consolidate several
trace files into a single trace file based upon the following criteria:

Session Id

Client Id

Service name

Action name

Module name
When using dedicated server processes, monitoring only a single session and not doing
parallel operations, there is little need for the trcsess utility. But when using shared server
processes, monitoring several sessions concurrently, and/or doing parallel DML, the
workload can span multiple trace files. In fact, it can be located on different nodes in a RAC
environment if the parallel operations cross nodes.
Also note that beginning with Oracle 10g, Oracle Trace functionality is no longer available.
For tracing database activity, use SQLTrace or TKPROF instead.
The syntax for the trcsess utility is:
trcsess [output=output_file_name]
[session=session_Id]
[clientid=client_Id]
[service=service_name]
[action=action_name]
[module=module_name]
[trace_files]
where:

output specifies the file where the output is generated. When this option is not
specified, the standard output is used for the output.

session consolidates the trace information for the session specified. The session Id is
a combination of session index and session serial number.

clientid consolidates the trace information given client Id.

service consolidates the trace information for the given service name.

action consolidates the trace information for the given action name.

module consolidates the trace information for the given module name.

trace_files is a list of all trace file names, separated by spaces, in which trcsess will
look for trace information. The wild card character * can be used to specify the trace file
names. If trace files are not specified, all the files in the current directory are checked
by trcsess.
Once the trace files have been consolidated, tkprof can be run against the consolidated
trace file for reporting purposes.
Utilities for Analyzing Oracle Trace Files
There are several utilities for analyzing Oracle trace files. These include trace assist
(trcasst), session tracer (trcsess), trace analyzer (trcanlzr.sql) and tkprof. Many DBAs are
very familiar with the Oracle trace facility, but just in case, here are some brief instructions
for using this powerful Oracle utility. Before tracing can be enabled, the environment must
first be configured by performing the following steps:
1.
Enable Timed Statistics: This parameter enables the collection of certain vital
statistics such as CPU execution time, wait events, and elapsed times. The resulting trace
output is more meaningful with these statistics. The command to enable timed statistics is:
ALTER SYSTEM SET TIMED_STATISTICS = TRUE;
2.
Check the User Dump Destination Directory: The trace files generated by Oracle
can be numerous and large. These files are placed by Oracle in the user_dump_dest
directory as specified in the init.ora. The user dump destination can also be specified for a
single session using the alter session command. Make sure that enough space exists on the
device to support the number of trace files that you expect to generate.
3.
Turn Tracing On: The next step in the process is to enable tracing. By default,
tracing is disabled due to the burden (5-10%) it places on the database. Tracing can be
defined at the session level:
ALTER SESSION SET SQL_TRACE = TRUE;
DBMS_SESSION.SET_SQL_TRACE(TRUE);
A DBA may enable tracing for another users session by using the following statement:
DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION (sid,serial#,true);
The sid (Session ID) and serial# can be obtained from the v$session view. Once tracing with
Oracle tkprof is enabled, Oracle generates and stores the statistics in the trace file. The
trace file name is version specific.
4.
Enable Oracle tkprof tracing only on those sessions that are having problems. Explain
Plan is not as useful when used in conjunction with tkprof since the trace file contains the
actual execution path of the SQL statement. Use Explain Plan when anticipated execution
statistics are desired without actually executing the statement.
5.
When tracing a session, remember that nothing in v$session indicates that a session
is being traced. Therefore, trace with caution and remember to disable tracing after an
adequate amount of trace data has been generated.
Tkprof does not control the contents of a trace file, it simply formats them. Oracle provides
multiple ways to actually generate the trace file. Tkprof is valuable for detailed trace file
analysis. For those DBAs that prefer a simpler tracing mechanism with instant feedback, the
autotrace utility should be used.
The trace assist (trcasst) utility is used to analyze Oracle trace files generated by most
Oracle error messages. This utility will analyze the trace file and put it into a readable
format.

Active Session History: Overview

ASH represents the history of recent sessions activity. The diagram shows you
how sessions are sampled when active. Each second, the Oracle database server
looks at active sessions, and records the events these sessions are waiting
for. Inactive sessions are not sampled. The sampling facility is very
efficient because it directly accesses the Oracle database internal
structures. The following is the sampled information:

SQL identifier of SQL statement

Object number, file number, and block number

Wait event identifier and parameters

Session identifier and session serial number

Module and action name

Client identifier of the session

Service hash identifier

ASH statistics are available through the V$ACTIVE_SESSION_HISTORY fixed view.
This view contains one row for each active session per sample. All columns
that describe the session in the ASH are present in the V$SESSION view.
The V$ACTIVE_SESSION_HISTORY view provides sampled session activity in the
instance. This can be used as a first fault system analysis. Any session that
is connected to the database and is waiting for an event that does not belong
to the Idle wait class is considered as an active session. This includes any
session that was on the CPU at the time of sampling.
Active session samples are stored in a circular buffer in SGA. As the system
activity increases, the number of seconds of session activity that can be
stored in the circular buffer decreases. The time of a session sample is
retained in the V$ view. The number of seconds of session activity displayed
in the V$ view is completely dependent on database activity.
The memory for the ASH comes from the System Global Area (SGA), and it is
fixed for the lifetime of the instance. It represents 2 MB of memory per CPU.
The ASH cannot exceed a maximum bound of five percent of the shared pool size,
or five percent of the SGA_TARGET.
When Automatic Workload Repository (AWR) snapshots are created, the content of
V$ACTIVE_SESSION_HISTORY is flushed to disk.
By capturing only active sessions, a manageable set of data is represented and
its size is directly related to the work being performed rather than the
number of sessions allowed on the system. You can examine the current Active
Session History (ASH) data in the V$ACTIVE_SESSION_HISTORY view and historical
data in the DBA_HIST_ACTIVE_SESS_HISTORY view.
You can also perform detailed analysis on this data, often avoiding the need
to replay the workload to gather additional performance tracing information.
The data present in the ASH can be rolled up on the various dimensions that it
captures.

DBTime-Graph and ADDM Methodology

Identifying the component contributing the most database time is equivalent to finding the single
database component that provides the greatest benefit when tuned. ADDM uses database time to
identify database components that require investigation and also to quantify performance
bottlenecks.

The first step in automatic performance tuning is to correctly identify the causes of performance
problems. Only when the root cause of the performance problem is correctly identified, is it
possible to explore effective tuning recommendations to solve or alleviate the issue.

ADDM looks at the database time spent in two independent dimensions:

The first dimension looks at the database time spent in various phases of processing user
requests. This dimension includes categories such as connecting to the database, optimizing SQL
statements, and executing SQL statements.

The second dimension looks at the database time spent using or waiting for various
database resources used in processing user requests. The database resources considered in this

dimension include both hardware resources, such as CPU and I/O devices, and software resources, such
as database locks and application locks.
To perform automatic diagnosis, ADDM looks at the database time spent in each category under both
these dimensions and drills down to the categories that had consumed significant database time. This
two-dimensional drilldown process can be represented using the DBTime-graph.
Performance problems often distribute database time across many categories in one dimension but not
in the other. For example, a database with insufficient CPU capacity slows down all phases involved in
processing user requests, which is in the first dimension of the ADDM analysis.
However, it would be evident from the second dimension that the top performance problem affecting the database is
insufficient CPU capacity. This two-dimensional view of determining where the database time is consumed gives
ADDM very good judgment in zooming in to the more significant performance issues.