XADM：理解和分析 -1018、-1019 和 -1022 Exchange 数据库错误 (转)

最新推荐文章于 2024-06-15 23:21:13 发布

circularr9834

最新推荐文章于 2024-06-15 23:21:13 发布

阅读量596

点赞数

文章标签：数据库操作系统

XADM：理解和分析 -1018、-1019 和 -1022 Exchange 数据库错误 (转)[@more@]

概要

本文提供的信息可帮助理解和分析 -1018、-1019 和 -1022 Exchange 数据库错误。本文介绍这三种错误的不同之处和导致报告这三种错误的数据库中的问题类型。

更多信息

Exchange 包括检测数据库中文件级页损坏的功能。与 Exchange 数据库有关的文件级损坏相关的最常见的三种错误是：

-1018 JET_errReadVerifyFailure
-1019 JET_errPageNotInitialized
-1022 JET_errDiskIO

在 Exchange 数据库中可能发生三种级别的损坏：

页（文件系统）级别
数据库（JET 数据库引擎）级别
应用程序（Exchange 信息存储）级别

Esefile.exe 实用工具可以检测数据库中页级别的错误。Eseutil.exe 实用工具可以检测和修复页级别和数据库级别的问题。Isinteg.exe 实用工具可以检测和修复应用程序级别的问题。

较低级别的损坏（页级别）几乎总是会导致较高级别的问题（数据库或应用程序级别）。因此，在使用 Eseutil 修复数据库之后，几乎每次都要接着使用 Isinteg。

数据库级和应用程序级的损坏与 Exchange 代码或与 Exchange 集成的第三方程序中的问题有关。页级损坏一般是由驱动程序、固件或硬件造成的，不过 Exchange 中的问题也可能会导致页级损坏。

您几乎总是会发现导致 -1018 错误的根本原因是 Exchange 依赖的底层系统，而不是 Exchange 代码本身。这一规律很少有例外。到目前为止例外情况仅在 Exchange 报告 -1018 状态方面，而不是因为 Exchange 本身导致了 -1018 错误。有关其他信息，请单击下面的文章编号，以查看 microsoft 知识库中相应的文章：

ASPx?scid=kb;EN-US;237953">237953 XADM:Erroneous -1018 Error Returned During Online Backup

aspx?scid=kb;EN-US;230215" rel="nofollow">230215 XADM:Backup Checksuming Not Performed on Single Processor Computers

尽管 -1019 和 -1022 错误主要是由底层系统中的缺陷造成的，但也不要马上就排除 Exchange 代码中的错误导致发生 -1019 和 -1022 错误的可能性。

错误 -1018 是一个最常见的错误，它表明 Exchange 数据库在文件系统级别遭到破坏。因此，本文将重点探讨错误 -1018。

造成磁盘上的数据损坏的基本情形有三种：

向存储媒体中写入了错误数据。
数据写入存储媒体中的错误位置。
数据在存储后被损坏或更改。

尽管很难做到百分之百防止或修正所有损坏，但检测到已发生的问题相对来说还是很容易的。Exchange 可以检测到其数据库文件中不正确的和放错位置的数据并报告 -1018 错误或 -1019 错误。如果文件严重损坏或文件的某些部分完全丢失，或者在 Exchange 尝试读取文件时不可访问，将会报告 -1022 错误。

Exchange 是如何计算校验和并给数据库页编号的

要了解触发 -1018 和 -1019 错误的机制的工作原理，必须了解 Exchange 数据库是如何存储数据页的。

在最低的逻辑级别，您可以将 Exchange 数据库文件看作是一组 4 KB 的页，它们按顺序编号。在从 Exchange 数据库读取和向其中写入数据时是逐页进行的。

包含数据的每个页都存储着其自己的页编号，并且有一个通过计算页上的所有数据而得出的校验和。校验和值本身是页上唯一未包括在这一计算中的部分。

