Transações no Fabric Data Warehouse

Aplica-se a:✅ Endpoint de Análise SQL e Armazém no Microsoft Fabric

Semelhante ao comportamento em SQL Server, as transações permitem controlar a confirmação ou a reversão de consultas de leitura e gravação.

Fabric Data Warehouse dá suporte a transações em conformidade com ACID. Cada transação é atômica, consistente, isolada e durável (ACID). Todas as operações em uma única transação são tratadas atomicamente, todas com êxito ou todas falhando. Se qualquer instrução na transação falhar, toda a transação será revertida.

Transações explícitas

Você pode modificar dados armazenados em tabelas em um Warehouse usando transações explícitas para agrupar alterações.

Por exemplo, você pode confirmar inserções em várias tabelas ou não confirmar em nenhuma delas se ocorrer um erro. Se estiver alterando detalhes de um pedido de compra que afeta três tabelas, é possível agrupar essas alterações em uma única transação. Isso significa que, quando essas tabelas são consultadas, ou todas elas têm as alterações, ou nenhuma tem. As transações são uma prática comum para quando você precisa garantir que seus dados sejam consistentes em várias tabelas.

Você pode usar mecanismos de controle de sintaxe T-SQL (BEGIN TRANCOMMIT TRANe ROLLBACK TRAN) padrão para transações explícitas. Para obter mais informações, consulte: - BEGIN TRANSACTION - COMMIT TRANSACTION - ROLLBACK TRANSACTION

Por exemplo, Fabric Data Warehouse tratará essas alterações de esquema como uma única unidade atômica:

-- Sample Syntax--- 
BEGIN TRAN; 
ALTER TABLE <table_name> ADD <column_name> <type>; 
ALTER TABLE <table_name> DROP COLUMN <column_name>; 
COMMIT;

Se qualquer instrução na transação falhar, todas as alterações de esquema serão revertidas automaticamente.

Fabric Data Warehouse dá suporte à execução do seguinte dentro de uma transação explícita:

  • CREATE TABLE
  • DROP TABLE
  • TRUNCATE TABLE
  • CTAS
  • sp_rename
  • ALTER TABLE adicionar colunas anuláveis
  • ALTER TABLE soltar colunas
  • ALTER TABLE adicionar ou soltar PRIMARY KEY, UNIQUEe FOREIGN KEY restrições com a NOT ENFORCED palavra-chave
  • Várias ALTER TABLE instruções
  • ALTER TABLE em tabelas temporárias distribuídas

Suporte a transações de consulta entre bancos de dados

Warehouse no Microsoft Fabric dá suporte a transações que abrangem armazéns dentro do mesmo espaço de trabalho, incluindo a leitura do endpoint de análise SQL do Lakehouse. Para obter um exemplo, consulte Gravar uma consulta SQL entre bancos de dados.

Entender o bloqueio e a obstrução no Fabric Data Warehouse

Fabric Data Warehouse utiliza bloqueio ao nível da tabela, independentemente de uma consulta acessar uma linha ou várias. A tabela a seguir fornece uma lista de quais bloqueios são usados para diferentes operações T-SQL.

Tipo de declaração Bloqueio realizado
DML
SELECT Schema-Stability (Sch-S)
INSERT Intenção exclusiva (IX)
DELETE Intenção exclusiva (IX)
UPDATE Intenção exclusiva (IX)
MESCLAR Intenção exclusiva (IX)
COPIAR PARA Intenção exclusiva (IX)
DDL
CREATE TABLE Modificação de Esquema (Sch-M)
ALTER TABLE Modificação de Esquema (Sch-M)
DROP TABLE Modificação de Esquema (Sch-M)
TRUNCAR TABELA Modificação de Esquema (Sch-M)
CRIAR TABELA COMO SELEÇÃO Modificação de Esquema (Sch-M)
CRIAR TABELA COMO CÓPIA DE Modificação de Esquema (Sch-M)

Você pode consultar os bloqueios mantidos atualmente com a exibição de gerenciamento dinâmico (DMV) sys.dm_tran_locks.

Para obter mais informações sobre bloqueios, escalonamento de bloqueios e compatibilidade de bloqueios, consulte o guia de bloqueio de transações e versionamento de linha.

