ループ内でコミットすることは一般的に悪い考えです（したがって、任意のツールが自動的にコミットできるようにします）。
ループ内でコミットすると、再起動可能なコードを書くのがはるかに難しくなります。 3回繰り返した後にエラーが発生した場合はどうなりますか？これで、2つのUPDATEの結果が正常にコミットされました。 ステートメント。おそらく、どの行が更新されたかを把握し、更新を元に戻すコードを記述するか、これら2つの成功したyearidのデータの更新を回避するコードを追加する必要があります。 値。それは確かに可能です。しかし、それはあなたの進歩を追跡するためにたくさんのコードを書くことを含み、そして一般的にあなたのコードをはるかに複雑にします。
ループ内でコミットすると、コードがはるかに遅くなります。コミットは一般的にかなり費用のかかる操作です。したがって、ループでそれを行うことは、一般的に悪い考えです。ループの反復が数十回しかない場合は、それほど問題にはなりません。しかし、数百または数千の反復がある場合、時間の大部分をコミットに費やしてしまう可能性があります。
ループ内でコミットすると、ORA-01555エラーが発生するリスクが大幅に高まります。 MyTableに対するクエリ データの読み取り一貫性のあるビューが必要です。ただし、ループ内でコミットすると、セッションに古いUNDOが不要になったことをOracleに通知することになります。 データ。 OracleがたまたまUNDOをパージした場合 ループの後続の反復に必要なデータは、エラーが発生します。そして、N回の反復を正常に実行したが、どの年が処理されたか、またはどの年を処理する必要があるかわからない、再起動不可能なコードの処理に戻ります。
ループ内でコミットすると、データの整合性の問題が発生する可能性があります。たとえば、他のセッションがレポートを実行している場合、それらのレポートは部分的に更新されたデータを簡単に確認できます。これは、データに一貫性がないことを意味することがよくあります。 3年間のデータが変更されたが、他の年は変更されていない場合、レポートを理解するのは非常に困難であり、人（またはプロセス）は簡単に誤った決定を下す可能性があります。
ループ内でコミットすると、コードの再利用性も低下します。コードにコミット（またはブロック内で確立したセーブポイント以外のロールバック）が含まれている場合、トランザクションをまだコミットしたくない他のコードからコードを呼び出すことはできません。そのため、トランザクション制御なしでロジックを再実装しようとしたり、トランザクションの整合性に誤って違反したりすることになり、必然的にデータの整合性の問題を引き起こすアプリケーションを構築することになります。