第 22 章トラブルシューティング

この章では、システムに問題があるかどうか、またその原因を調べるためのトラブルシューティングの方法について説明します。この章で説明する内容は次のとおりです。

デバッグ情報の有効化

システム全体をデバッグモードにする ics.conf パラメータはありませんが、ここでは有用なデバッグ情報を取得する方法について説明します。

「ログレベルを上げる」

「LDAP キャッシュへのアクセスログの有効化」

「Calendar Server ユーティリティによるシステムの監視」

ログレベルを上げる


注	パフォーマンスにマイナスの影響を与えるため、必要でない場合は、必ず、過度なログ記録および監視は無効にしてください。

表 22-1 のパラメータを使用して、ログの詳細度を上げます。

LDAP キャッシュへのアクセスログの有効化

表 22-1 デバッグモードを有効にするための ics.conf パラメータ
パラメータ	説明とデフォルト値
logfile.loglevel	CRITICAL、ALERT、ERROR、WARNING、NOTICE、および INFORMATION を含む、すべてのレベルでログ記録されるように、DEBUG に設定します。この設定はすべてのログに適用されます。

LDAP データキャッシュのすべてのアクセスをログに記録し、そのログ (レポート) を出力するには、表 22-2 に示す ics.conf パラメータを設定します。

表 22-2 デバッグモードを有効にするための ics.conf パラメータ
パラメータ	説明とデフォルト値
local.ldap.cache.stat.enable	LDAP データキャッシュへのアクセスをログに記録し、ログファイルに統計情報を出力するかどうかを指定します。デフォルトは "no" です (統計情報はログ記録されない)。統計情報のログを有効にするには、"yes" に設定します。パフォーマンス向上のために、このパラメータはデバッグモードでのみ使用してください。
local.ldap.cache.stat.interval	統計情報レポートをログファイルに書き込む間隔を秒単位で指定します。デフォルトは "1800" 秒 (30 分) です。これは、ログが有効になっている場合にのみアクティブになります。間隔を短くすると、問題を特定するのに役立ちます。間隔を長くすると、システムロードが減少します。

Calendar Server ユーティリティによるシステムの監視

システムを監視するには、次の Calendar Server ユーティリティを使用します。

csmonitor: 必要なデバッグレベルを指定します。数字が大きいほど、メッセージがより詳細になります。

csstats: counter.conf ファイルに定義されているカウンタオブジェクトからの統計情報を表示するには、list コマンドを使用します。

cstool: cshttpd、csadmind、および enpd の各サービスに対して ping を実行するには、このユーティリティを使用します。

LDAP の問題のトラブルシューティング

ここでは、LDAP の問題に関連する次の内容について説明します。

「Calendar Server ユーティリティが機能しない」

Calendar Server ユーティリティが機能しない

ホストされた環境を最初に作成する時に、ドメイン、コンテナ、ユーザー、リソースの適切なエントリを追加して、LDAP に DC ツリーを作成する必要があります。cscal などの Calendar Server のユーティリティを使用する際に、DC ツリーが存在しないと、次のエラーメッセージが表示される可能性があります。"Initialization failed .... exiting"。

DC ツリーには、DC ツリーのルートに少なくとも 1 つの (デフォルト) ドメインが含まれていることを確認します。「ホストされたドメインを追加するには (Schema 1)」に記載されている方法を使用して DC ツリー構造を作成します。

移行ユーティリティのトラブルシューティング

Calendar Server には、カレンダーデータベースおよび LDAP ディレクトリを移行するためのいくつかのユーティリティが用意されています。ここで説明する内容は次のとおりです。

「テクニカルサポートに問い合わせる前に必要なこと」

「移行ユーティリティの入手先」

テクニカルサポートに問い合わせる前に必要なこと

一般に、移行ユーティリティを使用して問題が生じた場合、次の情報を収集してから、テクニカルサポートに問い合わせることをお勧めします。

問題のデータベースのバックアップコピー。

すべての関連ログのコピー。

コアを含むすべてのエラー出力メッセージ。

移行ユーティリティの入手先

さまざまな移行ユーティリティおよびそのマニュアルは、次の一覧に示す場所にあります。