校验和算法，包括 Exchange 使用的校验和算法，都很好理解而且相当简单。它们经过特别设计，使两个不同的页生成相同校验和的可能性很小，即使两个页之间仅有一位之差。

尽管校验和测试足以确定页在写入后是否被更改，但校验和测试不足以确保页处于正确的位置。因此，除校验和外，Exchange 还为每个页加上了其自己的页编号。

数据库中前两个 4-KB 的页保留作为数据库的“标题”。在数据库停止时，您可以使用 Eseutil 实用工具的 /MH 开关查看此标题。标题包含用于标识整个数据库的信息。

在这两个标题页之后，数据库中的所有其他页都是数据。数据页都共享一个公用的结构。每个页都有其自己的页标题，它包含关于此特定页的标识信息，后面接着是实际的数据。

因为 Exchange 数据库中的第一个数据页位于前两个标题页之后，数据库中的第 3 物理页就是第 1 逻辑页。第 4 物理页就是第 2 逻辑页，依此类推。

数据库中的逻辑页编号通过下面的公式直接映射到物理页编号：

逻辑页编号 = 物理页编号 - 2

由于数据库文件的逻辑和物理页结构的关系是如此紧密，Exchange 可以很容易确定文件中的逻辑页是否位于正确的物理位置。

数据库中不计算校验和的页只有“未初始化的页”。它们是在扩展数据库大小以便为容纳更多数据创造空间时创建的页块。未初始化页的校验和及页编号均为零。一般情况下，未初始化页的每个字节都填充了“0x00”这一字符，但从 Exchange Server 4.0 或 Exchange Server 5.0 升级的数据库可能不是这样。

在未初始化页经过第一次使用后，它将不再返回未初始化状态，即使将它清空也是如此。相反，将在空页上设置一个标记以标明它可以再使用。此页仍带有一个页编号和校验和（即使它是空的）。

什么导致了 -1018 错误

当数据库文件中的已初始化的页中发现有下列情况之一时，Exchange 将报告一个 -1018 错误：

存储在页上的校验和与在读取页时所执行的校验和计算结果不匹配。
在给定了页在数据库文件中的物理位置的情况下，存储在页上的页编号与页上应有的页编号不匹配。

如果 Exchange 执行了下列操作之一，则它可能需要对自己生成的 -1018 错误负责：

构造一个具有错误校验和的页。
正确构造了页，但告诉操作系统将页写入错误的位置。

在系统管理员遇到 -1018 错误后，如果管理员在服务器上运行诊断硬盘测试而且这些测试报告没有问题，管理员可能就会断定问题的原因必然在于 Exchange，因为硬件已通过了初始分析。

然而，一次又一次，Microsoft 或硬件供应商通过进一步研究发现，硬件、固件或设备驱动程序中的一些细微问题应对损坏数据库文件负责。

由于多种原因，常规的诊断测试不能检测到所有这些暂时性错误。固件或驱动程序软件中的问题可能超出了诊断程序的诊断能力。诊断测试可能无法充分模拟长时间的运行或复杂的负载。而且，诊断监视或调试日志记录的添加可能会对系统造成足够程度的改变，以致问题不能再现。

Exchange 生成校验和及向数据库文件写入页的机制非常简洁而稳定，这是又一个理由，进一步表明 -1018 错误的根本原因不大可能是 Exchange 问题。校验和及错误页检测机制简单而可靠，自 Exchange 第一次发行以来基本上保持原样未动，只进行了一些较小的修改，以适应数据库版本之间的数据库页格式更改。

需进一步说明的是，校验和是在页就要写入到磁盘时生成的，此时所有其他数据（包括页编号本身）都已写入该页。在 Exchange 将校验和添加到页后，Exchange 命令 Microsoft windows 操作系统通过使用标准的、已发布的 Windows 应用程序编程接口 ( api) 将该页写入磁盘。

