Managing Huge Site Collections

Question

I have a situation in my company's environment where site collections are reaching a size of around 500GB. They are used as a repository for documents, so an application stores the documents in there and it's forgotten.

I read the SharePoint Boundaries and Limits documentation and it states that a Content Database and a Site Collection can have unlimited supported size, if certain requirements are met:

1. SharePoint Server 2010 sites must be based on Document Center or Records Center site templates.
2. Less than 5% of the content in the content database is accessed each month on average, and less than 1% of content is modified or written each month on average.
3. Do not use alerts, workflows, link fix-ups, or item level security on any SharePoint Server 2010 objects in the content database.

2 and 3 are ok, but not 1. Since those sites were created a long time ago and nobody thought of that, they were created using regular templates.

So a couple of questions:

Can I change the template? I would think that I can't but it doesn't hurt asking. Google didn't answer me.

What could be the consequences of ignoring recommendation #1, other than losing MS Support?

Is it a good idea to use BLOB?

Answer 1

The current guidance at https://technet.microsoft.com states that content databases of up to 4TB are supported for all usage scenarios and therefore you should be okay (for the moment at least).

No, you cannot change the template in use. If you wanted to do so, you'd have to export all of the content, delete and recreate the site collection, and then re-import all of the data.

The use of Remote Blob Storage (RBS) may be useful to you in this scenario, but only for performance/backup reason, however be aware that Microsoft considers the sum of the database AND the remote blobs to be the database size for support purposes, not just the content database itself (which contains the stubs pointing to the BLOBS), therefore this isn't going to solve your database size from a support point of view issue.

In reality, the best approach will be to split the site collections up into multiple site collections to end up with multiple smaller databases. Obviously this takes some planning and time to achieve and the procedure should be tested before it is used in production.