バッチ更新のレスポンスが悪い原因について

解決済

質問者：ryozyryozy
質問日時：2009/01/21 14:53
回答数：5件

いつもお世話になっております。
10gの2003Serverの環境ですが、ある業務パッケージで用意されているインターフェースにて、COBOLソースで25万件程のテーブルをリードして物理ワークファイルにライトし、更にそのファイルより別のオラクルテーブルにライトを行っているのですが、リードで約２時間、ライトに約５時間もかかってしまいます。試しに一人ずつ(350人×700件=約25万)画面にディスプレイしてみると最初の30分で80人分程処理しておりますが途中から急激に遅くなり一人につき5分以上かかってきます。

当然ながらCOBOLの読み書きするロジックに原因があると思っておりソースを追いかけておりますが、不思議なことに他ユーザーの9iの環境で同アプリを実行するとものの15分程で読み書きが終わってしまいます。データの内容は異なるでしょうが件数的にはほとんど変わりません。
従って、平行してオラクル側でも調査したいのですが、具体的に何をどうすればよいのか、情報が少なくて申し訳ないですが、何かヒントでもいただけないでしょうか？
何卒よろしくお願いします。

通報する

この質問への回答は締め切られました。

質問の本文を隠す

回答 (5件)

ベストアンサー優先
最新から表示
回答順に表示

No.5ベストアンサー

回答者： uresiiwa
回答日時：2009/01/23 07:57

10gではこの処理以外は良好な速度で稼動しているのですかね？

10gと9iの環境で処理時間が劇的に違いすぎる感じですね。
10gと9ｉは同じマシンではないですよね？
テスト中のCPU、メモリの稼動状況も比較確認してみたほうがよいです。

ホスト的に問題なしであれば、
１．STATSPACKレポートで7時間のうち、主に「何の処理」をしていたか調べる
２．１の結果で改善箇所が明確にならない場合は、SQLトレースを取る
ということをすれば悪い箇所が明確になると思います。
３．２の結果で非常に遅いSQLがあった場合、実行計画を表示して分析する

という流れになるかと思います。

- 0
- 件

通報する

この回答へのお礼

返事遅くなりました。
ご回答どうもありがとうございました。
STATSPACKレポート等勉強してみます。

通報する

お礼日時：2009/01/27 23:29

No.4

回答者： ossan_hiro
回答日時：2009/01/22 10:13

Oracleの情報を収集するのであればstatspackというツールを使って情報収集することができます（参考URLのリンク先を参照のこと）。

ただ、このレポートはOracleに詳しい方がいないと解析は難しいと思います。

9iだと早く10gだと遅いということですが、バージョンの違いのほかにDB構造は同じでしょうか？
メモリの割り当て、REDOログのサイズ、UNDO（ROLLBACK）セグメントのサイズ、一時表領域のサイズ等は同じなのでしょうか？

DB以外にもOSの状況（CPUとかDISKの空き容量とか）も確認したほうがいいと思います。

参考URL：http://otn.oracle.co.jp/skillup/stats_diag/1/ind …

- 0
- 件

通報する

この回答へのお礼

＞Oracleの情報を収集するのであればstatspackというツールを使って情報収集することができます（参考URLのリンク先を参照のこと）。
ただ、このレポートはOracleに詳しい方がいないと解析は難しいと思います。

ありがとうございます。一度勉強してみようと思います。

＞9iだと早く10gだと遅いということですが、バージョンの違いのほかにDB構造は同じでしょうか？
メモリの割り当て、REDOログのサイズ、UNDO（ROLLBACK）セグメントのサイズ、一時表領域のサイズ等は同じなのでしょうか？

おそらく同一パッケージですので、サイズは同等だと思われます。バージョンに起因しているものではないと考えます。

通報する

お礼日時：2009/01/23 01:30

No.3

回答者： nora1962
回答日時：2009/01/21 23:39

http://www.atmarkit.co.jp/fdb/rensai/orasql04/or …
あたりが参考になるかも。
これでひっかからない時は初期化パラメータ「cursor_sharing」を
「similar」にして再度試してみてください。
これで、負荷の高いSQLをピックアップできると思います。
「EXPLAIN」コマンドで実行計画を取得できるのでは。