You might want an endorsement from Oracle support.
There's nothing worse than when you encounter a (possibly totalled
unrelated) bug months down the track, and you get stuck trying to
explain/prove that this process had nothing to do with it
hth,
Connor
On Thu, May 7, 2015 at 10:13 PM, Andrew Kerber <andrew.kerber@xxxxxxxxx>
wrote:
I dont see any holes in this right now. But I would definitely rehearse
it once or twice before I tried to do it on the production RAC.
On Wed, May 6, 2015 at 5:11 PM, Hubler, Daniel <daniel.hubler@xxxxxxxxxx>
wrote:
Looking for opinions, anecdotes and comments on the following. . . . .
We have a 2-node RAC on IBM/AIX hardware.
Management has decided it is time to retire this hardware.
We have been discussing strategies for moving the new hardware into place.
There are now 2 opinions on how this could be/should be done:
a) Follow the RAC administration guide adding a new node into the
cluster,
and then take an old node away. The cluster grows from 2 nodes, to
3 nodes, then back to 2 nodes.
b) Move the new hardware into place using the following steps:
1) generate a MKSYSB of the LPAR to be replaced
2) shut down the LPAR to be replaced
3) create an LPAR on the new hardware, using the MKSYSB from the old
hardware
4) present the LUNs that were on the old node, to the new node
5) start up the LPAR on the new hardware; start up RAC
(and of course, the whole thing would have to be done twice; once
for each node in the cluster)
Plan “b” is a bit more involved than I present above.
It has been used successfully, many times, on LPARS that are running
stand-alone databases; not RAC.
We are a bit leery about executing plan “b” against an LPAR running RAC,
but we really
cannot see why it will not work.
Any thoughts appreciated.
Daniel Hubler
Aurora Healthcare
IT Infrastructure
--
Andrew W. Kerber
'If at first you dont succeed, dont take up skydiving.'
