可導致行事曆資料庫損毀的原因有以下多種:系統資源競爭、硬體故障、應用程式錯誤、資料庫故障,當然,還有人為的錯誤。本小節說明如何偵測行事曆資料庫損毀:
沒人能保證資料庫不受到損毀。但是可以將資料丟失和作業當機時間降至最低。密切監視資料庫和行事曆伺服器是儘早偵測損毀的關鍵。經常並完整地備份是從損毀 (只要發現) 中恢復的關鍵。
以下是行事曆資料庫可能受到的損毀的兩個層級:
應用程式層級 – 在多個資料庫檔案的一個資料庫檔案中的違例項目上作業時,這些項目會阻止伺服器執行。
資料庫層級 – Berkeley 資料庫頁面的損毀會導致各種問題的發生。一個常見問題就是執行 csdb check 時迴圈。另一個常見問題是出現如下錯誤訊息:
“illegal page type or format”, or “page 97895 doesn’t exist, create flag not set.”
監視 Calendar Server 記錄檔 (包括警示記錄),以發現任何可能指出資料庫損毀的錯誤訊息。
您應定期檢查記錄檔,瞭解是否存在 ALERT、CRITICAL、ERROR 以及 WARNING 層級的錯誤,一旦發現錯誤,應執行 Calendar Server 來檢查事件,以找出可能的問題。Calendar Server 正常作業期間會產生 NOTICE 和 INFORMATION 層級的記錄事件,這些事件可協助您監視伺服器狀態。
切勿移除資料庫目錄中的任何作業事件記錄檔。業事件記錄檔包含作業事件更新 (增加、修改或刪除),移除它們可能會損毀行事曆資料庫並且無法回復。
當您請求 Calendar Server 技術支援時,可能需要提供記錄檔,以協助解決問題。
使用 check 指令掃描行事曆資料庫,以檢查行事曆中 (包括行事曆特性 [calprops]、事件和待辦事項 [工作]) 是否有損毀。如果 check 指令找到無法解決的不一致情況,它會在輸出中報告該情況。
check 指令不檢查警示或群組排程引擎 (Group Scheduling Engine, GSE) 資料庫中是否發生損毀。
以具有安裝 Calendar Server 的系統之管理權限的使用者身份登入。
Calendar Server 可以執行,也可以停止;然而,如果可能,請停止 Calendar Server。
如果您尚未建立行事曆資料庫的副本,請建立副本。
僅複製資料庫 (.db) 檔案。您無需複製任何共用 (__db.*) 檔案或記錄 (log.*) 檔案。
移至 cal-svr-base/SUNWics5/cal/sbin 目錄。
例如,在 Solaris 作業系統上,輸入以下作為預設目錄:
cd /opt/SUNWics5/cal/sbin
在行事曆資料庫的副本中執行 check 指令:
./csdb check dbdir /tmp/check.out
如果未指定 dbdir,check 將使用目前目錄中的資料庫。
check 指令可產生大量資訊,因此請考量將所有輸出 (包括 stdout 和 stderr) 重新導向至一個檔案 (如範例中所示)。
check 完成後,請複查輸出檔案。如果您的資料庫已毀壞,請執行 rebuild 指令。
(請參閱22.5.6 重建已損毀的行事曆資料庫。)