郵件儲存的疑難排解

本小節提供有效維護郵件儲存的準則。此外，本節還說明當郵件儲存損毀或意外關閉時您可以使用的其他郵件儲存回復程序。請注意，有關這些附加郵件儲存復原程序的小節是修復電子信箱和電子信箱資料庫的擴充內容。

極力建議您在閱讀本小節之前，先閱讀該章以及 Sun Java System Messaging Server Administration Reference 中有關指令行公用程式和 configutil 的章節。本節涵蓋以下主題：

• 郵件儲存的標準監視程序

• 常見問題與解決方案

• 郵件儲存的啟動與回復

• 修復電子信箱和電子信箱資料庫

郵件儲存的標準監視程序

本小節概述郵件儲存的標準監視程序。對於郵件儲存的一般檢查、測試和標準維護作業來說，這些程序很有幫助。

如需附加資訊，請參閱監視郵件儲存。

檢查硬體空間

郵件儲存應該有足夠的附加磁碟空間和硬體資源。若郵件儲存已接近磁碟空間及硬體空間的上限，在郵件儲存內可能會出現問題。

磁碟空間不足是導致郵件伺服器問題和故障的最常見原因之一。若沒有空間可供寫入郵件儲存，郵件伺服器將當機。此外，當可用磁碟空間低於特定臨界值時，將出現與郵件遞送和記錄等相關的問題。如果 stored 程序的清除功能失敗，無法從郵件儲存中永久刪除已刪除的郵件，則磁碟空間將立即耗盡。

如需有關監視磁碟空間的資訊，請參閱監視磁碟空間和監視郵件儲存。

檢查記錄檔

檢查記錄檔確保郵件儲存程序按配置執行。Messaging Server 可為每個主要協定或服務建立一組單獨的記錄檔，它支援：SMTP、IMAP、POP 和 HTTP。您可以透過主控台，或直接到 msg_svr_base/log/ 目錄下查看記錄檔。您應定期監視記錄檔。

請注意記錄會影響伺服器效能。您指定的記錄詳細度越高，您的記錄檔在給定時間內佔用的磁碟空間就越大。您應為伺服器定義有效可行的記錄旋轉策略、過期策略和備份策略。如需有關定義伺服器記錄策略的資訊，請參閱第 21 章, 管理記錄。

使用遙測技術檢查使用者 IMAP/POP 階段作業

Messaging Server 所提供的遙測功能，可以將使用者的整個 IMAP、POP 或網頁郵件階段作業擷取為檔案。該功能對於除錯用戶端問題十分有用。例如，如果使用者抱怨他們的郵件存取用戶端無法按預期作業，就可以使用此功能來追蹤存取用戶端和 Messaging Server 之間的互動。

若要擷取階段作業，只需建立以下目錄：

msg_svr_base/data/telemetry/ pop_or_imap/userid

Messaging Server 將在該目錄中為每個階段作業建立一個檔案。輸出範例如下所示。

LOGIN redb 2003/11/26 13:03:21
>0.017>1 OK User logged in
<0.047<2 XSERVERINFO MANAGEACCOUNTURL MANAGELISTSURL MANAGEFILTERSURL
>0.003>* XSERVERINFO MANAGEACCOUNTURL {67}
http://redb@cuisine.blue.planet.com:800/bin/user/admin/bin/enduser 
MANAGELISTSURL NIL MANAGEFILTERSURL NIL
2 OK Completed
<0.046<3 select "INBOX"
>0.236>* FLAGS (\Answered flagged draft deleted \Seen $MDNSent Junk)
* OK [PERMANENTFLAGS (\Answered flag draft deleted \Seen $MDNSent Junk \*)]
* 1538 EXISTS
* 0 RECENT
* OK [UNSEEN 23]
* OK [UIDVALIDITY 1046219200]
* OK [UIDNEXT 1968]
3 OK [READ-WRITE] Completed
<0.045<4 UID fetch 1:* (FLAGS)
>0.117>* 1 FETCH (FLAGS (\Seen) UID 330)
* 2 FETCH (FLAGS (\Seen) UID 331)
* 3 FETCH (FLAGS (\Seen) UID 332)
* 4 FETCH (FLAGS (\Seen) UID 333)
* 5 FETCH (FLAGS (\Seen) UID 334)
<etc>

檢查 stored 程序

