关于Exchange数据库文件过大的正确处理方法

翻译

bjaojiggch 2017-08-19 12:53:26

作为一名Exchange管理员在管理exchange服务器的过程中,经常会碰到一些问题,比如日志过大,exchange数据库文件过大等一系列问题,最近发现一些管理员提出stm文件过大该如何处理?有些网友建议删除.stm文件,exchange重新相关服务会产生一个新的.stm文件,这种做法虽然也可以,但不值得推荐,即使在删除STM文件之前你做过备份,也是不可取的.如果你删除了.STM文件意味着你也删除了与stm同步的edb文件，这意味着什么，意味着存储在服务器上的邮件将会全部丢失，有人说我做了备份，调用那些文件我还原一个备份文件，重挂一下存储组不就OK啦，貌似可以，但这并不是最佳的解决方案，这就好比电脑一出问题就重装系统一下，不管大毛病小毛病，重装系统当然OK，效率并不一定最高。关键我们要学会找到和排除问题的方法。

大家都知道exchange的数据库文件是由EDB，其实stm也是exchange数据文件的一部分。既然它们都是exchange数据库文件，那它们之间又有什么样的关系呢？

在早期的exchange版本里，比如exchange 5.5 只有EDB文件，当时微软将EX主要定位是一个内部邮件系统，使用MAPI协议，这个协议也是微软的私有协议，EDB文件的作用是专门为此协议进行优化。但在实际运营过程中，我们实际上不只是利用EX5.5接收内部邮件，还要接收来自INTERNET邮件，MAPI并不是一个标准协议，因此每次收到INTERNET邮件时，都需要做一个格式转换处理。这样显然影响了EX5.5邮件服务器性能。

　　在EX2000及以后的EX版本里，微软增加了对INTERNET邮件的支持，这就是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文件格式返回。

　　这些转换是在后台发生的。对用户来说是透明的。通过上面的描述，你会看到，这两个文件是紧密联系的缺一不可。所以，在任何时间我们都不要单独操作这两个文件，它们是一个整体。同时也要注意的是，无论用户使用何方式访问邮箱，都需要向EDB文件请求邮箱结构信息，这是需要注意的。

上面是原理分析，那么我们到底该如何解决.stm或.edb文件过大这个问题呢？个人认为处理方法可以分为三步走。

第一步，通过exchange管理器，打开存储组，对已删除账户的邮箱进行清理，同时还需要检视一下已经辞工，而邮箱依然保留的账户，这些账户里的邮件是否需要进行收下来，这一部分可能有两三个原因，一个原因是有些用户当然离职了，比如象销售部门同事，邮箱需要作暂时保留；另一个部分是出差人员用OWA操作，寄件的内容保留在服务器上面；第三个原因可能是IT管理人员配置的时候，未把邮件保留在本地，或用户误操作引起，还有的是POP3方式，服务器上保留备份引起的。这些保留在服务器上的邮件日积月累将会严重影响了exchange数据库的负担，这一部分我们根据期类别进行分类处理，能保留在客户端就保留在客户端，不重要的要立即清除，剩余重要的才保留在服务器。

第二步：对服务器上个人邮箱进行压缩，命令： c:\>eseutil /d /priv。

第三步工作进行脱机整理，或者说是叫碎片整理。其实exchange不仅具有脱机整理的功能，自己还具有联机整理的功能，脱机整理只有在特殊情况下才需要进行，一般情况下不需要进行脱机整理，因为联机整理已经足够。脱机整理需要卸载存储，邮件服务器不能正常工作，一般只适合夜间或非工作时间来执行此工作。命令：