对于一个页来说，其校验和可能已正确生成，但接着此页也许会写入硬盘上的错误位置。这可能是由于暂时性内存错误造成的，如“位翻转”。例如，假设 Exchange 构建了第 70 页的一个新版本。该页本身未遇到错误，但是由磁盘控制器或操作系统使用的页编号的副本被随机改变了。如果 70（二进制 100110）由不稳定的内存单元更改为 6（二进制 000110），则可能会出现此问题。该页的校验和仍然正确，但现在该页在数据库中的位置出现了错误。当 Exchange 检测出逻辑页编号与页的物理位置不符时，将报告该页出现 -1018 错误。如果 Exchange 在页本身写入了错误的页编号，则可能会发生另一类页编号错误（由 Exchange 导致）。但这导致的是其他错误，而不是 -1018 错误。如果 Exchange 在第 70 页写入编号 71，然后在该页上正确地执行了校验和计算，则该页将写入 71 的位置，并且能通过页编号和校验和测试。

往往是，Exchange 数据库中报告的单个 -1018 错误并不会导致数据库停止，而且除显示 -1018 错误本身以外不会导致其他症状。该页可能在不经常访问的文件夹中（例如，“已发送邮件”或“已删除邮件”文件夹），或者位于一个很少打开甚至为空的附件中。

尽管单个 -1018 错误不大可能导致大范围的数据丢失，但仍会引起关注，因为一个 -1018 错误证明您的存储系统至少有一次未能可靠地存储或检索数据。尽管 -1018 错误可能是永远不会再次发生的暂时问题，但此错误很可能是一个早期警告，预示着一个将会越来越严重的问题。即使第一个 -1018 错误在数据库的一个空白页上，但您不知道下一次将是哪个页被损坏。如果一个关键的全局表被破坏，则数据库将可能无法启动，而且数据库修复也可能不会成功，或者只能部分成功。

在记录 -1018 错误之后，在发现并消除根本原因之前，您必须考虑到很快就会发生故障或对数据库进一步造成随机损坏的这一可能性并做出相应的计划。

从 -1018 错误中恢复

Exchange 将以 -1018 错误而失败的页视为完全不可读取的页，以防止对随机数据的操作导致数据库中进一步出现问题。

以 -1018 错误而告失败的页无法修复或挽救。必须从数据库中将其擦除。可以使用三种方法从数据库中擦除页：

从联机备份还原数据库。
使用 Eseutil.exe /D 开关进行数据库的脱机碎片整理。
使用 Eseutil.exe /P 开关修复数据库。

从联机备份还原数据库

如果在联机备份期间发现 -1018 错误，则备份将会停止。这可以确保损坏的页不会存在于上次成功备份上。如果禁用了循环记录，您可以还原最近可用的完整备份，然后将数据库从后继的事务日志中向前滚动。

使用 Eseutil.exe "/D" 开关进行数据库的脱机碎片整理

此方法在报告空白页上存在 -1018 错误时有效。如果仅在联机备份或每夜的联机维护期间发生 -1018 错误，则表明该页很少访问甚至可能是空白页。脱机碎片整理会废弃数据库中的所有空白页和辅助索引。

使用 Eseutil.exe“/P”开关修复数据库

使用此方法不会修复损坏的页，但损坏的页将会被删除。如果涉及的页是一个“叶级页”，将会丢失一些数据。数据库中的叶级页是携带实际数据的页。内部页仅携带结构和逻辑信息。在多数情况下，如果内部页丢失，Eseutil 可以完全重建表。不过，数据库中的大部分页都是叶级页。

Eseutil 的修复功能可以正常运行，并且在多数情况下可以将数据库以最少的数据丢失还原到运行状态。不过，如果许多页遭到损坏，或者关键系统表丢失，则数据丢失将可能是灾难性的，而且数据库也可能无法修复。

与从备份还原和将数据库向前滚动相比，修复数据库通常是下策，因为修复比还原用的时间长，而且风险较大。仅在下列情况下才选择修复：

您没有备份。- 或者 -
您无法从备份完整向前滚动。