stored 功能可執行多種重要作業，如郵件資料庫的死結和作業事件作業、增強存在時間策略以及永久刪除和清除磁碟上儲存的郵件。如果 stored 停止執行，將導致 Messaging Server 出現問題。如果 stored 未在 start-msg 執行時啟動，則其他程序均不會啟動。

• 檢查 stored 程序是否正在執行。執行 stored -t -v

• 檢查 store_root/mboxlist 中建立的記錄檔。

• 檢查預設記錄檔 msg_svr_base/log/default/default 中的 stored 郵件。

• 每當 stored 程序嘗試執行下列功能之一時，檢查檔案 (在目錄 msg_svr_base/config/ 中) 的時間戳記是否更新：

如需有關 stored 程序的更多資訊，請參閱「Sun Java System Messaging Server 6 2005Q4 Administration Reference」中的使用 stored 公用程式一章。

如需有關監視 stored 功能的附加資訊，請參閱監視郵件儲存

檢查資料庫記錄檔

資料庫記錄檔參照不活躍的作業事件檢查點記錄檔 (在目錄 store_root/mboxlist 中)。如果記錄檔累積，將不會產生資料庫檢查點。一般說來，總會有兩個或三個資料庫記錄檔同時存在。如果檔案較多，可能是發生問題的徵兆。

檢查使用者資料夾

如果您想檢查使用者資料夾，可以執行指令 reconstruct -r -n (遞迴不會修正)，該指令可檢閱任何使用者資料夾並報告錯誤。如需有關 reconstruct 指令的更多資訊，請參閱修復電子信箱和電子信箱資料庫

檢查核心檔案

僅在程序非預期終止時，存在記憶體檔案。查看這些檔案非常重要，特別是當您發現郵件儲存中存在問題的時候。在 Solaris 上，請使用 coreadm 來配置 core 檔案的位置。

郵件儲存的啟動與回復

郵件儲存的資料由郵件、索引資料以及郵件儲存資料庫共同組成。儘管該資料非常牢固，系統中仍可能會出現郵件儲存資料的問題，但這種情況很少發生。這些問題都可以從預設記錄檔中察覺，而且幾乎總是可以修正於無形。在極少數情況下，記錄檔中的錯誤訊息會指出您需要執行 reconstruct 公用程式。此外，做為最後一次復原，郵件會受備份和復原郵件儲存中說明的備份和復原程序保護。本小節將重點說明 stored 的自動啟動和復原程序。

郵件儲存將許多原本屬於管理員職責的回復作業都予以自動化。這些作業由郵件儲存常駐程式 stored 在啟動過程中執行，還包含資料庫快照和根據需要自動快速復原。stored 會徹底檢查郵件儲存的資料庫，並且在偵測到問題時自動啟動修復。

stored 還提供資料庫狀態的綜合分析，包括使用預設記錄的狀態訊息、報告對郵件儲存進行的修復，以及嘗試自動恢復作業等。

自動啟動和回復—作業原理

stored 常駐程式將在其他郵件儲存程序之前啟動。它將初始化郵件儲存資料庫，必要時也會回復該資料庫。郵件儲存資料庫中包含有資料夾、配額、訂閱以及郵件旗標等資訊。資料庫可以記錄和作業，因此已經內建回復功能。此外，還會在每個資料夾的郵件索引區域中複製資料庫資訊，做為備用。

雖然資料庫非常穩定，仍可能會偶爾發生損毀，但在大多數情況下，stored 可以透明地回復並修復資料庫。但是，只要 stored 重新啟動，您就應該檢查預設記錄檔，以確定系統不需要額外的管理介入。如果資料庫需要進一步重建，記錄檔中的狀態訊息會要求您執行 reconstruct。

開啟郵件儲存資料庫之前，stored 會分析資料庫的完整性，並將狀態訊息傳送到 warning 類別之下的預設記錄中。某些訊息對管理員很有用，某些訊息則包含已編碼的資料，可供內部分析之用。如果 stored 偵測到任何問題，它將嘗試修正並再次啟動資料庫。

當資料庫開啟後，stored 會通知其餘服務可以啟動。如果自動修復失敗，預設記錄中的郵件將指出應採取何種動作。請參閱表示需要執行 reconstruct -m 的錯誤訊息

在舊版中，stored 可能會啟動極度耗時的復原程序，使得管理員常常擔心 stored 是否「滯塞」。此類耗時的回復方式已被移除，並且 stored 可在一分鐘內決定最終狀態。但是，如果 stored 需要採用從快照回復之類的回復技術，該程序可能會多花費幾分鐘。

