データをテーブルにロードし、同時にクエリを実行する必要があります。データの性質上、整合性とパフォーマンスを犠牲にすることができます。トランザクションのオーバーヘッドを最小限に抑えるにはどうすればよいですか?
残念ながら、MySQL などの代替手段は使用できません (非技術的な理由により)。
データをテーブルにロードし、同時にクエリを実行する必要があります。データの性質上、整合性とパフォーマンスを犠牲にすることができます。トランザクションのオーバーヘッドを最小限に抑えるにはどうすればよいですか?
残念ながら、MySQL などの代替手段は使用できません (非技術的な理由により)。
テーブル内のすべての制約を無効にしてから、すべてのデータを挿入してから、再度有効にしてみてはどうでしょうか。
つまり、セッションセットの制約を変更します= deffered;
ただし、テーブルの作成時にテーブルの制約をdefferableに設定しなかった場合は、わずかな問題が発生する可能性があります。
おそらく私は何かを見逃していますが、Oracleではリーダーはライターをブロックせず、ライターはリーダーをブロックしないため、解決しようとしている問題は正確には何ですか?
データを読み取っているセッションの観点からは、挿入を行っているセッションは実際にはオーバーヘッドを追加していません (リーダーがデータを再構築するために UNDO テーブルスペース内のデータを参照する必要があるため、更新によってオーバーヘッドが少し追加される可能性があります)。データの読み取り一貫性のあるビュー)。データを挿入しているセッションの観点からは、読み取りを行っているセッションは実際にはオーバーヘッドを追加していません。もちろん、システム全体にボトルネックがあり、さまざまなセッションがリソースを競合する可能性があります (つまり、挿入が使用可能な I/O 帯域幅の 100% を使用している場合、実行する必要があるクエリの速度が低下します)。物理 I/O) ですが、そうではありません。
全テーブル スキャンの排除、未使用または非効率的なインデックスの削除など、すべてのデータベースに適用される一般的な最適化プラクティス以外に、実行できることがいくつかあります。
No Archive Log
ます。これは、速度のために回復可能性を犠牲にします。/*+ APPEND */
ヒントを使用します。これにより、UNDO が作成されないハイ ウォーター マークより上のテーブルにデータが配置されます。欠点は、既存の空き領域が使用されないことです。RAID 0
は、多数の小さなディスクを使用すると最高の挿入パフォーマンスが得られますが、使用状況によっては、RAID 10
読み取りパフォーマンスが向上するため、より適している場合があります。とはいえ、これらの変更のいずれからも多くのメリットが得られるとは思いません。
トランザクション分離を非コミットで読み取りたい。私はそれをお勧めしませんが、それはあなたが求めたものです:)
これにより、トランザクションの分離に違反し、コミットされていない挿入データを読み取ることができます。
この Ask Tom の記事を読んでください: http://www.oracle.com/technology/oramag/oracle/05-nov/o65asktom.html。
更新:私は実際に間違っていました.Oracleはコミットされていない読み取り分離レベルを実際にはサポートしていません.彼らはそれについて言及しているだけです:)。
どのようなパフォーマンスボリュームを見ていますか? インサートはバッチ処理されていますか、それとも多数の小さなインサートですか?
頭を壁にぶつけて優れたパフォーマンスを実現するための巧妙な方法を考え出す前に、すぐに使えるパフォーマンスをよりよく把握できる簡単なプロトタイプを作成しましたか? 目標を達成するために特別なことをする必要がないことは簡単にわかります。