test

Sun Java System Calendar Server 6 2005Q4 管理ガイド

一般的なデータベース障害の処理

ここでは、いくつかの一般的なデータベース障害と、推奨する対応策について説明します。ここで説明する内容は次のとおりです。

Procedurecsadmind が起動しない、または起動時にクラッシュする

csadmind では GSE (グループスケジューリングエンジン) とアラームディスパッチエンジンの両方のサービスを処理するため、GSE キュー内、またはアラームキュー内のエントリに問題があると、これらの問題が発生する可能性があります。

対応策

手順

  1. csadmind が稼動していない場合は、すぐに stop-cal を実行します。

    カレンダサービスを稼動したままにしておくと、トランザクションログが累積し、それが原因でデータベースがさらに破損して、トランザクションログファイルとデータベースを照合するのに時間がかかる場合があります。

  2. csadmind の再起動を試みます (start-cal の再実行)。

    正常に起動したら、次のようにして 2 つのキューが機能していることを確認します。

    1. csschedule を使用して、GSE キューをチェックします。

    2. dbrig を使用して、アラームキューをチェックします。

      csschedule および dbrig の実行方法については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 を参照してください。

  3. csadmind がダンプでクラッシュした場合は、pstack を分析します。

    トレースに GSE に関連した機能がある場合は (中に GSE の文字がある)、GSE キューの最初のエントリおよび予定データベースの参照エントリを調べます。ほとんどの場合、GSE エントリで参照されている予定が、問題を起こしているエントリです。この問題を解決するには次を実行します。

    1. csschedule を使用して、GSE エントリを削除します。

    2. cscomponents を使用して、問題を起こしている予定をデータベースから削除します。

      csschedule および cscomponents の実行方法については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 を参照してください。

  4. エントリが破損していない場合は、カレンダサーバーでは処理できない特殊な例の可能性があります。

    次の手順を実行します。

    1. 破損したデータベースのカレンダ環境のスナップショットを取り、カスタマサポートに問い合わせます。

      環境のバックアップを作成するには、次のように実行します。

      1. 次の場所にある db_checkpoint ユーティリティーを使用します。

        cal_svr_base/SUNWics5/cal/tools/unsupported/bin/db_checkpoint

      2. db_archive -s を実行します。

        -s オプションを使用して、すべてのデータベースファイルを識別し、それらを CD、DVD、テープなどのリムーバブルメディアにコピーします。

      3. db_archive -l を実行します。

        -l オプションを使用して、すべてのログファイルを識別し、使用されていないファイルをリムーバブルメディアデバイスにコピーします。

    2. サービスの停止を避けるには、カレンダデータベースを一時的に読み取り専用の状態にして、ホットバックアップのコピーに戻ります。

      • カレンダデータベースを一時的に読み取り専用の状態にすると、トランザクションの追加、変更、または削除はできなくなります。エンドユーザーがカレンダデータを追加、変更、または削除しようとすると、エラーメッセージが表示されます。カレンダの予定および仕事を追加、変更、または削除する管理者ツールも、データベースが読み取り専用モードの間は機能しません。

        カレンダデータベースを読み取り専用モードにするには、ics.conf ファイルを編集して、次のパラメータを “yes” に設定します。

        caldb.berkeleydb.readonly=”yes”

      • 「自動バックアップコピーの復元」にある手順を使用して、ホットバックアップコピーに戻ります。

        csstored を設定して有効にすると、ホットバックアップが使用可能になり、数分以内に最新の状態になります。また、常にホットバックアップコピーを検証して、破損していないことを確認するとよいでしょう。その場合は、db_verify を実行します。

  5. ほかの方法がすべて失敗した場合、ダンプと再ロードの手順を実行して、データベースを修復できるかどうか確認します。

    この手順は、「ダンプとロードによるカレンダデータベースの復元」で説明しています。

Procedureサービスがハングし、エンドユーザーが接続できない: 親のないロック

この状態は、制御スレッドが原因で発生する場合があります。これは Berkeley DB データベースのページをロックし、ロックを解除しないで終了します。この問題を確認するには、cshttpd プロセスおよび csadmind 上で pstack を実行します。pstack は標準 UNIX ユーティリティーで、次の場所に格納されています。/usr/bin/pstack。このユーティリティーにより、ロックを獲得するために待機しているスレッドが表示されます。

問題を解決するには、次のようにして Calendar Server を再起動します。

手順

  1. start-cal が存在するディレクトリに移動します。

    cd cal_svr_base/SUNWics5/cal/sbin

  2. start-cal コマンドを実行します。

    ./start-cal

Procedurecsdb rebuild が終了しない: データベースのループ

データベースのループは、通常、データベースファイルの破損により起こります。データベースが破損しているため、回復不能になる可能性があります。次のいくつかの選択肢があります。

手順

  1. ホットバックアップに戻ります。

    破損が最近起こったのであれば、いずれかのホットバックアップコピーを使用できます。

  2. 壊滅的アーカイブのリカバリプロセスを使用します。

    推奨されるプロセスについては、「自動バックアップコピーの復元」を参照してください。

  3. ダンプと再ロードの手順を使用します。「ダンプとロードによるカレンダデータベースの復元」を参照してください。