在啟動期間，csadmind 不會啟動或當機

由於 csadmind 是同時處理群組排程引擎 (GSE) 和警示派送引擎的服務，因此這種情況可能是由 GSE 佇列或警示佇列的違例項目導致的。

補救方法：

步驟

1. 如果 csadmind 沒有執行，請立刻發出 stop-cal。

   將行事曆伺服器置於執行狀態可能會導致作業事件記錄累積，從而進一步損毀資料庫，並且可能要花更長的時間使作業事件記錄檔符合資料庫。

2. 嘗試再次重新啟動 csadmind (再次發出 start-cal)。

   如果啟動成功，請確定透過以下操作使兩個佇列發揮其功能：

   1. 使用 csschedule 檢查 GSE 佇列。

   2. 使用 dbrig 檢查警示佇列。

      如需有關執行 csschedule 和 dbrig 的說明，請參閱附錄 DCalendar Server 指令行公用程式參照。

3. 如果 csadmind 由於傾印而當機，請分析 pstack。

   如果您在追蹤中發現任何與 GSE 有關的功能 (它們中有字母 GSE)，請查看 GSE 佇列的第一個項目和事件資料庫中的參照項目。多數時候，GSE 項目中涉及的事件是違例項目。若要修正此問題，請：

   1. 使用 csschedule 移除 GSE 項目。

   2. 使用 cscomponents 從資料庫中移除違例事件。

      如需有關執行 csschedule 和 cscomponents 的說明，請參閱附錄 DCalendar Server 指令行公用程式參照。

4. 如果項目沒有被損毀，可能是行事曆伺服器無法處理的特殊情況。

   執行以下步驟：

   1. 拍攝已損毀的資料庫的行事曆環境快照，並聯絡客戶支援。

      若要建立環境備份，請：

      1. 使用 db_checkpoint 公用程式，位於：

         cal_svr_base/SUNWics5/cal/tools/unsupported/bin/db_checkpoint

      2. 執行 db_archive -s。

         使用 -s 選項識別所有資料庫檔案，並將其複製到可移動的媒體 (例如 CD、DVD 或磁帶)。

      3. 執行 db_archive -l。

         使用 -l 選項識別所有記錄檔，並將未套用的記錄檔複製到可移動媒體裝置。

   2. 若要避免服務中斷，請將行事曆資料庫暫時置於唯讀狀態，並復原至緊急備份副本。

      • 將行事曆資料庫暫時置於唯讀狀態可防止任何增加、修改或刪除作業事件的發生。一般使用者增加、修改或刪除任何行事曆資料時都會收到錯誤訊息。當資料庫處於唯讀模式時，增加、修改或刪除行事曆事件和待辦事項的管理員工具將不可用。

        若要將行事曆資料庫置於唯讀模式，請編輯 ics.conf 檔案並將以下參數設定為 “yes”，如下所示：

        caldb.berkeleydb.readonly=”yes”

      • 使用復原自動備份副本中的說明復原至緊急備份副本。

        配置並啟用 csstored 後，在幾分鐘內即成為最新的緊急備份變為可用。您應經常驗證緊急備份副本以確定其也未被毀壞。(執行 db_verify。)

5. 如果其他所有方法均失敗，請執行傾印和重新載入程序以查看其是否能挽救資料庫。

   使用傾印和載入程序回復行事曆資料庫中說明了此程序。