Sun Java System Calendar Server 6.3 Administration Guide

Chapter 18 Administering the Delete Log Database

Calendar Server includes the Delete Log database (ics50deletelog.db) to store deleted events and todos (tasks).

In early releases, Calendar Server did not maintain a database of deleted events and tasks. User interfaces that store a local copy of the calendar events and tasks had difficulty trying to determine which events had been deleted. Client software was forced to compare the unique identifiers (uid) or recurrence identifiers (rid) of all events or todos (tasks) with the Calendar Server copy of the data in order to determine which components had been deleted. This limitation directly affected installations that used WCAP commands to develop a client user interface (UI). To solve this limitation, the delete log database was created.

Delete logs need to be managed, as any database file must be. The following sections describe management of deletelog files:

18.1 Creating the Delete Log Database

Calendar Server automatically creates the Delete Log database (ics50deletelog.db) in the csdb directory along with the other Calendar Server database files. Calendar Server writes events and todos to the Delete Log database as follows:

Non-Recurring Events and Todos

When a non-recurring event or todo is deleted, Calendar Server removes it from the Events database (ics50events.db) or Todos database (ics50todos.db) and then writes it to the Delete Log database (ics50deletelog.db).
Recurring Events and Todos

When individual instances of a recurring event or task are deleted, Calendar Server writes each deleted instance of the event or task to the Delete Log database (ics50deletelog.db).

When all instances of a recurring event or todo are deleted, Calendar Server deletes the master component from the event or todo database and then writes it to the Delete Log database. A master component in the Delete Log database will contain the rrules, rdates, exrules, and exdates recurrence parameters.

18.2 Querying the Delete Log Database

This section describes how to query the delete log database.

To return entries from the Delete Log database, use the fetch_deletedcomponents WCAP command in either Expanded Mode or Compressed Mode.

The following information explains when and how to specify each mode.

Expanded Mode (recurring = 0)

If the recurring parameter is 0, fetch_deletedcomponents returns all instances of recurring events that match the criteria, but it does not return the master component for recurring events.
Compressed Mode (recurring = 1)

If the recurring parameter is 1, fetch_deletedcomponents returns non-recurring events and the master components for any recurring events, but it does not return individual recurring events.

If all instances in a recurring chain are deleted, the master component returns the dtstart, dtend, rrules, rdates, exrules, exdates, and uid parameters.

Also, the fetch_deletedcomponents command does not return master components associated with the deleted recurring instances that are still active. To return active master components, use the fetchcomponents_by_lastmod WCAP command. The fetch_deletedcomponents command should be used in conjunction with the fetchcomponents_by_lastmod command.

For more about WCAP commands, see the Sun Java System Calendar Server 6.3 WCAP Developer’s Guide.

18.3 Purging the Delete Log Database

This section describes how to purge the delete log database. Calendar Server provides two types of purging of the delete log database, automatic and manual.

This section contains the following topics:

18.3.1 Tuning Delete Log Purging

Before purging the delete log database, you need to be very aware of the end users you are serving. If your end users are using Communications Express, the default parameter settings should be adequate. If , however, they are using client user interfaces that store a local copy of the events and tasks, such as the Connector for Microsoft Outlook, or the Sync Tool, then you must adjust the settings of the automatic purge configuration parameters to fit their needs. Typically, they need the delete log to include up to 30 days or more of entries. This will cause the size of the delete log to increase dramatically. A failure to make this adjustment could cause problems with the database. The purge interval should also be adjusted to fit the needs of the users. For instance, there might not be a point in running purge every minute when your Delete log database is holding 30 days of data before it will be allowed to be purged. Things will age out daily, though, so a daily purge would be reasonable.

Similar problems can occur running cspurge manually. If too much is removed from the Delete log, it can cause users of the Connector for Microsoft Outlook and the Sync Tool to get out of sync with the server database.

Waiting too long to purge the Delete log database can cause the files to grow very large. Then, when a giant purge occurs, daily transaction logs grow greatly, reflecting the fact that each item purged is a transaction recorded in those logs and then archived to the archive and hot backups. These large anomalies in the transaction logs can make it appear as if there is a system problem and cause time to be lost figuring out what happened.

18.3.2 Automatic Purge of the Delete Log Database

If you wish, you can have Calendar Server automatically purge entries in the Delete Log database at a specified interval. By default the automatic purge is disabled.

The following ics.confparameter controls the automatic purge feature.

Table 18–1 Configuration Parameters for Automatic Purge of the Delete Log Database


Parameter	Description
`service.admin.purge.deletelog`	Enables (`"yes"`) or disables (`"no"`) the automatic purge of Delete Log database (`ics50deletelog.db`) entries. The default is `"no"`.
`caldb.berkeleydb.purge.deletelog.interval`	Specifies the interval time in seconds to automatically purge entries in the Delete Log database (`ics50deletelog.db`). The default is `60` seconds.
`caldb.berkeleydb.purge.deletelog.beforetime`	Specifies a time in seconds before which to purge entries in the Delete Log database (`ics50deletelog.db`). The default is `518400` seconds (6 days).

For example, to have Calendar Server automatically purge Delete Log database entries every five minutes (600 seconds) that are more than 2 days old (172800 seconds), set parameters in 18.3.2 Automatic Purge of the Delete Log Database as follows:

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

After you set these parameters, restart Calendar Server for the new values to take effect.

18.3.3 Manual Purge of the Delete Log Database

You can choose to manually purge entries in the Delete Log database (ics50deletelog.db), using the cspurge utility:

Usage of this utility is as follows:

cspurge -e endtime -s starttime

The variables endtime and starttime specify the ending and starting times in Zulu time (also referred to as GMT or UTC).

To run cspurge, you must be logged in as the user and group under which Calendar Server is running (defaults are icsuser and icsgroup) or as root.

For example, to purge entries from July 1, 2003 through July 31, 2003:

cspurge -e 20030731T235959Z -s 20030701T120000Z

For more information, see D.13 cspurge.

18.4 Using Calendar Server Utilities for the Delete Log Database

The following table lists the Calendar Server utilities that support the delete log database (ics50deletelog.db).

Table 18–2 Utilities that Support the Delete Log Database


Utility	Description
`cspurge`	Allows the manual purge of entries in the Delete Log database.
`csbackup` and `csrestore`	Supports the backup and restore of the Delete Log database.
`csstats`	Reports Delete Log database statistics.
`csdb`	Supports the rebuild, recover, and check operations on the Delete Log database.
`cscomponents`	Lists (read-only) the number of entries in the Delete Log database.

For more information, including the syntax for these utilities, see Appendix D, Calendar Server Command-Line Utilities Reference.