9
Trace Files

This chapter describes how to use Oracle8i Enterprise Edition trace files when dealing with exception conditions.

This chapter contains the following major sections:

• Using Trace Files

• Specifying Trace File Directories

• Identifying Trace Files

• No Need to Format

• INIT.ORA Parameter for Creating World-readable Trace Files

Using Trace Files

Whenever Oracle8i encounters an exception condition, such as an access violation or an attempt to divide a value by zero, Oracle8i writes a trace file, also called a dump file.

A trace file can contain any of the following:

• Call stack trace

• Exception handler arguments

• Interpreted version of the exception handler data

• Register dump

• Dumps of the SGA, Process Global Area (PGA), and supervisor stacks

• Output from the SQL trace utility

The first few lines of the trace file include the time and date when the trace file was created and might contain other information about the creating process, including the following:

• Alpha OpenVMS process ID

• Alpha OpenVMS process name

• User identification code (UIC)

• User name

• Terminal device name

• Full filename specification of the image

• Process quotas and quota usage

Specifying Trace File Directories

Trace files are created by processes running the image ORACLE.EXE. These are the database processes, dedicated server processes, dispatchers and shared servers.

The INIT.ORA parameter, BACKGROUND_DUMP_DEST, sets the directory where trace files will be sent. Logical names can be used with this parameter rather than actual directory specifications. If the name is a logical name, then it is translated during instance startup in context of the process that starts up the instance.

Identifying Trace Files

The foreign command TRC is defined when the Oracle8i Enterprise Edition is installed. Use this symbol to display the trace files created in the ORA_DUMP directory on any given day.

Trace file names use the following convention:

<nodename>_<sid>_<FG/BG>_<image>_<process_id>.TRC  

nodename	Name of the node the instance was running on when the trace file was created
sid	System ID of the instance that was running when the trace file was created
FG/BG	Indicates that the trace files were created during the execution of either a foreground process (FG) or background process (BG)
image	Name of the executable image that was running when the trace file was created
process_id	Three-digit ORACLE process ID that is the same as the ID that appears in the Server Manager Monitor screen.
.TRC	File name extension appended to all trace filenames

For example, a trace file created by process 005 running SQL*Plus against instance MKT1 might create a trace file called HARPO_MKT1_BG_ORACLE_005.TRC.

In addition to the above trace files, a file called <nodename>_<sid>_ALERT.LOG is stored in the background process dump directory and updated each time a number of different activities related to the database occur. You should be aware of the growth in size of the file over time. For more information about this file, see the README file.

In addition to the existing messages in <nodename>_<sid>_ALERT.LOG, the following messages result from the 64-bit feature:

• ** Reserve memory size = <size> greater than created SGA size = <size> **
  ** Please reduce reserved memory size to avoid wasting memory. **

• ** Memory was not reserved for the SGA. SGA size = <size> **
  ** There might be performance advantages to allocating memory for the SGA in the OpenVMS reserved memory registry. **

• ** Unable to create SGA Buffer Object - Fast I/O will not be used. non-fatal error = <error> **

No Need to Format

The trace file format allows stack dumps to look similar on all implementations of Oracle8i Enterprise Edition and above. Trace files are also now preformatted.

INIT.ORA Parameter for Creating World-readable Trace Files

Trace files are created so that they are not world-readable. While this is secure, for those who are not administrating sensitive data the new protections may be overly restrictive. For example, a user tho attempts to use SQL*Trace to analyze code behavior will find that the results are in a trace file that they cannot read.

When the internal INIT.ORA parameter _TRACE_FILES_PUBLIC is set to TRUE, trace files will be created world-readable. In this case, trace data is available and a user can use SQL*Trace to analyze code behavior. However, this is not a secure thing to do. Setting the parameter to FALSE is secure.