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

潜んでいる問題にどうアプローチするか

　私がお客様のSQL Server環境を見せてもらうとき、何をしているのかをよく聞かれます。ほとんどの場合、事前にデータベース環境と領域利用状況、インデックス定義などを取得するスクリプトをお客様に渡し、データを取得します。

　お客様が最も監視してほしい時間帯を2時間ほど設定していただき（通常は本稼働環境の最もトランザクション負荷の高い時間帯）、パフォーマンス測定ツール（Quest SoftwareのSpotlight on SQL Server）、動的管理ビュー（DMV／DMF）を用いてデータを取得し、2週間程度の時間をかけて解析の作業に入ります。今回は、その動的管理ビューのデータの「どこをみているのか？」を解説しましょう。

やはり重要、RDBエンジンの内部動作

図1　SQL Serverの内部構造（クリックで拡大します）

　図1は、SQL Server 2008 R2の内部構造をブロックで表したものです。前回までにお話しした2つのチューニングステップのうち、第1フェイズのクエリーチューニングは、この図のクエリープロセッサ（リレーショナルエンジン）部分に対するチューニングです。第2フェイズのプラットフォームチューニングはストレージエンジン部分に対するものです。このストレージエンジンの挙動を知ることが、チューニングを体系的に理解する第1歩です。

　リレーショナルエンジンはCATチームの専門家、ドクター・ルバー・コラー（Dr. Lubor Kollar）氏が最も得意とする分野です。ここにはパーサがあり、オプティマイザがあり、コンパイル結果をプロシージャキャッシュに保存し、クエリー・エグゼキュータがコンパイル後の、複数ステップで構成される実行プランを基に実行するわけです。

　SQLOSが管理するプロシージャキャッシュに保存された実行プランは、再利用可能なものとアドホックなものに分けられます。再利用可能な実行プランは、オプティマイザやパーサ、コンパイラを通さず、すぐに実行が可能です。つまり、「再実行が可能」なプランに落とし込めるようなアプリケーションの作り方が重要になります。皆さまには当たり前のことかもしれませんが、これをもう一度認識しておきましょう。

　第2ステップであるプラットフォームチューニングのポイントは、ストレージエンジンのコンポーネントをきちんと理解することです。例えばトランザクションサービスは、トランザクションのACIDプロパティの保証や、同時に実行しているユーザ間のアイソレーション（分離レベル）をコントロールします。また、ロックマネージャはロックとラッチと呼ばれる2つの排他制御をつかさどっています。ロックはトランザクション完了まで継続的に保持されるもの、ラッチはストレージエンジン内部処理で使われる、リカバリ処理をしないものです。この2つを理解することは、チューニング作業を行う上で大変重要です。

　ロックについては、アプリケーションのアーキテクチャに起因するものですので、ダーティリードをどこまで許すか、SQL Server 2005からの機能であるリードコミッテッドスナップショットアイソレーション（RCSI）を利用するなど、アプリケーション側の対策で回避できます。

　今回はストレージエンジンの内部動作に起因する、SQL Serverの「ラッチ」をチェックしていきましょう。