テスト環境と本番環境で、DBからのデータ取得にかかる時間に違いがある。

質問

お世話になります。

WebサーバとDBサーバを使用して構築したシステムが
あります。
テスト環境と本番環境があり、それぞれ、以下の様になってます。

テスト環境
Webサーバ
　　Windows2000 Server＋IIS5.0＋ .NET Framework
DBサーバ
　　Windows2000 Server＋Oracle8.0.6

本番環境は
Webサーバ
　　Windows2000 Server＋IIS5.0＋ .NET Framework、
DBサーバ
　　Solaris（バージョン分からず）＋Oracle8.0.6

となっています。

テスト環境と本番環境の違いについてですが、
Webサーバの方は、スペックは違いますが、
その他の環境は同じです。

DBサーバの方は、OSの違いとOracleのデータベースの定義に少し違いがあるかもしれませんが、
データの件数とテーブルの定義は同じです。

そこで肝心の質問の件なのですが、
テスト環境と本番環境で、同システムを実行した際に、
DBからのデータ取得にかなりの時間の差があるのです。

テスト環境で、2～3分で終わる処理が
本番環境だと、30分くらいかかってしまいます。

何が原因でこのような状態になっているか分からず、
すごく悩んでいます。

ネットワークの速度にはそれほど違いはないのですが・・・。
また、マシンスペックは本番環境の方が高いです。

どんな細かい情報でもかまいませんので、
ここが怪しいのではないか？とかありましたら、
ご教授お願いします。

また、他に必要な情報とかありましたら、
できる限り調べますので、どうぞよろしくお願いします。

回答No.2

muyoshid · ベストアンサー

こんにちわ。

先ずは#1 の方が言われているように、検索条件となる
項目に索引が定義されているか確認して下さい。
本番環境にも索引が定義されているようであれば、念のため
索引を再作成してみてください。
→ alter index 索引名 rebuild; で再作成できます。

それでも性能が悪いようであれば、Oracle の初期化
パラメータファイルを見直してみてください。
バッファサイズや、shared pool サイズに問題がある
場合もあります。

それでも解決しなければ、SQL Trace を取って
tkprof するしかないですね。

回答No.4

muyoshid

こんにちわ。
#2 のmuyoshid です。

索引を使用しなかった場合、データ件数が同じでも
検索時間に差が出る事があります。
Oracle は、「最後のデータ」と言う管理を行って
いませんので、索引を使用しない検索 (全表検索)
した場合、高水準位指標までの読込みを行います。
一度100万件のデータが登録されると、データが削除
されても、100万件分のデータブロックの読込みが
行われます。
exp user/pass tables=(表名) file=data.dmp
としてデータを一旦バックアップして、
SQL> truncate table 表名
imp user/pass file=data.dmp ignore=y
としてデータの復旧をしてみて下さい。
デーブルのアクセスパターンに応じて、適宜
索引の定義も検討して下さい。

回答No.3

ARC

インデックスじゃないとすると、そうですねぇ…
もし可能であれば、本番系のデータ全部エクスポートして、テスト系に丸々インポートしてみたらどうなんでしょうか。
これによって、表定義とか統計情報については同一に出来ると思うんで。

それでもまだ違いが出るっていうのであれば、テーブルスペースとかのＤＢ定義の方の設定が違ってるんじゃないかなぁ。(先に書いたように、この辺に関してはさほど強くは無いんで、あまり突っ込んだ話は出来ないんですが。)

インポートしたテスト系のほうでもパフォーマンスの低下が起こるようであれば、多分、なんかのデータが悪さをしてるんじゃないかと(^^;

回答No.1

ARC

それほどまでに差があるとすると、例えば、インデックスの張り忘れなんかが頭をよぎります。
他にもリーフ分割など、インデックスがらみで遅くなる可能性はありますので、一度再生成されてみたらいかがでしょうか。

あとは、メモリやディスク領域の設定とか、あるいは統計情報なんかもパフォーマンスに関わってくるんですが… Oracleのチューニングについてはさほど詳しくは無いので、他の方にお任せします。

お礼

＞例えば、インデックスの張り忘れなんかが頭をよぎります。
テスト機、本番機ともにインデックスは貼っていない模様です。

でもデータベースの設計などが、問題の原因なのかもしれないんですね。

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