SMSQL Restores Are So Slow They Are Unusable

[TMADOCTHOMAS]

Hello,

We have had nothing but bad experiences so far in performing restores through the SnapManager for SQL tool.  We are on version 6.0.1, with SnapDrive 6.4.2.  When double-clicking the backup you want to restore, it can take 3 - 5 minutes for a list of backups to appear.  In some cases, we've waited 15+ minutes with no response, and finally had to cancel and re-try.  Sometime we get error messages.  Almost never has it 'just worked'.  We opened a NetApp case and they gave us a registry key to increase the timeout, which didn't really help.  In almost every restore, we've had to resort to manually creating FlexClones for the DBA's to use.  Has anyone else encountered this behavior or found a solution?

[TMADOCTHOMAS]

In case anyone searches and finds this post:

This particular SQL cluster is our largest, with two SQL instances and dozens of databases.  We back up transaction logs every 15 minutes, and we do this via one job for each database for each instance.  Similarly, we have one nightly job that performs a full backup of all databases in both instances.

Whenever double-clicking a backup to restore, SMSQL enumerates each backup for each database, not just the one backup we want to restore from.  This is 100+ databases x 96 backups and SMSQL cannot keep up.  NetApp Support has indicated this is a known issue and they are working on a redesign to address it.