了解和分析-1018年、-1019年和-1022年交换数据库错误

文章翻译 文章翻译
文章编号: 314917 - 查看本文应用于的产品
展开全部 | 关闭全部

本文内容

概要

本文提供了信息可帮助您了解和分析-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 知识库中相应的文章:
237953在联机备份过程中返回的错误-1018年错误
230215 不在单处理器计算机上执行的备份 checksuming
尽管-1019年和-1022年错误的大部分也由故障底层系统中,但不能排除发生的可能性-1019年和-1022年错误可能由于错误而在 Exchange 作为快速的代码。

错误-1018年是一个最常见的错误,它表明 Exchange 数据库遭到损坏,在文件系统级别。因此,大部分这篇文章重点介绍-1018年错误。

有三个磁盘上的数据可以被损坏的基本方法:
  • 错误的数据写入存储媒体。
  • 错误的位置写入数据存储介质上。
  • 数据已损坏,或在存储更改。
尽管这是很难避免或修正所有损坏的 100%,则相对容易地检测到已发生的问题。Exchange 检测其数据库文件中的错误和放错了位置的数据和报告-1018年错误或-1019年错误。如果文件严重损坏,并且它的部分完全缺少或其他不能访问 Exchange 试图读取文件时,会报告-1022年错误。

Exchange 如何计算校验和和数字数据库页

若要了解触发-1018年和-1019年错误的机制的工作方式,您必须了解 Exchange 数据库存储数据页的方式。

在最低的逻辑级别,您可以将 Exchange 数据库文件看作一 4 千字节 (KB) 页面,按顺序编号。读取和写入一次 Exchange 数据库一页数据。

每个页都包含数据的存储着其自己的页编号,并且有在页的所有数据从都计算校验和。校验和值本身只是一部分未在此计算中包括的页面。

校验和算法,包括交换使用,校验和算法是很容易理解和相对来说比较简单。他们进行了设计,因此,这样就可以为任何两个不同的网页相同的校验和很低,即使页面之间的区别是只有一个位。

尽管校验和测试足以确定写入后已更改的页,但校验和测试不足以确保页处于正确的位置。由于以上原因,Exchange 使用其自己的页编号,以及一个校验和标记每个页面。

前两个的 4 KB 页面,在数据库中保留给数据库的"标题。停止数据库后,您可以使用 Eseutil 实用工具 /MH 切换以查看此标头。标头中包含有关数据库作为一个整体的标识信息。

后这些两个标题页,在数据库中的其他网页的所有数据。所有的数据页共享公用结构。每个页都有其自身页面页眉,其中包含有关特定页,跟实际数据的标识信息。

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

在数据库中的逻辑页号直接映射到物理页编号,由以下公式:
逻辑页编号 = 物理页编号-2
数据库文件的逻辑和物理页结构密切相关,因为 Exchange 可以很容易地确定每个逻辑页是否是在文件中正确的物理位置。

不为其计算校验和的数据库的唯一网页是"未初始化的页面。它们的数据库的大小会扩展以容纳更多的数据时所创建的页块。在未初始化的页是一种具有零个校验和和零页号。通常情况下,使用字符填充未初始化的页的每个字节 0x00.

第一次使用未初始化的页后,它不返回未初始化状态,即使它将被清空。相反,一个标志,以将其标记为可供重复使用设置空白页上。页面仍带有页码和校验和,即使它是空的。

Exchange 2003 Service Pack 1 (SP1) 更改的校验和算法和正在使用的页面格式。此外,Exchange Server 2003 SP1 引入错误纠正代码 (ECC) 算法来检测和自动更正单比特错误。有关此新功能的详细信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章:
867626新的纠错码包含在 Exchange 服务器 2003 Service Pack 1

什么导致-1018年错误

Exchange 报告-1018年错误时初始化页的数据库文件中找到以下条件之一:
  • 存储在页的校验和不匹配读取页时执行校验和计算的结果。
  • 存储在页上的页码与应在页上,在给定的数据库文件中的页的物理位置的页码不匹配。
它可能需要负责则-1018年错误,如果 Exchange 执行下列内容之一:
  • 构造具有错误校验和的页。
  • 正确,构造一个页但通知操作系统在错误的位置写入页。
系统管理员遇到-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年错误是在数据库中的空页上,您不能知道哪一页可能已被破坏下一步。如果关键性全局表已损坏,数据库可能会变得 unstartable,并且数据库修复可能不成功或仅部分成功。

记录-1018年错误之后,您必须考虑和查找并消除根本原因之前规划即将发生故障或数据库进一步随机损坏的可能性。

从-1018年错误恢复

Exchange 将处理将失败,并防止对随机数据的操作导致数据库中的更多问题完全不可读取-1018年错误的页。

不能修复失败,出现-1018年错误的页,或在 salvaged。它必须从数据库擦除。有三种方法可以用来擦除从数据库页:
  • 从联机备份还原数据库。
  • 使用 eseutil.exe 会 /D 切换到执行数据库脱机碎片整理。
  • 使用 eseutil.exe 会 /P 若要修复该数据库的开关。

从联机备份还原数据库

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

使用 eseutil.exe 会 / D 切换到执行数据库脱机碎片整理

此方法很有效,如果-1018年错误报告空白页上。如果仅在联机备份或每夜联机维护期间出现-1018年错误,这表明很少访问的页面或它甚至可以是空白。所有空白页和数据库中的辅助索引,则会丢弃脱机碎片整理。

使用 eseutil.exe 会"/ P"切换到修复数据库

如果您使用此方法,但损坏的页会被删除,则不会修复损坏的页。如果涉及到的网页是"叶级页",会发生丢失数据。在数据库中的叶级页是执行实际的数据页。内部页带有仅结构和逻辑信息。在大多数情况下,Eseutil 可以完全重建表,如果内部页都将丢失。但是,大多数数据库中的页是叶级页。

Eseutil 的修复功能可以正常运行,并且在大多数情况下可以将数据库还原到最小的数据丢失的操作。但是,如果多个页面已损坏,或关键系统表都将丢失,数据丢失可能会导致灾难性后果,或者数据库可能无法修理。

通常,修复数据库是从备份恢复和前滚数据库,因为修复通常所用的时间比还原是下策与相比。仅当选择修复:
  • 您没有备份。
  • 您不能向前滚动完全从您的备份。
在修复或还原数据库之前,始终使当前数据库文件的备份副本。如果还原操作不起作用,您可以修复现有的数据库。如果修复不起作用,但仍然启动数据库的以前的副本,您可能能够抢救数据将会丢失。

重要 在修复数据库之后,您必须检查数据库标头中的修复计数。如果计数大于零,您必须使用 Eseutil,执行脱机碎片整理,然后您必须修复在信息存储级别使用 Isinteg 实用程序数据库。如果不这样做,用户可能会遇到问题,如无法在其邮箱已不存在的项目中打开邮件或附件或引用。

要检查的修复计数,请检查屏幕生成输出,当您运行以下命令:
ESEUTIL /MH [database_file_name]
要执行脱机碎片整理被修复的数据库,请运行以下命令:
ESEUTIL /D [database_file_name]
若要执行全面 Isinteg 修补程序修复后在 Exchange 2000,必须运行信息存储服务,但必须卸除要修复的数据库。运行以下命令以数据库修补程序:
ISINTEG-S [服务器名称]-修复-测试 ALLTESTS
若要执行全面 Isinteg 修复修复后在 Exchange 5.5,信息存储服务,必须停止服务器。运行以下命令,使用相应的交换机 (-PRI-PUB),具体取决于您是否运行修复对私有或公用数据库:
ISINTEG-PRI|PUB-修复-测试 ALLTESTS
请注意 您可以运行 Eseutil 和 Esefile 对原始数据库文件而不考虑他们的文件系统位置。数据库文件甚至不需要在 Exchange 服务器上。但是,数据库处于完全配置的 Exchange 服务器上的位置,因为 Isinteg 在信息存储级别运行,用来访问数据库的信息存储服务时,您必须运行 Isinteg。

有关详细信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章:
244525如何在没有 Exchange 服务器的计算机上运行 Eseutil

从-1019年错误恢复

预计将在使用的页未初始化或为空时,将报告-1019年错误 (JET_errPageNotInitialized)。如果 0x00000000 页码域中使用的页面上,-1019年错误报告的-1018年错误,而不是,即使页面也可能会校验和测试失败。

若要更正-1019年错误的方法是相同来更正-1018年错误。注意-1019年问题可能检测不到时间大于-1018年问题因为-1019年问题无法检测到联机备份。

尽管-1018年错误的根本原因很可能是 Exchange 之外,-1019年错误可能被因为 exchange 如果逻辑指针或页之间的链接无效。

但是,更常见的是-1019年错误原因是文件系统被损坏,或者页映射到不属于该文件的数据库文件。

从-1022年错误恢复

如果 Exchange 在数据库中,页要求操作系统,导致发生错误而不是所返回的页面数据会导致-1022年错误 (JET_errDiskIO)。-1022年错误是一般性错误,只要磁盘输入/输出 (I/O) 问题使 Exchange 无法访问数据库中所请求的页,就会出现。

-1022年错误的最常见原因是数据库文件严重损坏或截断。如果发生此问题,Exchange 将请求页号大于总页数在数据库文件中,并产生-1022年错误。由于文件系统中的问题或由于不正确的事务日志重播,会发生此问题。

Exchange 2000 中包含大量的安全措施以阻止重播事务日志,则可能会损害该数据库,但是,在 Exchange 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 输出中。当您运行的数据库完整性检查时,可能会报告-1018年错误的应用程序事件日志中 Eseutil /G 命令。在此情况下,则可能损坏的页为空。

在大多数情况下,允许您确定报告问题的页的窗体中报告错误。您还可以扫描 Esefile 标识损坏页与整个数据库。 Esefile 有关的详细信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章:
248406Exchange Server 5.5 和 Exchange 2000 Esefile 支持实用程序
下面的示例是从各种版本的 Exchange,连同分析中的每个错误的详细信息的应用程序事件日志的典型-1018年错误描述。
MSExchangeIS (248) Synchronous read page checksum error -1018
((1:3106 1:3106)(0-310013)(0-312215)) occurred.
Please restore the databases from a previous backup.
					
在前面的示例中,您可以解释在括号中的数字,如下所示:
  • (3106 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 查看页的更多的逻辑信息。可以查看页面结构信息从 Exchange 2000 和 Exchange Server 5.5 数据库使用 Eseutil 的 Exchange 2000 版本。

警告 不要在任何模式下写入到数据库的使用 Eseutil 的 Exchange 2000 版本对 Exchange Server 5.5 数据库。仅为安全起见,使用 /M 交换机和永远不会使用 /P, /G/R.此外,不要将 eseutil.exe 会和 Ese.dll Exchange 2000 版本复制到 Exchange Server 5.5 计算机。相反,将这些文件复制到远程服务器,并提供要检查数据库显式命令行通用命名约定 (UNC) 路径。

以下命令类似的命令输出到一个文本文件页的逻辑信息:
Eseutil /M \\exchange1\d$\exchsrvr\mdbdata\priv.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如何确定哪些邮箱拥有数据库中的某一特定页
如果 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) 中的页码不匹配请求的页时,这意味着存储页编号的页标题区域损坏。则可能: 页码甚至没有在数据库中。要确定是否属于这种情况,请 4096,再乘以页码,然后将该编号,以字节大小的数据库文件进行比较。在这种情况下,页码不大可能是 Exchange 最初写入,除非数据库的大小 (3,688,618,971 x 4096 = 15,108,583,305,216) 的 15 万亿字节。

另请注意,第一 dbtime 值完全重复页面号码模式。如果您将 3688618971 转换为十六进制 (使用计算器中其科学型模式下) 时,它将成为 0xDBDBDBDB。在 Exchange 2000 和 Exchange Server 5.5,8 个字节 dbtime 值的 4 字节的页号值后立即存储。为此,您知道至少 12 个连续的字节数为两个不同字段已覆盖具有特定模式。如果使用 Esefile 直接查看此页时,可能会发现与模式 0xDB 被覆盖的整个页面。另一种常见的无效字节模式为 0xFF。如果这是上面的错误的大小写 dbtime 值将是 4294967295。

出现以下错误提供了为在文件中的字节偏移量,而不是页码的页面信息:
Information Store (2160) The database page read from the file
"d:\exchsrvr\MDBDATA\PRIV.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 将使用头复制一个干净的校验和与 Exchange 重新启动时。

与前面的示例,请先校验和彼此实际上非常接近,各不相同,只有两个字符。校验和关闭时,这表明在页上所做的更改是最小: 也许只有一个位错误。很可能该页面仍然包含足够多的值得分析使用其逻辑结构 /M Eseutil /P.

