Condividi tramite

Repiantamento automatico per i database con mirroring di Fabric da SQL Azure Managed Instance

Questo articolo tratta della reinizializzazione automatica per il mirroring del database in Istanza gestita di Azure SQL.

In determinate condizioni, se c'è un ritardo nel mirroring verso Fabric, ne può risultare un aumento nell'utilizzo del file di log delle transazioni. Il log delle transazioni non può essere troncato fino a quando le modifiche confermate non siano replicate nel database in 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 transazioni OLTP critiche, il mirroring nel database SQL di Azure e nell'istanza gestita di SQL di Azure usa la funzionalità autoreseed che consente al log delle transazioni di essere troncato e reinizializzato 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. Un nuovo reseed comporta la generazione di una nuova istantanea iniziale delle tabelle configurate per il mirroring e la replica in Microsoft Fabric. Dopo lo snapshot, le modifiche incrementali vengono replicate.

Nel database SQL di Azure e nell'istanza gestita di SQL di Azure, è possibile che si verifichi di nuovo a livello di database o a livello di tabella.

  • Rinnovo a livello di database: Il mirroring continuo dei dati è sospeso per tutte le tabelle del database abilitate per il mirroring, il log delle transazioni viene troncato e il mirroring è reinizializzato per il database ripristinando lo snapshot iniziale di tutte le tabelle abilitate per il mirroring. Le modifiche incrementali ricominciano a replicarsi continuamente.

  • Reseed a livello di tabella: Il mirroring continuo dei dati viene arrestato solo per le tabelle che richiedono il reseed. Il mirroring viene reinizializzato per le tabelle interessate ripubblicando lo snapshot iniziale. Le modifiche incrementali ricominciano a replicarsi continuamente.

Cause della reinizializzazione automatica a livello di database

Un ripristino a livello di database garantisce la disponibilità di scrittura nel database, assicurando che il log delle transazioni non raggiunga la dimensione massima. Le dimensioni massime del log delle transazioni si basano sull'obiettivo del livello di servizio del database SQL di Azure o dell'istanza gestita di SQL di Azure. L'utilizzo del log delle transazioni per un database abilitato per il mirroring Fabric può continuare a crescere e ostacolare il troncamento del log. Quando le dimensioni del log delle transazioni raggiungono il limite massimo definito, le scritture nel database hanno esito negativo.

  • Il mirroring può impedire il troncamento del log per diversi motivi:

    • La latenza nel mirroring dei dati dall'origine al database di destinazione mirroring impedisce alle transazioni in attesa di replica di essere troncate dal log delle transazioni.
    • Le transazioni replicate con esecuzione prolungata e in attesa di replica non possono essere troncate, occupando spazio nel log delle transazioni.
    • Gli errori persistenti durante la scrittura nell'area di ricezione in OneLake possono impedire la replica.

      • Questo scenario può essere causato da autorizzazioni insufficienti. Il mirroring in Fabric utilizza l'identità gestita assegnata dal sistema (SAMI) o l'identità gestita assegnata dall'utente (UAMI) per scrivere nella zona di atterraggio in One Lake. Se questa configurazione non è configurata correttamente, la replica delle transazioni può avere esito negativo ripetutamente.

        Annotazioni

        Il supporto per l'identità gestita assegnata dall'utente è attualmente in anteprima.

  • Se la capacità dell'infrastruttura viene sospesa e ripresa, lo stato del database con mirroring rimane sospeso. Di conseguenza, le modifiche apportate nell'origine non vengono replicate in OneLake. Per riprendere il mirroring, passare al database con mirroring nel portale di Infrastruttura, selezionare Riprendi replica. Il mirroring continua da dove è stato sospeso.

    Se la capacità del Fabric rimane sospesa per molto tempo, il mirroring potrebbe non riprendere dal punto di arresto e ricaricherà i dati dall'inizio. Questo perché la sospensione prolungata del mirroring può causare l'aumento dell'utilizzo del log delle transazioni del database di origine e impedire il troncamento del log. Quando il mirroring viene ripreso, se lo spazio del file di log delle transazioni utilizzato è quasi esaurito, verrà avviata una reinizializzazione del database per liberare lo spazio nel log.

Cause della reinizializzazione automatica a livello di tabella

Quando si verificano modifiche dello schema nelle tabelle di origine abilitate per il mirroring, lo schema per tali tabelle con mirroring in Fabric non corrisponde più all'origine. Questo problema può verificarsi a causa delle istruzioni T-SQL DDL (Data Definition Language) seguenti ALTER TABLE nell'origine:

  • Aggiungere/eliminare/modificare/rinominare la colonna
  • Elimina/Rinomina tabella
  • Aggiungi una chiave primaria non clusterizzata

La reinizializzazione viene attivata solo per le tabelle interessate.

Diagnosi

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. Per altre informazioni sulla risoluzione dei problemi di utilizzo dei log nel database SQL di Azure, vedere Risolvere gli errori del log delle transazioni con il database SQL di Azure.

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

Durante la reimpostazione

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.

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 .
  • 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.

Controllare se è stato attivato un reset a livello di database

Se l'intero database viene riserializzato, verificare le seguenti condizioni.

  • 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.

Verificare se è stato attivato un rinumeramento a livello di tabella

  • Per qualsiasi tabella di cui viene eseguito il reinvio, cercare un valore di 7 per la state colonna in sys.sp_help_change_feed_table.

    Per altre informazioni, vedere sys.sp_help_change_feed_table.

Contenuti correlati

  • Last updated on