S

使用法

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

使用法

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

使用法

使用法

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

使用法

静的 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 の通信速度を調整するときに役に立ちます。 これらのパラメーターを変更すると、 オプティマイザーが要求をデータ・ソースに送信するかしないかに影響を与えます。

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

使用法

使用法

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

使用法

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

使用法

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

使用法

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

使用法

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

使用法

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

使用法

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

使用法

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

使用法

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

使用法

使用法

使用法

使用法

使用法

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

使用法

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

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

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

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

使用法

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

使用法

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

使用法

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

使用法

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

使用法

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

使用法

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

使用法

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

使用法

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

使用法

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

使用法

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

使用法

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

使用法

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

使用法

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

使用法

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

使用法

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

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

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

使用法

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

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

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

使用法

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

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

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

使用法

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

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

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

使用法

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

使用法

使用法

使用法

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

使用法

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

使用法

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

使用法

使用法

スプール制限が 0 (スプーリングが使用不可)、または -1 (スプーリングの制限なし) である場合、NULL が戻されます。スプールのパーセンテージが 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 を組み合わせて使用すると、統計作成の影響を評価する助けになります。

使用法

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

このエレメントは、秒およびマイクロ秒 (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 ステートメントの実行要求の発信元を固有に識別できます。また、このエレメントを他のステートメント履歴項目と一緒に使用して、デッドロックの原因を理解することもできます。

使用法

アプリケーション・スナップショットの場合は、 このステートメント・テキストに基づいて、 スナップショットを取った時点でアプリケーションが何を実行していたかを識別できます。 またスナップショットを取った時点でステートメントが処理されていなかった場合は、 最後に処理されたものを識別できます。

このエレメントが戻す情報は、SQL ステートメント・キャッシュから取り出されるので、 キャッシュがオーバーフローした場合は情報は得られません。 ステートメントの SQL テキストを必ずキャプチャーするには、 ステートメントのイベント・モニターを使用してください。

動的 SQL ステートメントの場合は、 このエレメントを使用してパッケージに関連付けられた SQL テキストを識別します。

ステートメント・イベント・モニターの場合、このエレメントは動的ステートメントについてのみ戻されます。 ステートメント・イベント・モニター・レコードがステートメント・イベント・モニターの BUFFERSIZE オプションで指定されたバッファーのサイズに収まらない場合には、レコードが収まるように stmt_text モニターの値が切り捨てられることがあります。

EVENT_STMT_HISTORY イベント・モニターの場合、このエレメントは動的ステートメントについてのみ戻されます。 残されたイベント・モニターの場合、動的ステートメントと静的ステートメントの stmt_text は、SQL ステートメント・キャッシュ内で使用可能な場合にのみ戻されます。

パフォーマンスを考慮したために静的 SQL ステートメント・テキストが提供されない場合、これを取得するためにシステム・カタログ表を照会する方法については、section_number モニター・エレメントを参照してください。

使用法

使用法

使用法

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

使用法

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

使用法

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

使用法

このエレメントを提供されたコンパイル環境と一緒に使用して、SQL コンパイラーによる SQL ステートメントの処理を完全に分析できます。

使用法

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

使用法

静的 SQL ステートメントの場合、 この値は SYSCAT.STATEMENTS カタログ・ビューで使用されているものと同じです。

使用法

使用上の注意

• ADMIN_GET_STORAGE_PATHS 表関数を使用している場合、 ストレージ・グループ ID は、ストレージ・パスが定義されているストレージ・グループを示します。
• MON_GET_TABLESPACES 表関数を使用している場合、 ストレージ・グループ ID は、表スペースが定義されているストレージ・グループを示します。

使用上の注意

• ADMIN_GET_STORAGE_PATHS 表関数を使用している場合、 このモニター・エレメントは、ストレージ・パスが定義されているストレージ・グループを示します。
• MON_GET_TABLESPACES 表関数を使用している場合、 このモニター・エレメントは、表スペースが定義されているストレージ・グループを示します。

使用法

宣言されるプロシージャーには親と同じ外部 ROUTINE_ID 値があるので、このエレメントを使用してそれらを区別します。

使用法

このモニター・エレメントを使用すると、データベースのリアルタイム統計収集により起動された同期 RUNSTATS アクティビティーの数を判別できます。 この値は頻繁に変わります。 システム使用量をより正確に知るには、長期にわたり特定のインターバルを設けてスナップショットを取ってください。 このエレメントと sync_runstats_time を組み合わせて使用すると、リアルタイム統計収集により起動された同期 RUNSTATS アクティビティーのパフォーマンスへの影響を評価する助けになります。

使用法

このエレメントと sync_runstats を組み合わせて使用すると、データベース・レベルでリアルタイム統計収集により起動された、同期 RUNSTATS アクティビティーのパフォーマンスへの影響を評価できます。

動的 SQL のスナップショット・モニターの場合、このエレメントを total_exec_time および num_executions と組み合わせて使用すると、同期 RUNSTATS の照会パフォーマンスへの影響を評価できます。

ステートメント・イベント・モニターの場合、このエレメントを stmt_start および stmt_stop と組み合わせて使用すると、リアルタイム統計収集の影響をさらに評価することができます。

使用法

このエレメントと CPU 時間に関連する他のエレメントを組み合わせて使用すると、 アプリケーション内のアクティビティーのレベルがわかります。 また、さらに調整するとその効果が得られる可能性があるアプリケーションを識別できます。