多數情況下，資料庫在回復後都可以恢復運作不需再做其他處置。然而，某些回復將需要執行 reconstruct -m，以同步化郵件儲存中的備用資料。這也會記錄到預設記錄中，因此在啟動後監視預設記錄很重要。雖然郵件儲存看起來一切如常，但還是有必要執行 reconstruct 之類的作業。

查閱記錄檔的另一個原因是可以確定損害資料庫的真正元兇。雖然 stored 的設計目的就是要讓郵件儲存能在存在任何其他系統問題的情況下啟動，但您也許還是想查明資料庫損毀的原因，因為這可能是更大潛在問題的徵兆。

表示需要執行 reconstruct -m 的錯誤訊息

本小節說明需要執行 reconstruct -m 的錯誤訊息類型。

當錯誤訊息指出電子信箱錯誤時，請執行 reconstruct <mailbox>。範例：

"Invalid cache data for msg 102 in mailbox user/joe/INBOX. Needs reconstruct"

"Mailbox corrupted, missing fixed headers: user/joe/INBOX"

"Mailbox corrupted, start_offset beyond EOF: user/joe/INBOX"

當錯誤訊息指出資料庫錯誤時，請執行 reconstruct -m。範例：

"Removing extra database logs. Run reconstruct -m soon after startup to resync redundant data"

"Recovering database from snapshot. Run reconstruct -m soon after startup to resync redundant data"

資料庫快照

快照是資料庫的最新備份，stored 可以用它在幾分鐘內透明地復原資料庫。這種方式比依賴其他區域中儲存的備援資訊來運作的 reconstruct 要快得多。

郵件儲存資料庫快照—作業原理

資料庫快照位於 mboxlist 目錄中，依預設每 24 小時自動取樣一次。依預設，快照會複製到 store 目錄的子目錄中。依預設，在任何給定時間，系統會保留五種快照：一個使用中的資料庫，三個快照以及一個資料庫/已移除的副本。已移除資料庫的副本較新，它是資料庫的緊急備用副本，通常放在 mboxlist 資料庫目錄的 removed 子目錄下。

如果復原程序確定目前資料庫已損毀並決定將其移除，則 stored 會將其移至 removed 目錄中 (如果可能)。這樣就可以根據需要對資料庫進行分析。

資料移動每週進行一次。如果已存在資料庫副本，stored 將不會在每次儲存啟動時替代資料庫副本。僅當 removed 目錄中的資料超過一週後，才會進行替代。這是為了防止原先有問題的資料庫在啟動成功後很快被取代。

指定郵件儲存資料庫快照的間隔和位置

所需空間至少是資料庫加上快照空間的五倍。極力建議管理員應重新配置快照以在單獨的磁碟上執行，並根據系統的需求進行調校。

如果 stored 在啟動時偵測到資料庫有問題，就會自動用最新的快照來回復。三個快照變數可以設定以下參數：快照檔案的位置、執行快照的間隔時間以及儲存的快照數目。這些 configutil 參數在表 18–15 中顯示。

如果快照的間隔時間太短，會對系統造成太多負擔並且資料庫中有問題的部分也很可能被複製到快照中。如果快照的間隔時間太長，會造成資料庫只能回復到當初快照時的狀態，中間的變動都會損失掉。

一般的建議是一天作一次快照，如果系統上的問題已存在數天之久，一週份或更多的快照會對回復很有幫助，因為您也許會想將系統復原到問題發生之前的狀態。

stored 會監視資料庫，並且當它懷疑資料庫有問題時，會拒絕使用最新的快照。然後它將擷取儘可能新的最可靠快照。雖然快照可能是一天前擷取的，但如果可用，系統還是會以較新的備援資料來置換較舊的快照資料。

因此快照的最終目的就是要取得系統最近的穩定狀態資料，以減輕系統在正常作業時重建資料的負擔。

修復電子信箱和電子信箱資料庫

如果有一個或多個電子信箱損毀，您可以使用 reconstruct 公用程式來重建電子信箱或電子信箱資料庫，並修復任何不一致問題。

reconstruct 公用程式可重建一個或多個電子信箱，或主電子信箱檔案，並修復任何不一致問題。您可以使用此公用程式從郵件儲存中任何一種資料損毀類型回復。請參閱表示需要執行 reconstruct -m 的錯誤訊息

表 18–16 列出了 reconstruct 選項。如需詳細的語法和用法需求，請參閱「Sun Java System Messaging Server 6 2005Q4 Administration Reference」中的「reconstruct」。

