Usar transações com pool SQL dedicado no Azure Synapse Analytics

Dicas para implementar transações com pool SQL dedicado no Azure Synapse Analytics para desenvolver soluções.

O que esperar

Como seria de esperar, o pool SQL dedicado suporta transações como parte da carga de trabalho do armazém de dados. No entanto, para garantir que o desempenho do pool SQL dedicado seja mantido em escala, alguns recursos são limitados quando comparados ao SQL Server. Este artigo destaca as diferenças e lista os outros.

Níveis de isolamento de transações

O pool SQL dedicado implementa transações ACID. O nível de isolamento do suporte transacional é padrão para READ UNCOMMITTED. Você pode alterá-la para READ COMMITTED SNAPSHOT ISOLATION ativando a opção de banco de dados READ_COMMITTED_SNAPSHOT para um banco de dados do usuário quando estiver conectado ao banco de dados mestre.

Uma vez que a funcionalidade está habilitada, todas as transações neste banco de dados são executadas sob o isolamento READ COMMITTED SNAPSHOT e a definição de READ UNCOMMITTED ao nível da sessão não será respeitada. Verifique as opções ALTER DATABASE SET (Transact-SQL) para obter detalhes.

Tamanho da transação

Uma única transação de modificação de dados é limitada em tamanho. O limite é aplicado por distribuição. Como tal, a dotação total pode ser calculada multiplicando o limite pela contagem de distribuição.

Para aproximar o número máximo de linhas na transação, divida o limite de distribuição pelo tamanho total de cada linha. Para colunas de comprimento variável, considere tomar um comprimento médio de coluna em vez de usar o tamanho máximo.

Na tabela abaixo foram feitas as seguintes suposições:

• Verificou-se uma distribuição equilibrada dos dados
• O comprimento médio da linha é de 250 bytes

Gen2

Geração 1

O limite de tamanho da transação é aplicado por transação ou operação. Não é aplicado em todas as transações simultâneas. Portanto, cada transação tem permissão para gravar essa quantidade de dados no log.

Para otimizar e minimizar a quantidade de dados gravados no log, consulte o artigo Práticas recomendadas de transações .

Estado da transação

O pool SQL dedicado usa a função XACT_STATE() para relatar uma transação com falha usando o valor -2. Esse valor significa que a transação falhou e está marcada apenas para reversão.

Por exemplo, no SQL Server, você pode ver uma transação semelhante à seguinte:

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;

O código anterior dá a seguinte mensagem de erro:

Msg 111233, Nível 16, Estado 1, Linha 1 111233; A transação atual foi abortada, e quaisquer alterações pendentes foram revertidas. Causa: uma transação em um estado somente de reversão não foi revertida explicitamente antes de uma instrução DDL, DML ou SELECT.

Você não obterá a saída das funções ERROR_*.

No pool SQL dedicado, o código precisa ser ligeiramente alterado:

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;

O comportamento esperado é agora observado. O erro na transação é gerenciado e as funções ERROR_* fornecem valores conforme o esperado.

As únicas alterações foram que o ROLLBACK da transação teve que ocorrer antes da leitura das informações de erro no bloco CATCH.

Função Error_Line()

Também vale a pena notar que o pool SQL dedicado não implementa nem suporta a função ERROR_LINE(). Se você tiver essa função em seu código, precisará removê-la para ser compatível com o pool SQL dedicado. Em vez disso, use rótulos de consulta em seu código para implementar uma funcionalidade equivalente. Para obter mais informações, consulte o artigo LABEL .

Utilização de THROW e RAISERROR

THROW é a implementação mais moderna para gerar exceções no pool SQL dedicado, mas RAISERROR também é suportado. No entanto, existem algumas diferenças que merecem atenção.

• Os números de mensagens de erro definidos pelo usuário não podem estar no intervalo de 100.000 a 150.000 para THROW
• As mensagens de erro do RAISERROR estão fixadas em 50.000
• O uso de sys.messages não é suportado

Limitações

O pool SQL dedicado tem algumas outras restrições relacionadas a transações. São os seguintes:

• Sem transações distribuídas
• Não são permitidas transações aninhadas
• Não são permitidos pontos de salvamento
• Sem transações nomeadas
• Sem transações marcadas
• Não há suporte para DDL, como CREATE TABLE dentro de uma transação definida pelo usuário

Próximos passos

Para saber mais sobre como otimizar transações, consulte Práticas recomendadas de transações. Guias de práticas recomendadas adicionais também são fornecidos para pool SQL dedicado e pool SQL sem servidor.