SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Netapp SnapManager for SQL


Netapp SnapManager for SQL

Author
Message
Craig Purnell
Craig Purnell
Old Hand
Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)

Group: General Forum Members
Points: 326 Visits: 526
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.



chudman
chudman
Old Hand
Old Hand (331 reputation)Old Hand (331 reputation)Old Hand (331 reputation)Old Hand (331 reputation)Old Hand (331 reputation)Old Hand (331 reputation)Old Hand (331 reputation)Old Hand (331 reputation)

Group: General Forum Members
Points: 331 Visits: 403
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



Craig Purnell
Craig Purnell
Old Hand
Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)

Group: General Forum Members
Points: 326 Visits: 526
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



chudman
chudman
Old Hand
Old Hand (331 reputation)Old Hand (331 reputation)Old Hand (331 reputation)Old Hand (331 reputation)Old Hand (331 reputation)Old Hand (331 reputation)Old Hand (331 reputation)Old Hand (331 reputation)

Group: General Forum Members
Points: 331 Visits: 403
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



Craig Purnell
Craig Purnell
Old Hand
Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)Old Hand (326 reputation)

Group: General Forum Members
Points: 326 Visits: 526
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.



msright1981
msright1981
Forum Newbie
Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)Forum Newbie (7 reputation)

Group: General Forum Members
Points: 7 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
Chris Taylor
Chris Taylor
SSChasing Mays
SSChasing Mays (654 reputation)SSChasing Mays (654 reputation)SSChasing Mays (654 reputation)SSChasing Mays (654 reputation)SSChasing Mays (654 reputation)SSChasing Mays (654 reputation)SSChasing Mays (654 reputation)SSChasing Mays (654 reputation)

Group: General Forum Members
Points: 654 Visits: 1910
@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?

_________________________________________________________________________________

SQLGeordie

Web:- Jarrin Consultancy
Blog:- www.chrisjarrintaylor.co.uk
Twitter:- @SQLGeordie
scott.shaw
scott.shaw
SSC Journeyman
SSC Journeyman (99 reputation)SSC Journeyman (99 reputation)SSC Journeyman (99 reputation)SSC Journeyman (99 reputation)SSC Journeyman (99 reputation)SSC Journeyman (99 reputation)SSC Journeyman (99 reputation)SSC Journeyman (99 reputation)

Group: General Forum Members
Points: 99 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.
David Benoit
David Benoit
Hall of Fame
Hall of Fame (3.4K reputation)Hall of Fame (3.4K reputation)Hall of Fame (3.4K reputation)Hall of Fame (3.4K reputation)Hall of Fame (3.4K reputation)Hall of Fame (3.4K reputation)Hall of Fame (3.4K reputation)Hall of Fame (3.4K reputation)

Group: General Forum Members
Points: 3410 Visits: 3650
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

“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
scott.shaw
scott.shaw
SSC Journeyman
SSC Journeyman (99 reputation)SSC Journeyman (99 reputation)SSC Journeyman (99 reputation)SSC Journeyman (99 reputation)SSC Journeyman (99 reputation)SSC Journeyman (99 reputation)SSC Journeyman (99 reputation)SSC Journeyman (99 reputation)

Group: General Forum Members
Points: 99 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.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search