PR
 SQL Serverという巨大な製品で,筆者が関心を持ち注目しているのはその内部構造だ。SQL Serverがどのようにして機能を実現しているのかを知りたいし,その知識を使ってSQL Serverをより上手に,そしてより素早く使えるようになりたいとも思っている。しかも,ソースコードを読むことなく,こうした知識をすべて吸収したいと思っているのだ。

 SQL Serverの内部構造を知ることによって,筆者は今の知識を得ることができた。そして過去7年間にわたって,この知識を読者の方と共有して,読者の皆様のSQL Server環境を向上させることに役立ててきたのである。

講座を受けて高揚感から苛立ちに

 初めて内部構造に興味を持ったのは,Sybaseの技術サポート・エンジニアとして働いていたころだ。約18年前の話である。ご存じの方もいると思うが,Sybaseデータベース・エンジンは,Microsoft SQL Server製品のオリジナルソースだったのだ。

 筆者は必要最小限のトレーニングだけを受けると,世界中のSybaseカスタマーに対して,同製品のあらゆる側面について技術サポートを行うようになった。複雑ではあるが面白いことも多いデータベース・パフォーマンスの問題をどうにかこうにか処理するようになって1年がたったころ,筆者はSybaseの教育部門を通して「Performance Tuning and Optimization(パフォーマンスのチューニングと最適化)」講座を受講した。

 講座を受けた1週間で,莫大な量の情報を吸収することができたが,講座を受講しているうちに,筆者の気持ちは高揚感から苛立ちに一変した。データベースが実際にはどのように機能しているのかを詳細に学ぶことができたのはうれしかったが,最初にカスタマーのサポートを始めたときにこうした情報を与えられなかったことに対して苛立ち,時には怒りさえも感じたのだ。

 だがこのことについて深く考えていくうちに,講座で得られる情報を使って解決できる問題に関してある程度の経験がなければ,講座で扱われる概念を理解することはできなかっただろうということを悟った。言い換えると,学んだ内容を過去に遭遇した特定の事態と結びつけて考えることができなければ,同製品の内部の仕組みについて詳しく学ぶことの意義を理解できなかっただろう。

 講座のあった1週間が終わったとき,筆者を支配していた気持ちは,大きな興奮だった。この製品に関しては専門家になれる可能性があることに気づいた筆者は,専門家になることを自分の目標に設定したのである。

専門の分野を見つけることを決意

 数年後,Sybaseを去った筆者は,Microsoftのデータベース製品に関連する仕事を始めた。先述したのと同じ講座で講師を務めるようになり,データベースが実際に機能する仕組みについてあらゆることを学ぶ努力も続けていた。

 SQL Server 6.5が全盛を迎えたころには,すっかり専門家の気分になっていた。だがこの気分は長続きしなかった。SQL Server 7.0が登場したため,また一からやり直さなければならなくなったのだ。7.0では,インデックスの構造やオプティマイザが考えられるクエリー・プラン,ロックの入手・保持方法などを含む内部構造がすべて変化したようだった。

 さらに,DTS(データ変換サービス)の導入やマージ・レプリケーション,データ・ウエアハウジングと分析サービスの始まり,そしてADO(ActiveX Data Objects)やOLE DBといった新しいプログラミング・インタフェースなどが追加されて,同製品は途方もなく巨大になった。新しい概念や挙動を学ぶのは新鮮で刺激的ではあったが,筆者は同製品のすべての側面で専門家になるのは不可能だと判断した。

 そこで,専門の分野を見つけることを決意し,コアエンジン,特にロック関連の問題とインデックス,そしてクエリー最適化に集中することにした。さらにデータとインデックスの物理ストレージを記述するメタデータに加えて,ロックとインデックスについての情報を提供するSQL Serverのメタデータも専門にしている。

 同時期に,Ron Soukupの「Inside SQL Server」という書籍の情報を更新して7.0を取り上げてほしいという要請を受けた。さらに,SQL Server Magazineのコラムを書き始めたのもこのころだ。多くの人の目に触れることが増えたおかげで,よく似た興味を持つたくさんの人に出会うことができた。だが同時に,大規模なSQL Serverシステムの維持や開発をしていながら,SQL Serverの内部構造には興味がない,あるいは知る必要がないと公言している人にも大勢出会った。だから筆者は彼らに尋ねるようにしている。なぜ知る必要がないなどと言えるのか,と。

あなたは内部構造を知る必要があるのか

 ここでReader's Digest(訳注:アメリカの雑誌)や日曜日の新聞に掲載されているようなクイズを行ってみたいと思う。読者の皆様が,内部構造について知っておくべき人物に該当するかどうかを判断する助けにしてほしい。

  1. アプリケーションやクエリーがうまく作動するときと,作動しないときがあるのだが,その理由がわからない。
  2. システムには十分なメモリーがあるのに,SQL Serverの動作が遅く感じられることがある。
  3. システム管理者であるあなたは,「システム管理者に連絡してください」という一文を含むSQL Serverエラー・メッセージに遭遇したが,そのエラー・メッセージを理解できなかったことがある。
  4. 自分の展開・テスト用環境ではアプリケーションを完璧に作動させることができていたのだが,何十あるいは何百というユーザーがいるプロダクション環境でそのアプリケーションを実行しようとしたら,基本的なクエリーやプロセスを完了できなかったことがある。
  5. Maintenance Wizardを使ってSQL Serverシステムにメインテナンスタスクをスケジューリングして,最適化と一貫性検査についての質問に「はい」と答えているが,このタスクの実行中にSQL Serverが実際にどんな手順を踏んでいるのかよくわかっていない。
  6. 必要性を検証することなく,定期的にインデックスのデフラグや再構築を手動で行っている。
  7. クエリーのスピードを上げるためにインデックスを追加したが,逆にデータ修正処理の速度が大幅に低下したことがある。
  8. データベースのリカバリモデルを変えたほうがいいというアドバイスを受けて,変更による影響を完全に把握せずに,実行に移したことがある。

 これらの質問のいずれかに対して,「はい」と答えた方はいるだろうか? もしいるなら,その人にとってSQL Serverの内部構造を学ぶことは無駄ではないだろう。

 SQL Serverの内部構造には,学んでもすぐには役に立たないこともあるだろう。だがその情報がパフォーマンス関連の問題解決に効果を発揮するときが来るかもしれないのだ。

 例えば,データベース復旧モードと,SQL Serverがモードによってトランザクション・ログを異なる方法で使用する様子について書かれた筆者の記事を読まれた方もいると思う。記事を読まれた方が,スクリプトを実行して,今は全く問題なく機能しているデータ・ローディングとインデックス・メンテナンスを行ったとしよう。この場合は,復旧モードとデータベースで行う作業の種類の間に関連性があることには気づかないだろう。

 だが将来,ログが保存元のディスクとは不釣合いなほど長くなっていることを発見し,縮小しようとしても上手くいかないということになったら,どうだろうか。それぞれのモードで何がログに記録されているのかを完全に把握していたら,トラブル・シューティングに役立つかもしれない。

内部構造を勉強したほうが良い理由トップ4

 SQL Serverの内部構造を知っておく必要があるということにまだ納得できない方のために,筆者が選んだ内部構造を学んだほうがいい理由の上位四つを紹介する。