exchange2010平稳运行大半年后的一次故障

   exchange2010平稳运行大半年了，期间也有过这样那样的小问题，比如控制台打不开，消息队列进不去等（都通过打补丁解决了），但这一次的问题似乎早就埋下伏笔。
    照理来说，公司邮箱用户三百人左右，每人划分1G，即使每人的邮箱都满状态，划给数据库的500G空间也足够应用；实际应用中，发现，数据库每天的增长惊人，查看邮箱数据库文件到目前为止仅为130G左右，并且增长缓慢，缘何500G可用空间不断缩小。
    开始时候，我在想是不是每人划分的空间太大引起的，于是做了缩小，能不扩大用户邮箱存储空间就不做。但数据库还是每天增加，似乎因为每天邮件往来也比较多，就觉得理所当然。不断增长，我又在想是不是开始规范邮箱用户的配制，台式机一律exchange协议，笔记本一律POP3协议，服务器尽量只保留三个月的邮件，这样数据库是不是会好过点。
    但这些还是阻止不了数据库的增长，当可用 空间只剩13.1G的时候，2012年10月24日上午10点，销售抱怨没收到客户邮件，开始了问题的发现之旅。
     问题：内部邮件正常发送接收，邮件外发正常，外部邮箱往公司邮箱发不进。
    处理：1.通过外部163邮箱发邮件给内部邮箱，发现外部邮箱在对公司邮箱say Helo ，但是公司邮箱置之不理。
              2.确定接收问题。开始圈定问题在端口/smtp/MX解析。
              3.联系西部数据，请求帮忙，联系靠谱，请求帮忙。都没问题。              
              4.应用EMC工具箱，邮件流工具邮件流疑难解答，端口正常，接收服务正常，但最后报错，错误内容未连接到smtp服务器。。。（记不清了）。一度以为真的就是这个服务出问题了。
              5.后来许工又用了下远程连接分析器。开始都很正常，最后的报错，让我们找到了真正的原因，在这里先感谢下。问题的根源还是我经常担心的邮箱空间问题。报错，空间不够。
              6.这就开始了我们腾空间之旅。
     邮箱数据库是一个130G大小的文件，但是文件夹内有很多1M大小的日志记录文件。数量庞大，总共加起来就有三百多G了。怎么搞。这些文件有何作用，能删除吗？
    各种度娘，各种谷哥。
     【度娘回答】 查出数据库写入的日志文件点，清理日志：

    1、执行 C:\Program Files\Exchsrvr\bin>eseutil /mk E:\exchsrvrstore01\mdbdata\e01.chk | find /i "checkpoint" 查找checkpoint点前的LOG文件名。 
    2、删除Checkpoint（检查点）前的LOG。
    3、重新启动Exchange Attendant Service。 c:\exchsrvr\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
     【开始操作】
     找到那个可删点，将之前的log日志剪切到另外一个盘，然后压缩了下，还是没敢真正删除。这样以来，有了40G的空间。尝试发个测试邮件，可以了收到了。这个方法就是check到数据库上次备份的一个时间点，然后告诉我可以删除备份点之前的文件。说实话这个点还是上次丁工说服务器要增加硬盘，为了保证数据安全，我硬着头皮用微软的WSB做了个备份。还是没成功的备份。
    
    这。。。
    不是长久之计啊。
     zenmegaizenmegai
    【看看大神的文章】
故障现象：

Exchange2010在使用一段时间后，日志占用磁盘空间不断增长（日志文件为单独一个分区），最后占满日志文件分区可用磁盘空间，导致用户无法正常收发邮件（注意：日志文件和邮箱数据库文件分别在不同分区，邮件数据库分区磁盘还有可用空间，只是日志文件分区磁盘空间已经满了），如何解决？

解决方法：

方法1： 
启用Exchange2010循环日志（不推荐）。

1） 打开“exchange管理器控制台---组织配置---邮箱”，选择需要启动“循环日志”的邮箱数据库。

2） 右键点击这个邮箱数据库，选择“属性”。

