DO’s&DONT’s #10: やらない方がいいこと – クエリの条件句で変数を参照する

神谷 雅紀 Escalation Engineer   クエリの WHERE 句や JOIN ON 句など、クエリのフィルタ条件や結合条件で変数を参照すると、クエリのパフォーマンスが悪化する (実行時間が長くなる) 可能性が高まります。   なぜ?   必ずしも最適ではない実行プランが生成される可能性 SQL Server は、クライアントから送信されてくるバッチ (クライアントから送信されてくるひとつ以上のステートメントの塊) をコンパイルし、バッチ内の各ステートメントの実行プランを生成し、その後、そのバッチを実行します。実行プランの生成過程であるクエリの最適化 (optimization) では、クエリの検索条件や結合条件などを参照し、最も低コストであると考えられる実行プランを選択します。クエリの検索条件や結合条件は、実行プランの選択に大きな影響を与えます。しかし、変数は、最適化の段階では未知の値です。 以下の例を見てみます。 declare @x nvarchar(10) set @x = N’ABC’ select * from tab where col1 = @x go このバッチは、declare, set, select の 3 ステートメントから構成されています。このバッチの実行が要求されると、まず、これら 3 ステートメントがコンパイルされます。select については、実行プランが生成されます。この実行プランの生成時、@x の値は未知です。なぜならば、@x の値が決定するのは、バッチのコンパイルおよび select の最適化が終わって、実際にこのバッチが実行され、set ステートメントが実行完了した後だからです。select…

5

SQL PASS Summit 2011 at Seattle

今年もシアトルでSQL PASS Summit 2011が開催され、世界52カ国から5,108人のSQLに携わる人が集まりました。セッションは170以上設けられ、Denaliの新機能やSQL AzureのDBサイズ制限が現在の50GBから3倍の150GBまで増加される予定も発表されました。Bob Ward の Inside TempDB は3時間のコースで目玉でした。Tempdbのファイル数が物理CPUの数と一致した場合に劇的なTempDBのパフォーマンスの向上が見られることは以前から知られていましたが、具体的に個数を変化させてパフォーマンス計測を行った結果と、トレースフラグ-T1118を組み合わせた場合ついての考察が紹介されました。(トレース フラグ –T1118 を使うことでExtentの割り当て方法を変更させることができます。詳細はここをご覧ください。) また、Microsoftカスタマー・サービスでは毎年開催しているSQL関連何でも質問コーナー:SQL Clinicを今年も設けました。参加者なら無料で何回でも質問できるので、今年もたくさんの人がERRORLOGやダンプファイル持参で訪れました。SQL Clinicについては、Bob Wardの下記の記事もご覧ください。 Inside SQL Clinic さらにSQL Server MVPによるノウハウが満載な本も紹介されました。SQL Server MVP Deep Dives SQL Server MVP Deep Dives, Volume 2  PASSについての詳細はhttp://www.sqlpass.org/ をご覧ください。なお、来年のPASS Summit 2012 はNov 6-9, 2012 にシアトルで開催される予定です。——Kayoko GraySenior Support Escalation Engineer

0

実行プランを読む – 基本編 (その 3)

  神谷 雅紀 Escalation Engineer   ビューカウントが少なかったので途中終了した「実行プランを読む」ですが、一部の方々からもうしばらく続けて欲しいという要望がありましたので、再開することにしました。 実行プランを見て、そのクエリがどのように実行されているのかを確認する際に、Stop and Go オペレータとともに注意する必要のある動きが Rebind と Rewind です。実行プランを読む – 基本編 (その 1), 実行プランを読む – 基本編 (その 2) に加えて、今回の内容を知っていれば、実行プランを見ることでクエリがどのように動くのかを理解することができるようになると思います。   Rebind と Rewind Rewind とは、データセット内の現在位置を最初の行に戻す動作です。その名の通り、巻き戻し (rewind) です。これに対して Rebind は、ある条件でオペレータが実行された後、再度別の新しい条件で実行されるとともに、行位置を新しい条件によるデータセットの最初の行に移動する動作です。オペレータに新しいパラメータを結び付け直し (rebind)、再実行します。Rebind と Rewind は、どちらも Nested Loops の inner input (実行プラン表示の下側の入力) のみで行われる動きです。   Rebind/Rewind 回数の確認方法 SET SHOWPLAN_XML や SET STATISTICS PROFILE…

1

断片化について

  神谷 雅紀 Escalation Engineer   断片化とは? 一般的に、断片化と言われる状況は、平均ページ密度 (average page density) が低い状況か、または、論理スキャンフラグメンテーション (logical scan fragmentation) の値が低い状況です。   平均ページ密度とは? 平均ページ密度とは、あるテーブルもしくはインデックスに関して、1 ページ (8KB) に、平均どの程度データが詰まっているのかを表しています。値が小さいほど断片化の度合いが大きいことを示しています。 例えば、平均ページ密度が 90% であれば、1 ページ 8KB の 90%、つまり、約 7.2KB はデータを格納するために使用されており、残りの 0.8KB が空きということになります。この場合、1 行のサイズが 0.8KB 未満であれば、このページにもう 1 行入る可能性がありますが、それ以上の大きさであれば、このページにはもう新しい行は入らないので、ページ密度は 90% が最大ということになります。このように、平均ページ密度は、必ずしも 100% にはなりません。 平均ページ密度は、DBCC SHOWCONTIG コマンドの出力に含まれている「平均ページ密度 (Avg. Page Density)」、または sys.dm_db_index_physical_stats のavg_page_space_used_in_percent で確認することができます。 尚、ページ密度は、インデックスを新規作成したり、再構築したりする場合であれば、FILLFACTOR によって指定可能な値です。   平均ページ密度が低いと何が起こるのか?…

0