通过

新增的 Exchange 核心存储功能

  • 项目

 

适用于： Exchange Server 2010 SP2

上一次修改主题： 2016-11-28

Microsoft Exchange Server 2010 包括对 Exchange 数据库体系结构的多项改进。

  • 公用文件夹报告功能已得到增强。

  • 数据库将不再与存储组关联。 存储组已被删除。

  • 存储架构和可扩展存储引擎 (ESE) 优化中的投资已降低了 70% 的 IOPS。

下面几部分将更详细地介绍这些改进。

内容

增强的公用文件夹报告功能

数据库管理

存储更改

新增 ESE 功能

增强的公用文件夹报告功能

公用文件夹报告功能已得到增强，可用于查看用户对公用文件夹中的任意项目所做的更改。 通过使用 Exchange 命令行管理程序中的 Get-PublicFolderStatistics cmdlet 可以查看这些信息。 有关详细信息，请参阅结合使用 PowerShell 和 Exchange 2010（Exchange 命令行管理程序）。

数据库管理

数据库将不再与存储组关联。 在 Exchange 2010 中，存储组功能已移动到数据库。

在 Exchange 2010 中，可以在 EMC 的“组织配置”节点中管理邮箱和公用文件夹数据库。 （在 Exchange Server 2007 中，数据库管理是在“服务器配置”节点中执行的。）

尽管公用文件夹数据库管理已从邮箱数据库的“服务器配置”节点移动到“组织配置”节点，但是公用文件夹数据库的功能在 Exchange 2010 中并未进行更改。 就像在 Exchange 2007 中，无法创建公用文件夹数据库的数据库副本，且无法将公用文件夹数据库添加到数据库可用性组 (DAG)。 但是，公用文件夹数据库可以托管在属于 DAG 的邮箱服务器上，虽然公用文件夹数据库不会受到日志传送或任何其他 DAG 功能的约束。

数据库 Cmdlet 更改

在 Exchange 2010 中删除存储组后，Exchange 2007 中使用的存储组 cmdlet 也随之删除，Exchange 2010 数据库 cmdlet 现在提供了如下表所示的功能。

Exchange 2010 中取代 Exchange 2007 存储组 cmdlet 的数据库 cmdlet

Exchange 2007 cmdlet Exchange 2010 中的功能更改描述

New-StorageGroup

此 cmdlet 已删除，配置参数已移动到 New-MailboxDatabase 和 New-PublicFolderDatabase cmdlet 中。

Remove-StorageGroup

此 cmdlet 已删除，配置参数已移动到 Remove-MailboxDatabase 和 Remove-PublicFolderDatabase cmdlet 中。

Set-StorageGroup

此 cmdlet 已删除，配置参数已移动到 Set-MailboxDatabase 和 Set-PublicFolderDatabase cmdlet 中。

Get-StorageGroup

此 cmdlet 已删除，配置参数已移动到 Get-MailboxDatabase 和 Get-PublicFolderDatabase cmdlet 中。

Move-StorageGroupPath

此 cmdlet 已删除，配置参数已移动到 Move-DatabasePath cmdlet 中。

Exchange 2010 中已扩展了 Exchange 2007 cmdlet 中的功能的数据库 cmdlet

Exchange 2010 cmdlet Exchange 2010 中的扩展功能描述

New-MailboxDatabase

New-PublicFolderDatabase

这些 cmdlet 均是对 New-StorageGroup cmdlet 中的参数和功能的扩展。 它们还使用指向新数据库的链接更新服务器对象，并使用托管服务器名称更新数据库对象。

Remove-MailboxDatabase

Remove-PublicFolderDatabase

这些 cmdlet 均是对 Remove-StorageGroup cmdlet 中的参数和功能的扩展。 此外，它们还使用指向新数据库的链接更新服务器对象，并使用托管服务器名称更新数据库对象。

Set-MailboxDatabase

Set-PublicFolderDatabase

这些 cmdlet 均是对 Set-StorageGroup cmdlet 中的参数和功能的扩展。 在更改主机服务器时，它们还使用指向新数据库的链接更新服务器对象，并使用托管服务器名称更新数据库对象。

