CHAPTER 9. Trace Files
This chapter describes how to use Oracle7 Server trace files when dealing with exception conditions.
This chapter contains the following major sections:
Using Trace Files
Whenever Oracle7 encounters an exception condition, such as an access violation or an attempt to divide a value by zero, Oracle7 writes a trace file, also called a dump file.
A trace file can contain any of the following:
- Exception handler arguments
- Interpreted version of the exception handler data
- 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:
- User identification code (UIC)
- Full filename specification of the image
- Process quotas and quota usage
Specifying Trace File Directories
Trace files are created by processes running the image SRV.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 Oracle7 Server 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_SRV_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 Oracle7 Server Version 7.1.5 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.