As SQL is an application database sitting on top of the volume/LUN and has it's own VSS writer with in the Microsoft VSS framework, hence its important that it's migrated using an application aware migration tool such as - NetApp SMSQL.
I wrote this post last month and showed the steps required for migrating SQL data from 7-mode to cDOT, which works perfectly fine. However I was intrigued to find out what if I use 7MTT tool to achieve the same result ?
Findings : Used 7MTT and it worked perfectly fine, still amused though. So, this is what I am going to elaborate here tonight.
What made it interesting:
1. I created 'test' db using SQL Management studio and created one table and inserted one row. This DB is initially on the local disk.
2. I created two volumes on the 7-mode filer : One for data and one for logs + snap-info.
3. I launched SnapDrive, added the 7-mode filer and created 3 virtual disk : Data, logs & snap-info. Data on a separate volume and logs & snap-info on the same volume but having separate LUNs.
4. I launched SMSQL console and moved the 'test' DB to 7-mode hosted LUNs : Primary data to Data drive, Logs to Logs drive and snap-info to separate drive.
5. I ran a first FULL backup with VERIFICATION, all came up good.
Here comes the 7MTT Tool:
6. Opened services.msc and stopped : SnapDrive & SnapManager services.
7. Launched 7MTT 3.3.1 tool and selected : Data & Logs volume for migration to cDOT SVM.
8. Migration (Final completion) happened successfully and it turned source Volume offline as I had chosen this option during final completion.
9. Opened system-manager GUI and launched cDOT filer and made sure the two Volumes now showed up, along with 3 LUNs. Please note 7MTT tool not only migrates the LUNs, it also maps them automatically (If chosen to be), I had checked by mistake, but it's ok. We just need to make sure we dis-associate them from the igroup.
Now, I must re-connect the same drives (3 LUNS that are migrated from 7-m to cDOT):
10. I went to cDOT system-manager and went to those 3 LUNs one by one and un-checked the mapping from the igroup.
11. I started the SnapDrive service and launched the SnapDrive management tool - I re-connected the 3 drives using the same 'Drive Letters' as it was with 7-m. However, the disk-signature had changed now, but will it matter ?
Finally:
12. I launched the SMSQL tool, and noticed it says 'test' DB is recovering..its in a hung state.
13. I was expecting this, as it was not a true application level migration and SMSQL must be wondering if these are the same disks ?
14. I didn't bother much to troubleshoot 'recovering...' error, as I knew I had taken a 'good back' post migration to 7-mode filer.
15. I used the restore wizard within SMSQL tool and restored the 'test' db from the last known good back. To my surprise, after the successful restore, when I clicked on the 'Backup' icon it didn't complain this time and it showed the drives correctly as it was with 7-m, except disk signatures.
16. Ran another full back and it worked perfectly. So, basically I have the working SQL 'test' DB hosted on my cDOT (Migrated usign 7MTT) plus the snapshots that were shipped as part of the snamirror replication process, which is the default mechanism for 'copy' based backup within 7MTT.
Tested:
17. I opened SQL Mgmt studio, selected 'test' DB and ran a query on table and it showed the row that I had populated in that table. Hmm...This is very interesting now, b'cos I was expecting the 'restore' to fail, as you remember this backup was made on the drives hosted on the 7-m LUNs, looks like 'disk signature' did not really matter to it. SQL database, snapdrive luns and snapshots are all working nicely.
18. Don't know if anyone has attempted this method on 'test' environment ?
I will be doing few more tests on the around migration concept, and will feed you back on the findings.
No comments:
Post a Comment