? ? 在最近一次關于Exchange服務器故障中，出現了員工無法進入郵箱的問題，最直接方法來登錄OWA頁面，看看正常不正常，反映出來的報錯信息如下：

???? 當接到這個報障后，第一時間，當時有人問到是不是公司的CAS服務器掛了？當然還是如果對郵件服務器足夠了解的話， 這個報錯一定不是郵箱服務器CAS出現故障，因為如果CAS出現問題，您也到不了這個頁面的，所以根據產品提供服務來判斷，能打開OWA頁面，說明CAS服務器是正常的，出現這個報錯是在用戶輸入帳號和密碼后出現的，那么其實不用去思考，故障點一定出現在郵箱服務器角色上，好帶著這個排錯思路我們來看看郵箱服務器角色吧。

???? 當打開EMC控制臺時，所以數據庫全為宕的狀態，所以這也就是為什么用戶在網頁方式輸入郵箱帳號及密碼后，提示郵箱不可用的原因了，但是數據庫全為宕狀態的根本原因又是什么呢？根據經驗有極大的可能是郵箱數據庫所在的存儲盤滿了，OK，那么來看看，發現數據庫所在磁盤可用空間為幾百KB。

???? 現在要做的事情，就是盡快清理出空間來先恢復主體業務，可用方法有如下：

1.數據庫采用了DAG，那么可以先把副本庫刪除，保證每個主數據庫所在的磁盤有足夠的空間，但是隱性的風險在于如果主數據庫宕掉，又恢復不起來，那故障影響范圍就更大了。

2.通過清除Log的方法釋放空間，此方法還是比較穩妥的，至少能先把主、副數據庫掛起來，而且不會影響業務使用。

3.開啟日志循環功能，但需要卸載故障數據庫，且需要時間等待。

???? 所以最后選擇了第二種方法，清除Log，那么OK，這里我采用如下命令清理數據庫log文件，GUI下也可以，但是數據量過大，很有可能會導致系統假死，而且清理起來要比較費事。

forfiles /s /m *.log /d -4 /c "cmd /c del @file /f"

上邊這條命令的意思是刪除4天前的日志，清理后發現空間釋放出來幾十個G，再來看數據庫狀態，已經正常掛載和同步，那么OK,此時至少在郵件量不大的情況下能恢復業務。

?? 好，接下來就要考慮的是如何增加存儲的問題了，由于環境中是在esxi中搭建的虛擬化，方法有如下幾種： ??
1.直接對郵箱服務器角色存儲盤擴容，但由于是生產，所以還是有一定風險，如果擴盤失敗，那么會帶來郵箱服務器整體真正宕機。

2.新增單獨的存儲盤，并且由于之前是日志與edb數據庫文件位于同一個盤下，所以我們在增加新的存儲盤時，要增加2塊，一塊用于存放edb文件，另一塊用于存放log文件，也在數據庫的恢復性上做了優化這樣，增加新存儲盤后，再新建新的數據庫，將原存儲盤中較大的數據庫郵箱進行遷移，此項操作雖比較耗時，但是還是相對來說比較穩妥的方法。

3.增加新的郵箱服務器角色，將出問題的原存儲盤中的郵箱數據庫分別增加副本至新的郵箱服務器中，但是此方法雖也是比較穩妥的方法，但是從服務器增加搭建再到同步副本，仍是很慢的方法。

?? ? 所以最終在解決根本性問題時，選擇了方法二，這樣既能調優Exchange數據庫存放結構，又保證不會出現更大的問題，唯一可能要注意的就是要時時觀察原數據庫存儲盤，如是空間接近不足時，要用上述命令刪除日志，來保證遷移的順利，當然也通過這種方法起到了釋放空白空間的作用，遷移結束后，先將原數據庫卸載，觀察如果郵箱無問題，就可以直接刪除舊的數據庫了。

??? 當然，存儲盤是有限的，而日志文件的增長又是比較迅速的，所以盡可能在企業環境中增加備份軟件對日志進行備份來減少日志增加量及完整性，如果實在沒有條件搭建備份平臺，那么也可以數據庫新建后，開啟日志循環功能，來控制日志容量的增長。

??? 當然，最后還想說的是運維工作本身是一件非常謹慎的事情，所以遇到事情還是應該冷靜下來，先確認問題點，快速恢復業務，同時找到最穩妥的解決辦法來保證從根本防止此類故障問題，這次故障其實還有一個原因就是上一代管理員在對郵件平臺規劃中并沒有考慮到更長遠的問題，數據庫存儲空間不做規劃，導致數據庫日志在增長后，無法及時清理，所以做任何平臺，都應該本著規劃為先，測試及評估為中，實施為后的思想，多想想當前規劃是否會成為自己運維的增加了更大的風險。

??? 這篇文章只起到一個排錯思路的分享，更多的還是然望能通過這個案例，來說明存儲空間及備份在企業中的根本作用和必要性。

本文轉自wangtingdong 51CTO博客，原文鏈接：http://blog.51cto.com/tingdongwang/1640968，如需轉載請自行聯系原作者

總結

以上是生活随笔為你收集整理的关于Exchange邮箱服务器角色故障排查及解决思路分享的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。