[sql] 저장 프로 시저에서 “SET XACT_ABORT ON”을 사용하면 어떤 이점이 있습니까?

내 생각에 SET XACT_ABORT ON은 SQL 2k5에서 BEGIN TRY / BEGIN CATCH를 추가하여 폐기되었습니다. Transact-SQL의 예외 블록 이전에는 오류를 처리하기가 실제로 어려웠으며 균형이 맞지 않은 프로 시저가 너무 흔했습니다 (항목과 종료시 @@ TRANCOUNT가 다른 프로 시저).

Transact-SQL 예외 처리를 추가하면 트랜잭션의 균형을 올바르게 유지할 수있는 올바른 프로 시저를 훨씬 쉽게 작성할 수 있습니다. 예를 들어 예외 처리 및 중첩 트랜잭션 에이 템플릿을 사용 합니다 .

create procedure [usp_my_procedure_name]
as
begin
    set nocount on;
    declare @trancount int;
    set @trancount = @@trancount;
    begin try
        if @trancount = 0
            begin transaction
        else
            save transaction usp_my_procedure_name;

        -- Do the actual work here

lbexit:
        if @trancount = 0   
            commit;
    end try
    begin catch
        declare @error int, @message varchar(4000), @xstate int;
        select @error = ERROR_NUMBER(), @message = ERROR_MESSAGE(), @xstate = XACT_STATE();
        if @xstate = -1
            rollback;
        if @xstate = 1 and @trancount = 0
            rollback
        if @xstate = 1 and @trancount > 0
            rollback transaction usp_my_procedure_name;

        raiserror ('usp_my_procedure_name: %d: %s', 16, 1, @error, @message) ;
    end catch   
end
go

복구 가능한 오류가 발생했을 때 자체 작업 만 롤백하는 원자 적 절차를 작성할 수 있습니다.

Transact-SQL 프로 시저가 직면 한 주요 문제 중 하나는 데이터 순도입니다 . 때때로 수신 된 매개 변수 또는 테이블의 데이터가 잘못되어 중복 키 오류, 참조 제한 오류, 제한 오류 확인 등이 발생합니다. 결국, 이것이 바로 이러한 제약의 역할입니다. 이러한 데이터 순도 오류가 불가능하고 비즈니스 논리에 의해 모두 잡히면 제약이 모두 더 이상 사용되지 않습니다 (효과를 위해 과장된 과장). XACT_ABORT가 ON이면 예외를 정상적으로 처리하는 예외 블록을 코딩 할 수있는 것과는 달리 이러한 모든 오류로 인해 전체 트랜잭션이 손실됩니다. 일반적인 예는 INSERT를 시도하고 PK 위반시 UPDATE로 되 돌리는 것입니다.

답변

INSERT INTO t1 VALUES (1/0)    
INSERT INTO t2 VALUES (1/1)    
SELECT 'Everything is fine'