|
| |
| Sun Java System Calendar Server 6 2005Q1 管理指南 | |
第 22 章
错误诊断本章介绍了一些错误诊断技术，您可以使用这些技术来确定您的系统是否有问题以及产生问题的原因。本章包含以下主题：
打开调试信息由于没有哪个 ics.conf 参数可用于将整个系统置入“调试模式”，因此，本节介绍了一些获取有用的调试信息的方法：
提高日志记录级别
请使用表 22-1 中所示的参数提高日志记录的详细级别：
表 22-1 用于打开调试模式的 ics.conf 参数
参数
说明和默认值
logfile.loglevel
设置为 DEBUG 可以记录所有级别，其中包括 CRITICAL、ALERT、ERROR、WARNING、NOTICE 和 INFORMATION。此参数适用于所有日志。
有关各种可用日志的更多信息，请参见使用 Calendar Server 日志文件。
启用将访问记录到 LDAP 高速缓存
要将所有访问记录到 LDAP 数据高速缓存并打印日志（报告），请设置表 22-2 中所示的 ics.conf 参数。
使用 Calendar Server 实用程序监视系统
请使用以下 Calendar Server 实用程序监视您的系统：
有关 Calendar Server 实用程序的更多信息，请参见附录 D“Calendar Server 命令行实用程序参考”。
LDAP 问题错误诊断本节包含与 LDAP 问题相关的主题：
Calendar Server 实用程序不起作用
如果是首次创建托管环境，则必须通过添加域、容器、用户和资源的适当条目来创建 LDAP 中的 DC 树。使用诸如 cscal 之类的 Calendar Server 实用程序时，如果 DC 树尚未存在，您可能会看到以下错误消息：“初始化失败...正在退出”。
请确保 DC 树在其根目录下至少包含一个（默认）域。使用添加托管域 (Schema 1) 中提供的说明来创建 DC 树结构。
迁移实用程序错误诊断Calendar Server 提供了几个用于迁移日历数据库和 LDAP 目录的实用程序。本节包含以下主题：
在致电技术支持之前需要做什么
通常，如果您在使用迁移实用程序时遇到问题，应与技术支持联系，在联系之前，应先收集以下信息：
迁移实用程序的位置
您可以从下述内容所指明的位置处找到各个迁移实用程序及其文档：
- 模式迁移实用程序 (commdirmig)——安装 Access Manager 时将同时安装此实用程序。此实用程序将把 LDAP 目录从 Schema 1 迁移到 Schema 2。有关此实用程序的信息，请参见《Sun Java System Communications Services 6 2005Q1 Schema Migration Guide》。
- Calendar Server 5.x 至 Calendar Server 6.x 的迁移实用程序（cs5migrate 和 cs5migrate_recurring）——技术支持提供了包含该实用程序及其文档的迁移包。
- csmig——此实用程序是随 Calendar Server 一起安装的。可在第 4 章“数据库迁移实用程序”中找到它的文档，该文档中包括了错误诊断一节。如果使用的是托管域和 LDAP 日历查找数据库 (CLD) 插件，则有必要运行此实用程序。
- csvdmig——此实用程序是随 Calendar Server 一起安装的。您可在第 4 章“数据库迁移实用程序”中找到它的文档，使用此实用程序可以为托管域准备日历数据库和 LDAP 目录条目。
- Calendar Server 2.x 至 Calendar Server 6.x 的迁移实用程序 (ics2migrate)——此实用程序是随 Calendar Server 一起安装的。您可在第 4 章“数据库迁移实用程序”中找到它的文档，使用此实用程序可以将 Calendar Server 2.x 数据库移植为与 Calendar Server 5.x 兼容。
- Netscape Calendar Server 4.x 至 Calendar Server 5.x 的迁移实用程序 (ncs4migrate)——您只能从技术支持处获得此实用程序。实用程序软件包包含文档。此实用程序将 Netscape Calendar Server 4.x 迁移到 Calendar Server 5.x。这些迁移往往需要特别注意。您可以考虑使用专业服务来帮助您规划迁移。
Calendar Server 错误诊断本节介绍了对非数据库问题的各种错误诊断方法。本节包含以下主题：
Ping 日历服务
要验证某项服务是否正在侦听指定的端口号。请使用 cstool 实用程序的 ping 命令。强制回应服务无法验证该服务是否正在运行，但可以表明该服务是否可以接受套接连接。
Calendar Server 服务选项如下：
要运行 cstool，必须正在运行 Calendar Server。
例如，要强制回应主机名为 calserver 的计算机以查看 cshttpd 服务是否正在侦听端口 80：
cstool -p 80 -h calserver ping http
默认情况下，cstool 等待响应的时间为 120 秒，但您可以使用 -t timeout 选项更改此值。
有关完整的实用程序参考资料，请参阅 Calendar Server 命令行实用程序参考。
解决 start-cal 问题
如果在您发出 start-cal 后并没有启动所有日历服务，则在重新启动之前必须停止已启动的日历服务。例如，如果 enpd、csnotifyd 和 csadmind 已启动，但 cshttpd 没有启动，则必须停止 enpd、csnotifyd 和 csadmind。
要启动日历服务，请执行以下步骤：
- 以具备管理权限的用户身份登录正在运行 Calendar Server 的系统。
- 使用 start-cal 停止并重新启动服务。例如：
cal_svr_base/SUNWics5/cal/sbin/start-cal
start-cal 首先发出 stop-cal 命令，然后才启动各种日历服务。
- 如果 stop-cal 无法停止服务，则可能是有某些子进程无法停止。要解决此问题，请参见解决 stop-cal 问题。
解决 stop-cal 问题
当 Calendar Server 关闭时，需要单独考虑两个问题：
停止子进程
发出 stop-cal 之后，某些子进程可能仍未停止。例如，stop-cal 可以停止 cshttpd 父进程，但无法停止任何 cshttpd 子进程。在这种情况下，必须使用以下过程单独停止其余的 Calendar Server 进程。
- 以具备管理权限的用户身份登录正在运行 Calendar Server 的系统。
- 通过对每项服务输入 ps 命令来确定其余 Calendar Server 进程的进程 ID (PID)：
ps -elf | grep cs-process
其中，cs-process 可以是 enpd、csnotifyd、csdwpd、csadmind 或 cshttpd。例如：
ps -elf | grep cshttpd
- 使用正在运行的每个进程的 PID，并输入 kill -15 命令来中止这些进程。例如：kill -15 9875
- 再次对每项服务输入 ps 命令，确保所有 Calendar Server 进程均已停止。
如果仍有 Calendar Server 进程正在运行，请输入 kill -9 命令将其中止。例如：kill -9 9875
不正确关闭后的恢复
如果未正确关闭 Calendar Server，请执行以下步骤：
- 执行上一个过程（停止子进程）中的步骤。
- 手动删除 LDAP 数据高速缓存数据库目录中的所有文件。这些遗留文件可能会导致数据库损坏。要删除这些文件，请执行以下步骤：
- 重新启动 Calendar Server。
cal_svr_base/SUNWics5/cal/sbin/start-cal
有关如何配置 LDAP 数据高速缓存的说明，请参见启用 LDAP 数据高速缓存。附录 E“Calendar Server 配置参数”包含了用于配置 LDAP 数据高速缓存的 ics.conf 参数列表。有关 LDAP 数据高速缓存的更多信息，请参见《Sun Java System Communications Services 6 2005Q1 Deployment Planning Guide》。
无法连接后端服务器
如果您收到指明前端服务器无法建立与后端服务器的连接的错误消息，请尝试以下步骤：
无法找到日历
如果使用的是 CLD 高速缓存选项，并已将一个或多个日历移至其他后端服务器（或更改了后端服务器的名称），请执行以下步骤：
- 确保已按以下说明移动日历：
- 清除 CLD 高速缓存。请参见清除 CLD 缓存。
如果已将一个或多个日历移至其他后端服务器，则 CLD 高速缓存将失效。要刷新 CLD 高速缓存，您需要先清除它，这样才可重建它。
错误诊断未正确完成的搜索
LDAP Directory Server 配置中的 nsslapd-sizelimit 和 nsLookthroughLimit 属性必须足够大，使搜索能够正确完成。如果 nsSizeLimit 不够大，进程可能被中断，而不显示任何结果。如果 nsLookthroughLimit 不够大，搜索可能不会完成。
本节包含以下主题：
确定限制属性是否具有适当的值
为限制属性设置适当的值
这些属性的 DN 为：
dn:cn=config,cn=ldbm databases,cn=plug ins,cn=config
关闭 csstored 中繁琐的每日消息
即使 csstored 进程尚未配置,默认情况下 start-cal 命令也将启动该进程。未配置的 csstored 进程将每隔 24 小时在运行 csstored 的计算机上发出说明其尚未配置的消息。
通过禁止未配置的 csstored 进程运行可以禁用此消息。要禁止 csstored 进程运行，请按如下所示为生成此消息的每台计算机设置 ics.conf 参数。
service.store.enable="no"
请确保没有禁用已配置 csstored 进行自动备份的计算机上的该进程。
处理数据库问题本节介绍了与日历服务器数据库有关的各种问题：
查找 Berkeley 数据库工具
所要采取的多数错误诊断步骤都需要您具有对 Berkeley 数据库实用程序的访问权限。虽然在 Calendar Server 包中提供了这些实用程序的某个版本，但它们不受支持。您可能希望直接从 Sleepycat Software (www.sleepycat.com) 上获得更多信息。
本节包含以下主题：
访问 Berkeley 数据库实用程序
设置并导出 LD_LIBRARY_PATH 环境变量以反映以下目录：
cal_svr_base/SUNWics5/cal/tools/unsupported/bin/
可用工具列表
表 22-3 列出了一些常用 Berkeley 数据库工具（实用程序）。
检测和修复数据库死锁
如果 Berkeley 数据库处于死锁状态，则必须重置数据库。尽早检测到此状态是很重要的。
要使系统可以定期检查数据库以检测到死锁状态并通知管理员，请执行以下步骤：
检测数据库损坏
导致日历数据库损坏的原因有多种：系统资源争用、硬件错误、应用程序错误和数据库错误，当然还有人为错误。本节介绍了如何检测日历数据库损坏：
数据库损坏基本知识
没有人可以保证数据库不被损坏。但您可以最小化数据丢失和运行的停机时间。严密监视数据库和日历服务器是尽早检测到损坏的关键。频繁和完整的备份是在发现损坏后从损坏中恢复的关键。
日历数据库中有两种可能的损坏级别：
监视日志文件
查看 Calendar Server 日志文件（包括警报日志）中的错误消息，这些消息可能会表明数据库受到损坏。有关日志文件的信息，请参阅使用 Calendar Server 日志文件。
应该定期查看日志文件，了解系统是否发生了 ALERT、CRITICAL、ERROR 和 WARNING 级别的错误，如果发现这些错误，请查看这些事件以找出 Calendar Server 操作可能出现的问题。在 Calendar Server 的正常操作过程中，系统会生成 NOTICE 和 INFORMATION 级别的日志事件，以帮助您监视服务器活动。
任何情况下都不要移除数据库目录中的任何事务日志文件。事务日志文件包含事务更新（添加、修改或删除），移除这些文件将损坏日历数据库，且无法恢复。
使用 csmonitor
使用 csmonitor 实用程序可以监视 Calendar Server。如果该实用程序检测到问题（例如，检测到多个事务日志文件或日历数据库缺少磁盘空间），该实用程序将向管理员发送警报电子邮件。有关更多信息，请参见 csmonitor。
检查日历数据库损坏
使用 check 命令可以扫描日历数据库中的损坏，包括日历属性 (calprops) 和事件及待办事件（任务）。如果 check 命令发现无法解决的冲突，它将在输出中报告该情况。
check 命令不检查警报或组计划引擎 (GSE) 数据库的损坏。
要检查日历数据库损坏，请执行以下步骤：
- 以系统管理员身份登录安装了 Calendar Server 的系统。
- Calendar Server 可以正在运行或已经停止，但最好停止 Calendar Server。
- 备份日历数据库（如果尚未备份）。只需复制数据库 (.db) 文件。无需复制任何共享 (__db.*) 文件或日志 (log.*) 文件。
- 转到 cal_svr_base/SUNWics5/cal/sbin 目录。例如，在 Solaris 操作系统上为转到默认目录，请输入：
cd /opt/SUNWics5/cal/sbin
- 对日历数据库副本运行 check 命令：
./csdb check dbdir > /tmp/check.out 2>&1
如果没有指定 dbdir，check 将使用当前目录中的数据库。
check 命令会生成许多信息，所以请考虑将所有输出（包括 stdout 和 stderr）重定向到一个文件中（如示例中所示）。
- 运行 check 命令后，查看输出文件。如果数据库已经损坏，请运行 rebuild 命令。（请参见重建损坏的日历数据库。）
防止在数据库损坏（只读模式）时服务中断
本节介绍了如何在处于恢复模式时使损坏的数据库仍然可访问，包含以下主题：
使用只读模式
如果遇到数据库损坏，一种防止服务中断的方法是将数据库置入只读模式。此模式允许最终用户读取数据库条目，但不允许添加、修改或删除。如果最终用户试图添加、修改或删除任何日历数据，系统将给出错误消息。另外，数据库处于只读模式时，用于添加、修改或删除日历事件和待办事件的管理员工具将不起作用。
注
如果数据库损坏到无法读取的程度，则必须中断服务直到恢复备份。恢复备份的最快方法是拥有一个完好的热备份。请参见恢复热备份。
将数据库置入只读模式
- 当然这并不是必需的，您可能选择即刻停止日历服务以防止数据库受到进一步损坏。要停止日历服务，请使用以下命令：
cal_svr_base/SUNWics5/cal/sbin/stop-cal
- 在命令行处，转到 ics.conf 所在的目录：
cd /etc/opt/SUNWics5/config
- 将日历数据库指定为只读模式：
caldb.berkeleydb.readonly="yes"
- 编辑完 ics.conf 文件后，请重新启动 Calendar Server：
cal_svr_base/SUNWics5/cal/sbin/start-cal
必须重新启动这些服务才能使 ics.conf 更改生效。
处理常见数据库故障
本节介绍了一些常见数据库故障，并提供了一些建议的修正方法。本节包含以下主题：
csadmind 不启动或在启动过程中发生故障
由于 csadmind 是处理组计划引擎 (GSE) 和报警分发引擎的服务，因此，此故障可能是由 GSE 队列或报警队列中的违例条目引起的。
修正方法：
- 如果 csadmind 未运行，请立即发出 stop-cal。
保持日历服务器运行可能导致事务日志累积，从而进一步损坏数据库，并可能需要更长时间才能使事务日志文件与数据库一致。
- 尝试再次重新启动 csadmind（再次发出 start-cal）。
如果启动成功，请通过以下操作确保这两个队列正常运行：
- 使用 csschedule 检查 GSE 队列。
- 使用 dbrig 检查报警队列。
有关运行 csschedule 和 dbrig 的说明，请参见附录 D“Calendar Server 命令行实用程序参考”。
- 如果 csadmind 发生转储故障，请分析 pstack。
如果您在跟踪中发现任何与 GSE 相关的函数（这些函数将带有 GSE 字母），请查看 GSE 队列中的第一个条目和引用的事件数据库中的条目。通常情况下，GSE 条目中引用的事件就是违例条目。要解决此问题，请执行以下步骤：
- 使用 csschedule 删除 GSE 条目。
- 使用 cscomponents 从数据库中删除违例事件。
有关运行 csschedule 和 cscomponents 的说明，请参见附录 D“Calendar Server 命令行实用程序参考”。
- 如果条目未损坏，则可能是日历服务器无法处理的特殊故障。
请执行以下步骤：
- 拍下损坏的数据库的日历环境快照，并与客户支持联系。
要创建环境备份，请执行以下步骤：
— 使用位于
cal_svr_base/SUNWics5/cal/tools/unsupported/bin/db_checkpoint 的 db_checkpoint 实用程序— 运行 db_archive -s 来标识所有数据库文件并将这些文件复制到可移动介质（例如 CD、DVD 或磁带）中。
— 运行 db_archive -l 来标识所有日志文件并将未应用的日志文件复制到可移动介质设备中。
- 要避免服务中断，请执行以下步骤：
- 将日历数据库临时置入只读状态。
在这种状态下，将不允许任何添加、修改或删除事务。最终用户尝试添加、修改或删除任何日历数据时，将收到错误消息。数据库处于只读模式时，用于添加、修改或删除日历事件和待办事件的管理员工具也将不起作用。
要将日历数据库置入只读模式，请编辑 ics.conf 文件并将以下参数设置为 "yes"，如下所示：
caldb.berkeleydb.readonly="yes"
- 恢复为热备份副本。
配置并启用了 csstored 之后，热备份应会在随后的几分钟内即可使用。您还应当始终验证热备份副本以确保其未损坏。（运行 db_verify。）
有关如何恢复热备份副本的说明，请参见恢复热备份。
- 如果所有修复操作均失败，请执行转储和重新装入过程以查看是否可以抢修数据库。
使用转储和装入过程来恢复日历数据库中介绍了此过程。
服务已挂起，最终用户无法连接孤立的锁定
这种情况可能是由包含 Berkeley DB 数据库页面锁定的控制线程在退出时没有释放该锁定而引起的。要确认此问题，请在 cshttpd 进程和 csadmind 上运行 pstack。（pstack 是位于/usr/bin/pstack 中的标准 UNIX 实用程序。）它应当会显示为获取锁定而正在等待的线程。
要解决此问题，请重新启动 Calendar Server，如下所示：
csdb rebuild 永无止境 — 数据库循环
数据库循环通常是由数据库文件损坏引起的。由于是数据库损坏，因此，它是不可修复的。有以下几种选择：
- 恢复为热备份。
如果是最近发生的损坏，您可以使用其中一个热备份。
- 使用灾难归档恢复过程。
有关建议的过程，请参见恢复热备份。
- 使用转储和重新装入过程（使用转储和装入过程来恢复日历数据库）。
重建损坏的日历数据库
本节介绍了如何使用 csdb rebuild 命令，并包含以下主题：
rebuild 概述
rebuild 命令可以扫描日历数据库并检查日历属性 (calprops) 事件和待办事件（任务），以确定是否发生了损坏。如果 rebuild 命令发现冲突，它将在 cal_svr_base/SUNWics5/cal/sbin/rebuild_db 目录中生成一个重建的日历数据库（.db 文件）。
如果没有指定 -g 选项，rebuild 命令将重建除组计划引擎 (GSE) 数据库之外的所有数据库。要同时重建 GSE 数据库，请包含 -g 选项。
要确定 GSE 数据库中是否存在任何条目，请运行 csschedule -v list 命令，然后在 GSE 处理完所有条目后再运行 rebuild 命令。
重建日历数据库
- 以系统管理员身份登录安装了 Calendar Server 的系统。
- 停止 Calendar Server。
- 制作日历数据库的副本，并将其放到 /tmp/db 目录下。只需复制数据库 (.db) 文件和日志 (log.*) 文件。无需复制任何共享 (__db.*) 文件。
- 转到 cal_svr_base/SUNWics5/cal/sbin 目录。例如，在 Solaris 操作系统上，为转到默认目录，请输入：
cd /opt/SUNWics5/cal/sbin
- 对日历数据库副本运行 rebuild 命令：
./csdb rebuild /tmp/db /tmp/
如果未指定数据库路径，rebuild 将使用当前目录。/tmp/ 参数指定了重建数据库的目标目录。
要同时重建 GSE 数据库，请包含 -g 选项。
rebuild 命令会生成许多信息，所以请考虑将所有输出（包括 stdout 和 stderr）重定向到一个文件中。
- 运行 rebuild 命令后，查看 rebuild.out 文件中的输出。如果重建成功，rebuild.out 文件中的最后一行应如下所示：
日历数据库已重建
- 在上一步中验证重建成功后，将重建数据库 (.db) 文件从 rebuild_db 目录复制到您的生产数据库中。
- 如果从损坏的数据库中恢复了任何共享 (__db.*) 文件或日志 (log.*) 文件，请将它们移到其他目录中。
- 重新启动 Calendar Server。
重建输出样例
以下示例显示了此命令及其生成的输出：
使用转储和装入过程来恢复日历数据库
本节包含以下主题：
转储和装入概述
使用转储和装入过程尝试恢复损坏的数据库。转储和装入过程使用 Berkeley 数据库 db_dump 和 db_load 实用程序，它们包含在 Calendar Server 的以下目录中：
cal_svr_base/SUNWics5/cal/tools/unsupported/bin
db_dump 实用程序读取数据库文件并将数据库条目写入输出文件，使用的格式与 db_load 实用程序兼容。
要获得有关 db_dump 和 db_dump 实用程序的文档，请访问 Sleepycat Software 公司的 Web 站点：
http://www.sleepycat.com/docs/utility/index.html
使用 db_dump 和 db_load 实用程序恢复数据库能否成功取决于数据库损坏的程度。可能需要尝试多个 db_dump 选项才能成功恢复数据库。但如果数据库严重损坏，不可能再恢复，您可能需要恢复为数据库上次完好无损的热备份或归档备份。
注
在执行转储和装入过程之前，您的日历数据库必须为 Berkeley DB version 3.2.9 版本或更高版本。如果使用的是早期版本，请首先运行 cs5migrate 实用程序升级日历数据库。
要获得 cs5migrate 的最新版本，请与 Sun 技术支持联系。
执行转储和装入过程
- 以运行 Calendar Server 的用户和组（例如 icsuser 和 icsgroup）身份登录，或以超级用户 (root) 身份登录。
- 如果必要，请停止 Calendar Server。
- 使用 csbackup、Sun StorEdge Enterprise Backup 软件或 Legato Networker 等实用程序备份损坏的数据库。有关更多信息，请参阅第 17 章“备份和恢复 Calendar Server 数据”。
- 使用 db_dump 实用程序转储每个损坏的数据库文件。数据库文件包括 ics50calprops.db、ics50journals.db、ics50alarms.db、ics50events.db、ics50todos.db 和 ics50gse.db。
依次使用以下选项运行 db_dump，直到数据库恢复（或确定数据库无法再恢复）：
- 使用 db_load 实用程序将输出文件装入新数据库文件。例如：
db_load new.ics50events.db < ics50events.db.txt
如果 db_load 报告一些关键字条目或数据条目中出现乱码，请编辑步骤 4 中的 db_dump 输出文件，删除出现乱码的关键字条目或数据条目。然后再次运行 db_load。
- 按照重建损坏的日历数据库中的说明，使用 csdb rebuild 命令重建已恢复的数据库文件。
rebuild 完成后，再次查看输出文件中的输出。如果重建成功，rebuild.out 文件中的最后一行应如下所示：
日历数据库已重建
如果 csdb rebuild 命令失败，请返回步骤 4，使用下一个 db_dump 选项（-r 或 -R）来转储数据库。
如果 db_dump -R 选项没有恢复损坏的数据库，请与 Sun Microsystems 的技术支持或销售代表联系以获得帮助。在此期间，您可能需要恢复为数据库上次完好无损的备份。
恢复自动备份副本
如果您已使用第 10 章“配置自动备份 (csstored)”中所述的自动备份功能，则可以在动态数据库损坏时恢复备份副本。
本节介绍了如何恢复两个不同的自动备份：
恢复之前
在恢复备份之前，请确保您已经执行了以下操作：
恢复热备份
当动态数据库损坏时，热备份应当是备份的首选。要恢复热备份，请执行以下步骤：
- 标识损坏的动态数据库目录中的任何未应用或为写入而打开的日志文件。
- 关闭为写入打开的日志。它包含最新事务。
- 创建新的（恢复）目录。
- 将当前热备份副本复制到新的恢复数据库目录中。
- 将 log.* 文件从损坏的动态数据库目录复制到新的恢复数据库目录中。
- 如果您要保留数据库的归档副本，请将尚未应用到动态数据库的日志复制到归档目录中，这样归档备份副本就完整了。
- 对新的恢复数据库运行带有指定的 -c -h 选项的 db_recover。
例如，如果新的恢复目录名为 recoverydb，则命令将如下所示：
db_recover -c -h recoverydb
- 将 log.* 文件保留在新的恢复目录中。
db_recover 程序将日志文件应用到新的恢复数据库中，但是从 4.2 版开始，Berkeley DB 要求保留这些日志文件。
- 对新的恢复目录中的数据库文件运行 db_verify。
有关说明，请参见检查日历数据库损坏。
- 对新的恢复目录运行 csdb -v list。
- 如果新的恢复目录通过了上述全部三个恢复步骤，则损坏的旧动态数据库将替换为新的恢复数据库。
- 将新的动态数据库复制到热备份目录中以用作新快照。所有新的日志都将应用到此副本中，直到拍下了下一个定期快照。
- 启动 Calendar Server。
- 如果新的恢复目录在任何一个步骤失败，则标识未损坏的早期热备份，如下所述：
恢复归档备份
如果您没有未损坏的热备份，但有归档备份及其事务日志，则可以通过执行以下步骤来恢复最近未损坏版本的已归档数据库：
- 标识损坏的动态数据库目录中的任何未应用或为写入而打开的日志文件。
- 关闭为写入打开的日志。它包含最新事务。
- 创建新的（恢复）目录。
- 将最新的归档副本及其日志文件复制到新的恢复数据库目录中。
- 将任何未应用的 log.* 文件从损坏的动态数据库目录复制到新的恢复数据库目录中。
- 对新的恢复数据库运行带有指定的 -c -h 选项的 db_recover。
例如，如果新的恢复目录名为 recoverydb，则命令将如下所示：
db_recover -c -h recoverydb
- 将 log.* 文件保留在新的恢复目录中。
db_recover 程序将日志文件应用到新的恢复数据库中，但是从 4.2 版开始，Berkeley DB 要求保留这些日志文件。
- 对新的恢复目录中的数据库文件运行 db_verify。
有关说明，请参见检查日历数据库损坏。
- 对新的恢复目录运行 csdb -v list。
- 如果新的恢复目录通过了上述全部三个恢复步骤，则损坏的旧动态数据库将替换为新的恢复数据库。
- 将新的动态数据库复制到热备份目录中以用作新快照。
- 启动 Calendar Server。
- 如果新的恢复目录在任何一个步骤失败，则标识未损坏的早期归档备份，如下所述：
修复自定义备份脚本
本节包括以下主题：
现在使用动态库编译 Berkeley 工具
如果使用诸如 db_recover 的 Berkeley 数据库工具创建了自定义备份脚本，您可能会发现在升级到 Calendar Server 2004Q2 或更高版本后该脚本将不再工作。出现此问题的原因是早期版本的 Calendar Server 使用静态库来编译这些工具。而现在使用动态库 libdb-4.2.so 编译这些工具。
修复自定义备份脚本
要将新的动态库与现有的自定义脚本结合使用，请设置以下全局变量，如下所示：
LD_LIBRARY_PATH=libdb-4.2.so