SQL CLR ストアド プロシージャにおける読み取り専用のカーソルのパフォーマンスの最適化

SQL CLR ストアド プロシージャで読み取り専用のカーソルのパフォーマンスを最適化するには、OpenESQL がそれらのストアド プロシージャをどのように処理しているかを理解する必要があります。SQL CLR ストアド プロシージャでは、複数のアクティブな結果セット (Multiple Active Result Sets; MARS) 指令を使用できないため、アクティブな結果セットを処理するために回避策を提供するよう OpenESQL に要求します。実装されるソリューションは、Visual COBOL のバージョンに応じて異なります。

Enterprise Developer 2.1 の Hot Fix 8 以降では、OpenESQL は、SQL CLR ストアド プロシージャでのスクロール不可能な読み取り専用の COBOL カーソルに DYNAMIC サーバー カーソル オプションではなく、FAST FORWARD を使用するようデフォルト設定されています。通常、FAST FORWARD カーソルにより、動的カーソルよりも優れたクエリ アクセス プランが生成されますが、クエリ プランの効率はファイアホース カーソルほど高くない場合があります。

このシナリオでは、OpenESQL DATASET カーソルに切り替えることで、サーバー カーソルを完全に使用することを回避できます。この変更により、DECLARE CURSOR 文自体のコード変更が分離されます。ただし、この方法では、ストアド プロシージャで使用されるメモリに結果セット全体が格納されるという欠点があります。結果セットが大きい、または多くのクライアントから同時にプロシージャが呼び出された場合、これにより、カーソルが開いている間に SQL Server のメモリを消費する可能性があります。さらに、DATASET カーソルが読み取り専用のカーソルに制限されていない間は、これらのカーソルをロックできません。つまり、ペシミスティック同時実行を使用できません (位置付け UPDATE が引き続きサポートされている場合でも)。これにより、アプリケーション ロジックが失敗する可能性があります。

OPTION=OPTIMIZESPCURSORS 指令、または Enterprise Developer 2.2 Update 1 以降の場合は OPTIMIZESPCURSORS 指令を使用することで、コード変更を完全に回避することができます。この場合、OpenESQL はファイアホース カーソルを開きます。カーソルを閉じる前にその他のデータベース アクセスが発生した場合、OpenESQL によって結果セットの残りの部分が DATASET カーソルに変換されます。

次の表に、オプションをまとめます。