sql - いつ変更をコミットしますか?

Question

Perl DBI 経由でアクセスする Oracle 10g を使用すると、数千万行のテーブルがあり、1 秒あたり数回更新され、別のプロセスからより頻繁に読み取られます。

すぐに、更新頻度が 1 桁 (おそらく 2 桁) 増加します。更新ごとにコミットするのではなく、N 個の更新ごとにコミットすることでパフォーマンスが向上すると誰かが提案しました。

いくつかの質問を聞きたいんです：

• それはより速いか遅いか、または依存します（新しい負荷の適切なシミュレーションを取得できるようになり次第、両方の方法でベンチマークを実行する予定です）
• なぜそれがパフォーマンスを助ける/妨げるのか.
• 「場合による」場合は、何に基づいていますか?
• それが役立つ場合、 N の最良の値は何ですか?
• 地元の DBA は、必要なときに有益な率直な回答を提供できないのはなぜですか?
  (実際、私はその答えを知っています) :-)

編集：

@codeslave : ありがとうございます。ところで、コミットされていない変更を失うことは問題ではありません。更新に使用された元のデータは、すべて問題がないことを確認するまで削除しません。ところで、掃除婦はサーバーのプラグを抜きました。2 回 :-)

いくつかのグーグルは、ロールバックセグメントに関連する問題のために役立つ可能性があることを示しましたが、数十ごとに N の経験則はまだわかりませんか? 何百？千 ？

@diciu : すばらしい情報です。必ず調べます。

Answer 1

コミットの結果、Oracle はディスク (つまり、REDO ログ ファイル) に内容を書き込みます。これにより、コミット中のトランザクションが実行した内容は、電源障害などの場合に回復可能になります。ファイルへの書き込みは、メモリへの書き込みよりも遅いため、 commit は、結合された一連の更新ではなく、連続して多くの操作に対して実行されると遅くなります。

Oracle 10g には非同期コミットがあり、高速化されますが信頼性が低下します: https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-6158695.html

PS 特定のアプリケーションで見たシナリオでは、結合された更新の数を 5K から 50K に変更すると、1 桁 (10 倍) 高速になることは確かです。

Answer 2

コミットの頻度を減らすと、確かに処理が高速化されますが、このテーブルを頻繁に読み書きしているため、ロックが発生する可能性があります。同じデータが同時に更新される可能性を判断できるのはあなただけです。この可能性が低い場合は、50行ごとにコミットし、状況を監視します。試行錯誤私は恐れています:-)

Answer 3

コミットの頻度を減らすだけでなく、個々の更新ではなく一括更新を実行することも検討する必要があります。

Answer 4

「すべてが正常であることが確実になるまで、更新に使用された元のデータを削除しない」場合は、その間のすべての増分コミットを削除し、問題が発生した場合はロールバックしてみませんか？トランザクションの上にトランザクションシステムを効果的に構築したようです。

Answer 5

@CodeSlaveの質問には、@ stevecholが回答します。すべての増分コミットを削除すると、ロックが発生します。彼のアドバイスに従って乱数を選び、負荷を監視し、それに応じて調整します。@diciutwaksを適用している間。

PS：トランザクションに加えてのトランザクションは偶然です。FTPで更新に使用されるファイルを取得し、すぐに削除するのではなく、1週間後に削除するようにcronジョブを設定しました（アプリケーションを使用している人が誰も文句を言っていない場合）。何か問題が発生した場合は、エラーをキャッチするために1週間あります。

Answer 6

速い/遅い？

おそらくもう少し速くなるでしょう。ただし、デッドロックに陥るリスクが高くなり、壊滅的な事態 (掃除婦がサーバーのプラグを抜く)、FUD、火災、ブリムストーンなどの場合に、コミットされていない変更が失われます。

なぜそれが役立つのですか？

コミット操作が明らかに少なくなるため、ディスクへの書き込みなどが少なくなります。

DBAと率直な答えは？

それが簡単だったなら、あなたはそれを必要としません。