Cache on Application（PD_DCAA）

機能

アプリケーション・レベルのキャッシュ情報を格納しています。

ページの先頭へ

デフォルト値および変更できる値

項目	デフォルト値	設定可否
Collection Interval	60	○
Collection Offset	0	○
Log	No	○
LOGIF	空白	○
Over 10 Sec Collection Time	No	×

ページの先頭へ

ODBCキーフィールド

AGENT_ID

ページの先頭へ

ライフタイム

アプリケーションがデータベースに接続している間。

ページの先頭へ

レコードサイズ

• 固定部：681バイト

• 可変部：368バイト

ページの先頭へ

フィールド

PFM - View名 (PFM - Manager名)	説明	要約	形式	デルタ	サポートVR	制約	データソース
Agent Id (AGENT_ID)	アプリケーションの固有ID。	−	ulong	No	すべて	−	SQLM_ELM_AGENT_ID

詳細説明：

アプリケーション・ハンドルを使用すると，アクティブ・アプリケーションを一意的に識別できます。アプリケーション・ハンドルは，エージェントIDと同義です。

PFM - View名 (PFM - Manager名)	説明	要約	形式	デルタ	サポートVR	制約	データソース
Appl Id (APPL_ID)	アプリケーションがデータベース・マネージャーのデータベースに接続したときのID。	−	string(33)	No	すべて	−	SQLM_ELM_APPL_ID

詳細説明：

このIDはクライアントとサーバの両者によって認識されるため，このIDを使用すると，アプリケーションのクライアント部分とサーバ部分を相関させることができます。DDCSアプリケーションでアプリケーションのクライアント部分とサーバ部分を相関させるにはoutbound_appl_idも必要です。このIDは，ネットワーク内では固有のIDです。アプリケーションIDにはさまざまな形式があり，データベース・マネージャーまたはDDCS（またはその両方）を実行中のクライアントとサーバマシン間の通信プロトコルによって形式が異なります。どの形式の場合もピリオドで区切られた3つの部分で構成されます。

PFM - View名 (PFM - Manager名)	説明	要約	形式	デルタ	サポートVR	制約	データソース
Appl Name (APPL_NAME)	クライアントで実行中のアプリケーションの名前。	−	string(257)	No	すべて	−	SQLM_ELM_APPL_NAM

詳細説明：

このエレメントとappl_idを使用すると，データ項目をアプリケーションに関連づけることができます。クライアントサーバ環境では，この名前はデータベース接続を確立するためにクライアントからサーバに送られます。DRDA-AS接続の場合は，この名前はDEDA外部名となります。クライアント・アプリケーションのコード・ページと実行中のデータベース・システム・モニターが使用しているコード・ページが異なる場合は，appl_nameを交換するときにcodepage_idを利用できます。

PFM - View名 (PFM - Manager名)	説明	要約	形式	デルタ	サポートVR	制約	データソース
Auth Id (AUTH_ID)	モニターされているアプリケーションを呼び出したユーザーの許可ID。	−	string(33)	No	すべて	−	SQLM_ELM_AUTH_ID

詳細説明：

このエレメントを使用すると，アプリケーションを呼び出したユーザーを判別できます。

PFM - View名 (PFM - Manager名)	説明	要約	形式	デルタ	サポートVR	制約	データソース
Cat Cache Inserts (CAT_CACHE_INSERTS)	システムが表記述子または許可情報をカタログ・キャッシュに挿入しようとした回数。	−	ulong	No	すべて	−	SQLM_ELM_CAT_CACHE _INSERTS

詳細説明：

Catalog Cache Lookupsと組み合わせると，次の公式を使用してカタログ・キャッシュ・ヒット率を計算できます。

1-(catalog_cache_inserts/catalog_cache_lookups)

詳細については，DB2のマニュアルを参照してください。

PFM - View名 (PFM - Manager名)	説明	要約	形式	デルタ	サポートVR	制約	データソース
Cat Cache Lookups (CAT_CACHE_LOOKUPS)	表の記述子情報または許可情報を取得するためにカタログ・キャッシュが参照された回数。	−	ulong	No	すべて	−	SQLM_ELM_CAT_CACHE _LOOKUPS

詳細説明：

このエレメントには，カタログ・キャッシュへの正常に行われたアクセスと失敗したアクセスの両方が含まれます。カタログ・キャッシュは，次の場合に参照されます。

• SQLステートメントのコンパイル中に，表，ビュー，または別名を処理したとき。

• データベース許可情報にアクセスがあったとき。

• SQLステートメントのコンパイル中にルーチンを処理したとき。

カタログ・キャッシュ・ヒット率の計算には次の公式を使用します。

(1-(cat_cache_inserts/cat_cache_lookups))

この値は，カタログ・キャッシュがどの程度カタログ・アクセスを回避しているかを示します。この比率が0.8を超える値の場合，キャッシュは効果的に動作しています。比率が低い場合は，catalogcache_szを大きくする必要があることを示します。データベースへの最初の接続の直後は，この比率は高くなります。

表，ビュー，別名などに関係するデータ定義言語(DDL)SQLステートメントは，そのようなオブジェクトに関する表記述子情報を取り除くため，それらのオブジェクトは次の参照で再挿入されることになります。さらに，データベース許可およびルーチンの実行特権のためのGRANTおよびREVOKEのステートメントによって，該当する許可情報がカタログ・キャッシュから取り除かれます。したがって，DDLステートメントとGRANT/REVOKEステートメントを多用した場合も，この比率は大きくなります。

詳細については，DB2のマニュアルを参照してください。

PFM - View名 (PFM - Manager名)	説明	要約	形式	デルタ	サポートVR	制約	データソース
Cat Cache Overflows (CAT_CACHE_OVERFLOWS)	割り振られたメモリーの境界からカタログ・キャッシュがオーバーフローした回数。	−	ulong	No	すべて	−	SQLM_ELM_CAT_CACHE _OVERFLOWS

詳細説明：

このエレメントとcat_cache_size_topを組み合わせて使用すると，オーバーフローを防止するのにカタログ・キャッシュのサイズを大きくする必要があるかどうかを判別できます。カタログ・キャッシュがオーバーフローすると不要なロック・エスカレーションが多くなり，その結果並行性を失ったり，またはデータベース共有メモリーから割り振られたほかのヒープでメモリー不足エラーを起こしたりすることがあります。カタログ・キャッシュのオーバーフローは，性能低下の原因にもなります。

カタログ・キャッシュのスペースは，表，ビュー，別名，または許可情報などの，どのトランザクションでも現在使用されていない表記述子情報を除去することで取り戻します。

cat_cache_overflowsが大きい場合は，ワークロードに対してカタログ・キャッシュが小さ過ぎることが考えられます。カタログ・キャッシュを大きくすると，パフォーマンスが改善されることがあります。多数の表，ビュー，別名，ユーザー定義関数，またはストアード・プロシージャーを参照する多数のSQLステートメントを，1つの作業単位にコンパイルするトランザクションがワークロードに含まれている場合は，1つのトランザクションにコンパイルするSQLステートメントの数を少なくすると，カタログ・キャッシュのパフォーマンスが改善されることがあります。多数の表，ビュー，別名，ユーザー定義関数，またはストアード・プロシージャーを参照する多数のSQLステートメントが入ったパッケージのバインドがワークロードに含まれる場合は，パッケージを分割してその中に含まれるSQLステートメントの数を少なくすると，パフォーマンスが改善されることがあります。

PFM - View名 (PFM - Manager名)	説明	要約	形式	デルタ	サポートVR	制約	データソース
Catcache Hit Rate (CATCACHE_HIT_RATE)	カタログ・キャッシュ・ヒット率。	−	float	No	すべて	−	( 1 - ( CAT_CACHE_INSERTS / CAT_CACHE_LOOKUPS ) ) ＊100

詳細説明：

この比率が80%を超える値の場合，キャッシュは効果的に動作しています。この比率が低い場合は，パッケージ・キャッシュを大きくする必要があることを示します。

PFM - View名 (PFM - Manager名)	説明	要約	形式	デルタ	サポートVR	制約	データソース
DB Name (DB_NAME)	情報が収集されるデータベースの実名またはアプリケーションの接続先でのデータベースの実名。	−	string(9)	No	すべて	−	SQLM_ELM_DB_NAME

詳細説明：

このエレメントを使用すると，データが適用される特定のデータベースを識別できます。

ホストへの接続またはIBM製品でのデータベースサーバへの接続でDB2Connectを使用しないアプリケーションの場合は，このエレメントとdc_pathモニター・エレメントを組み合わせて使用すると，データベースを個別に識別し，モニターが提供する情報の各レベルに関連づけることができます。

PFM - View名 (PFM - Manager名)	説明	要約	形式	デルタ	サポートVR	制約	データソース
Interval (INTERVAL)	情報が収集される時間。秒単位。	−	ulong	No	すべて	−	RECORD_TIME - CURRENT _SYSTEM_BOOT_TIME

詳細説明：

特になし。

PFM - View名 (PFM - Manager名)	説明	要約	形式	デルタ	サポートVR	制約	データソース
Num Assoc Agents (NUM_ASSOC_AGENTS)	1つのアプリケーションに関連づけられているサブエージェントの数。	−	ulong	No	すべて	−	SQLM_ELM_NUM_ASSOC _AGENTS

詳細説明：

このエレメントは，エージェント構成パラメーターの設定を評価するのに役立ちます。

PFM - View名 (PFM - Manager名)	説明	要約	形式	デルタ	サポートVR	制約	データソース
Pkg Cache Hit Rate (PKG_CACHE_HIT_RATE)	パッケージ・キャッシュ・ヒット率。	−	float	No	すべて	−	( 1- ( PKG_CACHE_INSERTS / PKG_CACHE_LOOKUPS ) ) ＊100

詳細説明：

この比率が80%を超える値の場合，キャッシュは効果的に動作しています。この比率が低い場合は，パッケージ・キャッシュを大きくする必要があることを示します。

PFM - View名 (PFM - Manager名)	説明	要約	形式	デルタ	サポートVR	制約	データソース
Pkg Cache Inserts (PKG_CACHE_INSERTS)	要求したセクションが使用できなかったためにパッケージ・キャッシュへのロードが必要になった回数の合計。	−	ulong	No	すべて	−	SQLM_ELM_PKG_CACHE _INSERTS

詳細説明：

このカウントには，システムが暗黙に準備した数が含まれます。パッケージ・キャッシュ参照数と組み合わせると，次の公式を使用してパッケージ・キャッシュ・ヒット率を計算できます。

1-(package_cache_inserts/package_cache_lookups)

詳細については，DB2のマニュアルを参照してください。

PFM - View名 (PFM - Manager名)	説明	要約	形式	デルタ	サポートVR	制約	データソース
Pkg Cache Lookups (PKG_CACHE_LOOKUPS)	アプリケーションがパッケージ・キャッシュ内のセクションやパッケージを検索した回数。	−	ulong	No	すべて	−	SQLM_ELM_PKG_CACHE _LOOKUPS

詳細説明：

パッケージ・キャッシュ・ヒット率の計算には次の公式を使用します。

1-(package_cache_inserts/package_cache_lookups)

パッケージ・キャッシュ・ヒット率は，パッケージ・キャッシュが効果的に利用されているかどうかを示します。この比率が0.8を超える値の場合，キャッシュは効果的に動作しています。この比率が低い場合は，パッケージ・キャッシュを大きくする必要があることを示します。

パッケージ・キャッシュのサイズを変えて試すことによって，pckcachesz構成パラメーターに最適な値を見つける必要があります。例えば，キャッシュのサイズを小さくしてもpkg_cache_insertsエレメントが増えない場合は，パッケージ・キャッシュのサイズをさらに小さくできます。パッケージ・キャッシュのサイズを小さくすれば，その分のシステム・リソースをほかの作業のために使えるようになります。pkg_cache_insertsの数を少なくして，パッケージ・キャッシュのサイズを大きくすると，システム全体のパフォーマンスが向上します。この実験は，フル・ワークロードの条件で行うのが最善です。

このエレメントとddl_sql_stmtsを組み合わせて使用すると，DDLステートメントを実行したときにパッケージ・キャッシュのパフォーマンスに影響を与えるかどうかを判別できます。DDLステートメントを実行すると，動的SQLステートメントの一部のセクションが無効になる場合があります。無効なセクションは，次に使用されるときにシステムが暗黙的に準備します。DDLステートメントを実行すると，多数のセクションが無効になり，こうしたセクションを準備するときに余分に必要になるオーバーヘッドのためにパフォーマンスが大きく低下することがあります。この場合のパッケージ・キャッシュ・ヒット率は，無効なセクションの暗黙的な再コンパイルを反映しますが，キャッシュに挿入される新しいセクションは反映しないので，パッケージ・キャッシュのサイズを大きくしても総合的なパフォーマンスは改善できません。フル環境を対象に作業する前に，アプリケーション自体のキャッシュを調整すれば，混乱を避けることができます。

実行する必要があるアクションを考える前に，パッケージ・キャッシュ・ヒット率の値にDDLステートメントがどのような役割を果たしているのかを明確にする必要があります。DDLステートメントがあまり発生しない場合は，キャッシュのサイズを大きくするとキャッシュのパフォーマンスを改善できる場合があります。DDLステートメントが頻繁に使用される場合は，DDLステートメントを制限する(時間を限定するなど)と改善できる場合があります。

static_sql_stmtsおよびdynamic_sql_stmtsのカウントは，キャッシュに入れるセクションの数量とタイプに関する情報を提供するときに利用できます。

詳細については，DB2のマニュアルを参照してください。

注：

この情報をデータベース・レベルで使用すると，すべてのアプリケーションについて個別の平均パッケージ・キャッシュ・ヒット率を計算できます。特定のアプリケーションのパッケージ・キャッシュ・ヒット率が知りたいときには，この情報をアプリケーション・レベルで調べてください。実行頻度の少ないアプリケーションのキャッシュ要件を満たすためにパッケージ・キャッシュのサイズを大きくしてもあまり意味がありません。

PFM - View名 (PFM - Manager名)	説明	要約	形式	デルタ	サポートVR	制約	データソース
Record Time (RECORD_TIME)	レコードに格納されたパフォーマンスデータの収集終了時刻。	−	time_t	No	すべて	−	Agent Collector

詳細説明：

特になし。

PFM - View名 (PFM - Manager名)	説明	要約	形式	デルタ	サポートVR	制約	データソース
Record Type (INPUT_RECORD_TYPE)	レコード名。常に「DCAA」。	−	char(8)	No	すべて	−	Agent Collector

詳細説明：

特になし。

ページの先頭へ