test

Sun Java System Application Server Enterprise Edition 8.2 トラブルシューティングガイド

第 3 章 HADB の問題

ここでは、Application Server 8.2 Enterprise Edition 製品で、高可用性データベース (HADB) モジュール、HADB 管理クライアント、またはロードバランサプラグインを利用する際に発生する可能性のある問題について説明します。これらのコンポーネントは、Application Server の残りの部分と別にインストールすることも、ともにインストールすることもできます。

この章では、次の項目を説明します。

HADB データベースの作成が失敗する

ここでは、次のようにデータベースの作成が失敗する場合に考えられる理由について説明します。

failed to start database : HADB Database creation failed

問題の原因を識別するには、ログビューアを使用するか、install_dir/hadb/4/log ディレクトリを調べるか、またはその両方を行います。発生する可能性がある主なエラーは、次のとおりです。

共有メモリーに関連する問題

説明

この問題は、次のいずれかの理由で発生する可能性があります。

原因 1

共有メモリーが設定されていないか、その設定が機能していない。

解決法 1

『 Sun Java System Application Server 8.2 Installation Guide』で説明されている手順に従います。共有メモリーの設定後、システムをリブートしてください。

原因 2

物理メモリーの容量がノードの要件を満たしていない。次のエラーメッセージが表示される場合があります。

HADB-S-05512: Attaching shared memory segment with key <xx\> failed, 
OS status=12 OS message: Not enough space.

解決法 2

前述のように、共有メモリーが設定されており、その設定が機能していることを確認します。

本稼働システムでは、ホスト上のノード数を減らすか、ホスト上の物理メモリーを増設します。

テストおよび開発システムでは、LogBufferSize および DataBufferPoolSize を設定して共有メモリー使用量を減らし、それぞれデフォルト値の 48 および 200MB よりも小さい値にします。これらの変数に設定可能な最小値は、それぞれ 32 および 64MB です。

原因 3

共有メモリーセグメントのサイズが、許容される最大サイズを超えている。

HADB-S-05510: Getting shared memory segment with key <xx\> failed, 
OS status=22. OS message: Invalid argument.

解決法 3

前述のように、共有メモリーが設定されており、その設定が機能していることを確認します。

共有メモリーが正しく設定されている場合は、いずれかの共有メモリーセグメントサイズ (LogBufferSize または DataBufferPoolSize) を、オペレーティングシステムの設定ファイルで設定されているシステム設定済みの最大値 (Solaris では /etc/system の shmsys:shminfo_shmmax) より大きく設定していないかどうかチェックします。

原因 4

指定した識別子で共有メモリーセグメントがすでに作成されている。

HADB-S-05515: Shared memory segment with key <segment_key\> exists already.

解決法 4

共有メモリーセグメントの一覧を表示してチェックします。UNIX では、ipcs を使用してセグメントのリストを表示できます。Windows では、メモリーがマップされたファイルを使用して共有メモリーを実現しています。HADB では、getTempPath システムコールを使用して、f_segmentid という名前を持つこれらのファイルが格納されているシステム定義の一時ディレクトリを取得します。

稼働中の別のデータベースやその他のプログラムが、この識別子の共有メモリーセグメントをすでに使用していないかどうかチェックします。使用している場合は、別のポートベースでデータベースを作成します。このセグメントを使用している稼働中のデータベースやその他のプログラムがない場合は、hadbm delete unused_database でセグメントを解放します。

セグメントが解放されているかどうかチェックします。セグメントがまだある場合は、それらを削除します (UNIX では ipcrm を使用、Windows では $TMP/f_* を削除)。ファイル名は、f_ プレフィックスのあとに、16 進に変換された segment_key が続く形式になっています。たとえば、エラーメッセージにセグメントキー 15201 がまだ残っていると表示された場合、その一時ファイルの名前は f_3B61 になります。

セマフォーが少なすぎる

説明

HADB-E-05521: Operation on semaphore with key "46025" failed, OS status=28 :
No space left on device

このエラーは、セマフォーの数が少なすぎる場合に発生することがあります。セマフォーはオペレーティングシステムからグローバルリソースとして提供されるため、その設定は、HADB だけでなくホスト上で実行されるすべてのプロセスに依存しています。このエラーは、HADB の起動中または実行中に発生する可能性があります。

解決法

/etc/system ファイルを編集して、セマフォーの設定を変更します。手順とガイドラインについては、『 Sun Java System Application Server Installation Guide』の「Preparing for HADB Setup」の章にある「Configuring Shared Memory and Semaphores」のセクションを参照してください。

