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

いまだから語ろう、SQL Serverの歴史

　SQL Serverの歴史は3つの世代に分けられるといっていいでしょう。

　第1世代はサイベースの技術提供を受け、その仕組みをWindows NT Server上に移植したものです。これはSQL Serverの4.2、6.0、6.5に相当します。このころはページロックの仕組みしか提供されておらず、このときにSQL Serverを使っていたエンジニアの皆さまは、ひょっとしたら「使えない」という判断を、いまでも引きずっているのではないかと思います。

大改革を行った第2世代、鍵は「ロック」と「SQL OS」

　その判断が若干変わるようになったのは、第2世代のころです。バージョンでいうと7.0や2000ですね。このときには、内部アーキテクチャの大改革が行われました。その開発の中心になったのは、ドクター・ジム・グレイと、デイブ・キャンベル氏です。サイベースのエンジンを一新し、「リレーショナルデータベースとして、あるべき姿にする」という目標を持って改良を行いました。

　ここでいうあるべき姿とは、ANSI（ISO）のSQL99に準拠したデータベースエンジンを目指すことにほかなりません。ANSIで定められたトランザクション分離レベル(Isolation Level)をクリアするよう、ジム・グレイ氏らがインプリメントしました。このエンジンの改革には、彼の功績が大変大きいのです。

　SQL Serverにおける行ロックの概念は2つあります。1つは「RIDロック」。これは、クラスタ化インデックスが定義されていないテーブルに対するロックです。ファイルグループID＋ファイル内のページ番号＋ページ内の行ロケータID、この3つを基に「一意である」と判断するのですね。第1世代はこの手法しかありませんでした。

　もう1つは「クラスタ化インデックスのキー値を用いたロック」です。これは、キー値、つまりユニークIDを基にしたロックです。私はこの「クラスタ化インデックスのキー値を用いたロック」を利用しなさいとよく言っていました。これは、ファントムリードが起こらないからです。

　例えば、「where ID<=100」のカウントを行うという条件を書いたとします。これで70行が見つかりました。そのあと、“ID=68”という、いままでなかった行を追加したとしましょう。「RID行ロック」の場合、INSERT行のコミットタイミングによって、カウントの結果が70行になったり71行になったりします。これを「ファントムリード」と呼んでいます。ファントムリードは、「クラスタ化インデックスのキー値を用いたロック」では発生しません。トランザクション内で一貫した結果になるのです。

　SQL99の仕様では、各トランザクションが完全に分離される最も高い分離レベル「SERIALIZABLE」ではこのファントムリードが検知できる必要があります。この点を、第2世代のSQL Serverではきっちりと対応してきました。

　もう1つ、第2世代で特徴的だったのは「SQL OS」の導入です。SQL Serverの第1世代では、プリンエンプティブなモードでマルチユーザーの管理をしており、すべてのコンテキストスイッチをOSのレイヤで行っていました。第2世代からはデータベースエンジン内に「SQL OS」というレイヤを用意し、ユーザーモードスケジューラとして実現したものです。これにより、SQL Server自身でメモリの管理、スレッドの管理、ユーザーコンテキスト切り替えができるようになりました。

　ジムは「10年以上安定して使えるDBエンジン」というビッグピクチャーを描き、それを実現しました。それだけに大変大きな変革ではありましたが、エンジニアにも受け入れられています。私は第1世代からこの変革を見てきましたが、ずいぶんとスマートな解決策を用意したなあ、と感じました。SQL Server 7.0では、当時の開発チームが技術的に彼のコンセプトについていけずに、SQL Server 2000で実現した機能（sp_getapplockなど）もあったと聞いております。