スキーマ移行ユーティリティ (commdirmig): このユーティリティは Access Manager のインストールと同時にインストールされます。このユーティリティは Schema 1 から LDAP ディレクトリを Schema 2 に移行します。このユーティリティについては、『Sun Java System Communications Services 6 2005Q1 Schema Migration Guide』を参照してください。

Calendar Server 5.x から Calendar Server 6.x への移行ユーティリティ (cs5migrate、および cs5migrate_recurring): テクニカルサポートサイトにはユーティリティとそのマニュアルを含む移行バンドルが用意されています。

csmig: このユーティリティは Calendar Server にインストールされています。マニュアルは第 4 章「データベース移行ユーティリティ」に記載されており、トラブルシューティングの節が含まれています。ホストされたドメインおよび LDAP カレンダー検索データベース (CLD) プラグインを使用している場合は、このユーティリティを実行する必要があります。

csvdmig: このユーティリティは Calendar Server にインストールされています。マニュアルは第 4 章「データベース移行ユーティリティ」に記載されています。ホストされたドメイン用のカレンダーデータベースおよび LDAP ディレクトリのエントリを準備するには、このユーティリティを使用します。

Calendar Server 2.x から Calendar Server 6.x への移行ユーティリティ (ics2migrate): このユーティリティは Calendar Server にインストールされています。マニュアルは第 4 章「データベース移行ユーティリティ」に記載されています。このユーティリティを使用して Calendar Server 2.x データベースを移行し、Calendar Server 5.x との互換性を持たせます。

Netscape Calendar Server 4.x から Calendar Server 5.x への移行ユーティリティ (ncs4migrate): このユーティリティは、テクニカルサポートサイトからのみ入手できます。ユーティリティパッケージにはマニュアルが含まれています。このユーティリティは Netscape Calendar Server 4.x を Calendar Server 5.x に移行します。これらの移行には特に注意を要します。移行の計画をサポートする Professional Services を利用されることをお勧めします。

Calendar Server のトラブルシューティング

ここでは、データベース以外の問題のさまざまなトラブルシューティングについて説明します。ここで説明する内容は次のとおりです。

「カレンダーサービスに対する ping の実行」

「正しく完了しない検索のトラブルシューティング」

「csstored のわずらわしい日常的なメッセージを無効にする」

カレンダーサービスに対する ping の実行

サービスが特定のポート番号で待機していることを確認するには、cstool ユーティリティの ping コマンドを実行します。サービスに対して ping を実行しても、サービスが実際に稼動しているかどうかは検証されません。ソケット接続が受け付けられるかどうかが検証されます。

http: HTTP サービス (cshttpd)

admin: 管理サービス (csadmind)

ens: ENS (予定通知サービス) (enpd)



注	現在のリリースでは、DWP サービス (csdwpd)、通知サービス (csnotifyd) に対して ping を実行することはできません。

cstool を実行するには、Calendar Server が稼動している必要があります。

たとえば、calserver というホスト名のマシンに対して ping を実行し、cshttpd サービスがポート 80 で待機しているかどうかを確認するには、次のように実行します。

デフォルトでは、cstool は 120 秒間応答を待ちますが、 -t timeout オプションを使用してこの値を変更することができます。

start-cal の問題の解決

start-cal を実行したときに起動しないカレンダーサービスがある場合は、再起動する前に起動したサービスを終了する必要があります。たとえば、enpd、csnotifyd、および csadmind は起動したが cshttpd が起動しなかった場合、必ず、enpd、csnotifyd、および csadmind を終了してください。

カレンダーサービスを起動するには、次のように実行します。

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

サービスを終了して、再起動するには、start-cal を使用します。次に例を示します。

cal_svr_base/SUNWics5/cal/sbin/start-cal

start-cal は、さまざまなカレンダーサービスを起動する前に、まず stop-cal コマンドを実行します。

stop-cal が終了に失敗した場合は、いくつかの子プロセスが終了に失敗した可能性があります。この処理については、「stop-cal の問題の解決」を参照してください。

stop-cal の問題の解決

Calendar Server のシャットダウン時には、考慮する必要がある 2 つの別個の問題があります。

「子プロセスを停止するには」

「不正シャットダウンした後で回復するには」

子プロセスを停止するには

