caracteristicas - sql server descargar

¿Cuál es el beneficio de usar "SET XACT_ABORT ON" en un procedimiento almacenado?

Question

¿Cuál es el beneficio de usar SET XACT_ABORT ON en un procedimiento almacenado?

Answer 1

Citando MSDN :

Cuando SET XACT_ABORT está activado, si una instrucción de Transact-SQL genera un error de tiempo de ejecución, la transacción completa finaliza y se retrotrae. Cuando SET XACT_ABORT está desactivado, en algunos casos solo se revierte la instrucción de Transact-SQL que generó el error y la transacción continúa el proceso.

En la práctica, esto significa que algunas de las declaraciones pueden fallar, dejando la transacción "parcialmente completada", y puede que no haya indicios de esta falla para la persona que llama.

Un simple ejemplo:

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

Este código se ejecutará ''exitosamente'' con XACT_ABORT DESACTIVADO, y terminará con un error con XACT_ABORT ON (''INSERT INTO t2'' no se ejecutará, y una aplicación cliente generará una excepción).

Como un enfoque más flexible, puede marcar @@ ERROR después de cada enunciado (antigua escuela) o utilizar bloques TRY ... CATCH (MSSQL2005 +). Personalmente, prefiero configurar XACT_ABORT cuando no haya motivos para un manejo avanzado de errores.

Answer 2

En cuanto a los tiempos de espera del cliente y el uso de XACT_ABORT para manejarlos, en mi opinión hay al menos una muy buena razón para tener tiempos de espera en las API del cliente como SqlClient, y eso es para proteger el código de la aplicación cliente de interbloqueos que ocurren en el código del servidor SQL. En este caso, el código del cliente no tiene ninguna falla, pero tiene que protegerse del bloqueo para siempre esperando que el comando se complete en el servidor. Por lo tanto, si los tiempos de espera de los clientes deben existir para proteger el código del cliente, XACT_ABORT ON debe proteger el código del servidor de los abortos del cliente, en caso de que el código del servidor tarde más en ejecutarse de lo que el cliente está dispuesto a esperar.

Answer 3

En mi opinión, SET XACT_ABORT ON se volvió obsoleto al agregar BEGIN TRY / BEGIN CATCH en SQL 2k5. Antes de los bloques de excepción en Transact-SQL era muy difícil manejar los errores y los procedimientos desequilibrados eran demasiado comunes (procedimientos que tenían un @@ TRANCOUNT diferente en la salida en comparación con la entrada).

Con la adición del manejo de excepciones de Transact-SQL es mucho más fácil escribir procedimientos correctos que garanticen un equilibrio adecuado de las transacciones. Por ejemplo, uso esta plantilla para manejo de excepciones y transacciones anidadas :

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

Me permite escribir procedimientos atómicos que solo retrotraen su propio trabajo en caso de errores recuperables.

Uno de los principales problemas a los que se enfrentan los procedimientos de Transact-SQL es la pureza de los datos : a veces los parámetros recibidos o los datos en las tablas son simplemente erróneos, lo que da como resultado errores clave duplicados, errores de restricción referencial, errores de limitación de restricciones, etc. Después de todo, esa es exactamente la función de estas restricciones, si estos errores de pureza de datos fueran imposibles y todos atrapados por la lógica comercial, las restricciones quedarían obsoletas (se agregará una exageración dramática para el efecto). Si XACT_ABORT está activado, todos estos errores provocan que se pierda toda la transacción, en lugar de poder codificar los bloques de excepciones que manejan la excepción correctamente. Un ejemplo típico es tratar de hacer un INSERTO y volver a una ACTUALIZACIÓN sobre la violación de PK.

Answer 4

Se utiliza en la gestión de transacciones para garantizar que los errores provoquen que la transacción se retrotraiga.

Answer 5

SET XACT_ABORT ON indica a SQL Server que revierte la transacción completa y cancela el lote cuando se produce un error en tiempo de ejecución. Lo cubre en casos como un tiempo de espera de comando que ocurre en la aplicación cliente en lugar de hacerlo en SQL Server (que no está cubierto por la configuración XACT_ABORT OFF predeterminada).

Dado que un tiempo de espera de consulta dejará abierta la transacción, se recomienda SET XACT_ABORT ON en todos los procedimientos almacenados con transacciones explícitas (a menos que tenga una razón específica para hacerlo) ya que las consecuencias de una aplicación que realiza trabajo en una conexión con una transacción abierta son desastrosas .

Hay una gran visión general en el blog de Dan Guzman ,