Re: Current Redo got deleted
Date: Sun, 22 Mar 2015 21:27:39 -0400
Message-ID: <550F6C0B.8080209_at_yahoo.com>
On 03/22/2015 06:38 PM, MARK BRINSMEAD wrote:
> The FIRST thing you should do, now that you have the database open...
> ...is to DUPLEX all of the online redologs. And while you are doing
> that, rename the surviving logfile members if necessary so you do not
> use a filename extension that says "delete me!" the way that ".log" does.
I beg to differ. There is no reason for redo log duplication if redo logs are already on RAID 1+0 volume, which they usually are. Redo log duplication in that case will force the database server CPU to do what the customer has already bought their SAN for. Your advice stands only if redo logs are on the local disks, which is exceedingly rare. The same goes for "normal redundancy" ASM disk groups. I see no reason for doing it, if ASM disk groups are on SAN, with built in redundancy., as is the case with RAID 1+0 LUNs.
The problem in this situation can be traced to the naming standards. As a consultant I am constantly warning my clients to never use ".log" extension for redo log files, despite the fact that OFA says so. Many system administrators have cleanup scripts, scheduled for wee hours of the night, which do something like this:
find / \( -name ".buf" -o "*.log" -o "*.dmp" -o "*.bak" \) -mtime +30 -print|xargs rm -f
And that will destroy the log files with the names that end with ".log",
even if the redo logs are duplexed. The solution is in changing the
extension for the log files. Nobody will delete files with the extension
".rdo", which is what I use for the databases I create. Of course, many
things can be said about carelessly allowing automated scripts to do the
cleanup but that is a system administration issue which doesn't belong
on this group.
I stopped using the "find" command to cleanup my Linux systems a long,
long time ago. There is a utility called "bleachbit" which does a
marvelous job and can be found here:
http://bleachbit.sourceforge.net
It's configurable and I utilize it to clean up afiedt.buf and similar which I carelessly leave all over the system.
-- Mladen Gogala Oracle DBA http://mgogala.freehostia.com -- http://www.freelists.org/webpage/oracle-lReceived on Mon Mar 23 2015 - 02:27:39 CET