了解 Exchange 2010 存储

  • 项目

 

适用于： Exchange Server 2010 SP2, Exchange Server 2010 SP3

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

Exchange 存储是一个存储平台，为在一个基础结构中管理多种信息提供单一存储库。Exchange 存储 (store.exe) 是 MicrosoftExchange Server 2010 的核心数据存储库。

目录

Exchange 2010 的各版本中的数据库

Exchange 存储的逻辑组件

Exchange 存储的文件结构

了解事务日志记录

可扩展存储引擎

存储运行状况

数据库日志或数据库驱动器上磁盘空间不足

Exchange 存储限制

Exchange 2010 的各版本中的数据库

Exchange 2010 有两种服务器版本：Standard Edition 和 Enterprise Edition.Exchange 2010 Standard Edition 用于满足中小型公司的邮件传递需要和协作需要，可能还适用于特定的服务器角色或分支机构。Exchange 2010 Enterprise Edition 适用于大型企业。

Exchange 2010 Standard Edition 支持多达五个数据库。Exchange 2010 Enterprise Edition 支持多达 100 个数据库。

Exchange 存储的逻辑组件

Exchange 存储的主要组件是邮箱数据库和公用文件夹数据库。这些组件可以驻留在单个服务器上，也可以分布在多个服务器上。

邮箱数据库包含组成 Exchange 2010 中邮箱的数据、数据定义、索引、校验和、标记以及其他信息。邮箱数据库包含个人用户的私人数据，并包含为该用户创建邮箱时所生成的邮箱文件夹。邮箱数据库以 Exchange 数据库 (.edb) 文件的形式存储。

公用文件夹数据库包含组成 Exchange 组织中的任何公用文件夹的数据、数据定义、索引、校验和、标记以及其他信息。

在 Exchange 2010 中，使用 Exchange 命令行管理程序管理公用文件夹。（也可以在 Exchange 管理控制台中执行部分公用文件夹数据库管理任务）。有关管理公用文件夹的详细信息，请参阅管理公用文件夹和了解公用文件夹。

Exchange 2010 的各版本中的数据库

Exchange 存储的文件结构

可以使用 Exchange 存储的逻辑组件（例如数据库）对其进行管理。但是，Exchange 2010 将数据存储在一组专用的数据文件中，例如 Exchange 数据库 (.edb) 文件、事务日志 (.log) 文件和检查点 (.chk) 文件。除非要备份或还原数据，否则很少需要与这些文件直接交互。下表对这些文件逐一进行了详细描述。

Exchange 存储的文件结构

数据文件 描述

Exchange 数据库 (.edb)

这些文件是邮箱数据的存储库。这些文件由可扩展存储引擎 (ESE) 直接访问，并具有为实现快速访问而设计的 B 树结构。这样用户便可以在一个输入/输出 (I/O) 循环内访问任意数据页面，与 Microsoft Exchange Server 2007 相比，速度提高了四倍。Exchange 数据库由多个 B 树组成，并包含通过存放索引和视图与主树配合使用的辅助树。

事务日志 (.log)

这些文件是数据库操作（例如创建或修改邮件）的存储库。对于已提交的操作，之后会将其写至数据库本身（在 .edb 文件中）。这种方法可以保证在服务中断时，所有完整和不完整的事务都被记录下来，从而保持数据的完整性。每个数据库都有自己的一组事务日志。

检查点 (.chk)

这些文件是指示操作何时成功保存到硬盘数据库中的数据的存储库。Exchange 2010 使用 .chk 文件，因此，当从中断的服务恢复时，ESE 实例可以从下一个未写入的操作开始，将日志文件自动重播至不一致的数据库中。.chk 文件与 .log 文件放置在相同的日志位置。

Exchange 2010 的各版本中的数据库

了解事务日志记录

Exchange 事务日志记录是 ESE 的一种强大的恢复机制，专用于在 Exchange 数据库突然停止后，将该数据库可靠地还原到一致状态。还原联机备份时也使用日志记录机制。本节详细介绍 Exchange 2010 事务日志记录，并简要介绍循环日志记录。

