邮件服务器Exchange Server 2000日志文件可以删除吗？急!

微软Exchange 2000的备份与恢复
我们应该理解，备份和恢复程序可以允许管理员有效的进行当出现损耗或者灾难的时候所要进行的意外的计划。本文将描述在 Microsoft® Exchange® 系统中基础性的交互作用和描述使用VERITAS NetBackupTM for Exchange来简化日常备份，恢复重要数据，使损失最小化的作用。

--------------------------------------------------------------------------------
任何一个计算环境都需要在损耗或灾难发生后恢复数据或整个系统的能力。有规律的备份将为成功的恢复作出显著的贡献。Microsoft® Exchange® 2000的备份和恢复程序提供的机制可以使用户在Exchange的环境下保持系统的持续及最小化的中断。 VERITAS NetBackupTM for Exchange是用于备份和恢复Exchange 2000的数据库和邮件箱的。
了解微软Exchange 2000 环境
我们应该理解Microsoft Exchange 2000和Microsoft Windows® 2000 Active Directory® 之间的交互作用可以使的Exchange 2000环境下的维护和恢复变得非常容易。同样的，我们应该理解数据库文件，处理记录和补丁还有检查文件的作用是帮助管理员们从失败或从特定的时间点来恢复数据。
Active Directory 和Exchange 2000 服务器
在活动目录里，域或者森林结构作为一个整体拥有所有的对象。如果一个单独的域控制器被删除了，该目录下不会有任何目标丢失（除非该服务器是现存的该域的最后一个域控制器）。 活动目录对象是作为剩余的域控制器的拷贝而存在；一个域里的每一个域控制器都是所有其他的完整的备份。
Exchange 2000 需要连接到储存在Windows 2000 活动目录里的对象。因此，经常对活动目录进行备份和额外的域控制器对于Exchange 2000环境的生存是至关重要的。有时候管理员需用调用一些旧的信息，比如他们不小心删除了一个重要的目录或者是安装了一个没用的程序。在这种情况下，活动目录的早期备份可以帮助恢复这些信息。活动目录提供了权威的修复能力。
即使是最小的Windows 2000环境也应该有至少两个域控制器来提供两个活动目录数据库的备份。更大的机构里在每个域下应该有不少于三个域控制器来提供冗余。
正确的执行备份后将把每一个域的活动目录拷贝到一个安全的位置。在对活动目录有明显的改动之前或者之后至少对每一个域进行一次备份，例如安装Exchange 2000。
如果有多于一个的活动目录的备份，那么在灾难恢复工作中将会大大获益。目录之一的损坏并不会中断对客户的服务；因此，恢复过程就不是一个紧急的过程。管理员还可以获得一些恢复的选项。他们可以从一个备份中恢复，重建该服务器并把该服务器再次作为域控制器加入到域中，或者增加一个第三方服务器作为域控制器的替代。
Exchange 2000 数据库文件
微软Exchange 2000 兼容多达20种数据库存储，每两个数据库文件的组合又一种edb后缀的文件来验证。
在一般的工作中，数据库文件本身永远不是最新的。存储服务将管理一个巨大的内存里的缓存空间来储存数据同时周期性的把修改的数据记录到磁盘上。可是，这种方法导致了正常激活的数据库文件与更新磁盘上的数据库文件之间的延迟。如果一个突然的系统错误发生那么这个延迟将危及数据库的完整性。
把数据存储到处理记录文件将确保修改的数据记录到磁盘上。这一技术比更新数据库要快（这将导致更新多个索引，随机磁盘读取和其他问题）同时允许Exchange在高负荷下保持传输的高性能。
当存储服务正常停止的时候，它将把所有数据库缓存中被修改的数据存储到数据库文件中，在服务中止以前使得文件处以一个一致的状态。如果存储服务非正常停止了（崩溃），数据库将保持在一个不一直或者未知的状态，但是处理记录将包括所有恢复数据库所需要的信息。对数据库重放这些记录将使它回到一个一致的状态- 就好象正常关机后所达到的情况。
Exchange 2000 流数据库
流数据库是Exchange2000的新功能。在Exchange5.5下，每一个来自Internet的信息都被转化到Messaging Application Programming Interface （MAPI）格式，这要求将Multipurpose Internet Mail Extensions （MIME）内容转换成一种Exchange 数据库可以索引，管理和识别的格式。Exchange2000将收到的Internet信息存储在流数据库里。这种文件有一个stm的后缀，同时是edb 数据库文件的一个合作文件。
这种stm文件包括原始内容；它并不包括索引和属性。当一个信息到达的时候，Exchange2000只是将信息索引和管理到edb文件中。 Exchange2000 接下来将记录该stm文件的位置，使用户可以到那里去阅读该信息。这种方法将使Internet信息更快的传输，同时减少信息格式的转换。edb和stm 文件是组成一套的并且应该被作为一个单独的文件来对待。如果一个管理员在备份edb文件时丢失了stm文件，那么该edb文件就是没用的了。
Exchange 2000 处理记录
微软Exchange数据库使用处理记录来接受，跟踪和维护数据。所有处理工作都首先被写入处理记录和内存，然后最后记录到数据库。处理记录可以在数据库失败或损坏后帮助恢复信息存储数据库。

信息存储包括两个分开的数据库，但是处理记录是被保存在一个单独的组里。因为所有处理首先被写入edb.log文件然后再写入数据库，实际的数据库可以是一个在处理记录文件里没有被提交的处理和实际的edb数据库文件的混合体。当edb.log文件被数据充满的时候（大约在5MB），它将被改名然后一个新的edb.log文件被建立。当edb.log文件被改名，被改名的记录文件被保存在相同的子目录下。被改名的记录文件使用一个连续的数字顺序来命名（例如： edb00014.log， edb00015.log，然后使用十六进制继续下去）
当服务正常的中止时记录在记录文件里的处理将被提交到各自的edb文件。记录文件不能被人工的清除；最好通过备份操作来清空记录文件。
与相应的Exchange在线备份磁盘相结合，记录文件可以让管理员能够掌握当天的处理同时可以不丢失任何信息的恢复一个数据库。
处理记录没有长期的价值；只有当它们是在最近一次在线备份时创建的才是有用的。单独把处理记录文件备份或者恢复，而不考虑用它们相关联的数据库，那样是毫无意义的。
在备份中的处理记录： 在备份的过程中提交了的处理记录将被微软Exchange删除。既然这些记录已经被提交到数据库文件同时他们已经被写入到备份媒介中，那么这些记录就不在需要了。如果处理记录文件变的损坏了，管理员在数据库恢复后将失去将之前移的能力。
在恢复中的处理记录： 在恢复Exchange2000 数据库时管理员有两个选择。
首先，他们可以保存现有的记录文件同时覆盖任何存在的记录文件。在文件被恢复，服务启动以后，数据库将把处理提交到恢复的记录中。如果在服务器上存在与恢复的记录文件编号相邻的记录文件，那么那些处理也将被提交。如果记录文件的文件名的编号顺序有间隔出现，那么间隔之前的记录文件没有任何处理会被提交。
处理记录完好无损而数据库需要恢复的情况是非常有用的。通过保存的记录文件，微软Exchange服务器可以恢复到错误发生的点而不是上一次全部或增量备份的时候（微分增量备份或累计增量备份）
第二个选择是删除现存的处理记录。在很多情况下，例如恢复信息存储到另一个服务器，或者是恢复到早先的日期而不重新提交所有仍然在磁盘上的记录，或者是执行一次全面恢复，需要删除现存的处理记录。
Exchange 2000 数据库补丁文件
数据库补丁文件可以在备份的过程中操作处理写入到数据库。如果一个处理导致了edb文件部分更新，但该文件已经被备份了，这时候它将被写入到该数据库的补丁文件中。只有在备份的过程中补丁文件才会存在。在微软Exchange服务器进行恢复的过程中，补丁文件将把在备份过程中的处理更新到恢复的数据库文件中去。
检查文件
检查文件可以恢复，或者运行从处理记录到edb文件的数据。检查点是记录在edb.chk文件中用来指明那些记录被提交了。不管是什么时候数据从记录文件写入到edb文件，该edb.chk文件将更新一个信息来说明该处理已经被成功的提交到了相关的edb文件。在恢复的过程中，Exchange将通过读取 edb.ch文件或者直接读取处理记录文件（在这种情况下不需要edb.chk文件）判断哪些处理还没有被提交。
信息存储和目录服务使用各自的edb.chk文件，它们在启动的时候读取该文件。他们可以使用处理记录来运行任何没有被提交到edb文件的记录。举例来说，如果一个Exchange服务器发生了损耗，而处理被记录到了处理记录而不是数据库文件，Exchange将尝试在启动的时候通过自动记录从记录文件到数据库文件的处理来进行恢复。
备份Exchange2000
管理员可以备份Exchange服务器上的所有数据库，或者一个指定的数据库组，或者存储集团。管理员同样可以选择恢复一个Exchange服务器上的所有信息或者恢复一个单独的数据库或者存储集团。
尽管管理员可以个别的备份所有的数据库，但是建议一次备份全部的存储集团。个别的数据库备份需要多个备份记录文件，同时当备份或者恢复Exchange2000数据库时，管理员不能在一个单独的存储集团里运行多个备份或者恢复操作。
以下步骤将在一次全面备份中发生：

将数据库文件写入备份媒介。
在备份过程中创建补丁文件来更新数据库。
将处理记录写入备份媒介。
将补丁文件写入备份媒介。
删除已提交的处理记录。
图1描述了一次Exchange2000数据库备份的过程。

图1、 Exchange 2000 数据库备份流程
备份类型
VERITAS NetBackup可以实现全面的，拷贝，增量的，和微分的备份。数据的重要性决定了备份的类型。在数据存储，性能和所需时间上每一种备份类型都具有优点和缺点。两种常见的方式是在线和离线。
在线备份： 在线备份允许数据库在数据备份的过程中继续运行。一次在线备份不会影响用户或中断操作。一次在线备份可以是部分的也可以是全部的。全面备份将拷贝数据库中的所有东西，而部分备份只拷贝记录文件。
一次在线的全面的备份是备份的首选类型。一次全面的备份将拷贝Exchange的数据库文件和Exchange的记录文件。它将删除包含已经提交到服务器数据库的处理的处理记录文件。从全面备份来进行恢复一般只涉及到一种备份类型。
离线备份： 一次离线备份让管理员可以保存一份数据库的拷贝而不拷贝记录文件。一次离线备份通常是第二位的选择。管理员必须在执行备份前停止数据库，在这一过程中用户将不能收发邮件。
Exchange 2000配置文件的备份
除了备份Exchange数据库，管理员还应该备份所有的关键性数据例如用户信箱的内容和运行Exchange服务器所必需的配置数据。管理员还应该经常性的备份Exchange2000的配置数据，包括下列：

Web存储系统数据库和支持文件
活动目录
系统状态，包括微软Internet信息服务（IIS）数据库，其中包含Exchange2000所要使用的协议的信息。
备份的验证和确认
恢复数据和服务器的能力取决于备份的质量；因此，确认备份程序的成功是非常重要的。对于完全的错误承受，根据情况和数据的级别来确认一次备份程序。
恢复Exchange2000
不同的灾难都可以折磨Exchange环境。例如管理员也许需要恢复一个被删除或损坏的信箱，或者他们需要恢复一个或更多的数据库或是存储集团。如果一个严重的灾难发生了，管理员也许需要使用/disasterrecovery开关来恢复整个Exchange服务器。这个程序包括确认活动目录仍然完好，恢复Exchange2000系统状态和恢复所有Exchange数据库。
管理员可以使用VERITAS NetBackup从备份中来恢复被损坏的数据库，存储集团，或者整个Exchange服务器。
Exchange 2000 数据库的恢复
一次恢复加上处理前移是在一次中断后恢复Exchange2000数据库的最简单和某些情况下唯一的方法。图2描述了恢复一个Exchange2000数据库的过程。

图 2. Exchange 2000 数据库恢复流程
管理员不应该同时恢复微软Exchange Mailbox和微软Exchange服务器。如果一个管理员停止了Exchange服务来恢复Exchange服务器的数据库，那么信箱对象的恢复将会失败。或者，如果恢复Exchange信箱在恢复Exchange数据库开始之前完成了，那么恢复数据库将清除被恢复的信箱对象。
在一个单独的存储集团里多个数据库的恢复
管理员同时只可以运行一次的备份或者恢复程序在一个特定的存储集团上。多个同时发生的备份和恢复程序必须运行在多个存储集团。因此：

在一个给定的存储集团内管理员一次只能恢复一个备份的数据库。
管理员可以同时恢复和备份多个存储集团。
当在同一个存储集团里恢复多个数据库时，在进行下一个数据库的恢复前首先应该设置好刚刚恢复的数据库。举例来说，数据库A，B，C是在同一个存储集团里并且被一起备份。要恢复数据库A，只需要设置恢复数据库A。如果一个管理员决定恢复数据库B，数据库A必须首先被恢复并设置好。一旦数据库A被设置好，管理员可以开始恢复数据库B。要同时恢复两个数据库，管理员必须首先标志数据库A和数据库B用于恢复。
恢复的过程将创建一个Restore.env文件在临时目录里，而当数据库成功的设置好以后该文件将被删除。如果管理员选择恢复数据库A和B，这个 Restore.env文件将包含两个数据库的信息。但是，当管理员个别的恢复数据库时，对应数据库A的Restore.env文件必须在数据库B恢复程序开始以前完成处理。
全服务器恢复
一个全服务器恢复涉及到恢复Exchange2000服务器或Windows 2000服务器或者两者都涉及。在Exchange2000下的多个存储集团和数据库将使恢复过程变得复杂。
当进行一个全服务器恢复时，管理员首先必须在恢复Exchange数据以前，在灾难恢复模式下重新安装微软Exchange2000服务器。灾难恢复模式将从活动目录里提取信息来正确的重新安装Exchange。
管理员应该知道恢复不同类型的服务器所需要的程序。Exchange2000服务器可以指定一些特定的任务，例如运行关键管理服务器（KMS）或是站点复制服务（SRS）。这些服务可以在Exchange服务器启动并运行后重建。
需要注意的是，Exchange服务器运行在不同的模式下也许需要一些额外的恢复步骤。举例来说，恢复一个Exchange2000集群服务器需要比恢复一个单独的Exchange2000成员服务器要多几个步骤。
使用NetBackup for Exchange
VERITAS NetBackup利用微软Exchange API 来在线执行对微软Exchange信息存储和目录以及所有相关的处理记录文件的备份工作。NetBackup支持先进的Exchange前进或回溯操作，因此管理员可以恢复Exchange数据库到任何时间，这是对于大范围的Exchange环境的一个关键性的要求。
要使用NetBackup for 微软Exchange服务器，管理员必须添加至少一个微软Exchange服务器级到NetBackup来定义对于该级的合适的时间安排。管理员同时必须设置NetBackup来执行对于个别的信箱和目录的备份和恢复任务。
微软Exchange服务器级的大部分要求和文件系统备份的要求一样。关于设置指令的细节请参考NetBackup 3.4系统管理员指南 for Windows NT/2000。
NetBackup for Exchange 的功能
以下部分将介绍NetBackup for Exchange的一些功能。
在线备份。 管理员不需要在备份微软Exchange服务器数据和处理记录时让服务器离线。这一能力确保了在微软Exchange服务器进行备份时微软Exchange服务和数据的可用性。
缩短的备份时间。管理员可以执行一次全面的或是增量的备份（微分增量备份或是累计增量备份）。一次全面备份需要相当长的时间，所以管理员很少进行它。作为过渡，自从上次全面备份后的更新可以被很快的备份起来，而增量备份可以只备份处理记录。当失败发生时，全面的和增量的备份将被恢复。
在恢复过程中，微软Exchange服务器可以更新数据库，提交被记录的处理到数据库。在微软Exchange服务器完成恢复后，系统将把状态调回到最后一次增量备份执行时的情况。
微软Exchange服务器备份支持。 NetBackup支持所有的微软Exchange服务器备份方法：全面备份，累计增量备份，微分增量备份，和拷贝。
中央管理。 管理员可以在一个中央的位置上定义，备份，和恢复微软Exchange服务器或其他的NetBackup客户机。
媒介管理。 NetBackup主服务器支持微软Exchange服务器备份所直接存储到那些很广泛的多种多样的存储设备上。
自动备份。管理员可以通过网络确定对本地或远端的客户机自动的，无人的备份的时间表。这些备份可以是全面的也可以是增量的并且完全是被NetBackup服务器在中央位置进行管理的。管理员也可以手动备份客户机。要确保备份的一致和准确，要在备份数据库前经常检查数据库的一致性。
恢复任务。 只需要几个简单的操作，管理员就可以使用NetBackup客户端来浏览微软Exchange服务器的备份并选择恢复哪些。
个别的信箱备份和恢复。 管理员可以在个别的信箱和目录上执行备份和恢复操作。这一功能包括下列能力：

对个别信箱和目录的定时备份。
对个别信箱和目录的用户直接备份。
基于服务器或客户端的个别信箱，目录或信息的恢复。
恢复不同的信箱和目录。
不同的客户端恢复个别的信箱，目录或信息。
备份的软件压缩。
备份的多个数据流。
The Exchange Messaging API （MAPI）允许VERITAS NetBackup for Exchange执行对Exchange信箱的"砖块级"备份。这个能力使得恢复个别信箱，目录，或电子邮件信息非常容易。管理员不再需要依靠一个备用的服务器来恢复个别的Exchange信息。
简单的数据保护
我们必须理解，备份和恢复过程和系统的其他元素是交互作用的，来允许管理员执行高效的针对损耗或灾难的意外计划。在产品环境里执行任何备份解决方案之前，要在测试实验室环境下测试所有提议的备份解决方案来配合现存的产品环境。
VERITAS NetBackup for Exchange这样的工具将使日常备份变的简单，帮助公司们恢复重要数据，使Exchange环境的中断可能最小化。VERITAS提供自由的选择和简单化的管理，提供可以确保在多个应用程序，服务器，存储器或是网络之间传输的数据的连续的可用性。
VERITAS 软件有限公司 是一家数据可用性软件解决方案的领先的提供商，它可以使客户保护和访问他们的关键性商务数据

可以删除啊！这是日志文件，只是记录了Exchange Server 2000邮件服务器的活动情况。放心的删吧～！

可以删除啊！这是日志文件，只是记录了Exchange Server 2000邮件服务器的活动情况。

部分日志绝对不能删除，否则DB会有问题。而那些已经提交的db的log，其实可以手工delete掉（普通删除文件的方法）。当备份出现问题，磁盘容量又不够时，该方法非常有用。
删除日志文件请千万小心。
还有种方法，就是先将日志设成循环日志，exchange会强制提交所有日志，同时会删除没用的日志文件。不过记得好像要重启service。
以下KB就是帮助用户如何确定哪些日志已经提交，可以删除。

XADM: Using Eseutil to Determine Which Logs Have Been Committed
View products that this article applies to.
Article ID : 182961
Last Review : October 28, 2006
Revision : 4.3
This article was previously published under Q182961
On This Page

SUMMARY

MORE INFORMATION

Exchange Server 5.5

Exchange 2000 Server
SUMMARY
You can use the Eseutil utility to view the contents of the checkpoint file to determine which log files have been committed to an Exchange database.
Back to the top

MORE INFORMATION
Exchange Server 5.5
The information in this section applies to all three Exchange Server 5.5 databases: • Dir.edb
• Priv.edb
• Pub.edb
To display the Edb.chk (checkpoint) file on the screen, run the following command from a command prompt:
eseutil /mk edb.chk | more
If you do not run eseutil from the folder where the Edb.chk file is located, you must provide the full path to the file.

In Exchange Server 5.5, there is one checkpoint file for each set of log files. There will be one Edb.chk file for the directory and one for the information store. (Priv.edb and Pub.edb share the same log files and checkpoint file.)

The information that is displayed is similar to: Microsoft(R) Exchange Server Database Utilities

Version 5.5

Copyright (C) Microsoft Corporation 1991-1997. All Rights Reserved.

Initiating FILE DUMP mode...
Checkpoint file: edb.chk

LastFullBackupCheckpoint (8,615,203)
Checkpoint (22,6485,399)
FullBackup (8,615,203)
FullBackup time:3/6/1998 11:52:16
IncBackup (0,0,0)
IncBackup time:0/0/1900 0:0:0
Signature: Create time:2/24/1998 14:23:47 Rand:24842 Computer:
Env (Session, Opentbl, VerPage, Cursors, LogBufs, LogFile, Buffers)
( 168, 25200, 4440, 8400, 84, 10240, 8045)

Operation completed successfully in 0.20 seconds.

Take the first number in the parentheses for the Checkpoint field and convert it to hexadecimal. The hexadecimal number is the file name of the first uncommitted log for the appropriate directory. Circular logging works by deleting all log files with generations that are lower than the generation in the checkpoint, for example:
Checkpoint (22,6485,399) = EDB00016.LOG
This syntax applies for most other fields in the dump file (LastFullBackupCheckpoint, FullBackup, IncBackup, and other fields).
Back to the top

Exchange 2000 Server
In Exchange 2000, there is one checkpoint file for each storage group and one for the directory. When you try to identify the last committed log file for a storage group, note that the storage group prefix applies to the checkpoint file and to all of the log files. For example, the default first storage group's checkpoint file name is E00.chk, and its log files are E00xxxxxx.log (where xxxxx is the hexadecimal sequence number of the log file).

To display the Exx.chk (checkpoint) file on the screen, run the following command from a command prompt (from the Exchsrvr\Bin folder):
eseutil /mk the_full_path_to_the_checkpoint_file
For example, you may run the following command:
eseutil /mk "C:\Program Files\Exchsrvr\MDBDATA\E00.chk"
Note that you must use the quotation marks if there is a space in the path to the checkpoint file.

The output of this command is similar to: Microsoft(R) Exchange Server(TM) Database Utilities
Version 6.0
Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved.

Initiating FILE DUMP mode...
Checkpoint file: C:\Program Files\Exchsrvr\MDBDATA\E00.chk

LastFullBackupCheckpoint: (0x0,0,0)
Checkpoint: (0x6A,1119,3D)
FullBackup: (0x0,0,0)
FullBackup time: 00/00/1900 00:00:00
IncBackup: (0x0,0,0)
IncBackup time: 00/00/1900 00:00:00
Signature: Create time:09/24/2001 17:10:26 Rand:522553071 Computer:
Env (CircLog,Session,Opentbl,VerPage,Cursors,LogBufs,LogFile,Buffers)
( off, 202, 30300, 1365, 10100, 128, 10240, 97940)

Operation completed successfully in 1.192 seconds.

Take the first number in the parentheses for the Checkpoint field. The hexadecimal number is the file name of the first uncommitted log for the appropriate database; in this example:
Checkpoint (0x6A,1119,3D) = E000006A.log
Back to the top

部分日志绝对不能删除，否则DB会有问题。而那些已经提交的db的log，其实可以手工delete掉（普通删除文件的方法）。当备份出现问题，磁盘容量又不够时，该方法非常有用。
删除日志文件请千万小心。
还有种方法，就是先将日志设成循环日志，exchange会强制提交所有日志，同时会删除没用的日志文件。不过记得好像要重启service。
以下KB就是帮助用户如何确定哪些日志已经提交，可以删除。

XADM: Using Eseutil to Determine Which Logs Have Been Committed
View products that this article applies to.
Article ID : 182961
Last Review : October 28, 2006
Revision : 4.3
This article was previously published under Q182961
On This Page

SUMMARY

MORE INFORMATION

Exchange Server 5.5

Exchange 2000 Server
SUMMARY
You can use the Eseutil utility to view the contents of the checkpoint file to determine which log files have been committed to an Exchange database.
Back to the top

MORE INFORMATION
Exchange Server 5.5
The information in this section applies to all three Exchange Server 5.5 databases: • Dir.edb
• Priv.edb
• Pub.edb
To display the Edb.chk (checkpoint) file on the screen, run the following command from a command prompt:
eseutil /mk edb.chk | more
If you do not run eseutil from the folder where the Edb.chk file is located, you must provide the full path to the file.

In Exchange Server 5.5, there is one checkpoint file for each set of log files. There will be one Edb.chk file for the directory and one for the information store. (Priv.edb and Pub.edb share the same log files and checkpoint file.)

The information that is displayed is similar to: Microsoft(R) Exchange Server Database Utilities

Version 5.5

Copyright (C) Microsoft Corporation 1991-1997. All Rights Reserved.

Initiating FILE DUMP mode...
Checkpoint file: edb.chk

LastFullBackupCheckpoint (8,615,203)
Checkpoint (22,6485,399)
FullBackup (8,615,203)
FullBackup time:3/6/1998 11:52:16
IncBackup (0,0,0)
IncBackup time:0/0/1900 0:0:0
Signature: Create time:2/24/1998 14:23:47 Rand:24842 Computer:
Env (Session, Opentbl, VerPage, Cursors, LogBufs, LogFile, Buffers)
( 168, 25200, 4440, 8400, 84, 10240, 8045)

Operation completed successfully in 0.20 seconds.

Take the first number in the parentheses for the Checkpoint field and convert it to hexadecimal. The hexadecimal number is the file name of the first uncommitted log for the appropriate directory. Circular logging works by deleting all log files with generations that are lower than the generation in the checkpoint, for example:
Checkpoint (22,6485,399) = EDB00016.LOG
This syntax applies for most other fields in the dump file (LastFullBackupCheckpoint, FullBackup, IncBackup, and other fields).
Back to the top

Exchange 2000 Server
In Exchange 2000, there is one checkpoint file for each storage group and one for the directory. When you try to identify the last committed log file for a storage group, note that the storage group prefix applies to the checkpoint file and to all of the log files. For example, the default first storage group's checkpoint file name is E00.chk, and its log files are E00xxxxxx.log (where xxxxx is the hexadecimal sequence number of the log file).

To display the Exx.chk (checkpoint) file on the screen, run the following command from a command prompt (from the Exchsrvr\Bin folder):
eseutil /mk the_full_path_to_the_checkpoint_file
For example, you may run the following command:
eseutil /mk "C:\Program Files\Exchsrvr\MDBDATA\E00.chk"
Note that you must use the quotation marks if there is a space in the path to the checkpoint file.

The output of this command is similar to: Microsoft(R) Exchange Server(TM) Database Utilities
Version 6.0
Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved.

Initiating FILE DUMP mode...
Checkpoint file: C:\Program Files\Exchsrvr\MDBDATA\E00.chk

LastFullBackupCheckpoint: (0x0,0,0)
Checkpoint: (0x6A,1119,3D)
FullBackup: (0x0,0,0)
FullBackup time: 00/00/1900 00:00:00
IncBackup: (0x0,0,0)
IncBackup time: 00/00/1900 00:00:00
Signature: Create time:09/24/2001 17:10:26 Rand:522553071 Computer:
Env (CircLog,Session,Opentbl,VerPage,Cursors,LogBufs,LogFile,Buffers)
( off, 202, 30300, 1365, 10100, 128, 10240, 97940)

Operation completed successfully in 1.192 seconds.

Take the first number in the parentheses for the Checkpoint field. The hexadecimal number is the file name of the first uncommitted log for the appropriate database; in this example:
Checkpoint (0x6A,1119,3D) = E000006A.log
Back to the top

可以删除的，没问题