Exchange Server 2003 中的 Exchange 事务日志记录

  • 项目

 

上一次修改主题： 2005-05-23

Microsoft® Exchange Server 事务日志记录是一种强大的灾难恢复机制，设计用于在数据库突然发生停止时，将 Exchange 数据库可靠地还原到一致的状态。还原联机备份时也可使用日志记录机制。

在对 Exchange 数据库文件进行实际更改之前，Exchange 会将更改写入事务日志文件。安全记录一个更改之后，可将其写入数据库文件。

通常在将更改安全写入事务日志之后最终用户即可使用这些更改，直到将其写入数据库文件为止。Exchange 使用一个复杂的可获得高性能的内部内存管理系统。在正常操作期间，以物理方式向数据库文件写入更改是低优先级的任务。Exchange 可以有效管理超过 1 GB 数据库页的缓存。此缓存包括从数据库读取的用于满足客户端请求的页，以及最终将被写回数据库文件的已更改的页。


如果数据库突然停止，已缓存的更改将不会仅因为内存缓存受到破坏而丢失。重新启动数据库时，Exchange 将扫描日志文件，并重建和应用尚未写入数据库文件的任何更改。此过程称为“重播”日志文件。数据库的构建方式使 Exchange 能够确定日志文件中的任何操作是否已应用到数据库、需要应用到数据库，或者不属于数据库。

与将所有的日志信息写入单个大型文件不同，Exchange 使用一系列日志文件，每个日志文件的大小正好为 5 MB。如果日志文件已满，Exchange 会将其关闭，并使用序号对其重命名。所填充的第一个日志的名称以 Enn00001.log 结束。nn 是指称为基名称或日志前缀的两位数字。

Exchange 服务器至多可以有四个存储组，每个存储组的日志文件由带有经过编号的前缀（例如，E00、E01、E02 或 E03）的文件名进行区分。存储组当前打开的日志文件只命名为 Enn.log — 在其已满或关闭之前该日志文件不具有序号。

检查点文件 (Enn.chk) 将跟踪 Exchange 向数据库文件写入记录的信息所执行的进度。通常，在繁忙的数据库上，检查点将比当前打开的日志落后三或四个日志文件。每个日志流都有一个检查点文件，并且每个存储组有一个单独的日志流。在单个存储组中，所有的数据库共享单个日志流。因此，单个日志文件通常包含对多个数据库的操作。

日志文件以十六进制形式编号，因此 E0000009.log 后的日志文件是 E000000A.log，而不是 E000010.log。可以使用“科学记数法”模式中的 Windows Calc.exe 应用程序，将日志文件序号转换为十进制的值。
若要执行此操作，请运行 Calc，然后在“视图”菜单上单击“科学记数法”。

还可以通过使用 Eseutil.exe 检查给定日志文件的日志文件头，查看其十进制序号。每个日志文件的第一个 4 KB 页包含的头信息说明并标识日志文件和其所属的数据库。Eseutil /ml [log filename] 命令显示的日志文件头如下所示：

Base name: e00

Log file: e00.log

lGeneration: 11 (0xB)

Checkpoint: (0xB,7DC,6F)

creation time: 12/30/2002 05:07:12

prev gen time: 12/27/2002 13:38:14

Format LGVersion: (7.3704.5)

Engine LGVersion: (7.3704.5)

Signature: Create time:12/27/2002 12:39:26 Rand:334208663 Computer:

Env SystemPath: D:\exchsrvr\mdbdata\

Env LogFilePath: D:\exchsrvr\mdbdata\

Env Log Sec size: 512

Env (CircLog,Session,Opentbl,VerPage,Cursors,LogBufs,LogFile,Buffers)

( off, 202, 10100, 1365, 10100, 384, 10240, 65421)

Using Reserved Log File: false

Circular Logging Flag (current file): off

Circular Logging Flag (past files): off

1 D:\exchsrvr\mdbdata\priv1.edb

dbtime: 44889 (0-44889)

objidLast: 242

Signature: Create time:12/27/2002 12:40:16 Rand:334252058 Computer:

MaxDbSize: 0 pages

Last Attach: (0xA,199,FB)

Last Consistent: (0xA,198,8A)

2 D:\exchsrvr\mdbdata\pub1.edb

dbtime: 29645 (0-29645)

objidLast: 284

Signature: Create time:12/27/2002 12:43:23 Rand:334432355 Computer:

MaxDbSize: 0 pages

Last Attach: (0xA,199,1AE)

Last Consistent: (0xA,198,8A)

Last Lgpos: (0xb,9BF,10A)

数据库文件和检查点文件具有类似的头信息。您可以使用不同的 Eseutil.exe 命令开关检查每种类型的头信息：

  • /ml 显示日志文件头。
  • /mh 显示数据库头和流式数据库文件头。
  • /mk 显示检查点文件头。

使用错误的开关显示头信息（例如，对数据库头使用 /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，因此最终日志文件名是 E000000B.log。

以上显示的检查点值并非实际读取自日志文件头，但可以如此显示。Eseutil.exe 直接从 Enn.chk 读取检查点值，这样您无需输入一个单独的命令就可以知道检查点的位置。如果检查点文件已破坏，则检查点值为 NOT AVAILABLE。此时，检查点位于当前日志文件 (0xB) 中，数字 7DC 和 6F 指示检查点在日志文件中行进的距离 — 这是有趣的信息，但在实际中几乎不需要此信息。

如果检查点文件受到破坏，Exchange 仍可以恢复并适当重播日志文件。但若要执行此操作，Exchange 将从最旧的日志文件开始扫描，而不是从检查点日志开始扫描。Exchange 将跳过已应用到数据库的数据，并按顺序扫描日志，直至找到需要应用的数据。

通常，Exchange 需要一到两秒的时间扫描一个已应用到数据库的日志文件。如果日志文件中存在需要写入数据库的操作，则需要 10 秒到几分钟的时间应用这些操作。平均而言，可以在 30 秒或更短时间内将一个日志文件的内容写入数据库。

Exchange 数据库正常关闭时，所有未完成的数据将写入数据库文件。正常关闭以后，数据库文件组（.edb 文件和 .stm 文件）被视为是一致的，Exchange 会将其从日志流分离。这表示数据库文件现在已处于自包含状态 — 已经完全最新。启动数据库文件时不需要事务日志。

通过输入 Eseutil /mh 命令并检查文件头，可以了解数据库是否已干净关闭。在 Exchange 2000 Service Pack 1 及更高版本中，头信息中的某一行将显示“状态：干净关闭”或“状态：异常关闭”。在此 Exchange 版本之前，相同的状态被报告为“状态：一致”或“状态：不一致”。

当一个存储组中所有的数据库都已断开连接，并且处于“干净关闭”状态时，可以安全删除所有的日志文件，而不影响数据库。如果您要删除所有的日志文件，Exchange 将生成以 Enn000001.log 开头的一个新日志序列。甚至可以将数据库文件移动到带有现有日志文件的其他服务器或存储组，并且数据库会将自身附加到其他日志流。

note注意：
尽管在关闭存储组中的所有数据库之后可以删除日志文件，但此操作将影响还原较旧备份和“前滚”的能力。当前数据库不再需要现有的日志文件，但在必须恢复较旧数据库时它们可能是必需的。

如果数据库处于“异常关闭”状态，则在再次装入数据库之前，从检查点向前的所有现有事务日志必须存在。如果这些日志不可用，则必须使用 Eseutil /p 修复数据库，使其保持一致并准备启动。

Caution警告：
如果必须修复数据库，某些数据可能会丢失。数据丢失通常影响不大，不过也可能具有灾难性影响。在数据库上运行 Eseutil /p 之后，应通过其他两步操作完成数据库的修复。
  1. 运行 Eseutil /d 对数据库进行碎片整理。此操作将丢弃并重建所有的数据库索引和空间树。
  2. 以 –fix 模式运行信息存储完整性检查器 (Isinteg.exe) 工具。此工具将扫描数据库，以便确定是否存在由丢弃未完成的事务日志造成的逻辑不一致。例如，数据库中可能存在相互不是最新的引用。Isinteg.exe 尝试在尽可能减少数据丢失的情况下改正这些问题。

除了使 Exchange 从意外的数据库停止进行可靠地恢复以外，事务日志记录对于进行和还原联机备份也具有重要作用。有关该过程的详细信息，请参阅 Exchange 联机备份在 Exchange Server 2003 中的工作原理。