Compartir vía

Uso de transacciones con un grupo de SQL dedicado en Azure Synapse Analytics

Sugerencias para implementar transacciones con un grupo de SQL dedicado en Azure Synapse Analytics para desarrollar soluciones.

Qué esperar

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

Niveles de aislamiento de transacciones

El grupo de SQL dedicado implementa transacciones ACID. El nivel de aislamiento de la compatibilidad transaccional está configurado de forma predeterminada en READ UNCOMMITTED. Para cambiarlo a READ COMMITTED SNAPSHOT ISOLATION, active la opción de base de datos READ_COMMITTED_SNAPSHOT para una base de datos de usuario cuando esté conectada a la base de datos maestra.

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

Tamaño de transacción

Una única transacción de modificación de datos tiene un tamaño limitado. El límite se aplica por distribución. Por lo tanto, la asignación total se puede calcular 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 límite de distribución por el tamaño total de cada fila. En el caso de las columnas de longitud variable, considere la posibilidad de tomar una longitud media de columna en lugar de usar el tamaño máximo.

En la tabla siguiente se han realizado las suposiciones siguientes:

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

Gen2

DWU Límite por distribución (GB) Número de distribuciones Tamaño máximo de transacción (GB) # Filas por distribución Número 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 2,250 150,000,000 9,000,000,000
DW6000c 45 60 2,700 180,000,000 10,800,000,000
DW7500c 56.25 60 3,375 225,000,000 13,500,000,000
DW10000c 75 60 4500 300,000,000 18,000,000,000
DW15000c 112.5 60 6,750 450,000,000 27,000,000,000
DW30000c 225 60 13,500 900,000,000 54,000,000,000

Gen1

DWU Límite por distribución (GB) Número de distribuciones Tamaño máximo de transacción (GB) # Filas por distribución Número 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

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

Para optimizar y minimizar la cantidad de datos escritos en el registro, consulte el artículo Procedimientos recomendados de transacciones .

Advertencia

El tamaño máximo de transacción solo se puede lograr para HASH o ROUND_ROBIN tablas distribuidas donde la propagación de los datos es uniforme. Si la transacción escribe datos de forma sesgada en distribuciones, es probable que se alcance el límite antes del tamaño máximo de la transacción.

Estado de transacción

El grupo de SQL dedicado usa la función XACT_STATE() para notificar una transacción con errores mediante el valor -2. Este valor significa que la transacción ha fallado y está marcada solo para rollback.

Nota:

El uso de -2 por la función XACT_STATE para indicar que una transacción con errores representa un comportamiento diferente a SQL Server. SQL Server usa el valor -1 para representar una transacción no confirmada. SQL Server puede tolerar algunos errores dentro de una transacción sin tener que marcarse como no compatibles. Por ejemplo SELECT 1/0 , provocaría un error pero no forzaría una transacción en un estado no confirmable. SQL Server también permite lecturas en la transacción no confirmada. Sin embargo, el "dedicated SQL pool" no permite hacerlo. Si se produce un error dentro de una transacción del pool de SQL dedicado, entrará automáticamente en el estado -2 y no podrá realizar ninguna consulta SELECT adicional hasta que se haya revertido la instrucción. Por lo tanto, es importante comprobar que el código de la aplicación vea si usa XACT_STATE() ya que es posible que tenga que realizar modificaciones de código.

Por ejemplo, en SQL Server puede ver una transacción similar a la siguiente:

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 proporciona el siguiente mensaje de error:

Msg 111233, Nivel 16, Estado 1, Línea 1 111233; La transacción actual se ha anulado y se han revertido los cambios pendientes. Causa: Una transacción en estado de solo rollback no se había revertido explícitamente antes de una instrucción DDL, DML o SELECT.

No obtendrá el resultado de las funciones ERROR_*.

En el grupo de SQL dedicado, 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. El error de la transacción se administra y las funciones ERROR_* proporcionan valores según lo previsto.

Todo lo que ha cambiado es que el ROLLBACK de la transacción tuvo que ocurrir antes de la lectura de la información de error en el bloque CATCH.

función Error_Line()

También merece la pena tener en cuenta que el grupo de SQL dedicado no implementa ni admite la función ERROR_LINE(). Si tiene esta función en el código, debe quitarla para que sea compatible con el grupo de SQL dedicado. Use etiquetas de consulta en el código en su lugar para implementar la funcionalidad equivalente. Para obtener más información, consulte el artículo LABEL .

Uso de THROW y RAISERROR

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

  • Los números de mensajes de error definidos por el usuario no pueden estar 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 dedicado tiene algunas otras restricciones relacionadas con las transacciones. Son los siguientes:

  • No hay transacciones distribuidas
  • No se permiten transacciones anidadas
  • No se permiten puntos de salvado
  • No hay transacciones con nombre
  • No hay transacciones marcadas
  • No se admite DDL, como CREATE TABLE dentro de una transacción definida por el usuario.

Pasos siguientes

Para más información sobre la optimización de transacciones, consulte Procedimientos recomendados de transacciones. También se proporcionan guías de procedimientos recomendados adicionales para el grupo de SQL dedicado y el grupo de SQL sin servidor.

  • Last updated on