在修复或还原数据库之前，都要制作当前数据库文件的备份副本。如果还原不能成功，您可以修复现有的数据库。如果修复不成功，但数据库以前的副本仍可以启动，您可能能够挽救若没有以前的可启动副本则必然会丢失的数据。

重要说明：在修复数据库之后，必须检查数据库标题中的修复计数。如果计数大于零，则必须使用 Isinteg 实用工具在信息存储级别修复数据库。如果不这样做，用户可能会遇到问题，例如无法打开邮件或附件，或者其邮箱中的引用指向不再存在的内容。

若要检查修复计数，请检查运行以下命令时生成的屏幕输出：

ESEUTIL /MH [数据库文件名]

如要在修复 Exchange 2000 之后进行全面的 Isinteg 修复，“信息存储”服务必须在运行，但要修复的数据库必须卸载。运行下面的命令进行数据库修复：

ISINTEG -S [服务器名] -FIX -TEST ALLTESTS

如要在修复 Exchange Server 5.5 之后进行全面的 Isinteg 修复，必须停止信息存储服务。根据要修复的是专用数据库还是公用数据库，使用适当的开关（ -PRI 或 -PUB）运行下面的命令行：

ISINTEG -PRI|PUB -FIX -TEST ALLTESTS

注意：您可以在原始数据库文件上运行 Eseutil 和 Esefile，而不用管它们的文件系统位置。数据库文件甚至不需要在 Exchange 服务器上。但是在运行 Isinteg 时要求数据库必须在完全配置的 Exchange 服务器上，因为 Isinteg 在信息存储级别运行，并使用信息存储服务访问数据库。

有关其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：

244525 XADM:如何在没有 Exchange Server 的计算机上运行 Eseutil

从 -1019 错误中恢复

当本应被使用的页未初始化或者为空时，将报告 -1019 错误 (JET_errPageNotInitialized)。如果使用中的页上的页编号字段是 0x00000000，则会报告 -1019 错误而不是 -1018 错误，即使在该页的校验和测试也未通过的情况下亦是如此。

纠正 -1019 错误的方法与纠正 -1018 错误的方法相同。注意，-1019 问题可能在发现 -1018 问题之后才能被发现，因为通过联机备份检测不到 -1019 问题。

尽管导致 -1018 错误的根本原因很可能在 Exchange 之外，但如果页之间的逻辑指针或链接无效，则可能会由 Exchange 导致 -1019 错误。

不过，发生 -1019 错误更常见的原因是文件系统被损坏，或者将页映射到不属于该文件的数据库文件中。

从 -1022 错误中恢复

如果 Exchange 向操作系统请求数据库中的一个页，则会出现一个错误而不是返回该页数据，结果会出现 -1022 错误 (JET_errDiskIO)。-1022 错误是一般性错误，每当磁盘输入/输出 (I/O) 问题使 Exchange 不能访问它请求的数据库中的页时，就会出现此错误。

-1022 错误最常见的原因是数据库文件被严重损坏或修剪。如果发生此问题，Exchange 将请求一个比数据库文件中的页数大的页编号，这样就会导致 -1022 错误。此问题可能会因为文件系统中的问题或者因为不适当地重放事务日志而发生。

Exchange 2000 包含广泛的防范措施，可以防止可能会损坏数据库的事务日志重放，但在 Exchange Server 5.5 中，有可能会重放一组不完整的日志文件并损坏数据库。例如，如果重放应从日志 9 开始，但却被强制从日志 10 开始，则可能会出现此问题。如果管理员删除了检查点文件和日志 9，则可能会强制重放。如果日志 9 中的一个事务将扩展数据库的大小，但日志 9 未重放到数据库中，则日志 10 中对添加到数据库的新页的引用将导致 -1022 错误。将不完整的事务日志集重放到数据库中带来的常见症状还包括突然崩溃、停止（挂起）和访问冲突。

