Re: done something dumb!

On Tue, 10 Aug 2004 09:31:35 +0100, Tom <tomNOSPAM_at_teameazyriders.com> wrote:

>> It doesn't, that's true. But you would have had to have issued three
>> complete separate rm or del commands to do the deed, which is unlikely
>> to
>> happen by accident, I would suggest. Either that, or the multiplexing
>> hasn't been done properly (for example, you can have three copies of one
>> log in C:\oradata. A del *.log would indeed wipe out all three in one
>> hit.
>> But having three copies of the same file in one directory on one disk
>> isn't actually proper multiplexing in the first placce).
>
> Sure - Scenario is dev box contains dev instance and tape drive. Another
> box is test box. I wanted to recreate a live instance on
> the test box for erm testing.
>
> Live RMAN backup sits on tape. So i put tape into dev box and extract
> required files for recovery into directory called recover -
> Phone rings, some form of emergency so go and sort that out. Come back
> do an ls and see my files ready and waiting.
>
> ** this is where i cock up!**
>
> On test box i have previously restored this same instance and so i have
> to remove those remenents first. So i start with the control
> and online redo.
>
> $ rm -f /u03/oradata/instancename/* && rm -f /u05/oradata/instancename/*
> && rm -f /u04/oradata/instancename/*
>
> AGGRRRRRRR - as you can see i never changed ternimal from the dev box to
> the test box after getting the files off tape and so i
> actually nuked the control files and the online redo from the dev box.
>
> So although very unlikely to happen it just goes to show it can actually
> happen and i am performing 'propper' miltiplexing even on a
> dev box. At least by me it seems! Anyway i restored the live instances
> to both boxes in the end and everything is OK.
>
> So remember - ALLWAYS CHECK YOUR TERMINAL!

Multiplexing is indeed designed to protect redo logs from hardware failure, not dba commonsense failure.

Issuing concatenated rm -f commands seems to me a little suicidal.

Having the same instance name on all three machines seems equally to be something of a death-wish. (I would suggest, for the future, something along the lines of /u0X/oradata/DEVsid, /u0X/oradata/TESTsid and /u0X/oradata/LIVEsid and so on). Do it here all the time. Still won't protect you from an rm -f /*/oradata, of course, but then at that point you should probably take a holiday and learn SQL Server whilst on it in any case.

I also colour code my desktops. If it's bright purple, it's 10g. If it's bright blue, it's 9i and if it's lurid green, it's practically unworkable and so must be 8i. You could do something similar, perhaps, to distinguish between live, dev and test. Just a thought.

Regards
HJR Received on Tue Aug 10 2004 - 04:58:43 CDT