您的举报已经提交成功，我们将尽快处理，谢谢！
大家还关注
(window.slotbydup=window.slotbydup || []).push({
id: '2081942',
container: s,
size: '1000,60',
display: 'inlay-fix'后使用快捷导航没有帐号？
一步搞定
只需一步，快速开始
查看: 4469|回复: 4
手机华为P1 XL在线时间201 小时最后登录阅读权限20UID5333107
, 积分 394, 距离下一级还需 6 积分
注册时间积分394精华0主题帖子 金币891 元 智豆0 点
各位老大，小弟下载的第三方日历为什么总是停止运行啊，原来用365日历，总是停止运行，后来换成了佐佐日历了还是这样。怎么办啊
手机全能战斗机在线时间11061 小时最后登录阅读权限90UID1649560
注册时间积分17449精华0主题帖子 金币 元 智豆1 点
重启下手机&&清除程序缓存& &恢复出厂设置三招
手机P1 XL在线时间242 小时最后登录阅读权限20UID5223036
, 积分 544, 距离下一级还需 156 积分
注册时间积分544精华0主题帖子 金币1188 元 智豆0 点
我用中华万年历有时会停止运行，重装过一次就都好了
手机华为P1 XL在线时间201 小时最后登录阅读权限20UID5333107
, 积分 394, 距离下一级还需 6 积分
注册时间积分394精华0主题帖子 金币891 元 智豆0 点
RE: 日历停止运行
伤城★小白狼 发表于
重启下手机&&清除程序缓存& &恢复出厂设置三招
全都试过了，不管用，肿么办
手机T9200在线时间684 小时最后登录阅读权限30UID5507058
, 积分 1149, 距离下一级还需 51 积分
注册时间积分1149精华0主题帖子 金币1240 元 智豆0 点
不是有自带日历吗，我觉得就很好呀
巨蟹座勋章
十二生肖-未羊
十二生肖-未羊勋章
安智超级版主勋章
安智超级版主勋章
安智帅哥勋章
安智帅哥勋章
安智全勤勋章
签到满一百天即可申请
安智网才子勋章
安智网才子勋章
安智网友聚会勋章
安智历届网友聚会勋章
ATX打杂勋章
ATX打杂专属勋章
安智巡查勋章
安智巡查勋章,不可申请
安智2013年会勋章
参加安智2013年会视频录制的机友专属勋章
参加论坛举报违规活动所得
闪耀之星勋章
参加指定活动获得
1000万会员勋章
1000万会员勋章
安智征文活动专用奖励
产品更新换代快，那么我们当初心心念念终于买来的东西可能没用多久就被淘汰了。那么，各位同学，你们家里有没有尘封着一些无奈被淘汰但又舍不得扔掉的电子产品呢？
Powered by手机综合区_玩机天地_OPPO官方论坛_OPPO乐园_Find7论坛_ColorOS_OPPO手机_OPPO手机评测_OPPO手机怎么样 -Calendar Server 6.3 软件故障排除 (Sun Java System Calendar Server 6.3 管理指南)
&& 第 22 章
Calendar Server 6.3 软件故障排除Sun Java System Calendar Server 6.3 管理指南第 22 章
Calendar Server 6.3 软件故障排除
本章包括如何设置日志记录以及怎样处理某些常见问题。
本章包含以下主题：
22.1 打开 Calendar Server 6.3 软件的调试信息
本节介绍使用日志和调试信息来故障排除 Calendar Server 部署的问题的概念性信息和说明。
由于没有哪个 ics.conf 参数可用于将整个系统置入&调试模式&，因此，本节介绍了一些获取有用调试信息的方法：
注 & 确保在不需要的时候关闭超额的日志记录和监视，因为它将对性能产生负面影响。
22.1.1 提高日志记录级别
使用下表显示的参数来提高日志记录的详细级别：
说明和默认值&
logfile.loglevel
设置为 DEBUG 可以获得所有详细级别的日志，其中包括 CRITICAL、ALERT、ERROR、WARNING、 NOTICE 和 INFORMATION。此参数适用于所有日志。
22.1.2 启用将访问记录到 LDAP 高速缓存
要将所有访问信息记录到 LDAP 数据高速缓存并打印日志（报告），设置下表中所示的 ics.conf 参数：
说明和默认值&
local.ldap.cache.stat.enable
指定是否将访问记录到 LDAP 数据高速缓存，以及是否在日志文件中记录统计信息。默认值为 "no"（不记录统计信息）。设置为 "yes" 可以记录统计信息。
为了增强性能，请仅在调试模式下使用此参数。&
local.ldap.cache.stat.interval
以秒为单位指定每个统计报告写入日志文件的时间间隔。默认值为 "1800" 秒（30 分钟）。
仅当启用了日志记录时，此参数才处于活动状态。减少时间间隔有助于您查明问题所在。增加时间间隔有助于降低系统负载。&
22.1.3 清除 LDAP 高速缓存
目前 Calendar Server 中没有使 LDAP 高速缓存数据过期的设置。必须手动删除 ldap_cache 目录中的内容，并重新启动 Calendar Server。
清除 LDAP 高速缓存
停止 Calendar Server。
删除 /var/opt/SUNWics5/csdb/ldap_cache 目录中的所有文件，但不删除 ldap_cache 目录本身。
重新启动 Calendar Server。
22.1.4 WCAP 命令和 HTTP 访问记录
两个便于调试的配置参数会启用收到的命令和 HTTP 访问的日志记录。将这两个参数中的一个或全部添加到 ics.conf 文件以激活日志记录：
mandlog = "yes" & cshttpd 进程会在日志目录中创建文件 <mands。日志包含服务器收到的每个 .shtml 或 .wcap 命令以及每个命令的所有参数。
mandlog.all = "yes" & cshttpd 进程在日志目录中创建文件 http.access。日志包含系统收到的每个 HTTP 请求。
注意 & 日志文件可能会迅速增大，并最终占用全部的可用磁盘空间。需小心监视这些文件，以避免发生问题。选择系统活动性较低的时期来启用并运行这些命令。如果在高峰时期运行，性能会大幅度下降。完成故障排除前始终禁用这两个命令。
22.1.5 使用 Calendar Server 6.3 csstats 实用程序监视系统
使用 csstats list 命令显示 counter.conf 文件中定义的计数器对象中的统计信息。
有关 csstats 实用程序的更多信息，参见。
22.2 LDAP 问题故障排除
本节包括故障排除 LDAP 问题的概念性信息。
如果是首次创建多域环境，则必须通过添加域、容器、用户、组和资源的适当条目来创建 LDAP 中的 DC 树。使用诸如 cscal 之类的 Calendar Server 实用程序时，如果 DC 树尚未存在，则可能会看到以下错误消息：&初始化失败.... 退出&。
请确保 DC 树在其根目录下至少包含一个（默认）域。按照中提供的说明，创建 DC 树结构。
22.3 迁移实用程序故障排除
Calendar Server 提供了几个用于迁移日历数据库和 LDAP 目录的实用程序。
本节包含以下主题：
22.3.1 在致电技术支持之前需要做什么
通常，如果在使用迁移实用程序时遇到问题，应与技术支持联系。
在联系之前，应收集以下信息：
出现问题的数据库的备份副本。
所有相关日志的副本。
所有错误输出消息（包括核心转储文件）。
22.3.2 迁移实用程序的位置
您可以从下述内容所指明的位置处找到各个迁移实用程序及其文档：
模式迁移实用程序 (commdirmig)
该实用程序与 Delegated Administrator （一个可单独安装的组件）捆绑在一起。此实用程序将 LDAP 目录从 Schema 版本 1 迁移到 Schema 版本 2。有关此实用程序的信息，参见。
Calendar Server 6.2 至 6.3 的迁移实用程序 csmigrate
安装软件后可在 sbin 目录中找到此实用程序。
Calendar Server 5 至 Calendar Server 6.2 的迁移实用程序 (cs5migrate)
安装软件后可在 sbin 目录中找到此实用程序。
Calendar Server 多域数据库准备实用程序 (csmig)
安装软件后可在 sbin 目录中找到此实用程序。
可在中找到有关此实用程序的文档，该章还包括故障排除一节。
Calendar Server 非域到多域的迁移实用程序 (csvdmig)
安装软件后可在 sbin 目录中找到此实用程序。
可在中找到此实用程序的文档。使用该实用程序可以针对多域准备日历数据库和 LDAP 目录条目。
始终先运行 csmig，再运行 csvdmig。
Calendar Server 2 至 Calendar Server 6 的迁移实用程序 (ics2migrate)
此实用程序是随 Calendar Server 一起安装的。可在中找到相关文档。使用此实用程序可以迁移 Calendar Server 2 数据库从而使其与 Calendar Server 5 兼容。
Netscape Calendar Server 4 至 Calendar Server 5 的迁移实用程序 (ncs4migrate)
您只能从技术支持处获得此实用程序。实用程序软件包包含文档。此实用程序将 Netscape Calendar Server 4 迁移至 Calendar Server 5。由于在源数据库中缺乏一致性，进行这些迁移时往往需要特别注意。可在很多手册中找到该实用程序的说明。您只能从技术支持处获得此实用程序。实用程序软件包包含文档。此实用程序将 Netscape Calendar Server 4 迁移至 Calendar Server 5。进行这些迁移时往往需要特别注意。通常需要对源文件做大量工作后，才可以运行该实用程序。您可以考虑使用专业服务来帮助您规划迁移。
22.4 Calendar Server 的非数据库故障排除
本节介绍了对非数据库问题的各种故障排除方法。
本节包含以下主题：
提示 & 此外，在讲述 SSL 的一章中有一节是说明 SSL 故障排除：
22.4.1 一个 cshttpd 进程接受了过多的连接并且占用了 100% 的 CPU 时间
如果一个 cshttpd 进程接受了过多的连接并且占用了 100% 的 CPU 时间，可能是禁用了负载平衡。要重新启用负载平衡，将 ics.conf 的参数 service.http.loadbalancing 的值更改为 "yes"。
解决 start-cal 问题
如果在您发出 start-cal 后并没有启动所有日历服务，则在重新启动之前必须停止已启动的日历服务。例如，如果 enpd、csnotifyd 和 csadmind 已启动，但 cshttpd 没有启动，则必须停止 enpd、csnotifyd 和 csadmind。
要启动日历服务，请执行以下步骤：
以具有配置权限的管理员身份登录。
发出 stop-cal 命令。
如果 stop-cal 命令无法停止所有的 Calendar Server 服务，则可能仍有某些子进程在运行。要解决此问题，参见。
确定已停止全部的 Calendar Server 进程后，可使用 start-cal 命令启动所有服务。例如：
cal-svr-base/SUNWics5/cal/sbin/start-cal
22.4.2 解决 stop-cal 问题
本节介绍改正 stop-cal 问题的某些概念性信息和说明。
当 Calendar Server 关闭时，需要单独考虑两个问题：
停止子进程
发出 stop-cal 之后，某些子进程可能仍未停止。例如，stop-cal 可以停止 cshttpd 父进程，但无法停止任何 cshttpd 子进程。在这种情况下，必须使用以下过程单独停止其余的 Calendar Server 进程。
以具备管理权限的用户身份登录正在运行 Calendar Server 的系统。
通过针对每一项服务输入 ps 命令来确定其余 Calendar Server 进程的进程 ID (Process 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 的 Linux 系统中，如果使用 ps 命令搜索日历进程，搜索结果的显示可能会十分混乱。在 Linux 系统中，ps 命令返回正在运行的线程的列表，而不是进程列表。尚未找到解决方法来仅显示进程。
不正确关闭后的恢复
如果未正确关闭 Calendar Server，请执行以下步骤：
执行上一个过程中的步骤。
手动删除 LDAP 数据高速缓存数据库目录中的所有文件。
这些遗留文件可能会导致数据库损坏。要删除这些文件，请执行以下步骤：
转到 LDAP 数据高速缓存目录。
默认值为 /opt/SUNWics5/csdb/ldap_cache，但请使用 ics.conf 文件中 local.ldap.cache.homedir.path 参数所指定的目录。
删除该目录下的所有文件。
例如：rm *.*
检查以确保已删除所有文件。
重新启动 Calendar Server。
cal-svr-base/SUNWics5/cal/sbin/start-cal
有关如何配置 LDAP 数据高速缓存的说明，参见。有关 LDAP 数据高速缓存的更多信息，参见。
22.4.3 无法连接至后端服务器
Ping 后端服务器以查看它是否响应。
如果不响应，确定失败的原因。当其再次起作用时，继续进行本任务中的下一个步骤。
清除 CLD 高速缓存。参见。
如果使用的是 CLD 高速缓存选项，并已通过 ics.conf 参数更新了服务器名，则应清除 CLD 高速缓存以删除服务器名。CLD 缓存中的旧条目会导致前端服务器无法正确连接到后端服务器，或导致 Calendar Server 无法找到移动后的日历。
使用 stop-cal 命令停止服务器。
使用 start-cal 重新启动 Calendar Server。
22.4.4 无法找到日历
如果使用的是 CLD 高速缓存选项，并已将一个或多个日历移至其他后端服务器（或更改了后端服务器的名称），则可能无法查看新服务器上的日历。
出现这样的情况时，执行以下步骤：
清除 CLD 高速缓存。参见。
如果已将一个或多个日历移至其他后端服务器，则 CLD 高速缓存将失效。要刷新 CLD 高速缓存，您需要先清除它，这样才可重建它。
如果失败，请确保是否遵循了正确的步骤来移动日历。可在以下章节中找到该信息：
然后清除高速缓存。
22.4.5 无法在后端计算机上创建日历
如果尝试在指定的后端服务器上创建日历，则会看到以下错误消息：DWP 主机服务器无效，原因可能有以下两种。服务器配置不正确，或者已将日历所有者分配给另一后端服务器。
本节介绍如何改正这两个问题：
22.4.5.1 后端服务器配置不正确
查看存在问题的后端服务器的 ics.conf 文件。
确认是否存在以下设置：
service.dwp.enable = "yes"
caldb.cld.type = "directory"
local.hostname = "back-end hostname"
22.4.5.2 将日历所有者分配给了另一后端服务器
查看用户的 LDAP 条目并确认是否存在 icsDWPHost 属性。icsDWPHost 的值必须与尝试在其中创建日历的后端服务器的名称相匹配。不能在另一后端服务器上为该用户创建日历。
22.4.6 尝试使用代理验证进行登录时，提示&未授权&。
本节包括对可能的失败原因的建议。遵循建议的步骤并重试登录。
执行一个或多个以下步骤来改正此错误：
验证 service.http.allowadminproxy 是否设置为 "yes"。
验证 admin-user 是否具有 Calendar Server 管理员权限。
验证 admin-password 是否正确。
验证 calendar-user 是否为 Calendar Server 的有效用户。
重试登录。
22.4.7 对未正确完成的搜索进行故障排除
本节包括故障排除未正确完成的搜索的概念性信息和说明。
LDAP Directory Server 配置中的 nsslapd-sizelimit 和 nsLookthroughLimit 属性必须足够大，以使搜索能够顺利完成。如果 nsSizeLimit 不够大，则进程可能被中断，而不显示任何结果。如果 nsLookthroughLimit 不够大，则可能无法完成搜索。
本节包含以下主题：
确定限制属性是否具有适当的值
要确定是否为这些属性设置了适当的值，请尝试以下命令：
ldapsearch -b "base" "(&(icscalendarowned=*user*)(objectclass=icsCalendarUser))"
其中，base 是 Calendar Server 用户和资源数据所在目录服务器的 LDAP 基本 DN，user 是最终用户可以在用户界面的搜索对话框中输入的值。
如果 LDAP 服务器返回错误消息，则可能是由于参数 nsSizeLimit 或 nsLookthroughLimit 的值不够大。
为限制属性设置适当的值
这些属性的 DN 为：
dn: cn=config,cn=ldbm databases,cn=plug ins,cn=config
使用 ldapmodify 动态设置 nsLookthroughLimit 的值。
即，无需停止和重新启动 Directory Server 来更改此属性。
默认值为 5000。如果搜索未报告结果，您可能希望增大该值。但是，这将使 LDAP 服务器的性能降低。
可以将限制设置为 -1，这样将取消任何限制。但是，这样做时应小心，因为它很可能会导致系统挂起。
如果要将 nsslapd-sizelimit 设置为更高的值，则必须执行以下步骤：
停止 Directory Server。
编辑 dse.ldif 文件。
重新启动 Directory Server。
有关如何使用 ldapmodify 和编辑 dse.ldif 文件的信息，参见以下位置处的 Directory Server 文档：
22.5 处理 Calendar Server 数据库问题
本节包括与 Calendar Server（Berkeley 数据库）数据库有关的各种问题：
本节包含以下主题：
22.5.1 查找 Berkeley 数据库工具
所要采取的多数故障排除步骤都需要您具有对 Berkeley 数据库实用程序的访问权限。虽然在 Calendar Server 包中提供了这些实用程序的某个版本，但它们不受支持。您可能希望直接从 Sleepycat Software () 上获得更多信息。
本节包含以下主题：
22.5.1.1 访问 Berkeley 数据库实用程序
设置并导出 LD_LIBRARY_PATH 环境变量以反映以下目录：
cal-svr-base/SUNWics5/cal/tools/unsupported/bin/
22.5.1.2 可用工具列表
下表列出了一些常用 Berkeley 数据库工具（实用程序）。
Berkeley 数据库工具&
db_archive
将不再使用的日志文件的路径名写入标准输出结果中，每行一个路径名。&
db_checkpoint
一个守护进程，用于监视数据库日志并定期调用检查点例程以对其进行检查点检查。&
db_deadlock
遍历数据库环境锁定区域，并在每次检测到死锁或已超时的锁定请求时异常中止锁定请求。&
将指定文件以 db_load 实用程序能够识别的平面文本格式写入标准输出结果中。
从标准输入中读取文件并将其载入指定的数据库文件。如果文件尚未存在，此工具将创建它。&
db_printlog
调试用于将日志文件转储为用户可读格式的实用程序。&
db_recover
在发生意外的应用程序、数据库或系统故障后，将数据库恢复到一致性状态。&
显示数据库环境的统计信息。&
验证一个或多个文件及其所包含的数据库的结构。&
检测和修复数据库死锁
如果 Berkeley 数据库处于死锁状态，则必须重置数据库。尽早检测到此状态是很重要的。
要使系统可以定期检查数据库以检测到死锁状态并通知管理员，请执行以下步骤：
以有权更改此配置的管理员身份登录。
发布 stop-cal 命令停止 Calendar Server 服务。
转至 /etc/opt/SUNWics5/cal/config 目录。
通过复制和重命名旧的 ics.conf 文件来保存该文件。
如果必要，编辑 ics.conf 使其具有以下值：
local.caldb.deadlock.autodetect=&yes&
将此参数设置为 "yes" 时，将启动用于监视锁定区域的 db_deadlock 守护进程。
22.5.2 检测数据库损坏
导致日历数据库损坏的原因有多种：系统资源争用、硬件错误、应用程序错误和数据库错误，当然还有人为错误。本节介绍了如何检测日历数据库损坏：
22.5.2.1 数据库损坏基本知识
没有人可以保证数据库不被损坏。但您可以最小化数据丢失和运行的停机时间。严密监视数据库和日历服务器是尽早检测到损坏的关键。频繁和完整的备份是在发现损坏后从损坏中恢复的关键。
日历数据库中有两种可能的损坏级别：
应用程序级别&一个或多个数据库文件中的违例条目会在服务器运行这些条目时阻止服务器继续运行。
数据库级别&Berkeley 数据库页面中的损坏会导致各种问题。一个常见的症状是运行 csdb check 时不断循环。另一个常见症状是显示错误消息，例如：
&非法的页面类型或格式&或
&第 97895 页不存在，未设置创建标志&
22.5.2.2 监视日志文件
查看 Calendar Server 日志文件（包括警报日志）中的错误消息，这些消息可能会表明数据库受到损坏。
应该定期查看日志文件，看是否发生了 ALERT、CRITICAL、ERROR 和 WARNING 级别的错误，如果发现这些错误，请检查事件以找出 Calendar Server 操作可能出现的问题。在 Calendar Server 的正常操作过程中，系统会生成 NOTICE 和 INFORMATION 级别的日志事件，以帮助您监视服务器的活动。
任何情况下都不要移除数据库目录中的任何事务日志文件。事务日志文件包含事务更新（添加、修改或删除），移除这些文件将损坏日历数据库，且无法恢复。
注 & 在请求 Calendar Server 技术支持时，可能需要您提供日志文件以协助解决问题。
检查日历数据库的损坏
使用 check 命令可以扫描日历数据库，包括日历属性 (calprops) 和事件以及待办事项（任务），以查看其中是否存在损坏。如果使用 check 命令发现无法解决的冲突，则将在输出结果中报告该情况。
check 命令不检查警报或组调度引擎 (Group Scheduling Engine, 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
如果未指定 dbdir，则 check 命令将针对当前目录中的数据库。
check 命令会生成许多信息，因此考虑将所有输出结果（包括 stdout 和 stderr）重定向到一个文件中（如示例中所示）。
运行完 check 命令后，查看输出文件。如果数据库已损坏，运行 rebuild 命令。
（参见。）
22.5.3 处理大小和数目突然剧增的事务日志文件
自动清除配置设置可能没有正确反映出最终用户希望看到的客户机用户界面。事务日志文件数目和大小的急剧增加可能只是长时间延迟清除&删除日志&记录所造成的。如果是有意进行这样的延迟以满足 Connector for Microsoft Outlook 或 Sync Tool 用户的需求，则出现事务日志文件的大小和数目的剧增并非异常。无需进一步的操作。系统最终会恢复正常。不过，如果最终用户正在使用 Communications Express 客户机，将自动清除设置恢复为其默认值应该可以解决此问题。
22.5.4 防止在数据库损坏（只读模式）时服务中断
本节介绍了如何在处于恢复模式时使损坏的数据库仍然可访问，包含以下主题：
22.5.4.1 使用只读模式
如果遇到数据库损坏，一种防止服务中断的方法是将数据库置入只读模式。此模式允许最终用户读取数据库条目，但不允许添加、修改或删除。如果最终用户试图添加、修改或删除任何日历数据，系统将给出错误消息。另外，数据库处于只读模式时，用于添加、修改或删除日历事件和待办事项的管理员工具将不起作用。
注 & 如果数据库被损坏到无法读取的程度，则必须中断服务直到用备份进行了恢复。使用备份进行恢复的最快方法是拥有完好的紧急备份。参见。
将数据库置入只读模式
以有权更改此配置的管理员身份登录。
发布 stop-cal 命令停止 Calendar Server 服务。
在命令行处，转至 ics.conf 所在的目录：
cd /etc/opt/SUNWics5/config
将参数设置为如下形式以将日历指定为只读模式：
caldb.berkeleydb.readonly=&yes&
通过发出 start-cal 命令重新启动 Calendar Server。
cal-svr-base/SUNWics5/cal/sbin/start-cal
必须重新启动这些服务才能使 ics.conf 更改生效。
22.5.5 处理常见数据库故障
本节介绍了一些常见数据库故障，并提供了一些建议的修正方法。本节包含以下主题：
csadmind 不启动或在启动过程中崩溃
由于 csadmind 是处理组调度引擎 (Group Scheduling Engine, GSE) 和警报分发引擎的服务，因此，此故障可能是由 GSE 队列或警报队列中的违例条目引起的。
修正方法：
如果 csadmind 未处于运行状态，立即发出 stop-cal 命令。
保持日历服务器运行可能导致事务日志累积，从而进一步损坏数据库，并可能需要更长时间才能使事务日志文件与数据库一致。
验证是否已停止所有 Calendar Server 进程。
有关如何验证是否已停止所有进程的说明，参见。
通过发出 start-cal -csadmind 命令来尝试再次重新启动 csadmind。
如果启动成功，通过执行以下步骤确保两个队列运行正常：
使用 csschedule 检查 GSE 队列。
使用 dbrig 检查警报队列。
有关运行 csschedule 和 dbrig 的说明，参见。
如果 csadmind 发生转储故障，分析 pstack。
如果您在跟踪中发现任何与 GSE 相关的函数（这些函数将带有 GSE 字母），请查看 GSE 队列中的第一个条目和引用的事件数据库中的条目。通常情况下，GSE 条目中引用的事件就是违例条目。要解决此问题，请执行以下步骤：
使用 csschedule 删除 GSE 条目。
使用 cscomponents 从数据库中删除违例事件。
有关运行 csschedule 和 cscomponents 的说明，参见。
如果条目未损坏，则可能是日历服务器无法处理的特殊故障。
请执行以下步骤：
拍下损坏的数据库的日历环境快照，并与客户支持联系。
要创建环境备份，请执行以下步骤：
使用 db_checkpoint 实用程序（位于：
cal-svr-base/SUNWics5/cal/tools/unsupported/bin/db_checkpoint）
运行 db_archive -s。
使用 -s 选项确定所有数据库文件，并将其复制到可移动介质（例如 CD、DVD 或磁带）中。
运行 db_archive -l。
使用 -l 选项确定所有日志文件，并将未应用的日志文件复制到可移动介质设备中。
为避免服务中断，请将日历数据库临时置入只读状态，并恢复为紧急备份副本。
将日历数据库临时置入只读状态，以防出现添加、修改或删除事务。最终用户尝试添加、修改或删除任何日历数据时，将收到错误消息。数据库处于只读模式时，用于添加、修改或删除日历事件和待办事项的管理员工具也将不起作用。
要将日历数据库置入只读模式，编辑 ics.conf 文件，按如下所示将指定参数设置为 "yes"：
caldb.berkeleydb.readonly=&yes&
按照中的说明，恢复为紧急备份副本。
配置并启用 csstored 之后，在几分钟的更新后即可使用紧急备份。还应当始终验证紧急备份副本以确保其未损坏。（运行 db_verify。）
如果所有修复操作均失败，请执行转储和重新装入过程以查看是否可以抢修数据库。
中介绍了此过程。
服务已挂起，最终用户无法连接&孤立的锁定
这种情况可能是由包含 Berkeley DB 数据库页面锁定的控制线程在退出时没有释放该锁定而引起的。要确认是否存在此问题，请针对 cshttpd 进程和 csadmind 运行 pstack。（pstack 是位于/usr/bin/pstack 中的标准 UNIX 实用程序）它应当显示为获取锁定而正在等待的线程。
要解决此问题，请重新启动 Calendar Server，如下所示：
转到 start-cal 所在的目录。
cd cal-svr-base/SUNWics5/cal/sbin
发出 start-cal 命令。
./start-cal
csdb 的重新建立总不停止&数据库循环
数据库循环通常是由数据库文件损坏引起的。由于是数据库损坏，因此，它是不可修复的。有以下几种选择：
恢复为紧急备份。
如果是最近发生的损坏，则可以使用其中一个紧急备份。
使用灾难归档恢复过程。
有关建议的过程，请参见。
使用转储和重新装入过程（）。
22.5.6 重建损坏的日历数据库
本节介绍了如何使用 csdb rebuild 命令，并包含以下主题：
22.5.6.1 rebuild 概述
rebuild 命令可以扫描日历数据库并检查日历属性 (calprops)、事件和待办事项（任务），以确定是否发生了损坏。如果 rebuild 命令发现冲突，它将在 cal-svr-base/SUNWics5/cal/sbin/rebuild_db 目录中重新建立一个日历数据库（.db 文件）。
如果未指定 -g 选项，rebuild 命令将重新建立除组调度引擎 (Group Scheduling Engine, 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
如果 sbin 目录的磁盘空间不足，在其他目录中运行 rebuild 命令。
针对日历数据库副本运行 rebuild 命令：
./csdb rebuild /tmp/db /tmp/
如果未指定数据库路径，rebuild 将使用当前目录。/tmp/ 参数指定了重新建立的数据库所在的目录。
如果还要重新建立 GSE 数据库，则包含 -g 选项。
rebuild 命令会生成许多信息，所以考虑将所有输出结果（包括 stdout 和 stderr）重定向到一个文件中。
请始终使用最新的备份副本重建日历数据库。
但是，如果曾丢失大量数据，同时由于定期备份数据库而创建了多个副本，请从最新副本向最旧副本进行重建。（这样做的唯一缺点是已删除的日历组件将重新出现在重建数据库中。）
例如，如果目录 db_0601、db_0615 和 db_0629 中分别有三组备份日历数据库文件，按以下顺序运行 rebuild 命令：
./csdb rebuild db_0629
./csdb rebuild db_0615
./csdb rebuild db_0601
rebuild 命令然后会将重新建立的数据库写入 cal-svr-base/SUNWics5/cal/sbin/rebuild_db 目录中。
运行完 rebuild 命令后，查看 rebuild.out 文件中的输出结果。
如果重新建立成功，rebuild.out 文件中的最后一行应如下所示：
Calendar database has been rebuilt
在上一步中验证重新建立成功后，将重新建立的数据库 (.db) 文件从 rebuild_db 目录复制到您的生产数据库中。
如果从已损坏的数据库中恢复了任何共享 (__db.*) 或日志 (log.*) 文件，请将它们移到其他目录中。
重新启动 Calendar Server。
22.5.6.2 重建输出样例
以下示例显示了此命令及其生成的输出：
# ./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
注 & 以上样例输出显示了对事件和待办事项数据库扫描了两次。这不是错误。首次扫描是为了验证日历属性数据库中的信息，再次扫描是为了确保可以访问日历属性数据库。
22.5.7 使用转储和装入过程来恢复日历数据库
本节包含以下主题：
22.5.7.1 转储和装入概述
使用转储和装入过程尝试恢复损坏的数据库。转储和装入过程使用 Berkeley 数据库 db_dump 和 db_load 实用程序，它们包含在 Calendar Server 的以下目录中：
cal-svr-base /SUNWics5/cal/tools/unsupported/bin
db_dump 实用程序读取数据库文件并将数据库条目写入输出文件，使用的格式与 db_load 实用程序兼容。
要获得有关 db_dump 和 db_load 实用程序的文档，访问 Sleepycat Software 公司的 Web 站点：
使用 db_dump 和 db_load 实用程序恢复数据库能否成功取决于数据库的损坏程度。可能需要使用多个 db_dump 选项才能成功恢复数据库。但如果数据库严重损坏，不可能再恢复，您可能需要恢复为最近一次完好的数据库紧急备份或归档备份。
注 & 在执行转储和装入过程之前，您的日历数据库必须为 Berkeley DB 版本 3.2.9 或更高版本。如果使用的是早期版本，需首先运行 cs5migrate 实用程序升级日历数据库。
要获得 cs5migrate 的最新版本，请与 Sun 技术支持联系。
执行转储和装入过程
以运行 Calendar Server 的用户和组（例如 icsuser 和 icsgroup）身份登录，或以超级用户 (root) 身份登录。
如果必要，请停止 Calendar Server。
使用 csbackup、Sun StorEdge Enterprise BackupTM 软件或 Legato Networker& 等实用程序备份损坏的数据库。
有关更多信息，请参阅。
使用 db_dump 实用程序转储每个损坏的数据库文件。
数据库文件包括 ics50calprops.db、ics50journals.db、ics50alarms.db、ics50events.db、ics50todos.db 和 ics50gse.db。
依次使用以下选项运行 db_dump，直到数据库恢复（或确定数据库无法恢复）：
没有用于数据库稍微损坏的选项。
对于中等程度的数据库损坏，使用 -r 选项。
对于严重程度的数据库损坏，使用 -r 选项。-R 选项从损坏的数据库中转储的数据（包括不完整的记录和已删除的记录）比 -r 选项要多。
例如，运行 db_dump 时带上 -r 选项：
db_dump -r ics50events.db \& ics50events.db.txt
使用 db_load 实用程序将输出文件装入新数据库文件。
db_load new.ics50events.db & ics50events.db.txt
如果 db_load 报告奇数个关键字或数据条目，编辑 db_dump 输出文件，并删除多余的关键字或数据条目。然后再次运行 db_load。
对其他损坏的数据库文件重复以上两步。
也就是，对其他损坏的数据库文件运行 db_dump。
使用 csdb rebuild 命令重新建立已恢复的数据库文件，如所述。
rebuild 完成后，再次查看输出文件中的输出结果。如果重新建立成功，rebuild.out 文件中的最后一行应如下所示：
Calendar database has been rebuilt
如果 csdb rebuild 命令失败，则使用下一个 db_dump 选项（-r 或 -R）来转储数据库。
如果即使是 db_dump 的 -R 选项也无法恢复损坏的数据库，请与 Sun Microsystems 的技术支持或销售代表联系以获得帮助。在此期间，您可能需要恢复为数据库上次完好无损的备份。
22.5.8 恢复自动备份副本
如果已使用中所述的自动备份功能，则可以在动态数据库损坏时使用紧急备份副本。
本节介绍了如何恢复两个不同的自动备份：
22.5.8.1 恢复之前
在恢复备份之前，请确保您已经执行了以下操作：
尝试诊断动态数据库的损坏是由哪个事务引起的。
删除或更正了引起损坏的事务，这样新的归档将不会被损坏。
通过将损坏的数据库复制到另一个目录或可移动介质中来保留它。如果要与技术支持联系，这样做是必要的。
恢复紧急备份
当动态数据库损坏时，紧急备份应当是首选的备份。要恢复紧急备份，请执行以下步骤：
标识损坏的动态数据库目录中的任何未应用或为写入而打开的日志文件。
关闭为写入打开的日志。它包含最新事务。
创建新的（恢复）目录。
将当前紧急备份副本复制到新的恢复数据库目录中。
将 log.* 文件从损坏的动态数据库目录中复制到新的恢复数据库目录中。
如果您要保留数据库的归档副本，请将尚未应用到动态数据库的日志复制到归档目录中，这样归档备份副本就完整了。
针对新的恢复数据库运行 db_recover，同时指定 -c -h 选项。
例如，如果新的恢复目录名为 recoverydb，则命令将如下所示：
db_recover -c -h recoverydb
将 log.* 文件保留在新的恢复目录中。
db_recover 程序将日志文件应用到新的恢复数据库，但是从 4.2 版开始，Berkeley DB 要求保留这些日志文件。
针对新的恢复目录中的数据库文件运行 db_verify。运行 db_verify：
使用这些命令停止 Calendar Server。
cd /opt/SUNWics5/cal/sbin
./stop-cal
使用此命令创建 Calendar Server 数据库 (csdb) 的另一个副本。
cp -Rp /var/opt/SUNWics5/csdb /var/opt/SUNWics5/csdb.db_verify
针对 csdb 的副本运行 db_verify。
请勿针对初始 csdb 运行 db_verify。
LD_LIBRARY_PATH=/opt/SUNWics5/cal/lib
export LD_LIBRARY_PATH
cd /opt/SUNWics5/cal/tools/unsupported/bin
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50alarms.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50calprops.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50events.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50gse.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50journals.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50recurring.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50todos.db
./db_verify -o -h /var/opt/SUNWics5/csdb.db_verify ics50deletelog.db
针对 ics50deletelog.db 运行 db_verify，同时带上 -o 选项。
如果成功运行完成 db_verify，则不会收到任何错误消息。如果数据库文件已损坏，它会抛出错误消息。例如：
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50todos.db
db_verify:Page 612: last item on page sorted greater than parent entry
db_verify: Page 612: incorrect next_pgno 885 found in leaf chain (should be 501)
db_verify: Page 0: page 501 encountered a second time on free list
db_verify: DB-&verify: ics50todos.db: DB_VERIFY_BAD: Database verification failed
针对新的恢复目录运行 csdb -v list。
如果新的恢复目录通过了上述全部三个恢复步骤，则损坏的旧动态数据库将替换为新的恢复数据库。
将新的动态数据库复制到紧急备份目录中以用作新快照。
所有新的日志都将应用到此副本中，直到拍下了下一个定期快照。
启动 Calendar Server。
如果新的恢复目录在任何一个步骤失败，则按如下所述确定未损坏的早期紧急备份：
从新到旧依次对每个紧急备份运行 db_verify 和 csdb -v list，以找到最近一个未损坏的副本。
可以将第一个找到的无损紧急备份副本恢复到动态数据库目录中。
用未损坏的紧急备份替换损坏的动态数据库，如所述。（请确保首先阅读。）
如果所有紧急备份均已损坏且没有可供恢复的归档备份，请致电技术支持。如果具有归档备份，请执行中的过程。（另请参见。）
恢复归档备份
如果您没有未损坏的紧急备份，但有归档备份及其事务日志，则可以通过执行以下步骤来恢复最近未损坏版本的已归档数据库：
标识损坏的动态数据库目录中的任何未应用或为写入而打开的日志文件。
关闭为写入打开的日志。它包含最新事务。
创建新的（恢复）目录。
将最新的归档副本及其日志文件复制到新的恢复数据库目录中。
将任何未应用的 log.* 文件从已损坏的动态数据库目录复制到新的恢复数据库目录中。
针对新的恢复数据库运行 db_recover，同时指定 -c -h 选项。
例如，如果新的恢复目录名为 recoverydb，则命令将如下所示：
db_recover -c -h recoverydb
将 log.* 文件保留在新的恢复目录中。
db_recover 程序将日志文件应用到新的恢复数据库中，但是从 4.2 版开始，Berkeley DB 要求保留这些日志文件。
针对新的恢复目录中的数据库文件运行 db_verify。
过程中的步骤说明了如何运行 db_verify。
针对新的恢复目录运行 csdb -v list。
如果新的恢复目录通过了上述全部三个恢复步骤，则损坏的旧动态数据库将替换为新的恢复数据库。
将新的动态数据库复制到紧急备份目录中以用作新快照。
启动 Calendar Server。
如果新的恢复目录在任何一个步骤失败，则标识未损坏的早期归档备份，如下所述：
依次从新到旧对每个归档备份副本运行以下三个恢复程序，以找到最近一个未损坏的副本：db_recover -c-h、db_verify 和 csdb -v list。
可以将第一个找到的无损归档副本恢复到动态数据库目录中。
用未损坏的归档备份替换损坏的动态数据库，如所述。
如果所有的归档备份均已损坏，请致电技术支持。
22.5.9 修复自定义备份脚本
本节包括以下主题：
22.5.9.1 现在使用动态库编译 Berkeley 工具
如果使用诸如 db_recover 之类的 Berkeley 数据库工具创建了自定义备份脚本，则在升级到 Calendar Server 后可能会发现该脚本不再工作。出现此问题的原因是早期版本的 Calendar Server 使用静态库来编译这些工具。而现在使用动态库 libdb-4.2.so 编译这些工具。
22.5.9.2 修复自定义备份脚本
要将新的动态库与现有的自定义脚本结合使用，请设置以下全局变量，如下所示：
LD_LIBRARY_PATH=libdb-4.2.so