Click here to monitor SSC
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase «««23456

Netapp SnapManager for SQL Expand / Collapse
Posted Monday, July 7, 2014 4:44 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, April 22, 2016 9:33 AM
Points: 57, Visits: 250
I've been using NetApp SnapManager for SQL for almost 2 years now. Like all snapshot technologies, it is quick, handy and useful when it works, but should not become your only solution for backups and restores. We have experienced around a 10% failure rate on our largest databases. (3-5 TB) The configuration tool is woefully inadequate and counterintuitive, and must be run anytime there's a change in drive structure or database structure (adding more .ndf files, etc) Not sure why NetApp hasn't simply built in an automated system to query the master and msdb databases for this info. I would say the interface itself shouldn't be used to manage more than 10 servers at once, so I have broken our servers into different divisions as well as functional groups. (Dev, Test, Prod) and manage each group from a different control server. This works well. Attempting to manage all 100+ servers from one interface would be madness.

We use clones a lot for testing and validation, they are very handy but be cautious with them. They contain actual live data, and must be secured accordingly. The PowerShell cmdlets that allow for automation of cloning do not include options for selecting several vital pieces of information, such as the connector, used to mount the drives. Instead, they default to the first connector in a list stored somewhere in NetApps. If a server ends up with clone drives attached that use a Fiber Channel connector, rather than an iSCSI connector, the server will die if it's controller dies, rather than vMotion to another controller. This negates the DR/BC functionality that makes NetApp so peachy-keen. This is because FC is host-dependant, whereas iSCSI can be "grouped" in igroups managed by multiple host machines. Hence we manually mount clones (until this is fixed by NetApp) directly from consistent snapshots taken by SnapManager. Quiescing the SQL databases and thus taking consistent snapshots is one of the most useful features of SnapManager. This process takes microseconds to finish, but seems to fail in about 10% of cases ... hence my warning above. This SHOULD NOT be your only strategy!

If it sounds as though you will need to become a storage administrator to make things work, you will at the very least need to understand many of the details of SAN/NAS management using NetApps. We maintain 5 different backup/restore strategies, with SnapManager being just one of them. Another of our strategies involves using NetApps to mirror to a another remote NetApps installation. We also do periodic classic backups, and frequent T-Log backups, which are immediately mirrored to a remote location. We also mirror differentials of all our critical DB servers to a remote location, as well as fall back, when needed, on classic tape drive backups stored offsite at yet another secure location.

As DBA's we should all know that nothing is ever easy or flawless, so it's common sense not to put all your eggs in one basket.

Post #1590152
Posted Thursday, July 24, 2014 10:33 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Tuesday, November 29, 2016 2:30 PM
Points: 738, Visits: 2,164
Still using smsql but are running into an ongoing problem where the largest database comes up in suspect mode on the disaster recovery side. No evidence of any corruption on the source/production database.

Our method is 1) break the mirror ( or it breaks itself if a real DR )
2) bring up DR netapp luns
3) fire up the DR sql failover cluster and the databases come online since they were attached when the cluster was last shut down. In other words most of the time sql is not running in DR.

3456,Server,"Could not redo log record (1741525:1017743:2), for transaction ID (0:0), on page (1:30607705), allocation unit 281474979397632, database 'COLLATERALMANAGER' (database ID 5). Page: LSN = (1741525:942479:31), allocation unit = 281474979397632, type = 1. Log: OpCode = 4, context 18, PrevPageLSN: (1741525:995618:2). Restore from a backup of the database, or repair the database."

Post #1595958
Posted Friday, July 25, 2014 9:35 AM


Group: General Forum Members
Last Login: Today @ 11:45 AM
Points: 2,752, Visits: 5,190
Indianrock - I think you might be better off starting a new topic for this issue mate
Post #1596286
Posted Tuesday, August 5, 2014 9:42 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, August 5, 2014 9:40 AM
Points: 1, Visits: 0
I have an encrypted SQL and I have to backup the SQL with encryption as it is.
Can SMSQL backup my SQL in encrypted stage?
Post #1599817
« Prev Topic | Next Topic »

Add to briefcase «««23456

Permissions Expand / Collapse