This section describes how to use the csdb rebuild command and contains the following topics:
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 cal_svr_base/SUNWics5/cal/sbin/rebuild_db directory.
The rebuild command without the -g option rebuilds all databases except the group scheduling engine (GSE) database. To also rebuild the GSE database, include the -g option.
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.
Log in as a user who has administration rights to the system where Calendar Server is installed.
Stop Calendar Server.
Make a copy of your calendar databases, placing them into the /tmp/db directory.
Copy the database (.db) files and the log (log.*) files. You don’t need to copy any share (__db.*) files.
Change to the cal_svr_base/SUNWics5/cal/sbin directory.
For example, on Solaris Operating Systems, for the default directory, enter:
If disk space is a problem for the sbin directory, run the rebuild command in a different directory.
Run the rebuild command on the copy of your calendar database:
./csdb rebuild /tmp/db /tmp/
If you don’t specify a database path, rebuild uses the current directory. The /tmp/ parameter species the destination directory for the rebuilt database.
To also rebuild the GSE database, include the -g option.
The rebuild command can generate a lot of information, so consider redirecting all output, including stdout and stderr, to a file.
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.
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
After you have verified that rebuild was successful in the previous step, copy the rebuilt database (.db) files from the rebuild_db directory to your production database.
If you have any share (__db.*) or log (log.*) files from the corrupted database, move them to another directory.
Restart Calendar Server.
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
The preceding 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 calendar properties database and then scans again to make sure calendar properties database is accessible.