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> 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