Function / ProcedureでのDML操作後にコミットが必要ですか？

function / procedureでinsert / delete / updateの後にcommitを書く必要があるかどうか知りたいのですが？

例：

create or replace function test_fun
return number is
begin
   delete from a;
   return 0;
end;

または手順

create or replace procedure aud_clear_pro
as
begin
   delete from a;
end;

削除後にコミットする必要がありますか？

次の状況を理解できません。

SQLウィンドウから関数/プロシージャを呼び出す場合、コミットが必要です

しかし
dbms_schedulerを使用して関数/手順をスケジュールし、ジョブを実行すると、deleteステートメントが自動的にコミットされます。

どうして？

— クパ
ソース

回答:

一般に、プロシージャはコミットしないでください。これらの種類のトランザクション制御の決定は、論理トランザクションが実際にいつ完了するかを知っている高レベルのコードに任せるべきです。ストアドプロシージャ内でコミットする場合、プロシージャが行う変更をより大きなトランザクションの一部にすることを望む呼び出し側は、単にプロシージャを直接呼び出すことができないため、その再利用性を制限しています。

プロシージャを対話的に呼び出す場合、プロシージャコールを論理トランザクションにするか、複数のプロシージャコールを含むより大きなトランザクションを作成するかはOracleにはわからないため、トランザクションを明示的にコミットまたはロールバックする必要があります。あなたが使用している場合はdbms_scheduler、dbms_schedulerジョブは論理的な取引であり、それは成功したと仮定すると、ジョブの終了（にコミットすることを前提としてdbms_job同じことを）。

そもそも関数はデータを操作しないでください。データを操作する関数は、SQLステートメントから呼び出すことはできません（関数自体がほとんど適切ではない自律型トランザクションを使用すると宣言されている場合を除き）。関数とプロシージャの両方を使用することの全体的なポイントは、関数がSQLステートメントに埋め込まれ、データを変更しないため、ユーザーにより自由に付与できることです。

— ジャスティン洞窟
ソース

Oracleでは、呼び出し元がプロシージャ呼び出しをバインドするトランザクションを開始することはできませんか？SQL Serverでは、プロシージャ内でコミットできますが、そのプロシージャを呼び出す前に呼び出し側がトランザクションを開いた場合、呼び出し側もコミットするまで何もコミットされません。

— ニックチャマス

@NickChammas-Oracleにはネストされたトランザクションの概念がありません。プロシージャがコミットすると、その時点までに呼び出し側が行ったすべてがコミットされます。呼び出し側は常に最初のステートメントで暗黙的にトランザクションを開始します（それはプロシージャコールか何か）ので、トランザクションを終了するのは常に呼び出し側次第です。

— ジャスティンケーブ

@JustinCaveそれは本当ですが、自律的なトランザクションを忘れないでください。

— フィリ

@Phil-本当ですが、それは非常に異なる動物です。自律型トランザクションは、呼び出し元によって行われたコミットされていない変更を確認できず、呼び出し元によってロールバックできないため、ロギングプロシージャ以外のものが自律型トランザクションを使用するように宣言されることはほとんどありません。

— ジャスティンケーブ

あなたの質問に答えるために; どうして？

投稿は2年前なので、おそらく既にご存知でしょう。しかし、私は記録のためだけに応答します。

Oracleのデフォルトのデータベース設定は、セッションが終了したときにトランザクションをコミットすることであるため、＃1はコミットを必要とし、＃2は必要ありません。sqlplusでコードを手動で実行すると、すぐにトランザクションがコミットされません。明示的なコミットを発行するか、sqlpusからログオフすると、トランザクションがコミットされます。

＃2で自動コミットを取得する理由は、スクリプトを実行するセッションを作成するためです。完了すると、自動的にログオフされ、自動コミットが発生します。

— スティーブ・カニンガム
ソース