Transações em Fabric Data Warehouse

Aplica-se a:✅ ponto final de análise SQL e Armazém de Dados em o Microsoft Fabric

Semelhante ao comportamento deles no SQL Server, as transações permitem controlar o commit ou o rollback de consultas de leitura e escrita.

Fabric Data Warehouse suporta transações compatíveis com ACID. Cada transação é atômica, consistente, isolada e durável (ACID). Todas as operações dentro de uma única transação são tratadas atomicamente, todas com sucesso 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 depósito usando transações explícitas para agrupar alterações.

Por exemplo, poderá validar inserções em várias tabelas ou em nenhuma das tabelas se surgir um erro. Se você estiver alterando detalhes sobre uma ordem de compra que afeta três tabelas, poderá agrupar essas alterações em uma única transação. Isso significa que, quando essas tabelas são consultadas, todas elas têm as alterações ou nenhuma delas 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 TRAN, COMMIT 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á estas 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 alguma instrução na transação falhar, todas as alterações no esquema são automaticamente revertidas.

Fabric Data Warehouse suporta a 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 Remover colunas
  • ALTER TABLE adicionar ou eliminar PRIMARY KEY, UNIQUE, e FOREIGN KEY restrições com a NOT ENFORCED palavra-chave
  • Múltiplas ALTER TABLE afirmações
  • ALTER TABLE em tabelas temporárias distribuídas

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

No Microsoft Fabric, o Armazém suporta 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 Escrever uma consulta SQL entre bancos de dados.

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

Fabric Data Warehouse utiliza bloqueio ao nível da tabela, independentemente de a consulta afetar 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 tomado
DML
SELECT Schema-Stability (Sch-S)
INSERT Intenção Exclusiva (IX)
DELETE Intenção Exclusiva (IX)
UPDATE Intenção Exclusiva (IX)
FUSÃO Intenção Exclusiva (IX)
COPIAR PARA Intenção Exclusiva (IX)
DDL
CRIAR TABELA Modificação de Esquema (Sch-M)
ALTERAR TABELA Modificação de Esquema (Sch-M)
DROP TABLE Modificação de Esquema (Sch-M)
TABELA TRUNCATE Modificação de Esquema (Sch-M)
CRIAR TABELA COMO SELEÇÃO Modificação de Esquema (Sch-M)
CRIAR TABELA COMO CLONE DE Modificação de Esquema (Sch-M)

Você pode consultar bloqueios atualmente mantidos com a vista de gestão dinâmica (DMV) sys.dm_tran_locks.

Para obter mais informações sobre bloqueios, escalonamento de bloqueio e compatibilidade de bloqueio, consulte Guia de bloqueio de transações e controle de versões de linhas.

Isolamento de Snapshot

Fabric Data Warehouse impõe isolamento de snapshots em todas as transações. O isolamento de instantâneos é um nível de isolamento baseado em linha que fornece consistência de nível de transação para dados e usa versões de linha armazenadas em tempdb para selecionar as linhas a serem 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 num instantâneo consistente dos dados no estado em que existiam no início da transação.

No isolamento de instantâneo, as consultas de uma transação veem a mesma versão ou o mesmo instantâneo, com base no estado do banco de dados no início da transação. No isolamento de instantâneo, as transações que modificam dados não bloqueiam transações que leem dados e as 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 bloqueios para transações complexas.

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

Em isolamento de snapshots, são possíveis conflitos de escrita-escrita ou atualização; para mais informações, veja Compreender conflitos de escrita-escrita em Fabric Data Warehouse.

Bloqueios de esquema

Os bloqueios de esquema evitam 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 as operações DDL, como alterações de esquema e migrações, podem bloquear ou estar bloqueadas por cargas de trabalho de leitura ativas.

  • Durante operações de linguagem de definição de dados (DDL), o Database Engine utiliza bloqueios de modificação de esquema (Sch-M). Durante o tempo em que é mantido, o Sch-M bloqueio impede todo o acesso simultâneo à mesa até que o bloqueio seja liberado.
  • Durante as operações de manipulação de linguagem de dados (DML), o Database Engine utiliza 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 a ser executadas enquanto uma consulta está sendo compilada, mas as operações 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 visualizações do sistema como sys.tables e sys.objects associadas à tabela de destino, durante a duração da transação. Isso bloqueia declarações simultâneas SELECT em sys.tables e sys.objects.

Práticas recomendadas para evitar bloqueios

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

Compreenda os conflitos de escrita-escrita em Fabric Data Warehouse

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

Conflitos de escrita-escrita ou de atualização são possíveis ao nível da tabela, uma vez que Fabric Data Warehouse utiliza bloqueio ao 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 escrita-escrita 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 de 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 qualidade inferior.
    • Eles podem entrar em conflito com as transações do utilizador, embora a preempção de compactação de dados impeça ativamente conflitos de escrita-escrita desse tipo.

Se ocorrer um conflito de gravação-gravação, você poderá ver mensagens de erro como:

  • Erro 24556: Transação de isolamento de instantâneo abortada devido a conflito de atualização. Usar o isolamento de instantâneo para aceder à tabela '%.*ls' direta ou indiretamente na base de dados '%.*ls' pode causar conflitos de atualização se as linhas dessa tabela tiverem sido excluídas ou atualizadas por outra transação simultânea. Tente novamente a transação.
  • Erro 24706: Transação de isolamento de instantâneo abortada devido a conflito de atualização. Não é possível usar o isolamento de instantâneo para acessar diretamente ou indiretamente a tabela '%.*ls' no banco de dados '%.*ls', para atualizar, excluir ou inserir a linha que já 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. Repita as transações que falharam.

Observação

Mesmo quando MERGE as transações resultam apenas em alterações apenas de adição, elas ainda criam um conflito de escrita-escrita. Quando a transação MERGE afeta linhas diferentes daquelas afetadas por outras transações DML simultâneas, ela pode encontrar esse erro se MERGE não for a primeira transação a ser comprometida: 'Transação de isolamento de instantâneo abortada 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 UPDATE, DELETE, MERGE na mesma tabela.
    • Preste muita atenção às operações UPDATE, DELETE, 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.
      • Utilize o retrocesso exponencial para evitar tempestades de tentativas que agravam as interrupções transitórias da rede. Para obter mais informações, consulte Padrão de Retentativa.
  • Conflitos de escrita simultânea com o serviço de compactação de dados em segundo plano do Fabric Data Warehouse são possíveis, mas normalmente são evitados pela funcionalidade de preempção da compactação de dados Data compaction preemption.

Bloqueio de tabelas e arquivos de 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 com um erro retornado. 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 parquet, o que resulta em menos conflitos com outras transações, exceto com aquelas que envolvem DDL (Linguagem de Definição de Dados), já que o esquema da tabela pode estar em processo de alteração.

Limitações

  • Não há suporte para transações distribuídas, por exemplo, BEGIN DISTRIBUTED TRANSACTION.
  • Não há suporte para salvar pontos.
  • Não há suporte para transações nomeadas.
  • Não há suporte para transações marcadas.
  • De momento, a funcionalidade de T-SQL é limitada no armazém de dados. Consulte a abrangência do T-SQL no Fabric Data Warehouse para obter uma lista dos comandos T-SQL que atualmente não estão disponíveis.
  • Se uma transação tiver inserção de dados numa tabela vazia e emitir um SELECT antes de fazer o rollback, as estatísticas geradas automaticamente ainda poderão refletir os dados não confirmados, causando 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 após um INSERT grande, atualize as estatísticas para as colunas mencionadas em seu SELECT.

Conteúdos relacionados

  • Last updated on