4

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?

Improve this question

4 Answers 4

Reset to default
3

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).

Improve this answer
0
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.

Improve this answer
2
  • We don't have Nintex.. The reason I got from the DBA is if something goes wrong in HR site collection, they could just restore the HR DB instead of the entire DB. Does that makes sense?
    – user57156
    Commented Dec 6, 2017 at 16:07
  • again, it is the decision at company level. you can achieve this is different way. But this one is easy for everyone but in large environment this will pain. other options are backup sharepoint sites every day, or if you have test environment then you can restore the DB in lower farm then extract the site collection and restore it in Prod...in nutshell, i think it is ok to have the same setup
    – Waqas Sarwar MVP ♦
    Commented Dec 6, 2017 at 16:28
1

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.

Improve this answer
1
  • Good point on the migration part..
    – user57156
    Commented Dec 6, 2017 at 16:05
0

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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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