Calendar Server 包含刪除記錄資料庫 (ics50deletelog.db),可以儲存已刪除的事件和待辦事項 (工作)。
在以前的發行版本中,Calendar Server 不維護已刪除事件和工作的資料庫。儲存行事曆事件及工作之本機副本的使用者介面難以判斷已刪除的事件。用戶端軟體被迫將所有事件或待辦事項 (工作) 的唯一識別碼 (uid) 或週期性識別碼 (rid) 與資料的 Calendar Server 副本做比較,以判斷刪除了哪些元件。這一限制直接影響到使用 WCAP 指令開發用戶端使用者介面 (UI) 的各個安裝。為解決此限制,已建立刪除記錄資料庫。
如同任何資料庫檔案一樣,刪除記錄也需加以管理。以下小節描述如何管理刪除記錄檔:
Calendar Server 自動在 csdb 目錄中建立刪除記錄資料庫 (ics50deletelog.db) 及其他 Calendar Server 資料庫檔案。Calendar Server 會將事件和待辦事項寫入刪除記錄資料庫,如下所示:
非週期性事件和待辦事項
刪除某個非週期性事件或待辦事項時,Calendar Server 會將其從事件資料庫 (ics50events.db) 或待辦事項資料庫 (ics50todos.db) 中移除,然後將其寫入刪除記錄資料庫 (ics50deletelog.db) 中。
週期性事件和待辦事項
刪除某個週期性事件或工作的個別實例時,Calendar Server 會將該事件或工作的每個已刪除實例寫入刪除記錄資料庫 (ics50deletelog.db) 中。
刪除某個週期性事件或待辦事項的所有實例時,Calendar Server 會將主要元件從事件或待辦事項資料庫中刪除,然後將其寫入刪除記錄資料庫中。刪除記錄資料庫中的主要元件包含 rrules、rdates、exrules 及 exdates 週期性參數。
本小節描述如何查詢刪除記錄資料庫。
若要從刪除記錄資料庫傳回項目,請以展開模式或壓縮模式使用 fetch_deletedcomponents WCAP 指令:
以下資訊說明何時及如何指定每一種模式。
展開模式 (recurring = 0)
如果 recurring 參數為 0,則 fetch_deletedcomponents 會傳回符合條件的週期性事件之所有實例,但不傳回週期性事件的主要元件。
壓縮模式 (recurring = 1)
如果 recurring 參數為 1,則 fetch_deletedcomponents 會傳回非週期性事件以及所有週期性事件的主要元件,但不傳回個別週期性事件。
如果刪除了週期性鏈中的所有實例,則主要元件會傳回 dtstart、dtend、rrules、rdates、exrules、exdates 及 uid 參數。
此外,fetch_deletedcomponents 指令不會傳回與仍處於使用中的已刪除週期性實例相關的主要元件。若要傳回使用中的主要元件,請使用 fetchcomponents_by_lastmod WCAP 指令。fetch_deletedcomponents 指令應與 fetchcomponents_by_lastmod 指令配合使用。
如需有關 WCAP 指令的更多資訊,請參閱 「Sun Java System Calendar Server 6.3 WCAP Developer’s Guide」。
本小節描述如何清除刪除記錄資料庫。Calendar Server 提供兩種清除刪除記錄資料庫的類型:自動及手動。
本小節包含以下主題:
清除刪除記錄資料庫之前,您需要深知您正在服務的一般使用者。如果您的一般使用者正在使用 Communications Express,則預設參數設定應該足夠了。不過,如果他們正在使用儲存事件及工作本機副本的用戶端使用者介面,例如 Connector for Microsoft Outlook 或 Sync Tool,則您必須調整自動清除配置參數的設定,以符合他們的需求。通常,他們需要刪除記錄包含長達 30 天或更長日期的項目。這將導致刪除記錄的大小顯著增長。如果未能做出這種調整,會導致資料庫發生問題。清除間隔也應該進行調整,以符合使用者的需求。例如,在您的刪除記錄資料庫將資料保留 30 天才允許清除的情況下,每分鐘執行清除可能沒有意義。由於事情每天都會變舊,所以每天清除是合理的。
手動執行 cspurge 時,也會發生類似的問題。如果從刪除記錄移除了太多,則它會導致 Connector for Microsoft Outlook 及 Sync Tool 的使用者與伺服器資料庫失去同步。
若等待很久才清除刪除記錄資料庫,會導致檔案變得非常的大。然後,當發生大量清除時,日常作業事件記錄會大量增加,以反映這樣的事實:每一個清除的項目都是記錄在那些記錄中並歸檔到歸檔備份及緊急備份的作業事件。作業事件記錄中的這些大量異常會讓系統看起來像有問題,並因為不瞭解發生什麼情況而浪費時間。
如果願意,您可以讓 Calendar Server 以指定的間隔自動清除刪除記錄資料庫中的項目。自動清除依預設為停用。
以下 ics.conf 參數控制自動清除功能。
表 18–1 用於自動清除刪除記錄資料庫的配置參數
參數 |
說明 |
---|---|
啟用 ("yes") 或停用 ("no") 自動清除刪除記錄資料庫 (ics50deletelog.db) 項目。 預設為 "no"。 |
|
指定自動清除刪除記錄資料庫 (ics50deletelog.db) 中項目的間隔時間 (以秒為單位)。 預設為 60 秒。 |
|
指定一個時間 (以秒為單位),清除刪除記錄資料庫 (ics50deletelog.db) 中早於此時間的項目。 預設為 518400 秒 (6 天)。 |
例如,若要使 Calendar Server 每隔五分鐘 (600 秒) 自動清除一次刪除記錄資料庫中超過兩天 (172800 秒) 的項目,請如下設定18.3.2 自動清除刪除記錄資料庫中的參數:
service.admin.purge.deletelog="yes" caldb.berkeleydb.purge.deletelog.interval=600 caldb.berkeleydb.purge.deletelog.beforetime=172800
設定這些參數後,重新啟動 Calendar Server 以使新值生效。
您可以使用 cspurge 公用程式,選擇手動清除刪除記錄資料庫 (ics50deletelog.db) 中的項目。
這個公用程式的用法如下:
cspurge -e endtime -s starttime
變數 endtime 及 starttime 指定結束和開始時間,且為祖魯時間 (也就是 GMT 或 UTC)。
若要執行 cspurge,您必須以執行 Calendar Server 的使用者及群組身份 (預設值為 icsuser 及 icsgroup) 或以 root 身份登入。
例如,清除從 2003 年 7 月 1 日到 2003 年 7 月 31 日的項目:
cspurge -e 20030731T235959Z -s 20030701T120000Z
如需更多資訊,請參閱D.13 cspurge。
下表列出了支援刪除記錄資料庫 (ics50deletelog.db) 的 Calendar Server 公用程式。
表 18–2 支援刪除記錄資料庫的公用程式
公用程式 |
說明 |
---|---|
cspurge |
允許手動清除刪除記錄資料庫中的項目。 |
csbackup 及 csrestore |
支援刪除記錄資料庫的備份與復原。 |
csstats |
報告刪除記錄資料庫統計資料。 |
csdb |
支援對刪除記錄資料庫的重建、回復以及檢查作業。 |
cscomponents |
列出 (唯讀) 刪除記錄資料庫中的項目數。 |
如需更多資訊 (包括這些公用程式的語法),請參閱附錄 DCalendar Server 指令行公用程式參照。