RE: RAC servers as-is move to new DataCenter
Date: Thu, 19 Mar 2015 14:23:19 -0400
Message-ID: <0cff01d06271$c7354d10$559fe730$_at_rsiz.com>
Since you’re already proposing a single temporary server, why don’t you just do a standby on that. You don’t need horsepower to run production there, but rather just enough horsepower to keep up with redo application.
Step 5 becomes Shutdown Applications
6. Allow pending transactions to complete
7. Restart restricted, switch redo logs, etc.
8. Shutdown at DC1.
9. Start and make primary at DC2 to make sure nothing boneheaded took place.
IF 9. fails, you abort until you can restage the move eliminating whatever boneheaded took place.
Old 9 regarding rsync for things not in the database still might need to be done.
Still need outage for the time to move the servers and point the existing DC1 servers at the relocated primary database,
but you’ve eliminated the time for RMAN out and back in.
You gain in that the up to date known good copy of the database is never in transit.
While the servers ARE in transport you might make an RMAN backup local to DC2.
If you stick with your plan, you probably want to make TWO RMAN backups to disjoint disk sets and retain one copy at DC1.
”I’m not paranoid, I’ve been a production DBA.”
mwf
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of msanjeevk
Sent: Thursday, March 19, 2015 1:23 PM
To: ORACLE-L
Subject: RAC servers as-is move to new DataCenter
All,
We have 2 node 11.2.0.4 RAC on OEL 6.5 (64bit) using Pure Storage LUN's for ASM in DataCenter1(DC1)
We do not use ASMLIB. For device persistence use combination of udev and multipath.conf
Requirement is to move servers(as-is move) -- to new DataCenter2(DC2) which has its own seperate Pure Storage Array
Public/VIP and SCAN IP's will remain the same after move to new DC2
I've checked the possibility of building 2 new servers at DC2 and setup standby etc to do cutover with less downtime however been told they don't have budget to buy new servers at DC2.
At highlevel plan will be - haven't done the POC yet for this:
Steps:
- Build a single temporary server which has same version at DC2
- Request SA to provision storage for Oracle/Grid Home etc to match mounted file systems on servers at DC1 and mount them with appropriate name at DC2.
- Do initial rsync between file systems at DC1 & DC2
- Request SA to provision LUN's from Pure storage and discover them at DC2 on temporary server
- Shutdown applications and database in DC1
- Take RMAN backup to disk
- Shutdown Oracle cluster services
- Request SA to copy the LUN allocated for ASM diskgroup hosting OCR and voting disk at DC1 to device with same name to a LUN provisioned at DC2
- Do final rsync between file systems at DC1 & DC2
- SA to move physical servers to new DC2
- At DC2, SA to bring up RAC servers and discover storage file systems that were earlier mounted on single temporary server
Permissions and mount points etc will match with how they existed at DC1
- SA to discover LUN's allocated (in step4 above) from Pure Storage at DC2
- Validate udev and multipath.conf and pure related rule files at the OS to make sure the wwid's are updated correctly for those devices
- Start cluster -- make sure everything looks good with OCR and voting file
- Create ASM diskgroup using devices provisioned in step10 above.
- Mount ASM Diskgroup on both RAC nodes to ensure its successful
- Restore RMAN back to ASM diskgroup and bring up DB
Are there any issues with this approach.
I've already reviewed this note:
Exact Steps To Migrate ASM Diskgroups To Another SAN/Disk-Array/DAS/etc Without Downtime. (Doc ID 837308.1)
But I cannot follow that as Pure Storage SAN is in 2 different data centers and our SA mentioned there will be only scp allowed between data center to copy files between storage file systems.
Also is there a better and efficient way to do this move with Pure Storage level LUN's copy between datacenters instead of RMAN backup and restore.
Has this been tried by other people in this list before.
Regards,
Sanjeev.
-- http://www.freelists.org/webpage/oracle-lReceived on Thu Mar 19 2015 - 19:23:19 CET