stop-cal を実行した後、いくつかの子プロセスが停止していない場合があります。たとえば、stop-cal によって cshttpd 親プロセスは停止しているのに、一部の cshttpd 子プロセスが停止していないことがあります。このような場合は、次の手順で、残りの Calendar Server プロセスを個別に停止させる必要があります。

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

サービスごとに ps コマンドを実行し、残っている Calendar Server プロセスのプロセス ID (PID) を特定します。

ps -elf | grep cs-process

ここで、cs-process は enpd、csnotifyd、csdwpd、csadmind、または cshttpd です。次に例を示します。

ps -elf | grep cshttpd

kill -15 コマンドに終了していない各プロセスの PID を指定して、プロセスを終了します。次に例を示します。kill -15 9875

それぞれの ps コマンドをもう一度実行し、すべての Calendar Server プロセスが終了していることを確認します。

Calendar Server プロセスがまだ稼動しているときは、kill -9 コマンドを実行して終了します。次に例を示します。kill -9 9875



注	Linux システムで Calendar Server を実行していて、ps コマンドを使用してカレンダープロセスを検索すると、結果が混乱しているように見えます。Linux では、ps コマンドは、プロセスのリストではなく実行しているスレッドのリストを返します。プロセスだけが表示されるようにするための既知の解決策はありません。

不正シャットダウンした後で回復するには

Calendar Server が正しくシャットダウンしなかった場合は、次の手順を実行します。

前の手順 (「子プロセスを停止するには」) を実行します。

LDAP データキャッシュデータベースのディレクトリ内のすべてのファイルを手動で削除します。ファイルが残っていると、データベースが破損する可能性があります。ファイルを削除するには、次のように実行します。

LDAP データキャッシュのディレクトリに移動します。デフォルトでは、/opt/SUNWics5/csdb/ldap_cache ですが、ics.conf ファイルの local.ldap.cache.homedir.path パラメータにより指定されるディレクトリを使用してください。

ディレクトリ内のすべてのファイルを削除します。

例: rm *.*

すべてのファイルが削除されたことを確認します。

例: ls

Calendar Server を再起動します。

cal_svr_base/SUNWics5/cal/sbin/start-cal

LDAP データキャッシュの設定方法については、「LDAP データキャッシュを有効にするには」を参照してください。付録 E 「Calendar Server の設定パラメータ」には、LDAP データキャッシュの設定に使用される ics.conf パラメータの一覧が記載されています。LDAP データキャッシュの詳細については、『Sun Java System Communications Services 6 2005Q1 配備計画ガイド』を参照してください。

バックエンドサーバーに接続できない

フロントエンドサーバーがバックエンドサーバーと接続できないことを示すエラーメッセージが表示される場合は、次の手順を実行します。

応答しているかどうか調べるには、バックエンドサーバーに対して ping を実行します。

応答している場合は、手順 2 に進みます。応答していない場合は、接続できない原因を調べ、再び動作するようになったら、手順 3 に進みます。

CLD キャッシュをクリアします。「CLD キャッシュのクリア」を参照してください。

CLD キャッシュオプションを使用していて、ics.conf パラメータのサーバー名を更新した場合は、CLD キャッシュをクリアしてサーバー名を消去する必要があります。CLD キャッシュに古いエントリが残されていると、フロントエンドサーバーが正しいバックエンドサーバーに接続できなくなったり、Calendar Server が移動後のカレンダーを見つけられなくなります。

Calendar Server を再起動します。

カレンダーが見つからない

CLD キャッシュオプションを使用していて、1 つ以上のカレンダーを別のバックエンドサーバーに移動した (または、バックエンドサーバーの名前を変更した) 場合は、次の手順を実行します。

次に記載されている手順に従ってカレンダーを移動していることを確認します。

「ユーザーカレンダーを別のバックエンドサーバーへ移動するには」を参照してください。

CLD キャッシュをクリアします。「CLD キャッシュのクリア」を参照してください。

1 つ以上のカレンダーを別のバックエンドサーバーに移動すると、CLD キャッシュは無効になります。再読み込みするには、キャッシュをクリアする必要があります。そうすると、キャッシュが再構築されます。

正しく完了しない検索のトラブルシューティング

LDAP ディレクトリサーバー設定の nsslapd-sizelimit 属性と nsLookthroughLimit 属性は、検索が正しく終了するように十分なサイズに設定する必要があります。nsSizeLimit が十分なサイズでない場合は、一部の結果が欠落したり、検索結果が表示されなくなることがあります。nsLookthroughLimit が十分なサイズでない場合、検索が完了しないことがあります。

