SQL Serverというブラックボックスを開いてみる：Dr. K's SQL Serverチューニング研修（1）（2/3 ページ）

[熊澤 幸生, 工藤 淳（インタビュアー），エイ・エヌ・テイ/オフィスローグ]

何がパフォーマンス・チューニングのカギになるのか？
それには内部構造の理解と未来像の把握が不可欠だ！

SQL Serverのアーキテクチャで最重要なのはメモリ管理

　SQL Serverのアーキテクチャを理解するうえで最も重要なのはどこかというと、ずばり「メモリ」です。メモリこそがSQL Serverで一番クリティカルな資源であり、これがどう使われているのかを知ることが、SQL Serverの深い理解につながります。

　SQL Serverのメモリ内部の構成を見てみると、図2のようになります。この中でもとりわけ重要なのが、「メモリプール」です。例えばこの中の「Buffer Cache」には、物理ディスクから読み込んだ8Kbytes単位のデータがすべていったんプールされます。また「User Connection Context」は、現在接続しているすべてのステータスを管理する部分です。このほかには「Memory to Leave」という領域もあり、ここは8Kbytesを超える大きなクエリなどのために提供されます。これらの機能をいくつか見るだけでも、パフォーマンス・チューニングにおけるメモリ管理の重要度が感じられるはずです。

図2　SQL Serverの仮想メモリ空間マップ

　先日、SQL Serverの育ての親ともいうべきマイクロソフトのジム・グレイ氏とデータベースの今後について話し合ったのですが、彼は今後64bit化が進んでいくと、もはやギガバイトではなくテラバイト級のメモリを持つことが珍しくなくなる。そうなると、近い将来にデータベースの設計自体を根本的に変えなくてはならないだろうと述べていました。

　64bitアプリケーションの処理能力は、現在の32bitに比べて格段に高くなります。その結果、アプリケーションから受け付ける処理が爆発的に増える一方で、メモリ上の変更（挿入や更新）と非同期で行われているディスクへの書き込み処理が間に合わなくなる可能性も高くなります。これを解決するには、現在のデータベースエンジン自体の設計を抜本的に変革しないと対応できないというのです。

データベースの進化に必須の要件とは？

　もう1つ、今後のデータベースを取り巻く環境の劇的な変化は、「Win FS」の登場です。これはSQL Server 2005のさらに次の世代のSQL Serverといわれているもので、次期Windows OSである「Longhorn」のファイルシステムの一部に取り込まれることが予想されています。その結果、PowerPointやWordのようなドキュメントファイルもすべてデータベースに格納されるようになります。ユーザーには素晴らしいシームレスな作業環境が実現しますが、一方データベースにとっては大変な変革を要求されることなのです。

　現在のSQL Serverにもこうした大容量のドキュメントや画像を扱う機能はありますが、ポインタのみを格納して実データは別テーブルに置き、アクセス時の過負荷を回避する手法を採っています。しかし64bit環境と新OSに移行すれば、大量のデータ処理にリアルタイムで対応していかなくてはなりません。その膨大なデータ更新処理をどうさばくかが大きな問題になります。

　もちろんマイクロソフトもすでに、そうした実験は開始しています。ジム・グレイ氏は「いちばんよいヒントはSharePoint Portal Serverにある」と示唆しています。実は、SharePoint Portal Serverは、内部のファイルシステムにSQL Serverを使用しています。ここに大きなファイルをデータベースエンジンに格納するヒントがあると、彼はいっているのです。また彼は、「the Microsoft Conference 2005」で「SODA（Service-Oriented Database Architecture）という新しい概念を紹介していました。これはもともとマイクロソフトのアーキテクチャ研究者であるデビッド・キャンベル氏が提唱してきたもので、データの性格ごとにデータベースの設計を変えていくべきだという考え方です。マイクロソフトではこれをSQL Serverに取り入れようと研究を進めています。

　いずれにしても、データベースの扱うデータ量が増えていけば、データベースのパラダイムそのものが大きく変化していきます。そうした時代の到来を目前に控えている現在、データベースの内部アーキテクチャとその重要ポイントをしっかり学んでおくことは大切です。ハードウェア市場の統計を見ても、64bitチップの生産量は急速に増加しています。間違いなく2006年以降は、SQL Serverの64bit化にこれまで以上の拍車がかかることでしょう。現場で開発・運用に携わるデータベース技術者にとっては、本気で勉強しなくては追い付けない状況が迫ってきているのです。

「なぜこういう現象が起こる？」の原因を理解する

　実際のパフォーマンス・チューニングに当たっては、具体的にどの部分に着眼していったらよいのかと思われるでしょう。本記事では次回以降、重要なパラメータに関する解説を行っていきますが、基本とすべきスタンスはあります。それは、パフォーマンス・チューニングに当たっては「表面的な事象と原因の関係を理解することが大事」という意識です。データベースに限らず、ごく当たり前のことと思われるかもしれませんが、データベースの場合、内部がブラックボックスだからといって、勘だけでいじくり回すととんでもない結果を招きますし、事実そういうケースは多いのです。

　パフォーマンス・チューニングに当たって着目すべき代表的なポイントの1つに、「ファイル別のI/O」が挙げられます。これは「どのファイルに対してI/Oが発生して、その結果どんな現象（問題）が現れているのか？」を知る重要な手掛かりです。また「wait事象」も重要なチューニング・ポイントです。これを理解できればどこがボトルネックなのかが分かるのです。ところがこれらの事象を見るための方法は、一般には非公開になっています。この部分について、私はマイクロソフトと共同でチューニングの手法を研究することで、それぞれの事象を分析して解決するためのテンプレートを確立しました。これにより、複数のボトルネックを発見して詳細なチューニングを施すことができるようになりました。このことについては、この後詳しく述べていきます。（次ページに続く）