データベースノードにアクセスできないため、データベースが機能しない

解決法

関係するホストの IP アドレスを固定してください。HADB では、データベース作成時に存在した固定 IP アドレスを使用するため、本稼働システムで動的 IP アドレス (DHCP) は使用できません。

管理エージェントでドメインを確立できなかった

説明

HADB 管理システムは、マルチキャストアドレス 228.8.8.8 上の UDP マルチキャストメッセージに依存しています。これらのメッセージを伝達できない場合、createdomain コマンドが失敗して次のメッセージが表示されます。

The management agents could not establish a domain, please check that the
hosts can communicate with UDP multicast.

考えられる原因は次のとおりです。

解決法 1

ホスト上に、異なるサブネットに接続する複数のネットワークインタフェースがある場合は、それらのサブネットの 1 つを使用するように管理エージェントを設定する必要があります。ma.server.mainternal.interfaces 属性を設定します。

解決法 2

マルチキャストメッセージのサポートに必要なネットワークインフラストラクチャーを構成します。

hadbm create または hadbm addnodes コマンドがハングする

説明

hadbm create または addnodes に指定したホストリストの一部のホストに複数のネットワークインタフェースがあり、ほかのホストにはネットワークインタフェースが 1 つしかない場合、hadbm create/addnodes コマンドがハングします。

解決法

ネットワークインタフェースを複数備えるホストでは、hadbm create/addnodes の実行時に hadb で使用するネットワークインタフェースの IP アドレスをドット区切りで指定します (たとえば、129.241.111.23)。IP アドレスの代わりにホスト名を使用すると、ホストに登録された最初のインタフェースが使用されるため、ノードが通信可能状態になる保証はありません。

ma (管理エージェントプロセス) に障害が発生する

説明

ma (管理エージェントプロセス) には、さまざまな理由で障害が発生します。

解決法

hadbm listdomain を使用して診断情報を表示します。一般に、対処法は障害の発生したエージェントを再起動することです。それで解決しない場合は、すべてのエージェントを順番に再起動します。

サーバーが応答する前に長いアイドル状態が発生する

説明

長いアイドル状態のあとでサーバーが要求を処理するため応答に長い時間がかかり、サーバーログに次のような「接続が失われた」というメッセージが表示されます。

java.io.IOException:..HA Store: Lost connection to the server.

そのような状況では、サーバーで HADB 用の JDBC プールを再作成する必要があります。

解決法

タイムアウト値を変更します。デフォルトの HADB 接続タイムアウト値は 1800 秒です。この期間中にアプリケーションサーバーから JDBC 接続を介して要求が 1 つも送信されないと、HADB によって接続が閉じられるため、アプリケーションサーバーで接続を再確立する必要が生じます。タイムアウト値を変更するには、hadbm set SessionTimeout= コマンドを使用します。

注 –

HADB 接続タイムアウトが JDBC 接続プールタイムアウトよりも必ず大きくなるようにしてください。JDBC 接続タイムアウトが HADB 接続タイムアウトよりも大きいと、接続が HADB 側から閉じられ、アプリケーションサーバーの接続プールに残ることになります。その後、アプリケーションでその接続を使用しようとすると、アプリケーションサーバーで接続を再作成する必要が生じ、重大なオーバーヘッドを招きます。

要求が成功しない

ここでは、次の問題について説明しています。

ロードバランサのタイムアウトは適切か ?

説明

loadbalancer.xml ファイルの response-timeout-in-seconds プロパティーを設定する場合は、実行中のすべてのアプリケーションの最大タイムアウトを考慮に入れる必要があります。この応答タイムアウトを非常に小さい値に設定すると、Application Server が要求に応答する前にロードバランサがタイムアウトするため、実行中の多数の要求が失敗します。

逆に、この応答タイムアウトを異常に大きい値に設定すると、応答を中止したインスタンスのキューに要求が格納されるため、多数の要求が失敗することになります。

解決法

response-timeout-in-seconds の値をすべてのアプリケーションのうちで最長の応答時間に設定します。

システムクロックは同期しているか ?

説明

セッションが HADB に格納される際には、そのセッションの最終アクセス時刻、最終変更時刻などの時刻情報も保存されます。クロックが同期していないと、インスタンスに障害が発生し別のマシン上の別のインスタンスがテイクオーバーする場合に、後者のインスタンスで、セッションの有効期限が切れていないのに切れていると判断されたり、さらに悪いことにセッションの最終アクセス時刻が将来の時刻になったりすることがあります。

