Re: Current Redo got deleted
Date: Mon, 23 Mar 2015 01:48:03 -0400
Message-ID: <CAAaXtLAVtB37HAP_7wTDGHcUKiLMfPVK7_auSqdTotkkxOP5eQ_at_mail.gmail.com>
Begging is so unseemly. But then, you don't really seem to be begging at all, so let's set that aside.
Please bear in mind, Mladen, that we are discussing a single specific case here, where an active online redolog was (apparently) manually deleted. That suggests, by the way, that it most probably was not on ASM storage, although in saying that I make the (perhaps foolish) assumption that somebody with sufficient knowledge to delete files from ASM would not at the same time be foolish enough to delete something without first knowing EXACTLY what it is. I am, however, making assumptions here.
Pretty much the only thing that will protect you from manual deletion of an online redolog is to have more than one copy. Differ with that all you like. But understand you might be "betting your paycheque" when you do.
RAID-0+1 is good. Very, very, good. And yes, it will provide adequate protection from a (hardware-based) single-disk-failure. I really encourage the use of RAID-0+1. (Well, RAID-10, ideally, but there's no need to split hairs, right?) But it will do NOTHING to protect you from some idiot armed with */bin/rm* -- or a disk formatter.
Of course NOTHING is going to protect you from a complete idiot intentionally scanning the entire filesystem and deleting anything that resembles a redolog. (You'll, note, though, that I did recommend changing the filename extension to something "safe", at the same time I recommended duplexing.) Similarly, nothing is going to protect you from the same idiot executing the command */bin/rm -rf /* (which is decidedly easier to type!). But the fact that "perfect" protection from this sort of human error (or sabotage) is not practical does not mean we should not take precautions to make it more difficult -- at the very least to make it more difficult to do *accidentally*.
REDO is where your current (or most recent) transactions all live. Really, can you be too careful with it?
Yes, there are probably some edge-cases where duplexing online redologs will impose an intolerable burden on your system. But cases like that should be the exception, not the norm, and should not be used as the "basis" for formulating good practices. And that goes doubly in an environment that just suffered an outage because somebody deleted the only copy of the current online redolog.
On Sun, Mar 22, 2015 at 9:27 PM, Mladen Gogala <dmarc-noreply_at_freelists.org> wrote:
> 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.
>
> ...
>
> --
> Mladen Gogala
> Oracle DBA
> http://mgogala.freehostia.com
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Mon Mar 23 2015 - 06:48:03 CET