2010-05-03 06:30 AM
Hi there, I'm looking for some advice...
I have a single SQL production server (runs as a VM) and run Snap Manager for SQL, its configured to take snapshots and use SnapMirror to replicate our local snaps to a DR box on another site.
Thankfully I haven't had to restore a production DB yet, however I am needing to document the process for our DR plan, I noticed a similar post already in here but it isn't helping with my specific problem.
Basically it is to do with performance and the length of time it takes to restore a DB. I have read through the admin guide and tr-3604 and what does become very clear is our lack of a Verification server - so I'm pretty sure that could be where the problem lies. The configuration was done by a NetApp consultant, however it would look like this has been a bit of an oversight. We are only licensed per server (and not per filer) so from another post I've seen in here I believe that if I configure a Verification server I will need another SMSQL and SnapDrive license. Is this correct?
My specific issues are:
The snapmanager software is quite unresponsive
When restoring a DB the other DB's hosted by this 1 production server take a huge hit
The length of time to restore a 15Gb DB seems too long (about an hour - including running the SMSQL application)
So can someone tell me what my best options to improve this are?? I have previously raised a support ticket with NetApp but I was told the delay I was experiencing was pretty normal... surely others have a different experience?
2010-05-03 06:44 AM
If you have more than one database sharing one LUN (or 2 LUNs) and you only restore one of them, SMSQL will have to use copy restore method, which is slow than LUN level restore method. You may want to consider changing the database layout, so only one database resides on one LUN.
Restore time should have nothing to do with verifications server, which is used for runing DBCC checkdb on the database in the snapshot. You could choose not doing verification before the restore.
2010-05-03 07:27 AM
So you do have share LUN configuration. If you have a very big database, you may consider creating a new LUN and moving that big one to it (assuming all others are small dbs).
2010-05-07 07:22 AM
Yes the LUN is shared, however the size of DB's doesn't make creating a new LUN for each DB that appealing. My two main DB's are about 15Gb, other than that there are another 20 or so with a few Gb each - but probably half are 'critical' so I don't want to have to have about loads of LUNs (1 for each critical DB).
I see what you're saying though in terms of why it is slower to restore this way (so thanks for your suggestion). I suppose I just hoped that the general slowness of the application itself in choosing which one to restore from was being caused by something specific. Probably takes about 10 minutes to even begin to choose which DB I want to restore.