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


Netapp SnapManager for SQL


Netapp SnapManager for SQL

Author
Message
David Benoit
David Benoit
Hall of Fame
Hall of Fame (3.3K reputation)Hall of Fame (3.3K reputation)Hall of Fame (3.3K reputation)Hall of Fame (3.3K reputation)Hall of Fame (3.3K reputation)Hall of Fame (3.3K reputation)Hall of Fame (3.3K reputation)Hall of Fame (3.3K reputation)

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

“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
petedoyon
petedoyon
Grasshopper
Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)

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

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

“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
pjdiller
pjdiller
SSC-Addicted
SSC-Addicted (443 reputation)SSC-Addicted (443 reputation)SSC-Addicted (443 reputation)SSC-Addicted (443 reputation)SSC-Addicted (443 reputation)SSC-Addicted (443 reputation)SSC-Addicted (443 reputation)SSC-Addicted (443 reputation)

Group: General Forum Members
Points: 443 Visits: 291
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.
Raymond0
Raymond0
Grasshopper
Grasshopper (19 reputation)Grasshopper (19 reputation)Grasshopper (19 reputation)Grasshopper (19 reputation)Grasshopper (19 reputation)Grasshopper (19 reputation)Grasshopper (19 reputation)Grasshopper (19 reputation)

Group: General Forum Members
Points: 19 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
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
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.
RP_DBA
RP_DBA
SSC Eights!
SSC Eights! (941 reputation)SSC Eights! (941 reputation)SSC Eights! (941 reputation)SSC Eights! (941 reputation)SSC Eights! (941 reputation)SSC Eights! (941 reputation)SSC Eights! (941 reputation)SSC Eights! (941 reputation)

Group: General Forum Members
Points: 941 Visits: 1070
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
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
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
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