1 Using Messages

Locating Message Documentation

This section describes how to locate message documentation when given an error message.

Accuracy of Messages

The accuracy of the messages in this manual is our primary concern. Occasionally, an enhancement to a message is not incorporated into the Oracle software. Should you encounter a message generated on your system that differs from the message in this book, be assured the improved message text is usually incorporated in the next release of the software. If you should encounter a discrepancy, then please contact us using the information contained in the Reader Comment Form at the front of this manual.

Message Format

All messages displayed are prefixed by text that indicates which program issued the message. For example, the prefix "ORA" shows that the message was generated by the Oracle products. The location of messages in this book depends on the prefix of the message.

All messages are listed in order by the message code number. To look up a message, use the message code number.

Recognizing Variable Text in Messages

To help you find and fix errors, Oracle embeds object names, numbers, and character strings in some messages. These embedded variables are represented by string, number, or character, as appropriate. For example:

ORA-00020: maximum number of processes (number) exceeded

The preceding message might actually appear as follows:

ORA-00020: maximum number of processes (50) exceeded

Message Stacks

Occasionally, you may see a message stack. This is simply a series of related messages issued at different levels of Oracle.

The following message stack is a generic example:

ORA-06502: PL/SQL: numeric or value error
ORA-06512: at "SCOTT.VALUE_ERR", line 1
ORA-06512: at line 1

The following message stack is a VAX/VMS example:

ORA-01034: Oracle not available
ORA-07625: smsget: $MGBLSC failure
%SYSTEM-W-NOSUCHSEC, no such (global) section

In this example, notice that the message at the bottom of the stack is issued by the VMS operating system. Seeing the messages at each level in the system may help you trace the originating event. For example, in this case, Oracle may not be available simply because it has not been started, and consequently there is no system global area (SGA). If you need the help of Oracle Support Services, then be sure to report all the messages in the stack.

Contacting Oracle Support Services

Some messages recommend contacting Oracle Support Services to report a problem. When you contact Oracle Support Services, please have the following information available:

• The hardware, operating system, and release number of the operating system on which Oracle is running

• The complete release number of the Oracle Database (for example, release 9.2.0.1.0 or release 9.0.1.1.2)

• All Oracle programs (with version numbers) in use when the error occurred. For example, SQL*Net V2.0 or SQL*Forms V3.0

• If you encountered one or more error codes or messages, then the exact code numbers and message text, in the order they appeared

• The problem severity, according to the following codes:

  1 = Program not usable. Critical impact on operations.

  2 = Program usable. Operations severely restricted.

  3 = Program usable with limited functions. Not critical to overall operations.

  4 = Problem circumvented by customer. Minimal effect, if any, on operations.

You will also be expected to provide the following:

• Your name

• The name of your organization

• Your Oracle Support ID Number

• Your telephone number

Oracle Exception Messages

Oracle's extensive self-checking helps detect internal errors. Oracle uses the following catchall message for Oracle internal exceptions:

ORA-00600: internal error code, arguments: [number], [number], [], [], [], []

An actual message might appear as follows:

ORA-00600: internal error code, arguments: [1042], [3], [upilam], [], [], []

The message text can be followed by up to six arguments, which indicate the origin and attributes of the error. The first argument is the internal error number. Other arguments are various numbers, names, and character strings. Empty brackets may be ignored.

In addition to being returned to the user, internal errors are also written to the Alert file along with additional information about the event causing the message. The Alert file also lists any trace files that may have been generated because of an internal error. See the following sections for descriptions of the trace and alert files.

If you receive an ORA-00600 message, report it to Oracle Support Services.

Trace Files

A trace file is created each time an Oracle instance starts or an unexpected event occurs in a user process or background process. The name of the trace file includes the instance name, the process name, and the Oracle process number. The file extension or file type is usually TRC, and, if different, is noted in your operating system-specific Oracle documentation. The contents of the trace file may include dumps of the system global area, process global area, supervisor stack, and registers.

Two initialization parameters are used to specify the location of the trace files.

• The BACKGROUND_DUMP_DEST initialization parameter specifies the location of trace files created by the Oracle background processes PMON, DBWR, LGWR, and SMON.

• The USER_DUMP_DEST initialization parameter specifies the location of trace files created by user processes such as SQL*Loader or Pro*C.

The Alert file also describes the location of trace files generated when internal errors occur. See the next section for a description of the Alert file.

You may need to format the trace file before using it to diagnose problems. To format a trace file, use the DUMPFMT utility, which is available on most systems and is described in your operating system-specific Oracle documentation. Oracle Support Services may ask you for a formatted trace file to help solve a problem.

The Alert File

The Alert file is a log file that records information about internal errors and administrative activities, such as backups. When an internal error occurs, the message is sent to the terminal screen as well as written to the Alert file. Oracle also writes additional information about internal errors to the Alert file, such as the location and name of any trace files generated because of the error.

The name of the Alert file is operating system-specific. The location of the Alert file is the same as the location of the background process trace files. This location is specified by the BACKGROUND_DUMP_DEST initialization parameter. For more information, see your Oracle operating system-specific documentation.

If your system uses an operator's console, some messages from Oracle may appear on the console. All important messages are written to the Alert file as well as the operator's console. Because non-Oracle messages also appear on this console, the Alert file is a better record for tracing all Oracle administrative activity and errors than the console log.

The Alert file also records information about administrative activities, such as backups and archiving online redo log files.