使用法

このエレメントを sc_work_class_id エレメントを組み合わせて使用すると、アクティビティーのサービス・クラス作業クラスが存在する場合にはそれを一意的に識別できます。

使用法

このエレメントを sc_work_action_set_id エレメントを組み合わせて使用すると、アクティビティーのサービス・クラス作業クラスが存在する場合にはそれを一意的に識別できます。

使用法

使用法

セクション Explain のプロシージャーと一緒にこのエレメントを使用すると、ステートメントを Explain して、ステートメントのアクセス・プランを表示させることができます。

使用法

このエレメントと num_columns_referenced エレメントを使用すると、SQL ステートメントのランタイム・セクションの実行中に表からアクセスされる列の平均数を判別できます。 この平均列アクセス・カウントは、 カラム・オーガナイズ 表への変換の候補になる可能性がある 行オーガナイズ 表 (例えば、通常は少数の列のみがアクセスされるワイド表) を識別するのに役立ちます。

このエレメントは、 カラム・オーガナイズ 表へのアクセスの効率性を理解するのにも役立ちます (例えば、表のスキャン時に通常読み取られる列数)。

使用法

静的 SQL ステートメントの場合は、このエレメントと creator、package_version_id、および package_name モニター・エレメントを組み合わせて使用すると、次のサンプル照会を使用して、SYSCAT.STATEMENTS システム・カタログ表を照会し、静的 SQL ステートメント・テキストを取得できます。

 
    SELECT SEQNO, SUBSTR(TEXT,1,120)
           FROM SYSCAT.STATEMENTS
           WHERE PKGNAME   = 'package_name' AND
                 PKGSCHEMA = 'creator'      AND
                 VERSION = 'package_version_id' AND
                 SECTNO    = section_number
           ORDER BY SEQNO

使用法

使用法

このエレメントを使用すると、 このデータ・ソースのデータを待機した実際の時間を判別できます。 この情報は、キャパシティー・プランニング、CPU のチューニング、 および SYSCAT.SERVERS の通信速度を調整するときに役に立ちます。 これらのパラメーターを変更すると、 オプティマイザーが要求をデータ・ソースに送信するかしないかに影響を与えます。

応答時間は、 フェデレーテッド・サーバーがデータ・ソースから行を要求してからフェデレーテッド・サーバーがその行を利用できるようになるまでの時間です。

使用法

このエレメントと照会ステートメント ID モニター・エレメント (stmtid) を組み合わせて使用すると、SQL ステートメントを識別できます。 同じステートメント・テキストを持つ照会を識別するためにセマンティック・コンパイル環境 ID が使用されますが、照会は異なるオブジェクトを参照するので、意味的には異なります。 例えば、ステートメント SELECT * FROM T1 で参照される表は、コンパイル環境のデフォルト・スキーマの値に依存します。 異なるデフォルト・スキーマを持つ 2 人のユーザーがこのステートメントを発行した場合、ステートメントの 2 つの項目がパッケージ・キャッシュに入ります。 2 つのエントリーは同じ stmtid 値を持ちますが、semantic_env_id の値は異なります。

使用法

使用法

このエレメントの値は、ビュー SYSCAT.SERVICECLASSES の列 SERVICECLASSID の値と一致します。 このエレメントを使用して、サービス・サブクラス名、または別のソースのサービス・サブクラスに関するリンク情報を検索します。 例えば、サービス・クラス統計をヒストグラム・ビン・レコードと結合させます。

使用法

このモニター・エレメントは、 sc_work_action_set_id モニター・エレメントの別名です。

使用法

このモニター・エレメントは、 sc_work_class_id モニター・エレメントの別名です。

使用法

このエレメントを他のアクティビティー・エレメントと一緒に使用すると、アクティビティーの動作の分析をすることができます。あるいは、他の統計エレメントと一緒に使用すると、サービス・クラスまたはしきい値キューの動作の分析をすることができます。

使用法

このエレメントを他のアクティビティー・エレメントと一緒に使用すると、アクティビティーの動作の分析をすることができます。あるいは、他の統計エレメントと一緒に使用すると、サービス・クラスまたはしきい値キューの動作の分析をすることができます。

使用法

このエレメントは、SQL ステートメントの準備、SQL ステートメントの実行、 またはその両方を行うのにどの許可 ID が使用されているかを判別するのに役立ちます。 このモニター・エレメントは、ストアード・プロシージャーの実行中に設定されたセッション許可 ID 値は報告しません。

使用法

使用法

• 新しいページであったため、まだディスク上には作成されていなかった。
• 別のエージェントが同じページを必要としたため、 別のプリフェッチ要求によってバッファー・プールにロードされた。 この場合は、 上記のケースと同様、スキップされたプリフェッチ要求の増加は問題ではありません。 生成された追加のプリフェッチ要求が冗長だっただけだからです。
• プリフェッチャーがプリフェッチ操作を完了できるようになる前に、 エージェントが直接ディスクからページを取り出した。 システムに十分な数のプリフェッチャーが構成されていない場合、あるいは別のタイプのプリフェッチのボトルネックが存在する場合、エージェントが直接ディスクからページを読み取ることを余儀なくされることがあります。 例えば、OLTP システムでは、ワークロードの大部分が通常はトランザクションであるため、構成パラメーター num_ioservers を 1 に設定することによって、プリフェッチャーの最小数が構成される場合があります。 しかし、表スキャンなど、プリフェッチを使用する操作が実行されると、単一のプリフェッチャーが処理を続行できない可能性があるため、エージェントはページを直接要求します。 この動作は、 本来プリフェッチャーが実行したはずの入出力に アプリケーションが対応することになるため、 パフォーマンスの低下を招く可能性があります。 この場合は、構成パラメーター num_ioservers を調整して、プリフェッチャーの数を増やすことを検討してください。 他に考えられる原因としては、プリフェッチ・サイズが極端に大きいためにプリフェッチ時間が通常より長くなる場合や、db2_parallel_io レジストリー変数が設定されていないために表スペース・コンテナー内の並列プリフェッチが制限されている場合などがあります。

使用法

• 新しいページであったため、まだディスク上には作成されていなかった。
• 別のエージェントが同じページを必要としたため、 別のプリフェッチ要求によってバッファー・プールにロードされた。 この場合は、 上記のケースと同様、スキップされたプリフェッチ要求の増加は問題ではありません。 生成された追加のプリフェッチ要求が冗長だっただけだからです。
• プリフェッチャーがプリフェッチ操作を完了できるようになる前に、 エージェントが直接ディスクからページを取り出した。 システムに十分な数のプリフェッチャーが構成されていない場合、あるいは別のタイプのプリフェッチのボトルネックが存在する場合、エージェントが直接ディスクからページを読み取ることを余儀なくされることがあります。 例えば、OLTP システムでは、ワークロードの大部分が通常はトランザクションであるため、構成パラメーター num_ioservers を 1 に設定することによって、プリフェッチャーの最小数が構成される場合があります。 しかし、表スキャンなど、プリフェッチを使用する操作が実行されると、単一のプリフェッチャーが処理を続行できない可能性があるため、エージェントはページを直接要求します。 この動作は、 本来プリフェッチャーが実行したはずの入出力に アプリケーションが対応することになるため、 パフォーマンスの低下を招く可能性があります。 この場合は、構成パラメーター num_ioservers を調整して、プリフェッチャーの数を増やすことを検討してください。 他に考えられる原因としては、プリフェッチ・サイズが極端に大きいためにプリフェッチ時間が通常より長くなる場合や、db2_parallel_io レジストリー変数が設定されていないために表スペース・コンテナー内の並列プリフェッチが制限されている場合などがあります。

使用法

使用法

• 新しいページであったため、まだディスク上には作成されていなかった。
• 別のエージェントが同じページを必要としたため、 別のプリフェッチ要求によってバッファー・プールにロードされた。 この場合は、 上記のケースと同様、スキップされたプリフェッチ要求の増加は問題ではありません。 生成された追加のプリフェッチ要求が冗長だっただけだからです。
• プリフェッチャーがプリフェッチ操作を完了できるようになる前に、 エージェントが直接ディスクからページを取り出した。 システムに十分な数のプリフェッチャーが構成されていない場合、あるいは別のタイプのプリフェッチのボトルネックが存在する場合、エージェントが直接ディスクからページを読み取ることを余儀なくされることがあります。 例えば、OLTP システムでは、ワークロードの大部分が通常はトランザクションであるため、構成パラメーター num_ioservers を 1 に設定することによって、プリフェッチャーの最小数が構成される場合があります。 しかし、表スキャンなど、プリフェッチを使用する操作が実行されると、単一のプリフェッチャーが処理を続行できない可能性があるため、エージェントはページを直接要求します。 この動作は、 本来プリフェッチャーが実行したはずの入出力に アプリケーションが対応することになるため、 パフォーマンスの低下を招く可能性があります。 この場合は、構成パラメーター num_ioservers を調整して、プリフェッチャーの数を増やすことを検討してください。 他に考えられる原因としては、プリフェッチ・サイズが極端に大きいためにプリフェッチ時間が通常より長くなる場合や、db2_parallel_io レジストリー変数が設定されていないために表スペース・コンテナー内の並列プリフェッチが制限されている場合などがあります。

使用法

• 新しいページであったため、まだディスク上には作成されていなかった。
• 別のエージェントが同じページを必要としたため、 別のプリフェッチ要求によってバッファー・プールにロードされた。 この場合は、 上記のケースと同様、スキップされたプリフェッチ要求の増加は問題ではありません。 生成された追加のプリフェッチ要求が冗長だっただけだからです。
• プリフェッチャーがプリフェッチ操作を完了できるようになる前に、 エージェントが直接ディスクからページを取り出した。 システムに十分な数のプリフェッチャーが構成されていない場合、あるいは別のタイプのプリフェッチのボトルネックが存在する場合、エージェントが直接ディスクからページを読み取ることを余儀なくされることがあります。 例えば、OLTP システムでは、ワークロードの大部分が通常はトランザクションであるため、構成パラメーター num_ioservers を 1 に設定することによって、プリフェッチャーの最小数が構成される場合があります。 しかし、表スキャンなど、プリフェッチを使用する操作が実行されると、単一のプリフェッチャーが処理を続行できない可能性があるため、エージェントはページを直接要求します。 この動作は、 本来プリフェッチャーが実行したはずの入出力に アプリケーションが対応することになるため、 パフォーマンスの低下を招く可能性があります。 この場合は、構成パラメーター num_ioservers を調整して、プリフェッチャーの数を増やすことを検討してください。 他に考えられる原因としては、プリフェッチ・サイズが極端に大きいためにプリフェッチ時間が通常より長くなる場合や、db2_parallel_io レジストリー変数が設定されていないために表スペース・コンテナー内の並列プリフェッチが制限されている場合などがあります。

使用法

• 新しいページであったため、まだディスク上には作成されていなかった。
• 別のエージェントが同じページを必要としたため、 別のプリフェッチ要求によってバッファー・プールにロードされた。 この場合は、 上記のケースと同様、スキップされたプリフェッチ要求の増加は問題ではありません。 生成された追加のプリフェッチ要求が冗長だっただけだからです。
• プリフェッチャーがプリフェッチ操作を完了できるようになる前に、 エージェントが直接ディスクからページを取り出した。 システムに十分な数のプリフェッチャーが構成されていない場合、あるいは別のタイプのプリフェッチのボトルネックが存在する場合、エージェントが直接ディスクからページを読み取ることを余儀なくされることがあります。 例えば、OLTP システムでは、ワークロードの大部分が通常はトランザクションであるため、構成パラメーター num_ioservers を 1 に設定することによって、プリフェッチャーの最小数が構成される場合があります。 しかし、表スキャンなど、プリフェッチを使用する操作が実行されると、単一のプリフェッチャーが処理を続行できない可能性があるため、エージェントはページを直接要求します。 この動作は、 本来プリフェッチャーが実行したはずの入出力に アプリケーションが対応することになるため、 パフォーマンスの低下を招く可能性があります。 この場合は、構成パラメーター num_ioservers を調整して、プリフェッチャーの数を増やすことを検討してください。 他に考えられる原因としては、プリフェッチ・サイズが極端に大きいためにプリフェッチ時間が通常より長くなる場合や、db2_parallel_io レジストリー変数が設定されていないために表スペース・コンテナー内の並列プリフェッチが制限されている場合などがあります。

使用法

このモニター・エレメントは、他の skipped_prefetch_uow_*_p_reads エレメントとともに、プリフェッチ要求が作成される原因となったものと同じ作業単位内のエージェントによって直接読み取られた、プリフェッチ要求内のページの数を示します。 システムに十分な数のプリフェッチャーが構成されていない場合、あるいは別のタイプのプリフェッチのボトルネックが存在する場合、エージェントが直接ディスクからページを読み取ることを余儀なくされることがあります。 例えば、ほとんどのワークロードが通常はトランザクションである OLTP システムでは、num_ioservers 構成パラメーターを 1 に設定することによって、プリフェッチャーの最小数を構成することができます。 しかし、表スキャンなど、プリフェッチを使用する操作が実行されると、単一のプリフェッチャーが処理を続行できない可能性があるため、エージェントはページを直接要求します。 この動作は、 本来プリフェッチャーが実行したはずの入出力に アプリケーションが対応することになるため、 パフォーマンスの低下を招く可能性があります。 この場合は、num_ioservers 構成パラメーターを調整して、プリフェッチャーの数を増やすことを検討してください。 他に考えられる原因としては、プリフェッチ・サイズが極端に大きいためにプリフェッチ時間が通常より長くなることや、db2_parallel_io レジストリー変数が設定されていないために表スペース・コンテナー内の並列プリフェッチが制限されていることなどがあります。

使用法

使用法

使用法

このモニター・エレメントは、他の skipped_prefetch_uow_*_p_reads エレメントとともに、プリフェッチ要求が作成される原因となったものと同じ作業単位内のエージェントによって直接読み取られた、プリフェッチ要求内のページの数を示します。 システムに十分な数のプリフェッチャーが構成されていない場合、あるいは別のタイプのプリフェッチのボトルネックが存在する場合、エージェントが直接ディスクからページを読み取ることを余儀なくされることがあります。 例えば、ほとんどのワークロードが通常はトランザクションである OLTP システムでは、num_ioservers 構成パラメーターを 1 に設定することによって、プリフェッチャーの最小数を構成することができます。 しかし、表スキャンなど、プリフェッチを使用する操作が実行されると、単一のプリフェッチャーが処理を続行できない可能性があるため、エージェントはページを直接要求します。 この動作は、 本来プリフェッチャーが実行したはずの入出力に アプリケーションが対応することになるため、 パフォーマンスの低下を招く可能性があります。 この場合は、num_ioservers 構成パラメーターを調整して、プリフェッチャーの数を増やすことを検討してください。 他に考えられる原因としては、プリフェッチ・サイズが極端に大きいためにプリフェッチ時間が通常より長くなることや、db2_parallel_io レジストリー変数が設定されていないために表スペース・コンテナー内の並列プリフェッチが制限されていることなどがあります。

使用法

使用法

使用法

• 新しいページであったため、まだディスク上には作成されていなかった。
• 別のエージェントが同じページを必要としたため、 別のプリフェッチ要求によってバッファー・プールにロードされた。 この場合は、 上記のケースと同様、スキップされたプリフェッチ要求の増加は問題ではありません。 生成された追加のプリフェッチ要求が冗長だっただけだからです。
• プリフェッチャーがプリフェッチ操作を完了できるようになる前に、 エージェントが直接ディスクからページを取り出した。 システムに十分な数のプリフェッチャーが構成されていない場合、あるいは別のタイプのプリフェッチのボトルネックが存在する場合、エージェントが直接ディスクからページを読み取ることを余儀なくされることがあります。 例えば、OLTP システムでは、ワークロードの大部分が通常はトランザクションであるため、構成パラメーター num_ioservers を 1 に設定することによって、プリフェッチャーの最小数が構成される場合があります。 しかし、表スキャンなど、プリフェッチを使用する操作が実行されると、単一のプリフェッチャーが処理を続行できない可能性があるため、エージェントはページを直接要求します。 この動作は、 本来プリフェッチャーが実行したはずの入出力に アプリケーションが対応することになるため、 パフォーマンスの低下を招く可能性があります。 この場合は、構成パラメーター num_ioservers を調整して、プリフェッチャーの数を増やすことを検討してください。 他に考えられる原因としては、プリフェッチ・サイズが極端に大きいためにプリフェッチ時間が通常より長くなる場合や、db2_parallel_io レジストリー変数が設定されていないために表スペース・コンテナー内の並列プリフェッチが制限されている場合などがあります。

使用法

このエレメントと他のソート・メモリー最高水準点モニター・エレメントを組み合わせて使用すると、ソート・ヒープ・メモリー使用量が最も多いアクティビティーを判別できます。 例えば、現行アクティビティーのリストを取得するには、MON_GET_ACTIVITY 表関数を発行します。 sort_consumer_heap_top、sort_consumer_shrheap_top、sort_heap_top、および sort_shrheap_top モニター・エレメントの値を記録することにより、どのアクティビティーが最もソート・メモリーを使用するかを判別できます。 メモリー使用量の最も多いアクティビティーが他のアクティビティーに負の影響を与えている場合は、そのアクティビティーのメモリー所要量を減らすことで並行性を改善してください。

使用法

このエレメントと他のソート・メモリー最高水準点モニター・エレメントを組み合わせて使用すると、ソート・ヒープ・メモリー使用量が最も多いアクティビティーを判別できます。 例えば、現行アクティビティーのリストを取得するには、MON_GET_ACTIVITY 表関数を発行します。 sort_consumer_heap_top、sort_consumer_shrheap_top、sort_heap_top、および sort_shrheap_top モニター・エレメントの値を記録することにより、どのアクティビティーが最もソート・メモリーを使用するかを判別できます。 メモリー使用量の最も多いアクティビティーが他のアクティビティーに負の影響を与えている場合は、そのアクティビティーのメモリー所要量を減らすことで並行性を改善してください。

使用法

データベース・レベルまたはアプリケーション・レベルでは、この値と total_sorts を組み合わせて使用すると、ディスクにオーバーフローしたソートのパーセンテージを計算できます。 このパーセンテージが高い場合は、sortheap の値を大きくして、 データベース構成を調整する必要があります。

ステートメント・レベルでこのエレメントを使用すると、 大量のソートを必要とするステートメントを識別できます。 このようなステートメントは、 さらに調整を行って必要となるソート量を少なくすると効率が上がります。

ソートがオーバーフローすると、ソートにマージ・フェーズが必要となり、 データをディスクに書き込む必要がある場合は入出力がさらに必要となるので、 必要な処理時間が増えます。

このエレメントは、1 ステートメント、1 アプリケーション、 または 1 つのデータベースにアクセスするすべてのアプリケーションについて情報を提供します。

値が -1 の場合は、データ収集スイッチ DFT_MON_SORT がオフになります。

使用法

このエレメントは、アクティビティーが再マップされたサービス・クラスをたどるのに使用できます。 これを使用して、特定のサービス・サブクラスからマップされたアクティビティー数の総計を計算することもできます。

使用法

この値は、オブジェクト関連の表スペースに関してのみレポートされます。オブジェクト関連の表スペースとは、再利用可能なストレージで使用可能な表スペースです。 reclaimable_space_enabled モニター・エレメントを使用して、再利用可能なストレージに対して表スペースが使用可能かどうかを判別してください。

エクステント・マップ・ページ (EMP) はメタデータであるため、このモニター・エレメントの値には EMP が含まれています。

データ・スペース・マップ・ページにはユーザー・データが含まれているので、spacemappage_page_reclaims_x モニター・エレメントの値に入っていると同時に、page_reclaims_x モニター・エレメントの値にも含まれます。 索引スペース・マップ・ページにはユーザー・データが含まれていないので、spacemappage_page_reclaims_x モニター・エレメントの値にしか含まれません。

使用法

この値は、オブジェクト関連の表スペースに関してのみレポートされます。オブジェクト関連の表スペースとは、再利用可能なストレージで使用可能な表スペースです。 reclaimable_space_enabled モニター・エレメントを使用して、再利用可能なストレージに対して表スペースが使用可能かどうかを判別してください。

エクステント・マップ・ページ (EMP) はメタデータであるため、このモニター・エレメントの値には EMP が含まれています。

データ・スペース・マップ・ページにはユーザー・データが含まれているので、spacemappage_page_reclaims_s モニター・エレメントの値に入っていると同時に、page_reclaims_s モニター・エレメントの値にも含まれます。 索引スペース・マップ・ページにはユーザー・データが含まれていないので、spacemappage_page_reclaims_s モニター・エレメントの値にしか含まれません。

使用法

この値は、オブジェクト関連の表スペースに関してのみレポートされます。オブジェクト関連の表スペースとは、再利用可能なストレージで使用可能な表スペースです。 reclaimable_space_enabled モニター・エレメントを使用して、再利用可能なストレージに対して表スペースが使用可能かどうかを判別してください。

エクステント・マップ・ページ (EMP) はメタデータであるため、このモニター・エレメントの値には EMP が含まれています。

データ・スペース・マップ・ページにはユーザー・データが含まれているので、spacemappage_page_reclaims_initiated_x モニター・エレメントの値に入っていると同時に、page_reclaims_initiated_x モニター・エレメントの値にも含まれます。 索引スペース・マップ・ページにはユーザー・データが含まれていないので、spacemappage_page_reclaims_initiated_x モニター・エレメントの値にしか含まれません。

使用法

この値は、オブジェクト関連の表スペースに関してのみレポートされます。オブジェクト関連の表スペースとは、再利用可能なストレージで使用可能な表スペースです。 reclaimable_space_enabled モニター・エレメントを使用して、再利用可能なストレージに対して表スペースが使用可能かどうかを判別してください。

エクステント・マップ・ページ (EMP) はメタデータであるため、このモニター・エレメントの値には EMP が含まれています。

データ・スペース・マップ・ページにはユーザー・データが含まれているので、spacemappage_page_reclaims_initiated_s モニター・エレメントの値に入っていると同時に、page_reclaims_initiated_s モニター・エレメントの値にも含まれます。 索引スペース・マップ・ページにはユーザー・データが含まれていないので、spacemappage_page_reclaims_initiated_s モニター・エレメントの値にしか含まれません。

使用法

SQLCA データ構造体を使用すると、ステートメントが正常に終了したかどうかを判別できます。 SQLCA の内容については、 SQLCA (SQL 連絡域) または SQLCA データ構造を参照してください。

使用法

このエレメントを使用して、 SQLROWSREAD しきい値がアクティビティーに適用されていた場合、どのしきい値が適用されていたかを判別します。

使用法

このエレメントを使用して、SQLROWSREAD しきい値がアクティビティーに適用されている場合、その値を判別します。

使用法

このエレメントを使用して、アクティビティーに適用されていた SQLROWSREAD しきい値にアクティビティーが違反したかどうかを判別します。

使用法

このエレメントを使用して、 SQLROWSREADINSC しきい値がアクティビティーに適用されていた場合、どのしきい値が適用されていたかを判別します。

使用法

このエレメントを使用して、SQLROWSREADINSC しきい値がアクティビティーに適用されている場合、その値を判別します。

使用法

このエレメントを使用して、アクティビティーに適用されていた SQLROWSREADINSC しきい値にアクティビティーが違反したかどうかを判別します。

使用法

このエレメントを使用して、 SQLROWSRETURNED しきい値がアクティビティーに適用されていた場合、どのしきい値が適用されていたかを判別します。

使用法

このエレメントを使用して、SQLROWSRETURNED しきい値がアクティビティーに適用されている場合、その値を判別します。

使用法

このエレメントを使用して、アクティビティーに適用されていた SQLROWSRETURNED しきい値にアクティビティーが違反したかどうかを判別します。

使用法

このエレメントを使用して、 SQLTEMPSPACE しきい値がアクティビティーに適用されていた場合、どのしきい値が適用されていたかを判別します。

使用法

このエレメントを使用して、SQLTEMPSPACE しきい値がアクティビティーに適用されている場合、その値を判別します。

使用法

このエレメントを使用して、アクティビティーに適用されていた SQLTEMPSPACE しきい値にアクティビティーが違反したかどうかを判別します。

使用法

この数値は、db2expln コマンドを使用して取得可能なアクセス・プラン内のサブセクション番号に関連しています。

使用法

使用法

使用法

この ID は、各スタンバイを区別するために使用されます。 この ID はシステムによって生成されます。 ID からスタンバイへのマッピングは、照会ごとに変わる場合があります。 ただし、ID「1」は常にプリンシパル・スタンバイ (または単一スタンバイ・システムでは唯一のスタンバイ) に割り当てられます。 照会がスタンバイ・データベースに対して発行される場合、他のスタンバイは不可視になります。このような場合は、常に 0 が返されます。

使用法

より詳細なスタンバイ状況が得られるように、受信位置と適用位置が別々に報告されます。 スプーリングにより、受信位置と適用位置が大きく異なることが可能になります。 standby_log_pos は、受信位置を示しています。 primary_log_posと比較すると、standby_log_pos は、フェイルオーバー時のデータ損失のリスクを示します。 standby_replay_log_pos は、テークオーバーが受信したすべてのログの再生を完了する必要があるため、テークオーバー (強制および非強制) にかかる時間に影響します。 standby_replay_log_pos は、スタンバイで読み取られるデータがどの程度最新になるかも示します。 バージョン 9.7 以前では、報告されるスタンバイ・ログ位置が適用位置です。

使用法

ギャップはバイト数で測定されます。 通常、standby_recv_buf_size と standby_spool_limit の合計を超えることはありません。 柔軟なバッファー管理およびスプール管理により、その合計を少し超える可能性があります。 バッファーとスプールを合わせた限界にギャップが達すると、スタンバイはログの受信を停止し、ピア状態の 1 次がブロックされます。 また、報告された受信/適用ギャップがバッファーとスプールの合計より小さいときには、スタンバイでバッファーとスプールのスペースが不足している可能性があります。 部分ページが複数回にわたって送信され、バッファー内で複数ページのスペースを占有する可能性があるためです (ただしスプールでは常に 1 ページ)。 しかし、ログ・ギャップ計算では複数の送信が考慮に入れられません。

使用法

使用法

スプール制限が 0 (スプーリングが使用不可) である場合、NULL が戻されます。 スプール制限が -1 (スプーリングの制限なし) である場合、アクティブ・ログ・パス・サイズ内のスプールのページ番号のパーセンテージが戻されます。 スプールのパーセンテージが 100% に達した場合、スタンバイ・データベースは、適用が進んでスペースが解放されるまで、ログの受信を停止します。 スプール・デバイス (スタンバイ・ログ・パス) がフルになると、制限に達する前にスプーリングが停止する場合があります。

使用法

変更履歴イベント・モニターでは、対応するユーティリティー・イベント開始 (UTILSTART または UTILSTARTPROC) の固有 ID。 このエレメントを START_EVENT_TIMESTAMP およびメンバー・エレメントと併用して、停止レコードを、対応する開始レコードと関連付けます。

使用法

使用法

このエレメントを使用すると、この統計レコードが生成された時点を判別できます。

このエレメントと last_wlm_reset エレメントを組み合わせて使用すると、この統計レコードの統計が生成された時間間隔を識別できます。

このモニター・エレメントを使用すると、同じ収集間隔において生成されたすべての統計レコードをグループ化することもできます。

使用法

このエレメントを使用すると、現在の統計キャッシュのサイズを判別できます。 この値は頻繁に変わります。 システム使用量を評価するには、長期にわたり特定のインターバルを設けてスナップショットを取ってください。 このエレメントを使用すると、catalogcache_sz 構成パラメーターの値を調整できます。

使用法

このエレメントと stats_fabrications を組み合わせて使用すると、データベース・レベルのリアルタイム統計収集のパフォーマンスへの影響を評価できます。 動的 SQL のスナップショット・モニターの場合、このエレメントと total_exec_time および num_executions を組み合わせて使用すると、統計作成の影響を評価できます。 ステートメント・イベント・モニターの場合、このエレメントを stmt_start および stmt_stop と結合させて使用すると、リアルタイム統計収集の影響をさらに評価することができます。

使用法

このエレメントを使用すると、データベースの統計作成の頻度を判別できます。 この値は頻繁に変わります。 システム使用量の全体像をより正確に知るには、長期にわたり特定のインターバルを設けてスナップショットを取ってください。 このエレメントと stats_fabricate_time を組み合わせて使用すると、統計作成の影響を評価する助けになります。

使用法

このエレメントと rts_rows_modified モニター・エレメントを使用して、RUNSTATS コマンドの実行が必要かどうかを判別するのに役立てることができます。

TRUNCATE TABLE ステートメントが実行されると、このエレメントは表に対して TRUNCATE TABLE ステートメントが実行されるまで値 -1 を表示します。

使用法

ステートメントの完了にかかる時間の標識として、このエレメントを使用します。

このエレメントは、秒およびマイクロ秒 (100 万分の 1 秒) の単位で消費時間を報告する 2 つのサブエレメントで構成されています。 このモニター・エレメントの名前に「_s」と「_ms」を追加したものがサブエレメントの名前になります。 このモニター・エレメントの消費時間の合計を取得するには、2 つのサブエレメントの値を合計する必要があります。 例えば、「_s」サブエレメントの値が 3 で、「_ms」サブエレメントの値が 20 の場合、モニター・エレメントの消費時間の合計は 3.00002 秒です。

使用法

このエレメントを他のステートメント履歴項目と一緒に使用して、デッドロックの原因となった SQL ステートメントのシーケンスを見ることができます。

使用法

このエレメントを使用して、特定の SQL ステートメントが実行された呼び出しを一意に識別できます。 また、このエレメントを他のステートメント履歴項目と一緒に使用して、デッドロックの原因となった SQL ステートメントのシーケンスを見ることができます。

使用法

このエレメントを他のステートメント履歴項目と一緒に使用して、デッドロックの原因となった SQL ステートメントのシーケンスを見ることができます。

使用法

このエレメントを他のステートメント履歴項目と一緒に使用して、デッドロックの原因と、特定の SQL ステートメントの実行の動作を理解することができます。

使用法

このエレメントを stmt_invocation_id モニター・エレメントと一緒に使用して、特定の SQL ステートメントが実行された呼び出しを一意に識別できます。 また、このエレメントを他のステートメント履歴項目と一緒に使用して、デッドロックの原因となった SQL ステートメントのシーケンスを見ることができます。

使用法

このエレメントを使用すると、実行中の操作または最後に終了した操作を判別できます。

以下のいずれかになります。

使用法

複数パーティション環境では、各パーティションに、キャッシュされたステートメントに対する固有のステートメント ID があります。 特定のステートメントが、複数のパーティションにわたって同一の ID を持つことはできません。

グローバルな動的 SQL スナップショットでは、最初のステートメント ID のみが戻されます。

使用法

このエレメントを stmt_nest_level モニター・エレメントと一緒に使用して、特定の SQL ステートメントの呼び出しを固有に識別できます。 また、このエレメントを他のステートメント履歴項目と一緒に使用して、デッドロックの原因を理解することもできます。

使用法

このエレメントを appl_id モニター・エレメントと一緒に使用して、特定の SQL ステートメントの実行要求の発信元を固有に識別できます。 また、このエレメントを他のステートメント履歴項目と一緒に使用して、デッドロックの原因を理解することもできます。