Exchange 事务日志记录

在对 Exchange 数据库文件执行更改之前，Exchange 会将更改写入事务日志文件中。安全记录更改后，即可将更改写入数据库文件中。通常，在将更改安全记录到事务日志之后，但在将其写入数据库文件之前，最终用户便可以使用这些更改。

Exchange 采用的高级内部内存管理系统已经优化，性能较高，可以高效地对数十 GB 的数据库页面的缓存进行管理。在正常运行期间，实际将更改写入数据库文件中是一项低优先级的任务。

如果数据库突然停止，缓存的更改不会因为内存缓存被破坏而丢失。数据库重新启动后，Exchange 将扫描日志文件，重新构建并应用任何尚未写入数据库文件的更改。此过程称为重播日志文件。数据库已经结构化，因此，Exchange 可以确定任何日志文件中的任何操作是已应用于数据库、需要应用于数据库还是不适用于数据库。

Exchange 不是将所有日志信息写入单个大文件中，而是使用一系列日志文件，每个日志文件的大小正好是 1 MB（即 1,024 KB）。如果日志文件已满，Exchange 将关闭该文件并使用序号重命名该文件。第一个写满的日志以名称 Enn00000001.log 结尾。nn 代表一个两位数，称为基本名称或日志前缀。

每个数据库的日志文件用带有编号前缀（例如，E00、E01、E02 或 E03）的文件名进行区分。当前对数据库打开的日志文件名为 Enn.log。该文件在被填充并关闭之后才会有序号。

检查点文件 (Enn.chk) 跟踪 Exchange 将记录的信息写入数据库文件的进度。每个日志流都有一个检查点文件，每个数据库都有各自的日志流。

日志文件以十六进制的形式进行编号，所以，E0000000009.log 之后的日志文件是 E000000000A.log，而不是 E0000000010.log。可以使用 Windows 计算器 (Calc.exe) 应用程序的“科学型”模式将日志文件序号转换为十进制值。为此，运行 Calc.exe，然后在“查看”菜单中单击“科学型”。

若要查看特定日志文件的十进制序号，可以使用 Exchange Server 数据库实用程序 (Eseutil.exe) 工具检查其文件头。每个日志文件的第一个 4-KB 页包含文件头信息，说明并标识日志文件及其所属的数据库。Eseutil /ml [log file name] 命令可以显示文件头信息。

如果使用错误的开关显示文件头（例如，对数据库文件头使用 /ml 而不是 /mh)，则会显示错误，或者所显示的文件头信息可能是乱码或不正确。

无法在装入数据库时查看其文件头。也无法在装入任何数据库时查看当前日志文件 (Enn.log) 的文件头。只要有一个数据库正在使用当前日志文件，Exchange 就会将该日志文件保持为打开状态。但是，可以在装入数据库时查看检查点文件的文件头。Exchange 每隔三十秒更新一次检查点文件，除非正在进行更新，否则随时都可以查看其文件头。

作为 Exchange 管理员，了解 Exchange 文件头非常重要。如果了解文件头，就可以确定哪些数据库和日志文件属于一个整体以及进行成功恢复需要哪些文件。

在以下日志文件文件头示例中，请注意前四行。

Base name: e00
Log file: e00.log
lGeneration: 11 (0xB)
Checkpoint: (0xB,7DC,6F)

日志文件文件头的这几行表明此日志文件是当前日志文件，因为该日志文件名没有序号。lGeneration 行表明在日志已被填充并关闭时，其序号将是 B，对应于十进制值 11。基本名称是 e00，因此，最终的日志文件名将是 E000000000B.log。

前面的文件头示例中的 Checkpoint 值实际上不是从日志文件文件头中读取的，但是看上去好像是从日志文件文件头中读取的它。Eseutil.exe 直接从 Enn.chk 读取 Checkpoint 值，这样就不必输入单独的命令即可了解检查点文件的位置。如果检查点文件已被破坏，Checkpoint 值将显示为 NOT AVAILABLE。在此例中，检查点位于当前日志文件 (0xB) 中，数字 7DC 和 6F 指示检查点在日志文件中的位置。注意，您将很少真正需要此信息。

