另外一个问题是，昨天在教MCM的时候与SharePoint专家交谈。 SharePoint指南指出，不支持100GB以上的内容数据库。 没有深入了解这些准则背后的原因，我有兴趣了解大于100GB的内容数据库以及您的经验（主要围绕性能，灾难恢复和HAconfiguration）。
您设法推送您的SharePoint安装有多远？ 我听说过1TB内容数据库的二手报道，但我想听听SharePointpipe理员自己的消息。
感谢您的任何信息。
我们有一个分别为111和102GB的数据库，在一个GigEnetworking上可以在30分钟内得到备份。 我听说较大的数据库可能会遇到长时间运行的存储过程的问题，但没有看到它的演示。
“扩展SharePoint 2007：存储架构”白皮书的一个很好的引用：
“…这通常被称为”100GB内容数据库大小限制“，事实上这不是一个真正的限制，而是一个推荐，SQL Server数据库多年来已经扩展到100GB以上，实际上，build议主要基于两个重要因素：
特定组织的服务级别协议（SLA）要求可能要求SharePoint数据库的备份操作必须在有限的时间内可执行。 内容数据库的大小将直接影响执行备份所需的时间。
存储子系统必须足够强大，才能处理所提供的SharePoint解决scheme的磁盘I / O需求。
只要给定的组织能够缓解这两个考虑因素，则可以允许内容数据库增长。 真实世界的实施已经看到成功的SharePoint部署已经实现了100GB，150GB，200GB，250GB，300GB，350GB和400GB的数据库大小。
对于日常使用，数据库大小并不重要 – 大多数查询将项目返回到一个列表中，而数据库中还有什么是没有关系的。 但是，在整个数据库上运行的操作将变得更加困难。 备份是最明显的例子 – 大型数据库需要更长的时间。 但是，只要数据库没有超过可以在一夜之间备份的数据就可以了 – 只要不耗尽磁盘空间，备份就可以长期运行并且非常可靠。
如果遇到真正的问题，那么移动或升级内容数据库的频率就会降低 – 这可能需要大约5倍于自由空间的数据库大小，并且可以使用查询来实现，例如触发失控自动增长。
我们有一个300 GB的内容数据库。 切换到Lite Speed后，备份没有问题。 在切换之前，我们会看到网站严重的性能下降。
对于logging，我们不希望有一个内容数据库这么大。 我们对内容共享有特定的业务要求，如果我们把内容放在单独的网站集中，那么这个要求就很难实现。
当我们第一次上线时，我们在高峰期使用数据库时遇到了重大的locking问题。 我们追溯到使用SharePoint中的CrossListQueryCache对象。 我们改变了使用该API，并修复了很多我们的performance。
我在这里写了一篇关于更多信息的小博客文章。
我们仍然看到某些types的更新（删除斑点> 20 MB）的locking问题，重命名网页（这可能会导致更新AllUserData表中的大量logging。我们正在MS支持特定情况下（即从回收站）这些已经追溯到SharePoint中特定的存储过程删除数据的方式，但我们还没有解决scheme。
我个人认为，在AllUserData表中有这么多的logging之后就会出现问题，MS向人们传达这个信息的简单方式就是保持在100 GB以下。
我build议ping MS IT人员…我听说他们有一个SharePoint Content DB> 800 GB的logging。
我们公司目前有一个140Mb的数据库。 在一个特定的列表中，我们正在经历缓慢的performance，已经允许增长到1.5Gb，其中包含附件（包括多个版本的附件）。 （顺便说一下，我只在那里呆了2个月）。 我们现在正在计划一个迁移，并且正在迁移到SP 2010，使用Metalogix工具可能需要几天的时间才能完成我们的testing。 我们是一个devise不好的数据库，devise不好的门户，现在我们这些人不得不用真正的问题来pipe理它。
我们有一个我们使用的备份站点，它是我们生产环境的一个精确副本。 但硬件是我们上一次硬件更新后的旧硬件 – 用于开发的旧硬件，用于生产的新硬件。 然而，由于性能问题，我们的开发环境的一些领域无法使用，迫使大列表中的一些开发必须在生产中完成。 哎哟，哎哟，哎哟….
这是错误的 关于尺寸没有限制。 他们build议不要有大的数据库，而只是为了使数据库pipe理更容易，并最大限度地减less备份/恢复时间。 我们可以说它的大小限制只取决于你的SQL基础结构。