８００万件のテーブル読み込みについて

oracle10G(10.2.0.1)をWin2003 SP2環境で使用しています。

あるテーブル（Ａテーブル）のデータ量が８００万件あり、そのテーブルを読み込むＳＱＬ（Ｂ.ＳＱＬ)が4分程度かかっていました。
ある日、Ａテーブルの項目名を変更することになりましたので、すべてのデータをＣＳＶ形式で保存し、テーブルをdropcreate後にsqlローダーにてインポートしたところ、Ｂ．ＳＱＬが１５分かかるようになってしまいました。
Ｂ．ＳＱＬは、項目名を変えただけで、インデックスも削除する前と同じ状態にしてます。
どこから調査すればよいのでしょうか？

よろしくお願いいたします。

No.5 ベストアンサー 回答者： uresiiwa 回答日時： 2009/01/16 22:56

統計について言及されていますが、B.SQLの実行計画を確認することも重要です。

現状とあわない統計に基づいて実行計画を立てていた場合、非効率な実行計画が表示されていたはずです。（800万行もあるのにROWSが1となるなど）

DBMS_STATSで解決したら良いですが、しなかった場合は、「コストベースで立てたプランが悪い実行計画となってしまった」ということが考えられます。コストベースだと、ほぼ同じデータでもある日突然遅くなることが十分考えられます。こっちの場合は、SQLにヒント句を組み込み、以前のような良い実行計画に誘導するやり方が考えられます。

もしくは、ダイレクパスロードのミスで主キーインデックスが壊れてしまい速度劣化するような場合などもありますが、いずれにしても、もしまだ遅かったら実行計画を出して分析してみてください。よく分からない時はここに実行計画を貼り付けたら皆さんがアドバイスくれるかと思います。

この回答へのお礼

ご回答ありがとうございます。
explain plan により実行計画を確認してみます。

お礼日時：2009/01/17 23:59

No.4 回答者： DB_eng 回答日時： 2009/01/15 15:27

動的サンプリングが働いてしまっていること、

及び統計情報をとることが書かれているので、
1点、補足します。
統計情報の取得コマンドですが、ANALYZEではなく、
DBMS_STATS.GATHER_TABLE_STATSにて行ってください。
CBO（コストベースオプティマイザ）が使用する統計情報は
ANALYZEコマンドではなく、DBMS_STATSが推奨されてます。
コマンドサンプルは、以下の通りです。
execute DBMS_STATS.GATHER_TABLE_STATS(
ownname=> 'SCOTT', <== スキーマ名
tabname=> 'EMP' , <== テーブル名
estimate_percent=> DBMS_STATS.AUTO_SAMPLE_SIZE, <== 左記のままか、1～100までの値。AUTOはORACLEまかせ、100であればより正確な統計値が得られる
cascade=> TRUE, <== その表に作成されている索引も取得
degree=> null <== 並列度。CPUが複数ある場合、指定すると取得時間が短縮される
);

この回答へのお礼

御回答ありがとうございます。
DBMS_STATSコマンドを実行してみます。

お礼日時：2009/01/15 16:54

No.3 回答者： 3rd_001 回答日時： 2009/01/14 18:01

まず、現状の実行計画をとりましょう。

アナライズは、実行計画を取ってからやりましょう。
でないと、どう変わったのかが判断できません。

また、今回は10gですので、現状がどうなっているかも調査してから対策を立てたほうが良いです。

もしかしたら、自動統計が取られているかもしれませんし、動的サンプリングで動いているのかもしれませんし、デフォルトの統計でうごいているかもしれません。
※Oracleの設定次第ですので、調べないとわかりません。

統計については以下を読んでから実施した方がよいです。
http://otndnld.oracle.co.jp/document/products/or …

この回答へのお礼

ご回答ありがとうございます。
早速実行してみます。

お礼日時：2009/01/14 20:42

No.2 回答者： mako_sea 回答日時： 2009/01/14 16:53

オラクルの統計情報は

ANALYZEコマンドで取得するようです。
ただしこの統計情報更新で改善するかは、
オプティマイザの設定にもよると思われます。

参考URL：http://itnavi.com/totteORA/Tips21.asp

この回答へのお礼

御回答ありがとうございます。
analyzeコマンドを実行してみます。

お礼日時：2009/01/14 16:56

No.1 回答者： wolf03 回答日時： 2009/01/14 15:26

コストベース検索である以上当然の事象です。

データを一気に入れたため、コスト最適化する統計情報が無い状態ですので遅いのです。
統計情報を何とかしない限り無理ですね。

この回答へのお礼

御回答ありがとうございます。
統計情報を何とかするというのは、しばらく実行を繰り返してから
再度統計情報を取得するということでしょうか？

お礼日時：2009/01/14 16:23