SharePoint内容数据库的最大大小

昨天在教MCM时与SharePoint专家交谈时遇到的另一个问题。SharePoint准则是不支持100GB以上的内容数据库。没有进入这些准则背后的原因，我很感兴趣地听到内容数据库更大的比100GB，并与他们您的经验（主要是围绕着性能，灾难恢复，以及医管局供应）。

您已将推送安装成功进行了多长时间？我听说过> 1TB内容数据库的二手故事，但是我想听听SharePoint管理员本身的声音。

感谢您提供任何信息。

我们有一个分别为111GB和102GB的数据库，可以在30分钟内在GigE网络上进行备份。我听说较大的数据库在长时间运行的存储过程中可能会遇到问题，但是没有看到它的演示。

摘自“ Scaling SharePoint 2007：存储体系结构”白皮书的引文：

“ ...通常被称为“ 100GB内容数据库大小限制”。实际上，这并不是真正的限制，而是建议。SQLServer数据库多年来一直扩展到100GB以上。实际上，推荐主要基于两个重要因素：

1. 给定组织的服务水平协议（SLA）要求可能要求SharePoint数据库的备份操作必须在有限的时间内执行。内容数据库的大小将直接影响执行备份所需的时间。

2. 存储子系统必须足够强大，才能处理它所服务的SharePoint解决方案的磁盘I / O要求。

只要给定的组织能够减轻这两个考虑，就可以允许内容数据库增长。在现实世界中，SharePoint已成功部署，实现了100GB，150GB，200GB，250GB，300GB，350GB和400GB的数据库大小。”

对于日常使用而言，数据库的大小并不是那么重要-大多数查询返回一个列表中的项目，而数据库中的其他内容也没有关系。但是，对整个数据库起作用的操作将变得更加困难。备份是最明显的例子-大型数据库将花费更长的时间。但是，只要数据库不超过可以在一夜之间备份的数据量，您就可以了-备份被设计为可以长期运行，并且只要您没有磁盘空间用完，备份就相当可靠。

遇到真正问题的地方是不那么频繁的事情，例如移动或升级内容数据库-这些可能需要大约5倍于可用空间的数据库大小，并且是通过使用查询来实现的，这些查询可以执行触发自动增长的操作。

我们有一个大小为300 GB的内容数据库。切换到Lite Speed后，备份没有问题。切换之前，我们会发现网站的性能严重下降。

根据记录，我们不希望有这么大的内容数据库。如果围绕内容共享，我们有特定的业务要求，如果我们将内容放在单独的网站集中，将很难实现。

首次上线时，在高峰使用期间，数据库存在主要的锁定问题。我们追溯到在SharePoint中使用CrossListQueryCache对象。我们从使用该API进行了更改，并修复了许多性能。

我在这里写了一篇博客文章，其中包含更多信息。

我们仍然会看到某些更新类型（删除blob> 20 MB），重命名网站（这可能导致对AllUserData表中许多记录的更新）存在锁定问题。我们正在与MS Support合作以解决特定情况（例如，从回收站中删除大型项目） ）。这些都可以追溯到SharePoint中特定存储过程删除数据的方式，但是我们还没有解决方案。

就我个人而言，我认为在AllUserData表中获得许多记录后会出现问题，而MS与人们进行交流的简便方法是保持在100 GB以下。

我建议对MS IT部门的人员进行ping操作...据我所知，他们的SharePoint Content DB> 800 GB。

我们公司的数据库目前为140Mb。我们在一个允许增加到1.5Gb的特定列表中遇到了性能下降，其中包含包含附件的多个版本的附件。（顺便说一句，我去过那里只有大约2个月）。我们现在正在计划进行迁移，并且根据我们的测试，希望使用Metalogix工具迁移到SP 2010可能需要几天的时间。我们的数据库设计不良，门户设计不良，现在我们这些人不得不面对实际问题进行管理。

我们有一个备份站点，它是我们生产环境的精确副本。但是硬件是我们上次硬件更新后的旧硬件-用于开发的旧硬件，用于生产的新硬件。但是，由于性能问题，我们的开发环境的某些区域无法使用，这迫使必须在生产中进行大量开发。哎呀哎呀...

错了 大小没有限制。他们建议不要使用大型数据库，而只是为了简化数据库管理并最大程度地减少备份/还原时间。我们可以说大小限制仅取决于您的SQL基础结构。