了解和排查 -1022 错误的根本原因比排查 -1018 或 -1019 错误更复杂。如果此错误是由于文件系统中的数据库损坏导致的，您需要检查或修复文件系统，然后从备份中还原 Exchange。尽管修复数据库仍是一个选项，但与修复其他错误相比，修复成功的可能性不大，因为 -1022 错误往往表明大面积的损坏。

到目前为止，未损坏的数据库发生 -1022 错误的最常见的原因是，另一应用程序让文件处于打开状态，使得信息存储服务无法访问这些文件。在这些情况下，您还可能会看到 -1032 错误 (JET_errFileAccessDenied)。重新启动所有 Exchange 服务或重新启动服务器可能会解除锁定。

第三方程序，如病毒扫描程序，可能会阻止 Exchange 访问 Exchange 数据。配置文件级病毒扫描时，总要将 Exchange 数据文件从文件扫描操作中排除。有几种病毒扫描程序利用了 Exchange 病毒扫描应用程序编程接口 (API) 来扫描信息存储中的邮件和附件。

分析 -1018 和 -1019 错误

此部分信息主要面向参与根本原因分析的技术支持人员和供应商人员。

在管理员发现 -1018 或 -1019 错误后，管理员至少需要知道三项内容：

被损坏的页上有什么内容
修复成功的可能性有多大
导致损坏的最初原因是什么

-1018 和 -1019 错误可能会在命令行中启动服务时发生，可能存在于应用程序的事件日志中，或者在 Exchange 实用工具（如 Eseutil）的输出中。当您使用 Eseutil /G 命令运行数据库完整性检查时，可能不在应用程序事件日志中报告 -1018 错误。在此情况下，被损坏的页很可能是空白的。

在多数情况下，报告错误的形式都让您能够确定是哪个页在报告此错误。您还可以使用 Esefile 扫描整个数据库，以确定被损坏的页。有关 Esefile 的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：

248406 XADM:Esefile Support Utility for Exchange Server 5.5 and Exchange 2000

下面几个例子是各种 Exchange 版本中的应用程序事件日志中的典型 -1018 错误描述，并包括对每个错误的详细分析。

MSExchangeIS (248) Synchronous read page checksum error -1018 ((1:3106 1:3106)(0-310013)(0-312215)) occured. Please restore the databases from a previous backup.

在上例中，圆括号中的数字应作如下解释：

(1:3106 1:3106) 代表数据库中被请求的页（第 3106 页），以及发现的页上实际写入的页编号（第 3106 页）。其中的“1:”代表这是数据库 1，在 Exchange Server 5.5 中就是 Priv.edb。数据库 2 是 Pub.edb。
(0-310013) 代表当前写入页中的 dbtime 值。dbtime 值是一个写在每个页上的 64 位值，大致与自从该页改变以来经过的时间相关。
(0-312215) 代表整个数据库的当前 dbtime 值：如果此页是现在改变的，则很可能是改变时写入此页的 dbtime 值。已经在此页上的 dbtime 值应始终比当前的 dbtime 值小。

假设正确地从该页读取了页编号，而且 dbtime 值也是合理的（第一个 dbtime 值比第二个小），则表明此页未由数据库外的页或另一不同的页完全替换。

您可以使用 Esefile，用一个与以下类似的命令输出此页本身：

Esefile /d database.edb 3106 > 3106.txt

由于此页在结构上看起来完全保持原样，因此您可能能够使用 Eseutil 查看此页的更多逻辑信息。您可以使用 Eseutil 的 Exchange 2000 版从 Exchange 2000 和 Exchange Server 5.5 数据库中查看页结构信息。

警告：使用 Eseutil 的 Exchange 2000 版本时，请不要在 Exchange Server 5.5 数据库上使用任何可能会向数据库写入的模式。为保险起见，请仅使用 /M 开关，一定不要使用 /P、 /G 或 /R。而且，请不要将 Eseutil.exe 和 Ese.dll 的 Exchange 2000 版复制到 Exchange Server 5.5 计算机上，而应将这些文件复制到一个远程服务器，并提供一个到您要检测的数据库的显式命令行统一命名约定 (UNC) 路径。

