第 14 章 Calendar Server データベースの管理

この章では、Sun Java^TM System Calendar Server データベースの管理について、次の項目を説明します。

Calendar Server データベースファイル

デフォルトでは、Calendar Server データベースファイル (および cld_cache、ldap_cache ディレクトリ) は次のディレクトリに作成、維持されます。

Calendar Server の設定プログラム (csconfigurator.sh) を利用して、別のディレクトリを指定することもできます。設定プログラムの詳細については、第 3 章「Calendar Server の設定」を参照してください。

表 14-1 はカレンダーデータベースファイルを示しています。

表 14-1 Calendar Server データベースファイル
ファイル	説明
ics50calprops.db	すべてのカレンダーのカレンダープロパティ。カレンダー ID (calid)、カレンダー名、ACL (アクセス制御リスト)、所有者が記録されている
ics50events.db	すべてのカレンダーの予定
ics50todos.db	すべてのカレンダーの仕事 (作業)
ics50alarms.db	すべての予定と仕事 (作業) のアラーム
ics50gse.db	GSE (グループスケジューリングエンジン) のスケジューリング要求のキュー
ics50journals.db	カレンダーのジャーナル。現在のリリースにはジャーナルは実装されていない
ics50caldb.conf	データベースのバージョン識別子
ics50recurring.db	繰り返し予定
ics50deletelog.db	削除された予定と仕事 (作業)。第 16 章「削除ログデータベースの管理」も参照してください。

csdb ユーティリティでは 3 つの論理データベースを形成することによって、Calendar Server データベースファイルを管理します。

caldb : 次の場所にあるすべての .db ファイルと _db.* ファイルで構成される
/var/opt/SUNWics5/csdb/

sessdb : 次のセッションディレクトリ内の session.db および _db.* ファイルで構成される
/opt/SUNWics5/cal/lib/admin/session/
/opt/SUNWics5/cal/lib/http/session/

statdb : 次の場所の counter ディレクトリ内にあるすべてのファイルで構成される
/opt/SUNWics5/cal/lib/counter/

csdb を使用したカレンダーデータベースの管理

ここでは、csdb ユーティリティを使用して次の作業を行う方法について説明します。

ターゲットデータベースの指定

csdb ユーティリティでターゲットデータベースを指定するときは、-t オプションを使用します。

-t caldb : カレンダーデータベース

-t sessdb : セッションデータベース

-t statdb : 統計情報データベース

-t オプションを指定しない場合、csdb は 3 種類すべてのデータベースを対象に動作します。ただし、check コマンドと rebuild コマンドの対象はカレンダーデータベースだけです。

カレンダーデータベースの状態の表示

カレンダーデータベースの状態を確認するときは、csdb ユーティリティの list コマンドを使用します。Calendar Server は稼動中でも停止していても構いません。

ターゲットデータベース (caldb、sessdb、statdb) を指定するときは、-t オプションを指定します。指定しない場合、csdb は 3 種類すべてのデータベースを対象に動作します。

たとえば、すべてのデータベースの状態と統計情報を表示するときは、次のように実行します。

現在のディレクトリに格納されているカレンダーデータベースに関する情報を冗長モードで表示するときは、次のように実行します。

破損したデータベースの復元

破損したデータベースの復元に使用するユーティリティは、データベースのタイプによって異なります。

破損してしまったセッションデータベースまたは統計情報データベースを復元するときは、csdb ユーティリティの recover コマンドを使用します。ターゲットデータベース (セッションは sessdb、統計情報は statdb) の指定には -t オプションを使用します。

破損したデータベース (caldb) を復元するには、「カレンダーデータベースのチェックと再構築」で説明するように、csdb ユーティリティの check コマンドおよび rebuild コマンドを使用します。

カレンダーデータベースの削除

カレンダーデータベースを削除するには、csdb ユーティリティの delete コマンドを使用します。Calendar Server は停止している必要があります。

ターゲットデータベース (caldb、sessdb、statdb) を指定するときは、-t オプションを指定します。指定しない場合、csdb は 3 種類すべてのデータベースを削除します。

たとえば、カレンダーデータベースを削除するときは、次のように実行します。

データベースを削除する前に、csdb ユーティリティは警告を出力します。

データベースの破損の検出と復元

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

データ損失の最小化

カレンダーデータベースのチェックと再構築

ダンプとロードによるカレンダーデータベースの復元

データ損失の最小化

どれだけ優れた復元手順を実行するにしても、データの損失を最小限に抑えるにはデータベースの破損をできるだけ早く検出することが重要です。データベースの破損を検出するために、次の点を考慮してください。

csbackup ユーティリティや Sun StorEdge^TM Enterprise Backup ソフトウェア、Legato Networker^TM などを使用して、毎日データベースをバックアップします。詳細については、第 15 章「Calendar Server データのバックアップと復元」を参照してください。

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

csmonitor ユーティリティを使用して Calendar Server を監視し、複数のトランザクションログファイルの発生やカレンダーデータベースのディスク容量の不足などの問題が生じた時点で管理者に電子メールを送信するようにします。詳細については、「「csmonitor」」を参照してください。

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

カレンダーデータベースのチェックと再構築

カレンダーデータベース (caldb) を調べ、必要に応じて再構築できるように、csdb ユーティリティには次のコマンドが用意されています。

check コマンド。カレンダーデータベースを走査して破損がないかどうかを調べ、結果をレポートとして出力します。check コマンドは、アラームまたは GSE (グループスケジューリングエンジン) データベースの破損をチェックしません。

rebuild コマンド。カレンダーデータベースを走査して破損がないかどうかを調べ、必要に応じて再構築したカレンダーデータベース (.db ファイル) を出力します。

データベースの問題を生じる可能性のある予定が発生したら、check コマンドを実行し、必要に応じて rebuild コマンドも実行します。たとえば、サイトで電源障害が発生したときは、check コマンドを実行してデータベースの破損が生じていないかどうかを確認します。

csdb ユーティリティには、破損したセッションデータベースおよび統計情報データベースを復元するための recover コマンドも用意されています。カレンダーデータベースが破損した場合は、recover ではなく check と rebuild を使用します。

カレンダーデータベースの破損チェック


警告	これらのコマンドを実行する前に、csbackup ユーティリティ (またはその他のバックアップユーティリティ) を使用してカレンダーデータベースのバックアップを作成します。

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

check コマンドを定期的に実行し、カレンダーデータベースの不整合を調べてください。たとえば、データベースをバックアップするたびに check を実行します。ただし、カレンダーデータベースの破損がすでに分かっている場合は、check コマンドを実行する必要はありません。破損しているデータベースを直ちに再構築してください。

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

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

Calendar Server は稼動中でも停止していても構いませんが、可能であれば停止してください。

カレンダーデータベースのコピーをまだ作成していない場合は、コピーを作成します。データベース (.db) ファイルだけをコピーします。共有ファイル (__db.*) やログファイル (log.*) をコピーする必要はありません。

cal_svr_base/opt/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 コマンドを実行します。

カレンダーデータベースの再構築

rebuild コマンドはカレンダーデータベースを走査し、破損がないかどうかについてカレンダープロパティ (calprops) 予定および仕事 (作業) を調べます。不整合が検出されると、rebuild コマンドは再構築したカレンダーデータベース (.db ファイル) を cal_svr_base/opt/SUNWics5/cal/sbin/rebuild_db ディレクトリに生成します。

-g オプションを指定せずに rebuild コマンドを実行すると、GSE (グループスケジューリングエンジン) データベース以外のすべてのデータベースが再構築されます。GSE データベースも再構築するときは、-g オプションを指定します。

GSE データベースにエントリが含まれているかどうかを調べるには、csschedule -v list コマンドを実行します。GSE がすべてのエントリの処理を完了してから rebuild コマンドを実行してください。

カレンダーデータベースを再構築するには

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

Calendar Server を停止します。

カレンダーデータベースのコピーをまだ作成していない場合は、コピーを作成します。データベース (.db) ファイルとログ (log.*) ファイルをコピーします。共有ファイル (__db.*) をコピーする必要はありません。

cal_svr_base/opt/SUNWics5/cal/sbin ディレクトリに移動します。たとえば、Solaris オペレーティングシステムでは次のように入力します。

cd /opt/SUNWics5/cal/sbin

注 : sbin ディレクトリのディスク容量が問題となる場合は、別のディレクトリで rebuild コマンドを実行してください。

カレンダーデータベースのコピーに対して rebuild コマンドを実行します。

./csdb rebuild /tmp/db /tmp/

データベースディレクトリを指定しない場合、現在のディレクトリに格納されているデータベースに対して rebuild が実行されます。/tmp/ パラメータは、再構築したデータベースの出力先ディレクトリを指定しています。

GSE データベースも再構築するときは、-g オプションを指定します。

rebuild は大量の情報を生成する可能性があるので、stdout や stderr を含むすべての出力をファイルとして書き出すことをお勧めします。



注	カレンダーデータベースを再構築するときは、常に最新のバックアップコピーを使用してください。ただし、膨大なデータが失われ、データベースの定期バックアップで複数のコピーを利用できるときは、最新のコピーから最も古いコピーの順に再構築を行います。この方法の唯一の欠点は、すでに削除されているカレンダーコンポーネントが再構築されたデータベースに再表示されることです。たとえば、3 つのバックアップカレンダーデータベースファイルが db_0601、db_0615、db_0629 というディレクトリに格納されている場合は、次の順序で rebuild コマンドを実行します。 ./csdb rebuild db_0629 ./csdb rebuild db_0615 ./csdb rebuild db_0601 rebuild は再構築したデータベースを cal_svr_base/opt/SUNWics5/cal/sbin/rebuild_db ディレクトリに書き込みます。

rebuild の実行が完了したら、rebuild.out ファイルを開きます。再構築が正常に完了した場合、rebuild.out ファイルの最後の行は次のようになります。

Calendar database has been rebuilt

前の手順で再構築の成功を確認したときは、再構築したデータベースファイル (.db) を rebuild_db ディレクトリから運用データベースにコピーします。

破損したデータベースのディレクトリに共有ファイル (__db.*) やログファイル (log.*) が含まれていた場合は、それも運用ディレクトリに移動します。

Calendar Server を再起動します。

ダンプとロードによるカレンダーデータベースの復元

csdb rebuild コマンドの実行が成功しなかった場合に破損したデータベースを復元するには、ダンプとロードの手順を試みます。ダンプとロードの手順では、Berkeley データベースの db_dump ユーティリティと db_load ユーティリティを使用します。Calendar Server では、これらのユーティリティは次のディレクトリに格納されています。

db_dump ユーティリティはデータベースファイルを読み取り、エントリを db_load ユーティリティと互換性のある形式で出力ファイルに書き込みます。

db_dump ユーティリティと db_load ユーティリティのマニュアルについては、Sleepycat Software の Web サイトを参照してください。

db_dump と db_load によるデータベースの復元が成功するかどうかは、データベースの破損具合によって決まります。データベースを復元するまでに、db_dump オプションを何度か実行しなければならないこともあります。ただし、破損が著しいデータベースは復元できません。この場合は、データベースの最終バックアップを使用しなければなりません。

カレンダーデータベースのバージョン

ダンプとロードの手順を実行するときは、カレンダーデータベースが Berkeley DB バージョン 3.2.9 以上である必要があります。それ以前のバージョンを利用している場合は、事前に cs5migrate ユーティリティを使用してカレンダーデータベースをアップグレードしてください。

最新バージョンの cs5migrate については、ご購入先のテクニカルサポートに問い合わせてください。

ダンプとロードの手順を実行するには

Calendar Server を実行するユーザーとグループ (icsuser、icsgroup など)、またはスーパーユーザー (root) として Solaris オペレーティングシステムにログインします。

Calendar Server が停止していなければ、停止します。

csbackup ユーティリティや Sun StorEdge^TM Enterprise Backup ソフトウェア、Legato Networker^TM などを使用して、破損しているデータベースのバックアップを作成します。詳細については、第 15 章「Calendar Server データのバックアップと復元」を参照してください。

db_dump ユーティリティを使用して、破損しているデータベースの各ファイルをダンプします。データベースファイルは、ics50calprops.db、ics50journals.db、ics50alarms.db、ics50events.db、ics50todos.db、ics50gse.db です。

データベースが復元されるまで (または復元不可能であると判明するまで)、次のオプションを順に指定して db_dump を実行します。

オプションなし : 軽度のデータベース破損

-r オプション : 中度のデータベース破損

-R オプション : 重度のデータベース破損。-R オプションを指定した場合、破損しているデータベースから部分的なレコードや削除されたレコードなども含め、-r オプションを指定した場合より多くのデータがダンプされる

たとえば、-r オプションを指定して db_dump を実行するときは、次のように入力します。

db_dump -r ics50events.db > ics50events.db.txt

db_load ユーティリティを使用して、出力ファイルを新しいデータベースファイルにロードします。

例 :

db_load new.ics50events.db < ics50events.db.txt

注 : db_load が奇数のキーまたはデータエントリをレポートする場合は、手順 4 で生成した db_dump 出力ファイルを編集し、異常のあるキーまたはデータエントリを削除します。次に、db_load を再実行します。

破損しているその他のデータベースファイルに対して手順 4 と手順 5 を繰り返します。

「カレンダーデータベースの再構築」で説明した csdb rebuild コマンドを使用して、復元したデータベースファイルを再構築します。

rebuild の実行が完了したら、出力ファイルを開きます。再構築が正常に完了した場合、rebuild.out ファイルの最後の行は次のようになります。

Calendar database has been rebuilt

csdb rebuild コマンドの実行が成功しなかった場合は手順 4 に戻り、次レベルの db_dump オプション (-r または -R) を指定してデータベースのダンプを行います。

db_dump -R オプションを実行しても破損しているデータベースを復元できない場合は、ご購入先のテクニカルサポートまたは販売代理店までご連絡ください。最悪の場合は、データベースの最終バックアップを使用しなければなりません。

推奨事項: カレンダーストアの管理と保守

管理と保守のためには、次の予防対策を毎日実行してください。

前へ目次索引次へ
Sun Java System Calendar Server 管理ガイド