Gzipping Oracle archive logs

[phil cook]

Hi

I'm running an Oracle database on a machine where space is a major consideration. Intermittantly huge batch loads occur on this machine & have on occasion blown away the archive logs filesystem. Currently I run a cron job (find) to gzip these archive logs every fifteen minutes if they are more than a day old. What I'd like to do is gzip every file in that area apart from the one that Oracle may currently be writing to. I could simply add a gzip * to cron but am afraid of the consequences should this clash with a file being written. I'm sure there is a fairly simple solution but I'm afraid I'm a bit slow. Can anybody suggest a good method?

Thanks

Phil

[Sandor Horvath_2 · Accepted solution]

Hi !

Try
gzip `ls -t | tail +2`

by Saa

[Alexander M. Ermes]

Hi there.
I attached a script, that we usefor some time now.
I hope, it helps.
Rgds
Alexander M. Ermes

[Suhas_2]

Phil,
Here are my two cents...
1> suppose you want to gzip /ora1/*
2> use "find" with "newer" option to find those files.
You can generate the template file with
"touch -t filename" command.
3> After finding those files, zipping them is simplest task.

Hope this helps...
Suhas.

[phil cook]

Thanks to you all for your suggestions - have used the first one (ls -t | tail etc) & this is working just fine.

Regards

[Dan Hetzel]

Hi Phil,

To avoid 'gzipping' the files already zipped, you may use:
gzip `ls -t !(*.gz)| tail +2`
meaning "list all files not ending in .gz"

This works in Posix and Korn shell

Best regards,

Dan

[phil cook]

Cheers Dan - I am using the method in the form

gzip `ls -t /live/oraarch/*ARC | tail +2`

which is giving the same result I'd guess.

Yours does look a bit neater though.

Thanks

[Alan Riggs]

Just FYI, your concern about zipping an active oracle archive log might be unnecessary. Speak to your DBA, but a standard way of oracle archiving involves a rotation of 3 archive logs. the archive is actually kept in oracle's shared memory segment. As one log fills, data rolls over smoothly into the next, and the full log is written into the archive directory. So, if you look at the directory at any given time, you will see only files that are "full" (the exact size your DBA has configured for archive rollover). The "active" log is in the SGA.

[Don Bentz]

FYI - MY DBA tells me that even though the archived redo_logs APPEAR full, the database has simply allocated a file according to its required size and may still be actively writing to it. The filesize may not change from the original allocation. If you delete the "latest" file, you could run the risk of copying/gzipping/deleting an incomplete copy. I would welcome any authoritative information to the contrary.

[Alan Riggs]

Well, I don't want to get into a DBA pissing match, so I will simply note that running wc against the newly created archive logs as they appear should shed light the question in your environment. On my system, comparing the last two created logs yields:

963580 2309305 104858624 arch_36645.log
954027 2454387 104858624 arch_36646.log

This seems to support the idea of a "full" archive log being deposited in my environment. YMMV, of course.

[John Palmer]

There will be finite amount of time during which the oracle arch process copies the latest online log file to the archived log directory.

This will vary due to a number of factors such as the logfile size and you do need to cater for it in your script.

What I do in my script is to check if the log is being written with the 'fuser' command. Something like:-

LOGS=$(ls arch*.log 2>/dev/null)

for LOG in ${LOGS}
do
if [[ -n $(fuser ${LOG} 2>/dev/null) ]];
then audit "Log ${LOG} is in use, ignoring..."
continue
fi

audit "compressing ${LOG}"
/usr/contrib/bin/gzip ${LOG}
# anything else you want to do to the log
done

I've just checked one of my servers and in the last three weeks, out of 523 logs being compressed, one was in use when the script was run (every 5 minutes).

Regards,
John