类似于下面这样的一个命令将把此页的逻辑信息输出到文本文件：

Eseutil /M exchange1d$exchsrvrmdbdatapriv.edb /p3106 > 3106.txt Initiating FILE DUMP mode... Database:priv.edb Page: 3106 pgnoThis <0x02360004, 4>:3106 (0x00000c22) objidFDP <0x02360018, 4>:19 (0x00000013) ulChecksumParity <0x02360000, 4>:4269350574 (0xfe791eae) ** computed checksum:157180847 (0x095e63af) dbtimeDirtied <0x02360008, 8>:310013 (0x000000000004bafd) cbFree <0x0236001c, 2>:436 (0x01b4) ibMicFree <0x02360020, 2>:3608 (0x0e18) itagMicFree <0x02360022, 2>:3 (0x0003) cbUncommittedFree <0x0236001e, 2>:0 (0x0000) pgnoNext <0x02360014, 4>:3108 (0x00000c24) pgnoPrev <0x02360010, 4>:3088 (0x00000c10) fFlags <0x02360024, 4>:2050 (0x00000802) Leaf page Primary page

从这一输出中，可以看出该页是一个叶级页，也就是说它上面有实际的数据。如果修复此数据库，则修复过程至少会导致此页数据的丢失。有关如何找到页所属的表或邮箱的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中相应的文章：

262196 XADM:How to DeteRmine Which Mailbox Owns a Particular Page in a Database

如果 Eseutil 输出中没有列出此页的叶级页，则修复完全成功的可能性就很大。多数内部页或结构页可以由复制过程完整地重构。

输出内容中还可能将此页显示为“空白页”。如果是这种情况，脱机碎片整理程序将会从数据库中废弃被损坏的页。

请记住，如果某个页已完全由不属于该数据库文件的数据块替代，则 Eseutil 输出内容可能会毫无意义。

下面是另一个错误示例：

MSExchangeIS ((247) ) Synchronous read page checksum error -1018 ((1:1057816 1:3688618971) (3688618971-3688618971) (0-16815256)) occurred. Please restore the databases from a previous backup.

在此示例中，从 (3688618971) 页实际读取的页编号与请求的页不匹配，这意味着存储页编号的页标题区域已被破坏。此页编号甚至有可能在数据库中根本不存在。如想确定是否属于这种情况，请用页编号乘以 4,096，然后将该数值与数据库文件的字节大小加以比较。在此情况下，该页编号不大可能是 Exchange 最初写入的那一页编号，除非数据库的大小是 15 TB (3,688,618,971 x 4,096 = 15,108,583,305,216)。

还要注意第一个 dbtime 值严格重复了该页编号模式。如果将 3688618971 转换为十六进制（在科学计数法模式中使用 Calc.exe），它将变成 0xDBDBDBDB。在 Exchange 2000 和 Exchange Server 5.5 中，8 字节的 dbtime 值紧挨在 4 字节的页编号值之后存储。因此，您就会知道两个不同字段中至少有十二个连续字节被一种特定的模式覆盖。如果使用 Esefile 直接查看此页，您可能会发现整个页被 0xDB 模式覆盖了。另一个常见的无效字节模式是 0xFF。如果上面的错误是这种情形，则 dbtime 的值将是 4294967295。

下面的错误中提供的页信息是该页在文件中的字节偏移量，而不是页编号：

Information Store (2160) The database page read from the file "d:exchsrvrMDBDATAPRIV.EDB" at offset 897024 (0x00000000000db000) for 4096 (0x00001000) bytes failed verification due to a page checksum mismatch.The expected checksum was 2651583211 (0x9e0bf2eb) and the actual checksum was 2651582996 (0x9e0bf214).The read operation will fail with error -1018 (0xfffffc06).If this condition persists then please restore the database from a previous backup.