3） 选择“维护”，勾选“启用循环日志记录”，然后应用。 

注意：启用循环日志记录后，不会马上清空日志占用磁盘空间，需要先卸载邮箱数据库，然后重新加载邮箱数据库，即可清空日志占用磁盘空间。

B)使用Windows Server backup清空日志（推荐）

1) 服务器管理器----功能---添加功能，添加Windows Server backup。 

2) 打开“服务器管理器---存储---Windows Server backup”。

3) 选择“备份计划”。

4) 在出现“备份计划向导”界面，下一步。

5) 选择“整个服务器”，下一步。注意：建议这里选择整个服务器，否则单独选择一个日志文件分区，不会清除日志。 

6) 设置备份时间，下一步。 

7) 选择“备份到卷”，下一步。 

8) 添加备份目标磁盘，下一步。 

9) 完成。 

10) 在“备份计划向导”页面，会提示第一个备份的时间。 

11) 点击右侧“备份计划”，看是否为“VSS完整备份”。 

注意：高级选项中必须为“VSS完整备份”，只有这种方式才会清空日志。

【赶紧的做啊】 
第二种方法做了。就坐等这一夜的备份了。

【第二天】
看到备份，我想到，那一夜，你拒绝了我。。
备份文件500G，蛋。
日志文件照样在。
 

【看看其他的】
1.http://social.technet.microsoft.com/Forums/zh-CN/exchangeserverzhchs/thread/48228b54-b3a8-4c17-b654-0bda268cf319 

2.http://social.microsoft.com/Forums/zh-CN/exchangeserverzhchs/thread/3cd332ec-2eac-49e9-a826-4c1d8e7b86ee 
3.http://social.technet.microsoft.com/Forums/zh-CN/exchangeserverzhchs/thread/2571ba7f-4f14-484c-8e16-8e1269e985aa

【看了就知道啊】 
原来部署邮箱需要做日志规划的啊：

事务日志文件将记录数据库引擎执行的每个事务。所有事务将先写入日志，然后再慢慢写入数据库。与 Exchange Server 2003 不同，Exchange 2010 中的事务日志文件大小已从 5 MB 减小到 1 MB。此更改旨在支持连续复制功能，并将主存储失败时的数据损失量降到最低。

可以使用下表来估计将在 Exchange 2010 邮箱服务器上生成的事务日志数量，其中平均邮件大小为 75 KB。

“每天生成的事务日志数”的值取决于选择的邮件配置文件和平均邮件大小。它表示每天每个邮箱将生成的事务日志数。每个邮件配置文件的日志生成数需考虑以下因素：

• 邮件大小的影响
• 发送/接收的数据量
• 数据库运行状况维护操作
• 记录管理操作
• 不是邮件但存储在邮箱中的数据（任务、本地日历约会、联系人）
• 强制的日志滚动（定期关闭当前事务日志文件的机制）

每个邮箱配置文件生成的事务日志数量

 

邮件配置文件（75 KB 的平均邮件大小）	每日生成的事务日志的数量
50	10
100	20
150	30
200	40
250	50
300	60
350	70
400	80
450	90
500	100

可以使用以下准则来了解邮件大小如何影响事务日志的生成速度：

• 如果平均邮件大小是 150 KB 的两倍，则每个邮箱生成的日志增加 1.9 倍。该数字表示包含附件和邮件表（邮件正文和附件）的数据库的百分比。
• 因此，邮件大小超过 150 KB 的两倍时，每个邮箱的日志生成速率也会增加一倍，从 1.9 增加到 3.8。 

例如，如果您每天有 100 封邮件，并且：

• 平均邮件大小为 150 KB，每个邮箱生成的日志为 20 × 1.9 = 38。
• 平均邮件大小为 300 KB，每个邮箱生成的日志为 20 × 3.8 = 76。

以下部分讨论影响日志大小容量的因素：

• 备份和还原因素 
• 移动邮箱操作 
• 日志增长开销因素 
• 高可用性因素 
• LUN 容量规划 

  备份和还原因素