如果检查点文件被破坏，Exchange 仍可以正确地恢复并重播日志文件。但是为此，Exchange 将开始扫描日志文件，从最早的可用文件开始，而不是从检查点日志开始。Exchange 跳过已应用于数据库的数据，并按顺序处理日志，直到遇到必须应用的数据。

通常，Exchange 扫描已应用于数据库的日志文件只需要一两秒的时间。如果日志文件中包含必须被写入数据库的操作，应用操作可能需要 10 秒到几分钟不等。平均来算，可以在 30 秒或更短的时间内将日志文件的内容写入数据库。

Exchange 数据库正常关闭时，所有未处理的数据都将被写入数据库文件。正常关闭后，将认为数据库文件集是一致的，Exchange 将其与日志流分离。这表明数据库文件现在是自包含文件（最新）。不需要事务日志即可启动数据库文件。

通过运行 Eseutil /mh 命令并检查文件头，可以判断数据库是否已正常关闭。

对于所有已断开连接并且处于正常关闭状态的数据库，可以安全地删除所有日志文件，不会影响数据库。如果要删除所有日志文件，Exchange 将生成一系列新的日志（从 Enn00000001.log 开始）。您可以将数据库文件移动到包含现有日志文件的其他服务器中，数据库会自行附加到其他日志流。

注释注意：
尽管在关闭所有数据库之后可以删除日志文件，但这样做将影响您还原早期备份并前滚的能力。当前数据库不再需要现有的日志文件，但是如果必须还原早期数据库，则可能需要这些日志文件。

如果数据库处于异常关闭状态，必须提供检查点之后的所有现有事务日志，才能再次装入数据库。如果这些日志不可用，则必须运行 Eseutil /p 命令来修复数据库，以使数据库处于一致状态并可以启动。

小心警告：
如果必须修复数据库，某些数据将丢失。尽管数据丢失量通常非常少，但是可能是灾难性的。对数据库运行 Eseutil /p 之后，应运行 Eseutil/ d 对数据库进行碎片整理。此操作将丢弃并重建所有数据库索引和空间树。

除了允许 Exchange 可靠地从意外的数据库停止中恢复之外，还需要通过事务日志记录创建和还原联机备份。有关创建和还原联机备份的详细信息，请参阅了解备份、还原和灾难恢复。

Exchange 2010 的各版本中的数据库

循环日志记录

可以将 Exchange 配置为通过启用循环日志记录来节省磁盘空间。循环日志记录允许 Exchange 在事务日志文件包含的数据提交到数据库之后覆盖这些事务日志文件。但是，如果启用循环日志记录，则可以将数据只恢复到上一完整备份。例如，当使用 Exchange 本机数据保护时，可以启用循环日志记录，这种情况下不进行备份。为防止日志累积，需要启用循环日志记录。

在 Exchange 2010 所使用的标准事务日志记录中，每个数据库事务都会被写入日志文件中，然后写入数据库中。如果日志文件的大小达到 1 MB，则将重命名该文件并新建日志文件。随着时间的推移，将产生一组日志文件。如果 Exchange 意外地停止，可以通过将这些日志文件中的数据重播到数据库中来恢复事务。将第一个日志文件包含的数据写入数据库之后，循环日志记录将覆盖并重复使用该日志文件。

在 Exchange 2010 中，默认情况下禁用循环日志记录。通过启用循环日志记录，可以降低对驱动器存储空间的要求。但是，如果没有一组完整的事务日志文件，则无法恢复晚于上一次完整备份的任何数据。在正常的生产环境中，建议不启用循环日志记录。

有关如何启用和禁用循环日志记录的信息，请参阅配置邮箱数据库属性。

Exchange 2010 的各版本中的数据库

可扩展存储引擎

