RE: San & single point of failure
- From: "Bobak, Mark" <Mark.Bobak@xxxxxxxxxxxx>
- To: "czeiler@xxxxxxxxxx" <czeiler@xxxxxxxxxx>, oracle_l <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 17 Nov 2008 16:11:01 -0500
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@xxxxxxxxxxxx<mailto:mark.bobak@xxxxxxxxxxxxxxx>
www.proquest.com<http://www.proquest.com>
www.csa.com<http://www.csa.com>
ProQuest...Start here.
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] 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
Other related posts:
