关于Exchange循环日志和备份（2）

前面提到过了，他是霸占磁盘空间的罪魁祸首，有些管理员一看日志文件很多的时候，于是开始删除日志文件，删到后来觉得烦琐了，于是就“启用循环日志”来减少烦琐的工作。我前面说了，你启用这个功能的话，你就可以向上帝祈求了...
　　很多刚接触Exchange的管理员会提出疑问：日志文件到底有什么用？是不是多余的？那我们来看看日志的重大作用。
　　对于一个SG来说，系统会产生一系列的日志，每个大小为5M，这些日志的扩展名为LOG，前缀一般是E00、E01……除了这些连续的日志文件外，还有一些特殊的日志文件（res1.log,res2.log,e0x.chk)，它们又有什么用呢？如果对Exchange数据做完全备份(Full Backup)的话，备份后日志文件会自动删除的，然后重新产生。老实说，十个管理员有九个对备份工作都怕怕，因此对这些日志是痛恨不已啊。我自己也做系统管理，对数据备份这个麻烦的工作的确很感冒，但是说到最后：备份工作必须做！不得不做！话题好像扯远了，呵呵...
　　那么微软在Exchange数据库系统中引入日志到底有什么作用呢？我们从以下几个方面来考察一下日志的作用：
1、作为一个企业级的邮件系统，必须要保证数据安全和完整。必须能够面对随时可能发生的意外灾难，把数据损失降低到最小。
2、必须提供高性能的邮件处理能力，对数据库中的邮件的事务操作在完成后必须马上(或是说立即)被记录在存储介质上(见前面的事务持久性说明)
3、灾难发生后，使用数据库备份恢复必须要返回到灾难发生前一刻的数据库状态(这是至关重要的！)
　　现在我们来更进一步的看一下，当用户要修改邮箱中的内容时，被修改的内容首先被提取出来放到内存中，实际的修改是发生在内存里的，这是众所周知的，当修改完成后，这些内容必须被尽快写回存储介质，这样才表示一个事务成功完成了。
　　从事务的描述中我们可以看到，事务是具有Atomic特性的，为了保证数据库的一致和完整，事务必须全部成功或全部失败，如果事务失败，则必须回滚到事务开始的状态。而当邮件在内存中修改完成后，此时事务并没有完成，因为还没有写到磁盘上。一旦系统崩溃，这些修改就丢失了。所以要确保事务修改完成，必须尽快将修改写回到数据库里去(也就是硬盘上)，这也是事务的持久性要求。
　　注意，这里说的第一时间或是尽快，是一个什么样的概念呢？如果我们直接修改EDB文件，由于EDB文件比较大，那么在硬盘上修改一个大文件，就需要花费大量的时间在等待和寻找数据存储块上(学过操作系统原理的人应该知道的)，当系统出现高负载的繁忙状态时，这将是一个非常大的瓶颈，也就无法做到“尽快”了。那怎么办呢？所以数据库系统使用了日志文件，而日志文件只有5MB大小，向这些文件写入修改肯定是很快速的，因此当内存的修改完成后，这些结果就会立即写入日志中，以保证了事务的持久性。当成功写入日志后，该事务就成功完成了(现在在硬盘上了，不会因为当机丢失了)接下来，ESE引擎会在后台慢慢将这些日志里的修改记录写回真正的数据库里去（这对用户来说已经不是那么重要了,这时候可能你的邮件都已经到对方了），这就是日志的第一个作用：确保事务在第一时间(尽可能快的)保存到非易失存储器上(磁盘上)，提供了事务持久性支持。我自己是变相的把他理解为邮件数据缓存的，不知道这样是否科学，呵呵！
　　根据上面的描述，我们看到运行中的Exchange数据库，是由三个部分组成的：
* 内存中已经完成处理还没有写会到日志里的内容（Dirt page）
* 还没有写到数据库文件里的日志内容
* EDB和STM数据库文件
　　对于第一个部分(内存中的)，一旦掉电就会丢失的，是最不安全的。而对于第二部分的内容，系统通过检查点文件（CHK）来标记哪些日志已经被写入数据库了，而哪些还没有。CHK文件类似一个指针。我们可以用“ESEUTIL /MK”来检查CHK文件里的内容，在该命令的输出中的checkpoint:<0x8,26d1,29>这样的东西就是检查点位置，它表示E0x00008的日志的页面序号已经被成功写入数据库了。大家可以自己看看。。：）
　　前面提到过，Exchange系统在出现灾难时，应该能恢复到灾难发生前时刻的状态。这是非常重要的。我在最前面就说过了“我就不相信你有做到时时备份”，但即使是最勤快的管理员，也只能在指定的预定时间内做数据备份。那么在备份完成后到灾难发生之前的这段数据该如何保护呢？是不是就任由它丢失呢？显然是不可能的。那答案是什么呢？就是日志文件。从前面对日志功能的描述中知道，任何对数据库的更改都先写入日志里，再由日志写入数据库，这样我们只要找到日志文件，就可以重新进行模拟的操作来完成备份后的数据库文件的更改了，举个例子来看先：
　　假设我在凌晨3点完成了一次FULL BACKUP，备份完成后，系统正常运行，到下午4点的时候，系统突然崩溃。我用凌晨3点的数据恢复了数据库，那么从凌晨3点到下午4点这段时间的数据哪里去找呢？这个时候就只能依赖于日志了。当完成数据库恢复后，系统会自动的跟踪到关联的日志文件，如果发现有比当前数据库还新的日志存在，系统就会自动的按照日志的顺序将更改写回到数据库中去。因此这样一来，从凌晨3点到下午4点的数据变更就被完整的恢复了。这就是日志的第二个作用：保证系统备份和恢复的完整性。当然前提是没有使用循环日志！
　　看到了吧，启用循环日志的危害是多么的大啊？备份是多么的重要啊？...如果你看到这里还执迷不悟启用循环日志的话，寡人可就要骂你#％@￥*#％!@)$％^&*(％…
　　说到这里，有人可能要问，如果数据库和日志同时损坏，如何办？答案是：你赶紧去买体育彩票吧，呵呵！我在这里也只能说“尽量避免这样的情况发生”。首先日志文件损坏的几率要远远低于数据库；第二，微软建议将数据库和日志分别存储在不同的磁盘上；第三，我是绝对相信你的Exchange服务器用了RAID的！要是这样还会同时坏，那就去买体育彩票吧，呵呵...对于管理员对日志文件的抱怨，合理的解决方法是定期做备份，虽然麻烦，但是公司付薪水给你就是让你做这个事情的。寡人再强调一次：启用循环日志是冒险的做法，当启用循环日志后，一旦系统或者数据库发生灾难，想要恢复时，你就抱头后悔或者跺脚吧！磁盘和数据谁更重要，相信你这位做系统管理的，应该很清楚的。