Exchange邮箱数据库事务日志引起磁盘暴涨 推荐

最近在做公司邮件系统的数据迁移（zimbra to exchange），原zimbra700多G的数据文件迁移到exchange2010中（IMAPSYNC迁移数据到exchange）。考虑到增长因素，exchange中预留了2T的空间用于数据存储。

Imapsync 详见：http://imapsync.lamiral.info/

本次数据迁移预计10天完成（账户5000多及其他原因，很耗时，哈哈哈。。。），过程基本正常，当进行到第五天时，查看进度，账户完成3000多，数据同步600G左右。zimbra服务器正常运行，邮件收发正常。Exchange服务器正常，同步完的账户邮件数量及内容一致。最后查看exchange数据库占用磁盘容量，竟然多达1.4xTB。继续下去，exchange会因数据库磁盘写满而无法正常运行。

为什么同步后邮件会增长这么多呢？

首先想到的问题是linux系统和windows系统的数据块大小不一致照成的，查看windows分配单元和linux block size的大小，都是4096字节，所以排除这个原因。既然和系统及分区无关，其他可能的原因就是数据库本身了。打开一个exchange邮箱数据库，能看到edb后缀的数据库文件及log后缀的日志文件。查看数据大小，log文件的总容量和edb文件几乎相同（log稍微大一些）。同步过程中exchange生成了相当于数据大小的日志文件。相当于在exchange中存有两份数据。查询微软知识库：Exchange邮箱数据库的事务日志文件将记录数据库引擎执行的每个事务。所有事务将先写入日志，然后再慢慢写入数据库。“每天生成的事务日志数”的值取决于选择的邮件配置文件和平均邮件大小。它表示每天每个邮箱将生成的事务日志数。每个邮件配置文件的日志生成数需考虑以下因素：

邮件大小的影响

发送/接收的数据量

数据库运行状况维护操作

记录管理操作

不是邮件但存储在邮箱中的数据（任务、本地日历约会、联系人）

强制的日志滚动（定期关闭当前事务日志文件的机制）

详细参考：http://technet.microsoft.com/zh-CN/library/ee832796

同时IMAPSYNC的工作原理相当于以imap的方式在exchange服务器上接收一份邮件数据。同步的邮件数量和邮件大小是正常工作的几百甚至上千倍，因此同一时刻会产生相当于数据大小的事务日志文件，进而磁盘容量暴涨。还好发现及时，问出现故障。

最后就是想办法清除多于日志文件，解决方法有两种，一种是启用Exchange2010循环日志，另一种是使用Windows Server backup执行一次“VSS完整备份”，这种方式会清空日志（推荐方法）。

注：清除日志后在mailbox出现问题的时候 无法进行排错。

生产环境中遇到日志占满磁盘空间，推荐采用备份的方式清除日志。考虑到我们这阶段只是同步邮箱数据产生的日志而非exchange运行中的发送接收产生，不会对mailbox有太大影响。因此采用启用日志循环功能，清除日志完成数据同步后再关闭日志循环个功能。

方法：

1. 启动 Exchange 管理控制台EMC。

2. 在EMC控制台中，展开“服务器配置”，然后单击“邮箱”。

3. 在工作窗格中，右键单击要启用或禁用循环日志记录的邮箱数据库，再单击“属性”。将出现“属性“对话框。

4. 选中“启用循环日志记录”复选框。





5. 单击“确定”。

6. 若要使对循环日志记录设置的更改生效，请重新启动 Microsoft Exchange 信息存储服务，或卸除后再重新装入存储组中的所有数据库。







7 对于多个邮箱数据库，可使用exchange powershell 命令开启日志循环，格式如下:

Set-MailboxDatabase -CircularLoggingEnabled $true -Identity 'CEOMSBGS'

多条写入ps1脚本运行即可。

8 当需求不能重启服务及卸载数据库时，可通过更改数据库维护时间时循环日志生效





对于多个数据库，同样适用于脚本，格式如下：

Set-MailboxDatabase -MaintenanceSchedule '日.14:00-日.15:00, 一.14:00-一.15:00, 二.14:00-二.15:00, 三.14:00-三.15:00, 四.14:00-四.15:00, 五.14:00-五.15:00, 六.14:00-六.15:00' -Identity 'CEOMSBGS'

所有执行完成后，查看磁盘容量，数据量大概是zimbra数据量的120%，属于正常范围。最后同步完成后再将日志循环功能关闭。

最后，问题解决，逃过被老板骂存储容量未规划好，呵呵呵。。。