前回のおさらい＆今回の概要

前回では，ユーザから受け取ったSQLに対して，DBMSがどのような手順を踏んでデータを取り出す（または更新する）か，という一連の流れを解説しました。今回は，そこから一歩進んで，実際にシステムに性能問題が発生したとき，どのように対処するか，という実践的なところに踏み込んで解説したいと思います。

前回の内容を前提とするものではありませんが，オプティマイザを中心とするクエリ評価エンジンの機能については，知っていたほうが理解しやすいでしょう。忘れてしまったという方は，第4回（1）で簡単におさらいしてください。

パフォーマンスチューニングは医療に近い

筆者は，仕事でパフォーマンスチューニングを引き受けることがよくあります。性能試験の一環として遅延が発生した処理のチューニングを行うこともあれば，すでにカットオーバーされて運用に入っているシステムが遅延を起こして，お祭りの会場になっているところにのこのこやっていくこともあります。

その経験に照らして，筆者は，パフォーマンスチューニングというのは医者の仕事に近い，と思っています。

もちろん，筆者は医者をやったことがあるわけではないので，医師の仕事のやり方については漠然とした理解しかありませんし，障害対応を広く「システムとして異常な状態から正常な状態への復旧」と位置付ければ，チューニングに限らず広くデバッグ全般をそうたとえることも可能でしょう。

しかしそれでも，パフォーマンスチューニングのプロセスはやはり，医師が行う「治療」のプロセスに非常に似通っていると思うのです。また，その類似性を意識することで，チューニングの手順を整理，理解しやすくなるメリットがあると思います。

そのようなわけで，本稿を読んだあと，みなさんが性能問題を抱えたシステムを見たら「ああ，病気のかわいそうな子だ。治してあげないと」と思うようになって，さらにその治し方のフローを具体的に頭に描けるようになれば，本稿の目的は達成されたことになります。それでは，本連載最後の1回も，どうぞお付き合いよろしくお願いします。

対象読者

• （DBに限らず）システムの遅延が発生して困った経験のある人
• 性能試験を担当することになった人
• 性能問題への対処方法について勉強したい人

対象環境

• すべてのリレーショナルデータベース

治療としてのチューニング

いきなり治療する？

ある日皆さんは，ユーザ，あるいはプロジェクトマネージャなどからこういう言葉をかけられました。

• 「システムのパフォーマンスが悪いんだけど見てもらえないかな？」

こんなとき，みなさんならどういう手順でチューニングを進めていこうとするでしょうか。いきなりデータベースのパラメータを変えるとか，バッファキャッシュのメモリ割り当てを変えてみる，というような唐突な行動は，よもや取らないでしょう。そういう場当たり的で闇雲な対処をしている現場もないではありませんが，真似してはいけません。

ここで冒頭筆者が言った言葉を思い出していただきたいのですが，パフォーマンスチューニングとは一種の治療行為です。とすれば，パフォーマンスの悪いシステムは患者に該当します。体調不良を訴えて病院にやってきた患者に，医者はまず何をするでしょう。どんなヤブ医者でも，いきなり投薬や手術に飛びついたりはしませんよね。

そう，まず行うべきは診察・検査です。なぜかといえば，病気や怪我の部位が特定できなければ，どんな治療をしてよいかもわからないからです。胃潰瘍に風邪薬は効きませんし，動脈から出血しているのに静脈を止血しても意味がありません。

チューニングの一般的なフロー

チューニングの一般的なフローを図示すると，図1のようになります。

まず，チューニング（＝治療）の前にやるべきことは検査です。つまり，「⁠どこで」「⁠なぜ」遅延しているのかを突き止めることです。チューニングプランを立てるのはそのあとです。これは一見まどろっこしい，迂遠（うえん⁠）⁠）な方法に見えるかもしれません。しかし，何の証拠もつかまないまま場当たり的な対処（治療）を行うことは，まぐれ当たり以外でうまくいくことはありませんし，状況をより悪化させることもあるのです。

さらに言うと，パフォーマンスチューニングという仕事は，遅延原因の特定までできれば半分終わったも同然なのです。その理由は，ちょうど医療の世界で多くの傷病（しょうびょう）に対してすでに治療方法が確立されているのと同じように，遅延原因に対するチューニング方法も半ば自動的に決まってくるからです。

データベースの鉄則

検査をせずに治療するようなヤブ医者にはなるな

それでは，検査・診察について，個々のステップを詳しく見ていきましょう。