本小節包括一些常見資料庫故障以及一些建議的補救方法。本小節包含以下主題:
由於 csadmind 是同時處理群組排程引擎 (GSE) 和警示派送引擎的服務,因此這種情況可能是由 GSE 佇列或警示佇列的違例項目導致的。
補救方法:
如果 csadmind 未執行,請立即發出 stop-cal 指令。
將行事曆伺服器置於執行狀態可能會導致作業事件記錄累積,從而進一步損毀資料庫,並且可能要花更長的時間使作業事件記錄檔符合資料庫。
驗證是否已停止所有 Calendar Server 程序。
如需有關如何驗證是否已停止所有程序的說明,請參閱停止子程序。
再次嘗試重新啟動 csadmind,方法是發出 start-cal -csadmind 指令。
如果順利啟動,執行以下步驟確定兩個佇列正在運作:
使用 csschedule 檢查 GSE 佇列。
使用 dbrig 檢查警示佇列。
如需有關執行 csschedule 及 dbrig 的說明,請參閱附錄 DCalendar Server 指令行公用程式參照。
如果 csadmind 由於傾印而當機,請分析 pstack。
如果您在追蹤中發現任何與 GSE 有關的功能 (它們中有字母 GSE),請查看 GSE 佇列的第一個項目和事件資料庫中的參照項目。多數時候,GSE 項目中涉及的事件是違例項目。若要修正此問題,請:
使用 csschedule 移除 GSE 項目。
使用 cscomponents 從資料庫中移除違例事件。
如需有關執行 csschedule 和 cscomponents 的說明,請參閱附錄 DCalendar Server 指令行公用程式參照。
如果項目沒有被損毀,可能是行事曆伺服器無法處理的特殊情況。
執行以下步驟:
拍攝已損毀的資料庫的行事曆環境快照,並連絡客戶支援。
若要建立環境備份,請:
若要避免服務中斷,請將行事曆資料庫暫時置於唯讀狀態,並復原至緊急備份副本。
將行事曆資料庫暫時置於唯讀狀態可防止任何增加、修改或刪除作業事件的發生。一般使用者增加、修改或刪除任何行事曆資料時都會收到錯誤訊息。當資料庫處於唯讀模式時,增加、修改或刪除行事曆事件和待辦事項的管理員工具將不可用。
若要將行事曆資料庫置於唯讀模式,請編輯 ics.conf 檔案並將以下參數設定為 “yes”,如下所示:
caldb.berkeleydb.readonly=”yes”
使用22.5.8 復原自動備份副本中的說明復原至緊急備份副本。
配置並啟用 csstored 後,在幾分鐘內即成為最新的緊急備份變為可用。您應經常驗證緊急備份副本以確定其也未被毀壞。(執行 db_verify。)
如果其他所有方法均失敗,請執行傾印和重新載入程序以查看其是否能挽救資料庫。
22.5.7 使用傾印和載入程序來回復行事曆資料庫中說明了這個程序。
這種情況可能是由控制執行緒導致的,該執行緒鎖定了 Berkeley DB 資料庫頁面,並在退出時未釋放鎖定。若要確認問題,請在 cshttpd 程序上執行 pstack,並執行 csadmind。(pstack 是標準的 UNIX 公用程式,位於:/usr/bin/pstack)。該公用程式將顯示等待以獲得鎖定的執行緒。
若要修正此問題,請重新啟動 Calendar Server,如下所示:
資料庫迴圈通常是由資料庫檔案中的損毀導致的。由於是資料庫損毀,故無法復原。有數個選項:
復原至緊急備份。
如果損毀是最近發生的,則可使用一個緊急備份。
使用突變歸檔回復程序。
如需建議使用的程序,請參閱22.5.8 復原自動備份副本。
使用傾印和重新載入程序,22.5.7 使用傾印和載入程序來回復行事曆資料庫。