ODBCを使用して SQLSetStmtAttr
を使用してSQL Server 2012データベースにアクセスし、SQL_SOPT_SS_CURSOR_OPTIONS
オプションをSQL_CO_FFO
に設定しているアプリケーションがあります。これは、 DBからの読み取りは、早送り専用カーソルによってバックアップされます。
これはOkほとんどの場合ですが、早送り専用カーソルのパフォーマンスは、「通常の」静的カーソル(取得するカーソル)よりも大幅に低い場合があります。デフォルトではSQL_CO_OFF
)。
質問:SQL Serverに早送りカーソルを使用しないように強制する方法はありますか?
明らかに、適切な方法はアプリケーションを変更することであり、そのプロセスは途中ですが、時間がかかります。その間、一時的な回避策を探しています。
これまでのところ、私が持っている唯一のアイデアはこれを使用することです:(from Fast Forward-only Cursors )
早送り専用カーソルの暗黙的な変換
早送り専用カーソルは、次の場合に暗黙的に他のカーソルタイプに変換されます。
- SELECTステートメントが1つ以上のテーブルをトリガーテーブル(INSERTED/DELETED)と結合する場合、カーソルは静的カーソルに変換されます。
ただし、一時的な回避策としても、それは少し醜いようです。より良いアプローチはありますか?
補足:この場合、早送りのみのカーソルのパフォーマンスが低下する主な理由は、 並列処理をサポートしていません 。
非早送りの場合sys.dm_exec_cursorsは私に:
API |スナップショット|読み取り専用|グローバル(0)
早送りオプションは次のとおりです。
API | Fast_Forward |読み取り専用|グローバル(0)
スナップショットオプションは、早送りオプションの5倍高速です。両方のクエリプランを見ると、DegreeOfParallelismを除いて、それほど違いはありません。スナップショットは16で、早送りは0です。問題は、ビューから読み取っている(制御があまりできない)ことであり、これらのビューの設計は最適ではありません。
いいえ、私が知る限り、サーバー側で早送りカーソルを無効にすることはできません。
アプリケーションが早送りカーソルを要求した場合、少なくとも「最新」バージョンのSQL Server(2005以降)では、それが取得されます。 From 暗黙のカーソル変換の使用 :
早送りカーソルは変換されません。
このシナリオの以前のSQLServer 2000で何が機能したか、または機能しなかったかをずっと忘れていました。参照するドキュメント内の暗黙的な変換ケースの1つを、一時的に機能させることができる場合があります。
現代の世界に戻りましょう。早送りカーソルは 静的または動的なプランにコンパイルする の場合がありますが、どちらの場合も非並列プランのみを生成するという制限が残ります。
一般に、すべての状況で許容できるパフォーマンスを発揮する単一クラスのカーソルまたはオプションのセットはありません。最高のパフォーマンスを得るには、カーソルのタイプとオプションセットをケースごとに評価する必要があります。