Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12345»»»

Netapp SnapManager for SQL Expand / Collapse
Author
Message
Posted Wednesday, July 08, 2009 9:07 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, April 10, 2014 6:33 AM
Points: 199, Visits: 478
Hello,

Is anyone using Netapp's Snapmanager for SQL to do backups/restores? Have you had any issues with it? All comments are appreciated.

Thanks.



Post #749368
Posted Thursday, July 08, 2010 11:18 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Today @ 5:25 PM
Points: 93, Visits: 245
Craig,

We have started adopting NETApp Snap Manager for SQL Server, and it looks like the road will be long and steep.

I have not found any recommendations for NETApp as far as standardizing on an enterprise level, so each server we tackle is being done one at a time, as far as configuring backups.

Couple that with the fact that we were not involved up-front (a perennial SQL DBA complaint), so we have to backfit several hundred servers to work with NETApp.

Have you had any luck?

Thanks,

Jeff



Post #949466
Posted Thursday, July 08, 2010 11:26 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, April 10, 2014 6:33 AM
Points: 199, Visits: 478
We have not purchased the software at this time. One of the reasons is that I fail to see the business value in it and was able to convince management of this , at least for now. Also, we are using Snapmanager for Exchange and had extreme problems getting it to work and configured. Can you share some of the details of your experience? Sounds like it is very labor intensive.

Thanks, Craig



Post #949469
Posted Friday, July 09, 2010 8:57 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Today @ 5:25 PM
Points: 93, Visits: 245
Craig,

NETApp is very good for what it was designed to do, which is, taking very fast snapshot backups of entire drives. This is an awesome tool from a storage tech's point of view. Not so much for DBA's. Where we are in our adoption of this tool is that we have no choice but to convert from backups on local drives or SAN drives (Tivoli) to using this volume backup methodology.

NetApp recommends that system database files remain local to the SQL Server physical server, while all other database files are split out on LUNS that are on the NetApp appliance. So my mdf files reside on one LUN, and my ldf's on another, with additional LUNS available for tempdb, and finally backups. And SM only likes 35 dbs on a LUN. So if I have 75 DBs on my server, I should have at least 8 luns with database files going to several locations. Think of the documentation to maintain and having to find the needed files during an emergency.

Moving to the new LUNS requires coordination between the storage folks, the server folks, the DBA team, and the user-base to move the files to their new homes. That is a lot of work.

One of the most highly touted benefits of SM is Fast backup and restore. You should know that this is only true if you plan on restoring ALL of your databases that are assigned to the LUNs that contain the data. Otherwise, your restore time and complexity INCREASE because the entire contents of the backed-up drive must be mounted, and then searched for the relevant database bits to restore. Problems we have encountered include
1) not having enough space to mount the drive allocated;
2) increased recovery time for a single database when many are assigned to a set of LUNs;
3) occasional SnapManager hiccups that make backups stop working;
4) The software backups manage the Log Sequence Numbers (LSNs) so if you take a native backup, you will have to recreate the backups using the SM tool, which is ok but not great. It will create a job to perform the backups, but we were kind of wanting a way to script this for standardization, and that still eludes us.
5) requirement for multiple backup strategies because system db backups are not part of what SM does. So now you have to have a backup plan for system db's, and one for user db's, if you didn't split those out before.
6) Determining the mix of databases to place on the same LUNs can be very problematic to triage. Business critical dbs should be on their own LUNS, and so should highly transactional dbs, but do you want to become a SAN specialist ? You will if you have to carve out LUNS for each special db on a server with 100 dbs.

Hope this helps.

Jeff



Post #950003
Posted Friday, July 09, 2010 9:15 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, April 10, 2014 6:33 AM
Points: 199, Visits: 478
Thanks for the insight, Jeff. That further reinforces my preference for the native tools. I can deploy my backup/maintenance jobs in about 2 minutes. Hope all works out ok for you.


Post #950023
Posted Saturday, July 10, 2010 12:03 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Saturday, July 10, 2010 11:44 AM
Points: 1, Visits: 0
Hi All,

I am interested to know if anyone has tested IBM Tivoli Storage FlashCopy Manager for SQL in production. I have read a good tutorial about it at: IBM Tivoli Storage Flash Copy Manager which make it seems quite good of a product, but I really would like to hear from some one who tried it in production.

