相关疑难解决方法(0)

SET XACT_ABORT ON在存储过程中使用有什么好处？

如果你小心并且在所有内容周围使用TRY-CATCH,并且你真的需要使用以下错误回滚:

SET XACT_ABORT ON

换句话说,是否有任何错误,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,也可以回滚整个事务.OFF是默认设置.

一般情况下,如果出现错误,那么人们希望继续处理事务的情况会超出人们希望在错误时回滚整个事务的情况,因为我经常听到DBA和博客建议继续SET XACT_ABORT ON避免遇到不一致的事务结果.SET XACT_ABORT ON作为模板化代码的一部分,我已经看到所有存储过程也有.

Quesions:

1. 如果大部分的用例需要的XACT_ABORT是ON什么将会导致SQL Server以它默认为OFF？默认XACT_ABORT会ON为SQL Server事务处理增加任何开销吗？

2. 该SET XACT_ABORT命令仅影响当前会话.我知道我可以SSMS默认为SET XACT_ABORT ON从SSMS > Tools > Options > Query Execution > SQL Server > Advanced如图所示在此图像中: 但这仅限于通过SSMS运行的SQL语句,并且对通过应用程序代码/ SSIS包调用的存储过程没有帮助.对于那些程序,我仍然需要SET XACT_ABORT ON在每个程序中重复.有没有办法在数据库级别XACT_ABORT设置ON？我可以设置XACT_ABORT全局的其他任何方式,而不必每次都担心吗？

我有这个交易:

BEGIN TRAN;
Update Job set JobTitle = 'wonderfullivin' where JobId = 1271;
Update Job set LastTransactionDate = null where JobId = 1271;
COMMIT;

其中第二个语句必须失败,因为LastTransactionDate设置为NOT NULL.当我查看事务日志时,我看到事务已提交.它不应该被中止,因为其中一个查询失败了吗？