Another question from talking to the SharePoint gurus while teaching MCM yesterday. The SharePoint guidelines are that content databases above 100GB are not supported. Without getting into the reasons behind those guidelines, I'm interested to hear about content databases larger than 100GB and your experiences with them (primarily around performance, disaster recovery, and HA provisioning).
How far have you managed to push your SharePoint installation? I've heard second-hand stories of > 1TB content databases, but I'd like to hear from the SharePoint admins themselves.
Thanks for any info you have.
Best Answer
We have a DB's at 111 and 102GB, respectively, that get backed up in under 30 minutes on a GigE network. I have heard that larger databases can have problems with long-running stored procedures, but have seen no demonstration of it.
A nice quote from The "Scaling SharePoint 2007: Storage Architecture" whitepaper:
"...This is commonly referred to as the “100GB content database size limitation”. In fact, this is not a true limitation but rather a recommendation. SQL Server databases have been scaling far beyond 100GB for years now. Practically speaking, the recommendation is based primarily on two significant factors:
Service Level Agreement (SLA) requirements for a given organization may dictate that backup operations for the SharePoint databases must be executable in a limited amount of time. The size of the content databases will have a direct impact on how long it takes to execute that backup.
The storage subsystem must be robust enough to handle the disk I/O requirements of the SharePoint solution that it serves.
As long as a given organization is able to mitigate these two considerations, then the content databases can be allowed to grow. Real world implementations have seen successful SharePoint deployments that have implemented database sizes of 100GB, 150GB, 200GB, 250GB, 300GB, 350GB and 400GB."