「制限属性の値が適切かどうかを調べるには」

「制限属性を適切な値に設定するには」

制限属性の値が適切かどうかを調べるには

これらの属性に適切な値が設定されているかどうかを調べるには、次のコマンドを実行します。

ldapsearch -b "base"
"(&(icscalendarowned=*user*)(objectclass=icsCalendarUser))"

base は、Calendar Server のユーザーとリソースのデータが格納されているディレクトリサーバーの LDAP ベース DN です。user は、エンドユーザーが Calendar Express の「登録」-「カレンダーの検索」ダイアログで入力できる値です。

LDAP サーバーがエラーを返す場合、nsSizeLimit または nsLookthroughLimit パラメータの値が十分でない可能性があります。

制限属性を適切な値に設定するには

nsLookthroughLimit の値を動的に設定するには、ldapmodify を使用します。つまり、この属性を変更するために Directory Server を終了して再起動する必要はありません。

デフォルト値は 5000 です。検索結果が表示されない場合、この値を大きくすることができます。ただし、そうすると LDAP サーバーのパフォーマンスが低下します。

制限を -1 に設定して、制限の適用を解除することもできます。ただし、システムがハングすることが想定されるため、慎重に行ってください。

nsslapd-sizelimit をより高い値に設定する場合は、次の手順を実行する必要があります。

Directory Server を停止します。

dse.ldif ファイルを編集します。

Directory Server を再起動します。



注	ldapmodify の使用方法および dse.ldif ファイルの編集方法については、『Sun Java System Directory Server 5 2005Q1 Administration Reference』の「Server Configuration Reference」を参照してください。

csstored のわずらわしい日常的なメッセージを無効にする

start-cal コマンドは、csstored プロセスが設定されていない場合でも、デフォルトで csstored プロセスを起動します。設定されていない csstored プロセスは、 csstored を実行しているすべてのマシンで 24 時間ごとに設定されていないことを伝えるメッセージを出力します。

csstored を未設定の状態で実行しないようにすることによって、メッセージを無効にできます。csstored プロセスの実行を無効にするには、メッセージが生成されるすべてのマシンで、次の ics.conf パラメータを設定します。

自動バックアップ作成のために csstored を設定しているマシンでは、プロセスを無効にしないでください。

データベース問題の処理

ここでは、Calendar Server データベースに関するさまざまな問題について説明します。

Berkeley データベースのツールの検索

多くのトラブルシューティングの手順では、Berkeley データベースのユーティリティプログラムへのアクセス権が必要です。これらのユーティリティプログラムは、Calendar Server バンドルで入手できますが、これらのプログラムはサポートされていません。詳細については、直接 Sleepycat Software (www.sleepycat.com) から入手できます。

「Berkeley データベースユーティリティにアクセスするには」

「使用可能なツールの一覧」

Berkeley データベースユーティリティにアクセスするには

LD_LIBRARY_PATH 環境変数を設定してエクスポートし、次のディレクトリに反映させます。

使用可能なツールの一覧

表 22-3 は、よく使用される Berkeley データベースのツール (ユーティリティプログラム) の一覧を示しています。

表 22-3 Berkeley データベースのユーティリティ
Berkeley データベースのツール	説明
db_archive	使用されなくなったログファイルのパス名を、標準出力に 1 行に 1 つずつ書き込みます。
db_checkpoint	データベースログを監視し、定期的にチェックポイントルーチンを呼び出して、チェックポイントを指定するデーモンプロセスです。
db_deadlock	データベース環境のロック領域をトラバースして、デッドロックまたはタイムアウトになっているロック要求を検出するたびに、ロック要求を中止します。
db_dump	指定したファイルを db_load ユーティリティが理解するフラットテキスト形式で標準出力に書き込みます。
db_load	標準出力から読み込み、指定したデータベースファイルにロードします。ファイルが存在しない場合は、ファイルを作成します。
db_printlog	人間が読める形式でログファイルをダンプするデバッグユーティリティです。
db_recover	予期しないアプリケーション、データベース、またはシステムの障害が発生した後、データベースを整合性のある状態に復元します。
db_stat	データベース環境の統計情報を表示します。
db_verify	1 つ以上のファイルおよびファイル内に含まれるデータベースの構造を検証します。

