Exchange、存根和数据库空间回收
原文发布于 2012 年 8 月 28 日（星期二）
Exchange 2010 SP2 RU1 包含有关数据库空间回收问题的修补程序。人们面对这个问题似乎不知所措，所以我想解释一下这个问题和修补程序，并讨论在数据库中使用第三方产品存根项目时的预期（存根是指针对象替代邮件并将原始版本存储在外部存储库中的过程）。
错误和修补程序
在 Exchange 2010 中，我们发现数据库空间在项目已被硬删除（项目已从存储中清除）的多种情形下无法回收。这包括根据日期批量删除项目的存档情形、删除附件的存根情形，以及诸如日记邮箱和公共文件夹复制等其他情形。此问题对大量客户造成了影响，而且此问题与项目删除的工作方式有关。
Exchange 2010 通常尝试在项目被硬删除的几分钟内清除已删除项目的行。但是，如果仍然有内容正在引用该项目，那么清除会失败。例如，在以下情形中清除可能会失败：内容索引编制正在对邮件编制索引，另外一个客户端正在读取邮件等等。如果有任何内容具有开放引用，那么清除将失败。在修补程序推出之前，如果清除在此时失败，该空间实际上会被漏掉，无法在不移动邮箱的情况下恢复。
已经发现，已删除邮件的未完成引用在日记邮箱上，或者使用了第三方存档软件时特别常见，所以遇到过此错误的大多数客户都与那两个情形的其中一个有关。但是从技术上来讲，任何客户端都可能具有开放引用，从而导致项目无法被清除。
SP2 RU1 中包含的修补程序通过添加清除重试机制来解决此问题。如果清除因有内容仍然具有开放引用而失败，那么存储将定期重试，直到成功为止。
它“修补”建立存根过程吗？
建立存根指第三方存档产品接收大型邮件并将其转化为较小项目或存根的过程。它通常以删除附件和将邮件正文变小的形式实现此过程。
当建立存根过程删除附件时，则可能受此错误的影响，因为那些删除的附件可能因为开放引用而无法清除。但是除此以外，此错误实际上和建立存根过程没有什么关系。
如果建立存根过程没有给我所需的空间怎么办？
Exchange 信息存储多年来发生了很大改变，但即使回到 Exchange 2003 和 2007 时代，建立存根过程也会导致数据库明显大于您增加邮箱大小时的预期。这主要是由两种开销造成的。
第一种类型的开销是不能简单地计算为邮件大小的属性。当在 Outlook 中查看邮件的大小时，看到的大小不是 Exchange 为该邮件存储的所有数据的总大小。我们存储某些不能针对用户计算的并且不能反映在邮件大小中的属性。这些可能是公共编档的属性（例如 PR_URL_NAME）或客户端无法访问的其他内部属性。
另一种类型的开销则是页面分段。数据库页面大小这些年来已发生了改变，从 Exchange 2003 中的 4k 到 Exchange 2007 中的 8k，再到 Exchange 2010 中的 32k。数据库中的每条记录都必须排列在这些页面中，根据我们可以实现的效率，页面上会留下一些空间。这就是页面分段，这可能会产生一些数据库维护无法回收的空白空间。Exchange 版本越新，页面大小越大，也就更容易将一些小项目排列到单个页面上，从而产生更少的分段，但是总是会存在一定量的分段。
邮件之间的开销量通常不会有太大的变化。小邮件的开销量与大邮件一样多。为此，当使用小项目填充数据库时，开销变得明显得多。
例如，当使用全部为 1 MB 大小的项目填充数据库时，这些项目都具有 1k 的开销。这意味着数据库具有大概 0.09% 的开销。现在，让我们在数据库中对所有项目建立存根，把它们降低到 4k 大小。突然间，1k 的开销变得格外明显，占据了 25% 的数据库。我曾经个人创建过开销为 70% 的 Exchange 2003 数据库，当时正是使用微小的项目填充并对所有内容建立存根。
Exchange 2010 情况如何呢？
在 Exchange 2010 中，还有另外一个因素可能影响存根的空间回收，那是数据库设计上的改变。
Exchange 2010 在降低数据库 IOPS 方面做出了巨大的改进。而这其中最重要的是去除了原来的在线碎片整理进程，该进程每天晚上主动整理数据库，通过重新排列内容来优化空间。在 Exchange 2010 中，我们更加注重在连续页面上存储邮箱内容以减少 IO，即使这意味着不时可能会出现一些未使用的空间。换句话说，Exchange 2010 并不是简单地打算在邮件突然减少时主动回收空间。它是一个我们最小化体系结构以改善 IO 的应用场景。有关维护更改的详细信息，请参阅 Exchange 2010 中的数据库维护。
这是否意味着无法通过建立存根节省空间？不一定。建立产品存根通常会删除附件，所以我们认为该空间能得到释放。尽管未针对其进行设计，但是我们已经看到 Exchange 2010 在对无附件的项目建立存根时也释放了一些空间。
但是，由于这不是 Exchange 2010 设计的一部分，因此我们无法告知您使用存根存档到底能释放多少空间。对此的任何期望都应该源自于您自己的测试或您存档软件供应商提供的数据。
换句话说，我们无法针对修改项目以压缩其属性时回收的空间进行任何承诺。如果修改了项目，让其变小，却没有释放空间，那么可以视为 Exchange 2010 设计使然。与往常一样，使用第三方产品时的数据库空间问题的支持调查的结果是，我们向您推荐特定的第三方，以便在 Exchange 按设计运行时向其寻求支持。
结束语
Exchange 2010 SP2 RU1 包括一个帮助客户执行任何类型存档、存根或其他操作的修补程序，因为它可以让硬删除项目的清除操作可靠地运行。但是，通过建立存根所获得的任何预期磁盘空间节省需要得到您和您的存档软件供应商的验证。在配置您的存储时，我们建议遵循我们发布的指南（其中包括利用大型邮箱，以便无需依赖第三方存档解决方案）和工具，以确保具有足够的空间用于 Exchange 数据。
Bill Long
这是一篇本地化的博客文章。请访问 Exchange, Stubbing, and Database Space Reclamation 以查看原文