I am creating a site collection with 6 subsites holding 1 document library each. We are migrating documents from an existing platform, somewhere around 300 000. The seperate sites represent a category of documents in essence and we will be using the content organiser to push docs to the right libraries based on metadata. Currently the site collection is empty.

I am in favour of keeping all the docs in a a single site collection for reasons of querying, a single content type and metadata navigation(which is key).

The client wants the same thing but there is the looming statement from MS saying that content DB's greater than 200gb are not really supported. Now this argument that they put forward seems to be based around backup/restore time. My clients main concern is that there is no performance degradation when we start hitting the 200gb mark. I need some tangible reason to convince them that what MS says on their site isn't really true... or is it?

Does anybody have a personal account of hitting this 'threshold' or should I be looking at RBS or some other solution? I really do not want to split the docs over multiple site collections.

  • 3
    So... you're looking for a reason to ignore MSFT's warnings on OOTB backup and performance... because you don't want to go through the effort of implementing the site the recommended best practices way? technet.microsoft.com/en-us/library/… – RJ Cuthbertson Jul 22 '13 at 17:00
  • Recommended best practice with regards to storage yes, not in regards to the solution we want to implement. – Ralph W Jul 23 '13 at 9:04
  • There are factors like budgets and time which may not seem important to a dev but are very important to management... – Ralph W Jul 23 '13 at 9:45
  • I understand the ramifications and importance of budgets and time lines. The recommendations are there for a reason. They aren't fabrications so MSFT can force you into a more complex implementation scenario. Think about it. What would be the effect on MSFT's product sales in doing that? The bottom line is still the bottom line. – RJ Cuthbertson Jul 23 '13 at 13:07
  • MS Actually has a published document that shows the performance impact of large databases. It's not that they are not supported, but there are strict requirements to meet those support thresholds. – Jesus Shelby Jul 24 '13 at 2:19

The technet page RJ linked to in his comment is one that I refer customers and management to all the time. These limits are there for a reason and they mention special scenarios where these limits can be broken. For example:

Content databases of up to 4 TB are supported when the following requirements are met:

  • Disk sub-system performance of 0.25 IOPs per GB. 2 IOPs per GB is recommended for optimal performance.
  • You must have developed plans for high availability, disaster recovery, future capacity, and performance testing.

You should also carefully consider the following factors:

  • Requirements for backup and restore may not be met by the native SharePoint Server 2013 backup for content databases larger than 200 GB. It is recommended to evaluate and test SharePoint Server 2013 backup and alternative backup solutions to determine the best solution for your specific environment.
  • It is strongly recommended to have proactive skilled administrator management of the SharePoint Server 2013 and SQL Server installations.
  • The complexity of customizations and configurations on SharePoint Server 2013 may necessitate refactoring (or splitting) of data into multiple content databases. Seek advice from a skilled professional architect and perform testing to determine the optimum content database size for your implementation. Examples of complexity may include custom code deployments, use of more than 20 columns in property promotion, or features listed as not to be used in the over 4 TB section below.
  • Refactoring of site collections allows for scale out of a SharePoint Server 2013 implementation across multiple content databases. This permits SharePoint Server 2013 implementations to scale indefinitely. This refactoring will be easier and faster when content databases are less than 200 GB.
  • It is suggested that for ease of backup and restore that individual site collections within a content database be limited to 100 GB. For more information, see Site collection limits.

There is also a row for "no explicit content database limit" and explains the scenario where this would be acceptable.

All of the things you need to consider and need to plan for, as listed above, cost money. It needs to be determined if the cost of making sure you meet the requirements to ensure stability within your environment plus the benefits / key features and requirements you mention outweigh the cost of the extra overhead produced by either splitting the data into separate site collections or implementing an RBS solution?

If you do end up having a problem and you are exceeding these limits you have more or less trapped yourself in a corner that's going to take even more time to get yourself out of once you are there. Microsoft might tell you that your environment is in an unsupported state and step one might be to get it into a supported state. You might as well do it the right way the first time and either make sure you fall under the scenarios described on the technet page, or implement an RBS solution.

That being said, I think you have an even bigger problem on your hands that you haven't even considered and that is the list view threshold.

List view threshold

Maximum value: 5,000

Limit type: Threshold

Notes: Specifies the maximum number of list or library items that a database operation, such as a query, can process at the same time outside the daily time window set by the administrator during which queries are unrestricted.

I could be misunderstanding your requirements but you lose a lot of flexibility when you start exceeding the threshold since exceeding it requires views to be filtered based off of indexed columns only. Yes you can increase the threshold in central admin but I personally have seen this cause performance problems with large document libraries.

In the end, no matter how you organize it, search and features that leverage search are going to be your best bet. It will be the most straight forward to set up and it should be supported regardless of the Content DB size limit solution (hardware, RBS, or otherwise) you choose. You can leverage search scopes, search web parts, and more to help your users find the documents they need in the most straight forward way possible. On top of that, if its Microsoft Office Documents (or PDFs with the ifilter installed and configured) it can even read the contents of the document and return results based on that.

  • Thanks for the input. Much appreciated. I was hoping to keep it more simple but it does look like I'll have to go the search route with multiple site collections. – Ralph W Jul 23 '13 at 9:42

Not the answer you're looking for? Browse other questions tagged or ask your own question.