Repropagação automática para bancos de dados espelhados de malha da Instância Gerenciada SQL do Azure

Este artigo aborda a resemeadura automática para espelhar um banco de dados na instância gerida SQL do Azure.

Sob certas condições, se houver um atraso no espelhamento para o Fabric, pode resultar 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 para o banco de dados espelhado. Quando o tamanho do log de transações atinge seu limite máximo definido, as gravações no banco de dados falham.

Para proteger bases de dados operacionais contra falhas de escrita em transações OLTP críticas, o espelhamento no Azure SQL Database e no Azure SQL Managed Instance utiliza a capacidade de autoreseed que permite truncar o registo de transações e reinicializa o espelhamento da base de dados para Fabric.

Uma re-semeadura interrompe o fluxo de transações para o Microsoft Fabric a partir do banco de dados espelhado e reinicializa o espelhamento no estado atual. Uma nova reinicialização envolve gerar um novo instantâneo inicial das tabelas configuradas para espelhamento e replicá-lo no Microsoft Fabric. Após o snapshot, as alterações incrementais são replicadas.

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

Repropagação a nível de base de dados: O espelhamento contínuo de dados é interrompido para todas as tabelas no banco de dados que estão habilitadas para espelhamento, o log de transações é truncado, e o espelhamento é recomeçado para o banco de dados através 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.
Réplica a nível de tabela: O espelhamento contínuo de dados é interrompido apenas para tabelas que exigem re-seed. O espelhamento é reinicializado para as tabelas afetadas republicando o instantâneo inicial. Em seguida, as alterações incrementais retomam a replicação contínua.

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

Uma nova propagação no nível do banco de dados protege a disponibilidade de gravação do banco de dados, garantindo que o log de transações não aumente para o tamanho máximo. O tamanho máximo do log de transações é baseado no Objetivo de Nível de Serviço do banco de dados do Banco de Dados SQL do Azure ou da Instância Gerenciada SQL do Azure. O uso do log de transações para um banco de dados habilitado para espelhamento Fabric pode continuar a aumentar e impedir o truncamento do log. Quando o tamanho do log de transações atinge o limite máximo definido, as gravações no banco de dados falham.

O truncamento de log impedido devido ao espelhamento pode acontecer por vários motivos:
- A latência no espelhamento de dados da origem para o banco de dados espelhado impede que as transações pendentes de replicação sejam truncadas do log de transações.
- As transações replicadas de longa duração à espera de replicação não podem ser truncadas, mantendo o espaço do log de transações.
- Erros persistentes ao escrever na zona de aterragem no OneLake podem impedir a replicação.
  - Este cenário pode ser causado por permissões insuficientes. O espelhamento para o Fabric utiliza Identidade Gerida Atribuída por Sistema (SAMI) ou Identidade Gerida Atribuída pelo Utilizador (UAMI) para escrever na zona de aterragem em One Lake. Se isto não estiver devidamente configurado, a replicação das transações pode falhar repetidamente.
    
    Observação
    
    O suporte para Identidade Gerida Atribuída pelo Utilizador (UAMI) está atualmente em fase de pré-visualização.
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 muito tempo, o espelhamento pode não ser retomado a partir de seu ponto de interrupção e reporá os dados desde o início. Isso ocorre porque pausar o espelhamento por muito tempo pode fazer com que o uso do log de transações do banco de dados de origem cresça e impeça o truncamento do log. Quando o espelhamento for retomado, se o espaço utilizado do arquivo de log de transações estiver quase cheio, uma reinicialização do banco de dados será iniciada para libertar o espaço ocupado no log.

Causas da repropagaçã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 na Malha não corresponde mais à origem. Isso pode acontecer devido às seguintes instruções de Linguagem de Definição de Dados (DDL) T-SQL na origem:

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

A repropagação só é acionada para as tabelas afetadas.

Diagnosticar

Para identificar se o espelhamento de malha está a impedir o truncamento do log de um banco de dados em espelho, verifique a coluna log_reuse_wait_desc na vista do catálogo de sistema sys.databases para ver se o motivo é REPLICATION. Para mais informações sobre os tipos de espera na reutilização de logs, 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 tipo de espera de reutilização do log, devido ao espelhamento do Fabric, o log de transações não conseguirá esvaziar as transações já confirmadas e continuará a ser preenchido. Para obter solução de problemas adicionais de uso de log no Banco de Dados SQL do Azure, consulte Solucionar erros de log de transações com o Banco de Dados SQL do Azure.

Use o seguinte script T-SQL para verificar o espaço total do log, o uso atual do log 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 nova semente

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

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

O log de transações está mais de @autoreseedthreshold por cento cheio, por exemplo, 70.
O motivo da reutilização do log é REPLICATION.
Como a espera de reutilização de REPLICATION log pode ser acionada 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 Fabric.

Verificar se uma nova propagação no nível do banco de dados foi acionada

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

A coluna reseed_state no procedimento armazenado sys.sp_help_change_feed_settings do sistema na base de dados SQL de origem indica o estado atual de reseed.
- 0 = Normal.
- 1 = O banco de dados iniciou o processo de reinicialização para Fabric. Estado de transição.
- 2 = O banco de dados está sendo reinicializado para malha e aguardando a reinicialização da replicação. Estado de transição. Quando a replicação é estabelecida, o estado de nova propagação é 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 para a state coluna em sys.sp_help_change_feed_table.

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

Verifique se uma nova propagação no nível da tabela foi acionada

Para qualquer tabela que esteja a ser inicializada novamente, procure 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.

Solucionar problemas de bases de dados espelhadas do Azure SQL Managed Instance Fabric

Feedback

Esta página foi útil?

Last updated on 2025-12-02