神圣的 COW！Exchange 2010 SP2 RU3 中对可恢复项目版本控制的更改

原文发布于 2012 年 6 月 1 日（星期五）

在过去几个月中，我们收到了有关可恢复项目文件夹（许多人把它叫做垃圾站，虽然我们不再这么称呼它）过度增长的报告，有两个主要场景会导致这种过度增长。

1. 单个项目恢复和诉讼保留版本控制
2. 日历版本日志记录

单个项目恢复和诉讼保留

单个项目恢复和诉讼保留允许在邮箱内保留数据。如果您不熟悉这些功能，请参见我前面的文章 Exchange 2010 中的单个项目恢复（该链接可能指向英文页面）了解更多信息。

除了在邮箱内保留数据外，单个项目恢复和诉讼保留还启用版本控制。实质上，当一个项目改变时，就会执行写入时复制 (COW) 来保留该项目的原始版本。原始项目位于 Recoverable Items\Versions 文件夹中。该文件夹不向用户显示。

鉴于 Exchange 2010 中包括了对于客户端连接和访问邮箱相关数据方式的更改，因此，写入时复制活动发生在客户端访问服务器上的 Exchange 系统对象 (XSO) 层。

什么东西会触发写入时复制？

• 对于邮件和帖子（IPM.Note* 和 IPM.Post*），写入时复制捕获主题、正文、附件、发件人/收件人和发送/接收日期的变化。
• 对于其他类型的项目，写入时复制捕获对项目的所有更改，文件夹间的移动和读/未读状态变化除外。
• 草稿被排除在写入时复制之外，目的是防止在自动保存它们时产生过量副本。

什么东西会导致可恢复项目文件夹过度增长？

写入时复制行为可导致过度增长。我们发现，以下使用 Microsoft Outlook 的方式是导致过量副本的一个主要原因：

1. 您创建了一个日历约会。
2. 您将一个 Office 文档附加到该约会中并保存它
3. 稍后，您决定打开该约会以引用 Office 文档中的某些内容。您打开该文档。
4. 在后台，Outlook 开始自动保存这一打开的约会和其对应的打开的文档（默认情况下，Outlook 每 3 分钟自动保存一次）。
5. 每个自动保存事件都触发一个写入时复制。但是因为自动保存同时保存 Office 文档和约会，所以有两个写入时复制事件。对于每个额外的附件，还会创建一个后续的写入时复制版本。

那么，问题找到了。

因为附件是邮件的一部分，所以为项目中每个附件创建一个副本没有意义。实质上，当保存一个带有附件的项目时，Outlook 执行以下操作：

1. CreateAttachment
2. SaveAttachment
3. SaveMessage

写入时复制同时发生在 SaveAttachment 和 SaveMessage。研究代码后，我们发现在保存附件后，对 SaveAttachment 的调用最终调用了与其关联的邮件上的 Flush 方法（通过此方法客户端将状态与服务器同步）。此 Flush 调用会发信号给写入时复制代码让其实施。

经过进一步分析，我们意识到，写入时复制逻辑在任何 Flush 调用上触发。这是一个突破性发现，因为 Flush 可以在很多情况下启动，因此可能是导致一些客户在他们的环境中看到成千上万个写入时复制事件的原因。

在 Exchange 2010 SP2 RU3 和更高版本中，写入时复制现在理解 Flush 与 Save 操作之间的差异，因此将只在发生 Save 操作时才触发。

日历版本日志记录

日历版本日志记录过程就是邮箱中发生的日历更改通过写入时复制保存的过程。Exchange 2010 中引入了日历版本日志记录，目的是帮助您排除故障和修复日历可靠性问题。

设计日历版本日志记录的目的是在每次更改日历项目时创建一个日志，这些日志提供会议的历史记录。您可以使用 Get-CalendarDiagnosticLog cmdlet 回顾历史，然后确定哪些客户端执行了破坏性操作。日历修复助理也会使用日历版本日志记录，它在尝试判断给定日历项的历史以检测不一致性情况时会使用这些日志。

默认情况下，在 Exchange 2010 中的邮箱上启用日历版本日志记录。您可以通过 CalendarVersionStoreDisabled 属性对某个邮箱禁用或启用这一功能。注意，该属性的名称是 CalendarVersionStoreDisabled，所以 $false 的默认值意味着默认情况下启用日历版本日志记录。根据邮箱配置，遵循不同的过程来存储日历项副本：

1. 如果没有为邮箱启用“单个项目恢复”或“诉讼保留”，则日历项的去除版本将保留在可恢复项目文件夹的根目录中 120 天。使用写入时复制创建去除版本（正文和非第一级别或非嵌入式邮件类型附件被删除）。
2. 如果为邮箱启用了“单个项目恢复”或“诉讼保留”，则日历项的完整副本保留在 Recoverable Items\Deletions 或 Recoverable Items\Versions 文件夹中。只要对 Recoverable Items\Deletions 或 Recoverable Items\Versions 文件夹中的日历项目执行硬删除操作，就会通过写入时复制基础结构创建去除版本。这一去除版本放置在 Recoverable Items 文件夹的根目录中并保存 120 天。只有在 Recoverable Items\Deletions 或 Recoverable Items\Versions 文件夹中的项目存放时间超过 134 天 (120 + 14）时，才不创建去除版本。在更改保留期、邮箱文件夹助理还没有执行，以及禁用了诉讼保留等时，都会发生这种情况。

由于上述问题涉及写入时复制逻辑不区分 Flush 和 Save 操作，因此在某些情况下，日历版本日志记录会消耗很大比例的可恢复项目文件夹配额（不知您是否还记得，警告阈值是 20 GB，硬配额是 30 GB）。

尽管 SP2 RU3 解决了写入时复制问题，进而解决了日历版本日志记录会消耗可恢复项目文件夹的所有配额的问题，但是在 SP2 RU2 中，我们曾对体系结构做了改动，使日历版本日志记录现在会在启动写入时复制前考虑可恢复项目文件夹大小。

如果文件夹大于 RecoverableItemsWarningQuota，则对邮箱禁用日历版本日志记录。使用的 RecoverableItemsWarningQuota 值取决于邮箱的设置：

1. 如果邮箱的 UseDatabaseQuotaDefaults 设置为 $true，则将使用邮箱数据库的 RecoverableItemsWarningQuota。
2. 如果邮箱的 UseDatabaseQuotaDefaults 设置为 $false，则将使用邮箱的 RecoverableItemsWarningQuota。

当禁用日历版本日志记录时，客户端访问服务器上的应用程序事件日志中生成以下事件：

事件 ID: 5003
来源: MSExchange 中间层存储
任务类别: CopyOnWrite
级别: 信息
描述: 用户邮箱 <legacyExchangeDN> 已超出垃圾站警告配额。已对该邮箱禁用日历日志记录。

这并非我们所做的全部工作。在开发的这一早期阶段，我不打算谈论太多细节，但我们正在进一步改进日历版本日志记录，以最大限度降低此功能对您的部署的影响。当我有更多内容可以与您分享时，我会通过此博客与您分享。

Ross Smith IV
首席项目经理
Exchange 客户体验

这是一篇本地化的博客文章。请访问 Holy COW! Changes to Recoverable Items versioning in Exchange 2010 SP2 RU3 以查看原文