22.5.2 Detecting Database Corruption

Calendar database corruption can be caused by various reasons: system resource contention, hardware failures, application errors, database failures, and of course human error. This section describes how to detect calendar database corruption:

• 22.5.2.1 Database Corruption Basics

• 22.5.2.2 Monitoring Log Files

• To Check for Calendar Database Corruption

22.5.2.1 Database Corruption Basics

No one can guarantee corruption free databases. But you can minimize data loss and operational downtime. Closely monitoring the database and calendar server is key to detecting corruption early. Frequent and complete backups are the key to recovering from corruption once it is found.

There are two levels of corruption possible in a calendar database:

• Application level–Offending entries in one of more database files prevent the server from running when they are operated upon.

• Database level–Corruptions in the Berkeley database pages cause various problems. One common symptom is looping while running csdb check. Another common symptom is an error message like the following:

  “illegal page type or format”, 
  or “page 97895 doesn’t exist, create flag not set.”

22.5.2.2 Monitoring Log Files

Monitor the Calendar Server log files, including the alarm logs, for any error messages that might indicate database corruption.

You should inspect the log files on a regular basis for ALERT, CRITICAL, ERROR, and WARNING level errors and, if found, examine the events for possible problems with the operation of Calendar Server. The NOTICE and INFORMATION level log events are generated during normal operation of Calendar Server and are provided to help you monitor server activity.

Never remove any transaction log files in the database directory. The transaction log files contain the transaction updates (additions, modifications, or deletions), and removing them can corrupt the calendar database beyond recovery.

When requesting technical support for Calendar Server, you might be asked to provide the log files for help in resolving problems.

To Check for Calendar Database Corruption

Use the check command to scan for corruptions in the calendar database, including calendar properties (calprops) and events and todos (tasks). If the check command finds an inconsistency that cannot be resolved, it reports the situation in its output.

The check command does not check for corruption in the alarm or group scheduling engine (GSE) databases.

1. Log in as a user who has administration rights to the system where Calendar Server is installed.

2. Calendar Server can be either running or stopped; however, if possible, stop Calendar Server.

3. Make a copy of your calendar database, if you haven’t already done so.

   Copy only the database (.db) files. You don’t need to copy any share (__db.*) or log (log.*) files.

4. Change to the cal-svr-base/SUNWics5/cal/sbin directory.

   For example, on Solaris Operating Systems for the default directory, enter:

   cd /opt/SUNWics5/cal/sbin

5. Run the check command on the copy of your calendar database:

   ./csdb check dbdir /tmp/check.out

   If you don’t specify dbdir, check uses the database in the current directory.

   The check command can generate a lot of information, so consider redirecting all output, including stdout and stderr, to a file (as shown in the example).

6. When check has finished, review the output file. If your database is corrupted, run the rebuild command.

   (See 22.5.6 Rebuilding a Corrupted Calendar Database.)