One of the nice new features that SharePoint 2010 brings to the table is the ability to integrate with SQL Server’s snapshot generation and management functionality.
Using SQL Server snapshots makes it possible for administrators to conduct some previously disruptive operations with minimal user impact.
For example, site collection backups normally require that a site collection be write-locked in order to maintain consistency during the backup process.
The same backup can be taken against a SQL Server snapshot without incurring the adverse effects of a write lock, permitting users to continue working with the site collection being backed-up without being forced into read-only mode.
There’s a catch, though: SQL Server snapshot capabilities only exist in the Developer and Enterprise editions of SQL Server. If you would like to use SQL Server snapshots with SharePoint 2010, be sure to plan on the use (and licensing) of SQL Server Enterprise in your farm.
For several versions now, SQL Server has included the ability to replicate content between databases. In the quest to make SharePoint highly available, you might be tempted to investigate SQL replication of SharePoint databases using this mechanism.
Unfortunately, SQL Server replication is not supported with SharePoint. If you are seeking to make your SharePoint environment highly available, look instead to other technologies such as Windows clustering and SQL Server database mirroring.
SQL Server transaction log shipping may also fit the bill for you if your requirements are more tolerant to data loss and down time.
Alternatively, there are third party products which can perform replication in SharePoint-friendly fashion.
When you're putting together a plan for Web applications and content databses in your environment, consider your expected usage patterns and how you expect your content databases to grow.
As a general rule of thumb, Microsoft recommends against growing content databases to larger than 200GB unless the content in the database meets specific non-collaborative usage criteria, such as that which is associated with single-site repositories and archives.
Databases that grow larger than the 200GB limit may cause performance degradation due to locking; they also represent a challenge from a backup and restore perspective.
