問題タブ [xact-abort]

SQL Server 2005 での SET XACT_ABORT ステートメントのスコープは何ですか? つまり、begin-end ブロック、プロシージャまたはトリガー、接続、データベース、サーバー?

以前は、SQL Server のストアド プロシージャ内で次のコード スニペットを使用していました。

しかし、今日、「set xact_abort on」ステートメントを知りました。次のコードは前のコードと同等ですか? それらの間に違いはありますか？

おそらく私は何かを見逃していますが、RAISERROR以下の s の重大度が 16 (ドキュメントによると) であっても、トランザクションはXACT_ABORT ON効果がないかのようにまだコミットされています。

通話中

プロデュース

Msg 50000、Level 16、State 2、Procedure RemoveMember、Line 20
指定されたユーザーはこのグループの管理者ではありません
Msg 50000、Level 16、State 3、Procedure RemoveMember、Line 24
自分自身を削除することはできません

XACT_ABORTに設定されている場合、トランザクション全体をロールバックすることになっていると思いましたONか？

XACT_ABORT ON を TRY...CATCH コンストラクトと一緒に使用して、TRY ブロックでエラーが発生したときに CATCH ブロックでトランザクションをロールバックしようとすることについて、少し混乱しています。

私はこのように構造化されたストアドプロシージャを持っています（もちろんここでは単純化されています）：

したがって、SP は次のように動作するように意図されています。トランザクションがいずれかの時点で失敗した場合、ロールバックする必要があります。そのため、挿入ビットが失敗した場合、削除ビットをロールバックする必要があります。つまり、テーブルは以前と同じ状態にする必要があります。

ここで、実行時に dbo.fn_DoSomething() 関数が使用できないとします (DBA によって誤って削除されました)。上記の SP は期待どおりに動作します。つまり、トランザクションはロールバックされ、テーブルはそのまま残り、SSMS に表示されるエラー メッセージは次のようになります。

"メッセージ 208、レベル 16、状態 1、プロシージャ usp_clean_and_re_Insert、行 15 無効なオブジェクト名 'dbo.fn_DoSOmething'. "

