Re: San & single point of failure

I've heard that several times before and the installations have worked well about half the time and not worked very well at all the other half of the time. It depends on your hardware and the expertise of the SAN engineer putting together the disk layout and all the other bits and pieces to ty into your database server hardware and operating system with an eye on the application characteristics (OLTP, DW, etc.).

That being said, give it a chance and see how it goes. But you should still squirrel away controlfiles, and redo logs (I also multiplex archivelogs) in separate directories to avoid the rm * thing (which happened to me about 15 years ago but the memory is as vivid this afternoon as it if happened yeasterday).

On Mon, Nov 17, 2008 at 3: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