Scale out collaboration sites (SharePoint Server 2010)

Applies to: SharePoint Server 2010, SharePoint Foundation 2010

This article describes how to scale out Microsoft SharePoint Server 2010 collaboration sites when you are using Remote BLOB Storage (RBS) and Microsoft SQL Server.

Before you implement RBS, we highly recommend that you evaluate its potential costs and benefits. For more information and recommendations about how to use RBS in a SharePoint Server 2010 installation, see Plan for RBS (SharePoint Server 2010).

In this article:

• About RBS and collaboration sites

• About scaling out collaboration sites

• Scaling out site collections by performing a shallow move

• Scaling-out site collections by performing a deep move

About RBS and collaboration sites

Collaboration sites store information that people and groups can collectively author, share, and revise. However, collaboration sites typically require more input/output (I/O) resources and consume more disk space as documents are revised. The use of RBS-enabled content databases over 200 gigabytes (GB) with collaboration sites is not supported. Because collaboration sites have larger I/O requirements and because of the support limits for RBS, you might want to scale out collaboration sites by moving them onto one or more separate content databases. For more information about RBS support limits, see the “Content database limits” section in SharePoint Server 2010 capacity management: Software boundaries and limits. For more information about how to plan collaboration sites, see Collaboration site planning (SharePoint Server 2010).

As documents are revised, data is sent over the network to and from the SharePoint content database. This results in more network bandwidth being used, especially if the documents are very large. This is especially the case if a document is being edited by many people at the same time, or many documents are being revised at the same time.

Documents in libraries are stored as unstructured data, or Binary Large Objects (BLOBs). Because BLOBs are immutable, a new BLOB is stored in the library for each revision. If you have enabled minor versioning, these BLOBs can consume disk space very quickly.

You can improve performance of highly-collaborative sites that have large documents by using RBS and by moving content onto separate content databases of 200 GB or smaller. This includes the stored BLOB data.

About scaling out collaboration sites

You can use the Windows PowerShell Move-SPSite command to move the site collections and the BLOB data from the large RBS-enabled content database (that is, more than 200 GB) to one or more smaller RBS-enabled content databases. You can do this in either of the following ways:

• Shallow move. If you have installed Microsoft SQL Server 2008 R2 with Service Pack 1 (SP1), you can use the Move-SPSite cmdlet with the RBSMappingProvider parameter. This will move only the metadata. The BLOB data will not be moved. Although this operation is much faster than the deep move procedure that is described later in this article, it has the following requirements:

  • You must have installed SQL Server 2008 R2 with SP1.

  • You must have upgraded the content database to the new SP1 schema.

  • The RBS provider for both the source and destination content databases must support the RBSMappingProvider parameter.

  • You must have created the site collection after you installed SQL Server 2008 R2 with SP1 or you moved the site collection by using the Move-SPSite cmdlet after you installed SQL Server 2008 R2 with SP1.

• Deep move. If you have not installed SQL Server 2008 R2 with SP1, you can use the Move-SPSite cmdlet. However, doing this moves both the metadata and the BLOB data. This operation can take a long time.

Scaling out site collections by performing a shallow move

You can use Windows PowerShell to move the site collections and the BLOB data from the large content database (that is, more than 200 GB) to one or more smaller databases.

To perform a shallow move of site collection metadata by using Windows PowerShell

1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

2. On the Start menu, click All Programs.

3. Click Microsoft SharePoint 2010 Products.

4. Click SharePoint 2010 Management Shell.

5. At the Windows PowerShell command prompt, type the following command:

   Move-SPSite -Identity <SiteCollectionName> -DestinationDatabase <DatabaseName> -RbsProviderMapping @{"<SourceProvider>"="<TargetProvider>",...}
   

   Where:

   • <SiteCollectionName> is the site collection that you want to move — for example, https://ServerName/Sites/SiteName.

   • <DatabaseName> is name of the content database to which you want to move the site collection — for example, ContentDB2.

   • <SourceProvider> is the value of the source RBS stores.

   • <TargetProvider> is the value of the source RBS stores.

     Note

     You can move more than one site collection by typing multiple <SourceProvider> to <TargetProvider> pairs inside the braces.

For more information, see Move-SPSite.

Scaling out site collections by performing a deep move

To perform a deep move of BLOB data and site collection metadata by using Windows PowerShell

1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

2. On the Start menu, click All Programs.

3. Click Microsoft SharePoint 2010 Products.

4. Click SharePoint 2010 Management Shell.

5. At the Windows PowerShell command prompt, type the following command:

   Move-SPSite -Identity <SiteCollectionName> -DestinationDatabase <DatabaseName>
   

   Where:

   • <SiteCollectionName> is the identity of the site collection that you want to move — for example, https://ServerName/Sites/SiteName.

   • <DatabaseName> is name of the content database to which you want to move the site collection — for example, ContentDB2.

For more information, see Move-SPSite.

See Also

Reference

Move-SPSite

Concepts

Plan for RBS (SharePoint Server 2010)
Collaboration site planning (SharePoint Server 2010)

Other Resources

SharePoint Server 2010 capacity management: Software boundaries and limits