Exchange Server 运维管理02:邮箱数据库存储原理

重申一下,出此系列文章的目的是为了加强运维管理的能力,也就是说不是部署或者是常规配置,这就需要掌握一些基本的理论知识。如果有朋友需要了解Exchange的部署或者是基本操作,可以参考其他的资源,也可以看我之前的Exchange系列文章。

本文将了解一下Exchage 2010数据库文件的存储原理,可能Exchange部署配置完成后,客户很少去关心底层数据库文件的存储格式,只要DAG副本能正常复制,用户邮箱正常使用就可以了,当然,这是理想状态,但万一数据库发生故障需要对数据库进行修复或者是还原时候,就需要用到和数据库存储相关的知识。

首先,Exchange 2010 Standard 版支持多达五个数据库。Exchange 2010 Enterprise 版支持多达 100 个数据库。但需要注意的是,这是指一台服务器上所支持的数据库的最大数量,包括活动数据库和被动数据库。

存储内容:

Exchange Server 2010中主要存储邮箱数据库和共用文件夹的内容,邮箱数据库是大家接触最多的,至于公用文件夹,大家简单了解即可,在 Outlook 2007之前的版本中,对于像忙/闲信息和脱机通讯簿 (OAB) 下载等功能,需要用到公用文件夹。也就是说如果企业中都是使用Outlook2007之后的版本,就可以和公用文件夹说拜拜了。因此,我们今天的重点是介绍邮箱数据库的内容。

邮箱数据库:

如果大家学习过任一数据库系统,则对于学习Exchange邮箱数据库一样简单。Exchange邮箱数据库分为数据库文件和事务日志文件两大类,当然除此之外,还有检查点文件,我们下面会一一介绍:

650) this.width=650;” height=”258″ title=”image” style=”border:0px;padding-top:0px;padding-right:0px;padding-left:0px;background-image:none;” src=”http://www.fwqtg.net/wp-content/uploads/2015/06/wKioL1V4V1zQa7NeAAF0khFkqoE139.jpg” border=”0″ alt=”Exchange Server 运维管理02:邮箱数据库存储原理” />

我这里直接升级到SP3,然后重启再运行此命令eseutil /ml 日志文件名,如下图所示:

49,对应于十进制值 73。基本名称是 e01,因此,最终的日志文件名将是 E0100000049.log。 Checkpoint 值实际上不是从日志文件文件头中读取的,但是看上去好像是从日志文件文件头中读取的它。Eseutil.exe 直接从 Enn.chk 读取 Checkpoint 值,这样就不必输入单独的命令即可了解检查点文件的位置。如果检查点文件已被破坏,Checkpoint 值将显示为 NOT AVAILABLE。在此例中,检查点位于当前日志文件 (0x50) 中,数字 FFFFFFFF 指示检查点在日志文件中的位置。一般,我们在修复或者是还原数据文件时,很少会用到检查点的信息。如果检查点文件被破坏,Exchange 仍可以正确地恢复并重播日志文件。只是Exchange 将从头开始扫描日志文件,从最早的可用文件开始,而不是从检查点日志开始。Exchange 跳过已应用于数据库的数据(写入到数据库的数据),并按顺序处理日志,直到遇到必须应用的数据。通常,Exchange 扫描已应用于数据库的日志文件只需要一两秒的时间。如果日志文件中包含必须被写入数据库的操作,应用操作可能需要 10 秒到几分钟不等。平均来算,可以在 30 秒或更短的时间内将一个日志文件的内容写入数据库。

Exchange 数据库正常关闭时,所有未处理的数据都将被写入数据库文件。正常关闭后,将认为数据库文件集是一致的,Exchange 将其与日志流分离。这表明数据库文件现在是自包含文件(最新)。不需要事务日志即可启动数据库文件。尽管在关闭所有数据库之后可以删除日志文件,但这样做将影响还原早期备份并前滚的能力。当前数据库不再需要现有的日志文件,但是如果必须还原早期数据库,则可能需要这些日志文件。

通过运行 Eseutil /mh 命令并检查数据库文件头,可以判断数据库是否已正常关闭,如果显示状态是cleanshutdown。则显示为正常关闭,否则,恭喜您,就修复吧。。。。。。。。。一个痛苦而漫长的过程。如果数据库处于异常关闭状态,必须提供检查点之后的所有现有事务日志,才能再次装入数据库。如果这些日志不可用,则必须运行 Eseutil /p 命令来修复数据库,以使数据库处于一致状态并可以启动。修复数据库,就有数据会丢失。尽管数据丢失量通常非常少,但是可能是灾难性的。对数据库运行 Eseutil /p 之后,应运行 Eseutil/ d 对数据库进行碎片整理。此操作将丢弃并重建所有数据库索引和空间树,如下图所示:

650) this.width=650;” height=”463″ title=”image” style=”border:0px;padding-top:0px;padding-right:0px;padding-left:0px;background-image:none;” src=”http://www.fwqtg.net/wp-content/uploads/2015/06/wKioL1V4V12TWYxnAAEos4ogj7A634.jpg” border=”0″ alt=”Exchange Server 运维管理02:邮箱数据库存储原理” />

如果 Exchange 2010 使用的是标准事务日志记录方式,则每个数据库事务都会被写入日志文件中,然后写入数据库中。如果日志文件的大小达到 1 MB,则将重命名该文件并新建日志文件。随着时间的推移,将产生一组日志文件。如果 Exchange 意外地停止,可以通过将这些日志文件中的数据重播到数据库中来恢复事务。循环日志记录方式则允许 Exchange 在事务日志文件包含的数据提交到数据库之后覆盖这些事务日志文件。但是,如果启用循环日志记录,则可以将数据只恢复到上一完整备份。因此,一般没有专门对Exchange数据库进行备份时,可以启用循环日志记录,为防止日志文件过多,影响到正常应用,需要启用循环日志记录。所以说,针对数据库进行有效的备份才是控制日志文件增长的有效办法。

本文出自 “杜飞” 博客,请务必保留此出处http://dufei.blog.51cto.com/382644/1660635


发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注