Re: RAC Trace files
- From: David Robillard <david.robillard@xxxxxxxxx>
- To: Ethan Post <post.ethan@xxxxxxxxx>
- Date: Wed, 2 Feb 2011 15:25:57 -0500
Hello Ethan,
> Getting regular trace files with the following in them (partial below) on 2
> node RAC 11.2.0.1 RHEL5. Harmless? Not harmless?
I have the exact same behavior as you do on the exact same
environment. Fresh install of an 11gR2 RHEL 5 two-node RAC.
The Automatic Diagnostic Repository (ADR), specified by the
DIAGNOSTIC_DEST parameter, gets filled with many thousands of .trc and
.trm files per day.
And that's on a database that has absolutely no data and no clients.
It's an empty RAC database that I've created to familiarize myself
with 11gR2 RAC.
To help me understand why this is happening, I read chapter 9
"Managing Diagnostic Data" in the 11g Release 2 Oracle Database
Administrator's Guide [1]. A quick way to check if you have problems
is to check the "Active Problem Count" and "Active Incident Count"
from SELECT * FROM V$DIAG_INFO;
You can also find out which process wrote which trace file with SELECT
PID, PROGRAM, TRACEFILE FROM V$PROCESS;
Also, you might want to limit the amount of space available to the ADR
(excluding the alert log) by setting MAX_DUMP_FILE_SIZE. I'm not sure
if this parameter controls the size of a single trace file or the
total amount of space ADR can consume? Can anyone help us here?
That being said, was still puzzled as to why was there so much trace
files (.trc) and trace map files (.trm)? My SQL_TRACE parameter is set
to false.
I've opened an SR with MOS in December 15th and I still have no answer
from Oracle.
> Have to say that the # of .trc files being generated by 11g+RAC is quite
> annoying. I am use to about 20% of trace files being useless information and
> 80% having real value, therefore I like to keep tabs on them, but now it
> seems like 80% are useless information and 20% mean something.
In previous Oracle versions (9iR2 and 10gR2) I used home made scripts
to clean-up and archive the files in audit_file_dest,
background_dump_dest, core_dump_dest and user_dump_dest.
But before I modify those scripts, I noticed that most files under
.../trace directory are moved to cdmp_`date +%Y%m%d%H%M%S`.
One way to find out why all these files written is to check your
.../trace/alert_
According to an old blog post by Surachart Opun [2] it could be a
result of a database block corruption. But not in my case, as the a
"select * from V$DATABASE_BLOCK_CORRUPTION;" query returns nothing
(i.e. no rows selected)
Have you had any luck with this problem?
Many thanks,
David
[1]
http://download.oracle.com/docs/cd/E11882_01/server.112/e17120/diag.htm#adminChapterDiagnosability
[2] http://surachartopun.com/2008/06/requesttrace-dump-in-directory-cdmp.html
--
//www.freelists.org/webpage/oracle-l
Other related posts:
