关于exchange的循环日志工作原理

belais2000

最近看了“浅谈exchange server邮件存储系统--原理篇”这篇文章。文章中介绍了日志的作用。按我的理解，日志可以简单描述成“承上启下”。“承上”即承接内存中的数据，“启下”后台会将数据“慢慢”的写入到edb中。所以基于这个原理，日志有效的做到了数据的完整性。。

而循环日志，其最主要的功能是节省空间，但是无法做到数据保护。对于此点我有不理解之处，查询了baidu和微软都没有找到介绍让我满意的答案，也找不到详细介绍的文档，而自我思考也没有想出个理所然。所以，将不明之处道来，恳请高手不吝指教。

循环日志只有3个log文件，而log文件是用户操作的“临时文件”，log文件会将其中的数据在不影响系统性能的情况下，在后台，把数据文件写入到数据库中。假设一个新服务器刚开始使用，按时间推移产生E000001.log，E000002.log，E000003.log 。那么在写入是不是就去覆盖E000001.log了？如果是这样的话，最开始时E000001.log中的数据是不是已经写入到数据库中？如果已经写入，那么出问题时把数据库文件复制出来，重新挂载，那么即相当于只是丢失了E000002.log，E000003.log两个文件中的数据吧。

belais2000

log文件在被覆盖前应该是会写入到数据库中的，否则数据库的文件就不完整了，。
而所以这种方式不安全是因为，如果出现硬盘损坏，那么数据库文件就不能取出了，所以只能恢复到备份时的状态。

那么，如果只是服务出现故障，而数据库没有被破坏的情况下，是不是可以把数据库重新挂载的？

belais2000

找到可一段文档 ：
http://technet.microsoft.com/zh-cn/library/bb331951(EXCHG.80).aspx
了解事务日志记录
适用于： Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007 主题上次修改时间： 2007-08-30

本主题介绍 Microsoft Exchange Server 2007 中的事务日志记录的详细信息，并对循环日志记录进行了简短的说明。

Exchange Server 事务日志记录是一个强大的可扩展存储引擎 (ESE) 灾难恢复机制，可以在数据库突然停止之后，可靠地将 Exchange 数据库还原到一致状态。还原联机备份时也使用日志记录机制。

   Exchange 事务日志记录
在对 Exchange 数据库文件执行更改之前，Exchange 会将更改写入事务日志文件。安全地记录了更改之后，即可将更改写入数据库文件。通常，在将更改安全地记录到事务日志之后但在将更改写入数据库文件之前，最终用户可以使用这些更改。

Exchange 采用针对高性能进行优化的复杂内部内存管理系统，可以有效地管理数十 GB 的数据库页缓存。因此，在正常运行期间，将更改真正写入数据库文件是一项低优先级的任务。

如果数据库突然停止，缓存的更改不会只是因为内存缓存被破坏而丢失。数据库重新启动后，Exchange 将扫描日志文件，重新构建并应用任何尚未被写入数据库文件的更改。此过程称为重播日志文件。数据库的结构使 Exchange 可以确定任何日志文件中的任何操作已应用于数据库、需要应用于数据库还是不属于该数据库。

Exchange 不是将所有日志信息写入单个大文件，而是使用一系列日志文件，每个日志文件的大小正好是 1 MB（即 1,024 KB）。如果日志文件已满，Exchange 将关闭该文件并使用序号重命名该文件。第一个已满的日志的最终文件名是 Enn00000001.log。nn 代表一个两位数，称为基本名称或日志前缀。

每个存储组的日志文件通过包含编了号的前缀（例如 E00、E01、E02 或 E03）的文件名进行区分。当前为存储组打开的日志文件简单地命名为 Enn.log — 在已满并关闭之前不包含序号。

检查点文件 (Enn.chk) 跟踪 Exchange 将记录的信息写入数据库文件的进度。每个日志流有一个检查点文件，每个存储组有各自的日志流。在一个存储组内，所有数据库共享一个日志流。因此，单个日志文件通常包含多个数据库的操作。

日志文件以十六进制的形式进行编号，所以，E0000000009.log 之后的日志文件是 E000000000A.log，而不是 E0000000010.log。可以使用 Windows 计算器 (Calc.exe) 应用程序的“科学型”模式将日志文件序号转换为十进制值。为此，运行 Calc.exe，然后在“查看”菜单中单击“科学型”。

若要查看特定日志文件的十进制序号，可以使用 Exchange Server 数据库实用程序 (Eseutil.exe) 工具检查其文件头。每个日志文件的第一个 4-KB 页包含文件头信息，说明并标识日志文件及其所属的数据库。Eseutil /ml [日志文件名] 命令可以显示文件头信息。有关 Eseutil 的详细信息，请参阅 Eseutil。

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

前面的文件头示例中的 Checkpoint 值实际上不是从日志文件文件头中读取的，但是显示好像是从日志文件文件头中读取的。Eseutil.exe 直接从 Enn.chk 读取 Checkpoint 值，这样就不必输入单独的命令来了解检查点文件的位置。如果检查点文件已被破坏，Checkpoint 值将显示为 NOT AVAILABLE。在此例中，检查点位于当前日志文件 (0xB) 中，数字 7DC 和 6F 指示检查点在日志文件中的位置。注意，您将很少真正需要此信息。

如果检查点文件被破坏，Exchange 仍可以正确地恢复并重播日志文件。但是为此，Exchange 将开始扫描日志文件，从最早的可用文件开始，而不是从检查点日志开始。Exchange 跳过已应用于数据库的数据，并按顺序处理日志，直到遇到必须应用的数据。

通常，Exchange 扫描已应用于数据库的日志文件只需要一两秒的时间。如果日志文件中包含必须被写入数据库的操作，应用操作可能需要 10 秒到几分钟不等。平均来算，可以在 30 秒或更短的时间内将日志文件的内容写入数据库。

Exchange 数据库正常关闭时，所有未处理的数据都将被写入数据库文件。正常关闭后，将认为数据库文件集是一致的，Exchange 将其与日志流分离。这意味着现在的数据库文件是自包含的文件 — 完全是最新的。不需要事务日志即可启动数据库文件。

通过运行 Eseutil /mh 命令并检查文件头，可以判断数据库是否已干净地关闭。

对于存储组中所有已断开并且处于干净关闭状态的数据库，可以安全地删除所有日志文件，不会影响数据库。如果要删除所有日志文件，Exchange 将生成一个新日志序列，从 Enn00000001.log 开始。您甚至可以将数据库文件移动到包含现有日志文件的其他服务器或存储组，数据库会将自己附加到其他日志流。

注意：
尽管在关闭存储组中的所有数据库之后可以删除日志文件，但这样做将影响您还原早期备份并前滚的能力。当前数据库不再需要现有的日志文件，但是如果必须还原早期数据库，则可能需要这些日志文件。
如果数据库处于肮脏关闭状态，必须提供检查点之后的所有现有事务日志，才能再次装入数据库。如果这些日志不可用，则必须运行 Eseutil /p 命令修复数据库，以使数据库处于一致状态并可以启动。

警告：
如果必须修复数据库，某些数据将丢失。尽管数据丢失通常微不足道，但是可能是灾难性的。对数据库运行 Eseutil /p 之后，应通过下列两个操作完全修复数据库：首先，运行 Eseutil/d 对数据库进行碎片整理。此操作将丢弃并重建所有数据库索引和空间树。然后，在 –fix 模式下运行信息存储完整性检查程序 (Isinteg.exe)。此工具在数据库中扫描由于丢弃未处理的事务日志而产生的逻辑不一致。例如，数据库中的相互引用可能不是最新的。Isinteg.exe 尝试在尽可能减少数据丢失的情况下解决此类问题。
除了允许 Exchange 可靠地从意外的数据库停止中恢复之外，还需要通过事务日志记录创建和还原联机备份。有关创建和还原联机备份的详细信息，请参阅数据库备份和还原。

   循环日志记录
可以将 Exchange 配置为启用循环日志记录来节省磁盘空间；尽管这种方法不能作为最佳做法来建议。循环日志记录允许 Exchange 在日志文件包含的数据已被提交到数据库之后覆盖这些事务日志文件。但是，如果启用循环日志记录，则只能将数据恢复到上一次完全备份。

在 Exchange 2007 使用的标准事务日志记录中，存储组中的每个数据库事务将被写入日志文件，然后再被写入数据库。如果日志文件的大小达到 1 MB，则将重命名该文件并新建日志文件。随着时间的推移，将产生一组日志文件。如果 Exchange 意外地停止，可以通过将这些日志文件中的数据重播到数据库中来恢复事务。将第一个日志文件包含的数据写入数据库之后，循环日志记录将覆盖并重复使用该日志文件。

在 Exchange 2007 中，默认情况下禁用循环日志记录。通过启用循环日志记录，可以降低对驱动器存储空间的要求。但是，由于没有完整的事务日志文件集，所以，无法恢复上一次完全备份之后的任何数据。因此，在正常的生产环境中，建议不启用循环日志记录。

有关如何在 Exchange 2007 中启用和禁用循环日志记录的信息，请参阅如何为存储组启用或禁用循环日志记录。

   连续复制和循环日志记录
可以将循环日志记录和连续复制组合使用。在此配置中，将获得称为连续复制循环日志记录 (CRCL) 的新型循环日志记录，它不同于本主题前面介绍的 ESE 循环日志记录。ESE 循环日志记录由 Microsoft Exchange Information Store 服务执行和管理，而 CRCL 由 Microsoft Exchange 复制服务执行和管理。

启用 ESE 循环日志记录时，并不会另外生成日志文件，而需要时会覆盖当前日志文件。但是，在连续复制环境中，需要使用日志文件进行日志传送和重播。因此，启用 CRCL 时，不会覆盖当前的日志文件，并且会生成用于日志传送和传重播过程的已关闭的日志文件。具体来说，Microsoft Exchange 复制服务管理 CRCL 以维持日志的连续性，当仍然需要日志以进行复制时，日志删除程序不会删除这些日志。因此，启用 CRCL 不会对复制产生负面影响。

在 Exchange 2007 的正式发布 (RTM) 版中，支持将循环日志记录与群集连续复制 (CCR) 或本地连续复制 (LCR) 结合使用。但是，我们不建议您将它们结合使用，因为这样在还原备份后不允许进行前滚恢复。Exchange 2007 Service Pack 1 (SP1) 还允许存储组在 CCR、LCR 或备用连续复制 (SCR) 环境中启用循环日志记录。但是，基于前面提到的原因，同样不提倡这种做法。在上述任一环境中启用该功能时，启用的功能是 CRCL 循环日志记录而非 ESE 循环日志记录（也称作 Joint Engine Technology (JET) 循环日志记录）。在 CCR、LCR 或 SCR 环境中，始终应使用以下过程启用或禁用循环日志记录：

使用 Suspend-StorageGroupCopy cmdlet 挂起连续复制。
启用或禁用循环日志记录。有关如何启用或禁用循环日志记录的详细步骤，请参阅如何为存储组启用或禁用循环日志记录。
在正在为循环日志记录启用或禁用的存储组中卸除和装入数据库。
使用 Resume-StorageGroupCopy cmdlet 恢复连续复制。
对于 LCR 环境中的存储组来说，在运行 Enable-StorageGroupCopy cmdlet 为某个存储组启用 LCR 之前，必须在该存储组中卸除然后再装入数据库，以确保 Microsoft Exchange Information Store 服务检测并使用当前循环日志记录设置。尽管 Microsoft Exchange Information Store 服务要求卸除然后再装入数据库来检测并使用该配置更改，但 Microsoft Exchange 复制服务可以动态检测并使用该配置更改，无需重新启动。因此，如果没有执行前一过程，那么，在 Microsoft Exchange 复制服务认为循环日志记录关闭（或打开）而 Microsoft Exchange Information Store 服务认为该循环日志记录处于相反状态的情况下，数据库会关闭。这可能导致日志文件被提前截断。

钉子

简单的来说，日志是对数据库操作的记录，当数据库出错或是还原时，可以通过回滚这些日志来还原。如果你启用循环日志，也就是把以后还原的后路给断了，所以微软不建议使用循环日志。