注 –

非共存構成では、HADB ノードをホスティングしているそれらのマシン上のクロックを同期させることは重要です。詳しくは、『Installation Guide』の「Preparing for HADB Setup」の章を参照してください。

解決法

クラスタ内のすべてのシステムでクロックが同期していることを確認します。

Application Server は HADB と通信しているか ?

説明

HADB が作成され稼働していても、持続性ストアが未作成の場合は、Application Server は HADB と通信できません。このような状況では、次のメッセージが表示されます。

WARNING (7715): ConnectionUtilgetConnectionsFromPool failed using
connection URL: connection URL

解決法

次のようなコマンドを使用して、HADB 内にセッションストアを作成します。

asadmin create-session-store --storeurl connection URL --storeuser haadmin 
--storepassword hapasswd --dbsystempassword super123

セッション持続の問題

ここでは、次の問題について説明しています。

create-session-store コマンドが失敗した

説明

asadmin create-session-store コマンドは、ファイアウォールを越えて実行できません。したがって、create-session-store コマンドが機能するには、アプリケーションサーバーインスタンスと HADB がファイアウォールの同じ側に存在する必要があります。

create-session-store コマンドは HADB と通信しますが、アプリケーションサーバーインスタンスとは通信しません。

解決法

HADB とアプリケーションサーバーインスタンスをファイアウォールの同じ側に配置します。

インスタンスレベルのセッション持続設定が機能しなかった

アプリケーションレベルのセッション持続設定は、インスタンスレベルのセッション持続設定より常に優先されます。アプリケーションを配備したあとにインスタンスレベルのセッション持続設定を変更した場合でも、アプリケーションの設定値がアプリケーションサーバーインスタンスの設定値より優先されます。

セッションデータが壊れている可能性がある

説明

次のような状況でシステムログからエラーが報告される場合、セッションデータが壊れている可能性があります。

解決法 1

asadmin clear-session-store コマンドを使用して、セッションストアをクリアーします。

解決法 2

セッションストアのクリアーで解決しない場合は、すべてのノード上のデータ領域を再初期化し、hadbm clear コマンドを使用して HADB 内のデータをクリアーします。

解決法 3

HADB のクリアーで解決しない場合は、データベースを削除して再作成します。

前記の解決法 2 と 3 では、HADB のクリアー後、セッションストアを再作成してデータベーススキーマを再確立します。

HADB のパフォーマンスの問題

HADB へのトランザクションが遅延したり異常終了したりすると、パフォーマンスが影響を受けます。一般にこうした状況は、システムリソースの不足が原因です。待機時間が 5 秒を超えると、トランザクションの異常終了を引き起こします。ノードの障害も、クラッシュ時にそのノード上のアクティブトランザクションが異常終了する原因となります。二重障害 (両方のミラーの障害) が発生すると、HADB が使用不能になります。障害の原因は、通常、HADB の履歴ファイルに記録されています。

問題を特定するには、次の点を考慮します。

CPU またはメモリーのリソースが不足していないか、あるいはスワッピングが多すぎないか ?

説明

「Process blocked for x sec, max block time is 2.500000 sec 」というエラーが原因で、ノードの再起動または二重障害が発生します。この場合、x はプロセスがブロックされた時間の長さで、それが 2.5 秒を超えました。

HADB ノードスーパーバイザプロセス (NSUP/clu_nsup_srv) では、前回、プロセスで何らかの監視操作を実行した時刻からの経過時間を追跡しています。その時間が指定された最大値 (デフォルトでは 2500ms) を超えると、NSUP は、ブロックされた時間が長すぎると判断しノードを再起動します。

NSUP が 2.5 秒より長くブロックされると、ノードの再起動が引き起こされます。ミラーノードが同じホスト上に配置されていると、二重障害の恐れが高まります。ミラーホスト上でブロッキングが同時に発生するときも、二重障害になる可能性があります。

こうした状況が発生する恐れが特に高いのは、共存構成の場合のように、システム内に CPU やメモリーの使用で競合するほかのプロセスが存在する場合です。プロセスが再スケジュールされるたびに、大規模なスワッピングや複数のページフォルトが発生するからです。

システムクロックの負の調整も NSUP がブロックされる原因になります。

解決法