集线器传输服务器和边缘传输服务器上的 Exchange 邮箱数据库和队列使用 ESE 数据库。ESE 是多用户索引顺序访问方法 (ISAM) 表管理器，具有完整的数据操作语言 (DML) 和数据定义语言 (DDL) 功能。通过 ESE，应用程序可以存储记录并创建索引，以便通过不同的方式访问这些记录。有关 ESE 的详细信息，请参阅可扩展存储引擎体系结构。有关 Exchange 2010 ESE 中的改进功能，请参阅新增的 Exchange 核心存储功能。

Exchange 2010 的各版本中的数据库

存储运行状况

Exchange 存储可以检测并更正会导致存储运行不正常的多种情况。Exchange 存储可以处理带毒邮箱和线程超时，使用报告和警报功能提醒不正常的 Exchange 存储状态，以及检测和修复邮箱数据库和公用文件夹数据库问题。

带毒邮箱检测和更正

在某些情况下，一个含有受损数据（逻辑数据或物理数据）的邮箱会导致 Exchange 存储出现故障，并拒绝对服务器所托管的所有邮箱提供服务。同样，带毒邮箱也会导致 Exchange 存储反复出现故障。本节介绍 Exchange 存储为检测及隔绝带毒邮箱所要采取的措施。

隔离带毒邮箱

在以下几类事件中，Exchange 存储会将邮箱标记为潜在威胁：

  • 如果为该邮箱工作的线程失败

  • 如果邮箱中有五个以上的线程长时间停止执行

标记为潜在威胁的邮箱及其被这样标记的次数。此类信息存储在注册表中。Exchange 存储还保存有关邮箱何时被标识为潜在威胁的时间戳信息。

在数据库安装期间，Exchange 存储读取邮箱被标识为潜在威胁的时间。如果已过去两个小时以上，则会删除邮箱的注册表项。在注册表中保留此信息的好处是，在高可用性环境中，群集数据库会复制该信息。甚至在 Exchange 存储的故障转移期间，其他计算机也拥有此信息。用于隔离带毒邮箱的注册表子项是 HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-{db guid}\QuarantinedMailboxes\{mailbox guid}。此路径的项是 CrashCount 和 LastCrashTime。

有关多少次故障会导致对邮箱进行隔离以及应将邮箱隔离多久的设置存储在 MailboxQuarantineCrashThreshold 和 MailboxQuarantineDurationInSeconds 项中，这两项位于 HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-{db guid} 子项中。

这些项的默认值分别是：MailboxQuarantineCrashThreshold 为三个故障，MailboxQuarantineDurationInSeconds 为 21,600 秒（六小时）。

处理带毒邮箱

默认情况下，如果发现邮箱在两小时内导致三次故障或死锁，Exchange 存储便会将其标记为在注册表中隔离。除非传递 OPEN_AS_ADMIN 标记，否则不允许访问邮箱。不允许任何 Exchange 进程（例如内容索引或邮箱助理）登录。QuarantineState 和 QuarantineTime 注册表项跟踪邮箱是否被隔离。如果邮箱在过去两小时内未导致任何故障并且未被隔离，则 Exchange 存储会清理邮箱的注册表路径。如果邮箱自从 LastCrashTime 值指定的时间以来被隔离的时间已超出 MailboxQuarantineDurationInSeconds 的值，则会自动解除隔离。

重置隔离邮箱

确定邮箱带毒的原因并更正后，应通过删除被隔离邮箱的注册表项来手动重置注册表项。但如果忘记执行此手动步骤，Exchange 存储会在设置隔离标记六个小时后，自动重置被隔离邮箱。如果在该时间段内未能调试及修复问题，则会导致在再次隔离邮箱或邮件之前出现一系列其他故障。

注释注意：
需要装入承载邮箱的数据库，或者需要重新启动 Exchange 存储，被隔离邮箱的重置才会生效。

重置被隔离邮箱的时间段可以由注册表项 HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-{db guid}\QuarantinedMailboxes\MailboxQuarantineDurationInSeconds 来控制。

报告和警报

您可以使用 Get-MailboxStatistics cmdlet 来报告邮箱的隔离状态。Exchange 存储具有一个用于统计被隔离邮箱数目的“性能监视器”计数器。该计数器名为 MSExchangeIS Mailbox\Quarantined Mailbox Count。

