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

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

O que esperar

Como seria de esperar, o pool de SQL dedicado dá suporte a transações como parte da carga de trabalho do data warehouse. No entanto, para garantir que o desempenho do pool de SQL dedicado seja mantido em escala, alguns recursos são limitados quando comparados ao SQL Server. Este artigo destaca as diferenças e lista as outras.

Níveis de isolamento de transação

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

Uma vez habilitada, todas as transações neste banco de dados são executadas em READ COMMITTED SNAPSHOT ISOLATION e a configuração READ UNCOMMITTED no 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. Dessa forma, a alocaçã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 usar um comprimento médio da coluna em vez de usar o tamanho máximo.

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

Ocorreu uma distribuição uniforme de dados
O comprimento médio da linha é de 250 bytes

Gen2

DWU	Limite por distribuição (GB)	Número de distribuições	Tamanho da transação MAX (GB)	# Linhas por distribuição	Máximo de linhas por transação
DW100c	1	60	60	4,000,000	240,000,000
DW200c	1.5	60	90	6,000,000	360.000.000 milhões
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	4,500	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

Primeira Geração

DWU	Limite por distribuição (GB)	Número de distribuições	Tamanho da transação MAX (GB)	# Linhas por distribuição	Máximo de linhas por transação
DW100	1	60	60	4,000,000	240,000,000
DW200	1.5	60	90	6,000,000	360.000.000 milhões
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

O limite de tamanho da transação é aplicado por transação ou operação. Ela não é aplicada 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 de práticas recomendadas de transações .

Aviso

O tamanho máximo da transação só pode ser obtido para HASH ou ROUND_ROBIN tabelas distribuídas em que a propagação dos dados está uniforme. Se a transação estiver gravando dados de forma distorcida para as distribuições, é provável que o limite seja atingido antes do tamanho máximo da transação.

Estado da transação

O pool de 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.

Observação

O uso de -2 pela função XACT_STATE para indicar uma transação com falha representa um comportamento diferente para o SQL Server. O SQL Server usa o valor -1 para representar uma transação não compromissável. O SQL Server pode tolerar alguns erros dentro de uma transação sem precisar ser marcado como não aprovável. Por exemplo SELECT 1/0 causaria um erro, mas não forçaria uma transação a um estado não comitável. O SQL Server também permite leituras na transação não confirmável. No entanto, o pool de SQL dedicado não permite que você faça isso. Se ocorrer um erro dentro de uma transação de pool de SQL dedicada, ele entrará automaticamente no estado -2 e você não poderá fazer mais instruções selecionadas até que a instrução seja revertida. Portanto, é importante verificar se o código do aplicativo para ver se ele usa XACT_STATE(), pois talvez seja necessário fazer modificações de código.

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 fornece a seguinte mensagem de erro:

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

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

No pool de 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.

Tudo o que mudou é que o ROLLBACK da transação precisou ocorrer antes da leitura das informações de erro no bloco CATCH.

função Error_Line()

Também vale a pena observar que o pool de SQL dedicado não implementa nem dá suporte à função ERROR_LINE(). Se você tiver essa função em seu código, precisará removê-la para estar em conformidade com o pool de SQL dedicado. Use rótulos de consulta em seu código para implementar a funcionalidade equivalente. Para obter mais informações, consulte o artigo LABEL .

Uso de THROW e RAISERROR

THROW é a implementação mais moderna para gerar exceções no pool de SQL dedicado, mas também há suporte para RAISERROR. No entanto, há algumas diferenças que vale a pena prestar 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 RAISERROR são fixadas em 50.000
Não há suporte para o uso de sys.messages

Limitações

O pool de SQL dedicado tem algumas outras restrições relacionadas a transações. Elas são as seguintes:

Nenhuma transação distribuída
Nenhuma transação aninhada permitida
Pontos de salvamento não permitidos
Nenhuma transação nomeada
Nenhuma transação marcada
Não há suporte para DDL, como CREATE TABLE dentro de uma transação definida pelo usuário

Próximas Etapas

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

Comentários

Esta página foi útil?

Last updated on 2026-03-26