Uso de transacciones en un grupo de SQL en Azure Synapse

Artículo
06/01/2023

En este artículo se incluyen sugerencias para implementar transacciones y desarrollar soluciones en un grupo de SQL.

Qué esperar

Como cabría esperar, el grupo de SQL admite transacciones como parte de la carga de trabajo de almacenamiento de datos. Sin embargo, para asegurarse de que el grupo de SQL se mantiene a escala, algunas características están limitadas en comparación con SQL Server. En este artículo se resaltan las diferencias.

Niveles de aislamiento de transacciones

El grupo de SQL implementa transacciones ACID. El nivel de aislamiento de la compatibilidad transaccional se establece de forma predeterminada en READ UNCOMMITTED. Para cambiarlo a READ COMMITTED SNAPSHOT ISOLATION, active la opción de base de datos READ_COMMITTED_SNAPSHOT de un grupo de SQL de usuario cuando se conecte a la base de datos maestra.

Una vez habilitada, todas las transacciones de esta base de datos se ejecutan en READ COMMITTED SNAPSHOT ISOLATION y no se respeta la opción de configuración READ UNCOMMITTED en el nivel de sesión. Consulte Opciones de ALTER DATABASE SET (Transact-SQL) para obtener más información.

Tamaño de la transacción

Una transacción de modificación de datos única tiene un tamaño limitado. El límite se aplica por distribución. Por lo tanto, la asignación total puede calcularse multiplicando el límite por el recuento de distribución.

Para aproximar el número máximo de filas de la transacción, divida el extremo de la distribución entre el tamaño total de cada fila. Para las columnas de longitud variable, plantéese utilizar la longitud media de la columna en lugar del tamaño máximo.

En la tabla siguiente se han realizado dos supuestos:

Se ha producido una distribución uniforme de los datos
La longitud media de la fila es de 250 bytes

Gen2

DWU	Extremo por distribución (GB)	Número de distribuciones	Tamaño de la transacción MAX (GB)	N-º de filas por distribución	Máximo de filas por transacción
DW100c	1	60	60	4 000 000	240 000 000
DW200c	1.5	60	90	6\.000.000	360 000 000
DW300c	2.25	60	135	9 000 000	540 000 000
DW400c	3	60	180	12 000 000	720 000 000
DW500c	3,75	60	225	15 000 000	900 000 000
DW1000c	7.5	60	450	30 000 000	1 800 000 000
DW1500c	11,25	60	675	45 000 000	2 700 000 000
DW2000c	15	60	900	60 000 000	3 600 000 000
DW2500c	18,75	60	1125	75 000 000	4 500 000 000
DW3000c	22.5	60	1,350	90,000,000	5,400,000,000
DW5000c	37.5	60	2250	150 000 000	9 000 000 000
DW6000c	45	60	2,700	180,000,000	10,800,000,000
DW7500c	56,25	60	3375	225 000 000	13 500 000 000
DW10000c	75	60	4500	300.000.000	18 000 000 000
DW15000c	112,5	60	6750	450 000 000	27 000 000 000
DW30000c	225	60	13 500	900 000 000	54 000 000 000

Gen1

DWU	Extremo por distribución (GB)	Número de distribuciones	Tamaño de la transacción MAX (GB)	N-º de filas por distribución	Máximo de filas por transacción
DW100	1	60	60	4 000 000	240 000 000
DW200	1.5	60	90	6\.000.000	360 000 000
DW300	2.25	60	135	9 000 000	540 000 000
DW400	3	60	180	12 000 000	720 000 000
DW500	3,75	60	225	15 000 000	900 000 000
DW600	4.5.	60	270	18 000 000	1 080 000 000
DW1000	7.5	60	450	30 000 000	1 800 000 000
DW1200	9	60	540	36 000 000	2 160 000 000
DW1500	11,25	60	675	45 000 000	2 700 000 000
DW2000	15	60	900	60 000 000	3 600 000 000
DW3000	22.5	60	1,350	90,000,000	5,400,000,000
DW6000	45	60	2,700	180,000,000	10,800,000,000

Se aplica el límite de tamaño de la transacción por transacción u operación. No se aplica en todas las transacciones simultáneas. Por tanto, cada transacción puede escribir esta cantidad de datos en el registro.

Para optimizar y minimizar la cantidad de datos que se escriben en el registro, consulte el artículo Procedimientos recomendados relacionados con las transacciones.

Advertencia

El tamaño máximo de la transacción solo se puede conseguir para las tablas de distribución HASH o ROUND_ROBIN donde la propagación de los datos es uniforme. Si la transacción está escribiendo datos de forma sesgada en las distribuciones, es posible que el límite se alcance antes de que la transacción llegue al máximo de su tamaño.

Estado de las transacciones

El grupo de SQL usa la función XACT_STATE() para notificar una transacción errónea con el valor -2. Este valor indica que la transacción no se ha realizado y que solo se marca para reversión.

Nota

