关于Exchange循环日志和备份.doc

关于Exchange循环日志和备份.doc 关于Exchange循环日志和备份 很多Exchange管理员都碰到一个头痛的问题:日志文件霸占磁盘空间。 磁盘空间是有限的;但是Exchange只要在运行，日志文件的产生就是无限的，虽然每个只有5M大小，但是日志文件的产量很惊人的，大部分的磁盘空间都被日志文件霸占了;微软在Exchange的时候，提供了一个启用循环日志功能，启用这个功能后，系统只会产生5个5M大小的日志文件，循环更替使用，日志文件霸占磁盘空间的问题是被解决了，不过从这一刻开始，你就向上帝祈求吧，祈求你的Exchange数据库在你的任职期间一路平安。如果有个三长两短，mount不上去的时候，你就找个地方哭吧!因为你有一段时间内的邮件丢了。 我之这样肯定说丢了邮件是因为: 第一，我就不相信你有做到时时备份; 第二，除非你很幸运，你上次备份到现在，你的Exchange没有处理过一封邮件。 第三，数据库修复或恢复是需要日志文件的，你那5个循环日志能帮你多少? 就凭借以上三个原因，我绝对是举双手双脚建议你关闭循环日志功能的。 依据一、我自己的教训与经验; 依据二、微软官方对Exchange数据库的。 具体的原因，就请你看下面的内容，以下内容是根据微软官方资料说明以及自己对Exchange Server的管理经验整理出来的，供各位参考，以便更清楚的认识Exchange Server的存储系统，以及各部分的作用。 一、IS服务和ESE的层次关系 IS服务我们一定很了解了，它是Exchange服务器中重要的服务之一，它控制着对MS(Mail Store)和PF(public Folder)的存储操作请求，如果这个服务没有启动，Exchange服务器就是名存实亡。我们也知道，Exchange服务器的存储实际上是由叫ESE的数据库引擎来管理的。这个ESE引擎是微软专门为保存非关系型数据而开发的，目前在微软的很多产品中都有广泛的应用，如:AD数据库、DHCP、文件和LOG文件组成的。在这些文件里，微软使用了B+树的内部数据结构。ESE的引擎的任务之一，就是当IS服务请求访问数据库的时候，把这些请求转化为对内部数据结构的读写访问。B+树的特点是能够对存储在硬盘上的数据提供快速访问能力。微软利用B+树作为ESE的后台结构的主要原因，就是尽可能的提高访 问数据时I/O性能。当然，这些结构对于EXCHANGE STORE来说是透明的。 另外，作为一个数据库系统，ESE有责任提供事务级别的操作的支持，并维护数据库的完整性和一致性。对数据库系统而言，我们提到事务时，一般用ACID来描述事务的特点: A - Atomic(原子的):事务必须是全或全无的操作，要么全部成功更新，要么全部不被更新。 C - Consistent(一致的):一个成功提交的事务必须使数据库处于一个一致的状态。 I - Isolated(孤立的):所有未提交的更改都必须能够和其他事务独立开来的。 D - Durable(持久的):当事务一旦提交，所做的更改必须存储到稳定的介质上，防止系统失败导致的数据库不一致。(此点非常重要!) Atomic这个词,我查字典是原子的;原子能的;极微的解释，好像这里用这样很不大对劲，感觉解释为绝对的比较好懂。 二、EXCHANGE 2000/2003存储系统的新特点 在EX5.5中，ESE的版本为ESE97，而在EX2000/2003里，ESE版本已经升级ESE98了。ESE引起在以下方面得到了改进: * I/O性能进一步提高和优化; * 对日志文件增加了计算校验操作; * 提高了ESEUTIL等工具的维护速度; 而IS也在以下方面有了更新: * 在每个SERVER上提供最多5个SG(Storage Group)支持; * 数据库STM文件格式的引入，提高了INTER邮件的性能; * 的关系 常有人问，EDB文件是数据库，那STM文件是做什么用的?可以删除吗? 在EX5.5里，只有EDB文件，因为在EX5.5发布时，微软主推的是内部邮件系统，因此其主要协议为MAPI，这是微软的私有邮件协议，EDB文件是专门为此协议优化过的。因此在EX5.5中，为了支持INTER邮件，必须在每次处理INTER邮件时，做一个格式转换。这显然带来了性能的损失。 在EX2000里，微软加大了对INTER邮件的支持，这就是STM文件的。MAPI格式是RPC和二进制标准的，而STM是纯文本加上一些MIME编码格式，这样的区别使得它们不可能存储在同一数 据库里。因此EX2000中，微软开始使用EDB和STM两个文件来分别保存两种格式的邮件。并且在两个文件之间建立了引用和关联。对于用户来说，它的邮箱实际上是跨越了EDB和STM文件共同组成的。另外，需要注意的是，EDB文件中还保留着用户的邮箱结构。所以EDB文件更加重要。那么EDB和STM是怎么协同工作的呢?我们以几个情景来分析之。 情景一:用户使用OUTLOOK(MAPI)发送接收邮件 在该情景下，用户将邮件通过MAPI协议提交给数据库，直接被保存EDB文件中。当用户通过MAPI访问邮箱里的邮件时，如果被访问的邮件在EDB里，直接返回，如果在STM里(如外来邮件)，则执行转换，将STM转换为EDB文件格式，再返回用户。 情景二:用户使用标准SMTP/POP3/IMAP4等协议访问 用户使用非MAPI协议提交的邮件，内容保存在STM文件里，但是由于EDB里有邮箱结构，STM没有，因此系统会把邮件的重要信息提取出来，放在EDB里。当用户用MAPI提取邮件时，过程同上，当用户通过标准协议访问时，同样需要进行格式转换，转换为STM文件格式返回。 这些转换是在后台发生的。对用户来说是透明的。通过上面的描述，你会看到，这两个文件是 123下一页 ....，。紧密联系的缺一不可。所以，在任何时间我们都不要单独操作这两个文件，它们是一个整体。同时也要注意的是，无论用户使用何方式访问邮箱，都需要向EDB文件请求邮箱结构信息，这是需要注意的。 看完上面两个情景解释，你对默认的priv1.edb、priv1.stm两个数据文件应该有区分和了解吧?!寡人刚接触Exhange的时候对这两个文件的区别也很感冒! 四、LOG文件的重大作用 前面提到过了，他是霸占磁盘空间的罪魁祸首，有些管理员一看日志文件很多的时候，于是开始删除日志文件，删到后来觉得烦琐了，于是就启用循环日志来减少烦琐的工作。我前面说了，你启用这个功能的话，你就可以向上帝祈求了... 很多刚接触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点的数据变更就被完整的恢复了。这就是日志的第二个作用:保证系统备份和恢复的完整性。当然前提是没有使用循环日志! 看到了吧，启用循环日志的危害是多么的大啊?备份是多么的重要啊?...如果你看到这里还执迷不悟启用循环日志的话，寡人可就要骂你水给你就是让你做这个事情的。寡人再强调一 次:启用循环日志是冒险的做法，当启用循环日志后，一旦系统或者数据库发生灾难，想要恢复时，你就抱头后悔或者跺脚吧!磁盘和数据谁更重要，相信你这位做系统管理的，应该很清楚的。 五、ESE与IS服务的启动和关闭 ESE引擎在加载数据库文件时，会去检查数据库文件的标志。这个标志保留了上次关闭数据库的状态，当状态为正常关闭说，系统将直接加载该数据库，当数据库标志为非正常关闭时，系统将先进行一个软恢复过程(你可以在事件里看到它)，然后再加载。 那么，正常关闭和非正常关闭有什么区别呢?一个正常关闭的数据库，表示所有的日志信息都已经正确的写入数据库了。反之一个非正常关闭的数据库，则表示至少有一部分数据未能正确的从日志写入数据库。要注意的是，非正常关闭的数据库并不等于已经被破坏的数据库。只表示有数据没有提交到数据库文件。 使用ESEUTIL /MH命令可以看到数据库的该状态，其中的STATE字段标记的就是这个状态，Clean shutdo盘 在EX2000里，有一个M盘的映射。这个映射只是提供开发人员通过API访问邮箱和邮件用的。因此对M盘的手工操作都可能带来数据库的破坏，请注意，另外，有一种观点认为备份了M盘就备份了邮件，这是绝对错误的。M盘虽然是数据库的映射，但已经去掉了很多的关联和内在联系。因此备份M盘是不能恢复数据库的。所有的Exchange管理员必须按规定认真的备份系统状态和SG。切不可偷懒哦，偷懒的最终结果是让你加倍的付出时间去拯救数据。 看到这里，你还认为日志文件是多余的吗?Exchange管理员，赶快取消循环日志，建立健全的备份吧，为了你的薪水或者提高在老板心里的重要度，学会备份，很重要!关于数据备份的种类与方法，如果你想做一个合格的系统管理员，那就该多花一点时间在这上面。 上一页123....，。