Repropagação automática para bancos de dados espelhados de malha do Banco de Dados SQL do Azure

Este artigo aborda a re-semeadura automática para espelhamento de um banco de dados no Banco de Dados SQL do Azure.

Sob certas condições, se houver um atraso no espelhamento para o Fabric, o uso aumentado do arquivo de log de transações pode ocorrer. 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. Um reseeding 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 Azure SQL Database e na Azure SQL Managed Instance, o reseed pode ocorrer ao nível do banco de dados ou da tabela.

Nível de banco de dados resemeado: O espelhamento de dados em curso é interrompido para todas as tabelas no banco de dados habilitadas para espelhamento, o log de transações é truncado e o espelhamento é reinicializado para o banco de dados respublicando o instantâneo primário de todas as tabelas habilitadas para espelhamento. Em seguida, as alterações incrementais retomam a replicação contínua.
Nível de tabela reseed: O espelhamento contínuo de dados é interrompido apenas para tabelas que exigem repropagação. 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 re-semeadura automática ao nível do banco de dados

Uma reanálise 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 cresça até ao tamanho máximo. O tamanho máximo do log de transações é determinado pelo Objetivo de Nível de Serviço (SLO) da base de dados no Azure SQL Database ou na Azure SQL Managed Instance. O uso do log de transações para um banco de dados habilitado para espelhamento de Fabric pode continuar a crescer e impedir o truncamento de 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 pendentes 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 a Identidade Gerida Atribuída ao Utilizador (UAMI) está atualmente em versão de pré-visualização.
Se a capacidade de 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 da malha permanecer pausada por muito tempo, o espelhamento dos dados pode não ser retomado no ponto onde parou e vai reiniciar a transferência dos 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 do arquivo de log de transações usado estiver quase cheio, uma nova propagação do banco de dados será iniciada para liberar o espaço de log retido.

Causas do reset automático ao nível de 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 ALTER TABLE instruções T-SQL DDL (linguagem de definição de dados) na fonte de dados:

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

A reiniciação é acionada apenas 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 o re-semeamento

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 inteiro estiver sendo reindexado, verifique 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 sendo repropagada, procure 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.

Solucionar problemas de bancos de dados espelhados de malha do Banco de Dados SQL do Azure

Feedback

Esta página foi útil?

Last updated on 2025-12-02