ストアード・プロシージャーとユーザー定義関数のパフォーマンスの向上

特定の推奨事項に従うことにより、ストアード・プロシージャーとユーザー定義関数のパフォーマンスを向上できます。

プロシージャー

ストアード・プロシージャーとユーザー定義関数のパフォーマンスを向上するには、次の推奨事項のいずれかを使用します。

  • SYSIBM.SYSROUTINES カタログ表の ASUTIME 列を更新し、各ストアード・プロシージャーまたは関数のプロセッサー限度を設定します。
    指定する制限値により、Db2は、ループするプロシージャーまたは関数を取り消すことができます。
  • ストアード・プロシージャーの異常終了回数を制限するため、次のいずれかのオプションを指定します。
    • インストール・パネル DSNTIPX の MAX ABEND COUNT フィールド。 指定する限度はすべてのストアード・プロシージャーに適用されます。この限度によって、問題のプロシージャーが原因で生じる異常終了ダンプ処理のためにシステムが妨害されることを回避します。
    • ALTER または CREATE PROCEDURE ステートメントの STOP AFTER FAILURES オプション。 指定する限度によって MAX ABEND COUNT フィールドに指定されているシステム限度がオーバーライドされ、特定ストアード・プロシージャーの限度が指定されます。
  • WLM が確立したストアード・プロシージャー・アドレス・スペースで並行実行できるプロシージャーまたは関数の数を最大化するには、次のようにします。
  • ストアード・プロシージャーのパフォーマンスを向上されるためにWLM速度ゴールを設定します。
    詳細は、「 z/OS Workload Manager の速度目標の設定 」を参照してください。
  • WLM アプリケーション環境でストアード・プロシージャーをグループにまとめます。
    詳細は、「アプリケーション環境の定義 」を参照してください。
  • プログラムで標識変数を使用し、この標識変数をパラメーターとして渡します。
    出力パラメーターが大量のストレージを占有する場合、ストレージ域全体をストアード・プロシージャーに渡すことは無駄な操作であることがあります。 ただし、呼び出し側プログラムで標識変数を使用して、ストアード・プロシージャーに 2 バイトの領域のみを渡し、ストアード・プロシージャーから領域全体を受け取ることができます。
  • WLM により管理されるストアード・プロシージャー・アドレス・スペースに高い優先度を設定します。
  • CREATE PROCEDURE ステートメントにパフォーマンス関連オプションを適切に設定します。
    次の表に、推奨値を示します。
    表 1. CREATE PROCEDURE ステートメントのパフォーマンス関連オプションの推奨値
    オプション 推奨される設定値
    PROGRAM TYPE SUB
    STAY RESIDENT はい
    PARAMETER STYLE GENERAL WITH NULLS または SQL
    COMMIT ON RETURN ローカルに呼び出されるストアード・プロシージャーの場合は NO、Sysplex ワークロード・バランシングが使用されていない環境の分散クライアント・アプリケーションから呼び出されるストアード・プロシージャーの場合は YES。
  • ストアード・プロシージャー・アドレス・スペース開始プロシージャーでは、DSNTRACE DD ステートメントは使用しないでください。 DSNTRACE は、オフラインの参照および診断のためにすべてのトレース・メッセージを収集するために使用する機能です。 ただし、DSNTRACE を使用するとストアード・プロシージャー初期化のオーバーヘッドが大幅に増加します。 また、マルチタスキング環境では DSNTRACE は機能しません。これは、CAF は DSNTRACE トレース・データ・セットへのアクセスを直列化しないためです。
  • DSNTIP インストール・パネルで CACHERAC サブシステム・パラメーターに十分大きな値を指定します。
    CACHERACパラメーターは、メンバー上のDb2のルーチンについて、ルーチン許可情報のキャッシングに割り振るストレージの量を指定します。
  • CMTSTAT サブシステム・パラメーターを INACTIVE に設定します。
    この設定により、可能な場合はコミット時に分散スレッドが非アクティブになります。 非アクティブ・スレッドは、スレッド再利用の対象となります。このため、分散アクティブ・スレッドの数を減らすことで、ワークロードに必要なスレッド・ストレージの量が減ります。
  • 新しいアドレス・スペースを開始するためのコストが非常に高い環境の場合は、MNSPASサブシステム・パラメーターを設定して、開始および保守するアドレス・スペースの最小数を指定します。
  • 可能な限り、外部ストアード・プロシージャーをネイティブ SQL プロシージャーに変換します。
    ネイティブSQLプロシージャの本体はSQLで記述され、 Db2 はネイティブストアドプロシージャに関連するCプログラムを生成しません。 ネイティブ SQL プロシージャーは、より完全にサポートされており、保守が容易であり、通常は非推奨の外部 SQL プロシージャーよりも効率よく実行されます。
  • 外部ストアード・プロシージャーおよび外部関数のワークロードを慎重に調べます。
    IBM® OMEGAMON® for Db2 Performance Expert on z/OS® を使用して、ストアドプロシージャとユーザー定義関数を監視することができます。
  • ストアード・プロシージャーを含むロード・ライブラリーに対し、拡張区分データ・セット (PDSE) メンバーを使用します。
    PDSE メンバーを使用することで、ロード・ライブラリーの容量の増大に伴うストアード・プロシージャー・アドレス・スペースの停止および開始の必要性を解消できる可能性があります。これは、新規エクステント情報が動的に更新されるためです。 追加や置換によりロード・ライブラリーが大きくなった場合は、ライブラリーを拡張する必要があります。 区分データ・セット (PDS) メンバーを使用する場合、新しいエクステント情報が使用できないためにロード障害が発生することがあります。