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 Tuesday, July 12, 2011 2:51 PM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, July 21, 2014 5:04 PM
Points: 2,107, Visits: 3,581
Yes, read the blog and appreciated the information. We have run into most of those issues as well. I did find some suggestions to eliminate the need for reconfiguration with every database add / remove but haven't tested that yet. I will soon and let you know what I find.

One question, are you using this for DR or strictly backup / recovery? Are you using FlexClones at all?


David

@SQLTentmaker
SQL Tentmaker
“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
Post #1140680
Posted Wednesday, August 24, 2011 12:05 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, January 3, 2014 4:06 PM
Points: 6, Visits: 54
I'm about ready to jump into SMSQL 5.1 on VM SQL and was wondering why you caution against VM based SQL with SMSQL?

Pete


Pistol Pete
Post #1164906
Posted Wednesday, August 24, 2011 3:27 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, April 2, 2014 9:56 AM
Points: 37, Visits: 158
petedoyon (8/24/2011)
I'm about ready to jump into SMSQL 5.1 on VM SQL and was wondering why you caution against VM based SQL with SMSQL?

Pete


I caution against using SMSQL for large environments (> 25 servers). We saw extreme manageability issues which NetApp did not deny. The technology is good but the means to manage it is not. I got word that NetApp is looking to Syncsort as a 3rd party solution. I haven't used the product but from demos it looks more geared to SAN admins than DBAs.
Post #1165021
Posted Wednesday, August 24, 2011 3:31 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, April 2, 2014 9:56 AM
Points: 37, Visits: 158
David Benoit (7/12/2011)
Yes, read the blog and appreciated the information. We have run into most of those issues as well. I did find some suggestions to eliminate the need for reconfiguration with every database add / remove but haven't tested that yet. I will soon and let you know what I find.

One question, are you using this for DR or strictly backup / recovery? Are you using FlexClones at all?


I'd be interested to know how the database add/remove testing goes. There is such a disconnect between the SMSQL console and SQL Server that we could never get it to work.

We were only using it for backup and recovery. We tried some cloning but it was spotty. Oddly enough my DBA team would be unable to complete the clone but my SAN admin could. Nice technology but very frustrating.
Post #1165023
Posted Thursday, August 25, 2011 7:32 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, July 21, 2014 5:04 PM
Points: 2,107, Visits: 3,581
scott.shaw (8/24/2011)
Nice technology but very frustrating.


Agreed. Mainly in that the tools are not there yet, not even in the ability to script things and make them automated. Definitely doesn't work when you are trying to manage multiple servers as you stated.

I haven't tested the configuration I mentioned yet as it hasn't been a present pain point and we have a few other things in the fire presently but will update when I am able to get to it.



David

@SQLTentmaker
SQL Tentmaker
“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
Post #1165341
Posted Thursday, August 25, 2011 12:40 PM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Saturday, March 15, 2014 1:45 PM
Points: 405, Visits: 286
We've been using this for about a year, and I think we have more luck with the product. We're using it for backup/restores naturally, but also take advantage of the Cloning to other machines, verifying on other machines, etc. Also, I've created a script in PowerShell that mounts the last backup for an index maintenance scan before actually performing the index maintenance on the primary data.

It's quirky to be sure, and we've encountered many of the same issues, but it has advantages that we now rely on.
Post #1165670
Posted Wednesday, August 31, 2011 11:50 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, June 18, 2014 8:32 PM
Points: 15, Visits: 303
We also use SnapManager for backups and restores and clones. And Document Server volume snaps.
We now find that when the databases are frozen it may take several minutes for the snapshot to complete. We do have quite a few databases on the LUN. In fact about 90 databases. (Before any guffawing we have no choice but to use SnapManager and we inherited the applications as is.).
I am tending towards what has been written - ie 25 to 35 db per LUN. Now we also have some big indexes and I was tending towards putting the indexes onto their own LUN.
Any thoughts
Post #1168480
Posted Thursday, September 1, 2011 8:06 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, April 2, 2014 9:56 AM
Points: 37, Visits: 158
Raymond0 (8/31/2011)
We also use SnapManager for backups and restores and clones. And Document Server volume snaps.
We now find that when the databases are frozen it may take several minutes for the snapshot to complete. We do have quite a few databases on the LUN. In fact about 90 databases. (Before any guffawing we have no choice but to use SnapManager and we inherited the applications as is.).
I am tending towards what has been written - ie 25 to 35 db per LUN. Now we also have some big indexes and I was tending towards putting the indexes onto their own LUN.
Any thoughts