您可以将第一个偏移量转换为页编号，方法是：删除结尾三个零，减去 1，并将结果转换为十进制数。在此例中，0x00000000000db - 1 = 0xda = 218（十进制）。您可以将此十进制页编号用于 Esefile 或 Eseutil。

注意：为将数据库中的两个标题页考虑在内，应减去 1，而不要减 2，这是因为，偏移量是从 0x0 而不是从 0x1 开始计数的。如想使用 Esefile 或 Eseutil 检查标题页，请指向第 -1 页和第 0 页。

Exchange 数据库标题实际上仅需要单个页。第二个页是标题的“影子”副本。在数据库完全关闭后，使用 Esefile /D 页转储功能针对第 -1 和第 0 页报告的校验和应始终是相同的。如果标题是在崩溃期间重写的，则 Exchange 在重新启动时将使用具有干净校验和的标题副本。

在前面的示例中，两个校验和实际上非常接近，仅有两个字符不同。当校验和接近时，表明对该页的更改非常小：也许只有一个位是错误的。很有可能此页仍包含足够的逻辑结构，值得使用 Eseutil /M /P 进行分析。

错误信息中预期的校验和实际上是从页中读取的，因为该页现在存在于数据库中。而错误信息中实际的校验和是 Exchange 在读取此页时重新动态计算的校验和。

如果页上的实际校验和是 0x89abcdef，则该页中包含的都是 0x00 字符。如果实际校验和是 0x76543210，则该页包含的都是 0xFF 字符。

下面是 -1019 错误的一个示例：

Information Store (3928) The database page read from the file "d:exchsrvrMDBDATAPRIV.EDB" at offset 1675264 (0x0000000000199000) for 4096 (0x00001000) bytes failed verification because it contains no page data.The read operation will fail with error -1019 (0xfffffc05). If this condition persists then please restore the database from a previous backup.

在典型操作中，如果一个页能够报告 -1019 错误或 -1018 错误，则 -1019 错误将优先报告。请记住，只要在页上写入的页编号是 0x00000000，就会发生 -1019 错误，但 Exchange 认为该页正在使用中。如果文件系统将一个由零填充的数据块映射到数据库文件中，或者 Exchange 出现错误并将一个未使用的页指定为“在使用中”，均会导致 -1019 错误，但很难证明究竟是其中哪一种原因造成了此错误。

从前面的错误中，您看不出来该页是处于未初始化的状态，还是处于其他状态。必须使用 Esefile 和 Eseutil 进一步检查此页。在此示例中，页编号是十进制数 408（从 0x199 中推出）。

可以使用 Eseutil 进一步检查此页。 pgnoThis 值应与查询的页编号相匹配，而且如果该页上的校验和是错误的， ulChecksumParity 值将报告一个附加的 ** 计算的校验和值。您可以使用 Esefile /D 开关检查原始页，以确定它是否未初始化（全是 0x00 字符）。

假 -1018 错误

当磁盘上的页正确但 I/O 系统未能正确地检索此数据时，会发生“假”-1018 错误。这种错误通常是暂时性的，而且很难查出原因。但即使是“假”-1018 错误也需要引起高度重视。存储系统的可靠性仍存在问题，而且系统可能存在发生其他问题或故障的危险。

如果怀疑系统上有暂时性读取错误，请使用 Esefile /D 开关或 Eseutil /M /P 检查涉及的每个页。如果使用其中任一实用工具扫描整个数据库，会造成 I/O 系统紧张，这可能会导致更多误判。

Exchange Server 5.5 Service Pack 2 (SP2) 添加了可帮助识别暂时性读取错误的功能。Exchange 在读取验证失败后将重新读取该页 16 遍。如果该页在数次尝试之后最终读取成功，则表明系统在从磁盘进行可靠的读取方面存在问题。即使 16 次读取都失败，也不能断言该页被损坏。请使用 Esefile 或 Eseutil 执行辅助测试。