まず、構文エラーは無視できると思います（たとえば、END LOOPはありません。 、dbms_output.put_line 呼び出しに最初の一重引用符がないなど）
変更をロールバックする必要があるかどうかについては、状況によって異なります。
一般に、ループ内に中間コミットはありません。これは、I / Oと経過時間の点ではるかにコストがかかるため、一般的に貧弱なアーキテクチャです。また、再起動可能なコードを書くのがはるかに難しくなります。たとえば、SELECT ステートメントが10行を選択し、5つの更新を発行（およびコミット）した後、6番目の更新が失敗しますか？例外を修正した後、6行目から再開できる唯一の方法は、コードの進行状況を保存（および更新）する別のテーブルを用意することです。また、このブロックを呼び出すコードで問題が発生し、作業の半分が実行され（そしてコミットされ）、残りの半分が実行されなかった場合を処理する必要があります。
一般に、トランザクション制御ステートメントは、コードの最も外側のブロックにのみ配置します。 COMMIT以降 またはROLLBACK プロシージャでは、プロシージャによって実行されたかどうかに関係なく、セッションで実行された作業をコミットまたはロールバックするため、トランザクション制御ステートメントの追加には十分注意する必要があります。通常は、発信者にコミットするかロールバックするかを決定させます。もちろん、これまでのところ、最終的には、他のルーチンから呼び出されることのない最も外側のブロックに移動し、適切なトランザクション制御が必要になりますが、非常に注意が必要です。再利用される可能性のあるコードを書いているかどうかについて。
この場合、暫定的なコミットがあるため、ROLLBACKの唯一の効果は 最初の更新ステートメントが失敗した場合、このブロックを呼び出す前にセッションで実行された作業がロールバックされます。最初の更新ステートメントが成功した場合、暫定コミットはそれらの以前の変更をコミットします。これは、再利用可能なブロックでの中間コミットとトランザクション制御が問題となる理由について話すときに人々が心配する一種の副作用です。