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

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

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

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

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

• 第1世代
  • SQL Server 4.2／6.0／6.5
    • サイベースから技術提供を受け、Windows NT Server上に移植
    • 2KB／ページ 16KB／エクステント　ページロック
• 第2世代
  • SQL Server 7.0／2000
    • Dr. ジム・グレイ（Jim Gray）／デイブ・キャンベル（Dave Campbell）氏らを迎えアーキテクチャを刷新
    • 8KB/ページ 64KB/エクステント 行ロックの導入
    • SQLOSの採用
    • IA64上のNUMAサポート
    • Analysis Service／ETLの提供開始
    • XML のサポート
• 第3世代
  • SQL Server 2005／2008／2008R2
    • IA32からx64への移行
    • NUMAアーキテクチャの採用
    • クエリー並列処理機能の強化
    • 動的管理ビューによる内部動作と問題点の可視化
    • ラージオブジェクト格納への対応
    • BI機能の強化

　第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)をクリアするよう、ジム・グレイ氏らがインプリメントしました。このエンジンの改革には、彼の功績が大変大きいのです。

【関連記事】
オブジェクト指向、Javaを取り入れた新しい業界標準「SQL99」詳細解説
http://www.atmarkit.co.jp/fnetwork/tokusyuu/01sql99/sql99_1a.html

　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自身でメモリの管理、スレッドの管理、ユーザーコンテキスト切り替えができるようになりました。

【関連記事】
Dr. K's SQL Serverチューニング研修
（1）SQL Serverというブラックボックスを開いてみる
http://www.atmarkit.co.jp/fdb/rensai/drk01/drk01_1.html

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