test

Sun Java System Calendar Server 6 2005Q4 Administration Guide

Chapter 16 Administering Calendar Server Databases with csdb

Calendar Server keeps many database files in multiple directories. You must protect your database files either by implementing the automatic back up process described in Chapter 10, Configuring Automatic Backups (csstored), or by implementing your own system of backups. You can administer the database files using the csdb utility.

This chapter describes how to manage Calendar Server databases using csdb, and includes the following sections:

Using csdb to Manage Calendar Databases

To administer database files, use the Calendar Server utility csdb. This section contains topics:

How csdb Groups Database Files

The calendar database utility csdb treats the database files as three logical databases:

Calendar Database (caldb)

The caldb consists of all the .db files and the _db.*files found in the database directory. The following is the default location for the calendar database files (as well as the cld_cache and ldap_cache subdirectories):

/var/opt/SUNWics5/csdb

If you prefer, you can specify a different directory when running the Calendar Server configuration program (csconfigurator.sh). For information about the configuration program, refer to Chapter 3, Calendar Server Configuration Program (csconfigurator.sh)

The following table describes the calendar database (caldb) files:

Table 16–1 Calendar Server Database Files

File  

Description  

ics50calprops.db 

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

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 calendars. Journals are not implemented in the current release. 

ics50caldb.conf 

Database version identifier. 

ics50recurring.db 

Recurring events. 

ics50deletelog.db 

Deleted events and todos (tasks). See also Chapter 18, Administering the Delete Log Database

Session Database (sessdb)

The session database consists of all files located in the following directories: /opt/SUNWics5/cal/lib/admin/session/ and /opt/SUNWics5/cal/lib/http/session/

Statistical Database (statdb)

The statistical database consists of all files found in the counter directory:

/opt/SUNWics5/cal/lib/counter/

csdb Can Target Specific Databases

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

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

csdb Administrative Tasks

This section describes how to use the csdb utility to perform the following administrative tasks:

Note –

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

ProcedureTo List Status for a Database Group

To view the status of a database group (caldb, sessdb, statdb), use the csdb utility list command.

To list database status:

  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. Change to the /sbin directory. For example, on Solaris Operating Systems, enter:


    cd /opt/SUNWics5/cal/sbin

  4. Run the list command against one or all of the database groups. For example, to list the status and statistics for all three database groups:

    ./csdb list

    The code that follows shows sample output:


    Sleepycat Software: Berkeley DB 4.1.25: (December 19, 2002)

Calendar database version: 3.0.0 [BerkeleyDB]
Total database size in bytes: 57344

Session database version: 1.0.0 [BerkeleyDB]
Total database size in bytes: 0

Counter database version: 1.0.0 [Memory Mapped Files]
Total database size in bytes: 118792

    Or, you can choose to use the verbose mode. For example:

    ./csdb -v list

    The following sample code shows the verbose output:


    Sleepycat Software: Berkeley DB 4.1.25: (December 19, 2002)

Calendar database version: 3.0.0 [BerkeleyDB]
Total database size in bytes: 57344
Total number of calendars:    2
Total number of events:       0
Total number of tasks:        0
Total number of alarms:       0
Total number of gse entries:  0
Total number of master component entries:  0
Total number of deletelog entries:  0
Total logfile size in bytes:  5779919

Session database version: 1.0.0 [BerkeleyDB]
Total database size in bytes: 0
Total logfile size in bytes:  0

Counter database version: 1.0.0 [Memory Mapped Files]
Total database size in bytes: 118792

    Or, use the -t option to specify one target database group (caldb, sessdb, or statdb). For example, to view database status and statistics for only the calendar database:

    csdb -t caldb list

ProcedureTo 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.

To check for database corruption:

  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, enter:


    cd /opt/SUNWics5/cal/sbin

  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, you can choose to replace it with your hot backup copy. Alternately, you can choose to try to rebuild the corrupted one by running the rebuild command.

ProcedureTo Rebuild the Calendar Databases (caldb) - No GSE

To recover a damaged calendar database (caldb), use the csdb utility rebuild command. The rebuild command scans all of the calendar databases for corruption. If the rebuild command finds an inconsistency, it generates a rebuilt calendar database (.db files) in the cal_svr_base/SUNWics5/cal/sbin/rebuild_db directory.

The rebuild command can generate a lot of information, so consider redirecting all output, including stdout and stderr, to a file.

In the instructions that follow, the rebuild command does not rebuild the group scheduling engine (GSE) database.

To rebuild the calendar databases without the GSE database:

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

  2. Stop Calendar Server.

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

  4. Change to the cal_svr_base/SUNWics5/cal/sbin directory. For example, on Solaris Operating Systems, enter:


    cd /opt/SUNWics5/cal/sbin

    If disk space is a problem for the sbin directory, run the rebuild command in a different directory.

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


    ./csdb rebuild /tmp/db /tmp/

    If you don’t specify a database directory, rebuild uses the database in the current directory. In the preceding example, the /tmp/ parameter specifies the destination directory for the rebuilt database.

    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:

    1. ./csdb rebuild db_0629

      Then check for corruption. If this backup copy is also corrupt, then run rebuild on the next backup copy.

    2. ./csdb rebuild db_0615

      Then check for corruption. If this backup copy is also corrupt, then run rebuild on the next backup copy.

    3. ./csdb rebuild db_0601

      ... etc.

    The rebuild command writes the rebuilt database to the cal_svr_base/SUNWics5/cal/sbin/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, copy the rebuilt database (.db) files from the rebuild_db directory to your production database.

  8. If you have any share (__db.*) files from the corrupted database, move them to another directory.

  9. Restart Calendar Server.

ProcedureTo Rebuild the Calendar Databases, Including the GSE Database

If you have implemented group scheduling at your site, then you should include the GSE database in the rebuild.

To rebuild both the calendar databases and the GSE database:

  1. Determine if the GSE database has any entries by running the csschedule -v list command and then let the GSE finish processing the entries.

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

  3. Stop Calendar Server.

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

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

  5. Change to the cal_svr_base/SUNWics5/cal/sbin directory.

    For example, on Solaris Operating Systems, enter:

    cd /opt/SUNWics5/cal/sbin

    If disk space is a problem for the sbin directory, run the rebuild command in a different directory.

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

    ./csdb -g rebuild /tmp/db /tmp/

    If you don’t specify a database directory, rebuild uses the database in the current directory. In the preceding example, the /tmp/ parameter specifies the destination directory for the rebuilt database.

    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 cal_svr_base/SUNWics5/cal/sbin/rebuild_db directory.

  7. 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

  8. After you have verified that rebuild was successful, copy the rebuilt database (.db) files from the rebuild_db directory to your production database.

  9. If you have any share (__db.*) files from the corrupted database, move them to another directory.

  10. Restart Calendar Server.

Example 16–1 Sample Rebuild Output

The sample output shows the events and the todos databases scanned twice each. This is not an error. It scans the first time to verify the information in the calprops database and then scans again to make sure calprops is accessible from the calendar database.

The following example shows the command and the output that it generated:


# ./csdb -g rebuild
Building calprops based on component information.
Please be patient, this may take a while...
Scanning events database...
512 events scanned
Scanning todos database...
34 todos scanned
Scanning events database...
512 events scanned
Scanning todos database...
34 todos scanned
Scanning deletelog database...
15 deletelog entries scanned
Scanning gse database...
21 gse entries scanned
Scanning recurring database...
12 recurring entries scanned
Successful components db scan
Calendar database has been rebuilt
Building components based on calprops information.
Please be patient, this may take a while...
Scanning calprops database to uncover events...
25 calendars scanned
Scanning calprops database to uncover todos...
25 calendars scanned
Successful calprops db scan
Calendar database has been rebuilt

To Delete a Database Group

To delete a calendar database, use the csdb utility delete command. 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.