チューニングを行うにあたって

まず最初に、あなたのパフォーマンスチューニングに対する考え方を 確認させて頂きたいと思います。
次の項目のうち、あなたが該当するものはいくつありましたか？

  1. データベースのチューニングは、「このままではシステムの応答が遅くて使い物にならない」と気付いた時点から始めれば良い。
  2. 非常に性能の高い(そして高価な)サーバがあれば、応答時間の問題は解決される。
  3. SQL文の良否は、必要とする結果を正しく取得できるかどうかのみで決まる。
  4. 表結合を行うとパフォーマンスが低下するので、なるべく１つの表内に 、抽出に必要な全項目を含めてしまうのが良い。
  5. 抽出するデータ件数が多くなると遅くなってしまうのは仕方ないので、 そこはお客様に対し、運用でカバーして頂くよう依頼する。
  6. パフォーマンス低下の原因は、プログラマの作成するSQL文に大きく影響されるが、設計上の問題によりパフォーマンスが低下することは稀である。
  7. ネットワーク上の負荷を低減させるために、クライアントからのSQL文発行を控え、複雑なSQL文については可能な限りビューを使用した方が良い。
  8. 索引を構築すれば表へのアクセスが速くなるので、更新処理の時間を多少犠牲にしてでも索引をたくさん構築しておく。
  9. データベースサーバのパラメータ設定は、Oracleの初期セットアップ状態のまま、変更する必要はほとんどない。
  10. ストアドブロシージャを使用すると、サーバへの負荷が大きくなるので使用しない方が良い。

あなたはいくつあてはまりましたか？
答えは、10個全て誤りです。その理由は以下の通りです。
但し、全てのシステムがこの通りだとは申し上げません。当然ながら例外もありえますので...。

  1. 設計時点、あるいは初期データベース作成の時点からパフォーマンスを意識している必要がある。設計やデータベースの構造の問題が後になって発覚しても、そう簡単には修正できない。
  2. どんなにサーバの性能が良くても、作りが悪ければ非常に遅いシステムになってしまう。現実として、Pentium120MHz程度のパソコン上で適切にチューニングされたOracleサーバを動かした方が、PentiumIIの450MHzクラスのサーバ上に置かれた、チューニングされていないOracleよりも処理が速かったということさえありました。
  3. SQLの実行結果が期待した通りの行を返すのは当然のことですが、各プログラマの仕事はそこで終わるわけではありません。正しい結果を返したとしても、処理に時間がかかりすぎてはシステムとしては使い物にならないため、パフォーマンス面と検索結果の両方を満足して、初めてSQLプログラミングが完了したといえます。これは、夜間に稼動する大規模なバッチ処理にもあてはまります。夜間のバッチ処理が翌朝の業務開始までに終わらなかったなんて冗談じゃ済まされませんから・・・。
  4. これは、根本的に誤った設計方法です。Oracleのようなリレーショナル・データベース(RDBMS)では、テーブル設計時に進んで非正規化を行うことはしません。一度、完全に正規化を行った後で、『やむを得ず』冗長に持たせなければならない項目のみをテーブル内に持たせるようにします。
  5. 検索に時間が掛かりすぎる処理になりますと、「こんなの検索方法が悪い！！」となってしまいがちですが、運用でカバーする前に、すべてのチューニングを終わらせたかどうか確認しましたか？全てのSQL文は最適なアクセスパスを選択していますか？チューニングをもう１度見直せばパフォーマンスが改善されるといったケースも多々あります。
  6. 設計がお粗末だと、最適なSQL文を組んでも速度が上がらないということも十分に起こり得ます。製造工程(プログラム開発)以前の工程として、設計段階があるのですから、後々にひきずらないためにも設計はしっかりとやっておくべきです。
  7. 複雑なSQLを１つのビューにすると、確かにネットワークの転送量は減ります。が、PL/SQLでストアドプロシージャを組んだ方がより効率的、かつサーバでの処理速度の向上にもつながります。ビューを使用した場合でも結局はビューに対してSQL文を実行して結果を取り出しますし、ビューからの検索速度が、ビューを構成するSQL文よりも処理が速くなることはほとんどないため、結果的にはそれほどの速度向上につながらないことがほとんどです。パフォーマンス面だけをとれば、ビューの使用はあまり良いとは言えません。
  8. １つの表内に索引を山ほど作ったとしても、オプティマイザが混乱してしまう元になりかねません。１つの表内に索引が多すぎると「この索引を使ってほしいのに、使ってくれない！」なんてことも起こりますし、何よりディスク領域の無駄にもつながります。いくつかの索引をまとめて１つにした上で、１つの表内に存在する索引の数を減らしただけで検索・更新速度ともに向上したというケースさえもあります。
  9. Oracleの初期データベースのパラメータは、そのままでは使い物にならない場合がほとんどです(Oracleさん、ごめんなさい...)。ほとんどの場合、サーバの能力(メモリ・CPU等)やディスク構成、クライアントからの接続数などを考慮して初期パラメータを調整する必要が生じます。
  10. 逆です。ストアドプロシージャにしておくと、SQLがコンパイル済の状態で格納されるため、SQLのコンパイルに対するオーバーヘッドが減少します。さらに、ストアドプロシージャ内でカーソルを使用する方が、データアクセスを効率化できる場合が多いです。詳しくは後述します。
トップへ戻る