データベースデッドロックの検出と解決

Berkeley データベースがデッドロック状態にある場合は、データベースをリセットする必要があります。できるだけ早期にこの状態を検出することが重要です。

システムが定期的にデータベースをチェックして、デッドロック状態を検出し、管理者に通知するようにするには、次のように実行します。

設定を変更する権限を持つ管理者としてログインします。

/etc/opt/SUNWics5/cal/config ディレクトリに移動します。

古い ics.conf ファイルをコピーして名前を変更し、保存します。

必要に応じて、ics.conf ファイルを編集して次の値を設定します。

local.caldb.deadlock.autodetect="yes"



注	このパラメータが "yes" に設定されている場合は、ロック領域を監視する db_deadlock デーモンが起動されます。

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

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

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

「ログファイルの監視」

「csmonitor の使用」

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

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

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

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

アプリケーションレベル: 1 つ以上のデータベースファイルのエントリに問題があると、それらを基にしている場合、サーバーが稼動しなくなります。

データベースレベル: Berkeley データベースのページが破損すると、さまざまな問題が発生します。一般的な症状は、csdb check を実行するとループすることです。もう一つの一般的な症状は、次のようなエラーメッセージが表示されることです。"illegal page type or format"、または "page 97895 doesn't exist, create flag not set."

ログファイルの監視

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

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

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

csmonitor の使用


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

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

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

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

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

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

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 2>&1

dbdir を指定しない場合、現在のディレクトリに格納されているデータベースに対して check が実行されます。

check コマンドは大量の情報を生成する可能性があるので、この例で示すように stdout や stderr を含むすべての出力をファイルとして書き出すことをお勧めします。

check の実行が完了したら、出力ファイルを確認します。データベースが破損していた場合は、rebuild コマンドを実行します。「破損したカレンダーデータベースの再構築」を参照してください。

データベース破損時のサービス停止の防止 (読み取り専用モード)

ここでは、リカバリモードの間も破損したデータベースにアクセスできる方法について説明します。ここで説明する内容は次のとおりです。

「読み取り専用モードの使用」

「データベースを読み取り専用モードにするには」

読み取り専用モードの使用

データベースの破損が見つかった場合、サービスの停止を防ぐ 1 つの方法は、データベースを読み取り専用モードにすることです。このモードでは、エンドユーザーはデータベースのエントリを読むことはできますが、追加、変更、または削除はできません。エンドユーザーがカレンダーデータを追加、変更、または削除しようとすると、システムによりエラーメッセージが表示されます。また、カレンダーの予定および仕事を追加、変更、または削除する管理者ツールも、データベースが読み取り専用モードの間は機能しません。

データベースを読み取り専用モードにするには


注	データベースを読み取ることができないほど破損している場合は、バックアップを復元するまでの間、サービスを停止する必要があります。バックアップを復元する最短の方法は、有効なホットバックアップを取ることです。「ホットバックアップを復元するには」を参照してください。

必要がなくても、カレンダーサービスを一時的に停止して、データベースがさらに破損するのを防ぐこともあります。カレンダーダービスを停止するには、次のようにように実行します。

cal_svr_base/SUNWics5/cal/sbin/stop-cal

コマンド行で、ics.conf が格納されているディレクトリに移動します。

cd /etc/opt/SUNWics5/config

カレンダーデータベースに対して読み取り専用モードを指定します。

caldb.berkeleydb.readonly="yes"

ics.conf ファイルの編集が終わったら、Calendar Server を再起動します。

cal_svr_base/SUNWics5/cal/sbin/start-cal

ics.conf の変更を適用するために、サービスを再起動する必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次の手順を実行します。

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

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

- 次の場所にある db_checkpoint ユーティリティを使用します。
cal_svr_base/SUNWics5/cal/tools/unsupported/bin/db_checkpoint

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

db_archive -l を実行して、すべてのログファイルを識別し、適用されていないファイルをリムーバブルメディアデバイスにコピーします。

サービスの停止を避けるには、次の手順を実行します。

カレンダーデータベースを一時的に読み取り専用状態にします。

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

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

caldb.berkeleydb.readonly="yes"

ホットバックアップのコピーに戻ります。

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