Isolamento por instantâneo

O Fabric Data Warehouse aplica o isolamento por instantâneo em todas as transações. O isolamento de instantâneo é um nível de isolamento baseado em tempdb que fornece consistência de dados a nível de transação e utiliza versões de linha armazenadas em tempdb para selecionar as linhas que devem ser atualizadas. A transação usa as versões de linha de dados que existem quando a transação começa. Isso garante que cada transação opere em um instantâneo consistente dos dados como eles existiam no início da transação.

No isolamento de instantâneo, as consultas na transação veem a mesma versão ou instantâneo, com base no estado do banco de dados quando a transação é iniciada. No isolamento de instantâneo, transações que modificam dados não bloqueiam transações que leem dados e transações que leem dados não bloqueiam transações que gravam dados. Esse comportamento otimista e sem bloqueio também reduz significativamente a probabilidade de deadlocks para transações complexas.

Se você usar o T-SQL para alterar o nível de isolamento, a alteração será ignorada no momento da execução da consulta e o isolamento do instantâneo será aplicado.

No isolamento de instantâneo, conflitos de gravação-gravação ou atualização são possíveis, para obter mais informações, consulte Entenda os conflitos de gravação-gravação em Fabric Data Warehouse.

Bloqueios de esquema

Os bloqueios de esquema impedem conflitos em instruções DDL, como o esquema de uma tabela sendo alterado enquanto as linhas estão sendo atualizadas em uma transação. Lembre-se de que operações DDL, como alterações de esquema e migrações, podem bloquear ou serem bloqueadas por cargas de leitura ativas.

  • Durante operações de DDL (linguagem de definição de dados), o Database Engine usa bloqueios de modificação de esquema (Sch-M). Durante o tempo em que ele é mantido, o Sch-M bloqueio impede todo o acesso simultâneo à tabela até que o bloqueio seja liberado.
  • Durante operações de DML (linguagem de manipulação de dados), o Database Engine usa bloqueios de estabilidade de esquema (Sch-S). As operações que adquirem bloqueios Sch-M são bloqueadas por bloqueios Sch-S. Outras transações continuam sendo executadas enquanto uma consulta está sendo compilada, mas as operações de DDL são bloqueadas até que possam obter acesso exclusivo ao esquema.
  • As operações DDL também adquirem um bloqueio exclusivo (X) em linhas em exibições do sistema, como sys.tables e sys.objects associadas à tabela de destino, durante a transação. Isso bloqueia instruções simultâneas em SELECT, sys.tables e sys.objects.

Práticas recomendadas para evitar o bloqueio

  • Evite transações de execução prolongada ou agende durante períodos de baixa ou nenhuma atividade simultânea.
  • Agende operações de DDL somente durante as janelas de manutenção para minimizar o bloqueio.
  • Embora as instruções DDL possam ser executadas dentro de transações de usuário explícitas (BEGIN TRAN), elas devem ser usadas com cuidado em cargas de trabalho simultâneas. Devido ao comportamento de bloqueio, o DDL dentro de uma transação pode bloquear operações DML ou SELECT simultâneas nas tabelas afetadas, bem como consultas SELECT em exibições de catálogo do sistema, como sys.tables .sys.objects Para monitorar e solucionar possíveis conflitos de bloqueio, use sys.dm_tran_locks.
  • Monitore bloqueios e conflitos no armazém.

Entenda os conflitos de gravação simultânea no Fabric Data Warehouse

Conflitos de escrita-escrita podem ocorrer quando duas transações tentam UPDATE, DELETE, MERGE ou TRUNCATE a mesma tabela.

Conflitos de gravação-gravação ou conflitos de atualização são possíveis no nível da tabela, pois o Fabric Data Warehouse usa bloqueio no nível da tabela. Se duas transações tentarem modificar linhas diferentes na mesma tabela, elas ainda poderão entrar em conflito.

