I understand the purpose of SET XACT_ABORT command:
When SET XACT_ABORT is ON, if a Transact-SQL statement raises a run-time error, the entire transaction is terminated and rolled back.
When SET XACT_ABORT is OFF, in some cases only the Transact-SQL statement that raised the error is rolled back and the transaction continues processing. Depending upon the severity of the error, the entire transaction may be rolled back even when SET XACT_ABORT is OFF. OFF is the default setting.
In general, the scenarios where one would want to continue processing a transaction if error would be outnumbered by the scenarios where one would want to rollback the entire transaction if error, because I often hear DBAs and blogs recommending to keep SET XACT_ABORT ON to avoid running into inconsistent transaction results. I have seen all our stored procedures also have SET XACT_ABORT ON, as part of the templated-code.
Quesions:
If most of the use cases require
XACT_ABORTto beON, what would have lead SQL Server to default it toOFF? Would defaultingXACT_ABORTtoONhad added any overhead to SQL Server transaction processing?The
SET XACT_ABORTcommand affect only the current sessions. I know I can make SSMS default toSET XACT_ABORT ONfromSSMS > Tools > Options > Query Execution > SQL Server > Advancedas shown in this image:
But this is limited to only for the SQL statements running through SSMS and does not help with stored procedures called through application code/SSIS packages . For those procedures I still have to repeat SET XACT_ABORT ONin every procedure. Is there any wayXACT_ABORTcan be set toONat database level? Any other ways I can set theXACT_ABORTglobally and don't have to worry about it every time?
