Files - Expert Oracle Database Architecture - page 97

And, finally, I can create a “package” of the incident that is useful for support. The package will contain
everything a support analyst needs to begin working on the problem.
This section is not intended to be a full overview or introduction to the ADRCI utility, which is documented fully
in the Oracle Database Utilities manual. Rather, I just wanted to introduce the existence of the tool—a tool that makes
using trace files easy.
Prior to ADRCI in 11 g , was there anything you could do with the unexpected trace files beyond sending them to
support? Yes, there is some information in a trace file that can help you track down the who, what, and where of an
error. The trace file can also help you find out if the problem is something others have experienced.
The previous example shows that ADRCI is an easy way to interrogate the trace files in Oracle 12 c (I showed just a
small fraction of the commands available). In 10 g and before, you can do the same thing, albeit it a bit more manually.
For example, a quick inspection of the very top of a trace file provides some useful information. Here's an example:
/home/ora10gr1/admin/ora10gr1/udump/ora10gr1_ora_2578.trc
Oracle Database 10g Enterprise Edition Release 10.1.0.4.0 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /home/ora10gr1
System name: Linux
Node name: dellpe
Release: 2.6.9-11.ELsmp
Version: #1 SMP Fri May 20 18:26:27 EDT 2005
Machine: i686
Instance name: ora10gr1
Redo thread mounted by this instance: 1
Oracle process number: 16
Unix process pid: 2578, image: oracle@dellpe (TNS V1-V3)
The database information is important to have when you go to http://support.oracle.com to file the service
request or to search to see if what you are experiencing is a known problem. In addition, you can see the Oracle
instance on which the error occurred. It is quite common to have many instances running concurrently, so isolating
the problem to a single instance is useful.
Here's another section of the trace file to be aware of:
*** 2010-01-20 14:32:40.007
*** ACTION NAME:() 2010-01-20 14:32:39.988
*** MODULE NAME:(SQL*Plus) 2010-01-20 14:32:39.988
*** SERVICE NAME:(SYS$USERS) 2010-01-20 14:32:39.988
This part of the trace file is new with Oracle 10 g and above and won't be there in Oracle9 i and before. It shows
the session information available in the columns ACTION and MODULE from V$SESSION . Here we can see that it was
a SQL*Plus session that caused the error to be raised (you and your developers can and should set the ACTION and
MODULE information; some environments such as Oracle Forms and APEX already do this for you).
Additionally, we have the SERVICE NAME . This is the actual service name used to connect to the database—
SYS$USERS, in this case—indicating we didn't connect via a TNS service. If we logged in using user/pass@ora10g.
localdomain , we might see:
*** SERVICE NAME:(ORA10G) 2010-01-20 14:32:39.988
where ora10g is the service name (not the TNS connect string; rather, it's the ultimate service registered in a TNS
listener to which it connected). This is also useful in tracking down which process or module is affected by this error.