RE: San & single point of failure

Hi Claudia,

The idea behind multiple control files is indeed to avoid single points of failure. It's really about how much risk you're willing to accept. Controlfiles aren't very large, so, many people (myself included), will have controlfiles in multiple locations (hopefully, multiple locations that map to different disks in the storage array).

However, with today's large storage arrays, that have lots (hundreds) of disks, and everything striped and mirrored (SAME strategy), it's often impossible to tell if "this" raw volume and "that" raw volume are mutually exclusive, in terms of the actual, physical, backend storage.

One could make an argument that, given sufficiently protected storage presented to the host for Oracle usage, that you really don't need more than one controlfile, as it's already been striped and mirrored and load balanced and everything else, by the storage array. But, this makes me a bit uncomfortable. At the very least, if you have multiple control files, and suffer some type of corruption of one of them, you can always repair any potential storage problem, and then copy over the controlfile from one of your redundant copies. Now, if you have a properly setup and executed backup strategy, then you should have a backup of the controlfile, and you should be able restore from backup and recover, in the event of a corruption, even if you have only one controlfile. However, it's a much simpler and quicker recovery, if you have multiple copies, to copy one over the other and go.

Bottom line, me personally, I have multiple copies. In my case, I use ASM, so, I have one copy in DATA_DG, one in REDO_DG, and one in FLASHBACK_DG. There's no way for me to guarantee whether that storage is actually completely redundant all the way down to the physical disks, and that's something I just accept. If you're a storage expert, or if you work with your SAN admin, he may be able to tell you if your various controlfiles are really physically redundant or not. Is it worth the trouble to do so? It comes back to where I started: how much risk will you accept, and how paranoid are you? :)

-Mark

--
Mark J. Bobak
Senior Database Administrator, System & Product Technologies
ProQuest
789 E. Eisenhower, Parkway, P.O. Box 1346
Ann Arbor MI 48106-1346
+1.734.997.4059  or +1.800.521.0600 x 4059
mark.bobak_at_proquest.com<mailto:mark.bobak_at_il.proquest.com>
www.proquest.com<http://www.proquest.com>
www.csa.com<http://www.csa.com>

ProQuest...Start here.

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Claudia Zeiler
Sent: Monday, November 17, 2008 3:51 PM
To: oracle_l
Cc: Colin Nicholls; Edivin (Lin) Cao
Subject: San & single point of failure

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