内部動作を知らずしてチューニングは語れない：真・Dr. K's SQL Serverチューニング研修（3）（3/3 ページ）

Latch

　最後に、Latchについて説明しましょう。Latchの最も代表的な振る舞いは、tempdbデータファイルから、セッション内で利用する一時ワークテーブル領域を取得するために、グローバルアロケーションマップ（GAM）を一時的に排他制御（ラッチ処理）するためにかけるものです。これは、tempdb（一時表領域）を用いた内部動作に起因します。

　例えばorder by句やgroup by句を使ったselect文を実行すると、一時表領域を利用して処理が行われます。作業用の一時テーブル用に8kバイト×8ページのエクステントが使われるのですが、これは各一時表領域に存在するGAMの値をもとに、新規に割り当てを行います。これがLatchです。

　ストレージエンジンは、セッション内で利用する一時ワークテーブル領域を取得するとき、必ずGAMを参照して、利用可能なエクステント領域を決定します。もしtempdbデータファイルが複数存在すれば、最も空き領域サイズの大きなtempdbデータファイルから領域を取得します。そのため、複数用意しているすべての表領域の初期サイズと自動拡張のパラメータを合わせ、かつその数をCPUコアの数、正確にいうとCPUコアと1：1に関連付けられた「スケジューラの数」とtempdbのデータファイル（一時表領域）の数を合わせれば、Latchは最小限になります。

図4　tempdbの設定例。CPUコア数（スケジューラ数）と同じ数だけ用意する（クリックで拡大します）

　この3つのラッチを把握することで、第一段階の問題把握ができるはずです。お客様の環境で本番稼働しているデータベースの動的管理ビューを2時間データ取得し、その結果を「page関連のラッチ」に関するwaittimeをもとにソートし、上位にあるラッチをチェックするのが最初の仕事です。そのあと、ラッチに関する設定を変更し、動的管理ビューの数値を比較するというわけです。

　今回挙げたラッチは、実はそんなに「隠れた」ものではなく、基礎に近いものです。この情報を教えてくれたのもCATのメンバーでした。最初にこの一連の調査を横で見たとき、感動を覚えるほどでした。これらのラッチに関する情報は、データベース物理ファイルがきちんと設計されているか、パラメータはおかしくないかなど、データベース管理者の「手腕」を一目で判断できる、ちょっと怖いデータでもあります。

CAT直伝のスクリプト、公開

　では、このようなデータベースチューニングのためのデータはどうやって取ればいいのでしょうか。今回はCAT直伝のドキュメントとスクリプトを公開しましょう。といっても、これらは一子相伝で門外不出なわけではなく、広く公開されているものです。

　こちらが、CATチームが公開したドキュメント群です。英語のものしかありませんが、技術者にとっては無理やりな日本語訳をするよりも読みやすいかもしれません。このインデックスをみても分かるように、リソースのボトルネックはどこにあるのか？ CPUのボトルネックをどう見つけるか？ 実行時間の長いクエリーをどうすべきかなど、場数を踏んだCATならではのノウハウをまとめた、素晴らしいドキュメントです。

　これに合わせ、CATチームは動的管理ビューを目的別にデータ取得するスクリプトを用意しています。これはトム・デビットソン氏が中心に作ったもので、インデックスの利用状況のチェックや使ってないインデックスの把握など、I／O周りの確認が充実したスクリプト群です。

　このスクリプトは実際に活用することももちろんですが、ぜひこの中身をみて、何をどう取得しているのかも併せて把握するといいでしょう。CATはスクリプトにしっかりとコメントも残しています。このスクリプトはノウハウの固まりですので、中身もみることで一段上のエンジニアになれること間違いなしです。ぜひ、読むことをおすすめします。