バージョン 8.1.3
 —  DBA タスク  —

データベースのモニタリングとチューニング

モニタリングとチューニングでのデータベース管理者の作業は次のとおりです。


リソース使用のモニタリング

データベースの完全性が維持され、かつ効率的なレベルのサービスが提供されているかを確認するため、継続してデータベース環境のモニタを行うのは DBA の役目です。

DBA は、サービス低下が起こる前にこれを予測したり、データベースのオペレーションや設計を規則的にコントロールされた方法で調整する一連の手順を設定しなければなりません。 この手順とは、次のような作業を行います。

Top of page

データベース使用のレポート出力

DBA は、データ処理部門とユーザー部門のマネージメントに対して、データベース使用とパフォーマンスに関して定期的にレポートすべきです。 このレポートは、できるだけ事実を反映させ、また必要があればデータベース環境に対するチューニングの勧告も含む必要があります。 チューニングは組織全体には利益をもたらしますが、一部のユーザーにはサービスの低下になることもあります。 したがって、チューニングに関する決定はすべての関連ユーザーのことを考慮しなければなりません。

Top of page

データベース制御のモニタリング

DBA は適切な管理方法を設定し、データベースの完全性を保証するためにこれをモニタする必要があります。

このコンピュータが作成する管理情報(コントロールトータル)がコンピュータ処理実行時間や生成レポートについてチェックするときに役立ちます。 バッチレスポンス(あるいは問い合わせ)では、実行時間、サーチパラメータ、最終データ更新時刻およびプライマリパラメータコントロールのような情報を含みます。 これは、信頼レベルを高め、データベースの完全性を保証するうえで役に立ちます。

コントロールトータルに問題がある場合、それぞれのインストールに応じて問題が異なることがあります。 この分野で、しっかりした規則をすぐに作成することは不可能ですが、一般的な指標は示すことは可能です。

データベースを使用する各アプリケーションシステムの設計時に、DBA は次のような考慮がされているかを確認する必要があります。

Top of page

パフォーマンス管理、統計、チューニング

次の表に、使用する統計のモニタリングのいくつかとデータベース環境に対する調整(あるいはチューニング)を示します。

変化するもの 必要なチューニング
データベースの構造 使用アクセスメソッド ハードウェアまたはソフトウェア構成 処理プライオリティ ディスクストレージ割り当て
端末およびライントラフィック  
レスポンスタイム(アプリケーションのパフォーマンス)
ユーザーの総アクセスおよびディスクリプタ    
データベースサイズ  
データベースの成長度  

本番データベースに何らかの変化があったときは、信頼性や完全性を高度に保つよう十分な注意が必要です。 何が変化しても、DBA は正しい判断を下しそれが正確に行われるよう保証しなければなりません。 チューニング処理に対して DBA は絶対的なコントロールを持ち、正式な受入れ手順に沿っているかを確認しなければなりません。

上の表中の項目の変化について過度に対応することがないよう DBA は注意しなければなりません。 ライントラフィックやレスポンスタイム等が突然変化した場合、一時的な現象かもしれないので、 通常のオペレーティング状態でしばらく様子を見て、恒久的な傾向なのか一時的な現象なのかを判断する必要があります。

もう 1 つの表の見方として、新規プロジェクトの導入により、ライントラフィックやレスポンスタイム等にかなりの変化がみられるとき、要求のチューニングが必要かを判断するのに使用します。DBA は、新規アプリケーションシステムを導入する前に、これらの影響を最小限にとどめるように対応できます。

Top of page

Adabas セッション統計

各 Adabas セッションの終わりに出力される統計を使用して Adabas のパフォーマンスをモニタできます。 具体的には、セッション統計として次の統計が用意されています。

I/O 統計

次の 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 番号ごとの ASSO/DATA I/O の配分(初期化を除く)

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 はフォーマットの上書きが過剰にならないよう注意し、次の処置を取る必要があります。

  1. ユーザープログラムがコマンド ID を正しく使用しているかどうか、つまり適時空白以外のコマンド ID を使用したり、不要なコマンド ID を解放しているかどうかを確認します コマンド ID 使用の詳細については、『Adabas コマンドリファレンスマニュアル』を参照してください。

  2. 内部フォーマットバッファプールのサイズの拡大を考慮します(『Adabas オペレーションマニュアル』「ADARUN LFP パラメータ」参照)。

Adabas ニュークリアスによって、各セッションの終了時にフォーマット変換とフォーマット上書きの統計表が作成されます。 Adabas オペレータコマンド DSTAT を使用してこの情報を確認することもできます。

自動再スタート

セッション中に行われた自動再スタートの回数です。

コマンドのスローバック

Adabas ニュークリアスが、次のリソースのどちらかを待っていたためにコマンドが実行できなかった回数です。

このような場合にはコマンドは後で処理するようコマンドキューに戻されます(スローバック)。

この数が 0 より大きければ、次の処置を取る必要があります。

  1. ADARUN LWP(ワークプールサイズ)パラメータと LS(ソートワークエリア)パラメータの比率を調整します。

  2. Adabas ワークプールのサイズを大きくします(ADARUN LWP パラメータ)。

  3. ADARUN TT(トランザクションタイムリミット)パラメータを評価します。

  4. アプリケーションプログラムのホールドロジックをチェックします。

  5. Adabas ホールドキューサイズを大きくします(ADARUN NH パラメータ)。

  6. スーパーディスクリプタを使って検索コマンドの複雑さを減らします。

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 パラメータを調整しなければなりません。

Top of page

コマンドロギング

Adabas コマンドロギングは Adabas に対してユーザーが発行した全コマンドに関する情報を生成します。 次の情報が得られます。

コマンドロギングは ADARUN パラメータ LOGGING により制御されます。

Top of page