Reseed automático para bancos de dados espelhados do Fabric da Instância Gerenciada de SQL do Azure

Este artigo explora o processo automático de reseeding para replicação de um banco de dados na Instância Gerenciada do Azure SQL.

Em determinadas condições, se houver um atraso no espelhamento para o Fabric, isso pode resultar em um aumento no uso do arquivo de log de transações. O log de transações não pode ser truncado até que as alterações confirmadas sejam replicadas no banco de dados espelhado. Depois que o tamanho do log de transações atingir seu limite máximo definido, as gravações no banco de dados falharão.

Para proteger os bancos de dados operacionais contra falhas de gravação para transações OLTP críticas, o espelhamento no Banco de Dados SQL do Azure e na Instância Gerenciada de SQL do Azure usa o recurso autoreseed que permite que o log de transações seja truncado e reinicializa o espelhamento de banco de dados para o Fabric.

Uma resseada interrompe o fluxo de transações para o Microsoft Fabric do banco de dados espelhado e reinicializa o espelhamento no estado atual. Um reseed envolve a geração de um novo instantâneo inicial das tabelas configuradas para espelhamento e sua replicação para o Microsoft Fabric. Após o instantâneo, as alterações incrementais são replicadas.

No Banco de Dados SQL do Azure e na Instância Gerenciada do Azure SQL, o reseed pode ocorrer no nível do banco de dados ou no nível da tabela.

Reinicialização do nível de banco de dados: Interrompe-se o espelhamento contínuo de dados em todas as tabelas do banco de dados habilitadas para espelhamento, o log de transações é truncado e o espelhamento é reinicializado para o banco de dados por meio da republicação do instantâneo inicial de todas as tabelas habilitadas para espelhamento. Em seguida, as alterações incrementais retomam a replicação contínua.
Ressementear a nível de tabela: O espelhamento contínuo de dados é interrompido apenas para tabelas que exigem ressemeadura. O espelhamento é reinicializado para essas tabelas impactadas, republicando o instantâneo inicial. Em seguida, as alterações incrementais retomam a replicação contínua.

Causas da reutilização automática no nível do banco de dados

Um reseed no nível do banco de dados protege a disponibilidade de escrita do banco de dados, garantindo que o log de transações não cresça até o tamanho máximo. O tamanho máximo do log de transações baseia-se no Objetivo de Nível de Serviço do Banco de Dados SQL do Azure ou da Instância Gerenciada do SQL do Azure. O uso de log de transações para um banco de dados habilitado para o espelhamento do Fabric pode continuar aumentando e impedindo o truncamento de log. Depois que o tamanho do log de transações atingir o limite máximo definido, as gravações no banco de dados falharão.

A prevenção do truncamento do log devido ao espelhamento pode ocorrer por vários motivos:
- A latência no espelhamento de dados da origem para o banco de dados espelhado impede que transações pendentes de replicação sejam truncadas do log de transações.
- Transações replicadas de execução prolongada pendentes de replicação não podem ser truncadas, ocupando espaço no log de transações.
- Erros persistentes ao gravar na zona de aterrissagem no OneLake podem impedir a replicação.
  - Esse cenário pode ser causado por permissões insuficientes. O espelhamento no Fabric usa SAMI (Identidade Gerenciada Atribuída pelo Sistema) ou UAMI (Identidade Gerenciada Atribuída pelo Usuário) para gravar na zona de destino no One Lake. Se isso não estiver configurado corretamente, a replicação de transações poderá falhar repetidamente.
    
    Observação
    
    O suporte à UAMI (Identidade Gerenciada Atribuída ao Usuário) está atualmente em versão prévia.
Se a capacidade do Fabric for pausada e retomada, o status do banco de dados espelhado permanecerá pausado. Como resultado, as alterações feitas na origem não são replicadas para o OneLake. Para retomar o espelhamento, vá para o banco de dados espelhado no portal do Fabric, selecione Retomar replicação. O espelhamento continua de onde foi pausado.

Se a capacidade do Fabric permanecer pausada por um longo tempo, o espelhamento poderá não ser retomado do ponto de parada e redirecionará os dados desde o início. Isso ocorre porque pausar o espelhamento por um longo tempo pode fazer com que o uso do log de transações do banco de dados de origem aumente e impeça o truncamento do log. Quando o espelhamento for retomado, se o espaço de arquivo de log de transações usado estiver quase cheio, um rebalanceamento do banco de dados será iniciado para liberar o espaço do log que está retido.

Causas da ressecação automática no nível da tabela

Quando ocorrem alterações de esquema nas tabelas de origem habilitadas para espelhamento, o esquema dessas tabelas espelhadas no Fabric não corresponde mais à origem. Isso pode acontecer devido às seguintes ALTER TABLE instruções T-SQL da DDL (linguagem de definição de dados) na origem:

Adicionar/soltar/alterar/renomear coluna
Truncar/renomear tabela
Adicionar chave primária não clusterizada

O ressemeio é acionado apenas para as tabelas afetadas.

Diagnosticar

Para identificar se o espelhamento do Fabric está impedindo o truncamento de log para um banco de dados espelhado, verifique a log_reuse_wait_desc coluna no modo de exibição do catálogo do sys.databases sistema para ver se o motivo é REPLICATION. Para obter mais informações sobre os tipos de espera de reutilização de log, consulte Fatores que atrasam o truncamento do log de transações. Por exemplo:

SELECT [name], log_reuse_wait_desc 
FROM sys.databases 
WHERE is_data_lake_replication_enabled = 1;

Se a consulta mostrar REPLICATION o tipo de espera de reutilização de log, devido ao espelhamento do Fabric, o log de transações não poderá esvaziar transações confirmadas e continuará a ser preenchido. Para obter mais informações sobre a solução de problemas de uso de log no Banco de Dados SQL do Azure, consulte Solucionar problemas de erros de log de transações com o Banco de Dados SQL do Azure.

Use o script T-SQL a seguir para verificar o espaço total do log, o uso do log atual e o espaço disponível:


USE <Mirrored database name>
GO 
--initialize variables
DECLARE @total_log_size bigint = 0; 
DECLARE @used_log_size bigint = 0;
DECLARE @size int;
DECLARE @max_size int;
DECLARE @growth int;

--retrieve total log space based on number of log files and growth settings for the database
DECLARE sdf CURSOR
FOR
SELECT SIZE*1.0*8192/1024/1024 AS [size in MB],
            max_size*1.0*8192/1024/1024 AS [max size in MB],
            growth
FROM sys.database_files
WHERE TYPE = 1 
OPEN sdf 
FETCH NEXT FROM sdf INTO @size,
                @max_size,
                @growth 
WHILE @@FETCH_STATUS = 0 
BEGIN
SELECT @total_log_size = @total_log_size + 
CASE @growth
        WHEN 0 THEN @size
        ELSE @max_size
END 
FETCH NEXT FROM sdf INTO @size,
              @max_size,
              @growth 
END 
CLOSE sdf;
DEALLOCATE sdf;

--current log space usage
SELECT @used_log_size = used_log_space_in_bytes*1.0/1024/1024
FROM sys.dm_db_log_space_usage;

-- log space used in percent
SELECT @used_log_size AS [used log space in MB],
       @total_log_size AS [total log space in MB],
       @used_log_size/@total_log_size AS [used log space in percentage];

Durante a resseada

Durante a resseada, o item de banco de dados espelhado no Microsoft Fabric está disponível, mas não receberá alterações incrementais até que a resseada seja concluída. A reseed_state coluna em sys.sp_help_change_feed_settings indica o estado de novamente.

No Espelhamento do Fabric, o log de transações do banco de dados SQL de origem é monitorado. Um autoreseed só será disparado quando as três condições a seguir forem verdadeiras:

O log de transações está mais de @autoreseedthreshold porcentagem cheio, por exemplo, 70.
O motivo da reutilização do log é REPLICATION.
Como a espera de reutilização de REPLICATION log pode ser gerada para outros recursos, como replicação transacional ou CDC, o autoreseed só ocorre quando sys.databases.is_data_lake_replication_enabled = 1. Esse valor é configurado pelo Espelhamento de Malha.

Verificar se um reseed no nível do banco de dados foi iniciado

Se todo o banco de dados estiver sendo reutilizado, procure as seguintes condições.

A coluna reseed_state no procedimento armazenado do sistema sys.sp_help_change_feed_settings no banco de dados SQL de origem indica seu estado atual de nova delimitação.
- 0 = Normal.
- 1 = O banco de dados iniciou o processo de reinicialização para o Fabric. Estado transitório.
- 2 = O banco de dados está sendo reinicializado no Fabric e aguardando a reinicialização da replicação. Estado transitório. Quando a replicação é estabelecida, o estado de novamente é movido para 0.
Para obter mais informações, consulte sys.sp_help_change_feed_settings.
Todas as tabelas habilitadas para espelhamento no banco de dados terão um valor de 7 na coluna state em sys.sp_help_change_feed_table.

Para obter mais informações, consulte sys.sp_help_change_feed_table.

Verificar se uma nova sequência no nível da tabela foi iniciada

Para qualquer tabela que esteja sendo re-semeada, procure por um valor de 7 para a coluna state em sys.sp_help_change_feed_table.

Para obter mais informações, consulte sys.sp_help_change_feed_table.

Solucionar problemas de bancos de dados espelhados do Azure SQL Managed Instance Fabric

Comentários

Esta página foi útil?

Last updated on 2025-12-03