检测数据库损坏

导致日历数据库损坏的原因有多种：系统资源争用、硬件错误、应用程序错误和数据库错误，当然还有人为错误。本节介绍了如何检测日历数据库损坏：

• 数据库损坏基本知识

• 监视日志文件

• 使用 csmonitor

• 检查日历数据库的损坏

数据库损坏基本知识

没有人可以保证数据库不被损坏。但您可以最小化数据丢失和运行的停机时间。严密监视数据库和日历服务器是尽早检测到损坏的关键。频繁和完整的备份是在发现损坏后从损坏中恢复的关键。

日历数据库中有两种可能的损坏级别：

• 应用程序级别—一个或多个数据库文件中的违例条目会在服务器运行这些条目时阻止服务器继续运行。

• 数据库级别—Berkeley 数据库页面中的损坏会导致各种问题。一个常见的症状是运行 csdb check 时不断循环。另一个常见症状是显示错误消息，例如：

  “非法的页面类型或格式”或 
  “第 97895 页不存在，未设置创建标志”

监视日志文件

查看 Calendar Server 日志文件（包括警报日志）中的错误消息，这些消息可能会表明数据库受到损坏。有关日志文件的信息，请参阅使用 Calendar Server 日志文件。

应该定期查看日志文件，看是否发生了 ALERT、CRITICAL、ERROR 和 WARNING 级别的错误，如果发现这些错误，请检查事件以找出 Calendar Server 操作可能出现的问题。在 Calendar Server 的正常操作过程中，系统会生成 NOTICE 和 INFORMATION 级别的日志事件，以帮助您监视服务器的活动。

任何情况下都不要移除数据库目录中的任何事务日志文件。事务日志文件包含事务更新（添加、修改或删除），移除这些文件将损坏日历数据库，且无法恢复。

在请求 Calendar Server 技术支持时，可能需要您提供日志文件以协助解决问题。

使用 csmonitor

使用 csmonitor 实用程序可以监视 Calendar Server。如果该实用程序检测到问题（例如，检测到多个事务日志文件或日历数据库缺少磁盘空间），该实用程序将向管理员发送警报电子邮件。有关更多信息，请参见csmonitor。

检查日历数据库的损坏

使用 check 命令可以扫描日历数据库，包括日历属性 (calprops) 和事件以及待办事件（任务），以查看其中是否存在损坏。如果使用 check 命令发现无法解决的冲突，则将在输出结果中报告该情况。

check 命令不检查警报或组调度引擎 (Group Scheduling Engine, GSE) 数据库中的损坏。

步骤

1. 以具备管理权限的用户身份登录安装了 Calendar Server 的系统。

2. Calendar Server 可以正在运行或已经停止，但最好停止 Calendar Server。

3. 如果尚未备份，请备份日历数据库。

   只需复制数据库 (.db) 文件。无需复制任何共享 (__db.*) 文件或日志 (log.*) 文件。

4. 转至 cal_svr_base/SUNWics5/cal/sbin 目录。

   例如，在 Solaris 操作系统上为转到默认目录，请输入：

   cd /opt/SUNWics5/cal/sbin

5. 针对日历数据库副本运行 check 命令：

   ./csdb check dbdir /tmp/check.out

   如果未指定 dbdir，则 check 命令将针对当前目录中的数据库。

   check 命令会生成许多信息，因此请考虑将所有输出结果（包括 stdout 和 stderr）重定向到一个文件中（如示例中所示）。

6. 运行完 check 命令后，查看输出文件。如果数据库已损坏，请运行 rebuild 命令。

   （请参见重建损坏的日历数据库。）