SharePoint 2013 too many content databases

Question

I joined a company where there are 10 content databases created for 10 site collections(SP2013 version). All the databases together has less than 80GB content.

Well I don't know why they created these many content databases. I know that the best practice is to split the content DB if it has over 100GB of content. Here one of the content DB has less than 200 MB content. My question is there any overhead of having too many content databases like this. Should I suggest to merge some content databases?

Answer 1

It's unlikely to have much overhead from a resource perspective, but it will have administrative overhead. I'd personally likely merge them.

You can also exceed 100GB by a significant amount (up to 4TB for regular use, beyond that for Records Center).

Answer 2

I would also trying to merge it but before merging i would make sure couple of things as you inherited the environment.

• what was the reason to create a site collection into dedicated content database.
• Is there any special requirement for it...i know if they are using 3rd party solutions like Nintex, sometime they need a site collection into own content database.
• sometime due to copying of existing site collection required separate db.

these are couple of examples but you have to make sure that merging the DB will not impact the environment.

Answer 3

I think the days of separating out your databases is coming to a close. Usually in 2010 we would say yes, due to limitations, but Microsoft has greatly exceeded the limits, and it makes more sense with the speed of SQL and hardware nowadays to keep them all together.

If you are looking to migrate to 2016, having one content DB is so much easier than having ten. Each content DB you will have to test, backup, migrate, attach to the instance, mount to sharepoint, and test the contents.

Answer 4

I also worked at a company with a separate database for each site collection. The main reason for this was Nintex workflows, but there may be other reasons like custom code. Typically, qall lead back to disaster recovery. Each company, group, or team should have a disaster recovery plan that takes into consideration workflows. 3rd party products, and custom code, among other things.

The advantage of having 1 database per site collection is the a ility to restore the database/site collection without affecting the others. Alternatively, you could make site collection backups (Backup-SPSite) regularly so you would be able to restore just one site collection if necessary. Aaa