Database Reference
In-Depth Information
EODA@ORA12CR1> !ls
/home/ora12cr1/app/ora12cr1/diag/rdbms/ora12cr1/ora12cr1/trace/*Look_For_Me*
The prior line of code didn't fit within the physical limitations of this page, so it displays as two lines when it
should be on one line. The
ls
command is searching for files in this directory:
/home/ora12cr1/app/ora12cr1/diag/rdbms/ora12cr1/ora12cr1/trace
The
*
character is a wildcard instructing
ls
to look for any files with the string of
Look_For_Me
included in the file
name. For this example, there are two files the prior
ls
command located:
/home/ora12cr1/app/ora12cr1/diag/rdbms/ora12cr1/ora12cr1/trace/ora12cr1_ora_22489_Look_For_Me.trc
/home/ora12cr1/app/ora12cr1/diag/rdbms/ora12cr1/ora12cr1/trace/ora12cr1_ora_22489_Look_For_Me.trm
As you can see, the trace file is now named in the standard
<ORACLE_SID>_ora_<PROCESS_ID>
format, but it also
has the unique string we specified associated with it, making it easy to find “our” trace file name. The trace file ends
with the extension of
.trc
. There's also a corresponding trace map file (with the extension of
.trm
) which contains
structural information about the trace file. Usually you'll only be interested in the contents of the
.trc
file.
Trace Files Generated in Response to Internal Errors
I'd like to close this section with a discussion about those other kinds of trace files—the ones we did not expect that
were generated as a result of an
ORA-00600
or some other internal error. Is there anything we can do with them?
The short answer is that, in general, they are not for you and me. They are useful to Oracle Support. However,
they can be helpful when we file a service request with Oracle Support. That point is crucial: if you are getting internal
errors, the only way they will ever be corrected is if you file a service request. If you just ignore them, they will not get
fixed by themselves, except by accident.
For example, in Oracle 10
g
Release 1, if you create the following table and run the query, you may well get an
internal error (or not; it was filed as a bug and is corrected in later patch releases):
ops$tkyte@ORA10G> create table t ( x int primary key );
Table created.
ops$tkyte@ORA10G> insert into t values ( 1 );
1 row created.
ops$tkyte@ORA10G> exec dbms_stats.gather_table_stats( user, 'T' );
PL/SQL procedure successfully completed.
ops$tkyte@ORA10G> select count(x) over ()
2 from t;
from t
*
ERROR at line 2:
ORA-00600: internal error code, arguments: [12410], [], [], [], [], [], [], []
Now, suppose you are the DBA and all of a sudden this trace file pops up in the trace area. Or you are the
developer and your application raises an
ORA-00600
error and you want to find out what happened. There is a lot
of information in that trace file (some 35,000 lines, in fact), but in general it's not useful to you and me. We would
generally just compress the trace file and upload it as part of our service request processing.
