2

私は、Oracle データベースの 2 つのインスタンスを使用していoneますtwo。twoは よりも優れたハードウェア (ハードディスク、メモリ、CPU) で実行されておりone、 Oracle のバージョンに関してはtwoマイナー バージョンが 1 つ遅れoneています (両方とも 11g)。table_name両方とも、まったく同じインデックスが定義されたまったく同じテーブルを持っています。500,000 の同一の行をtable_name両方のインスタンスにロードします。次に、両方のインスタンスで実行します。

delete from table_name;

このコマンドは、 で完了するのに 30 秒、 で完了するのにone40 分かかりtwoます。2 つのテーブルで INSERT と UPDATE を実行すると、同様のパフォーマンスの違いがあります。2 つのデータベース間のパフォーマンスに劇的な影響を与える可能性があるものについて何か提案はありますか?

4

4 に答える 4

3

最初にインスタンス構成を比較します-名前を選択し、V $ PARAMETER ORDER BY NAMEから値を選択し、結果を両方のインスタンスのテキストファイルにスプールし、ファイル比較ツールを使用して違いを強調します。データベース名とファイルの場所による違い以外は調査する必要があります。極端な場合は、一方のデータベースにアーカイブロギングがなく、もう一方のデータベースに5つのアーカイブ先が定義されている場合があります。

データベースホスト上のファイルシステムにアクセスできない場合は、アクセスできる人を見つけて、セッションの開始時にトレースファイルとtkprofの結果を取得してもらい、ALTER SESSION SET sql_trace = trueを実行してから、削除を実行します。これにより、テーブルのトリガー（所有していない可能性があります）、監査などによる再帰SQLが公開されます。

于 2010-04-19T22:25:59.393 に答える
2

削除セッションの v$session の wait_class 列と event 列を監視できれば、遅延の原因についての手がかりが得られます。通常、完全なテーブルの DELETE はディスクにバインドされると予想されます (待機クラスの指示 I/O または構成)。テーブルからデータを読み取り (何を削除するかを認識します)、データ ブロックとインデックス ブロックを更新して、UNDO テーブルスペースと REDO ログに多くのエントリを生成するエントリを削除する必要があります。

本番環境では、基盤となるファイルが複数のディスク (SSD も含む) に分散している場合があります。開発/テスト環境では、それらすべてが 1 つのデバイスでスタックし、ディスク上で多くの頭の動きが発生して速度が低下する場合があります。SQL のジャンプはおそらく 10 倍になることがわかりました。あなたのものはそれよりも悪いです。

テーブル ['Concurrency' の wait_class] に同時アクティビティがある場合 (たとえば、他のセッションの挿入)、ロックの競合が発生するか、セッションが両方ともインデックスをハンマーしようとしている可能性があります。

于 2010-04-20T00:54:13.140 に答える
1

インスタンスtwoで何かが明らかに間違っています。これらの SO の質問とその回答をご覧になることをお勧めします。

特に：

  • インデックス化されていない外部キー参照がありますか (削除に時間がかかる理由 #1 -- AskTom のこのスクリプトを見てください)、
  • テーブルに ON DELETE TRIGGER はありますか?
  • インスタンス2で何らかのアクティビティがありますか(このテーブルが継続的に更新される場合、他のセッションによってブロックされる可能性があります)。
于 2010-04-20T07:59:42.133 に答える
1

注意してください: 私はデータベース管理者ではありません...

オフィスの窓に次のように書かれています。

緊急の場合は、オンコール DBA に次のことを依頼してください。

  1. プラン確認
  2. 実行統計
  3. 共有バッファー プールのフラッシュ

番号 2 および/または 3 は、通常、あるデータベースでは機能するが他のデータベースでは機能しないクエリ、または昨日は機能するが今日は機能しないクエリを修正します....

于 2010-04-19T22:49:36.413 に答える