変更をいつコミットするか?

Question

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

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

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

• それは速いのか遅いのか、それともそれによって異なります (新しい負荷の適切なシミュレーションが得られ次第、双方向のベンチマークを計画しています)
• なぜそれがパフォーマンスに役立つのか、またはパフォーマンスを妨げるのか。
• 「それは...による」のなら、何に依存しますか？
• それが役立つ場合、N の最適な値は何ですか?
• 必要なときに、地元の DBA が役立つ明確な答えを提供できないのはなぜですか?
  (実際、私はその答えを知っています) :-)

編集：

@コードスレーブ:おかげで、ところで、コミットされていない変更を失うことは問題ではありません。すべてが問題ないと確信しているまで更新に使用された元のデータを削除しません。

いくつかのグーグルは、ロールバックセグメントに関連する問題のためにそれが役立つかもしれないことを示しましたが、私はまだ数十年ごとにnの経験則を知りませんか？何百？千 ？

@diciu :素晴らしい情報、私は間違いなくそれを調べます。

Answer 1

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

Oracle 10g には非同期コミットがあり、これにより速度は大幅に向上しますが、信頼性は低くなります。 https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-6158695.html

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

Answer 2

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

Answer 3

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

Answer 4

「すべてが問題ないと確信するまで、更新に使用した元のデータを削除しない」のであれば、その間にある増分コミットをすべて削除し、問題があればロールバックすればよいのではないでしょうか?トランザクションの上にトランザクション システムを効果的に構築しているようですね。

Answer 5

@CodeSlaveあなたの質問は@stevecholによって答えられます。すべての増分コミットを削除するとロックが発生します。これより良いものが見つからない場合は、彼のアドバイスに従い、乱数を選択し、負荷を監視し、それに応じて調整することになると思います。@diciu の微調整を適用しながら。

追伸：トランザクションの上にあるトランザクションは単なる偶然です。FTP で更新に使用されるファイルを取得し、すぐに削除するのではなく、1 週間後に削除するように cron ジョブを設定しました (アプリケーションを使用している誰も苦情を言っていない場合)。エラーが発生する エラーを見つけるのに 1 週​​間かかります。

Answer 6

速い/遅い?

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

なぜ役立つのでしょうか?

明らかにコミット操作が減り、その結果、ディスクへの書き込みなどが減ります。

DBA の答えは何ですか?

それが簡単であれば、必要ありません。