HADB ノードに十分なシステムリソースが割り当てられるようにします。また、時刻同期デーモンで 2 秒を超える大幅な調整が行われないようにします。

ディスクの競合はないか ?

説明

ディスクの競合は、ディスク装置に対するユーザーデータの読み取り/書き込み、および HADB から履歴ファイルへの書き込みに悪影響を与えることがあります。重度のディスク競合は、ユーザートランザクションの遅延や異常終了の原因となります。履歴ファイルへの書き込みが遅延すると、ノードの再起動が発生することがあり、最悪の場合、二重障害になります。

ディスクの競合は、データ、ログデバイス、および履歴ファイル用に使用しているディスクのディスク入出力を OS から監視することで識別できます。履歴ファイルへの書き込み遅延は、HADB 履歴ファイルに記録されます。「NSUP BEWARE timestamp Last flush took too long (x msecs).」というメッセージが遅延を表しています。

この警告は、ディスク入出力に要した時間が異常に長いという意味です。遅延が 10 秒を超えると、ノードスーパーバイザによって trans プロセスが再起動され、次のようなエラーメッセージが表示されます。

Child process trans0 10938 does not respond.
Child died - restarting nsup.
Psup::stop: stopping all processes.

このメッセージは、trans (clu_trans_srv ) プロセスが、ほかの動作 (たとえば、履歴ファイルへの書き込みの待機中) のためにビジー状態になったままで、trans プロセスのハートビートをチェックするノードスーパーバイザの要求に応答できないことを示しています。このため、nsup で trans が終了していると判断され、プロセスが再起動されます。

プロセスが多すぎる (多くの HADB ノードはほかのプロセスと共存している) ためにオペレーティングシステムがオーバーロード状態になると、入出力動作のスケジューリングに遅延が生じることがあります。HADB 関連の入出力処理が遅延すると、HADB ノードから履歴ファイルに「HADB warning: Schedule of async <read,write\> operation took ...」というメッセージが書き込まれます。

この問題は特に、Red Hat AS 2.1 で複数の HADB ノードが同じホスト上に配置され、すべてのノードでデバイスの配置に同じディスクを使用する場合に生じることが報告されています。

解決法

ノードで使用するデバイスの配置には、ノードごとに 1 つのディスクを使用します。ノードに複数のデータデバイスがあってディスクの競合が生じている場合は、1 つのデータデバイスを別のディスクに移動します。履歴ファイルにも同じ方法を適用できます。

すべてのデータおよびログデバイス、またすべての履歴ファイルが、NFS マウントディスクやほかのリモートマウントディスクではなく、ローカルディスク上に存在することを確認してください。

監視ツールで HADB ディスクの競合がなくならない場合は、データバッファープールサイズを大きくすることができます。

HADB データデバイス空間が不足していないか ?

説明

トランザクションが失敗する 1 つの理由として、データデバイス空間の不足も考えられます。このような状況が生じると、HADB から履歴ファイルに警告が書き込まれ、データを挿入したり更新したりするトランザクションが異常終了します。

通常、次のようなメッセージが表示されます。

HIGH LOAD: about to run out of device space, ...
HIGH LOAD: about to run out of device space on mirror node, ...

一般には、データデバイスにはユーザーデータの 4 倍以上の空き容量が必要とされています。詳しくは、『パフォーマンスチューニングガイド』を参照してください。

解決法 1

次のコマンドを使用して、データデバイスのサイズを大きくします。

hadbm set DeviceSize=size

この解決法は、すべてのノードで HADB データデバイス用に使用されている物理ディスクに空き容量がある場合にのみ適用できます。

HADBM により、データベースの各ノードが自動的に再起動されます。

解決法 2

HADB を停止して削除し、ノード数を増やしたり、データデバイスのサイズを大きくしたり、ノードごとに複数のデータデバイスを配置したりした、新しいインスタンスを作成します。ただし、この解決法では、Application Server で作成したすべての持続データおよびスキーマが消去されます。この手順の詳細については、『管理ガイド』を参照してください。

ほかの HADB リソースが不足していないか ?

HADB ノードの起動時に、次の割り当てが行われます。

HADB ノードでリソースの不足が発生すると、トランザクションが遅延したり異常終了したりします。ミラーノード間でリソース使用量情報がやり取りされるので、ミラーノード上で失敗する可能性が高い操作を、ノード側で遅延させたり中止したりできます。

トランザクションが繰り返し遅延すると、タイムアウトになってクライアントにエラーメッセージが返される場合があります。タイムアウトしない場合、クライアント側でわかるのは、システムでリソースが不足している時間帯にはパフォーマンスが低下するという現象のみです。

