test

Sun Java System Calendar Server 6 2005Q4 管理指南

關於資料庫問題

本小節包括關於 Calendar Server 資料庫的各種問題：

尋找 Berkeley 資料庫工具

您將要執行的許多疑難排解步驟要求已存取 Berkeley 資料庫公用程式。儘管 Calendar Server 隨附有這些公用程式的某個版本，但其不受支援。您可能希望直接從 Sleepycat Software (http://www.sleepycat.com) 獲得更多資訊。

本小節包含以下主題：

存取 Berkeley 資料庫公用程式

設定並匯出 LD_LIBRARY_PATH 環境變數，以反映以下目錄：

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

可用工具清單

下表列出了一些常用 Berkeley 資料庫工具 (公用程式)。

Berkeley 資料庫工具 

說明 

db_archive

將不再使用的記錄檔之路徑名稱寫入標準輸出 (每行一個路徑名稱)。 

db_checkpoint

常駐程式程序，監視資料庫記錄並定期呼叫檢查點常式檢查資料庫記錄。 

db_deadlock

遍歷資料庫環境鎖定區域並在每次偵測到死結或已逾時的鎖定請求時中斷鎖定請求。 

db_dump

使用 db_load 公用程式可以識別的平面文字格式，將指定的檔案寫入標準輸出。

db_load

從標準輸入中讀取檔案並將其載入指定的資料庫檔案。如果檔案不存在，該工具將建立它。 

db_printlog

除錯公用程式以人類可讀格式傾印記錄檔。 

db_recover

應用程式、資料庫或系統出現意外故障後，將資料庫復原為與原來一致的狀態。 

db_stat

顯示資料庫環境的統計。 

db_verify

驗證一個或多個檔案的結構及檔案包含的資料庫。 

Procedure偵測與修正資料庫死結

如果 Berkeley 資料庫處於死結狀態，則必須重設資料庫。儘早偵測此情況是很重要的。

若要使系統能定期檢查資料庫以偵測死結狀態並通知管理員，請：

步驟

  1. 以擁有變更配置權限的管理員身份登入。

  2. 變更至 /etc/opt/SUNWics5/cal/config 目錄。

  3. 透過複製及重新命名，儲存舊的 ics.conf 檔案。

  4. 如有必要，編輯 ics.conf 以具有以下值：

    local.caldb.deadlock.autodetect=”yes”

    備註 –

    此參數設定為 “yes” 時，啟動監視鎖定區域的 db_deadlock 常駐程式。

偵測資料庫損毀

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

資料庫損毀基本

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

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

監視記錄檔

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

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

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

備註 –

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

使用 csmonitor

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

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

使用 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 指令。

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

防止服務在資料庫發生損毀時中斷 (唯讀模式)

本小節包括如何在回復模式中保持已損毀的資料庫可存取，並包含以下主題：

使用唯讀模式

遇到資料庫損毀時，防止服務中斷的一個方法是將資料庫置於唯讀模式。此模式允許一般使用者讀取資料庫項目，但不允許對其進行增加、修改或刪除。如果一般使用者嘗試增加、修改或刪除任何行事曆資料，系統將提示錯誤訊息。此外，當資料庫處於唯讀模式時，增加、修改或刪除行事曆事件和待辦事項的管理員工具將不可用。

備註 –

如果資料庫已毀壞到不可被讀取的程度，則必須將服務中斷足夠長的時間以復原備份。復原備份的最快方法是具有完好的緊急備份。請參閱復原之前。

Procedure將資料庫置於唯讀模式

步驟

  1. 儘管不是必要的，但您可以選擇暫時停止行事曆服務以防止資料庫被進一步損毀。

    若要停止行事曆服務，請：

    cal_svr_base/SUNWics5/cal/sbin/stop-cal

  2. 在指令行變更至 ics.conf 所在的目錄︰

    cd /etc/opt/SUNWics5/config

  3. 為行事曆資料庫指定唯讀模式：

    caldb.berkeleydb.readonly=”yes”

  4. 完成編輯 ics.conf 檔案之後，請重新啟動 Calendar Server︰

    cal_svr_base /SUNWics5/cal/sbin/start-cal

    您必須重新啟動服務，以使 ics.conf 變更生效。

處理常見資料庫故障

本小節包括一些常見資料庫故障以及一些建議的補救方法。本小節包含以下主題：

Procedure在啟動期間，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. 如果其他所有方法均失敗，請執行傾印和重新載入程序以查看其是否能挽救資料庫。

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

Procedure服務當機並且一般使用者無法連線 – 孤立鎖定

這種情況可能是由控制執行緒導致的，該執行緒鎖定了 Berkeley DB 資料庫頁面，並在退出時未釋放鎖定。若要確認此問題，請執行 cshttpd 程序上的 pstack，並執行 csadmind。(pstack 是標準的 UNIX 公用程式，其位於：/usr/bin/pstack)。該公用程式將顯示等待以獲得鎖定的執行緒。

若要修正此問題，請重新啟動 Calendar Server，如下所示：

步驟

  1. 變更至 start-cal 所在的目錄。

    cd cal_svr_base/SUNWics5/cal/sbin

  2. 發出 start-cal 指令。

    ./start-cal

Procedurecsdb rebuild 無法完成 – 資料庫迴圈

資料庫迴圈通常是由資料庫檔案中的損毀導致的。由於是資料庫損毀，故無法復原。有數個選項：

步驟

  1. 復原至緊急備份。

    如果損毀是最近發生的，則可使用一個緊急備份。

  2. 使用突變歸檔回復程序。

    如需建議使用的程序，請參閱復原自動備份副本。

  3. 使用傾印和重新載入程序，使用傾印和載入程序回復行事曆資料庫。

重建已損毀的行事曆資料庫

本小節說明如何使用 csdb rebuild 指令，其中包含以下主題：

rebuild 簡介

rebuild 指令掃描行事曆資料庫，並檢查行事曆特性 (calprop) 事件和待辦事項 (工作) 是否損毀。如果 rebuild 指令找到不一致性，其會在 cal_svr_base/SUNWics5/cal/sbin/rebuild_db 目錄中產生重建行事曆資料庫 (.db 檔案)。

不帶有 -g 選項的 rebuild 指令重建除群組排程引擎 (GSE) 資料庫之外的所有資料庫。若還要重建 GSE 資料庫，請包含 -g 選項。

若要確定 GSE 資料庫中是否有項目，請在執行 rebuild 指令之前執行 csschedule -v list 指令，然後使 GSE 處理完那些項目。

Procedure重建行事曆資料庫

步驟

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

  2. 停止 Calendar Server。

  3. 建立行事曆資料庫副本，並將行事曆資料庫置於 /tmp/db 目錄中。

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

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

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


    cd /opt/SUNWics5/cal/sbin
    備註 –

    如果 sbin 目錄的磁碟空間不足，請在其他目錄中執行 rebuild 指令。

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


    ./csdb rebuild /tmp/db /tmp/

    如果未指定資料庫路徑，rebuild 將使用目前的目錄。/tmp/ 參數為重建資料庫指定目標目錄。

    若還要重建 GSE 資料庫，請包含 -g 選項。

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

    備註 –

    請始終使用最新的備份複本重建您的行事曆資料庫。

    然而，如果您的資料大量遺失，而您已經定期備份了資料庫並有多個複本可用，請從最新的複本到最舊的複本進行重建。(唯一的缺點是已刪除的行事曆元件將重新出現在重建資料庫中。)

    例如，如果您有三組備份行事曆資料庫檔案，分別在目錄 db_0601、db_0615 及 db_0629 中，請按以下序列執行 rebuild 指令：


    ./csdb rebuild db_0629 
./csdb rebuild db_0615 
./csdb rebuild db_0601

    然後 rebuild 指令會將重建資料庫寫入 cal_svr_base/SUNWics5/cal/sbin/rebuild_db 目錄。

  6. rebuild 完成後，請複查 rebuild.out 檔案中的輸出。

    如果重建成功，rebuild.out 檔案中的最後一行應為：


    Calendar database has been rebuilt

  7. 驗證在先前步驟中的重建成功之後，請從 rebuild_db 目錄將重建資料庫 (.db) 檔案複製到您的生產資料庫。

  8. 如果您有任何已毀壞資料庫的共用 (__db.*) 檔案或記錄 (log.*) 檔，請將其移至其他目錄。

  9. 重新啟動 Calendar Server。

重建輸出範例

以下範例顯示指令及其產生的輸出：


# ./csdb -g rebuild
Building calprops based on component information.
Please be patient, this may take a while...
Scanning events database...
512 events scanned
Scanning todos database...
34 todos scanned
Scanning events database...
512 events scanned
Scanning todos database...
34 todos scanned
Scanning deletelog database...
15 deletelog entries scanned
Scanning gse database...
21 gse entries scanned
Scanning recurring database...
12 recurring entries scanned
Successful components db scan
Calendar database has been rebuilt
Building components based on calprops information.
Please be patient, this may take a while...
Scanning calprops database to uncover events...
25 calendars scanned
Scanning calprops database to uncover todos...
25 calendars scanned
Successful calprops db scan
Calendar database has been rebuilt
備註 –

前面的輸出範例顯示事件資料庫和待辦事項資料庫分別被掃描了兩遍。這不是錯誤。掃描第一遍以驗證行事曆特性資料庫中的資訊，然後再掃描一遍以確定行事曆特性資料庫可存取。

使用傾印和載入程序回復行事曆資料庫

本小節包含以下主題：

傾印和載入概況

使用傾印和載入程序以嘗試復原已損毀的資料庫。傾印和載入程序使用 Berkeley 資料庫 db_dump 和 db_load 公用程式，Calendar Server 在以下目錄中提供這些公用程式：


cal_svr_base/SUNWics5/cal/tools/unsupported/bin

db_dump 公用程式使用與 db_load 公用程式相容的格式，來讀取資料庫檔案並將資料庫項目寫入輸出檔案。

如需有關 db_dump 和 db_load 公用程式的文件，請參閱 Sleepycat Software 網站：

http://www.sleepycat.com/docs/utility/index.html

使用 db_dump 和 db_load 公用程式回復資料庫成功與否取決於資料庫的損毀程度。在成功地回復資料庫之前，您可能需要嘗試多個 db_dump 選項。但是，如果您的資料庫嚴重毀壞，回復也許是不可能的，您可能需要復原至資料庫的最後一個完好的緊急備份或歸檔檔案備份。

備註 –

在執行傾印和載入程序之前，行事曆資料庫必須為 Berkeley DB 3.2.9 版，或更高版本。如果您的版本是舊版，請首先執行 cs5migrate 公用程式以對您的行事曆資料庫進行升級。

如需 cs5migrate 的最新版本，請致電 Sun 技術支援。

Procedure執行傾印和載入程序

步驟

  1. 以執行 Calendar Server 的使用者與群組 (例如 icsuser 與 icsgroup) 身份登入，或以超級使用者 (root) 身份登入。

  2. 如有必要，請停止 Calendar Server。

  3. 使用公用程式 (例如 csbackup、Sun StorEdge Enterprise BackupTM 軟體或 Legato Networker®) 備份已毀壞的資料庫。

    如需更多資訊，請參閱第 17 章, 備份與復原 Calendar Server 資料 。

  4. 使用 db_dump 公用程式傾印每個已毀壞的資料庫檔案。

    資料庫檔案為 ics50calprops.db、 ics50journals.db、ics50alarms.db、ics50events.db、ics50todos.db 和 ics50gse.db。

    請依次使用以下選項執行 db_dump，直到已回復資料庫 (或直到您確定無法回復資料庫) 為止：

    • No 選項，用於次要資料庫損毀。

    • -r 選項，用於中度資料庫損毀。

    • -R 選項，用於嚴重資料庫損毀。-R 選項從已毀壞的資料庫中傾印的資料要比 -r 選項多，包括部分已刪除的記錄。

      例如，配合執行 db_dump 與 -r 選項：


      db_dump -r ics50events.db \> ics50events.db.txt

  5. 使用 db_load 公用程式將輸出檔案載入至新的資料庫檔案。

    例如：


    db_load new.ics50events.db < ics50events.db.txt

    如果 db_load 報告的鍵值或資料項目為奇數，請編輯 db_dump 輸出檔案，並移除奇數鍵值或資料項目。然後再次執行 db_load。

  6. 對其他已毀壞的資料庫檔案重複前面的兩個步驟。

    亦即對其他已毀壞的資料庫檔案執行 db_dump。

  7. 使用 csdb rebuild 指令重建回復的資料庫檔案，如重建已損毀的行事曆資料庫中所述。

    rebuild 完成後，請複查輸出檔案中的輸出。如果重建成功，rebuild.out 檔案中的最後一行應為：


    Calendar database has been rebuilt

    如果 csdb rebuild 指令未成功，請使用下一個 db_dump 選項 (-r 或 -R) 傾印資料庫。

    如果 db_dump -R 選項無法回復已毀壞的資料庫，請與 Sun Microsystems 技術支援或銷售客戶代表連絡，以尋求援助。同時，您可能需要復原至您資料庫的最後一個完好備份。

復原自動備份副本

如果您已使用第 10 章, 配置自動備份 (csstored)中所述的自動備份功能，則可以在即時資料庫毀壞時使用緊急備份副本。

本小節包括如何復原兩種不同的自動備份：

復原之前

復原備份之前，請確定您已經完成以下作業：

Procedure復原緊急備份

即時資料庫被毀壞時，應首先選擇緊急備份。若要復原緊急備份，請執行以下步驟：

步驟

  1. 識別所有未套用的或開啟以備在已損毀的即時資料庫目錄中寫入的記錄檔。

  2. 關閉開啟以備寫入的記錄。它包含最新作業事件。

  3. 建立新的 (回復) 目錄。

  4. 將目前的緊急備份副本複製到新的回復資料庫目錄中。

  5. 將已毀壞的即時資料庫目錄中的 log.* 檔案複製到新的回復資料庫目錄中。

  6. 如果您保留了資料庫的歸檔檔案副本，請將尚未套用於即時資料庫的記錄複製到歸檔檔案目錄，這樣您的歸檔檔案備份副本就完整了。

  7. 配合執行 db_recover 與針對新的回復資料庫指定的 -c -h 選項。

    例如，如果新的回復目錄名為 recoverydb，則指令將如下所示：

    db_recover -c -h recoverydb

  8. 將 log.* 檔案保留在新的回復目錄中。

    db_recover 程式將記錄檔套用於新的回復資料庫，但是從 4.2 版開始，Berkeley DB 要求保留這些記錄檔。

  9. 對新的回復目錄中的資料庫檔案執行 db_verify。

    如需說明，請參閱檢查行事曆資料庫是否損毀。

  10. 對新的回復目錄執行 csdb -v list。

  11. 如果新的回復目錄通過了前面所有三個回復步驟，請用新的回復資料庫替代舊的已損毀的即時資料庫。

  12. 將新的即時資料庫複製到緊急備份目錄中，以做為新的快照執行。

    在拍攝下個常規快照之前，所有新記錄將被套用於此副本。

  13. 啟動 CalendarServer。

  14. 如果新的回復目錄在任何一個步驟中失敗，請按照如下說明識別未毀壞的更舊的緊急備份：

    1. 向後執行緊急備份，透過依次在每個緊急備份上執行 db_verify 和 csdb -v list 尋找未毀壞的最新副本。

    2. 通過的第一個緊急備份可以被復原至即時資料庫目錄。

      使用未使用的緊急備份替代已毀壞的即時資料庫，如復原緊急備份中所述。(請務必首先閱讀復原之前。)

    3. 如果無緊急備份可用且您沒有可嘗試的歸檔檔案備份，請致電技術支援。如果您有歸檔檔案備份，請遵照復原歸檔檔案備份之後的程序。(另請參閱復原之前。)

Procedure復原歸檔檔案備份

如果您沒有未損毀的緊急備份，但有歸檔檔案備份及其作業事件記錄，則可以透過執行以下步驟復原已歸檔資料庫的最新未損毀版本：

步驟

  1. 識別所有未套用的或開啟以備在已損毀的即時資料庫目錄中寫入的記錄檔。

  2. 關閉開啟以備寫入的記錄。它包含最新作業事件。

  3. 建立新的 (回復) 目錄。

  4. 將最新的歸檔檔案副本及其記錄檔複製到新的回復資料庫目錄。

  5. 將已毀壞的即時資料庫目錄中的任何未套用的 log.* 檔案複製到新的回復資料庫目錄中。

  6. 配合執行 db_recover 與針對新的回復資料庫指定的 -c -h 選項。

    例如，如果新的回復目錄名為 recoverydb，則指令將如下所示：

    db_recover -c -h recoverydb

  7. 將 log.* 檔案保留在新的回復目錄中。

    db_recover 程式將記錄檔套用於新的回復資料庫，但是從 4.2 版開始，Berkeley DB 要求仍舊將這些記錄檔保留在此處。

  8. 對新的回復目錄中的資料庫檔案執行 db_verify。

    如需說明，請參閱檢查行事曆資料庫是否損毀。

  9. 對新的回復目錄執行 csdb -v list。

  10. 如果新的回復目錄通過了前面所有三個回復步驟，請用新的回復資料庫替代舊的已損毀的即時資料庫。

  11. 將新的即時資料庫複製到緊急備份目錄中，以作為新的快照執行。

  12. 啟動 CalendarServer。

  13. 如果新的回復目錄在任何一個步驟中失敗，請按照如下說明識別未損毀的更舊的歸檔檔案備份：

    1. 向後執行歸檔檔案備份副本，透過依次對每一個歸檔檔案備份副本執行以下三個回復程式以尋找未損毀的最新副本：db_recover -c-h、db_verify 和 csdb -v list。

    2. 通過的第一個歸檔檔案副本可以被復原至即時資料庫目錄。

      使用未使用的歸檔檔案備份替代已毀壞的即時資料庫，如復原歸檔檔案備份中所述。

    3. 如果您的歸檔檔案備份都不可用，請致電技術支援。

修復自訂備份程序檔

本小節包含以下主題：

使用動態式庫編譯的 Berkeley 工具

如果您已使用 Berkeley 資料庫工具 (例如 db_recover) 建立自訂備份程序檔，則可能會發現升級至 Calendar Server 後，該程序檔無法再工作。其原因是：舊版 Calendar Server 使用靜態式庫編譯工具。現在使用動態程式庫 (libdb-4.2.so) 編譯工具。

修復自訂備份程序檔

若要將現有的自訂程序檔與新的動態式庫一同使用，請按如下所示設定以下全域變數：

LD_LIBRARY_PATH=libdb-4.2.so