Transações no Fabric Data Warehouse

Aplica-se a:✅ ponto de extremidade de análise do SQL e Warehouse no Microsoft Fabric

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

O Fabric Data Warehouse dá suporte a transações compatíveis 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 em nenhuma das tabelas 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, 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 TRANCOMMIT TRANe ROLLBACK TRAN) padrão para transações explícitas. Para obter mais informações, consulte: - BEGIN TRANSACTION - COMMIT TRANSACTION - ROLLBACK TRANSACTION

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

O armazém no Microsoft Fabric dá suporte a transações que se estendem entre armazéns que estão no 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 o bloqueamento no Fabric Data Warehouse

O Fabric Data Warehouse usa o bloqueio no nível da tabela, independentemente de uma consulta tocar uma linha ou muitas. A tabela a seguir fornece uma lista de quais bloqueios são usados para diferentes operações T-SQL.

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

Fabric Data Warehouse impõe 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 Compreensão dos conflitos de gravação-gravação no 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 Mecanismo de Banco de Dados 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 Mecanismo de Banco de Dados 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.
• Evite colocar instruções DDL dentro de transações de usuário explícitas (BEGIN TRAN). Transações de longa duração que modificam tabelas podem causar problemas de bloqueio para outras operações DML e consultas, tanto em tabelas de usuário quanto em visualizações do catálogo do sistema, como sys.tables. Para monitorar e solucionar possíveis conflitos de bloqueio, use sys.dm_tran_locks.
• Monitore bloqueios e conflitos no armazém.
  • Use sys.dm_tran_locks para inspecionar os bloqueios atuais.
• O Fabric Data Warehouse dá suporte a algumas instruções DDL dentro de transações definidas pelo usuário, mas não são recomendadas em transações de execução longa. Dentro das transações, as instruções DDL podem bloquear transações simultâneas ou causar conflitos de gravação/gravação.

Entender conflitos de gravação simultânea no Armazém de Dados Fabric

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

Conflitos de escrita ou conflitos de atualização são possíveis no nível da tabela, já que o Fabric Data Warehouse usa bloqueio em nível de 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.

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.
• Conflitos de gravação e gravação com o serviço de compactação de dados em segundo plano do Fabric Data Warehouse são possíveis, mas normalmente são impedidos 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 com o retorno de um erro. Esses conflitos são avaliados no nível da tabela e não no nível do arquivo de parquet individual.

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

Limitações

• Não há suporte para transações distribuídas, por exemplo. BEGIN DISTRIBUTED TRANSACTION
• ALTER TABLE não há suporte em uma transação explícita.
• 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 a área de superfície T-SQL no Fabric Data Warehouse para obter 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 SELECT após um grande INSERT, atualize as estatísticas das colunas mencionadas em seu SELECT.

Conteúdo relacionado

• Consultar o ponto de extremidade de análise do SQL ou Warehouse no Microsoft Fabric
• Tables