2010-01-12 02:26 AM
I have multiple Microsoft 2000/2003 Clusters running SQL 2000 and am required to migrate all databases to new storage.
One option is:
Snapmirror all the existing volumes then.
Stop SQL services
Update the snapmirror
Break the Snapmirror relationship to make the mirrored data read / write
Present the mirrored LUNs to the SQL cluster
Assign the new LUNs the drive letters of the existing LUNs
Start up SQL
My concern is that there may be an issue with Cluster didk signatures etc.
Has anyone done this? Is there a flaw to this approach?
2010-01-16 06:57 AM
We have moved our SQL volumes between aggergates and between filers using these steps:
Works for use
2010-01-16 01:56 PM
Quick question re this:
Are you sure it is necessary? If that would be the case, then recovery times for a DR plan in similar environment should be substantially increased.
I always thought Windows is blind for LUN serial number & the fact that LUNs at the destination have the same signatures are good enough to seamlessly recover.
(After quick web research I am doing at this very moment it looks to be slightly more complex, e.g.:
But it is still for me hard to believe LUN serial number fix would be required for a site-to-site failover...)
2010-01-18 01:04 AM
If you want to power down your servers and move the luns and then just start the servers without any changes. Change the ID.
If you want to discount the drives, move luns and then reconnect disks in snap drive. There is no need to change the ID.
I use both methods without issue.
2010-01-18 02:54 AM
if possible, most secure & clean way is to disconnect using snapdrive and then reconnect, all while server is still runing but SQL services stop
ped. this makes sure you really have the correct disks at the right driveletter/mountpoint.
i strongly suggest a full reboot of the server after everything was moved & changed anyway to make sure its all reboot persistent.
2013-03-15 11:43 AM
Thanks for the sequence of events. One thing to note, though, for those folks using SnapDrive and SMSQL; the final snapshot should be taken with SMQL/SnapDrive in order to successfully mount the LUN on the far end. If the snapshot is not taken or taken via the CLI or System Manager, you'll receive an error stating, "Unable to find a Snapshot copy containing a consistent LUN to restore."
You can see this thread for the idea: https://communities.netapp.com/thread/15903