RE: San & single point of failure

Beware also of SAN administrators who setup RAID 5 and later give that storage to DBA's for their databases. It does not hurt to double check what kind of underlying RAID they've got for you.

Julio

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Bradd Piontek Sent: Monday, November 17, 2008 4:06 PM
To: czeiler_at_ecwise.com
Cc: oracle_l
Subject: Re: San & single point of failure

there are other reasons to multi-plex the controlfile If you only have one, you aren't guarded from logical controlfile corruption. OR, say, maybe a dba or admin accidentally removes one of your controlfiles.

In theory, provided your SAN adminstrators lay things out correctly, there may be something to be said for their redundancy at the hardware level. I've seen database be sliced up into /data and /archive. As time has gone on in my career, I've asked more questions on the layout and thought about things a bit more. I'm not sure there is a clear cut answer, but it definitely does 'depend'.

Bradd Piontek
  "Next to doing a good job yourself,

        the greatest joy is in having someone
        else do a first-class job under your
        direction."

• William Feather

On Mon, Nov 17, 2008 at 2:50 PM, Claudia Zeiler <czeiler_at_ecwise.com<mailto:czeiler_at_ecwise.com>> wrote:

All,

I have just been given a new server to put a database on. It is a SAN server, but the apparent layout of drives to me is:

/redo1

/redo2

/big everything_else_disk

This means that I have just put control_file1, 2, and 3 all in the same place - on /big. I thought that the whole point of multiple control files was to avoid single points of failure, such as a single location.

I am told that SAN layout is to handle mirroring, striping, & hot spots behind the scene and I don't need to worry. If this is true, why do I need duplicates of the control file?

Something smells fishy to me. Does anyone else have an opinion?

-Claudia

--
http://www.freelists.org/webpage/oracle-l