ホットバックアップコピーの復元方法については、「ホットバックアップを復元するには」を参照してください。

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

この手順については、「ダンプとロードによるカレンダーデータベースの復元」を参照してください。

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

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

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

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

cd cal_svr_base/SUNWics5/cal/sbin

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

./start-cal

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

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

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

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

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

推奨されるプロセスについては、「ホットバックアップを復元するには」を参照してください。

ダンプと再ロードの手順を使用します (「ダンプとロードによるカレンダーデータベースの復元」)。

破損したカレンダーデータベースの再構築

ここでは、csdb rebuild コマンドの使用方法について説明します。ここで説明する内容は次のとおりです。

「rebuild の概要」

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

「再構築出力のサンプル」

rebuild の概要

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

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

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

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

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

Calendar Server を停止します。

カレンダーデータベースのコピーを作成し、/tmp/db のディレクトリに置きます。データベース (.db) ファイルとログ (log.*) ファイルをコピーします。共有ファイル (__db.*) をコピーする必要はありません。

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/SUNWics5/cal/sbin/rebuild_db ディレクトリに書き込みます。

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

Calendar database has been rebuilt

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

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

Calendar Server を再起動します。

再構築出力のサンプル

次の例は、コマンドと、そのコマンドにより生成された出力を示しています

# ./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

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


注	上記の出力サンプルでは、予定と仕事のデータベースがそれぞれ 2 回走査されたことを示しています。これはエラーではありません。最初の走査では calprops データベースの情報を確認し、次に再走査して calprops が確実にデータベースからアクセスできることを確認します。

「ダンプとロードの概要」

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

ダンプとロードの概要

ダンプとロードの手順を使用して破損したデータベースの復元を試みます。ダンプとロードの手順では、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) としてログインします。

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

csbackup ユーティリティや Sun StorEdge Enterprise Backup^TM ソフトウェア、Legato Networker^TM などを使用して、破損しているデータベースのバックアップを作成します。詳細については、第 17 章「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 オプションを実行しても破損しているデータベースを復元できない場合は、ご購入先のテクニカルサポートまたは販売代理店までご連絡ください。それまでの間は、データベースの最終バックアップを使用する必要があります。

自動バックアップコピーの復元

第 10 章「自動バックアップ (csstored) の設定」で説明されている自動バックアップ機能を使用している場合、ライブデータベースが破損した場合、バックアップコピーを復元できます。

ここでは、2 つの異なる自動バックアップの復元方法について説明します。

「復元する前に」

「ホットバックアップを復元するには」

「アーカイブバックアップを復元するには」

復元する前に

バックアップを復元する前に、必ず次の操作を行っていることを確認してください。

どのトランザクションがライブデータベースの破損の原因になったか診断を試みていること。

新規のアーカイブが破損されないように、破損しているトランザクションを削除または修正していること。

破損したデータベースを、別のディレクトリまたはリムーバブルメディアにコピーして保存していること。このコピーは、テクニカルサポートに問い合わせを行う際に必要になります。

ホットバックアップを復元するには

ライブデータベースが破損した場合、ホットバックアップがバックアップの最初の選択肢となります。バックアップを復元するには、次の手順を実行します。

破損したライブデータベースのディレクトリで、適用されていない、または書き込み可能な状態のログファイルを識別します。

書き込み可能なログを閉じます。このログには、最新のトランザクションが含まれています。

新規の (復元) ディレクトリを作成します。

現在のホットバックアップのコピーを、新規の復元データベースのディレクトリにコピーします。

log.* ファイルを破損したライブデータベースのディレィトリから、新規の復元データベースのディレクトリにコピーします。

データベースのアーカイブコピーを保持している場合は、ライブデータベースに適用されなかったログをアーカイブディレクトリにコピーします。そうすることにより、アーカイブバックアップのコピーが完了します。

新規の復元データベースに対して指定された -c -h オプションを指定して、db_recover を実行します。

たとえば、新規の復元ディレクトリの名前が recoverydb の場合は、コマンドは次のようになります。

db_recover -c -h recoverydb

log.* ファイルは新規のディレクトリに残しておきます。

db_recover プログラムではログファイルを新規の復元データベースに適用しましたが、バージョン 42 以降、Berkeley DB では、ログファイルをそのまま残しておくようお勧めします。

