维护Exchange Server 2003 邮件服务器(解决邮箱存储占用空间过大问题)

钉子

来源：Windows 中文论坛
作者：lianggj

前段时间一直有网友在问的问题.
问题一:
随着时间增长,邮件服务器邮箱存储占用的空间会不断加大,就算在客户端把邮件删除,可服务器存储邮件占用的空间还是没有减少,这是怎么回事?
问题二:
我的邮件服务器已经好几年啦,怎么样才能把邮箱用户比较老的邮件自动删除,不让它占用服务器的空间?

就是由这两个问题写了篇文章:
我的办法是做收件人策略+备份,减少邮件存储与及日志文件占用服务器空间.(这个数据库文件和日志文件是占空间的主要文件).

环境如下:
一台服务器作为DC(contoso.msft)+EXCHANGE,一台加入域(contoso,msft)的客户端.


环境已搭建好,为了测试自动删除过期邮件,空间占用问题,先给用户发封大邮件,让用户占用服务器空间.
在域内,用户c给用户m(用户实验前已建立)发封大邮件(邮件带附件).
在发之前先检查数据库以及日志占用空间大小.



内网邮箱用户互发邮件,占用服务器存储空间.





检查邮箱,服务器占用空间.(服务器一下涨了好多)



这时可把邮件认为是老邮件,建立收件人邮箱管理器策略来管理邮件.
如把2天前的大于是10240k的邮件删除.

把策略用于用户c和m.
策略设置如下:

让策略立刻生效.


验证结果.把时间手工调整一下,如改到3天后.
当前时间,以及3天后时间.邮箱大小变化情况.




客户端邮件已被删除,所以在服务看邮箱存储占用空间大小已经减少.
过期邮件已处理完毕,下面来释放空间.
这时候存储在物理磁盘的空间并没有减少,主要由数据库文件和日志文件组成.
可通过碎片整理和压缩来减少数据库空间,通过备份来删除日志文件.



做碎片整理和压缩数据库,做的是脱机数据库整理.

参考文章:

http://support.microsoft.com/kb/328804/zh-cn

http://support.microsoft.com/kb/192185/zh-cn

先检查数据库大小.主要由priv1.edb和priv1.stm构成.



1. 在 Exchange 系统管理器中，右键单击要进行碎片整理的信息存储，然后单击卸除存储。
2. 在命令提示符处，更改至 Exchsrvr\Bin 文件夹，然后键入 eseutil /d 命令、数据库开关以及要使用的任何选项。
例如，以下命令在邮箱存储数据库上运行标准的碎片整理实用工具：
C:\program files\exchsrvr\bin> eseutil /d c:\progra~1\exchsrvr\mdbdata\priv1.edb







结果.





现在空间大小主要是由日志文件占用.通过备份可以清除日志文件,用于释放更多的空间.

参考文章:

http://www.5dmail.net/bbs/viewthread.php?tid=55926&extra=page%3D1%26amp%3Bfilter%3Ddigest

由楼上的图可看出没备份前空间占用情况.

调出ntbackup,对Exchange 的”Information Store“存储组的所有数据库备份.



结果log文件减少.空出磁盘空间.



在这里浅谈了邮件管理和空间占用的问题,希望能对存在这问题的朋友有所帮助...

loneliness88

好，经典！
谢谢分享！！！

oneway1

这样做有很大风险，特别是对于很大的数据库，对于实际环境操作有难度。

风险如下：

1. 清理的条件很难设置。
常有些用户会将一些重要信件或者日常指导性的mail放在mailbox中，这样他无论webmail还是outlook里都可以看到。有时候，虽然邮件是很久前的，但还是经常需要使用。特别是一些老板，邮箱本身比较大，他们喜欢在下面分门别类建目录，存放历史邮件。你一个定期删除，呵呵，就等着倒备份吧。

2. offline defrag风险如下。

a. 盘空间问题，defrag需要一倍的数据库空间。一般，想到defrag的时候通常是磁盘空间已经快不够了。这时候还需要映射网络盘来做。这时候磁盘性能和网络性能很关键。defrag过程其实是复制数据库副本，在副本上defrag，然后在将副本copy回来的过程。副本copy会来的时候是一个很危险的过程，如果副本有问题，那只好恢复备份了。

b. 时间问题。如果数据库很大，需要很长时间。在此期间，你不可以睡大觉，也不可以长时间离开，因为任何错误都会停止defrag的进程，大数据库的操作是很费时间的。10Gb以上的文件copy一次就要不少时间。而且，通常停机时间都是事先计划好的，一旦发现问题需要马上处理，重新开始。 最最恶心的是，有时候进程条长时间不动，硬盘狂闪，你可能用几个小时已经做了95％。你根本不知道服务器在干什么，到底是停下重做，还是继续等待？

大容量数据库的defrage简直就是exchange admin的恶梦。

oneway1

根据个人经验，控制数据库大小可以如下处理。
1.设置合理的邮箱大小限制。
2.设置内部单封邮件的大小限制。
3.设置Internet单封邮件的大小限制。

众所周知，由于数据库无法在线缩小文件大小，即使这样数据库依然会变大。但是，exchange数据库有一个默认的墓碑时间，超过墓碑时间后，新数据可以写入墓碑所占的空间。因此，如果没有大量增加用户，新系统的数据库容量会在墓碑时间后趋于稳定。不会无休止快速增长。

oneway1

defrag需要分标准版和企业版exchange来讲。

企业版exchange的用户，请彻底忘了offline defrag吧，这年头还有企业版用户做offline defrag的 。多建个store，move所有邮箱到新store，删除老的就好了。对每个用户的影响大概也就几分钟。

sadleaf

thank you!

atong999888

原帖由 oneway1 于 2007-1-12 16:26 发表
defrag需要分标准版和企业版exchange来讲。

企业版exchange的用户，请彻底忘了offline defrag吧，这年头还有企业版用户做offline defrag的 。多建个store，move所有邮箱到新store，删除老的就好了。对每个 ...

这个办法比较好, 我一直用它.

钉子

没错，在讨论这个问题的时候，还需要了解一些：
1.Exchange服务器数据库维护周期的知识。
2.当然，像oneway在4楼中提到的大小控制策略是ex管理员的基本功。
3.注意“邮件管理器”的运行和条件策略。

lianggj

谢谢3楼.4楼的指点...写这文章前.仅从问题出发.所以才用这方案的...如我文章一开始所说的.

oneway1

以前ex 5.5的时候，一次做offline defrag失败，连续通宵2个晚上才搞定。呵呵，所以有感而发。

提醒一下，move信箱的时候，临时把log改为循环日志。dismount store后检查一下数据库完整性。如果是硬件raid5，看看有没有加电池模块，把写缓存打开。