重建電子信箱

若要重建電子信箱，請使用 -r 選項。此選項的使用時機是：

• 存取電子信箱時傳回以下錯誤之一：「系統 I/O 錯誤」或「信箱的格式無效」。

• 存取電子信箱會導致伺服器當機。

• 已在暫存區目錄中新增或移除檔案。

reconstruct -r 會先執行一致性檢查。它會報告一致性狀況，並僅在偵測到問題時才進行重建。因此，此發行版本已提昇了 reconstruct 公用程式的效能。

您可以按照以下範例中的說明使用 reconstruct：

若要重建使用者 daphne 的電子信箱暫存區，請使用以下指令：

reconstruct -r user/daphne

重建電子信箱資料庫中列出的所有電子信箱的暫存區：

reconstruct -r

但是使用此選項時必須小心，因為對於大型郵件儲存來說，重建電子信箱資料庫中列出的所有電子信箱的暫存區會佔用很長時間。(請參閱重建效能。)較好的故障回復方式可能是將多個磁碟用於儲存。如果其中一個磁碟發生故障，也不致影響整個儲存。如果磁碟損毀，您只需使用 -p 選項重建一部分儲存，如下所示：

reconstruct -r -p subpartition

若要重建指令行引數中列出的、位於 primary 分割區的電子信箱：

reconstruct -p primary mbox1 mbox2 mbox3

如果您需要重建 primary 分割區中的所有電子信箱：

reconstruct -r -p primary

如果您要強制 reconstruct 重建資料夾而不執行一致性檢查，請使用 -f 選項。例如，以下指令會強制重建使用者資料夾 daphne：

reconstruct -f -r user/daphne

若要只檢查所有電子信箱而不進行修正，請使用 -n 選項，如下所示：

reconstruct -r -n

檢查並修復電子信箱

執行電子信箱資料庫的高階一致性檢查和修復：

reconstruct -m

若要對主分割區執行一致性檢查和修復，請執行︰

reconstruct -p primary -m

將 -p 和 -m 旗標與 reconstruct 一起執行不會修正 lright.db。這是因為修正 lright.db 需要掃描郵件儲存中每個使用者的 ACL。對每個分割區執行此選項不會很有效。若要修正 lright.db，請執行 reconstruct -l。

若要對個別使用者的名為 john 的電子信箱執行一致性檢查和修復，請執行︰

reconstruct -p primary -u john -m

-m 選項的使用時機是：

• 已從儲存的暫存區移除一個或多個目錄，從而還需要移除電子信箱資料庫的項目。

• 已將一個或多個目錄復原到儲存的暫存區，從而還需要新增電子信箱資料庫的項目。

• stored -d 選項無法確保資料庫的一致性。

  如果 stored -d 選項無法確保資料庫的一致性，您應依次執行以下步驟：

  • 關閉所有伺服器。

  • 移除 store_root/mboxlist 中的所有檔案。

  • 重新啟動伺服器程序。

  • 執行 reconstruct -m 以根據暫存區的內容建立新的電子信箱資料庫。

重建效能

reconstruct 執行作業所花費的時間取決於以下因素：

• 所執行的作業類型及選擇的選項

• 磁碟效能

• 執行 reconstruct -m 時的資料夾數目

• 執行 reconstruct -r 時的郵件數目

• 郵件儲存的整體大小

• 系統在執行哪些其他程序以及系統的忙碌程度

• 是否有正在進行的 POP、IMAP、HTTP 或 SMTP活動

reconstruct -r 選項會執行初始一致性檢查；該項檢查會根據需要重建的資料夾數目來提昇 reconstruct 的效能。

有大約 2400 名使用者的 85GB 郵件儲存伺服器 (同時有 POP、IMAP 或 SMTP 活動) 的系統具有以下效能：

• reconstruct -m 大約需要 1 小時

• reconstruct -r -f 大約需要 18 小時

如果伺服器上沒有 POP、IMAP、HTTP 或 SMTP 活動正在執行，則 reconstruct 作業所需的時間會顯著減少。

常見問題與解決方案

本節列出郵件儲存的常見問題及解決方案：

• Messenger Express 或 Communications Express 未載入郵件頁面

• 使用萬用字元式樣的指令失效

• 未知/無效的分割區

• 使用者電子信箱目錄的問題

Messenger Express 或 Communications Express 未載入郵件頁面

