SharePoint Tech Content Database sizing and capacity planning (backup/restore implications)
Question: I've heard 50GB is a database limit. I need to support 10TB+ and I'm concerned about management or manageability issues and don't want to support a ton of databases. Can the technology support me?
Answer: This is a non issue. SharePoint can support hundreds of GB databases. It may be a best practice in IT to manage their databases less than 100GB per database, but it's more about threaded backups than what SharePoint can support. I’ve heard of databases larger than 500GB and farms supporting more than 2TB of active content.
This blog posting may help…
How large for a single SharePoint content database?
Further thoughts on the topic…
Ultimately, it comes down to the backup/restore, high availability, disaster recovery solution and applicable SLAs that will play into database sizes.
For example here’s how I think about it.
(1) If I have one SQL server and I’m backing up to tape, I have approximately 16 hours to backup my data without impacting end user performance. So I’ll want to keep my databases around 50GB so I can ensure that the TB or so on my SQL server can be backed up with multiple threads in the 16 hours.
(2) If I have 2 or more SQL servers in a cluster I can failover and give myself 24 hours without impacting user performance (access from the web front ends colliding with database backup requests (disk or network I/O)).
(3) If I have SQL log shipping, I don’t have a time limit for the backup since I’ve got another copy on another SQL server. So I’d look at granular recovery requirements. How am I going to provide document or site recovery… This would drive my database size requirements. Maybe I’m using Snapshots for this.
(4) If I have database mirroring (SQL 2005), again I wouldn’t have a time limit, but granular recovery would drive my decision. How do I recover sites and documents? If this is taken care of via snapshots. Then I may end up with really large databases into the hundreds of GBs.
By the way, this is applicable for WSS, SPS and MOSS. There are NO HARD LIMITS.
If scenario (1) rings true and you're either having a headache backing up and restoring frequently a large database that you would prefer to be in 4 or 5 or even 10 (smaller databases are easier to copy and bring online), then you should look at Keith Richie's SharePoint Utility kit or the Database Split tool that IT used.
Joel
