Data Backup and Recovery

SQL Server Best Practices Architecture UCS and FAS3270


Hey there

We are moving from EMC SAN and physical servers to NetApp fas3270 and virtual environment on Cisco UCS B200 M3.

Traditionally - Best Practices for SQL Server Datbases are to separate the following files on spearate LUN's and/or Volumes

  • Database Data files
  • Transaction Log files
  • TempDB Data files

Also I have seen additional separations for...

  • System Data files (Master, Model, MSDB, Distribution, Resource DB etc...)
  • Indexes

Depending on the size of the database and I/O requirements you can add multiple files for databases.  The goal is provide optimal performance.  The method of choice is to separate Reads & Writes, (Random and Sequential activities)

If you have 30 Disks, is it better to separate them?  Or is better to leave the files in one continous pool? 

  • 12 Drives RAID 10 (Data files)
  • 10 Drives RAID 10 (Log files)
  • 8 Drives RAID 10 (TempDB)

Please don't get too caught up on the numbers used in the example, but place focus on whether or not (using FAS3270) it is better practice to spearate or consolidate drives/volumes for SQL Server Databases




Hi Michael,

It's a completely different world with NetApp! As a rule of thumb, you don't need separate spindles for different workloads (like SQL databases & logs) - you just put them into separate flexible volumes, which can share the same aggregate (i.e. a grouping of physical disks).

For more detailed info about SQL on NetApp have a look at this doc:





TR-4003 references 2005 and 2008.  Is there a document that references SQL Server 2012?



I think the 'proper' TR doc is in the works & should be published any time soon.

You can find some brief info re SQL 2012 in the SnapManager for SQL 6.0 admin guide:

There is also a couple of TR docs about specific areas: TR-4108 about SQL over CIFS & TR-4105 about automated provisioning.




We are going through a similar process currently and I am not getting alot of guidelines or clarification from our implementation vendor.  (We are going from a NON-SAN environment)  Do you have any suggestions or problem areas that you ran across during your implementation and configuration process?