これらの問題は、「高負荷」の状況で頻繁に発生します。詳しくは、「高負荷の問題」を参照してください。

高負荷の問題

次のような症状が出るシナリオは、高負荷であると判断できます。

高負荷の問題が疑われる場合は、次の点を考慮してください。

注 –

多くの場合、これらの問題すべては、より多くの CPU パワーを利用できるようにすることで解決できます。

タプルログの容量が不足していないか ?

すべてのユーザー操作 (delete、insert、update) はタプルログに記録されて、実行されます。タプルログは、次の理由でいっぱいになる可能性があります。

解決法 1

「CPU 利用率の向上」の説明に従って、CPU の使用量をチェックします。

解決法 2

CPU の利用状況に問題がなければ、ディスク入出力をチェックします。ディスク競合の兆候がある場合は、hadbm set DataBufferPoolSize=... でデータバッファーサイズを大きくして、ログレコード処理中のページフォルトを回避します。ディスク競合が発生する場合は、「ディスクの競合はないか ?」で説明している解決法に従います。

解決法 3

ネットワーク競合の兆候がないかどうかチェックし、ボトルネックを解決します。

解決法 4

hadbm set LogBufferSize=... を使用して、タプルログバッファーを大きくします。

node-internal ログがいっぱいになっていないか ?

CPU またはディスク入出力に問題があると、スケジュールされても処理されない node-internal 操作が異常に増加します。

node-internal ログの容量がなくなると、履歴ファイルに node-internal ログの HIGH LOAD を示すメッセージが出力されます。

解決法 1

「CPU 利用率の向上」の説明に従って、CPU の使用量をチェックします。

解決法 2

CPU の利用状況に問題がなければ、ディスク入出力をチェックします。ディスク競合の兆候がある場合は、hadbm set DataBufferPoolSize=... でデータバッファーサイズを大きくして、ログレコード処理中のページフォルトを回避します。ディスク競合が発生する場合は、「ディスクの競合はないか ?」で説明している解決法に従います。

ロックの数は十分か ?

この状況を識別するための主な追加の症状は、次のとおりです。

解決法 1: 長いトランザクションを分割する

ノード上で実行されるトランザクションで、そのノードに割り当てられたロックの 25% を超える数のロックを使用することはできません。「repeatable read」遮断レベルで実行される読み取りトランザクション、および更新/挿入/削除トランザクションでは、トランザクションが終了するまでロックが保持されます。したがって、長いトランザクションを小さいトランザクションに分割することをお勧めします。

解決法 2: ロックの数を増やす

hadbm set NumberOfLocks= を使用して、ロックの数を増やします。

パフォーマンスチューニングを行えば問題を解決できるか ?

ほとんどの状況では、負荷を減らすかリソースの可用性を高めることでホストのパフォーマンスを改善できます。次に示す手順はさらに広範囲に適用できます。

これに加え、『パフォーマンスチューニングガイド』の説明に従って次のリソースを調整することにより、「HIGH LOAD」の問題を改善できます。

表 3–1 HADB のパフォーマンスチューニングプロパティー

リソース 

プロパティー 

データベースバッファーのサイズ 

hadbm attribute DataBufferPoolSize

タプルログバッファーのサイズ 

hadbm attribute LogBufferSize

ノード内部ログバッファーのサイズ 

hadbm attribute InternalLogBufferSize

データベースロックの数 

hadbm attribute NumberOfLocks

セマフォーリソースの不足で発生する接続の問題

説明

この問題が発生すると、履歴ファイルに次のようなメッセージが出力されます。

HADB-E-05521: Operation on semaphore with key "46025" failed, 
OS status=28 : No space left on devicewhere:

ホストコンピュータ上にさらに多くのセマフォー unso 構造を設定する必要があります。各オペレーティングシステムに semmnu を設定する方法については、『Sun Java System Application Server 8.2 Installation Guide』の「Preparing for HADB Setup」の章を参照してください。

解決法

影響を受けている HADB ノードを停止して、影響を受けているホストを再設定およびリブートし、HADB ノードを再起動します。HADB は、これらの処理中も使用可能です。

CPU 利用率の向上

説明

パフォーマンスは、使用可能な CPU サイクルおよび入出力容量によって重大な制限を受けることがあります。システムパフォーマンスを最適化するには、HADB を最適に設定することに加えて、そのような問題を解決および防止することが必要です。