しかし、何らかの理由で CATCH ブロックからの PRINT ステートメントが実行されないようです。つまり、SSMS でそれらを見ることができませんか? TRY...CATCH に関する Microsoft のドキュメントによると、TRY ブロックでの実行中にエラーが発生した場合、実行は CATCH ブロックに渡されます ( https://msdn.microsoft.com/en-us/library/ms175976(v=sql .90).aspx )。

ただし、XACT_ABORT ON を削除すると、事態はさらに奇妙になります。

1. PRINT ステートメントがまだ SSMS に表示されない

2. 上記と同じエラーが正しく表示されます。

"メッセージ 208、レベル 16、状態 1、プロシージャ usp_clean_and_re_Insert、行 15 無効なオブジェクト名 'dbo.fn_DoSOmething'. "

3. 次のような最終エラーがあります。

「メッセージ 266、レベル 16、状態 2、手順 usp_clean_and_re_Insert、EXECUTE 後の行 52 トランザクション数は、COMMIT または ROLLBACK TRANSACTION ステートメントが欠落していることを示しています。前の数 = 0、現在の数 = 1。」

これにより、SSMS (SP が実行されたクエリ ウィンドウ) を切断するまでテーブルがロックされます。その後、すべての結果がそのままの状態でテーブルが再び使用可能になります (したがって、DB エンジンはコミットできないトランザクションを暗黙的にロールバックする必要があります)。

このエラー メッセージに関する他の投稿 (次のようなもの: Transaction count after EXECUTE shows a mismatched number of BEGIN and COMMIT statement. Previous count = 1, current count = 0 ) を読んで、CATCH ブロックの XACT_STATE を確認する必要があることを理解しました。コミット不可能なトランザクションをロールバックします（これはhttps://msdn.microsoft.com/en-us/library/ms189797.aspxからの同じアドバイスです）が、これはまさに私が上記の SP で行ったことであり、トランザクションSSMS を切断するまで (XACT_ABORT ON なしで) ロールバックされませんか?

私は混乱しています！要約すれば：

1. SSMS に PRINT ステートメントが表示されないのはなぜですか?

2. ストアド プロシージャから XACT_ABORT ON を削除すると、CATCH ブロックの ROLLBACK TRANSACTION が実行されないのはなぜですか?

3. XACT_ABORT ON が単独で機能するように見えるのに、なぜ TRY...CACTH を使用するのでしょうか。つまり、Try..catch を削除して XACT_ABORT を ON のままにすると、トランザクションがロールバックされるので、catch ブロックで暗黙の ROLLBACK TRANSACTION を使用して TRY CATCH が必要になるのはなぜですか?

個々のエラーをキャッチしてログに記録するために、複数の TRY/CATCH ブロックを使用する大規模なストアド プロシージャがあります。また、途中でエラーが発生した場合に全体をロールバックできるように、プロシージャの内容全体をトランザクションでラップしました (面倒なクリーンアップを防ぐため)。XACT_ABORT が有効になっているのは、トランザクション全体をロールバックしないためです。

重要なコンポーネント:
私のデータベースには、この手順が実行されるたびにレコードが挿入され、操作の結果と問題の詳細が含まれるテーブルがあります。

面白いことが起こっています-実際、何が間違っているのかを最終的に理解したとき、それはかなり明白でした...ログテーブルへの挿入ステートメントもロールバックされているため、これをSSMSから実行していない場合、ロールバックによってアクティビティの痕跡がすべて削除されるため、これが実行されたことさえ確認できません。

質問:
この単一の挿入ステートメントを除いて、トランザクション全体をロールバックすることは可能でしょうか? ストアド プロシージャの実行中にコンパイルしたエラー メッセージを保持したいと思います。

本当にありがとう！

〜エリ

更新 6/28
これは私が見ているもののコードサンプルです。これと @Alex および @gameiswar によって提示されたサンプルとの主な違いは、私の場合、try/catch ブロックがすべて単一のトランザクション内にネストされていることです。これの目的は、(複数のテーブルに対して) 複数のキャッチを取得することですが、最後の更新が失敗した場合でも、混乱全体がロールバックされるようにします。

私はSQLServer 2014を使用しており、IDとデータと呼ばれるvarchar列を持つ1つのテーブルを持つ単純なデータベースを持っています。次のステートメントを実行すると、奇妙な動作が発生します。

SSMS は、呼び出しで間違ったクエリを実行しようとしたため、エラーが発生したことを示していますsp_executesql。ただし、 も示しています1 row(s) affected。testTable で選択クエリを実行すると、値 'b' が挿入されていることがわかります。

ステートメントをTRY/CATCHブロックでラップすると、すべてが期待どおりに機能し、トランザクション アクション全体がロールバックされます。

SET XACT_ABORT ON何か問題が発生した場合、トランザクション全体がロールバックされることを保証するべきではありませんか? 不足している設定はありますか？

ありがとう

SET XACT_ABORTコマンドの目的を理解しています。

SET XACT_ABORT が ON の場合、Transact-SQL ステートメントで実行時エラーが発生すると、トランザクション全体が終了し、ロールバックされます。

SET XACT_ABORT が OFF の場合、場合によっては、エラーを発生させた Transact-SQL ステートメントのみがロールバックされ、トランザクションは処理を続行します。エラーの重大度によっては、SET XACT_ABORT が OFF の場合でも、トランザクション全体がロールバックされる場合があります。オフがデフォルト設定です。

一般に、エラーが発生した場合にトランザクションの処理を続行したいシナリオよりも、エラーが発生した場合にトランザクション全体をロールバックしたいシナリオよりも数が多くなります。これは、DBA やブログがSET XACT_ABORT ON一貫性のないトランザクションに遭遇しないように継続することを推奨しているのをよく耳にするためです。結果。SET XACT_ABORT ONテンプレート化されたコードの一部として、すべてのストアド プロシージャにも が含まれているのを見てきました。

質問:

1. ユース ケースのほとんどXACT_ABORTが. をデフォルトにすると、SQL Server トランザクション処理にオーバーヘッドが追加されましたか?ONOFFXACT_ABORTON

2. このSET XACT_ABORTコマンドは、現在のセッションのみに影響します。この画像に示すように、 SSMS のデフォルトをSET XACT_ABORT ONfromにすることができることはわかっ ています。これらの手順については、すべての手順で繰り返す必要があります。データベースレベルで設定できる方法はありますか? グローバルに設定でき、毎回心配する必要がない他の方法はありますか?SSMS > Tools > Options > Query Execution > SQL Server > AdvancedSET XACT_ABORT ONXACT_ABORTONXACT_ABORT

暗号化された列 (Always Encrypted) から変数にデータを選択するストアド プロシージャがエラーで失敗する

セッションが強制終了状態のため、実行を続行できません

がオンに設定されている場合XACT_ABORT。

行を削除SET XACT_ABORT ON;すると、ストアド プロシージャは完全に機能しますが、それがどのように関連しているかは不明です。

変数を完全に削除すると、エラーも修正されます。

環境：

• Microsoft SQL Server 2016 Enterprise (64 ビット) Service Pack 2 with CU2 (13.0.5153.0): 現時点での最新ビルド。
• Microsoft Windows NT 6.3 (15063)

ストアド プロシージャ:

テーブル宣言:

サンプルデータ：

ストアド プロシージャを呼び出します。

エラー：

メッセージ 596、レベル 21、状態 1、行 29
セッションが強制終了状態であるため、実行を続行できません。

メッセージ 0、レベル 20、状態 0、行 29
現在のコマンドで重大なエラーが発生しました。結果がある場合は、破棄する必要があります。

XACT_ABORT と Always Encrypted がどのように関連しているかについての参照は見つかりませんでした。

SQL Server のログも確認しましたが、問題に関する追加情報は見つかりませんでした。

更新：

登録された SQL Server バグへのリンク