Condividi tramite

Configurare la reinizialità automatica per i database con mirroring dell'infrastruttura da SQL Server

Questo articolo illustra la reinizializzazione automatica per il mirroring di un database da un'istanza di SQL Server.

Esistono alcune situazioni in cui i ritardi nel mirroring in Fabric possono comportare un aumento dell'utilizzo dei file di log delle transazioni. Ciò avviene perché il log delle transazioni non può essere troncato fino a quando non è stato eseguito il commit delle modifiche nel database con mirroring. Quando le dimensioni del log delle transazioni raggiungono il limite massimo definito, le scritture nel database hanno esito negativo. Per proteggere i database operativi da errori di scrittura per le transazioni OLTP critiche, è possibile configurare un meccanismo autoreseed che consente di troncare il log delle transazioni e reinizializzare il mirroring del database in Fabric.

Un reinizializzato arresta il flusso delle transazioni in Microsoft Fabric dal database con mirroring e reinizializza il mirroring nello stato corrente. Ciò comporta la generazione di un nuovo snapshot iniziale delle tabelle configurate per il mirroring e la replica in Microsoft Fabric. Dopo lo snapshot, le modifiche incrementali vengono replicate.

Durante la reinizialità, l'elemento del database con mirroring in Microsoft Fabric è disponibile, ma non riceverà modifiche incrementali fino al completamento della reinizialità. La reseed_state colonna in sys.sp_help_change_feed_settings indica lo stato di reinvio.

La funzionalità di autoreseed è disabilitata per impostazione predefinita in SQL Server 2025, per abilitarla vedere Abilita autoreseed. La funzionalità autoreseed è abilitata e non può essere gestita o disabilitata nel database SQL di Azure e nell'istanza gestita di SQL di Azure.

In Mirroring dell'infrastruttura viene monitorato il log delle transazioni del database SQL di origine. Un autoreseed viene attivato solo quando vengono soddisfatte le tre condizioni seguenti:

  • Il log delle transazioni è maggiore della @autoreseedthreshold percentuale completa, 70ad esempio . In SQL Server configurare questo valore quando si abilita la funzionalità, con sys.sp_change_feed_configure_parameters.
  • Il motivo del riutilizzo del log è REPLICATION.
  • Poiché l'attesa di riutilizzo del log può essere generata per altre funzionalità, ad esempio la replica transazionale o CDC, l'esecuzione REPLICATION automatica avviene solo quando sys.databases.is_data_lake_replication_enabled = 1. Questo valore viene configurato dal mirroring dell'infrastruttura.

Diagnose

Per identificare se il mirroring dell'infrastruttura impedisce il troncamento del log per un database con mirroring, controllare la log_reuse_wait_desc colonna nella sys.databases vista del catalogo di sistema per verificare se il motivo è REPLICATION. Per altre informazioni sui tipi di attesa di riutilizzo del log, vedere Fattori che ritardano il troncamento del log delle transazioni. Per esempio:

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

Se la query mostra REPLICATION il tipo di attesa di riutilizzo del log, a causa del mirroring dell'infrastruttura il log delle transazioni non può svuotare le transazioni di cui è stato eseguito il commit e continuerà a riempirsi.

Usare lo script T-SQL seguente per controllare lo spazio totale dei log e l'utilizzo del log corrente e lo spazio disponibile:


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];

Abilitare l'autore

Se l'utilizzo del log restituito dallo script T-SQL precedente è quasi pieno (ad esempio, maggiore di 70%), valutare la possibilità di abilitare il database con mirroring per la reinizialità automatica usando la sys.sp_change_feed_configure_parameters stored procedure di sistema. Ad esempio, per abilitare il comportamento autoreseed:

USE <Mirrored database name>
GO
EXECUTE sys.sp_change_feed_configure_parameters 
  @autoreseed = 1
, @autoreseedthreshold = 70;

Per altre informazioni, vedere sys.sp_change_feed_configure_parameters.

Nel database di origine, il reinvio deve rilasciare lo spazio del log delle transazioni mantenuto dal mirroring. Eseguire un manuale CHECKPOINT nel database SQL Server di origine per forzare il rilascio dello spazio di log se il motivo di blocco è ancora REPLICATION dovuto al mirroring. Per altre informazioni, vedere CHECKPOINT (Transact-SQL).

Reinvio manuale

Come procedura consigliata, è possibile testare la reinizializzazione manuale per un database specifico usando la stored procedure seguente per comprendere l'impatto prima di attivare la funzionalità di reinizializzazione automatica.

USE <Mirrored database name>
GO
EXECUTE sp_change_feed_reseed_db_init @is_init_needed = 1;

Per altre informazioni, vedere sys.sp_change_feed_reseed_db_init.

Controllare se è stato attivato un nuovo

  • La colonna reseed_state nella procedure di sistema memorizzata sys.sp_help_change_feed_settings nel database SQL di origine indica il suo stato di ricampionamento corrente.

    • 0 = Normale.
    • 1 = Il database ha avviato il processo di reinizializzazione in Fabric. Stato di transizione.
    • 2 = Il database viene reinizializzato in Fabric e in attesa del riavvio della replica. Stato di transizione. Quando viene stabilita la replica, lo stato reinviato passa a 0.

    Per altre informazioni, vedere sys.sp_help_change_feed_settings.

  • Tutte le tabelle abilitate per il mirroring nel database avranno un valore di 7 nella colonna state in sys.sp_help_change_feed_table.

    Per altre informazioni, vedere sys.sp_help_change_feed_table.

Contenuti correlati

  • Last updated on