昨天在教授 MCM 时与 SharePoint 专家交谈时提出了另一个问题。SharePoint 指南规定不支持超过 100GB 的内容数据库。如果不了解这些指南背后的原因，我很想听听有关内容数据库的信息更大超过 100GB 以及您对它们的体验（主要围绕性能、灾难恢复和 HA 配置）。
您已成功将 SharePoint 安装推向了多远？我听说过 > 1TB 内容数据库的二手故事，但我想听听 SharePoint 管理员本人的说法。
感谢您提供的任何信息。
答案1
我们分别拥有 111 和 102GB 的数据库，它们在千兆以太网网络上的备份时间不到 30 分钟。我听说较大的数据库在长时间运行的存储过程方面可能会出现问题，但没有看到过这样的演示。
来自“扩展 SharePoint 2007：存储架构”白皮书的精彩引述：
“...这通常被称为“100GB 内容数据库大小限制”。事实上，这不是真正的限制，而是一种建议。多年来，SQL Server 数据库的规模已经远远超过 100GB。实际上，该建议主要基于两个重要因素：
特定组织的服务级别协议 (SLA) 要求可能规定 SharePoint 数据库的备份操作必须在有限的时间内执行。内容数据库的大小将直接影响执行该备份所需的时间。
存储子系统必须足够强大，才能处理其所服务的 SharePoint 解决方案的磁盘 I/O 要求。
只要某个组织能够缓解这两个问题，那么就可以允许内容数据库增长。现实世界的实施已经看到成功的 SharePoint 部署，这些部署已实现 100GB、150GB、200GB、250GB、300GB、350GB 和 400GB 的数据库大小。”
答案2
对于日常使用来说，数据库大小并不那么重要 - 大多数查询返回一个列表中的项目，数据库中还有什么并不重要。但是，对整个数据库进行的操作将变得更加困难。备份是最明显的例子 - 对于大型数据库，备份将花费更长时间。但是，只要数据库不超过一夜之间可以备份的内容，您就没问题 - 备份旨在长期运行，只要您不耗尽磁盘空间，备份就非常可靠。
您真正会遇到的问题是在诸如移动或升级内容数据库等不太频繁的事情上 - 这些可能需要大约 5 倍的数据库大小的可用空间，并且使用可以执行诸如触发失控自动增长之类的操作的查询来实现。
答案3
我们有一个 300 GB 大小的内容数据库。切换到 Lite Speed 后，备份没有问题。在切换之前，我们会看到网站性能严重下降。
需要说明的是，我们并不想拥有如此庞大的内容数据库。我们对内容共享有特定的业务需求，如果我们将内容放在单独的网站集中，那么实现起来将非常困难。
刚上线时，我们在高峰使用期间遇到了数据库的重大锁定问题。我们将其追溯到 SharePoint 中 CrossListQueryCache 对象的使用。我们改用该 API，这修复了我们的许多性能问题。
我写了一篇博客文章，其中包含更多信息这里。
我们仍然看到某些类型的更新（删除大于 20 MB 的 blob）、重命名 Web（这可能会导致更新 AllUserData 表中的大量记录）存在锁定问题。我们正在与 MS 支持部门合作解决特定案例（例如从回收站中删除大型项目）。这些问题可以追溯到 SharePoint 中特定存储过程删除数据的方式，但我们还没有解决方案。
我个人认为，在 AllUserData 表中获取如此多的记录后就会出现问题，而 MS 向人们传达此问题的最简单方法就是说保持在 100 GB 以下。
我建议联系 MS IT 的人员...我听说他们有一个 > 800 GB 的 SharePoint 内容数据库。
答案4
那是错误的。大小没有限制。他们建议不要拥有大型数据库，而只是为了使数据库管理更容易并最大限度地减少备份/恢复时间。我们可以说，大小限制仅取决于您的 SQL 基础结构。