解決法

利用されていない余分の CPU がホスト上にあれば、同じホストに新しいノードを追加します。それができない場合、新しいマシンを追加して、それらに新しいノードを追加します。

マシンに十分なメモリーがあれば、DataBufferPoolSize を増やし、ログファイルに警告を出力する可能性のあるほかの内部バッファーのサイズを大きくします。それができない場合、新しいマシンを追加して、それらに新しいノードを追加します。

このセクションについての詳細は、『パフォーマンスチューニングガイド』を参照してください。

HADB 管理の問題

hadbm コマンドとその多数のサブコマンドおよびオプションを使用して、高可用性データベース (HADB) を管理することができます。hadbm コマンドは、install_dir/SUNWhadb/4/bin ディレクトリにあります。

このコマンドの詳細な説明については、『Sun Java System Application Server 管理ガイド』の「Configuring the High Availability Database」の章を参照してください。各 hadbm サブコマンドの詳細については、hadbm のマニュアルページを参照してください。

ここでは、次の問題について説明しています。

hadbm コマンドが失敗する: エージェントにアクセスできなかった

説明

コマンドが次のエラーで失敗します。

The agents <url\> could not be reached.

URL のホストにアクセスできなかった可能性があります。原因は、ホストがダウンしている、通信経路が確立されていない、URL のポート番号が違う、管理エージェントがダウンしている、のいずれかです。

解決法

URL が正しいかどうか確認します。URL が正しい場合は、ホストが稼動しておりすぐに通信できる状態にあることを確認します。次に例を示します。

ping hostname1ping hostname2...

hadbm コマンドが失敗する: コマンドが見つからない

説明

hadbm コマンドはカレントディレクトリから実行できます。検索 PATH を設定してどこからでも hadb コマンドを使用できるようにすれば、一層便利です。「hadbm: Command not found」というエラーは、これらの条件のいずれにも当てはまらなかったことを示します。

解決法 1

hadbm コマンドを含むディレクトリに cd で移動し、そこから実行します。

cd install_dir/SUNWhadb/4/bin/
./hadbm

解決法 2

hadbm コマンドのフルパスを指定して呼び出します。

install_dir/SUNWhadb/4/bin/hadbm

解決法 3

PATH 変数を設定すると、どこからでも hadbm コマンドを使用できます。PATH 変数の設定手順については、『Sun Java System Application Server 8.2 Installation Guide』の「Preparing for HADB Setup」の章を参照してください。

PATH の設定が正しいかどうか確認するには、次のコマンドを実行します。

which asadmin
which hadbm

ユーティリティーに返されるパスを確認してください。

hadbm コマンドが失敗する: JAVA_HOME が定義されていない

説明

「hadbm: <path\>: Invalid Java home location」というメッセージは、JAVA_HOME 環境変数が適切に設定されていないことを示します。

解決法

システムに複数のバージョンの Java がインストールされている場合は、JAVA_HOME 環境変数に正しいバージョンの Java (Enterprise Edition では 1.4.1_03 以上) が設定されているかどうか確認します。

PATH 変数の設定手順については、『Sun Java System Application Server 8.2 Installation Guide』の「Preparing for HADB Setup」の章を参照してください。

hadbm createdomain が失敗し、2 つに分割されたドメインが作成される

説明

ネットワークインタフェースが複数あるホスト上で HADB 管理エージェントを実行する場合、それらのネットワークインタフェースがすべて同一サブネット上にないと、createdomain コマンドが次のように失敗することがあります。

hadbm:Error 22020: The management agents could not establish a domain, 
please check that the hosts can communicate with UDP multicast.

管理エージェントのデフォルトでは、UDP マルチキャスト用に「最初の」(java.net.NetworkInterface.getNetworkInterfaces() で返される「最初の」) インタフェースが使用されます。

解決法

最善の解決法は、設定ファイルで ma.server.mainternal.interfaces を設定して、使用するサブネットを管理エージェントに通知することです。次に例を示します。

ma.server.mainternal.interfaces=10.11.100.0

サブネット間のルーターで、マルチキャストパケットを経路指定するように設定する方法もあります。デフォルトでは、管理エージェントで使用するマルチキャストアドレスは、228.8.8.8 です。

create が失敗する: ホスト上にパスがない

説明

hadbm create コマンドの実行後、コンソールに次のようなエラーが表示されます。

./hadbm create ...
...
hadbm: Error 22022: Path path does not exist on host host

