Re: done something dumb!

I agree with Howard's suggestion for color coding your telnet session desktop. The basis of my color choice, however, is a little bit different.. The background color is based upon the environment, not the DB version. Bright eye-strain red for production, lurid orange for pre-production and a lovely soothing shade of green for test/dev.

In addition, we use a very basic single character prefix standard for the SID, dsid for development, tsid for test, psid for pre-production and sid (with no prefix) for the production instance.

  David  

On Tue, 10 Aug 2004 19:58:43 +1000, "Howard J. Rogers" <hjr_at_dizwell.com> wrote:

>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 - 22:02:01 CDT