From: D'Hooge Freek <Freek.DHooge@uptime.be>
To: "Jon.Crisler@usi.com" <Jon.Crisler@usi.com>, "Mark W. Farnham"	<mwf@rsiz.com>, "oracle-l@freelists.org" <oracle-l@freelists.org>
Date: Wed, 21 Oct 2009 19:21:12 +0200
Subject: RE: RAC on Linux moving OCR and Voting disk to another SAN
Thread-Topic: RAC on Linux moving OCR and Voting disk to another SAN
Message-ID: <4814386347E41145AAE79139EAA398980D2E239464@ws03-exch07.iconos.be>
References: <C6A86B84C27C4E87B246BE30B0CBEA55@rsiz.com> <56211FD5795F8346A0719FEBC0DB0675052F265E@mds3aex08.USIEXCHANGE.COM>
In-Reply-To: <56211FD5795F8346A0719FEBC0DB0675052F265E@mds3aex08.USIEXCHANGE.COM>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
Precedence: normal
Reply-to: Freek.DHooge@uptime.be

But during the period that you run on the mirrors, you are vulnerable for split brain situations.
I would rather use the methods described in 428681.1 and just make sure that you have a backup of the votingdisks (using dd) and the ocr volumes (ocrconfig -export) on local disk.
In case of a problem you can quickly restore them to the old luns (which you can remain attached to the servers).

For migration of the asm disks, you can just add the new luns to the asm disk groups and then remove the old ones.

I have used this scenario already with several customers when they migrated to a new san.


Regards,

 
Freek D'Hooge
Uptime
Oracle Database Administrator
email: freek.dhooge@uptime.be
tel +32(0)3 451 23 82
http://www.uptime.be
disclaimer


-----Original Message-----
From: oracle-l-bounce@freelists.org [mailto:oracle-l-bounce@freelists.org] On Behalf Of Crisler, Jon
Sent: woensdag 21 oktober 2009 19:08
To: Mark W. Farnham; oracle-l@freelists.org
Subject: RE: RAC on Linux moving OCR and Voting disk to another SAN

I think one of our major concerns is to prevent a failure due to disk
issues on the old SAN.  If I add mirrors to the new SAN for OCR and
Voting disk (VD), we can then worry about removing the old ocr and vd
during a maintenance window at our leisure. 

-----Original Message-----
From: Mark W. Farnham [mailto:mwf@rsiz.com] 
Sent: Wednesday, October 21, 2009 11:53 AM
To: mwf@rsiz.com; Crisler, Jon; oracle-l@freelists.org
Subject: RE: RAC on Linux moving OCR and Voting disk to another SAN

I see K Gopalakrishnan has already responded and added a version
warning. He
even spelled his own name correctly. Sorry about the extra "la" in my
earlier post.

mwf

-----Original Message-----
From: oracle-l-bounce@freelists.org
[mailto:oracle-l-bounce@freelists.org]
On Behalf Of Mark W. Farnham
Sent: Wednesday, October 21, 2009 11:43 AM
To: Jon.Crisler@usi.com; oracle-l@freelists.org
Subject: RE: RAC on Linux moving OCR and Voting disk to another SAN

Having not done this yet personally and having only read about it, take
this
with a grain of salt and of course read the manuals. My thoughts would
trend
toward adding new OCR and voting disks in the desired locations and then
later removing the ones to be removed. I believe that without adding
"mirrors" (which I wish they called plexes or image copies, because hey,
they are really not backward images) you have to have an outage to move
them.

I believe the commands you want are ocrconfig and crsctl.

I think I've seen the details in K Gopalalakrishnan's book on RAC, and
in
the Julian Dyke/Steve Shaw book as well if you need something more
succinct
and clear than the manuals.

Good luck,

mwf
<snip>
without any downtime.  However, we cannot figure out if it is possible
to move the OCR and Voting disk with no downtime.  Does anybody have any
<snip>


--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l