Get-MailboxDatabase

Get-PublicFolderDatabase

这些 cmdlet 均是对 Get-StorageGroup cmdlet 中的参数和功能的扩展。 Status 参数已得到扩展，用于返回由 Get-StorageGroupCopyStatus cmdlet 返回的当前状态信息。

Move-DatabasePath

此 cmdlet 是对 Move-StorageGroupPath cmdlet 中的参数和功能的扩展。

除了上述 cmdlet 更改外，还删除了 StorageGroupCopy cmdlet。 有关详细信息，请参阅管理邮箱数据库副本。

存储更改

在 Exchange 2010 中，为了删除邮箱数据库与服务器对象之间的依赖关系，已对存储架构进行了更改。 此外，还对新架构进行了改进，以通过重构用于存储信息的表来帮助降低每秒的数据库 I/O (IOPS)。 通过重构表可允许更高的逻辑连续性和位置参考。 这些更改降低了存储对由 ESE 维护的辅助索引的依赖性。 因此，存储不再对与辅助索引相关的性能问题敏感。

此外，通过添加与检测和更正错误以及提供警报相关的多种功能（如下所示），已对存储恢复和运行状况进行了改进：

  • 针对恶意邮箱的邮箱隔离

  • 针对空间小于 1 GB 的数据库的传输中断

  • 线程超时检测和报告

有关存储恢复和运行状况的详细信息，请参阅了解 Exchange 2010 存储。

为了改进高可用性功能，已对核心存储功能进行了许多更改。 高可用性已集成到 Exchange 2010 的核心体系结构中，使各种规模和行业部门中的组织都能够经济地部署邮件连续性服务。 有关 Exchange 2010 中高可用性更改的详细信息，请参阅了解高可用性和站点恢复。

新增 ESE 功能

为了实现以下目标，已在 Exchange 2010 中对可扩展存储引擎 (ESE) 进行了改进：

  • 增大 I/O 并使之有序以降低 IOPS

  • 优化商品存储

  • 减少数据库管理

  • 联机碎片整理

  • 联机数据库扫描

增大 I/O 并使之有序

通过在 Exchange 2010 中增大 I/O 大小并降低读取/写入频率，ESE 能够提高性能。 此外，ESE 还可以通过使数据库中的数据更加有序（这样可以增加相关数据位于 B 树同一区域的可能性）来提高性能。

在 Exchange 中，数据库中的所有数据会存储在多个 B 树中，而这些 B 树则会分为多个页面。 在 Exchange 2007 和更早版本中，存储在 B 树中的数据不具有连续性。 事实上，在 Exchange 的以前版本中，是随机对数据库执行读取/写入操作的。 这意味着相关数据可能不会位于硬盘的同一区域。 对于非连续数据，需要进行多次传递，才能从硬盘中对其进行读取或将其写入硬盘。

B 树碎片整理

为了通过维护 B 树中的连续数据来减少 I/O 操作次数，已对 B 树碎片整理过程进行了改进。

使用以下三种新操作可就地执行 B 树碎片整理（而不是通过创建新的 B 树并重命名索引和表）：

  • 页面移动   页面移动包括将一个页面上的所有数据移动到一个新分配的页面。

  • 部分左合并   部分左合并与 Exchange 2007 或更早版本中的右合并相同，不同之处在于数据是从左页移动到右页。

  • 完全左合并   完全左合并与 Exchange 2007 或更早版本中的完全右合并相同。

为了优化性能，碎片整理已从右合并更改为左合并。 数据是自右至左从硬盘中读取或写入硬盘的。 如果以与读取/写入的相同方向对数据库进行碎片整理，碎片整理将与读取/写入操作发生冲突。 此外，在某种程度上，空间分配允许分配下一页，但不允许分配上一页。 因为页面移动需要分配新页面，所以，对数据库进行自左至右的碎片整理效率会更高。

碎片整理管理器是 ESE 中的一个新事件，用于监视需要进行碎片整理的 B 树以及已进行了碎片整理的 B 树。 碎片整理管理器会在应进行碎片整理的所有装入数据库中编译 B 树列表。 发现碎片化的 B 树后，它们会向碎片整理管理器注册，之后，碎片整理管理器将对其进行处理。

