RE: Moving VLDB RAC to a new datacenter
Date: Wed, 26 Feb 2014 17:43:23 -0500
Message-ID: <1ad101cf3344$2893eed0$79bbcc70$_at_rsiz.com>
DWH you say. So it would be helpful to know what your load strategy, frequency, and size is.
Especially whether or not you have any non-batch updates.
For example if you only loaded new data once a week, you might want ship the whole thing and load them both the cutover week, run plenty of diagnostic queries, rinse and repeat being confident all your feeds and results worked before you released the current production.
Even if it is more frequently than weekly, as long as all the updates are batch processes, it is just a question of shipping some vintage of the database and then applying all the batch loads and supplementary aggregations just as you did to the original. In fact doing that for a whole cycle of loads has the salutary effect of making sure you didn't leave any pieces of software behind.
If you've got manual (meaning people typing stuff) updates or trickle feeds where you never possess the new data independently of the database you still might be able to capture all the inputs for replay, but it would require planning and discipline and knowing where each update fits in relation to an batch loads and aggregations.
The ways you've mentioned below should also work. Best if you've got a log of your exact releases and patches for everything, so nothing is different beyond the network addresses.
mwf
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Radoulov, Dimitre
Sent: Wednesday, February 26, 2014 4:59 PM
To: oracle-l_at_freelists.org
Subject: Moving VLDB RAC to a new datacenter
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:
- rman backup in mount state to a temporary storage and restore to a new RAC in our datacenter.
- 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
--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l
Received on Wed Feb 26 2014 - 23:43:23 CET