Exchange 存储还在每次隔离邮箱时写入一个事件，其中包含有关具体邮箱和具体时间的详细信息。事件 10018 标识被隔离的邮箱。

Exchange 2010 的各版本中的数据库

数据库修复

在 Exchange 2010 Service Pack 1 (SP1) 中，可以使用 New-MailboxRepairRequest cmdlet 来检测并修复受损邮箱。您可以对特定邮箱或对邮箱数据库运行此 cmdlet。当运行此任务时，将中断对正在修复的邮箱的访问。如果再次对邮箱数据库运行此 cmdlet，则只中断对正在修复的邮箱的访问。数据库中的所有其他邮箱将继续正常运行。有关详细信息，请参阅创建邮箱修复请求。

New-MailboxRepairRequest cmdlet 检测和修复下列类型的邮箱损坏：

  • 搜索文件夹损坏（使用 CorruptionType 参数的 SearchFolder 值）

  • 没有反映正确值的文件夹的汇总计数（使用 CorruptionType 参数的 AggregateCounts 值）

  • 没有返回正确内容的文件夹视图（使用 CorruptionType 参数的 FolderView 值）

  • 已置备文件夹错误地指向未置备的父文件夹（使用 CorruptionType 参数的 ProvisionedFolder 值）

运行 New-MailboxRepairRequest cmdlet 后，可以使用事件查看器查看请求的详细信息。有关详细信息，请参阅在事件查看器中查看邮箱修复请求条目。

还可以使用 New-PublicFolderDatabaseRepairRequest cmdlet 检测并修复公用文件夹数据库中的复制问题。在请求运行时，仍然可以访问公用文件夹数据库中的公用文件夹。但是，不能访问当前正在修复的公用文件夹。有关详细信息，请参阅创建公用文件夹数据库修复请求。

Exchange 2010 的各版本中的数据库

超时检测和报告

如果线程死锁或者停止执行，也表明 Exchange 存储运行不正常。如果在一分钟内单个邮箱上有超过五个线程、单个数据库上有超过十个线程或单个服务器上有超过二十个线程未执行，将在服务器上报告超时。指示检测到超时的性能计数器是 MSExchangeIS\ RPC Request Timeout Detected。

Exchange 存储还将下列事件写入服务器：

  • 10025，报告 Exchange 服务器超时

  • 10026，报告数据库超时

  • 10027，报告单个邮箱超时

如果在单个邮箱上检测到超时，则该邮箱可能会被认为已中毒，并通过增加 CrashCount 项的值以与处理故障类似的方式对其进行处理。这样就更容易将其隔离。

Exchange 2010 的各版本中的数据库

数据库日志或数据库驱动器上磁盘空间不足

当 Exchange 存储检测到日志或数据库驱动器的可用空间低于 1 GB 时，就会中断向该数据库进行的所有传送。这是为了防止磁盘空间不足。当磁盘空间不足时，将无法装入或调试数据库。此外，也无法回收数据库空间。这是一种自我保护机制，仅在您未对监视基础结构所发出的空间问题警告做出反应时才出现。

磁盘空间超过 1.5 GB 时，Exchange 存储允许继续进行传送。下列性能计数器会指示这种情况：

  • MSExchangeIS Mailbox\ Delivery Blocked：数据库空间不足

  • MSExchangeIS Mailbox\ Delivery Blocked：日志空间不足

Exchange 存储还将下列事件写入服务器：

  • 10014，指示磁盘上的日志空间不足

  • 10015，指示磁盘上的数据库空间不足

如果遇到磁盘空间不足的问题，可以执行以下操作来更正问题：

Exchange 2010 的各版本中的数据库

Exchange 存储限制

在 Exchange 2010 中，对 Exchange 存储实施了连接和使用限制，以防止单个应用程序或单个用户使用所有与 Exchange 存储的可用连接。如果单个用户或应用程序使用所有连接，其他用户或应用程序将无法访问 Exchange 存储，这可能会导致停机。

有关详细信息，请参阅Exchange 存储限制。

Exchange 2010 的各版本中的数据库

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