モニタリングとチューニングでのデータベース管理者の作業は次のとおりです。
データベースの完全性が維持され、かつ効率的なレベルのサービスが提供されているかを確認するため、継続してデータベース環境のモニタを行うのは DBA の役目です。
DBA は、サービス低下が起こる前にこれを予測したり、データベースのオペレーションや設計を規則的にコントロールされた方法で調整する一連の手順を設定しなければなりません。 この手順とは、次のような作業を行います。
サービス低下を引き起す可能性のある原因の特定
データベースパフォーマンスをモニタするツールの設定
調整作業のコントロール
DBA は、データ処理部門とユーザー部門のマネージメントに対して、データベース使用とパフォーマンスに関して定期的にレポートすべきです。 このレポートは、できるだけ事実を反映させ、また必要があればデータベース環境に対するチューニングの勧告も含む必要があります。 チューニングは組織全体には利益をもたらしますが、一部のユーザーにはサービスの低下になることもあります。 したがって、チューニングに関する決定はすべての関連ユーザーのことを考慮しなければなりません。
DBA は適切な管理方法を設定し、データベースの完全性を保証するためにこれをモニタする必要があります。
このコンピュータが作成する管理情報(コントロールトータル)がコンピュータ処理実行時間や生成レポートについてチェックするときに役立ちます。 バッチレスポンス(あるいは問い合わせ)では、実行時間、サーチパラメータ、最終データ更新時刻およびプライマリパラメータコントロールのような情報を含みます。 これは、信頼レベルを高め、データベースの完全性を保証するうえで役に立ちます。
コントロールトータルに問題がある場合、それぞれのインストールに応じて問題が異なることがあります。 この分野で、しっかりした規則をすぐに作成することは不可能ですが、一般的な指標は示すことは可能です。
データベースを使用する各アプリケーションシステムの設計時に、DBA は次のような考慮がされているかを確認する必要があります。
各バッチ更新処理の実行時、どのようなチェックを行えるか。 例えば、レコード件数、追加、削除、更新を行うときなど。
これらをチェックするのにどんな制御がファイル全体にわたって必要か。 例えば、値フィールドのハッシュトータルなど。
ある期間の終わりに、コントロールトータルを調べ誤りであることがわかったとき、データを回復するためにどんな入力トランザクション、Adabas ログ等を保持しておかなければならないか。
地域別のコントロールトータル(支店別、製品グループ別)から、ファイルコントロールトータルエラーの影響を受ける領域を特定できるか。
次の表に、使用する統計のモニタリングのいくつかとデータベース環境に対する調整(あるいはチューニング)を示します。
変化するもの | 必要なチューニング | ||||
---|---|---|---|---|---|
データベースの構造 | 使用アクセスメソッド | ハードウェアまたはソフトウェア構成 | 処理プライオリティ | ディスクストレージ割り当て | |
端末およびライントラフィック | ○ | ○ | ○ | ○ | |
レスポンスタイム(アプリケーションのパフォーマンス) | ○ | ○ | ○ | ○ | ○ |
ユーザーの総アクセスおよびディスクリプタ | ○ | ○ | ○ | ||
データベースサイズ | ○ | ○ | ○ | ○ | |
データベースの成長度 | ○ | ○ | ○ | ○ |
本番データベースに何らかの変化があったときは、信頼性や完全性を高度に保つよう十分な注意が必要です。 何が変化しても、DBA は正しい判断を下しそれが正確に行われるよう保証しなければなりません。 チューニング処理に対して DBA は絶対的なコントロールを持ち、正式な受入れ手順に沿っているかを確認しなければなりません。
上の表中の項目の変化について過度に対応することがないよう DBA は注意しなければなりません。 ライントラフィックやレスポンスタイム等が突然変化した場合、一時的な現象かもしれないので、 通常のオペレーティング状態でしばらく様子を見て、恒久的な傾向なのか一時的な現象なのかを判断する必要があります。
もう 1 つの表の見方として、新規プロジェクトの導入により、ライントラフィックやレスポンスタイム等にかなりの変化がみられるとき、要求のチューニングが必要かを判断するのに使用します。DBA は、新規アプリケーションシステムを導入する前に、これらの影響を最小限にとどめるように対応できます。
各 Adabas セッションの終わりに出力される統計を使用して Adabas のパフォーマンスをモニタできます。 具体的には、セッション統計として次の統計が用意されています。
入出力(I/O)統計
コマンド統計
プール/キュー使用統計
次の I/O 統計が出力されます。
読み込み | 書き込み | |
---|---|---|
ASSO | 50 | 21 |
DATA | 2388 | 2184 |
WORK | 9 | 1385 |
PLOG | 9 | 1603 |
CLOG | 0 | 0 |
合計 | 2456 | 5193 |
LOG. READS | 33899 | |
BUFFER EFF. | 13.9 |
I/O 件数はセッション中に実行されたアソシエータ(ASSO)、データストレージ(DATA)、ワーク(WORK)、データプロテクションログ(PLOG)、およびコマンドログ(CLOG)に対する物理 I/O 回数を示します。
さらにバッファプールに対して発行された論理読み込みの回数(LOG. READS)、および論理読み込み回数をアソシエータとデータストレージの読み込み回数で割った、バッファ効率(BUFFER EFF.)が得られます。 バッファ効率の値が高いほどバッファプールの利用効率が良くなります。 その値が 10 未満の場合には DBA は Adabas バッファプールのサイズを大きくする必要があります(『Adabas オペレーションマニュアル』の「LBP パラメータ」参照)。
VOL-SER | HIGH RABN | COUNT |
---|---|---|
ADA003 | (ASSO:894) | 38 |
ADA003 | (ASSO:2544) | 6 |
ADA003 | (DATA:894) | 0 |
ADA003 | (DATA:1344) | 4572 |
合計 | 4616 |
物理ボリュームごとのアソシエータ、およびデータストレージについての I/O 配分に関する情報も提供されます。 アクセス/更新された最大 RABN(HIGH RABN)、および I/O 回数(COUNT)が示されます。 DBA はこのデータを使用して、バッファプールパラメータやデータベースの物理割り当てに調整が必要かどうか判断する必要があります。
次の例では、Adabas は 5 つのスレッドで 12,687 コールを実行したセッションのコマンド統計が出力されます。
次の表は、セッションのコマンドソースを表示します。同一の環境(ローカル)またはネットワークを経由するリモート環境のどちらかです。
ソース | 件数 |
---|---|
REMOTE LOGICAL | 0 |
REMOTE PHYSICAL | 0 |
LOCAL LOGICAL | 0 |
LOCAL PHYSICAL | 12,686 |
次の表はセッションにおけるスレッドの活動を示します。
スレッド | 件数 |
---|---|
1 | 7,328 |
2 | 2,728 |
3 | 1,240 |
4 | 814 |
5 | 541 |
合計 | 12,651 |
最大番号のスレッドがゼロより大きい活動回数を持つ場合には、スレッド数を増やせば Adabas ニュークリアスはより多くのコマンドを処理できることが推測できます。 スレッド数の増加によりコマンドがコマンドキューで選択を待つのを防止できます。
次の表はファイル別のコマンド数の配分を示します。
ファイル | 件数 |
---|---|
0 | 4,247 |
1 | 8,404 |
合計 | 12,651 |
ファイルに関係しないコマンド(BT、ET など)はファイル 0 に数えられます。
次の表はコマンドタイプ別のコマンド数の配分を示します。
コマンドタイプ | 件数 |
---|---|
A1/4 | 4,198 |
ET | 4,191 |
L1/4 | 4,242 |
OP | 56 |
合計 | 12,687 |
コマンドタイプ UC は Adabas ユーティリティから発行された特権コールを示します。
注意:
コマンドタイプ REST は C1、C5、RI、HI のようなコマンドを示します。
THERE WERE 56 USERS PARTICIPATING MOST CALLS ( 57) INITIATED BY USER user ID MOST I/O-S ( 14) INITIATED BY USER user ID MOST THR.-TIME (04:16:32) WAS USED BY USER user ID
28 | フォーマットが変換された |
0 | フォーマットが上書きされた |
0 | 自動再スタートが行われた |
20 | ISN 問題が原因で戻された |
16 | スペース問題が原因で戻された |
186 | バッファフラッシュが起きた |
Adabas の読み込みコマンドと更新コマンドでは読み込む、あるいは更新するフィールドをフォーマットバッファに指定する必要があります。 このフォーマットバッファは Adabas によって解釈され、内部フォーマットバッファに変換されます。結果としてできた各内部フォーマットバッファは内部フォーマットバッファプールに格納され、 ユーザー ID とコマンド ID の組み合わせにより識別されます。
Adabas は新しい読み込み/更新コマンドについてそれぞれユーザー ID/コマンド ID で識別されるエントリがすでにプール内に存在しているかをチェックし、 存在していない場合、Adabas によってコマンドの新しいフォーマットバッファが変換され、プールに入れられます。 フォーマットバッファプールが一杯になると、既存のエントリは新しいエントリを格納するために上書きされます。
フォーマット変換処理では、CPU に大きな負荷がかかります。 したがって、DBA はフォーマットの上書きが過剰にならないよう注意し、次の処置を取る必要があります。
ユーザープログラムがコマンド ID を正しく使用しているかどうか、つまり適時空白以外のコマンド ID を使用したり、不要なコマンド ID を解放しているかどうかを確認します コマンド ID 使用の詳細については、『Adabas コマンドリファレンスマニュアル』を参照してください。
内部フォーマットバッファプールのサイズの拡大を考慮します(『Adabas オペレーションマニュアル』「ADARUN LFP パラメータ」参照)。
Adabas ニュークリアスによって、各セッションの終了時にフォーマット変換とフォーマット上書きの統計表が作成されます。 Adabas オペレータコマンド DSTAT を使用してこの情報を確認することもできます。
セッション中に行われた自動再スタートの回数です。
Adabas ニュークリアスが、次のリソースのどちらかを待っていたためにコマンドが実行できなかった回数です。
使用可能な ISN
Adabas ワークプールスペース
このような場合にはコマンドは後で処理するようコマンドキューに戻されます(スローバック)。
この数が 0 より大きければ、次の処置を取る必要があります。
ADARUN LWP(ワークプールサイズ)パラメータと LS(ソートワークエリア)パラメータの比率を調整します。
Adabas ワークプールのサイズを大きくします(ADARUN LWP パラメータ)。
ADARUN TT(トランザクションタイムリミット)パラメータを評価します。
アプリケーションプログラムのホールドロジックをチェックします。
Adabas ホールドキューサイズを大きくします(ADARUN NH パラメータ)。
スーパーディスクリプタを使って検索コマンドの複雑さを減らします。
ADARUN パラメータについては、『Adabas オペレーションマニュアル』を参照してください。
セッション中に起きたバッファフラッシュの回数。
Adabas バッファプールはアクティブな全ユーザーに共有される仮想データベースを示します。 バッファプールには、最もよく使われるアソシエータおよびデータストレージブロックが含まれ、その目的は物理 I/O を最小にすることです。
バッファプールの大きさは ADARUN LBP パラメータで決まります。 LBP は、できる限り大きく設定する必要があります。その設定が大きすぎると、オペレーティングシステムのページング回数が極端に増えてしまうため、そうならないように注意します。
セッション統計には、セッション中に使用したバッファおよびキューの最大利用率も含まれます。 このような統計は、バッファプールを除き、最大値を計算できるすべてのバッファおよびキューについて示されます。 次の表にサンプルセッションの最大値を示します。
プールエリア | ADARUN パラメータ | 最大値 | % |
---|---|---|---|
AB | NAB = 10 | 12032 | 29 |
CQ | NC = 20 | 3648 | 95 |
DUQ | LDEUQP = 5000 | 500 | 10 |
FI | LFP= 12000 | 1760 | 14 |
HQ | NH = 100 | 552 | 23 |
SC | LCP= 10000 | 0 | 0 |
TBI | LI = 10000 | 0 | 0 |
TBS | LQ = 10000 | 0 | 0 |
UQ | NU = 20 | 4880 | 86 |
UQF | NU = 20 | ||
WORK | LWP = 14000 | 70464 | 50 |
XID | XID = 0 | 0 | 0 |
注意:
UQF は、ファイルリストを保持するユーザーキュー拡張です。 そのプールのサイズは、UQ
プールサイズを使用して計算されます。
セッション中に有効であった ADARUN パラメータ設定値に関する最大値が示されます。
DBA は、それぞれの最大値を監視し、必要ならば適当な ADARUN パラメータを調整しなければなりません。
Adabas コマンドロギングは Adabas に対してユーザーが発行した全コマンドに関する情報を生成します。 次の情報が得られます。
ユーザー ID
日時
使用されたコマンド
アクセスされたファイル
アクセスされたレコード
受け取った Adabas レスポンスコード
コマンドの実行にかかった時間
コマンドロギングは ADARUN パラメータ LOGGING により制御されます。