このエラーメッセージは、マシン上に存在しないパスを指定して新しいノードを追加した場合にも表示されることがあります。

解決法

ホストにログインし、HADB デバイスおよび HADB 履歴ファイルのパスを作成します。hadbm create を実行し、作成したパスを --devicepath および --historypath オプションで指定します。ホスト上で管理エージェントを実行するユーザーに、これらのディレクトリに対する読み取りおよび書き込みアクセス権があることも確認してください。

注 –

HADB の実行可能ファイルを複数の異なるホスト上の異なるパスにインストールすることはできません。

データベースが起動しない

create または start コマンドが失敗し、次のコンソールエラーメッセージが表示されます。

hadbm: Error 22095: Database could not be started...

次の点を考慮してください。

共有メモリーのセグメント取得エラーがなかったか ?

説明

ノードの停止後に、そのノードに割り当てられたリソース (共有メモリー、ディスク領域) がほかのプロセスに占有されていると、起動が失敗することがあります。

解決法

この問題を解決する方法については、「共有メモリーに関連する問題」を参照してください。

履歴ファイルにエラーが記録されていないか ?

説明

問題がなくならない場合は、HADB 履歴ファイルを調べます。見つかる可能性が高い主なエラーメッセージは、次のとおりです。

解決法

前述の項目のいずれにも問題が発生していないことを確認したら、次の救済策を順番に試してください。

詳しくは、『Error Message Reference』を参照してください。

clear コマンドが失敗した

clear コマンドでは、ディスク上に存在するデータベースデバイスファイルを再初期化します。このコマンドは、ディスクまたはディスクアクセスの問題が原因で失敗することがあります。このことを示す hadbm からのエラーメッセージがないかどうかチェックします。もしないなら、ma.log ファイル内を検索して、devinit から出力されたエラーメッセージがないかどうかチェックします。

create-session-store が失敗した

asadmin create-session-store コマンドは、次のいずれかの理由で失敗することがあります。

無効なユーザー名またはパスワード

このエラーは、create-session-store コマンドに指定した --dbsystempassword が、データベース作成時に指定したパスワードと異なる場合に発生します。

解決法 1

正しいパスワードを指定してコマンドを再試行します。

解決法 2

dbsystem パスワードを忘れた場合は、hadbm clear でデータベースをクリアーし、新しい dbsystem システムパスワードを指定する必要があります。

SQLException: No suitable driver

create-session-store から次のエラーが出力されます: SessionStoreException: java.sql.SQLException: No suitable driver。

解決法 1

asadmin で、Application Server config ディレクトリの asenv.conf で定義した AS_HADB パスから hadbjdbc4.jar を見つけられない場合に、このエラーが発生することがあります。

解決法は、HADB のインストール場所を指すように AS_HADB を変更することです。

次に、asenv.conf ファイルから AS_HADB エントリの例を示します。

AS_HADB=/export/home0/hercules/0815/SUNWhadb/4.4.0-8

解決法 2

このエラーは、--storeUrl に間違った値を指定した場合にも発生することがあります。この問題を解決するには、hadbm get jdbcURL を使用して正しい URL を取得します。

hadbm コマンドがハングする

hadbm との間で通信する管理エージェントが、操作が完了する前に停止すると、hadbm プロセスがハングすることがあります。すべてのエージェントが稼働しているかどうかチェックしてください。

HADB を再起動できない

説明

二重ノード障害が起きると、HADB 再起動は機能しません。HADB を再起動するには、付加的な回復アクションが必要です。

二重ノード障害の主な症状は、次のとおりです。

この問題は、停電後などにミラー HADB ホストマシンで障害が発生したりリブートが行われたりした場合、単一マシンインストールで HADB を先に停止することなくマシンがリブートされる場合、または両方のデータ冗長ユニット (DRU) からミラーマシンのペアがリブートされる場合に発生します。

HADB は、このような「二重障害」の状況から自動的に自己回復できません。ペアーノード上に存在したデータの一部が失われるからです。このような場合、hadbm start コマンドは失敗し、hadbm status コマンドにより HADB が作動不能状態であることが示されます。

DRU と HADB の詳細な説明については、『管理ガイド』の「Administering the High Availability Database」、および『配備計画ガイド』を参照してください。

ヒント –

HADB が異常な動作 (たとえば、定常的にタイムアウトする) を示している場合、再起動でその問題が解決するかどうかを調べるには、hadbm restart コマンドを使用します。

