Previous     Contents     Index     Next     
iPlanet Calendar Server Administrator's Guide



Chapter 5   Managing Calendar Server Databases


This chapter describes how to manage iPlanet Calendar Server databases and calendar data using the csdb utility.

This chapter contains these sections:

To run the csdb utility, you must log in as a user who has administrative rights to the system where the Calendar Server is running. For more information, see Chapter 7 "Calendar Server Command-Line Utilities."

For information about backing up and restoring a calendar database, see Chapter 6 "Backing Up and Restoring Calendar Server Data."



Specifying a Target Database


The csdb utility -t option allows you to specify a target database:

  • -t caldb — calendar database

  • -t sessdb — session database

  • -t statdb — statistics database

If you do not include the -t option, csdb operates on all three databases, except for the check and rebuild commands, which operate only on the calendar database.

Table 5-1describes the calendar database (caldb) files:


Table 5-1    Calendar Database Files

File

Description

ics50calprops.db  

Calendar properties for all calendars. Includes the calendar ID (calid), calendar name, Access Control List (ACL), owner, and more.  

.ics50events.db  

Events for all calendars.  

ics50todos.db  

Todos (tasks) for all calendars.  

ics50alarms.db  

Alarms for all events and todos (tasks).  

ics50gse.db  

Queue of scheduling requests for the group scheduling engine (GSE).  

ics50journals.db  

Journals for all calendars. Journals are not implemented in the current release of Calendar Server.  

ics50caldb.conf  

Database version identifier.  



Viewing Calendar Database Status


To view the status of a calendar database, use the csdb utility list command. The Calendar Server can be either running or stopped.

Use the -t option to specify the target database (caldb, sessdb, or statdb); otherwise, csdb operates on all three databases.

For example, to view database status and statistics for all databases:

csdb list

To view information about the calendar database in the current directory in verbose mode:

csdb -v -t caldb list



Deleting a Calendar Database


To delete a calendar database, use the csdb utility delete command. The Calendar Server must be stopped.

Use the -t option to specify the target database (caldb, sessdb, or statdb); otherwise, csdb deletes all three databases.

For example, to delete the calendar database:

csdb -t caldb delete

The csdb utility issues a warning before deleting the database.



Importing and Exporting Calendar Data


To export and import calendar data to and from a file, use the csexport and csimport utilities. The calendar data can be in either iCalendar (.ics) or XML (.xml) format.

You must run csexport and csimport locally on the machine where your Calendar Server is installed. The Calendar Server can be either running or stopped.


Exporting Calendar Data

To export calendar data to a file, use csexport. The file name extension (.ics or .xml) that you specify for the output file determines which format is used.

For example, to export the calendar with the calendar ID (calid) JSmithcal in iCalendar (text/calendar MIME) format to a file named jsmith.ics:

csexport -c JSmithcal calendar jsmith.ics

To export the calendar JSmithcal in XML (text/xml MIME) format to a file named jsmith.xml:

csexport -c JSmithcal calendar jsmith.xml


Importing Calendar Data

To import calendar data from a file previously saved using the csexport utility, use csimport. The file name extension of the import file (.ics or .xml) indicates the format in which it was saved.

For example, to import calendar data to the calendar ID (calid) JSmithcal from the file jsmith.ics that was saved in iCalendar (text/calendar MIME) format:

csimport -c JSmithcal calendar jsmith.ics

To import data into the calendar JSmithcal from a file named jsmith.xml that was saved in XML (text/xml MIME) format:

csimport -c JSmithcal calendar jsmith.xml

If the specified calendar ID (calid) already exists, its data is cleared before the new data is imported.



Recovering a Damaged Database


To recover a damaged session or statistics database, use the csdb utility recover command. Use the -t option to specify the target database: sessdb (session) or statdb (statistics).

Before you run the recover command, stop the Calendar Server using the stop-cal command.

For example, to recover a damaged session database in the current directory:

csdb -t sessdb recover


Note To recover a damaged calendar database (caldb), use the csdb utility check and rebuild commands instead of recover.

For more information, see "Checking and Rebuilding a Calendar Database".




Checking and Rebuilding a Calendar Database


The csdb utility commands includes the following commands to check and, if necessary, to rebuild a calendar database (caldb):

  • The check command scans a calendar database to determine if any corruption has occurred and reports the results in its output. (The check command does not check for corruption in the alarm or group scheduling engine (GSE) database.)

  • The rebuild command also scans a calendar database to determine if any corruption has occurred and if necessary, generates a rebuilt calendar database (.db files).

The csdb utility also incudes the recover command to recover a damaged session or statistics database. If your calendar database is corrupted, use check and rebuild instead of recover.


Caution

Before you run these commands, backup your calendar database using the csbackup utility (or another backup utility).



Checking a Calendar Database for Corruption

The check command scans a calendar database and checks calendar properties (calprops) events and todos (tasks) for corruption. If the check command finds an inconsistency that cannot be resolved, it reports the situation in its output.

You should run the check command regularly to check your calendar database for inconsistencies. For example, consider running check after each backup of your database. However, if you already know that your calendar database is corrupted, you don't need to run the check command. Go ahead and rebuild your corrupted database.


To check a calendar database for corruption:

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

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

  3. Make a copy of your calendar database, if you haven't already done so. Copy only the six database (.db) files. You don't need to copy any share (*.share) or log (log.*) files.

  4. Change to the server-root/cal/bin/ directory. For example, on Solaris, enter:

    cd /opt/SUNWics5/cal/bin

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

    ./csdb check dbdir > /tmp/check.out 2>&1

    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.


Rebuilding a Corrupted Calendar Database

The rebuild command scans a calendar database and checks the calendar properties (calprops) events and todos (tasks) for corruption. If the rebuild command finds an inconsistency, it generates a rebuilt calendar database (.db files) in the server-root/cal/bin/rebuild_db/ directory.


Note The rebuild command rebuilds all databases except the group scheduling engine (GSE) database. To determine if the GSE database has any entries, run the csschedule -v list command and then let the GSE finish processing the entries before you run the rebuild command.



To rebuild a corrupted calendar database:

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

  2. Stop the Calendar Server.

  3. Make a copy of your calendar database, if you haven't already done so. Copy only the six database (.db) files. You don't need to copy any share (*.share) or log (log.*) files.

  4. Change to the server-root/cal/bin/ directory. For example, on Solaris, enter:

    cd /opt/SUNWics5/cal/bin

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

    ./csdb rebuild dbdir > /tmp/rebuild.out 2>&1

    If you don't specify a directory, rebuild uses the database in the current directory.

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


    Note Always rebuild your calendar database using the latest backup copy.

    However, if you have experienced a significant loss of data and you have periodically backed up your database and have more than one copy available, rebuild from the latest copy to the oldest one. (The only drawback is that calendar components that were deleted will reappear in the rebuilt database.)

    For example, if you have three sets of backup calendar database files in directories db_0601, db_0615, and db_0629, run the rebuild command in the following sequence:

    ./csdb rebuild db_0629
    ./csdb rebuild db_0615
    ./csdb rebuild db_0601

    The rebuild command then writes the rebuilt database to the server-root/cal/bin/rebuild_db/ directory.


  6. When rebuild has finished, review the output in the rebuild.out file. If the rebuild was successful, the last line in the rebuild.out file should be:

    Calendar database has been rebuilt

  7. After you have verified that rebuild was successful in the previous step, copy the rebuilt database (.db) files from the server-root/cal/bin/rebuild_db/ directory to your production database.

  8. If any share (*.share) or log (log.*) files are left from the corrupted database, delete them or move them to another directory.

  9. Restart the Calendar Server.


Previous     Contents     Index     Next     
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.

Last Updated January 22, 2002