RE: Managing large ASM trace files

What Tanel wrote works.  

Sadly, of 63 enhancement requests voted into the first Oracle VLDB list circa 1992, one of the highest ranking losers was to automatically grandfather all trace files down one directory into a date named subdirectory dYYYYMMDD (the leading d being optional on OSes that support all numeric “folder” or directory names.  

The number of problems by simply down foldering all old files cannot be counted.  

IF memory serves, Tanel once described a problem rooted in a huge number of files in a directory as the most complex to debug he’d ever seen (as of that time).

You CAN do this yourself for files that are not open on most operating systems (that alternate not quite solution being one of the reasons that nice bit of transparent automation didn’t make the cut.)  

SIGH. The worst one we failed to reach consensus on was creating a varchar type that recorded the difference between NULL and the empty string. That still blows chunks to this day and my comment at dinner at Kincaid’s to Bob Miner that changing all our code would be a lot of work was the thing I’ve said in my entire life that I would most like to not have said. Since we’d already laboriously handled the mistake that Oracle considered empty strings to mean NULL in all our code, I couldn’t justify the effort to my employer at the time.  

oops. Sorry.  

mwf  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Tanel Poder Sent: Monday, February 25, 2019 1:37 PM
To: dougk5_at_cox.net
Cc: oracle-l-freelist
Subject: Re: Managing large ASM trace files  

Hi Doug,  

At OS level, you can truncate the file using:  

echo > filename.trc  

or just  

> filename.trc
 

Apparently there's a truncate command in Linux as well (but I've never used it).  

--

Tanel Poder

https://blog.tanelpoder.com/seminar

 

 

On Mon, Feb 25, 2019 at 12:00 PM DOUG KUSHNER <dougk5_at_cox.net> wrote:

Is there a way to manage the size of 12.2 ASM trace files?  Several trace files for gmon, lmhg, gen0 and mmon processes appear to keep the same PID for the instance lifetime, resulting in very large trace files.  Setting MAX_DUMP_FILE_SIZE will prevent the trace file from growing beyond the max size, but does this by not logging new events to the files.

I'm looking for a way to trim or otherwise manage the size of these files, which have open file handles so it is not as simple as deleting or archiving them.

Thanks,

Doug

 

 

 



--
http://www.freelists.org/webpage/oracle-l