关于Exchange邮箱服务器角色故障排查及解决思路分享

关于Exchange邮箱服务器角色故障排查及解决思路分享

在Exchange网络服务器最近的一次故障中，出现了员工无法访问其电子邮件的问题。最直接的方法是登录OWA网页，看看一切正常和不正常。反映的错误信息如下:

接到这个举报后，第一时间，当时就有人问企业的CAS网络服务器是不是死了。当然，如果您很好地掌握了邮件服务器，这个错误一定不是由邮箱服务器CAS的故障引起的。因为如果CAS出现问题，你将无法访问这个网页。因此，您可以根据产品展示服务项目打开OWA网页，这表明CAS网络服务器一切正常。这个错误是在客户输入账号和登录密码后出现的，实际上没必要去想。故障点必须出现在邮箱服务器的人物角色上，所以可以有这一排错误的想法。

当EMC控制面板打开时，所有数据库都关闭，所以这就是为什么客户在网页方法中键入邮箱帐户和登录密码后提醒邮箱地址不能使用。但是所有数据库宕机的直接原因是什么？根据工作经验，属于电子邮件数据库的存储磁盘很有可能已满，OK。然后经过讨论发现属于数据库的硬盘在室内可以用几百KB空。

我们现在要做的是尽快清出室内空房间，先修复演员的业务流程。可用的方法如下:

1.数据库选择DAG，可以先删除群库，保证每个主数据库所属的硬盘有足够的空间空。但潜在的风险在于，如果主数据库宕机，无法修复，故障隐患的范畴会变得更大。

2.按照消除日志的方法，可以释放到室内空房间。这个方法比较合适。至少可以先把一级和二级数据库链接起来，不容易危及业务流程应用。

3.打开日志循环系统，但必须卸载失败的数据库，并等待很长时间。

所以最后选择了第二种方法，对数消去法，所以OK。这里我选择以下指令来清除数据库日志文件，在GUI下是可以的，但是数据信息太多可能会导致诈死，清除起来比较困难。

对于文件/秒/米*。log/d-4/c"cmd/cdel@file/f"

上面这个命令的意思是删除四天前的日志，清除后发现室内空房间里放了几十个G。看数据库情况，一切都已经正常初始化了，所以OK，此时至少在邮件量不大的情况下，业务流程会修复。

好了，接下来我们需要考虑如何增加存储的问题，因为虚拟化技术是在自然环境下的esxi中内置的。方法如下:
1。立即扩展邮箱服务器角色存储磁盘，但因为是制造的，所以仍然存在一定的风险。如果扩展不成功，整个真实邮箱服务器将会关闭。

2.添加独立的存储磁盘，而且由于以前日志和edb数据库文档都在同一个磁盘上，所以当我们添加新的存储磁盘时，需要添加两个磁盘，一个用于存储edb文件，另一个用于存储日志文件，并且我们还改进了数据库的恢复。添加新的存储磁盘后，我们将创建一个新的数据库，并从原始存储磁盘传输一个大型数据库电子邮件。虽然这个实际 *** 作需要很长时间，但是需要很长时间。

3.添加一个新的邮箱服务器角色，原存储磁盘中有问题的每个邮件数据库都会添加到新的邮箱服务器中。然而，虽然这种方法也是一种更合适的方法，但从服务器添加和构建到同一个电子邮件服务器仍然是一种较慢的方法。

所以最终在处理全局问题时，选择了第二种方法，这样既能优化Exchange数据库的存储结构，又能保证不容易出现更高的问题。唯一有可能被注意到的，就是一直查看原数据库存储盘。如果室内空距离不够近，要用指令删除日志，保证转移成功。自然按照这种方法就有了释放空缺房空的效果。传输完成后，将首先卸载原始数据库。如果电子邮件没有问题，您可以立即删除旧数据库。

自然存储磁盘相对有限，日志文档的提升也比较快。因此，尽量在公司的自然环境中增加备份软件来备份日志数据，以减少日志量和一致性的增加。如果没有标准的备份数据服务平台，也可以在新创建数据库后打开日志循环系统来 *** 纵日志量的增加。

自然，最后我想说的是，运维管理本身就是一件非常审慎的事情。所以当事情发生的时候，我们要静下心来，先找准难点，快速修复业务流程，找到最合适的解决方案，保证从根源上避免这种失败问题。实际上，这次失败的另一个原因是上一代管理者在电子邮件服务平台的整体规划中没有充分考虑更长远的问题。数据库空之间没有整体规划，导致数据库日志无法在改进后立即清除。因此，各服务平台应坚持以整体规划为基础，适度测试评估，后期实施的理念。想想今天的整体规划会不会增加自身运维管理的风险。

本文分享的故障排除思路只有一个，很大一部分是希望根据这个例子，可以展示公司存储空和备份数据的根本功效和重要性。