test

Sun Java System Calendar Server 6.3 管理ガイド

22.5.2 データベースの破損の検出

カレンダデータベースは、システムリソースの競合、ハードウェアの障害、アプリケーションエラー、データベース障害、人為的な原因など、さまざまな原因で破損することがあります。ここでは、カレンダデータベースの破損を検出する方法について説明します。

22.5.2.1 データベース破損の基本的考え方

データベースが破損しないと誰にも保証はできません。ですが、データの損失と運用停止時間を最小限にとどめることができます。破損を早期に検出するには、厳密にデータベースおよびカレンダサービスを監視することが重要です。頻繁に完全なバックアップを行なっておくことが、破損が検出された場合に復元する秘訣です。

カレンダデータベースで起こりうる破損には、2 つのレベルがあります。

22.5.2.2 ログファイルの監視

データベース破損の兆候を示すエラーメッセージについて、アラームログを含む Calendar Server ログファイルを監視します。

ALERT 、CRITICAL、ERROR、および WARNING レベルのエラーについて、ログファイルを定期的に調べてください。これらのエラーが見つかったときは、Calendar Server の動作で考えられる問題について調査します。NOTICE および INFORMATION レベルのログ予定は、Calendar Server の通常動作中に生成されることがあります。これは、サーバーアクティビティーの監視に役立つように提供されています。

データベースディレクトリ内のトランザクションログファイルを削除しないでください。トランザクションログファイルにはトランザクションの更新 (追加、変更、削除) が記録されており、これを削除すると復元できない状態にまでカレンダデータベースが破損してしまうことがあります。

注 –

Calendar Server に関するテクニカルサポートを依頼する場合、問題解決のためにログファイルの提出が必要となることがあります。

Procedureカレンダデータベースの破損をチェックするには

カレンダプロパティー (calprops)、予定、および仕事 (作業) を含め、カレンダデータベースを走査して破損がないかどうか調べるには、check コマンドを使用します。check コマンドにより回復不能な不整合が検出された場合、その状況がレポートとして出力されます。

check コマンドは、アラームまたは GSE (グループスケジューリングエンジン) データベースの破損をチェックしません。

  1. Calendar Server がインストールされているシステムの管理権限を持つユーザーとしてログインします。

  2. 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 コマンドを実行します。

    「22.5.6 破損したカレンダデータベースの再構築」を参照してください。