Thanks in advance,
MSright1981
Linux 2 AIX Blog
Post #950357
Posted Wednesday, August 04, 2010 3:23 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, April 17, 2014 4:57 AM
Points: 398, Visits: 1,711
@chudman

How long did you find it takes to restore a snap of a LUN? Also, how large do the snaps grow to once taken? I know this is very much "it depends" but just looking at a rough estimate, whether they grow to 10GB or 100GB daily once snapped. Is it a like for like, as in if you increased the size of a standard DB by 10Gb would a snap grow by 10GB as well?


Chris

Blog:- chrisjarrintaylor.co.uk
Twitter:- @SQLGeordie
Post #963304
Posted Tuesday, July 12, 2011 7:44 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, April 02, 2014 9:56 AM
Points: 37, Visits: 158
I've written a few articles at MSSQLTips concerning implementing SMSQL and also testing backup times with snaps and streaming backups. http://www.mssqltips.com/author.asp?authorid=55.

We implemented SMSQL on a grand scale starting about 8 months ago. We currently have about 50 SQL Servers running the software. I can now safely say we've essentially hit the limits of what SMSQL is capable of managing. The interface is just not made to manage a large number of servers and the random problems the NetApp snap technology has with virtual machines is too much to handle. I will be finishing a blog post this afternoon outlining everything we've learned. Feel free to check it out at www.blogofshaw.blogspot.com.

Also, I'll be working directly with NetApp over the next month or so providing them suggestions and real-world examples of the problems we have with the tool and how they can improve it. I have to say NetApp has been very receptive and have been honest and aware of the tool's limitations. As of now though, we are moving a majority of our systems off of SMSQL and back to Idera's SQLSafe.

Post #1140316
Posted Tuesday, July 12, 2011 8:13 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Tuesday, April 15, 2014 3:20 PM
Points: 2,105, Visits: 3,560
scott.shaw (7/12/2011)
I've written a few articles at MSSQLTips concerning implementing SMSQL and also testing backup times with snaps and streaming backups. http://www.mssqltips.com/author.asp?authorid=55.

We implemented SMSQL on a grand scale starting about 8 months ago. We currently have about 50 SQL Servers running the software. I can now safely say we've essentially hit the limits of what SMSQL is capable of managing. The interface is just not made to manage a large number of servers and the random problems the NetApp snap technology has with virtual machines is too much to handle. I will be finishing a blog post this afternoon outlining everything we've learned. Feel free to check it out at www.blogofshaw.blogspot.com.

Also, I'll be working directly with NetApp over the next month or so providing them suggestions and real-world examples of the problems we have with the tool and how they can improve it. I have to say NetApp has been very receptive and have been honest and aware of the tool's limitations. As of now though, we are moving a majority of our systems off of SMSQL and back to Idera's SQLSafe.



Scott - looking forward to the post. We are using SnapManager for SQL and it does work but does have some weaknesses and IMO some excessive maintenance overhead. Recovery can be very quick but you are also looking at different teams to be involved for recovery efforts unless you make your DBA's SAN admins as well. Our usage is only on a few servers so, the complexities that you speak of with 50 is not something that we are hitting presently. Again, looking forward to your post. Thanks for sharing.


David

@SQLTentmaker
SQL Tentmaker
“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
Post #1140344
Posted Tuesday, July 12, 2011 2:34 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, April 02, 2014 9:56 AM
Points: 37, Visits: 158
I've posted my blog. I hope it helps. To summarize:

1. Management Console too slow when more than 20 servers are registered. Your mileage may vary
2. Random, reoccurring errrors add huge operational overhead and wastes man hours. Some of these issue are due to SnapDrive not working well in virtual environment. Even our storage folks are at their wits end.
3. Management Console configuration not tightly integrated with SQL Server. Systems which add or remove databases frequently should not use SMSQL

So, what systems are good for SMSQL?

1. Systems with 1 large database (>200GB)
2. Shops with only a few SQL Servers (<10)
3. Shops not running SQL Server on VM
4. Shops who do not care about using SMSQL on systems already built or who are willing to go through the pains of reconfiguring those systems to use SMSQL
5. Systems that do not change often; ie, add or remove user databases.

I still want to stress to everyone that engineers at NetApp have so far been willing to work with us on the product's weaknesses. Admitting your problems is the first step to recovery. My company plans to hold them to that.
Post #1140665
« Prev Topic | Next Topic »

Add to briefcase 12345»»»

Permissions Expand / Collapse