Raymond0,

The limitations isn't based off a solid number. The limitation is based off a rough estimate of how long SMSQL will need to quiesce the system to complete the snapshot. The length is normally based off the total size of the volume. I'm actually surprised that if the volume is frozen for that long that SQL Server doesn't lose connection to your databases. I had always assumed anything greater than about 30 seconds would cause the databases to go suspect.

My recommendation would be to allocate additional LUNs to separate volumes and move even distribute the datafiles across the volumes. Snapshots are completed at the volume level so if you can arrange to maybe spread your database files across 3 or 4 volumes then you'll limit the total amount of time the system will freeze. I would also think about putting the log files on a separate volume than your datafiles.

In summary, if you have a bunch of small databases then put them on a single volume. If you have 1 or 2 very large databases then I would definitely recommend putting those on their own separate volumes. Keep in mind that since you have multiple databases on a single volume your restores will be streaming and could actually take as long or longer than a native restore.
Post #1168686
Posted Thursday, September 22, 2011 10:07 AM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Wednesday, May 14, 2014 7:13 AM
Points: 620, Visits: 864
scott.shaw (7/12/2011)
I've posted my blog. I hope it helps.

Yep, it helped feed my growing unease for implementing SMSQL.

We're currently in the throes of carving up an aggregate for 4 db servers and I gotta say that there are no warm and fuzzies after reading through this thread. Nevertheless, I have a couple questions regarding configuration.

1. Putting the TempDb on it's own volume. It was my understanding that the software snapshots all volumes so is this recommendation strictly to keep TempDb from being intermingled with UserDb snapshots? Since system dbs don't get snapshoted, what's the drawback of putting TempDb on the same volume?

2. Two of our servers house single 4-5TB dbs. Both are made up of multiple filegroups so we're leaning toward creating separate volumes for each filegroup. Make sense?

Any other observations using SMSQL with dbs in the multi-TB range would be appreciated.


_____________________________________________________________________
- Nate

@nate_hughes
Post #1179559
Posted Thursday, September 22, 2011 12:49 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, April 2, 2014 9:56 AM
Points: 37, Visits: 158
RP_DBA (9/22/2011)
scott.shaw (7/12/2011)
I've posted my blog. I hope it helps.

Yep, it helped feed my growing unease for implementing SMSQL.

We're currently in the throes of carving up an aggregate for 4 db servers and I gotta say that there are no warm and fuzzies after reading through this thread. Nevertheless, I have a couple questions regarding configuration.

1. Putting the TempDb on it's own volume. It was my understanding that the software snapshots all volumes so is this recommendation strictly to keep TempDb from being intermingled with UserDb snapshots? Since system dbs don't get snapshoted, what's the drawback of putting TempDb on the same volume?

2. Two of our servers house single 4-5TB dbs. Both are made up of multiple filegroups so we're leaning toward creating separate volumes for each filegroup. Make sense?

Any other observations using SMSQL with dbs in the multi-TB range would be appreciated.


Yes, you can put tempdb on the same volume as your system drive. But, there are 2 downsides. 1. tempdb could grow and fill the drive; and, 2. If your server team is taking snapshots of the volume, tempdb could grow and you will be wasting space taking a snapshot of tempdb. We put it on the a separate volume so it would be excluded from any server-level snapshots.

As far as your second point - my initial thought is you will want all the filegroups associated with one database on the same volume. This way you get a single, consistent snapshot of the whole database. What you don't want are .mdf, .ndf, or .ldf files from different databases on the same volume - especially for large databases. This is because the snap may be quick but the restore will be streaming and take a very long time.

Sorry to add to your unease. I do think SMSQL could be useful for VLDBs so you may be on the right track. I would still not recommend it for managing more than 20 SQL Servers (rough estimate) large or small.

Good luck!
Scott
Post #1179680
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse