Oracleのチューニングについて

あるWebアプリケーションの一部の処理が、最近極端に処理が遅くなったと感じているものがあります。
アプリケーションの仕様も変えていない（確実とは言えません）と思いますので、OracleDB側（チューニング）の問題ではないかと疑っております。

いろいろチューニングについて調べたところ、まず「データ・ブロック数を減らす」という点を確認しようと思っています。
無駄なブロック数を減らそうとした場合、暫定的な対応にはなりますが、一度データをtruncateしてからデータを再挿入すると、きれいな状態でデータブロックが再生成される、という認識でよいのでしょうか？
（一度truncateしても処理スピードが変わらない場合は、「データブロック」の問題ではない、という判断で良いでしょうか？）

逆に上記で変わらない場合は、DB側で確認すべき点・何か原因として怪しいと考えられる点はありますでしょうか？

宜しくお願い致します。

No.4 ベストアンサー 回答者： sapporo30 回答日時： 2006/10/31 03:05

DBのパフォーマンスが悪くなった場合は、

１．　アナライズを実行する。
２．　SQLの見直しをする。
　　　SQL trace を取って、FULL　SCANしているような
　　　SQL を見直す。
３．　DBのチューニングをする。
というような感じです。
DB自体のチューニングを行う前に、アナライズをしたほうが
いいです。（対して手間がかからないので）

OracleDBは、検索パスを決めるのに、COSTベース　オプティマイザ
を使用しています。
そのCOSTを決定するのに、統計情報を使用します。
統計情報は、テーブルの件数やばらつきなどの情報です。
その統計情報を収集するのが、アナライズです。
古い統計情報のテーブル、スキーマだと、
極端にパフォーマンスが悪くなる場合があるので
まず最初にしたほうがいいです。

No.3 回答者： sapporo30 回答日時： 2006/10/29 07:13

アナライズは実行されていますか？

この回答へのお礼

行っておりません。
（アナライズという言葉自体始めて聞きました・・・）
OracleDBを導入時（業者さんに依頼）に設定を行ってもらった
以降はホッタラカシ状態となってしまっていますので、
定期的に行わなくてはいけないことだと、全く行っていない、
ということになります。

まずは、ANALYZEコマンドについて勉強するようにしたいと思います。
取り急ぎ、試してみたほうが良い、コマンドなどありましたら、
ご指示いただけると幸いです。
知らないことが多すぎで１から勉強しないとマズい状態のようです・・・

お礼日時：2006/10/30 16:18

No.2 回答者： FudaKeji 回答日時： 2006/10/25 23:16

データの更新(削除、追加も)を繰り返すことでデータが複数のブロックにまたがったりしてブロックの利用率が低くなることがあります。

TuncateしてImportすることで無駄な空き部分が詰まるために必要なデータを取得するためにスキャンするブロック数が減ります。
ってことで認識はあっていると思いますよ。

StatsPackは一度使うと簡単になるので是非勉強してみてください。
専用の表領域と専用のユーザーを作成し、sysで$ORACLE_HOME/rdbms/spcreate.sql を実行すればパッケージが作成されます。

その後、作成済みの専用ユーザーで
exec statspack.snap;
を2回実行し、今度は spreport.sql を実行。

パフォーマンスチューニングのマニュアルや、OiSC(サポート契約があれば)に情報が沢山有ります。

データが予想以上に増えている表とか無いですか？

この回答へのお礼

ご回答ありがとうございます。

StatsPackはまだ実行できていません。
（マニュアルを見たところをそれほど難しくないように感じてはいますが、業者さんにOracleを導入をしてもらった状況でそれ以降は構成はほとんどイジっておらず、私自身も表領域の作成等も行ったことがないため、実際に行うのに躊躇しております。まず表領域等の勉強から始めないと・・・　といった状況です）

サポート契約もありますのでOiSCも参照可能です。
まずは勉強から・・・　といった状況です。

> データが予想以上に増えている表とか無いですか？

ここで言う”データ”とは、(1)レコードの数、それとも(2)1レコード内のデータ×レコード数　の(2)のほうですよね？
レコード数はあまり増えていませんが、１レコード内のデータ量は日々増えていますのでその辺は気にしております。（VARCHAR2で定義したカラム内のデータ）
よって削除・追加は頻度としては多くありませんが、更新の頻度は結構あります。

ただレコード数はどのテーブルも5000レコード程度なので、索引があればそれほど時間がかかるものではないように思われるのですが・・・
何かのタイミングで、索引から検索されなくなってしまった（全表走査になってしまった）ということはありえるのですか？

またブロックの利用率でここまで処理が遅くなるのか（今まで4秒程度で応答があった処理が、現在は10秒ほどかかっているので、違う原因があるのかもしれません。
ブロック数の問題でこれほどの違いは考えられるものですか？

お礼日時：2006/10/26 09:43

No.1 回答者： FudaKeji 回答日時： 2006/10/24 22:44

tuncate→import を試す前にstatspackというキーワードを調査してください。

statspackではある２時点間の性能データを採取することが出来ます。

(1)statspack実行
(2)該当処理実行
(3)statspack実行

で(1)と(2)の間でどのような処理が実行されたかを確認出来ます。
まず暫定対応を行う前の状況を確認し、対応後のレポートと比較することで改善された場合の原因が特定できます。

データ量の変換に伴い実行計画が変化したことが考えられますが、まず現状の性能情報が必要です。

この回答へのお礼

ありがとうございます。
そうですね、まずは原因を究明するためにも状況を分析することを行うようにしたいと思います。
（statspackについてサラッと調べてみましたが、ちょっと難しそうな話なので、じっくり調べてから行うようにしたいと思います。）

また勉強の為に知りたいのですが、全てのデータを一度truncateしてからデータを再投入すれば、データブロックの状態はきれいになる、という認識は間違っていないでしょうか？

お礼日時：2006/10/25 12:07