test

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

第 22 章 疑難排解

本章包括一些可以用於確定系統是否有問題以及問題出現之原因的疑難排解技術。本章包含以下主題：

啟用除錯資訊

由於沒有一個可以將整個系統置於「除錯模式」的 ics.conf 參數，所以本小節說明一些獲得有用除錯資訊的方法：

備註 –

確定關閉不需要的多餘記錄和監視，否則將對效能起負面影響。

提昇記錄層級

使用下表中顯示的參數提昇記錄詳細度：

參數 

說明和預設值 

logfile.loglevel

設定為 DEBUG 以記錄所有層級，包括 CRITICAL、ALERT、ERROR、WARNING、NOTICE 和 INFORMATION。此設定可套用於所有記錄。

如需有關可用的不同記錄的更多資訊，請參閱使用 Calendar Server 記錄檔。

啟用對 LDAP 快取記憶體的存取記錄

若要記錄對 LDAP 資料快取記憶體的所有存取情況並列印記錄 (報告)，請設定下表中所顯示的 ics.conf 參數。

參數 

說明和預設值 

local.ldap.cache.stat.enable

指定是否在記錄檔中記錄對 LDAP 資料快取記憶體的存取情況並列印統計資料。預設為 “no” (無記錄的統計)。設定為 “yes” 以啟用對統計的記錄。

若要增強效能，請僅在除錯模式中使用此設定。 

local.ldap.cache.stat.interval

指定各統計資料報告寫入記錄檔的間隔時間 (以秒為單位)。預設為 “1800” 秒 (30 分鐘)。

此預設僅在記錄啟用時才處於作用中。縮短間隔可以協助您準確地確定問題所在。增加間隔將會減緩系統載入。 

清除 LDAP 快取記憶體

目前 Calendar Server 中沒有使 LDAP 快取記憶體資料過期的邏輯。您必須手動移除 ldap_cache 目錄的內容並重新啟動 Calendar Server。

Procedure清除 LDAP 快取記憶體

步驟

  1. 停止 Calendar Server。

  2. 移除 /var/opt/SUNWics5/csdb/ldap_cache 目錄中的所有檔案，但請勿移除 ldap_cache 目錄本身。

  3. 重新啟動 Calendar Server。

使用 Calendar Server 公用程式監視系統

使用以下公用程式監視系統：

如需有關 Calendar Server 公用程式的更多資訊，請參閱附錄 DCalendar Server 指令行公用程式參照。

LDAP 問題的疑難排解

如果您是首次建立託管環境，則必須透過增加適當的網域、容器、使用者和資源項目在 LDAP 中建立 DC 樹狀結構。如果使用 Calendar Server 公用程式 (例如 cscal) 時 DC 樹狀結構尚不存在，您可能會看到以下錯誤訊息：「Initialization failed .... exiting」。

確定您的 DC 樹狀結構在 DC 樹狀結構根目錄下至少包含一個 (預設) 網域。使用建立新的託管網域中的說明建立 DC 樹狀結構。

遷移公用程式的疑難排解

Calendar Server 提供了數個用於遷移行事曆資料庫和 LDAP 目錄的公用程式。本小節包含以下主題：

呼叫技術支援之前所要執行的工作

一般情況下，如果您在使用遷移公用程式時遇到疑難，則應該先收集好以下資訊，然後聯絡技術支援：

遷移公用程式的位置

各遷移公用程式及其文件位於以下清單中所指定的位置：

模式遷移公用程式 (commdirmig)

此公用程式隨附於 Delegated Administrator，是一個可獨立安裝元件。它可將您的 LDAP 目錄從 Schema 1 遷移至 Schema 2。如需有關此公用程式的資訊，請參閱「Sun Java System Communications Services 6 2005Q4 Schema Migration Guide」。

Calendar Server 5 至 Calendar Server 6 遷移公用程式 (cs5migrate)

技術支援提供了包括公用程式及其文件的遷移程式集。

Calendar Server 遷移公用程式 (csmig)

此公用程式與 Calendar Server 一同安裝。文件位於第 4 章, 資料庫遷移公用程式中，其中包括疑難排解小節。如果您要使用託管網域和 LDAP 行事曆查找資料庫 (CLD) 外掛程式，則必須執行此公用程式。

Calendar Server 虛擬網域遷移公用程式 (csvdmig )

此公用程式與 Calendar Server 一同安裝。文件位於第 4 章, 資料庫遷移公用程式中。使用此公用程式為托管網域準備行事曆資料庫和 LDAP 目錄項目。

Calendar Server 2 至 Calendar Server 6 遷移公用程式 (ics2migrate)

此公用程式與 Calendar Server 一同安裝。文件位於第 4 章, 資料庫遷移公用程式中。使用此公用程式遷移 Calendar Server 2 資料庫，以與 Calendar Server 5 相容。

Netscape Calendar Server 4 至 Calendar Server 5 遷移公用程式 (ncs4migrate)

此公用程式僅可從技術支援獲得。公用程式套裝軟體中包含相關文件。此公用程式可將 Netscape Calendar Server 4 遷移至 Calendar Server 5。這些遷移需要特別注意，因為來源資料庫中缺乏一致性。與許多手冊相同，此公用程式僅可從技術支援獲得。公用程式套裝軟體中包含相關文件。此公用程式可將 Netscape Calendar Server 4 遷移至 Calendar Server 5。這些遷移需要特別注意。通常需要對原始碼檔案執行許多工作，此公用程式才可以執行。可以考量使用專業服務協助您規劃遷移。

Calendar Server 的疑難排解

本小節包括多種用於非資料庫問題的疑難排解方法。本小節包括以下主題：

提示 –

此外，在 SSL 章節中還包含 SSL 疑難排解小節：

SSL 的疑難排解

對行事曆服務執行 Ping 作業

若要驗證服務是否在偵聽指定的連接埠號，請使用cstool 公用程式的 ping 指令。對某種服務執行 ping 作業不會驗證該服務是否確實正在執行，但會指示該服務是否可以接受套接字連線。

cstool 的服務選項

Calendar Server 服務選項為：

http

HTTP 服務 (cshttpd)

admin

管理服務 (csadmind)

ens

事件通知服務 (enpd)

備註 –

您無法對 DWP 服務 (csdwpd) 或通知服務 (csnotifyd) 執行 ping 作業。

cstool 範例

例如，對主機名稱為 calserver 的機器執行 ping 作業，以查看 cshttpd 服務是否正在偵聽連接埠 80：

cstool -p 80 -h calserver ping http

依預設，cstool 會等待 120 秒，以查看有無回應；但您可以使用 -t timeout 選項變更該值。

如需完整的公用程式參考材料，請參閱附錄 DCalendar Server 指令行公用程式參照。

備註 –

必須執行 Calendar Server，才能執行 cstool。

Procedure修正 start-cal 問題

如果發出 start-cal 時未能啟動所有的行事曆服務，則必須先停止啟動的服務，然後再重新啟動。例如，如果 enpd、csnotifyd 和 csadmind 已啟動，但 cshttpd 未啟動，則必須停止 enpd、csnotifyd 和 csadmind。

若要啟動行事曆服務，請：

步驟

  1. 以對 Calendar Server 執行時所在的系統具有管理權限的使用者身份登入。

  2. 使用 start-cal 停止服務，然後再重新啟動服務。例如：

    cal_svr_base/SUNWics5/cal/sbin/start-cal

    start-cal 首先發出 stop-cal 指令，然後才啟動各種行事曆服務。

  3. 如果 stop-cal 未能停止服務，則可能是因為某些子程序沒有停止。若要處理此情況，請參閱修正 stop-cal 問題。

修正 stop-cal 問題

關閉時需要考量以下兩個不同的問題：

Procedure停止子程序

發出 stop-cal 後，很可能未停止某些子程序。例如，stop-cal 可能停止了 cshttpd 父系程序，但未停止任何 cshttpd 子程序。在此情況下，您必須使用以下程序分別停止其餘 Calendar Server 程序：

步驟

  1. 以對 Calendar Server 執行時所在的系統具有管理權限的使用者身份登入。

  2. 透過為每種服務輸入 ps 指令，確定其餘 Calendar Server 程序的程序 ID (PID)：


    ps -elf | grep cs-process

    其中 cs-process 為 enpd、csnotifyd、csdwpd、csadmind 或 cshttpd。例如：


    ps -elf | grep cshttpd

  3. 使用仍在執行的各程序的 PID，輸入 kill -15 指令強制結束該程序。例如：kill -15 9875

  4. 再次輸入各 ps 指令，以確定所有 Calendar Server 程序均已停止。


    If a Calendar Server process is still running, 
   enter a kill -9 command to kill it. 
For example: kill -9 9875
    備註 –

    在執行 Calendar Server 的 Linux 系統上，如果您使用 ps 指令搜尋行事曆程序，其結果可能會令人費解。在 Linux 上，ps 指令傳回正在執行的執行緒清單，而非程序清單。尚無可以僅顯示程序的已知解決方法。

Procedure不正確關閉後回復

如果 Calendar Server 未正確關閉，請執行以下步驟：

步驟

  1. 執行先前程序修正 stop-cal 問題中的步驟。

  2. 手動刪除 LDAP 資料快取記憶體資料庫目錄中的所有檔案。

    這些剩餘檔案可能會毀壞資料庫。若要刪除這些檔案，請：

    1. 變更至 LDAP 資料快取記憶體目錄。

      預設為 /opt/SUNWics5/csdb/ldap_cache，但是請使用 ics.conf 檔案中的 local.ldap.cache.homedir.path 參數所指向的目錄。

    2. 移除目錄中的所有檔案。

      例如： rm *.*

    3. 檢查以確定已移除所有檔案。

      例如： ls

  3. 重新啟動 Calendar Server。

    cal_svr_base /SUNWics5/cal/sbin/start-cal

    如需有關如何配置 LDAP 資料快取的說明，請參閱為 LDAP 配置 Calendar Server。如需有關 LDAP 資料快取記憶體的更多資訊，請參閱「Sun Java System Communications Services 6 2005Q4 Deployment Planning Guide」。

無法連線至後端伺服器

  1. 對後端伺服器執行 ping 作業以檢查它是否有回應。

    如果有回應，請移至步驟 3。如果沒有回應，請確定其失敗原因及其何時可以再次工作，然後繼續

  2. 清除 CLD 快取記憶體。請參閱清除 CLD 快取記憶體。

    如果您要使用 CLD 快取記憶體選項並且已更新 ics.conf 參數的伺服器名稱，則應清除 CLD 快取記憶體以移除伺服器名稱。CLD 快取記憶體中的過期項目會妨礙前端伺服器建立與正確後端伺服器之間的連線，或會導致某個行事曆在被移動後，Calendar Server 無法找到該行事曆。

  3. 重新啟動 Calendar Server。

找不到行事曆

如果您要使用 CLD 快取記憶體選項並且已將一個或多個行事曆移至其他後端伺服器上 (或者變更了後端伺服器的名稱)，請執行以下步驟：

  1. 確定執行用於移動行事曆的程序，該程序位於：

    管理使用者行事曆。

  2. 清除 CLD 快取記憶體。請參閱清除 CLD 快取記憶體。

    如果您將一個或多個行事曆移動至其他後端伺服器上，則 CLD 快取記憶體將會過期。若要更新快取記憶體，您需要將其清除以便重建。

嘗試使用代理伺服器認證登入時，系統會提示您「未授權」

  1. 驗證 service.http.allowadminproxy 是否已設定為 “yes”。

  2. 驗證 admin-user 是否具有 Calendar Server 管理員權限。

  3. 驗證 admin-password 是否正確。

  4. 驗證 calendar-user 是否為有效的 Calendar Server 使用者。

未正確完成的搜尋的疑難排解

LDAP 目錄伺服器配置中的 nsslapd-sizelimit 與 nsLookthroughLimit 屬性的值必須足夠大，以便搜尋可以正確完成。如果 nsSizeLimit 的值不夠大，可能會發生截斷，並且不會顯示任何結果。如果 nsLookthroughLimit 的值不夠大，搜尋可能無法完成。

本小節包含以下主題：

Procedure確定限制屬性是否有適當的值

步驟

  1. 若要確定這些屬性是否已設定為適當的值，請嘗試以下指令：

    ldapsearch -b "base " "(&(icscalendarowned=*user*)(objectclass=icsCalendarUser))"

    其中 base 為 Calendar Server 的使用者和資源資料所在的目錄伺服器的 LDAP 基底 DN，而 user 為一般使用者可在使用者介面中搜尋對話方塊中輸入的值。

  2. 如果 LDAP 伺服器傳回錯誤，可能是 nsSizeLimit 參數或 nsLookthroughLimit 參數的值不夠大。

Procedure將限制屬性設定為適當的值

這些屬性的 DN 為：

dn: cn=config,cn=ldbm databases,cn=plug ins,cn=config

步驟

  1. 使用 ldapmodify 動態設定 nsLookthroughLimit 的值。

    您不必停止再重新啟動 Directory Server 以變更此屬性。

    預設值為 5000。如果搜尋沒有報告結果，您可能要增加此值。但是，這可能會減緩 LDAP 伺服器。

    如果可能，請將限制設定為 -1，從而不加任何限制。但是，請謹慎執行此作業，因為該作業可能會導致系統當機。

  2. 如果您要將 nsslapd-sizelimit 設定為更高的值，則必須執行以下步驟：

    1. 停止 Directory Server。

    2. 編輯 dse.ldif 檔案。

    3. 重新啟動目錄伺服器。

      備註 –

      如需有關如何使用 ldapmodify 和編輯 dse.ldif 檔案的資訊，請參閱 Directory Server 文件，位於：

      http://docs.sun.com/coll/1316.1 和 http://docs.sun.com/coll/1419.1

從 csstored 關閉令人生厭的每日訊息

依預設，start-cal 指令啟動 csstored 程序 (即使其尚未配置)。未配置的 csstored 程序將在執行 csstored 的每台機器上每隔 24 小時發出一次訊息，說明其尚未配置。

若要停用該訊息，請防止 csstored 在未配置的情況下執行。若要停止 csstored 程序執行，請為產生訊息的每台機器設定如下所示的 ics.conf 參數：

service.store.enable=”no”

請小心不要停用已配置 csstored 以進行自動備份的機器上的程序。

關於資料庫問題

本小節包括關於 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