第 18 章 管理“删除日志”数据库

Calendar Server 包括“删除日志”数据库 (ics50deletelog.db)，该数据库用来存储已删除的事件和待办事项（任务）。

在早期版本中，Calendar Server 没有提供维护已删除事件和任务的数据库。存储日历事件和任务的本地副本的用户界面很难确定已删除了哪些事件。客户端软件不得不将所有事件或待办事项（任务）的唯一标识符 (uid) 或周期标识符 (rid) 与数据的 Calendar Server 副本进行比较，以确定已删除哪些组件。这种局限性直接影响了使用 WCAP 命令生成客户端用户界面 (UI) 的安装。为解决此局限性，创建了“删除日志”数据库。

与必须对所有数据库文件进行管理一样，也需要管理“删除日志”数据库。以下章节介绍了如何管理删除日志文件：

• 18.1 创建“删除日志”数据库

• 18.2 查询“删除日志”数据库

• 18.3 清理“删除日志”数据库

• 18.4 使用适用于“删除日志”数据库的 Calendar Server 实用程序

18.1 创建“删除日志”数据库

在 csdb 目录下除了创建其他 Calendar Server 数据库文件，Calendar Server 还将自动创建“删除日志”数据库 (ics50deletelog.db)。Calendar Server 按如下方式在“删除日志”数据库中写入事件和待办事项：

• 非重复性事件和待办事项

  删除非重复性事件或待办事项后，Calendar Server 将从“事件”数据库 (ics50events.db) 或“待办事项”数据库 (ics50todos.db) 中将其删除，然后将其写入“删除日志”数据库 (ics50deletelog.db)。

• 重复性事件和待办事项

  删除重复性事件或任务的单个实例后，Calendar Server 将把每个这样的实例写入“删除日志”数据库 (ics50deletelog.db)。

  重复性事件或待办事项的所有实例被删除后，Calendar Server 将从事件或待办事项数据库中删除主组件，然后将其写入“删除日志”数据库。“删除日志”数据库中的主组件将包含以下重复性参数：rrules、rdates、exrules 和 exdates。

18.2 查询“删除日志”数据库

本节说明如何查询“删除日志”数据库。

要从“删除日志”数据库返回条目，使用 WCAP 命令 fetch_deletedcomponents（不管是在扩展模式还是在压缩模式下）。

以下信息介绍指定每种模式的时间和方法。

• 扩展模式 (recurring = 0)

  如果 recurring 参数为 0，则 fetch_deletedcomponents 命令将返回符合条件的重复性事件的所有实例，但不会返回重复性事件的主组件。

• 压缩模式 (recurring = 1)

  如果 recurring 参数为 1，则 fetch_deletedcomponents 命令将返回非重复性事件和所有重复性事件的主组件，但不会返回单个重复性事件。

  如果删除了重复性链中的所有实例，则主组件将返回 dtstart、dtend、rrules、rdates、exrules、exdates 和 uid 参数。

  另外，fetch_deletedcomponents 命令不返回与已删除重复实例关联但仍处于活动状态的主组件。要返回活动的主组件，使用 WCAP 命令 fetchcomponents_by_lastmod。fetch_deletedcomponents 命令应该与 fetchcomponents_by_lastmod 命令一起使用。

有关 WCAP 命令的更多信息，参见《Sun Java System Calendar Server 6.3 WCAP Developer’s Guide 》。

18.3 清理“删除日志”数据库

本节说明如何清理“删除日志”数据库。Calendar Server 提供两种清理“删除日志”数据库的方法，即自动清理和手动清理。

本节包含以下主题：

• 18.3.1 调优“删除日志”清理

• 18.3.2 自动清理“删除日志”数据库

• 18.3.3 手动清理“删除日志”数据库

18.3.1 调优“删除日志”清理

在清理“删除日志”数据库前，需非常了解您正在为其提供服务的最终用户。如果最终用户使用的是 Communications Express，则默认的参数设置已足够。然而，如果他们使用的是存储事件和任务的本地副本的客户端用户界面（例如 Connector for Microsoft Outlook 或 Sync Tool），则必须调整自动清理配置参数的设置以满足其需求。通常，他们需要“删除日志”数据库包括 30 天甚至更多的条目。这样会显著增加“删除日志”的大小。如果调整失败，则会导致数据库出错。同样还应调整清理时间间隔以满足用户的需求。例如，在允许清理“删除日志”数据库之前，如果该数据库保留了 30 天的数据，则不应每分钟都运行清理。数据库的内容每天都会换出，因此一天执行一次清理比较合理。

手动运行 cspurge 时也会出现类似的问题。如果从“删除日志”中删除的内容过多，则会导致 Connector for Microsoft Outlook 和 Sync Tool 的用户无法与服务器数据库保持同步。

如果隔很长时间才清理一次“删除日志”数据库，可能会导致文件变得非常大。然后，在开始清理这些巨型文件时，日常事务日志也会明显增大，以反映每个被清理的项目都是一个记录到这些日志中然后又归档到归档和紧急备份中的一个事务。事务日志中的这些大型异常现象会使其显得系统似乎出现了故障，并且需花费时间来指明所发生的事情。

18.3.2 自动清理“删除日志”数据库

如果需要，可让 Calendar Server 在指定时间间隔内自动清理“删除日志”数据库中的条目。默认情况下，禁用自动清理。

下列 ics.conf 参数可控制自动清理功能。

表 18–1 自动清理“删除日志”数据库的配置参数

参数	说明
service.admin.purge.deletelog	启用 ("yes") 或禁用 ("no") 自动清理“删除日志”数据库 (ics50deletelog.db) 条目功能。 默认值为 "no"。
caldb.berkeleydb.purge.deletelog.interval	指定自动清理“删除日志”数据库 (ics50deletelog.db) 中条目的时间间隔（以秒为单位）。 默认值为 60 秒。
caldb.berkeleydb.purge.deletelog.beforetime	指定清理“删除日志”数据库 (ics50deletelog.db) 中条目前的时间（以秒为单位）。 默认值为 518400 秒（6 天）。

例如，要使 Calendar Server 每五分钟（300 秒）自动清理一次 2 天（172800 秒）前生成的“删除日志”数据库条目，按如下所示设置18.3.2 自动清理“删除日志”数据库中所述参数：

service.admin.purge.deletelog="yes"
 caldb.berkeleydb.purge.deletelog.interval=600
 caldb.berkeleydb.purge.deletelog.beforetime=172800

设置这些参数后，重新启动 Calendar Server 以使新值生效。

18.3.3 手动清理“删除日志”数据库

可选择使用 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。

18.4 使用适用于“删除日志”数据库的 Calendar Server 实用程序

下表列出了支持“删除日志”数据库 (ics50deletelog.db) 的 Calendar Server 实用程序。

表 18–2 支持“删除日志”数据库的实用程序

实用程序	说明
cspurge	允许手动清理“删除日志”数据库中的条目。
csbackup 和 csrestore	支持“删除日志”数据库的备份和恢复。
csstats	报告“删除日志”数据库的统计信息。
csdb	支持对“删除日志”数据库执行重建、恢复和检查操作。
cscomponents	列出（只读）“删除日志”数据库中的条目数。

有关更多信息（包括这些实用程序的语法），参见附录 D，Calendar Server 命令行实用程序参考。