页面大小增加到 32 KB

数据库中的所有数据会存储在多个 B 树中，而这些 B 树则会分为多个页面。 页面大小是用于读取和写入数据库的最小大小，它还是用于数据库缓存的单元大小。 由于从磁盘读取数据的速度比在内存中执行操作的速度慢，因此，通过将页面大小增加到 32 KB，ESE 可降低 IOPS，这样可通过缓存内存中的较大页面大小来提高性能。

优化商品存储

Exchange 2010 中的 ESE 的另一个目标是减少部署 Exchange 的资金和运营成本。 通过使用 JBOD 和 SATA 类硬盘降低存储成本并优化商品存储可实现此目标。

磁盘子系统在处理少量较大的 I/O 时更有效。在 Exchange 2010 或更早版本中，页面大小是读取/写入的最小大小，也是数据库缓存的最小大小。 接合 I/O 是指将数据库页操作合并到单个 I/O 操作的过程，因此，会产生少量较大的 I/O 操作。

通过接合 I/O 增加平均数据库 I/O 大小有以下优点：

  • 提高了磁盘使用效率 磁盘在处理较大 I/O 时更有效。 磁盘的使用越有效，就有越多的邮箱可托管在该磁盘上。

  • 提高了缓存预热速率   缓存预热是一个通过预加载上次启动数据库时对数据库执行的初始查询来帮助减少执行次数的过程。 服务器重新启动、故障转移或切换后，较大的 I/O 将允许 ESE 提高预热缓存的速率。

数据库维护

Exchange 2010 中的 ESE 的目标之一是降低维护和管理数据库的成本。 数据库维护包括用于管理和保持邮箱数据库完整性的多个任务。

数据库维护分为如下几部分：

  • 存储邮箱维护

  • ESE 数据库维护

在 Exchange 2007 中，ESE 数据库维护会占用大量的磁盘空间。 在 Exchange 2010 中，为了提高性能已进行了一些改进。 在 Exchange 2010 中，大型或极重负载配置文件服务器上的存储邮箱维护任务大约仅需要 45 分钟，而 ESE 数据库维护每晚通常需要 6 到 8 个小时才能完成对大型 Exchange 2007 数据库（2 GB 配额）的维护操作。

在 Exchange 2010 中，为了支持大型邮箱以及 JBOD 存储和未使用 RAID 的存储，已进行了一些改进。

注释注意：
Exchange 2010 与 Exchange 2007 中所有以 Exchange 存储为重点的联机数据库维护功能（如恢复项目清理）是相同的。 仅更改了 ESE 功能、联机碎片整理和数据库校验和检查。

数据库碎片整理

碎片整理使 Exchange 数据库的内部页变得连续。 碎片整理可由系统在数据库联机时自动执行（联机碎片整理），也可由管理员在数据库脱机时手动执行（脱机碎片整理）。

联机碎片整理

在 Exchange 2010 中，联机碎片整理的体系结构已发生了更改。 联机碎片整理已被移出邮箱数据库维护过程。 现在，联机碎片整理在后台全天候运行。 因为联机碎片整理始终在运行，因此 Exchange 不再将事件发布到事件日志指示数据库中的空白区数量。 在后台数据库维护期间，删除数据库中标记为删除的项目会释放这些页。 空白空间的百分比随着连续的联机碎片整理过程的工作而不断变化。

根据用户使用数据库中的邮箱发送和接收的邮件量，可以估计数据库中的空白空间量。例如，如果数据库中拥有 100 个 2 GB 的邮箱（共 200 GB），其中用户平均每天发送和接收 10 MB 的邮件，则空白空间量大约为 1 GB (100 * 10 MB)。 如果后台数据库维护不能完成全面检查，则空白空间量可能会超过此估计值。

您不需要配置此功能的任何设置。 Exchange 会在使用数据库时对其进行监视，并随时进行一些小的更改以持续对其进行碎片整理，从而满足空间和连续性要求。 如果数据库分析某个范围的页面，并发现它们并未按应当的那样按顺序，则将启动异步线程对 B 树/表的该部分进行碎片整理。 联机碎片整理也会受限制，因此不会对客户端性能产生负面影响。

