2 つの CLOB フィールドを含むテーブルから行を削除しようとすると、Oracle が非常に遅くなるという問題が発生しています。テーブルには何百万もの行があり、制約はなく、削除は主キーに基づいています。インデックスを再構築し、統計を再計算しましたが、役に立ちませんでした。
このテーブルからの削除のパフォーマンスを改善するにはどうすればよいですか?
待機を有効にしてトレースする
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_monitor.htm#i1003679
UDUMP ディレクトリでトレース ファイルを見つけます。それをTKPROF。最後を見ると、その SQL 中にデータベースが何に時間を費やしたかがわかります。次のリンクは、パフォーマンスの問題を分析する方法の概要です。
http://www.method-r.com/downloads/doc_download/10-for-developers-making-friends-with-the-oracle-database-cary-millsap
UNDO
この場合、テーブルスペースがボトルネックになっているようです。
ROLLBACK
データ削除後の作成にかかる時間を確認してください。クエリ自体の時間(内)に匹敵する時間がかかる場合50%
、これは確かに当てはまります。
クエリを実行するDML
と、データ(元のデータと変更されたデータの両方)がREDOログに書き込まれ、データファイルとUNDO
テーブルスペースに適用されます。
数百万行を削除CLOB
するには、ギガバイトではないにしても数百メガバイトをUNDO
表領域にコピーする必要があり、それ自体に数十秒かかります。
これについて何ができますか?
UNDO
:別のディスクに配置し、まばらさを減らします(より大きなデータファイルを作成します)。ROLLBACK SEGMENTS
管理対象の代わりに使用し、このクエリにをUNDO
割り当てて、クエリを実行する前にROLLBACK SEGMENT
発行SET TRANSACTION USE ROLLBACK SEGMENT
します。そうでない場合、つまりクエリ自体よりもはるかにROLLBACK
高速に実行される場合は、パラメータを試してみてください。REDO
REDO
パラメータを使用してバッファサイズを増やしますLOG_BUFFER
。UNDO
操作も生成するREDO
ので、とにかくこれをすべて行うと便利です。
NOLOGGING
ここにリストされている特定の操作セットにのみ適用されDELETE
、それらの操作の1つではないため、前にアドバイスされたものは役に立ちません。
Oracle では、行を削除するときに生成する REDO の量を考慮する必要があります。CLOB フィールドが非常に大きい場合、書き込まれる REDO の量が原因で Oracle がそれらを削除するのにしばらく時間がかかり、できることはあまりない可能性があります。
実行できるテストは、両方の CLOB フィールドが null に設定されている行で削除に時間がかかるかどうかを確認することです。その場合は、インデックスの更新に時間がかかっている可能性があります。その場合、削除が非常に頻繁に発生する場合は、可能であればインデックスの統合を調査する必要があります。
テーブルが派生テーブルである場合、つまり、他のテーブルから再構築できる場合は、テーブルの NOLOGGING オプションを調べることができます。最小限のロギングで、ソース テーブルからテーブルを再構築できます。
このエントリが少しでも役立つことを願っていますが、さらに詳細な情報が問題の診断に役立つ可能性があります。
削除されたCLOBは、バージョン管理されてLOBセグメントに保持されているため、UNDOTBSに含まれません。元にすると、LOBINDEXの変更がいくつか生成されると思います。
以前にLOBをヌルまたは空にした場合、実際にDELETEとは別にコミットを使用してその時間を測定しましたか?何千もの削除を発行する場合、バッチコミットを使用しますか?インスタンスはアイドル状態ですか?次に、AWRレポートは何が起こっているかを教えてくれるはずです。