RE: RedHat 6 RAC Specific Questions & Concerns
- From: <Christopher.Taylor2@xxxxxxxxxxxx>
- To: <jeremy.schneider@xxxxxxxxxxxxxx>
- Date: Mon, 19 Aug 2013 10:47:22 -0500
So, if I were to want to design a system of less complexity (i.e. less
potential stress), would you recommend using a normal/standard clustered
filesystem for OCR and voting disks such as GFS for RedHat, or OCFS2 for Oracle
Linux and would it have to be a raw device, or would a cooked filesystem
mounted with O_DIRECT be sufficient?
I would imagine that high-end performance of OCR/Voting files is of "least
concern" when it comes to clustering, and recoverability (and ease of
recoverability) would be the driving factor here?
Thoughts?
Chris
From: Jeremy Schneider [mailto:jeremy.schneider@xxxxxxxxxxxxxx]
Sent: Monday, August 19, 2013 10:33 AM
To: Taylor Christopher - Nashville
Cc: Oracle-L
Subject: Re: RedHat 6 RAC Specific Questions & Concerns
I have set up clusters in all of these configurations - raw, CFS and ASM for
OCR/voting.
A few weeks ago I unexpectedly had to completely recover a multi-TB cluster
database from backups. It was an intense situation with several levels of
management watching over our shoulders and sweating every minute of downtime.
In this case the OCR and voting disk were stored on ASM.
We did get everything recovered - but there are a lot of surprises in store for
you guys when you first try to recover a database where OCR/Voting are on ASM.
The problem is all the bootstrapping and interdependencies between ASM and CRS.
And they changed the syntax of recovery commands between 11.2 point releases.
And there are still gaps in the documentation - even on metalink/MOS.
After my experience with that recovery, I would personally counsel people to
avoid putting the OCR/Voting disks on ASM when possible until it stabilizes a
little (no more syntax changes in point releases!!) and until the documentation
is a bit better. I would recommend still using raw devices -- even with 11gR2.
Contrary to popular belief, raw devices *are* still supported by the 11gR2
software (this is in the docs and on MOS)... you just have to use the command
line to configure it because Oracle removed support from the installer and
other GUIs.
On a related note, I would also recommend that you use dedicated volumes for
your OCR and Voting Disks -- this offers a few advantages over using a volume
which also hosts other data (data files, ACFS volumes, etc). For example...
try doing a space reorg that requires dropping a ASM disk that has a voting
disk on it... and BTW I think the 12c docs mention this as a recommendation
too.
But note that the 12c docs state that they have completely removed support for
raw devices in that release and whenever the time finally comes to upgrade to
12c you will be forced to migrate to ASM or CFS for your voting disk and OCR.
IMHO Oracle's whole architectural decision to force the OCR and voting disks
into ASM volumes is completely premature. ASM is generally treated as a
"cluster resource" which can't start until clusterware is running and you need
lots of "special" backdoors to get the OCR/Voting disks into it. It's beyond
me why they decided not to allow raw devices anymore. Especially when they
still recommend a "quorum" volume dedicated to voting disks in 12c! If a LUN
is only for a voting disk, then adding an ASM layer only does one thing:
complicate recovery. I really don't see any advantage at all.
Sorry, /end ranting... and just my opinion anyway, after a recent irritating
experience with a restore...
-J
--
http://about.me/jeremy_schneider
--
//www.freelists.org/webpage/oracle-l
Other related posts:
