Exchange Server 数据库体系结构和数据库引擎概述

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

本文内容

概要

本文提供了 Microsoft Exchange 服务器的数据库体系结构和数据库引擎的一般概述。讨论包括: 数据库组件的信息,数据库一致性的维护,可能类型的数据库故障和数据库实用程序。

更多信息

Exchange Server 来存储邮件和目录信息应用到数据库之前使用容错的、 基于事务的数据库。Exchange Server 5.5 标准版,每个数据库可以增长到 16 千兆字节 (GB) 的最大值。Exchange Server 5.5 企业版大小只受硬件限制。

如果发生断电或其他异常系统故障时,Exchange 服务器将使用事务日志文件来重新构建是已被服务器接受,但尚未写入到数据库的数据。

数据库组件

Exchange 服务器的设计基于标准的数据库技术。系统依赖于一个嵌入式的数据库引擎,Exchange 服务器的磁盘的结构进行布局并管理内存。数据库引擎技术也在后台使用由其他 Windows 应用,例如对于 Windows Internet 名称服务 (WINS) 和动态主机配置协议 (DHCP)。

信息存储

是关键的组件,用于在 Exchange 服务器的数据库管理,信息存储区是实际上两个单独的数据库。在专用信息存储数据库 Priv.edb,管理用户邮箱中的数据。公用信息存储区 Pub.edb,管理公用文件夹中的数据。

信息存储适用于该消息应用程序编程接口 (MAPI) 和数据库引擎,以确保所有的用户操作将记录在服务器的硬盘上。例如对于用户保存在 Outlook 中的一条消息时, MAPI 首先调用然后调用数据库为引擎然后将所做的更改写入到磁盘的信息存储区。

JET 数据库引擎

Exchange Server 数据库基于 JET 格式的使用日志文件来跟踪和维护的信息。Microsoft JET 是合并速度和其他高级功能来增强基于事务的处理能力与性能的高级的 32-位多线程的数据库引擎。

数据库引擎通过交换的数据在内存的 4 千字节 (KB) 页缓存在内存中的该磁盘。它更新内存中的页,并将新的或更新的页写回磁盘。这使系统更有效则因为请求时出现,而不是不断地将该磁盘的内存中的数据库引擎缓冲区数据时。

在版本早于 Exchange Server 5.5,高速缓冲存储器是一个固定的大小。如果需要更多的内存,则管理员必须手动更改缓冲区大小。

在 Exchange Server 5.5,动态缓冲分配允许扩大或缩小,根据多少内存,以及哪些资源正在使用 Microsoft Windows NT 服务器计算机上运行的其他服务的高速缓冲存储器。如果其他的服务不使用的内存,Exchange Server 数据库引擎将占用最随着它需要尽可能多的内存中。如果需要内存的其他服务,通过传输到硬盘的页并收缩该缓冲区的大小内,数据库引擎放弃一些内存。

请求在进行时,数据库引擎将请求加载到内存,并将标记为"脏"页面 ("脏"页面是已写入的数据,并仍被保存在内存中的页面)。这些脏页将稍后写入磁盘上信息存储数据库。

维护数据库一致性

尽管在内存中缓存是最有效的方法来处理数据,一种效果是在磁盘上的信息是永远不会完全保持最新的。在内存中的脏页会导致数据库被标记为不一致,即使 Exchange 服务器正常运行。数据库是真正的一致状态仅在所有脏页都成功时转移到在其中没有错误发生的关闭过程中的磁盘。

如果您丢失内存的内容吗?例如对于如果服务器崩溃之前将数据写入到磁盘和您处于不一致的数据库吗?Exchange 使用这种情况下从恢复事务日志文件。

事务日志文件

事务日志文件保留在内存中的易失数据的安全副本。如果系统崩溃,假设该数据库未损坏,日志文件使您能够恢复到上次提交事务之前崩溃的数据。(请注意建议您将存储在专用硬盘上的日志文件,以便日志不会影响可以损坏数据库的可能的磁盘故障)。

Exchange 是一个"基于交易记录"的消息传递系统,和信息存储是一个事务的数据库。事务是一组更改到如插入、 删除和在其中系统下面四个"ACID"的固定条件列表的更新的数据库:
  • 原子: 发生两者之一所有操作都出现或都不它们的出现。
  • 一致: 数据库是从一个正确的状态转换到另一个。
  • 独立: 更改之前将不可见提交。
  • 耐用: 提交的事务将在数据库中保留,即使系统崩溃。
以下这些固定条件列表意味着仅当它可以保证数据被从系统崩溃或其他故障保护持久或持久时,数据库引擎都将提交事务。仅当数据的已转移从内存到事务日志文件在硬盘上时,数据库引擎的提交数据。

例如对于要将邮件从收件箱文件夹移到重要文件夹,Exchange 服务器执行三个操作:
  1. 从收件箱文件夹中删除该邮件
  2. 将消息插入到重要文件夹
  3. 更新以反映项和未读的项目数的每个文件夹的信息
在一个事务中完成这些操作。该操作的顺序并不重要。Exchange 服务器可以安全地删除该邮件从收件箱文件夹因为仅当邮件被安全地插入到重要文件夹时,删除操作被提交。即使系统崩溃,Exchange 服务器永远不会移动它时丢失了一条消息,并且永远不会得到与该消息的两个副本。

逻辑上,您可能会认为的将数据作为从内存在日志文件,然后再在数据库上移动磁盘,但实际发生时将该数据从内存移至数据库磁盘上。日志文件经过优化以供高速的写操作以便在正常的操作过程中,数据库引擎永远不会实际读取日志文件。它读取日志文件中如果信息存储服务异常停止,或崩溃,数据库引擎需要重播日志文件中恢复的不同而不同。

检查点文件

数据库引擎维护为了跟踪的数据已不尚未写入到数据库文件在磁盘上的调用为每个日志文件序列 Edb.chk 检查点文件。检查点文件是指示在日志文件在信息存储需要的位置开始出现故障的情况下恢复的日志序列中的指针。检查点文件是必需的高效的恢复。没有它,信息存储将从磁盘上最旧的日志文件的开头开始,并检查以确定是否它有已被写入数据库--一个耗时的过程,尤其是如果您想做的只是使数据库保持一致的每个日志文件中的每一页。

检查点文件位于系统磁盘上。如果必须恢复您的系统磁盘,可能丢失了此文件中或在只有一个无效的版本中。但在大多数情况下检查点文件自身的处理。

普通记录

下面的步骤说明了"正常登录"的数据被写入事务日志文件的过程:
  1. 该用户发送一条消息。
  2. MAPI 调用信息存储,以告诉该用户发送邮件。
  3. 信息存储在数据库引擎启动事务,并对数据进行相应的更改。
  4. 数据库引擎通过 dirtying 在内存中的新页记录在内存中的交易记录。
  5. 同时,数据库引擎保护事务日志文件中的交易记录,并创建一个日志记录。当数据库引擎到达末尾的事务日志文件时,它将滑过,序列中创建一个新的日志文件。
  6. 数据库引擎将脏页写入数据库文件在硬盘上。
  7. 检查点文件被更新。
循环日志记录

Exchange Server 支持一种称为这实现管理员已更关心服务器磁盘空间比有关数据恢复时一次循环记录的功能。

循环日志记录工作方式在很大程度在同一方法正常记录只不过是必不可少的跟踪的传输的信息的检查点文件到磁盘。 在为该检查点文件前进到下一个日志文件的循环日志记录的过程中重复使用旧的文件。发生这种情况时您不能使用在一起的磁盘上的日志文件与备份媒体还原到最近提交的事务。

默认状态下,循环日志记录被打开在 Exchange Server 5.5 保持固定的大小的日志文件,并防止堆积。当一个日志文件达到其 5 MB 的限制时,数据库引擎将其删除,并创建一个新的日志文件序列中。如此一来 Exchange 服务器会使数据库保持一致,如果出现崩溃的硬盘上保留足够的数据。

建议您关闭您 Exchange Server 的计算机上的循环日志记录。循环日志记录可能可减少需要的磁盘空间,但它还消除了恢复到上次提交事务之前在出现故障的能力。您无法重放日志文件,只能恢复到上次完全备份的数据。即使只有一个日志文件将被覆盖,没有要恢复其他 99%,将日志数据的方法。

在起的作用,循环日志记录不再是一个基于事务的系统的优点。 保持打开状态的循环日志记录有必要,仅当您不需要您的数据,或者如果您有其他方法来恢复数据。如果您担心日志文件占用的磁盘资源是更好一些,通过执行定期的联机备份清除它们。当不再需要它们时,备份将自动删除事务日志文件。

数据保护

它看上去逻辑认为数据库文件是最重要方面的数据恢复。但在 Exchange 服务器,事务日志文件更重要,因为它们包含不在数据库文件中的信息。(这是您应在稳定的服务器上找到它们,并将它们放在专用的、 高性能磁盘上的原因即使这意味着将在速度较慢的磁盘上数据库文件放。

事务日志文件保留在磁盘上,以便系统可以恢复故障的内存中的易失数据的安全副本。如果系统崩溃,但只要您具有将日志文件,该数据库未损坏,您可以恢复到上次提交事务发生故障前的数据。

事务日志文件还使编写效率更高的数据,因为它是一个日志文件比若要将页面插入到数据库中按顺序更新网页更快。当在数据库中发生更改时,数据库引擎更新内存中的数据。 它同步将交易记录的记录写入日志文件,告诉它如何恢复交易记录,如果在系统出现故障。然后,数据库引擎将数据写入数据库磁盘上。若要最大限度地减少磁盘输入/输出,数据库引擎将传输到磁盘在批处理中的页。

序列中的每个日志文件可以包含多达 5 MB 的数据。满一个日志文件时它将被重命名为以前日志文件,并使用 Edb.log 文件的名称创建一个新。Exchange 服务器将每个日志文件与一个十六进制的生成编号相关联。因为日志文件可以有相同的名称数据库引擎戳标头具有唯一的签名序列中的每个文件中以便它可以区分不同的日志文件的生成内容。

数据库损坏

Exchange 可能会遇到一个故障,如要求系统尝试以返回到一致状态的硬件故障。因为存在不同类型的数据库损坏,使用不同的症状不同的工具和技术需要诊断和修复问题。

有两种类型的损坏:
  • 物理损坏
    最低级别的数据可以物理损坏磁盘上。这通常是与硬件相关的问题总是要求您从备份中还原。
  • 逻辑损坏
    典型的逻辑损坏发生在数据库级别上。例如对于数据库引擎故障可能会导致索引条目指向丢失的值。逻辑损坏也会发生在应用程序级别的邮箱、 邮件、 文件夹,和附件中。例如对于应用程序级别损坏可能导致不正确的引用计数不正确的访问控制级别但不包括一个消息正文的邮件头等等。

物理损坏

物理损坏是严重,因为它可以销毁数据,并可以执行该唯一一件事就是从备份还原 Exchange。很重要,检测早期物理损坏,并快速解决问题。

检测物理损坏

在信息存储中的物理损坏在事件查看器的应用程序日志中生成下列错误:
  • -1018 (JET_errReadVerifyFailure) 从磁盘读取的数据不是写入的数据相同到磁盘。
  • -1022 (JET_errDiskIO) 的硬件、 设备的驱动程序或操作系统正在返回错误。
  • -510 JET_errLogWriteFail 的日志文件的磁盘空间不足或没有使用日志文件磁盘发生硬件故障。
虽然 Exchange 在物理损坏时通常会显示一个-1018年或-1022年错误消息,但您还可以通过执行是 Microsoft 推荐的备份数据的方法的联机备份检测物理损坏。联机备份也是最好的方法来检测出数据库文件中的损坏,因为它是唯一的过程,它将系统地检查每个数据库中的单个页。

您在运行联机备份时 Windows NT 备份软件将读取数据库文件中的每个 4 KB 页面,将其传递到数据库引擎,然后将它写到磁带。数据库引擎,验证已在每页校验和正确。 如果在页校验和与数据库引擎计算的校验和不匹配将硬盘和 NT 备份日志上的物理数据库损坏-1018年错误。

防止物理损坏

为了防止物理损坏最好的方法是 outfit 质量的硬件组件与服务器并正确配置系统。请确保没有与运行 Exchange Server 的计算机上的数据库和日志文件运行文件级别实用程序的如防病毒的软件。

如果您可靠的硬件可能会永远不会看到物理破坏的迹象。如果一致地执行操作遇到-1018年错误,您可能有硬件问题,可能是损坏的磁盘或磁盘控制器。

有关回写高速缓存: 某些回写缓存阵列控制器不正确地成功提交的交易记录之前返回实际固定数据到磁盘。若要关闭的回写缓存,除非该进程具有电池备份是最安全的课程。如果使用了使用回写缓存,避免损坏的数据库,从而确保数据受到完全保护,并且您有程序,确保在崩溃之后重播到适当的磁盘缓存的数据。

从物理损坏恢复

从物理数据库损坏中恢复,唯一方法是从最后一次的正确备份中还原 (如果无错误运行备份,是很好) 并以一致且未损坏的状态将系统回滚向前日志文件。重复的失败可能表示数据库所在的位置该磁盘有问题。

实际上没有修复物理损坏数据库的安全方法。您可以运行在 Eseutil.exe 实用程序在修复模式以获得数据库再次,工作正常,但这不建议这样做,因为 Eseutil 只是删除了坏的页。

注:如果是在所有可能避免在修复模式下使用 Eseutil (eseutil/p)。Eseutil,附带的 Exchange 服务器,是最后的手段对所有其他失败时修复数据库损坏。在修复模式中它获取断开的数据库再次运行通过只删除已损坏的页。Eseutil 应永远不会用于恢复数据。如果您执行运行 eseutil/p 命令,您也必须运行脱机碎片整理 (eseutil/d),并且您必须运行 Isinteg-测试 alltests-修复 命令来将数据库还原到一致状态。

逻辑损坏

逻辑损坏是诊断和修复物理损坏比,因为逻辑损坏是不可预知的并且通常由软件错误引起的困难得多。通常,它要求来提醒您逻辑损坏问题。(逻辑损坏是非常少见,在 Exchange Server 5.5)

防止逻辑损坏

因此不可预知逻辑损坏是没有以防止其万无一失的方法。但是,有降低风险的方法:
  • 安装最新的 service pack,Microsoft exchange Server 5.5 版尽可能快。Service pack 修复 Exchange Server 5.5 中的已知问题的一个数字。

    有关服务包和如何获取它们的其他信息请单击下面文章编号,以查看 Microsoft 知识库中相应的文章:
    241740错误的列表固定在 Exchange Server 5.5 Service Pack 3
    254682XADM: Exchange Server 5.5 SP3 后的数据库引擎的修补程序
    191014如何获取最新的 Exchange Server 5.5 服务包
  • 请确保您 Exchange Server 的计算机是安全的不会更改您的配置。
如果您发现问题,并按照这些预防措施后问题仍然存在您可能会发现新的 bug。这是否大小写尽快通知 Microsoft。
修复逻辑错误

在信息存储中或在数据库引擎,则可能会发生逻辑损坏现象。因为逻辑损坏会导致严重损坏的数据,不要忽略错误的报告。

您可以使用该 Isinteg 实用程序来签入在信息存储或签入到数据库引擎中的问题 Eseutil 实用程序中的问题。请注意您应使用这些实用程序如非绝对必要,请勿后您尝试从备份还原系统。

Isinteg 实用程序

该信息存储完整性检查程序 (Isinteg) 查找并消除公用和专用信息存储数据库中的错误。 这些错误可能会阻止启动信息存储或防止用户从登录和接收、 打开,或删除电子邮件。

Isinteg 不是为使用正常的信息存储维护的一部分 ; 它提供给在灾难恢复情况下提供帮助。例如对于您可以运行 Isinteg 时获取同步系统崩溃后更正信息存储在内存中的计数器。

Isinteg 实用程序在逻辑架构级别工作,因为它可以恢复 Eseutil 实用程序将无法恢复的数据。 这是因为在逻辑架构级别有效 Eseutil 实用程序在物理架构级别的数据可以是语义上无效。Isinteg 在事件查看器中,应用程序日志中记录的信息,以便您可以跟踪恢复进度。

Isinteg 实用程序执行两个主要任务:
  • 该修补程序从脱机备份还原后的信息存储。
  • 该方法会测试并有选择地修复信息存储区中的错误。
有关疑难解答信息存储和 Isinteg 实用程序的其他信息请单击下面文章编号,以查看 Microsoft 知识库中相应的文章:
182081XADM: 说明的 ISINTEG 实用程序

或者,请参阅 Exchange Server 5.5 光盘中 Support\Utils 目录上的 Isinteg.rtf 文档。

Eseutil 实用程序

Eseutil 实用程序检查的数据库表和记录结构和对进行碎片整理、 修复,和信息存储和目录的完整性进行检查。因为运行 Eseutil,所以在修复模式,只需删除损坏的页,只有在您尝试从备份还原后,才使用此实用程序。

有关 Eseutil 实用程序的其他信息,请单击下面文章编号,以查看 Microsoft 知识库中相应的文章:
192185XADM: 如何使用 ESEUTIL 实用程序 (Eseutil.exe) 碎片整理
或者,请参阅光盘 Support\Utils 目录中的 Eseutil.rtf 文档上 Exchange 5.5。

数据备份

由于 Exchange 服务器位于基于事务的避免执行文件级别或 $ 脱机备份的数据库文件在磁盘上的。最好的方法确保您会在系统包括还没有进行的交易记录中保留所有数据被刷新到磁盘,是执行常规的联机备份。

联机备份

联机备份,可以在您备份媒体来备份 Exchange Server 数据库,而不关闭服务器。当 Exchange 服务器正在执行的联机备份包括信息存储区的所有服务将继续正常运行。页继续更新内存中,并将它们传输到磁盘上的数据库文件、 交易记录将记录在日志文件和检查点文件继续移动。

Exchange 使用,用于跟踪的已更新的页面运行备份软件,以确保在备份过程中修改页还应备份时 (修补程序).pat 文件。有两个.pat 文件 Priv.pat 专用信息存储和公用信息存储的 Pub.pat。

当您执行联机备份时,定期检查应用程序日志中的在事件查看器中以确保备份都无法成功完成。

联机备份的过程

一个例如 Windows NT 备份的备份程序 (Ntbackup.exe) 有一个完整备份或副本备份过程中的如下:
  1. 使数据库的副本,并且其备份到磁带。
  2. 向页的一个子集.pat 文件被复制到磁带后更改该页面。
  3. 将当前 Edb.log 文件重命名为 Edb x.log,位置 x 日志文件生成数字以十六进制的格式,将创建一个新的日志生成。
  4. 在一个完整备份中备份.pat 文件和所有日志文件到磁带 (除了新的 Edb.log) 检查点之后。在一个副本备份备份所有日志文件之前和之后检查点。
  5. 在一个完整备份将会删除事务日志文件的早于该检查点。在一个副本备份不会删除任何事务日志文件。
备份程序执行增量备份或差异备份过程中的以下操作:
  1. 在一份日志文件和它们备份到磁带上一个增量备份,使。在一个差异备份将复制到磁带的数据库。
  2. 向页的一个子集.pat 文件被复制到磁带后更改该页面。
  3. 将当前 Edb.log 文件重命名为 Edb x.log,并创建新的日志生成。
  4. 之前和之后检查点包括在新 Edb.log,到磁带备份.pat 文件和所有日志文件。
  5. 在一个增量备份将会删除超过检查点的事务日志文件。在一个差异备份不会删除任何日志文件。

脱机备份

请尽量避免执行脱机备份。一个联机的备份中备份程序将为您,管理文件,但脱机备份是一个手动、 耗费人力的过程,它是容易人为错误。此外的脱机备份中,您不能验证校验和的数据库的每一页上。 联机备份是用于检测损坏和执行数据恢复单个最有价值的工具。

有关备份的其他信息,请单击下面文章编号,以查看 Microsoft 知识库中相应的文章:
191357XADM: 从完全联机备份还原单个数据库
179308XADM: 如何验证 Exchange 联机备份

属性

文章编号: 271987 - 最后修改: 2006年10月28日 - 修订: 5.1
这篇文章中的信息适用于:
  • Microsoft Exchange Server 4.0 标准版
  • Microsoft Exchange Server 5.0 标准版
  • Microsoft Exchange Server 5.5 标准版
关键字:?
kbmt kbinfo KB271987 KbMtzh
机器翻译
注意:这篇文章是由无人工介入的微软自动的机器翻译软件翻译完成。微软很高兴能同时提供给您由人工翻译的和由机器翻译的文章, 以使您能使用您的语言访问所有的知识库文章。然而由机器翻译的文章并不总是完美的。它可能存在词汇,语法或文法的问题,就像是一个外国人在说中文时总是可能犯这样的错误。虽然我们经常升级机器翻译软件以提高翻译质量,但是我们不保证机器翻译的正确度,也不对由于内容的误译或者客户对它的错误使用所引起的任何直接的, 或间接的可能的问题负责。
点击这里察看该文章的英文版: 271987
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