Os conflitos de gravação simultânea surgem principalmente de dois cenários:

  • Conflitos de carga de trabalho induzidos pelo usuário
    • Vários usuários ou processos modificam simultaneamente a mesma tabela.
    • Pode ocorrer em pipelines ETL, atualizações em lote ou transações sobrepostas.
  • Conflitos induzidos pelo sistema
    • Tarefas de sistema em segundo plano, como a compactação automática de dados, reescrevem arquivos de baixa qualidade.
    • Elas podem entrar em conflito com transações de usuário, embora a preempção de compactação de dados ativamente previna conflitos de gravação-gravação desse tipo.

Se ocorrer um conflito de escrita-escrita, você poderá ver mensagens de erro como:

  • Erro 24556: Transação de isolamento de instantâneo anulada devido a conflito de atualização. Usar o isolamento de instantâneo para acessar a tabela '%.*ls' direta ou indiretamente no banco de dados '%.*ls' pode causar conflitos de atualização se linhas nessa tabela tiverem sido excluídas ou atualizadas por outra transação simultânea. Tente a transação novamente.
  • Erro 24706: Transação de isolamento por instantâneo abortada devido a conflito de atualização. Não é possível usar o isolamento de instantâneo para acessar direta ou indiretamente a tabela '%.*ls' no banco de dados '%.*ls' para atualizar, excluir ou inserir a linha que foi modificada ou excluída por outra transação. Tente novamente a transação.

Se você encontrar essas mensagens de erro, uma ou mais transações foram bem-sucedidas e uma ou mais transações conflitantes falharam. Tente novamente as transações que falharam.

Observação

Mesmo quando MERGE as transações resultam apenas em alterações somente de acréscimo, elas ainda criam um conflito de gravação/gravação. Quando a transação de isolamento por instantâneo MERGE afeta linhas diferentes das transações DML simultâneas, ela pode encontrar esse erro se MERGE não for a primeira transação a ser confirmada: "Transação de isolamento por instantâneo interrompida devido a conflito de atualização".

Práticas recomendadas para evitar conflitos de gravação simultânea

Para evitar conflitos de escrita-escrita:

  • Evite operações simultâneas UPDATEDELETEna MERGE mesma tabela.
    • Preste atenção às operações de UPDATE, DELETE e MERGE em transações de várias etapas.
  • Use a Lógica de Repetição em todos os aplicativos e consultas.
    • Implemente a lógica de repetição em procedimentos armazenados e pipelines de ETL.
    • Adicione lógica de repetição com atraso em pipelines ou aplicativos para lidar com conflitos transitórios.
      • Use a retirada exponencial para evitar tempestades de repetição que pioram interrupções transitórias de rede. Para obter mais informações, consulte Padrão de repetição.
  • Os conflitos de gravação/gravação com o serviço de background de compactação de dados do Fabric Data Warehouse são possíveis, mas normalmente são evitados pelo recurso de Preempção de compactação de dados.

Bloqueio de tabela e arquivo parquet

Os conflitos de duas ou mais transações simultâneas que atualizam uma ou mais linhas em uma tabela são avaliados no final da transação. A primeira transação a ser confirmada é concluída com êxito, e as outras transações são revertidas devido a um erro. Esses conflitos são avaliados no nível da tabela e não no nível do arquivo parquet individual.

As instruções INSERT sempre criam novos arquivos de parquet, o que significa menos conflitos com outras transações, exceto para DDL, pois o esquema da tabela pode estar passando por alterações.

Limitações

  • Não há suporte para transações distribuídas, por exemplo. BEGIN DISTRIBUTED TRANSACTION
  • Não há suporte para pontos de salvamento.
  • Não há suporte para transações nomeadas.
  • Não há suporte para transações marcadas.
  • No momento, a funcionalidade T-SQL do Warehouse é limitada. Consulte área de superfície T-SQL no Fabric Data Warehouse para uma lista de comandos T-SQL que atualmente não estão disponíveis.
  • Se uma transação tiver inserção de dados em uma tabela vazia e emitir um SELECT antes de reverter, as estatísticas geradas automaticamente ainda poderão refletir os dados não confirmados, produzindo estatísticas imprecisas. Estatísticas imprecisas podem levar a planos de consulta e tempos de execução não otimizados. Se você reverter uma transação com SELECTs depois de realizar um grande INSERT, atualize as estatísticas das colunas mencionadas em seu SELECT.

Conteúdo relacionado

  • Last updated on