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

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

SQL Serverは一般的にチューニング不要のデータベースと認識されている。しかし基幹系業務システムへの導入が進むにつれて、パフォーマンス・チューニングのニーズは急速に高まってきた。そこで本記事では、日本におけるSQL Serverコンサルタントの第一人者、熊澤幸生氏にSQL Serverチューニングのノウハウを語っていただくことにした。インタビュアーはSQL Serverへの造詣が深いITジャーナリスト、工藤淳氏が担当する。（編集局）

―― はじめに

　「簡単に導入できるのはいいけれど、いざチューニングしようと思うとブラックボックスで手出しできない」と思われがちなSQL Server。だが、本当にSQL Serverは“いじれない”のだろうか？

　「そんなことはありません。私はいくつものコマンドを駆使してSQL Serverのチューニングをお客さまに提供していますよ」というのは、わが国のSQL Serverコンサルティングの先駆者として知られる、“ドクターK”こと熊澤幸生氏だ。世界でも140人しかいないマイクロソフト・リージョナルディレクターを1997〜2002年まで務め、現在は株式会社エイ・エヌ・テイ執行役員／コンサルティング部長として、SQL Serverパフォーマンス・チューニングの最前線をいく熊澤氏に、本連載を通じて秘伝のノウハウを伝授していただこう！

SQL Serverは他社製品とどう違い、どこが優れているのか？
それには内部構造の理解と重要ポイントの把握が不可欠だ！

「SQL Serverのパラメータはいじれない」という誤解

　SQL Serverは、非常に優れた機能と実績を持つRDBMS（Relational Database Management System）です。Oracle、IBM DB2と並ぶ現代の代表的なデータベース製品であることは、この記事を読まれる方ならすでにご存じでしょう。

　マイクロソフトは、エンタープライズ系データベースシステムに力点を置いたソリューション提供をここ数年強力に進めており、大規模なミッションクリティカル事例での実績も世界規模で急速に増えています。さらに64bit化や待望のSQL Server 2005の登場など、SQL Serverはいままさに追い風の中にあるといえるのではないでしょうか。

　ところが、こうした目覚ましい進歩にもかかわらず、依然としてデータベース技術者の現場、とりわけパフォーマンス・チューニングを手掛ける技術者の間には、「SQL Serverはチューニングが行いにくい」「導入してすぐに使えるのはいいが、いじれるパラメータも少なく初心者向けだ」という誤解が根強く残っているのも確かです。本当でしょうか？

　長年SQL Serverのパフォーマンス・チューニングに携わってきた私からすると、これは大きな誤解です。SQL Serverはその気になりさえすれば、思いどおりにチューニング可能なのです。

SQL Serverは内部にWindowsとは別のOS機能を備えている

　では、具体的なチューニングの話に入る前に、「そもそもSQL ServerはほかのRDBMS製品と比較した場合にどんなところが違い、どこが特徴的なのか？」を少しだけ知っておきましょう。SQL Serverの設計上の特徴を知ることが、製品と機能の正しい理解には欠かせないからです。

　まずSQL Serverがほかの製品と大きく異なるのは、「自分自身の中にOSとしての機能を備えている」点にあります。これはUMS（User Mode Scheduler）と呼ばれるスケジューラで、SQL Server 7.0ですでに実装され、SQL Serverの自動化志向を支える原動力となってきました（図1）。

図1　SQL ServerのOS機能であるSQL OS：User Mode Scheduler
UMSはプロセッサごとに生成される。図では4つのCPUに対して4つのUMSが生成されていることを示している。各スレッドは1つのUMSに割り当てられると、以降は同じUMSのみで動作する。

　UMSは基本的にOS（Windows）から見てノンプリエンプティブです。Windowsはプリエンプティブ・スケジューラを採用しているため、実行中のスレッドはタイムスライスによって交互に実行されるのですが、この際のコンテキスト・スイッチのコストは非常に高い。これに対して、UMSで管理されるスレッドは、1つのCPUに割り当てられたらスレッドが自発的に放棄するまでCPUを独占できます（もちろん、いくつかの例外はあります）。

　このようにスレッド管理をSQL Server自身で行えるために、ほかのRDBMS製品ではできない自動チューニングが可能なのです。ここがSQL Serverと競合製品との大きな構造的違いであり、かつアドバンテージだといえます。

参考資料
「Inside the SQL Server 2000 User Mode Scheduler」（MSDN Libraryより、英文）

「クラスタ化／非クラスタ化インデックス」がチューニングのカギ

　またチューニングに関する部分では、「クラスタ化インデックスと非クラスタ化インデックス」の関係に特徴があります。クラスタ化インデックスの扱い方がOracleとは大きく異なるので、ここをきちんと理解してチューニングできれば検索などでも大きな効果が期待できます。逆にここを理解していないままアプリケーションを作って、「SQL Serverはパフォーマンスが出ない」と決め付けてしまう人も少なくありません。せっかく時間と労力をかけて、もったいない話です。

　余談ですが、Oracleの場合はユーザー数に比例して技術者の層が厚く、こうした初中級者にはブラックボックスに見える部分でも、自分で分析してきちんと解明できる人が多いのです。一方、SQL Serverはオフィス業務の延長線上で使うようなエンドユーザーまですそ野が広い分、そこまで突き詰められるレベルの技術者ばかりとは限りません。その結果、「よく分からないから使えない」となるケースも多いのだと思います。

「SQL Serverは使えない」と決め付ける2つの技術者タイプ

　データベースのチューニング現場を見てみると、SQL Serverのパフォーマンスが出ないというケースには、典型的な2つのタイプがあります。

　まず「取りあえず作ったら、こんな大きなデータベースになっちゃった」というタイプ。これは明らかにSQL Serverに問題があるのではなく、成り行きで進めてしまうような姿勢やスキルにありますね。とはいえ、ユーザーのすそ野が広いSQL Serverでは、決して珍しい例でもないのです。

　もう1つは意外なことに、大手のSIer（システムインテグレータ）が作り上げたシステムに多く見られます。技術者もUNIXやメインフレームで経験のあるベテランで、出来上がりも良いのだけれど、なぜかパフォーマンスが出ないという例です。残念ながらこれもSQL Serverの構造と特性を理解していないが故の悲劇です。

チューニングレスはビジネスを最優先するマイクロソフトの哲学

　本来SQL ServerとOracleは、根本となる設計思想から異なっています。徹底的にチューニングして作り込むことでシステムの最大限の性能を発揮させる「技術指向」のOracleに対して、SQL Serverはより「ビジネス指向」です。「the Microsoft Conference 2005」でCEOのスティーブ・バルマー氏が述べていたように、マイクロソフトはユーザーのビジネスをより効率的にするために、ツールとしてのソリューションを提供することを最重要ポリシーに掲げています。彼の言葉を借りれば、「重要なのはテクノロジーではなく、顧客のビジネスだ」というわけです。

　そのためにSQL Serverは、早くから自動化に焦点を絞って開発されてきました。専門のデータベース技術者がいない企業でも、導入したその日から一定のレベルの運用が可能で、パフォーマンス・チューニングも自動化されていること。それによって、システム運用に関する負荷やコストをユーザーから取り除き、本来のビジネスにエネルギーを振り向けられるようにする。SQL Serverの進化の背景にはそうしたマイクロソフト独自の思想があるのであって、“基幹系の重い処理は不得手”というのはまったくの誤解だということを、この機会にぜひ理解してほしいと思います。