使用 ESE 性能计数器集 MSExchange Database ==> Defragmentation Tasks 可查看执行的任务。 有关详细信息，请参阅如何启用扩展 ESE 性能计数器。

脱机碎片整理

脱机碎片整理是一个手动过程，由系统管理员在数据库处于已卸除（脱机）状态时执行。 在此过程中，将使用 ESEUTIL 工具读取数据库文件，并使用内容以连续方式写入新数据库。 脱机碎片整理过程不从原始数据库复制空白空间；因此，新创建的数据库文件的大小将小于磁盘上的原始数据库（可能会小很多，具体取决于数据库中的空白空间数量）。 一直以来，对数据库执行脱机碎片整理的常见原因中包括以下原因：

  • 缩小磁盘上的数据库大小

  • 回收数据库中的空白空间

  • 避免低空闲磁盘空间

  • 修复损坏的数据库（ESEUTIL /p 后修复的第三步）

脱机碎片整理从来不是 Exchange 数据库常规维护的内容；现在，Microsoft 也曾推荐对数据库进行非常规的主动式脱机碎片整理。做出这项推荐的原因各种各样，其中包括如下原因：

  • 因为必须将数据库脱机，这将导致停机。

  • 在复制的邮箱数据库环境中，这将导致需要重新设定进行了脱机碎片整理的主动副本的所有被动副本，并且还需要重新设定经过脱机碎片整理的任何被动副本。 （因此，在任何时候都不要对被动数据库副本执行脱机碎片整理。）

  • 这将导致创建具有新数据库签名的新数据库，从而无法从脱机碎片整理之前所做的数据库备份中还原日志文件。

作为脱机碎片整理的替代方法，我们建议客户创建一个新数据库，然后将邮箱移到新创建的数据库。 在 Exchange 2010 环境中，邮箱是联机移动的，不会中断对最终用户的服务。 此外，将所有邮箱从现有数据库移到新数据库时，最终结果是相同的： 经过碎片整理的数据库具有连续写入页面，在数据库文件中没有明显的空白空间。 在该过程完成之后，只需删除旧数据库（现在是空数据库）。本指南仅介绍用于回收空白空间的主动式脱机碎片整理。 如果 Microsoft 客户支持服务部门指示，仍应执行碎片整理。

联机数据库扫描

联机数据库扫描（也称之为数据库校验和检查）也已进行了更改。 在 Exchange 2007 Service Pack 1 (SP1) 中，可以选择将一半的联机碎片整理时间用于此数据库扫描过程（以确保 Exchange 在特定时间段内从数据库中读取每一页以检测所有损坏）。

在 Exchange 2010 中，联机数据库扫描将对数据库进行校验和检查，并执行 Exchange 2010 存储崩溃之后的操作。 空间会由于崩溃而导致泄漏，但是联机数据库扫描可以发现并恢复丢失的空间。 Exchange 2010 中的系统是按照每七天对每个数据库进行一次完全扫描的期望设计的。 如果数据库未在此时间范围内完成扫描，则将触发警告事件。 在 Exchange 2010 中，现有两种模式可用于在主动数据库副本上运行联机数据库扫描：

  • 作为已安排的邮箱数据库维护过程中的最后一个任务来运行。 可以通过更改邮箱数据库维护日程安排来配置其运行的时间。 可将此选项用于大小在 1 兆兆字节 (TB) 以下的较小数据库，这种数据库完成全面扫描所需的时间较少。

  • 在后台以 24 × 7 全天候模式运行（默认行为）。 此选项适用于所有数据库大小，但建议用于大型数据库（大小在 1-2 TB）。 Exchange 每天扫描数据库的次数不会超过一次。 此读取 I/O 是 100% 按顺序执行的（这在磁盘上很容易实现），在大多数系统上，等同于大约 5 兆字节 (MB)/秒的校验和检查率。

有关配置数据库维护的详细信息，请参阅维护邮箱数据库。

 © 2010 Microsoft Corporation。保留所有权利。