El uso de -2 por la función XACT_STATE para denotar una transacción errónea representa un comportamiento diferente para SQL Server. SQL Server utiliza el valor -1 para representar una transacción no confirmable. SQL Server puede tolerar algunos errores en una transacción sin necesidad de que se marque como no confirmable. Por ejemplo, SELECT 1/0 produciría un error, pero no forzaría una transacción a un estado no confirmable.

SQL Server también permite lecturas en la transacción no confirmable. Sin embargo, el grupo de SQL no permite hacer esto. Si se produce un error dentro de una transacción del grupo de SQL, especificará automáticamente el estado -2 y no podrá realizar más instrucciones select hasta que la instrucción se haya revertido.

Como tal, es importante comprobar el código de aplicación para ver si utiliza XACT_STATE() cuando necesite realizar modificaciones del código.

Por ejemplo, puede que vea una transacción con el siguiente aspecto en SQL Server:

SET NOCOUNT ON;
DECLARE @xact_state smallint = 0;

BEGIN TRAN
    BEGIN TRY
        DECLARE @i INT;
        SET     @i = CONVERT(INT,'ABC');
    END TRY
    BEGIN CATCH
        SET @xact_state = XACT_STATE();

        SELECT  ERROR_NUMBER()    AS ErrNumber
        ,       ERROR_SEVERITY()  AS ErrSeverity
        ,       ERROR_STATE()     AS ErrState
        ,       ERROR_PROCEDURE() AS ErrProcedure
        ,       ERROR_MESSAGE()   AS ErrMessage
        ;

        IF @@TRANCOUNT > 0
        BEGIN
            ROLLBACK TRAN;
            PRINT 'ROLLBACK';
        END

    END CATCH;

IF @@TRANCOUNT >0
BEGIN
    PRINT 'COMMIT';
    COMMIT TRAN;
END

SELECT @xact_state AS TransactionState;

El código anterior muestra el siguiente mensaje de error:

Msg 111233, Level 16, State 1, Line 1 111233; La transacción actual se ha anulado y los cambios pendientes se han revertido. La causa de este problema es que una transacción en estado de solo reversión no se revierte explícitamente antes de una instrucción DDL, DML o SELECT.

Tampoco obtendrá el resultado de las funciones ERROR_*.

En el grupo de SQL, el código debe modificarse ligeramente:

SET NOCOUNT ON;
DECLARE @xact_state smallint = 0;

BEGIN TRAN
    BEGIN TRY
        DECLARE @i INT;
        SET     @i = CONVERT(INT,'ABC');
    END TRY
    BEGIN CATCH
        SET @xact_state = XACT_STATE();

        IF @@TRANCOUNT > 0
        BEGIN
            ROLLBACK TRAN;
            PRINT 'ROLLBACK';
        END

        SELECT  ERROR_NUMBER()    AS ErrNumber
        ,       ERROR_SEVERITY()  AS ErrSeverity
        ,       ERROR_STATE()     AS ErrState
        ,       ERROR_PROCEDURE() AS ErrProcedure
        ,       ERROR_MESSAGE()   AS ErrMessage
        ;
    END CATCH;

IF @@TRANCOUNT >0
BEGIN
    PRINT 'COMMIT';
    COMMIT TRAN;
END

SELECT @xact_state AS TransactionState;

Ahora se observa el comportamiento esperado. Se administra el error en la transacción y las funciones ERROR_* proporcionan los valores esperados.

Lo único que ha cambiado es que la operación ROLLBACK de la transacción tenía que producirse antes de la lectura de la información de error en el bloque CATCH.

Función Error_Line()

También cabe destacar que el grupo de SQL no implementa o admite la función ERROR_LINE(). Si ha incluido esta función en el código, tendrá que quitarla para que sea compatible con el grupo de SQL.

En su lugar, utilice etiquetas de consulta en el código para implementar una funcionalidad equivalente. Para obtener más información, vea el artículo sobre etiquetas.

Uso de THROW y RAISERROR

THROW es la implementación más moderna para producir excepciones en el grupo de SQL, pero también se admite RAISERROR. Sin embargo, hay algunas diferencias a las que se debe prestar atención.

Los números de mensajes de error definidos por el usuario no pueden encontrarse en el intervalo de 100 000 a 150 000 para THROW.
Los mensajes de error RAISERROR se fijan en 50.000.
No se admite el uso de sys.messages.

Limitaciones

El grupo de SQL tiene algunas otras restricciones relacionadas con las transacciones.

Los pasos son los siguientes:

Transacciones no distribuidas
Transacciones anidadas no permitidas
Puntos de almacenamiento no admitidos
Sin transacciones con nombre
Sin transacciones marcadas
No existe compatibilidad con DDL como el elemento CREATE TABLE de una transacción definida por el usuario

Pasos siguientes

Para obtener más información sobre la optimización de transacciones, vea Procedimientos recomendados relacionados con las transacciones. Para más información sobre otros procedimientos recomendados del grupo de SQL, consulte Procedimientos recomendados del grupo de SQL.

Compartir vía