日志 LUN 大小在一定程度上取决于备份和还原设计。例如，如果设计允许后退两周并重播自那时起生成的所有日志，则需要两周日志文件的空间。如果备份设计包括每周完整备份和每日差异备份，则日志 LUN 需要大于整周日志文件的空间，以允许在还原期间进行备份和重播。大多数执行夜间完全备份的企业，会将所需的每天日志生成容量的分配提高到两到三倍。采用该方法可防止备份失败导致填满日志驱动器而卸除数据库。

如果计划在 Exchange 2010 中使用邮箱恢复和单个项目恢复功能作为备份基础结构（从而启用循环日志记录），那么最佳做法是，您应该确保将所需的每天日志生成容量的分配提高到三倍。这样可确保当复制已挂起或在正常参数下无法运行时，数据库不会由于截断故障而卸除。

  移动邮箱操作

移动邮箱是大型邮箱部署的主要容量因素。许多大型公司每夜或每周将一定百分比的用户邮箱移动到不同的数据库、服务器或网站。如果您的组织也是如此，您可能会发现为日志 LUN 多提供一些空间以容纳邮箱移动是非常必要的。

尽管源服务器会记录小型记录删除，目标服务器仍必须先将所有传输数据写入事务日志。如果一天生成 10 GB 的日志文件，并且将 30 GB 的缓冲区保留三天，则移动 50 个 2 GB 的邮箱 (100 GB) 将填满目标日志 LUN 并导致停机。在上述情况下，可能必须为日志 LUN 分配额外容量以支持移动邮箱。

  日志增长开销因素

对于大多数部署来说，我们建议您在创建日志 LUN 时向日志大小增加 20% 的开销因素（考虑其他所有因素之后），这样可以确保出现意外的日志生成时存在必要的容量。

  高可用性因素

高可用性会在三个重要方面影响日志容量要求：

• 数据库副本计数   整个系统的日志容量会基于在高可用性部署中选择的数据库副本的数量而增加。如果有三个数据库副本分布在三个服务器上，则需要为每个服务器上的每个副本设置日志容量。
• 日志截断机制   由于 Exchange 2010 中的高可用性最多可以提供每个邮箱数据库的 16 个副本，因此它可提供将连续复制循环日志记录作为日志截断/删除机制的基础（与运行完整/增量备份来截断/删除旧日志相对）。有关详细信息，请参阅了解备份、还原和灾难恢复和高可用性和站点恢复中的“日志截断而不备份”部分。
• 数据库副本重播延迟   Exchange 2010 中的高可用性提供了一种选择，可以延迟被动数据库副本上的日志重播（按副本配置）。此功能用于当将日志播放到延迟数据库副本中时提供延迟。此延迟有助于防止可能会使不需要的内容复制到所有数据库副本的事件。通过在将带有不需要的内容的日志播放到数据库中之前挂起重播，可以防止将该内容播放到延迟数据库副本中。 
  为数据库副本启用重播延迟后，日志容量要求会相应地发生更改。如果配置了 14 天延迟，则需要设置 17 天的日志。只有配置了延迟的数据库副本需要额外的日志容量，该数据库的其他副本（没有延迟）将具有正常的（非延迟）日志容量要求。

有关详细信息，请参阅了解高可用性因素。

  LUN 容量规划

LUN 的容量要求将基于数据集（数据库、事务日志、内容索引和恢复空间）的大小以及其他一些可用空间。多数操作管理程序都具有容量阈值，当 LUN 的利用率超过 80％ 时，容量阈值可提供警报。

可以使用以下公式来确定 LUN 的相应大小：

LUN 容量 = 数据大小 /（1 - 可用空间百分比要求）

例如，如果数据大小要求为 3000 MB，可用空间要求为 20％，则承载该数据的 LUN 的大小必须为 3750 MB。

   【现在知道的】
    在邮箱部署的时候，就要部署一个盘作为备份用。设置备份计划，每天备份。这样日志文件才会自动清除。也就是说，用WSB来给我做一个日志文件的压缩与操作。这样数据库文件才不会汗颜的增长。。。