现在存在于数据库中实际读取从页的校验和错误消息中的预期校验值。实际校验和错误消息中的是 Exchange 动态 re-calculates 读取页的校验和。

如果在页面上的实际校验和是 0x89abcdef,该页面包含所有 0x00 字符。如果实际的校验和是 0x76543210,该页面包含 0xFF 的所有字符。

下面的示例是-1019年错误:
Information Store (3928) The database page read from the file
"d:\exchsrvr\MDBDATA\PRIV.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 期望页都被使用。它可能很难证明-1019年错误原因是文件系统映射到数据库文件中,零块还是因为 Exchange 犯了一个引用未使用的页作为"中使用"。

页未初始化或处于其他状态,不能从前面的错误判断。您必须使用 Esefile 和 Eseutil 来进一步检查页面。在此示例中,页码是 408 十进制 (从 0x199 派生)。

您可以使用 Eseutil 进一步检查页面。" pgnoThis 值应与匹配的查询时,页码和 ulChecksumParity 报告其他值 ** 计算校验和 如果在页面上的校验和错误,值。您可以使用 Esefile /D 切换到查看以确定其是否处于未初始化的原始页 (所有 0x00 字符)。

-1018年错误

磁盘上的页是正确的但 I/O 系统未能正确地检索数据时,将发生"假"-1018年错误。此类错误通常是瞬态和难隔离。但是"假"-1018年错误都留意。存储系统的可靠性仍受到安全威胁,并且系统有可能会在其他问题或故障的危险。

如果您怀疑暂时性的读取的错误在您的系统中,使用 Esefile /D 切换或 /M Eseutil /P 若要验证所涉及的各个页面。如果任一实用程序可用于扫描整个数据库,则将可能会导致更多的误报的 I/O 系统的负担。

Exchange 5.5 Service Pack 2 (SP2) 添加功能,以帮助标识暂时性的读取的错误。Exchange 读取的验证失败后重读页 16 倍。如果几次重试后成功最终读取的页,则表明在能够可靠地读取磁盘中没有一个系统的问题。即使所有 16 次读取均失败,并不最终证明该页面已损坏。执行与 Esefile 或 Eseutil 次测试。

数据库零位调整

数据库零位调整用于 Exchange 数据库中的已删除的信息,以便它不能恢复或通过直接检查数据库文件的读取。 有关数据库零位调整的详细信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章:
223161ESE 清零操作的信息
如果启用了数据库零位调整,则为空或部分空页面的某些部分可能会被覆盖,与特定字符模式,但该页仍不会返回未初始化状态。

属性

文章编号: 314917 - 最后修改: 2011年5月24日 - 修订: 0.1
这篇文章中的信息适用于:
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange 2000 Server 标准版
  • Microsoft Exchange Server 5.5 标准版
关键字:?
kbinfo kbmt KB314917 KbMtzh
机器翻译
注意:这篇文章是由无人工介入的微软自动的机器翻译软件翻译完成。微软很高兴能同时提供给您由人工翻译的和由机器翻译的文章, 以使您能使用您的语言访问所有的知识库文章。然而由机器翻译的文章并不总是完美的。它可能存在词汇,语法或文法的问题,就像是一个外国人在说中文时总是可能犯这样的错误。虽然我们经常升级机器翻译软件以提高翻译质量,但是我们不保证机器翻译的正确度,也不对由于内容的误译或者客户对它的错误使用所引起的任何直接的, 或间接的可能的问题负责。
点击这里察看该文章的英文版: 314917
Microsoft和/或其各供应商对于为任何目的而在本服务器上发布的文件及有关图形所含信息的适用性,不作任何声明。 所有该等文件及有关图形均"依样"提供,而不带任何性质的保证。Microsoft和/或其各供应商特此声明,对所有与该等信息有关的保证和条件不负任何责任,该等保证和条件包括关于适销性、符合特定用途、所有权和非侵权的所有默示保证和条件。在任何情况下,在由于使用或运行本服务器上的信息所引起的或与该等使用或运行有关的诉讼中,Microsoft和/或其各供应商就因丧失使用、数据或利润所导致的任何特别的、间接的、衍生性的损害或任何因使用而丧失所导致的之损害、数据或利润不负任何责任。

提供反馈

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com