SnapManager® 5.1 for Microsoft® SQL Server®

[PAGEYWAGEY]

Hi,

Can someone please help ...

Just looking at how I best deploy SnapMgr for our SQL environment .... Any comments?

Now
1. Six prod SQL boxes (No SnapMgr/SnapDrive configured at this stage)
2. One test box with SnapDrive & SnapMgr configured with a sample db NetApp backup. This box has no production dbs’ on it.
3. No SQL Cluster

Goal for Production DB environment
There will be a SQL Cluster and some SQL standalone boxes(Those not suitable for SQL Clustering). All of these boxes will be using SnapDrive/SnapMgr.

I need to administer SnapMgr for all SQL boxes in the most straightforward way.

Suggested Plan
SQL Cluster – Install SnapDrive/SnapMgr.
Non-SQL Cluster boxes(6 prod db servers) - Install SnapDrive/SnapMgr.
Remote Admin box – Install SnapMgr (Not sure if it needs SQL Server installed on it, so could I remove it?) Would I need to set-up all backup schedules/restore activities from this box or would they need to be configured/performed on the individual SQL box? Do I need a remote admin box at all?

Cheers,
Steve.

MCITP SQL Server 2008 DB

[DJBAKER123]

Hey Steve,

Not sure about whether your remote machine needs SQL installed but it can manage other SMSQL operations to other hosts so yes any one SMSQL install can manage other hosts.  A few other tidbits I have picked up along the way with Netapp and SQL:

1.) If you are planning any snapvault (archive) operations with SMSQL, make sure your system and user dbs are on seperate LUNs/vols and in qtrees.  Luns can be moved online into qtrees without affecting operations however any scripts created will need to modified to see path change. As well all DBs you wish to use in SV archives should have the same vol usage - ie DB1 mdf is on drive G and LDF is on Drive H:, DB2 can be on same drive letters but can't be on any other as well, otherwise neither will be able to be archived.

2.) There is a new version of SMSQL out - ver 5.2

3.) We do a lot our dev copy refresh from prod sql systems by remote SQL calls through scheduled SQL jobs.  From the dev box we run a sql task to stop db activity, dismount dbs and then remote call on the prod sql server to take a backup (snapshot).  We then get the Dev server to mount that snapshot and start up the DBs.  There are many other ways to do this however this makes it easily done within SQL without having to go into SMSQL.  Just another option!

Hope this helps,

Dan 

[scampbel]

Hi Steve,

It looks like you are on the right track.

Another thing to maybe consider if you have a large number of database is the use of mount points instead of drive letters. Check out chapter 6 of the SnapManager 5.1 for Microsoft SQL Server Installation and Administration Guide for more info on this one.

Simon