RE: RedHat 6 RAC Specific Questions & Concerns
Date: Mon, 19 Aug 2013 10:47:22 -0500
Message-ID: <F05D8DF1FB25F44085DB74CB916678E887A61A2E90_at_NADCWPMSGCMS10.hca.corpad.net>
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_at_ardentperf.com]
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
--
http://www.freelists.org/webpage/oracle-l
Received on Mon Aug 19 2013 - 17:47:22 CEST