照理來說，公司郵箱用戶三百人左右，每人劃分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了。怎麼搞。這些文件有何作用，能刪除嗎？
各種度娘，各種谷哥。
【度娘回答】查出數據庫寫入的日誌文件點，清理日誌：
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 需要大於整週日誌文件的空間，以允許在還原期間進行備份和重播。大多數執行夜間完全備份的企業，會將所需的每天日誌生成容量的分配提高到兩到三倍。採用該方法可防止備份失敗導致填滿日誌驅動器而卸除數據庫。
如果計劃在 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來給我做一個日誌文件的壓縮與操作。這樣數據庫文件纔不會汗顏的增長。。。