新規の復元ディレクトリ内のデータベースファイルに対して、db_verify を実行します。

詳細は、「カレンダーデータベースの破損のチェック」を参照してください。

新規の復元ディレクトリに対して、csdb -v list を実行します。

新規の復元ディレクトリで上記の 3 つの手順を実行したら、古い破損したライブデータベースを新規の復元ディレクトリと置き換えます。

新しいスナップショットとして機能させるには、新規のライブデータベースをホットバックアップのディレクトリにコピーします。次の定期的なスナップショットが取得されるまで、すべての新しいログがこのコピーに適用されます。

Calendar Server を起動します。

新規の復元ディレクトリでいずれかの手順に失敗した場合は、次のようにして破損していない古いホットバックアップを特定します。

ホットバックアップを新しい順から逆に調べて、各ファイルで順に db_verify および csdb -v list を実行して、破損していない最新のコピーを見つけます。

パスする最初のホットバックアップコピーが、ライブデータベースのディレクトリに復元されます。破損したライブデータベースを新規のホットバックアップと置き換えます。

次に、手順 12 と手順 13 を実行します。

ホットバックアップがどれも動作せず、アーカイブバックアップがない場合は、テクニカルサポートに問い合わせてください。アーカイブバックアップがある場合は、次の手順を実行します。「アーカイブバックアップを復元するには」を参照してください。

アーカイブバックアップを復元するには

破損したホットバックアップはないが、アーカイブバックアップとトランザクションログがある場合は、次の手順を実行して、アーカイブしたデータベースの最新の破損していないデータベースを復元できます。

破損したライブデータベースのディレクトリで、適用されていない、または書き込み可能な状態のログファイルを識別します。

書き込み可能なログを閉じます。このログには、最新のトランザクションが含まれています。

新規の (復元) ディレクトリを作成します。

最新のアーカイブコピーとそのログファイルを、新規の復元データベースのディレクトリにコピーします。

適用されていない log.* ファイルを破損したライブデータベースのディレクトリから、新規の復元データベースのディレクトリにコピーします。

新規の復元データベースに対して指定された -c -h オプションを指定して、db_recover を実行します。

たとえば、新規の復元ディレクトリの名前が recoverydb の場合は、コマンドは次のようになります。

db_recover -c -h recoverydb

log.* ファイルは新規のディレクトリに残しておきます。

db_recover プログラムではログファイルを新規の復元データベースに適用しましたが、バージョン 4.2 以降、Berkeley DB では、ログファイルをそのまま残しておくようお勧めします。

新規の復元ディレクトリ内のデータベースファイルに対して、db_verify を実行します。

詳細は、「カレンダーデータベースの破損のチェック」を参照してください。

新規の復元ディレクトリに対して、csdb -v list を実行します。

新規の復元ディレクトリで上記の 3 つの手順を実行したら、古い破損したライブデータベースを新規の復元ディレクトリと置き換えます。

新しいスナップショットとして機能させるには、新規のライブデータベースをホットバックアップのディレクトリにコピーします。

Calendar Server を起動します。

新規の復元ディレクトリがいずれかの手順に失敗した場合は、次のようにして破損していない古いアーカイブバックアップを特定します。

アーカイブバックアップのコピーを新しい順から逆に調べて、順に各ファイルに対して次の 3 つのリカバリプログラムを実行して、破損していない最新のコピーを見つけます。
db_recover -c-h、db_verify および csdb -v list。

次に、手順 12 と手順 13 を実行します。

カスタムのバックアップスクリプトの修復

「現在、動的ライブラリでコンパイルされている Berkeley ツール」

「カスタムのバックアップスクリプトを修復するには」

現在、動的ライブラリでコンパイルされている Berkeley ツール

Berkeley データベースのツール (db_recover など) を使用してカスタムスクリプトを作成した場合、Calendar Server 2004Q2 以降にアップグレードすると、機能しない可能性があります。これは、Calendar Server の以前のバージョンでは、ツールを静的ライブラリでコンパイルしていたためです。現在では、ツールは動的ライブラリの libdb-4.2.so でコンパイルされています。

カスタムのバックアップスクリプトを修復するには

既存のカスタムスクリプトで新しい動的ライブラリを使用するには、次に示す大域変数を設定します。

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