偵測資料庫損毀

可導致行事曆資料庫損毀的原因有以下多種：系統資源競爭、硬體故障、應用程式錯誤、資料庫故障，當然，還有人為的錯誤。本小節說明如何偵測行事曆資料庫損毀：

• 資料庫損毀基本

• 監視記錄檔

• 使用 csmonitor

• 檢查行事曆資料庫是否損毀

資料庫損毀基本

沒人能保證資料庫不受到損毀。但是可以將資料丟失和作業當機時間降至最低。密切監視資料庫和行事曆伺服器是儘早偵測損毀的關鍵。經常並完整地備份是從損毀 (只要發現) 中恢復的關鍵。

以下是行事曆資料庫可能受到的損毀的兩個層級：

• 應用程式層級 – 在多個資料庫檔案的一個資料庫檔案中的違例項目上作業時，這些項目會阻止伺服器執行。

• 資料庫層級 – Berkeley 資料庫頁面的損毀會導致各種問題的發生。一個常見問題就是執行 csdb check 時迴圈。另一個常見問題是出現如下錯誤訊息：

  “illegal page type or format”, 
  or “page 97895 doesn’t exist, create flag not set.”

監視記錄檔

監視 Calendar Server 記錄檔 (包括警示記錄)，以發現任何可能指出資料庫損毀的錯誤訊息。如需有關記錄檔的資訊，請參閱使用 Calendar Server 記錄檔。

您應定期檢查記錄檔，瞭解是否存在 ALERT、CRITICAL、ERROR 以及 WARNING 層級的錯誤，一旦發現錯誤，應執行 Calendar Server 來檢查事件，以找出可能的問題。Calendar Server 正常作業期間會產生 NOTICE 和 INFORMATION 層級的記錄事件，這些事件可協助您監視伺服器狀態。

切勿移除資料庫目錄中的任何作業事件記錄檔。業事件記錄檔包含作業事件更新 (增加、修改或刪除)，移除它們可能會損毀行事曆資料庫並且無法回復。

當您請求 Calendar Server 技術支援時，可能需要提供記錄檔，以協助解決問題。

使用 csmonitor

使用 csmonitor 公用程式監視 Calendar Server。該公用程式會在偵測到問題 (例如存在多個作業事件記錄檔或行事曆資料庫磁碟空間不足) 時透過電子郵件警示管理員。如需更多資訊，請參閱csmonitor。

檢查行事曆資料庫是否損毀

使用 check 指令掃描行事曆資料庫，以檢查行事曆中 (包括行事曆特性 [calprop]、事件和待辦事項 [工作]) 是否有損毀。如果 check 指令找到無法解決的不一致情況，它會在輸出中報告該情況。

check 指令不檢查警示或群組排程引擎 (GSE) 資料庫中是否有損毀。

步驟

1. 以具有安裝 Calendar Server 的系統之管理權限的使用者身份登入。

2. Calendar Server 可以執行，也可以停止；然而，如果可能，請停止 Calendar Server。

3. 如果您尚未建立行事曆資料庫的副本，請建立副本。

   僅複製資料庫 (.db) 檔案。您無需複製任何共用 (__db.*) 檔案或記錄 (log.*) 檔。

4. 變更至 cal_svr_base/SUNWics5/cal/sbin 目錄。

   例如，在 Solaris 作業系統上，輸入以下作為預設目錄：

   cd /opt/SUNWics5/cal/sbin

5. 在行事曆資料庫的副本中執行 check 指令：

   ./csdb check dbdir /tmp/check.out

   如果您未指定 dbdir，check 將使用目前目錄中的資料庫。

   check 指令可產生大量資訊，因此請考量將所有輸出 (包括 stdout 和 stderr) 重新導向至一個檔案 (如範例中所示)。

6. check 完成後，請複查輸出檔案。如果您的資料庫已毀壞，請執行 rebuild 指令。

   (請參閱重建已損毀的行事曆資料庫。)