Moving Oracle to new SAN without breaking ServiceGuard

[Jeffrey E. Stevenson]

I currently have 2 Oracle databases set up using ServiceGuard, storing their datafiles on a SAN. We now have a new SAN and need to move the Oracle datafiles from the old SAN to the new SAN. Are there any set instructions already written up explaining how to do this without breaking ServiceGuard?

[TwoProc]

Jeff - I don't think this is possible, as all of your volume group moves (for your SAN) are defined in the startup and shutdown scripts of the package for Oracle that you're using.

But, if you look at the definition of the cluster, you should be able to see what changes need to be made to remedy the situation, and change the package to use the new volume groups, instead of the old. Once you've looked at a working script, you can see it's a bit complicated, but straightforward.

[Michal Kapalka (mikap)]

hi,

i think its possible only if you shutdown the DB server.

mikap

[Jeffrey E. Stevenson]

When I do this, I will be able to shutdown both databases. So, that was already planned.

[Matti_Kurkela]

If your Oracle databases are "basic" failover packages (=not Oracle RAC), and your Serviceguard configuration uses a quorum server OR your Serviceguard version is new enough, you might be able to migrate your data to the new SAN without stopping Oracle at all.

Of course, stopping Oracle may still be useful because it frees all the system resources (mainly I/O capacity) for the data migration.

First, find your "Managing Serviceguard" manual (also available at http://docs.hp.com High Availability section) appropriate for your Serviceguard version. Read Chapter 7 (Cluster and Package Maintenance), subchapter "Reconfiguring a cluster", sub-title "Updating the Cluster Lock configuration". If your Serviceguard version allows on-line cluster lock reconfiguration, the instructions will be there. Otherwise, there will be the instructions for off-line cluster lock reconfiguration only.

The general idea in on-line data migration is to add LUNs from the new SAN to the old VGs one by one. You do this on the node that is currently running the package.

As you don't mention VxVM, I assume you're using the default LVM.

If you have MirrorDisk installed, you can then use it to mirror each LV to the new LUN, then delete the old side of the mirror set. If you don't have MirrorDisk, you can still do an on-line migration using the pvmove command. Once an old LUN becomes completely free, you can use vgreduce to remove it from the VG.

The cluster lock LUN(s) will require special attention, but the procedures are described in the "Managing Serviceguard" manual (see above).

You must also make the failover node aware of the migration. Create a new map file for the package VG on the primary node (using "vgexport -p -s -m "), then move the map file to the failover node, export the package VG, then use the new map file to re-import it. (This is the same procedure as when adding a new LUN to a package VG.)

Once all old LUNs are free, you can disconnect the old SAN and use "rmsf -a " to remove the old disk devices from the system configuration.

We've done multiple data migrations in this way quite successfully.

MK