64ビット時代の「バランスド・システム」：真・Dr. K's SQL Serverチューニング研修（5）（1/3 ページ）

64ビットシステムの増加で見えてきた新たな問題

　第2回で「バランスド・システム」の考え方をご紹介しました。SQL Serverの内部動作を理解し、ハードウェアとOSの知識を得て、SQL Serverが最も動作しやすいハードウェアを構成するという考え方です。

　SQL Serverの本当の性能を引き出すには、アプリケーションが出来上がって、動かしてみてから「遅いな」と感じて試行錯誤でクエリを修正してみるということではいけません。アプリケーションを作り始める前の段階、アプリケーションを動かすハードウェアを用意するところから気を付けなければならないのです。

　今回は、第2回では詳しく紹介できなかったメモリ容量の見積もり方を解説します。特に、SQL Serverの主流が32ビット（x86）版から64ビット（x64）版に変わって問題になってきたところ、言い換えればSQL Server 2000から、2005、2008、2008 R2に移行するときに発生しやすい問題に焦点を当てます。

キャッシュに入るデータを意識する

　バランスド・システムの考え方を解説した第2回では、64ビットのアドレス空間では、最大1Tバイトのメモリ空間のすべてを、さまざまなキャッシュが共有するため、単純にメモリ空間を64ビットに移行しただけでは、キャッシュ同士の競合（バッファーキャッシュとプロシージャキャッシュ）が発生する可能性があるということを説明しました。

　この事実を踏まえて、メモリのベストプラクティスとして「ユーザーデータベース容量の5〜10％をバッファキャッシュとして用意する」というポイントをご紹介しました。具体的に言うと、NUMAのシステムなら、各ノードごと（各プロセッサソケット）に最低8GBのメモリ（できれば16GB）を、SMPシステムの場合はプロセッサコアあたり最低4GBのメモリを用意しておきましょうということです。

　そして、アドホック（使い捨ての）クエリとプリペアードクエリが多いときは、メモリを大量に消費するとも説明しました。しかし、最適なメモリ容量を導き出すには、キャッシュの種類と、それぞれにどんなデータが入るのかというところから考える必要があります。

　バッファキャッシュには、主にデータベース上のデータページとインデックスページのデータが入ります。同じ結果を繰り返しユーザーに返すようなときは、このキャッシュからデータを返すことで、処理性能を上げているのです。第2回では、このキャッシュのために、ユーザーデータベース容量の5〜10％をバッファキャッシュとして用意すべきと説明しました。

　しかし、最適なメモリ容量を導き出すには、バッファキャッシュの容量を考えるだけでは足りません。第2回では説明できませんでしたが、プロシージャキャッシュの容量も大きなポイントとなるのです。そして、プロシージャキャッシュの容量を考えるには、その中にどんなデータが入るのかを理解する必要があります。

　プロシージャキャッシュに入るデータは大きく2つに分けられます。1つ目は「オブジェクトプラン」。これはストアドプロシージャや関数、トリガーといった、再利用可能なクエリを指します。

　2つ目は「SQLプラン」です。これはクエリの実行プランのことで、アドホッククエリや「パラメータ化クエリ」の実行プランを蓄積しています。パラメータ化クエリとは、クエリの中から変動する数値の部分を変数のようにして、コンパイルしたクエリを指します。実行するたびに、ユーザーが指定した数値を当てはめて実行しますが、再コンパイルは必要ないというものです。