如果使用者無法載入任何 Messenger Express 頁面或 Communications Express 郵件頁面，可能是因為壓縮之後資料損毀。如果系統部署了過期的代理伺服器，則有時可能會發生這種情況。若要解決該問題，請嘗試將 local.service.http.gzip.static 和 local.service.http.gzip.dynamic 設定為 0，以停用資料壓縮。如果此方法可以解決這個問題，您可能需要更新代理伺服器。

使用萬用字元式樣的指令失效

有些 UNIX shell 要求在萬用字元參數的前後加上引號，有些則不要求。例如，C shell 嘗試展開包含萬用字元 (*、?) 做為檔案的引數，如果找不到相符項，則會失敗。這些與式樣相符的引數可能需要以引號括住，以傳遞至 mboxutil 之類的指令。

例如：

mboxutil -l -p user/usr44*

可在 Bourne shell 下執行，但在 tsch 和 C shell 下會失敗。這些 shell 的慣用格式是：

mboxutil -l -p "user/usr44*"

如果使用萬用字元式樣的指令無法執行，請檢驗您是否需要為該 shell 的萬用字元加上引號。

未知/無效的分割區

如果使用者的電子信箱被移至剛建立的新分割區，且 Messaging Server 未重新整理或重新啟動，則該使用者將在 Messenger Express 中收到訊息「未知的/無效的分割區」。此問題只會發生在新分割區上。如果您現在向此新分割區增加其他使用者電子信箱，則必須重新整理/重新啟動 Messaging Server。

使用者電子信箱目錄的問題

如果郵件儲存的損毀僅限於一小部分使用者，而沒有對系統造成全域損毀，則使用者電子信箱存在問題。以下使用準則提出了一套用於辨識、分析和解決使用者電子信箱目錄問題的程序：

1. 復查記錄檔、錯誤訊息或使用者觀察到的任何不尋常行為。

2. 若要保留除錯資訊及歷程，請將整個 store_root/mboxlist/ 使用者目錄複製到郵件儲存以外的其他位置。

3. 若要找出可能導致問題的使用者資料夾，請執行 reconstruct -r -n 指令。如果您無法使用 reconstruct 找到資料夾，則該資料夾可能不在 folder.db 中。

   如果您無法使用 reconstruct -r -n 指令找到資料夾，請使用 hashdir 指令來確定該資料夾的位置。如需有關 hashdir 的更多資訊，請參閱hashdir 公用程式和「Sun Java System Messaging Server 6 2005Q4 Administration Reference」中「Messaging Server 指令行公用程式」一章的 hashdir 公用程式。

4. 如果找到該資料夾，請檢查檔案和許可權並驗證檔案大小是否正確。

5. 使用 reconstruct -r (不帶 -n 選項) 重建電子信箱。

6. 如果 reconstruct 未偵測出您觀察到的問題，則可以使用 reconstruct -r -f 指令強制重建郵件資料夾。

7. 如果資料夾不在 mboxlist 目錄 (store_root/mboxlist) 中，而是在 partition 目錄 store_root/partition) 中，則可能存在全域不一致性。在這種情況下，您應執行 reconstruct -m 指令。

8. 如果上一步驟不管用，您可以移除 store.idx 檔案，然後再次執行 reconstruct 指令。

   ---

   注意 –

   如果您確定檔案中存在 reconstruct 指令無法發現的問題，則應僅移除 store.idx 檔案。

   ---

9. 如果該問題僅限於一個問題郵件，您應將此郵件檔案複製到郵件儲存以外的其他位置，然後對 mailbox/ 目錄執行 reconstruct -r 指令。

10. 如果您確定資料夾位於磁碟上 (store_root/partition/ 目錄)，但顯然不在資料庫中 (store_root/mboxlist/ 目錄)，請執行 reconstruct -m 指令來確保郵件儲存的一致性。

如需有關 reconstruct 指令的更多資訊，請參閱修復電子信箱和電子信箱資料庫

儲存常駐程式無法啟動

如果 stored 無法啟動，並傳回以下錯誤訊息：

# msg_svr_base/sbin/start-msg

msg_svr_base: Starting STORE daemon ...Fatal error: Cannot
find group in name service

這表示系統找不到 local.servergid 中配置的 UNIX 群組。Stored 及其他常駐程式需要將它們的 GID 設定為該群組。有時，由 local.servergid 定義的群組會被意外刪除。在這種情況下，就必須重建被刪除的群組，將 inetuser 加入群組，然後將 instance_root 及其檔案的所有權改授予 inetuser 和該群組。