この方法で HADB が再起動するなら、HADB のサービスを引き続き利用できます。これとは異なり、HADB の起動と停止を hadbm stop および hadbm start を使用して別個の操作で行う場合は、HADB の停止中は HADB サービスを利用できません。

解決法

ノードの状態が Starting か Recovering を示すことを確認してから、データベースをリセットします。『管理ガイド』の「Administering the High Availability Database」の章にある「Recovering from Session Data Corruption」の手順に従います。

共有メモリーセグメントキーがすでに存在する (Windows のみ)

説明

hadbm プロセスから次のエラーが返されます。

HADB-S-05515: Shared memory segment with key "NNNNN" exists already

制御による停止後に HADB インスタンスを作成する際、以前に作成した、同じポートベースを使用するインスタンスを削除せずに行うと、このエラーが発生することがあります。この問題は、何らかの理由で HADB インスタンスの削除が失敗したことが原因で生じる場合もあります。

解決法

停止中のすべての hadb インスタンスを削除し、HADB リソースを再利用する前にすべての HADB リソースが解放されていることを確かめます。

問題がなくならないなら、$TMP/f_* の HADB ファイルを削除することによって、HADB の共有メモリーセグメントを手動で削除します。

configure-ha-cluster の失敗

説明

いくつかのホスト名から成る HADB ドメインの作成が成功したので、listdomain コマンドでそれを確認します。

$hadbm listdomain -w admin
Hostname Enabled? Running? Release  Interfaces
host1 Yes      Yes      V4-4-1-3 128.139.113.110
host2 Yes      Yes      V4-4-1-3 128.139.113.111

次に、hadbm create コマンドでデータベースを作成し、--hosts オプションのパラメータとして完全ドメイン名を含む妥当なホスト名を指定します。

$ hadbm create --hosts=host1.xyz.abc.com,host2.xyz.abc.com...

このとき、次のエラーが返されます。

hadbm:Error 22176: The host host1.xyz.abc.com is not registered in the
HADB management domain. Use hadbm createdomain to set up the management
domain or hadbm extenddomain to include new hosts in an existing domain.

解決法 1

listdomain で表示される名前を使用します。次に例を示します。

hadbm create --hosts=host1,host2...

解決法 2

10 進の IP アドレス (DDN) を使用します。次に例を示します。

hadbm create --hosts=128.139.113.110,128.139.113.111

configure-ha-cluster を実行できない

説明

2 つの異なる HADB インストールが設定されています。1 つはサーバーホスト上に、もう 1 つは hadbm クライアントホスト上にあり、それぞれ異なるバージョンの HADB を実行しています。管理エージェントが一方の HADB バージョンで起動され、その後、hadbm create が他方のバージョンで実行されます。次のエラーが返されます。

HADBMGMT007:hadbm create command failed.  Return value: 1 STDOUT:
STDERR: hadbm:Error 22170: The software package V4.4.x could not be found at path <pacakgepath\>/4.4-x on
 host <hostname\>.
CLI137 Command configure-ha-cluster failed.

解決法

管理エージェントとすべての hadbm クライアントで、同じバージョンの HADB を使用します。

hadbm set コマンドが失敗する

説明

hadbm set コマンドを実行すると、データベースインスタンスが回復困難な状態に陥ります。

hadbm set コマンドでデータベース設定変数を変更しようとすると失敗します。たとえば、DataBufferPoolSize の大きいサイズへの変更は、node-0 の共有メモリーの不足が原因で失敗します。この hadbm set コマンドにより、データベースに、停止状態の node-0 と稼動状態の node-1 が設定されます。hadbm set を使用してプールサイズを元の値にリセットしようとすると、次のメッセージが表示されて失敗します。

22073: The operation requires restart of node 1. Its mirror node is
currently not available. Use hadbm status --nodes to see the status of
the nodes.

この状況では、hadbm startnode 0 コマンドも使えません。

解決法

データベースを停止し、hadbm set を使用して前の値を復元してから、データベースを再起動します。

configure-ha-cluster の失敗: HADB インスタンスの作成が失敗する

説明

HADB クラスタの作成が、次のメッセージで失敗します。

cresqldict: HADB-E-00208: The transaction was aborted.

これは、SQL 辞書テーブルを生成するブートトランザクションが異常終了したことを示します。

解決法

configure-ha-cluster をもう一度実行します。hadbm create コマンドが前記のメッセージで失敗する場合は、コマンドを再実行します。