次の方法で、HADB のアクティビティーを監視できます。
これらの節では、hadbm status、hadbm deviceinfo、および hadbm resourceinfo コマンドについて簡潔に説明します。HADB 情報の解釈については、『Sun Java System Application Server Enterprise Edition 8.2 パフォーマンスチューニングガイド』の「パフォーマンス」を参照してください。
hadbm status コマンドを使用して、データベースまたはそのノードの状態を表示します。コマンド構文は次のとおりです。
hadbm status [--nodes] [--adminpassword=password | --adminpasswordfile=file] [--agent=maurl] [dbname]
dbname オペランドにはデータベース名を指定します。デフォルトは hadb です。
--nodes オプション (省略形 -n) は、データベース内の各ノードに関する情報を表示します。詳細については、「ノードの状態」を参照してください。その他のコマンドオプションの説明は、「汎用オプション」を参照してください。
詳細については、hadbm-status(1)を参照してください。
次に例を示します。
hadbm status --nodes
データベースの状態には、データベースの現在の状況が要約されます。次の表で、データベースが取りうる状態の種類について説明します。
表 3–14 HADB の状態
データベースの状態 |
説明 |
---|---|
高可用性耐障害 (HAFaultTolerant) |
データベースに耐障害性があり、DRU ごとに少なくとも 1 つのスペアノードを備えている。 |
耐障害 |
すべてのミラーノードペアが実行中である。 |
稼働 |
各ミラーノードペア内の少なくとも 1 つのノードが実行中である。 |
非稼働 |
1 つ以上のミラーノードペアで、両方のノードがなくなっている。 データベースが非稼働状態である場合は、「データベースの解除」で説明されている手順に従って、データベースを解除します。 |
停止 |
データベース内に実行中のノードがない。 |
不明 |
データベースの状態を判定できない。 |
--nodes オプションを使用して、hadbm status コマンドでデータベース内の各ノードに関する次の情報を表示させます。
ノード番号
ノードが実行中であるマシンの名前
ノードのポート番号
ノードのロール。ロールとその意味のリストについては、「ノードのロール」を参照してください。
ノードの状態。状態とその意味のリストについては、「ノードの状態」を参照してください。
対応するミラーノードの番号。
次の節に説明されているように、ノードのロールと状態は変更される場合があります。
ノードには作成時にロールが割り当てられます。次のいずれかのロールを担います。
アクティブ:データを格納し、クライアントアクセスを許可します。アクティブノードはミラー化されたペアになっています。
スペア:クライアントアクセスを許可しますが、データを格納しません。データデバイスを初期化した後に、他のデータノードを監視して、あるノードが使用不能であれば修復を開始します。
オフライン:ロールが変更されるまでサービスを提供しません。ふたたびオンラインになったときに、元のロールに戻される場合があります。
シャットダウン:アクティブとオフラインの中間の段階で、スペアノードによる機能の引き継ぎを待機している状態です。スペアノードによる引き継ぎが完了すると、ノードはオフラインになります。
ノードは次のいずれかの状態になります。
起動中:ノードは起動中です。
待機中:ノードは起動レベルを決定できず、オフラインになっています。ノードがこの状態のまま 2 分を経過した場合は、そのノードを停止し、repair レベルで起動してください。「ノードの停止」、「ノードの起動」、および 「データベースの解除」を参照してください。
実行中:ノードはロールに応じたすべてのサービスを提供しています。
停止中:ノードは停止処理を行なっています。
停止:ノードは停止しています。停止したノードの修復は禁止されています。
回復中:ノードは回復処理を行っています。ノードに障害が発生した場合、ミラーノードがそのノードの機能を引き継ぎます。障害が発生したノードは、メインメモリーまたはディスク内のデータとログレコードを使用して回復を試行します。また、ミラーノードのログレコードを使用して、障害発生時に実行していたトランザクションの回復に努めます。回復に成功した場合には、そのノードがふたたびアクティブになります。回復が失敗した場合は、ノードの状態が「修復中」に変更されます。
修復中:ノードは修復処理を行っています。この操作で、ノードは再初期化され、ミラーノードからデータとログレコードがコピーされます。修復には回復より時間がかかります。
次の目的で、HADB データ (ディスク記憶装置) デバイスの空き領域を監視します。
ディスク容量の使用傾向を定期的にチェックする。
予防保守の一環として。ユーザー側の負荷が増え、データベース設定の大きさの変更やスケールを考慮している場合。
データベースを拡大する操作の一部として。hadbm addnodes を実行して新規ノードをシステムに追加する前に、十分なデバイス空間があるかどうかをチェックします。ノードを追加するには、既存のノード上に 40 〜 50% ほどの空き領域が必要となることを念頭に置いてください。
履歴ファイルや server.log ファイルに次のようなメッセージが表示された場合。
No free blocks on data devices
No unreserved blocks on data devices .
hadbm deviceinfo コマンドを使用して、データデバイス内の空き領域に関する情報を取得します。このコマンドを実行すると、データベースの各ノードについて次の情報が表示されます。
割り当て済みの合計デバイスサイズ (Totalsize)。単位は M バイト。
空き領域 (Freesize)。単位は M バイト。
現在使用されているデバイスの比率 (Usage)
コマンド構文は次のとおりです。
hadbm deviceinfo [--details] [--adminpassword=password | --adminpasswordfile=file] [--agent=maurl] [dbname]
dbname オペランドにはデータベース名を指定します。デフォルトは hadb です。
--details オプションを指定すると、次の追加情報が表示されます。
デバイスが実行した読み取り操作の数。
デバイスが実行した書き込み操作の数。
デバイスの名前。
その他のコマンドオプションの説明は、「汎用オプション」を参照してください。
詳細については、hadbm-deviceinfo(1)を参照してください。
ユーザーデータ用に使用可能な空き容量を算定するには、合計デバイスサイズから HADB 用に予約済みの容量 (LogBufferSize の 4 倍 + デバイスサイズの 1%) を減算します。ログバッファーのサイズがわからない場合は、コマンド hadbm get logbufferSize を使用してください。たとえば、合計デバイスサイズが 128M バイトで LogBufferSize が 24M バイトの場合、ユーザーデータ用に使用可能な容量は 128 – (4 x 24) = 32M バイトです。この 32M バイトのうち、半分はレプリケートデータ用に使用され、約 1 % が索引用に使用されるため、実ユーザーデータに使用できるのは 25 % だけです。
ユーザーデータに使用可能な容量は、合計サイズと予約済みサイズの差です。将来的にデータを再断片化するのであれば、空き容量がユーザーデータに使用可能な領域の 50% にほぼ等しくなるようにする必要があります。再断片化がふさわしくない場合は、データデバイスを最大限度まで活用することができます。システムのデバイス容量が不足すると、リソース消費警告が履歴ファイルに書き込まれます。
HADB の調整に関する詳細については、『Sun Java System Application Server パフォーマンスチューニングガイド』を参照してください。
コマンド
hadbm deviceinfo --details
を実行すると、次の例のような結果が表示されます。
NodeNO Totalsize Freesize Usage NReads NWrites DeviceName 0 128 120 6% 10000 5000 C:\Sun\SUNWhadb\hadb.data.0 1 128 124 3% 10000 5000 C:\Sun\SUNWhadb\hadb.data.1 2 128 126 2% 9500 4500 C:\Sun\SUNWhadb\hadb.data.2 3 128 126 2% 9500 4500 C:\Sun\SUNWhadb\hadb.data.3
hadbm resourceinfo コマンドは、HADB ランタイムリソース情報を表示します。この情報を使用して、リソースの競合を識別し、パフォーマンス上のボトルネックを削減するのに役立てることができます。詳細については、『Sun Java System Application Server Enterprise Edition 8.2 パフォーマンスチューニングガイド』の「HADB のチューニング」を参照してください。
コマンド構文は次のとおりです。
hadbm resourceinfo [--databuf] [--locks] [--logbuf] [--nilogbuf] [--adminpassword=password | --adminpasswordfile=file] [--agent=maurl] [dbname]
dbname オペランドにはデータベース名を指定します。デフォルトは hadb です。
次の表で、hadbm resourceinfo の特別なコマンドオプションについて説明します。その他のコマンドオプションの説明は、「汎用オプション」を参照してください。
詳細については、hadbm-resourceinfo(1)を参照してください。
表 3–15 hadbm resourceinfo コマンドオプション
オプション |
説明 |
---|---|
-d |
データバッファープール情報を表示します。 詳細については、下記 「データバッファープール情報」を参照してください。 |
-l |
ロック情報を表示します。 詳細については、下記 「ロック情報」を参照してください。 |
-b |
ログバッファー情報を表示します。 詳細については、下記 「ログバッファー情報」を参照してください。 |
-n |
ノードの内部ログバッファー情報を表示します。 詳細については、下記 「ノード内部ログバッファー情報」を参照してください。 |
データバッファープール情報には、次の内容が含まれます。
NodeNo: ノード番号。
Avail: プール内の使用可能容量の合計。単位は M バイト。
Free: 使用可能な空き容量。単位は M バイト。
Access: 起動時から現在までにデータベースがデータバッファーにアクセスした累積回数。
Misses: データベース起動時から現在までに発生したページフォルトの累積回数。
Copy-on-Write: チェックポイントのためにデータバッファーに内部的にコピーされたページの累積数。
ユーザートランザクションがレコードに対して操作を実行するときには、そのレコードを含むページはデータバッファープール内になければなりません。そのようになっていないと、miss、つまりページフォルトが発生します。すると、ディスク上のデータデバイスフィルからページが取り出されるまで、トランザクションは待機する必要があります。
ミスの比率が高い場合は、データバッファープールを増やしてください。ミスのカウントは累積回数なので、定期的に hadbm resourceinfo を実行し、二回分のカウントの差を調べて、ミスの比率の傾向を確認します。空き容量が非常に少ないとしても、チェックポイントメカニズムによって新たに使用可能なブロックが作成されるので、心配する必要はありません。
次に例を示します。
NodeNO Avail Free Access Misses Copy-on-Write 0 256 128 100000 50000 10001 256 128 110000 45000 950 |
ロック情報には、次の内容が含まれます。
NodeNo: ノード番号。
Avail: ノード上で使用可能なロックの合計数。
Free: 使用されていないロックの数。
Waits: ロックの獲得を待機しているトランザクションの数。これは累積数です。
1 つのトランザクションが、ノード上で利用可能なロックの 25% を超えて使用することはできません。そのため、規模の大きい操作を実行するトランザクションは、この制限を認識している必要があります。そのようなトランザクションはバッチ処理で実行するのが最善です。その場合、それぞれのバッチは別個のトランザクションとして扱われ、バッチごとにコミット操作を行うことになります。このようにする必要があるのは、繰り返し可能な読み取り遮断レベルで実行する読み取り操作、および削除、挿入、更新操作が、トランザクション終了後にのみ解放されるロックを使用するからです。
NumberOfLocks を変更するには、「履歴ファイルの消去と保存」を参照してください。
次に例を示します。
NodeNO Avail Free Waits 0 50000 20000 101 50000 20000 0 |
ログバッファー情報には、次の内容が含まれます。
NodeNo: ノード番号。
Available: ログバッファー用に割り当てられたメモリーの容量。単位は M バイト。
Free: 空きメモリーの容量。単位は M バイト。
空き容量が非常に少ないとしても、HADB がログバッファーの圧縮を開始するので、心配する必要はありません。HADB は、リングバッファーの先頭から圧縮を開始し、連続するログレコードに対して圧縮を実行します。ノードが実行していないのにミラーノードが受信しているログレコードを HADB が検出すると、圧縮は続行できなくなります
次に例を示します。
NodeNO Avail Free 0 16 21 16 3 |
ノード内部ログバッファー情報には、次の内容が含まれます。
ノード番号。
Available: ログデバイス用に割り当てられたメモリーの容量。単位は Mバイト。
Free: 空きメモリーの容量。単位は M バイト。
次に例を示します。
NodeNO Avail Free
0 16 21 16 3