近視眼的なSQLチューニングやハードウェア頼みの設計は禁物
コンサルティングサービス統括
テクノロジーソリューションコンサルティング統括本部
データベースソリューションコンサルティング本部
データベースソリューション第1部
シニアコンサルタント
開發健太郎氏
開發氏は、中島氏が指摘する「幅広い視野を持った人材の不足」の影響を、SQLレベルのチューニングでも感じている。
「単一のSQL文レベルのチューニングばかりに気を取られ、そのチューニングがシステム全体にどう影響するのかを考慮できていないケースが見られる」（開發氏）。
例えば、あるテーブルにインデックスを張ったとしよう。このとき、そのテーブルにアクセスしているのが、1つのSQL文だけであれば問題はないが、実際には他のさまざまなSQL文からアクセスされているものだ。よって、それらの個所にどういった影響が及ぶのかを考えなければならないのである。
なお、以前なら、そうした調査には多くの時間を要したが、現在ではOracle Databaseに備わる各種の機能を使うことで効率的に作業が行える。例えば、Oracle Database 11gで追加された「SQL Plan Management（SPM）」を使うと、SQL文の実行計画を記録し、それを評価したうえで本番環境に適用することができる。実行計画の変更による影響を事前に把握し、効果のある変更だけを適用することが可能なのだ。
オラクルエンジニア通信：「【技術資料】SQL Plan Management 機能解説：Oracle Database 11g」
また、Oracle Database 11gで追加された「インビジブル・インデックス」も、SQL文の変更に伴う影響範囲を限定し、チューニング効率を高めてくれる便利な機能だ。これを使うと、指定したインデックスを特定のセッションでしか見えないようにできるので、それによってインデックス追加の影響範囲をコントロールできるのである。
オラクルエンジニア通信：「不可視索引（インビジブル・インデックス）」
また、近年は業務設計担当者でも、自分が書くSQL文の性能に注意を払うようになってきているが、「その反面、SQL以外の部分の設計が雑になってきた」と開發氏は嘆く。ハードウェアの性能が向上してリソースが潤沢になったためか、インフラまで十分に意識した設計が行われていないのだ。その結果、設計のバランスが悪くなるケースが散見される。
当然のことながら、システム全体の性能はハードウェアとソフトウェアの性能のバランスをとって調整しなければならない。例えば、現在はメモリが安価なので大量のメモリを搭載し、その上にデータを展開して処理を行うケースが多いが、本番環境で膨大なデータが発生してメモリからデータがあふれてしまうと、そこで大量のI/Oが発生する。このI/O処理には、メモリ上での処理と比べて数十倍の時間がかかるため、パフォーマンスは大幅に劣化する。「大量のメモリを搭載しているから」とデータベース・パーティショニングなどへの配慮を怠ると、途端にこのようなトラブルに見舞われるのだ。こうした問題の背景にあることは何か？
「先のSQLチューニングの問題にしても、ハードウェア性能に依存した設計にしても、その根本には業務／アーキテクチャに応じたチューニングを継続的かつ効果的に行っていくための体制を作るという意識が欠如していることがある。そのため、場当たり的にSQL文を修正したり、無闇にハードウェアに頼ったりといったことが起きるのだろう」（開發氏）。
