パフォーマンスを語るために歴史を語ろう：真・Dr. K's SQL Serverチューニング研修（1）（2/3 ページ）

日本におけるSQL Serverコンサルタントの第一人者、熊澤幸生氏によるSQL Server詳説シリーズが帰ってきました。2008 R2に至るまでの歴史を振り返り、その先の世代に向けた展望までも語ります（編集部）

[熊澤幸生，株式会社 CSK Winテクノロジ]

ハードウェアの壁——第2世代の問題点

　そして第3世代、バージョン番号でいうと2005／2008／2008R2では、第2世代で完了した「あるべきRDBMSの姿」への変革を、ハードウェアの進化へ対応させました。最も大きな変化は、x64アーキテクチャ(64ビットアドレス方式)への本格移行です。これにより、従来よりもシンプルなメモリ管理が実現できるようになりました。そのほかにもNUMA（Non-Uniform Memory Access）対応やDMV(動的管理ビュー)もこの時点で行われています。

【関連記事】
NUMA（Non-Uniform Memory Access、Non-Uniform Memory Architecture）
http://www.atmarkit.co.jp/icd/root/77/44603477.html

　ここで第2世代までのメモリ管理を説明しておきましょう。第2世代のころ、ハードウェアはXeon CPUを4ソケット、メモリ16GB、ストレージはSCSIディクスを10-20ボリュームRAID5 で構成し、全体の容量は150GBくらいでしょうか。このころのアーキテクチャ、IA32ではメモリの最大量は4GBでした。いまから見ると4GBはクライアントPCでも使い切ってしまうレベルの量ですね。サーバの、それもデータベースのエンジンから見たら大変狭い領域です。第2世代ではこの4GBの壁を突破するために、AWE（Address Windowing Extensions）という仕組みを使っていました。

図1　AWEを利用したときのメモリ空間（32ビットアドレス変換レジスタを4ビット拡張することで、AWE空間を実現した）

　AWEとは、巨大な物理メモリの一部をユーザーメモリ空間内のウィンドウにマッピングし、ページを切り替えることで、最大64GBのメモリを利用する機能でした。32ビットのアドレス変換テーブルを4ビット拡張し、この4ビットでメモリのぺージングを管理します。昔からのPCユーザーには、MS-DOS時代にお世話になった640kbの壁を突破する仕組み、「EMS」を思い浮かべると分かりやすいかもしれません。

【関連記事】
Dr. K's SQL Serverチューニング研修（2）
誰も知らないメモリ・チューニングの極意を教えよう
http://www.atmarkit.co.jp/fdb/rensai/drk02/drk02_1.html

　AWEによって、テラバイト級のDWHなどにもSQL Serverが利用されるようになりました。ところがこのAWE、SQL Serverの最上位エディションであるEnterprise版にしか使えなかったのです。そればかりか、設定もGUIからは行えず、コマンドラインから設定を変更する必要がありました。まさに知る人ぞ知るオプションです。そのため、メモリをふんだんに搭載しているにもかかわらず、4GB分しか利用していないというお客様が多くいたことを思い出します。

　正直、これではまずいよね、と私は思っていました。それがあって私自身がチューニングサービスをはじめたものの、開発チームとの連携も薄く、解析のためのツールがほとんどありませんでした。パラメータを1つずつ調整してはチェック、調整してはチェックというトライアンドエラーが続き、大変時間と手間のかかる作業だったことを思い出します。

　第3世代では64ビットアーキテクチャの移行により、このようなメモリ管理の苦労から解放されます。メモリも安価になりました。それに向け、第3世代のSQL Serverでは、大容量のメモリを素直に利用できる仕組みになったわけです。

　第3世代では、動的管理ビューにより、詳細な内部の動作状況を表示するような解析ツールも多数提供されます。オラクルのRDBMSでいうところの「Statspack」に相当するツールですね。このあたりから分かるかと思いますが、実は第2世代までのSQL Serverはいわば「ブラックボックス」でした。第3世代でやっと、積極的に内部情報が出てきたといえます。