Re: Moving VLDB RAC to a new datacenter

  • From: Martin Berger <martin.a.berger@xxxxxxxxx>
  • To: Dimitre Radoulov <cichomitiko@xxxxxxxxx>
  • Date: Thu, 27 Feb 2014 17:07:41 +0100

Hi Dimitre,

We did similar things several times. Unfortunately you did not tell in your
email if your storage (FC or NFS?) can be shared across both data centers?
In our env it can, so we have:
DC1:
Storage1
node1; node 2
^
|
v
DC2:
Storage2

the steps are like:
1) make Space from Storage2 available for node1 & node2
2) add the new Space from Storage2 to the DiskGroups, remove "old" Space
(as the link DC1<->DC2 is less powerful than local Storage, there is a
Performance degregation. Still this step can be done within some hours)
3) shutdown node1 and node2; physically move it to DC2; mount & start it.

This works fine in our env, the downtime is 'only' the time to shutdown,
move, startup.
But of course the shared storage is required.

hth
 Martin


On Wed, Feb 26, 2014 at 10:59 PM, Radoulov, Dimitre
<cichomitiko@xxxxxxxxx>wrote:

> Hi all,
> source and target environment:
>
> RHEL 5.8
> RAC EE 11.2.0.2 on ASM
>
> We've been asked to move a multi-terabyte DWH two-node RAC database from
> one datacenter
> to another. The database is currently in noarchivelog mode (and there is
> no space to enable it).
>
> We're considering the following options:
>
> 1. rman backup in mount state to a temporary storage and restore to a new
> RAC in our datacenter.
> 2. Storage cloning: shut down the cluster and clone the LUNs to a
> temporary storage to plug in
> to a new RAC in our datacenter.
>
> In both cases, I suppose, we'll need to setup a new RAC in our datacenter.
> For option 1, we'll need to restore the database, register it as a cluster
> resource
> and add an instance. For option 2, we'll need to create a new database
> with the same
> name and the same ASM diskgroup layout. After that we'll need to shut down
> the database, detach the storage and present the cloned LUNs to the hosts.
> After bringing up the database we'll need to change the old GI references
> (remote listener
> to the new scan name).
>
> Of course, I'm not sure if the high level action plan above is
> correct/complete
> and I don't seem to find any MOS note/documentation that describes such a
> scenario.
>
> Any corrections, suggestions and references are welcome!
>
>
> Thanks
> Dimitre
>
>
>

Other related posts: