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

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

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

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

Calendar Server の設定プログラム (csconfigurator.sh) を利用して、別のディレクトリを指定することもできます。設定プログラムについては、『Sun ONE Calendar Server 6.0 インストールガイド (Solaris 版)』を参照してください。

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

表 5-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	削除されたイベントと仕事 (タスク)。第 7 章「削除ログデータベースの管理」も参照

csdb ユーティリティを利用したデータベースの管理

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

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

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

カレンダーデータのインポートとエクスポート

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

csdb ユーティリティを実行するには、Calendar Server が稼動しているシステムの管理権限を持つユーザーとしてログインする必要があります。詳細は、第 11 章「Calendar Server のコマンド行ユーティリティ」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

カレンダーデータのインポートとエクスポート

カレンダーデータをファイルにエクスポートしたり、ファイルからインポートするには、csexport ユーティリティと csimport ユーティリティを使用します。サポートされているカレンダーデータの形式は、iCalendar (.ics) と XML (.xml) です。

csexport と csimport は、Calendar Server がインストールされているマシンでローカルに実行する必要があります。Calendar Server は稼動中でも停止していても構いません。

カレンダーデータのエクスポート

カレンダーデータをファイルにエクスポートするときは、csexport を使用します。ファイルの形式は、出力ファイルに指定する拡張子 (.ics または .xml) によって決定されます。

たとえば、カレンダー ID (calid) が JSmithcal のカレンダーを iCalendar 形式 (text/calendar MIME) の jsmith.ics というファイルにエクスポートするには、次のように実行します。

この JSmithcal カレンダーを XML 形式 (text/xml MIME) の jsmith.xml というファイルにエクスポートするには、次のように実行します。

カレンダーデータのインポート

csexport ユーティリティを使用して作成したファイルからカレンダーデータをインポートするときは、csimport を使用します。保存されているインポートファイルの形式は、そのファイルの拡張子 (.ics または .xml) で示されます。

たとえば、カレンダー ID (calid) が JSmithcal のカレンダーに iCalendar 形式 (text/calendar MIME) で保存された jsmith.ics というファイルからデータをインポートするには、次のように実行します。

この JSmithcal カレンダーに XML 形式 (text/xml MIME) で保存された jsmith.xml というファイルからデータをインポートするには、次のように実行します。

指定したカレンダー ID (calid) がすでに存在する場合、そこに含まれる古いデータは新しいデータのインポート前にクリアされます。

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

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

recover コマンドを実行する前に、stop-cal コマンドを実行して Calendar Server を停止してください。

たとえば、現在のディレクトリに格納されている破損したセッションデータベースを復元するときは、次のように実行します。

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


注	破損したカレンダーデータベース (caldb) の復元には、recover ではなく、csdb ユーティリティの check コマンドと rebuild コマンドを使用します。詳細については、「カレンダーデータベースのチェックと再構築」を参照してください。

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

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

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

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

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

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

データ損失の最小化

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

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

データ損失の最小化

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

csbackup ユーティリティや Sun StorEdge^TM Enterprise Backup ソフトウェア、Legato Networker^TM などを使用して、毎日データベースをバックアップします。詳細については、第 6 章「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 コマンドを実行する必要はありません。破損しているデータベースを直ちに再構築してください。

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

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

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

カレンダーデータベースのコピーをまだ作成していない場合は、コピーを作成します。カレンダーデータベース (.db) ファイルだけをコピーします。共有ファイル (__db_name.share) やログファイル (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 を停止します。

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_name.share) やログファイル (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 の実行については、『Sun ONE Calendar Server 6.0 インストールガイド (Solaris 版)』を参照してください。

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

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

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

csbackup ユーティリティや Sun StorEdge^TM Enterprise Backup ソフトウェア、Legato Networker^TM などを使用して、破損しているデータベースのバックアップを作成します。詳細については、第 6 章「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 のテクニカルサポートまたは販売代理店までご連絡ください。最悪の場合は、データベースの最終バックアップを使用しなければなりません。