SharePoint 2010 SP1: What it does -- and does not do

A host of small improvements make SharePoint even better, and its database size limitations are significantly raised for some systems

SharePoint 2010 has been stable and feature-rich from the get-go, but nonetheless, Microsoft recently released Service Pack 1 for it. I've heard few complaints regarding its performance and a great deal of praise regarding the leaps taken beyond its predecessor. However, a common gripe relates to the content database size limitations even if you are using Remote Blob Storage (RBS).

So does SharePoint 2010 SP1 address the database size issue, and what else does it bring to the table to make SharePoint 2010 even better?

[ Read J. Peter Bruzzese's five essential tips for deploying SharePoint 2010. | Stay abreast of key Microsoft technologies in InfoWorld's Technology: Microsoft newsletter. ]

What's new in SharePoint 2010 SP1
First, here is what SharePoint 2010 SP1 adds:

Support for SQL Server "Denali" (aka SQL Server 2011): Given that SharePoint is heavily integrated with SQL, it stands to reason that new features in the forthcoming Denali version of SQL Server will only make SharePoint 2010 better.

Shallow Copy: This new feature allows you to move site collections to new content databases without having to move all the Remote Blob storage content. Thus, only the ownership information is moved, without having to copy the unstructured data in the file store. The Move-SPSite PowerShell cmdlet has been enhanced to allow this feature.

Site Recycle Bin: With this new feature, administrators can restore site collections and/or sites that have been accidentally deleted by their owners. How often does this happen? Hopefully not too often. But when it does, having recoverable copies without getting out backups is a plus. We've had the Recycle Bin feature in SharePoint for lists, libraries, and documents for while now; this is a nice additional safety net.

StorMan.aspx (Storage Space Allocation page): StorMan.aspx has been reintroduced in SharePoint 2010 SP1. It was removed from the original version of SharePoint 2010. Now that it is back, it adds the ability to display better information to users regarding their quota information. That makes it easier for users to clean up their sites by deleting content they may not need.

Cascading filters in PerformancePoint Services: Filters values can now be passed from one filter to the next.

Broader browser support: SharePoint 2010 SP1 adds support for IE9 in Internet Explorer 8 Standards Mode, as well as for Google Chrome.

As a result of the new features and enhancements, Microsoft has updated much of the SharePoint 2010 information at its TechNet site.

The content database conundrum
Content databases contain site collections. A site collection doesn't span content databases; it lives within the one database. SharePoint 2010's original size limits were 200GB for collaboration content and 1TB for document archive content -- regardless of whether your content was in the database itself or lived in an NTFS folder through Remote Blob Storage support (a blob is a binary large object). These limitations often forced administrators to create additional content databases and site collections for the sake of breaking up the location of their data.

Remote Blob Storage allows content that would normally be housed in a content database (such as documents and video) to be stored in another location, such as an NTFS folder. This is a welcome feature in SharePoint 2010 because administrators were sometimes uncomfortable with documents and such being stored in SQL.

With the release of SharePoint 2010 SP1, the general usage scenarios remain the same for content databases. However, there is now a secondary supported path that says as much as 4TB are supported per content database if your disk subsystem's performance is at least 0.25 I/O operations per gigabyte; 2 IOPs per gigabyte is recommended for optimal performance. In addition, you must have developed plans for high availability, disaster recovery, future capacity, and performance testing (according to TechNet's latest capacity management information).

At the same time, there are no explicit content database limits if the content database is for document archiving -- if you meet the requirements I've mentioned. You must also have sites based on the Document Center or Records Center site templates. The reason document archives have no explicit limits is that this content is not accessed often, so the performance issues that gave rise to the limits usually don't apply. The lack of explicit limits for document archiving assumes that less than 5 percent of the content is accessed each month and less than 1 percent is modified or written each month. You also would not want to use alerts, workflows, link fix-ups, or item-level security on any objects in this content database.

You might be thinking, "Wow, with no limitation I could really grow this out of control, especially using Remote Blob Storage to have my content sit in an NTFS folder. If only network-attached storage was supported." The good news is that NAS is now supported with Remote Blob Storage as long as it takes no more than 20ms from the time SharePoint Server 2010 requests a Blob until it receives that first byte from the NAS.

SharePoint 2010 SP1 doesn't bring game-changing features, but it doesn't need to. SharePoint 2010 itself was that game changer, and what we need now are reasonable enhancements -- exactly what Microsoft has delivered in SharePoint 2010 SP1.

This article, "SharePoint 2010 SP1: What it does -- and does not do," was originally published at Read more of J. Peter Bruzzese's Enterprise Windows blog and follow the latest developments in Windows at For the latest business technology news, follow on Twitter.