Condividi tramite

Reinizializzazione automatica per i database con mirroring di Fabric dal servizio Azure SQL Database

Questo articolo illustra la risemina automatica per il mirroring di un database in Azure SQL Database.

In determinate condizioni, se si verifica un ritardo nel mirroring su Fabric, può risultare un aumento dell'utilizzo del file di log delle transazioni. Il log delle transazioni non può essere troncato fino a quando le modifiche confermate non sono replicate nel database mirror. 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 oggetto 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.

Nel database SQL di Azure e nell'istanza gestita di Azure SQL, il ripristino dei valori di identità può avvenire a livello del database o a livello della tabella.

  • Livello di database di cui è stato reinviato: Il mirroring continuo dei dati viene arrestato per tutte le tabelle del database abilitate per il mirroring, il log delle transazioni viene troncato e il mirroring viene reinizializzato per il database ripubblicando lo snapshot iniziale di tutte le tabelle abilitate per il mirroring. Le modifiche incrementali riprendono quindi la replica continua.

  • Livello di reseed della tabella: Il mirroring continuo dei dati viene interrotto solo per le tabelle che richiedono il reseed. Il mirroring viene reinizializzato per le tabelle interessate ripubblicando lo snapshot iniziale. Le modifiche incrementali riprendono quindi la replica continua.

Cause della reinizialità automatica a livello di database

Una reimpostazione a livello di database protegge la disponibilità di scrittura nel database assicurando che il log delle transazioni non cresca fino alla 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 impedire il troncamento del log. Quando le dimensioni del log delle transazioni raggiungono il limite massimo definito, le scritture nel database hanno esito negativo.

  • Il troncamento del log impedito a causa del mirroring può verificarsi per diversi motivi:

    • La latenza nella sincronizzazione dei dati dall'origine al database con mirroring impedisce che le transazioni in sospeso per la replica vengano troncate dal log delle transazioni.
    • Impossibile troncare le transazioni replicate con esecuzione prolungata in attesa di replicazione, occupando lo spazio del 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à del Fabric viene sospesa e poi ripresa, lo stato del database in mirroring resta In Pausa. 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à dell'infrastruttura rimane sospesa per molto tempo, il mirroring potrebbe non riprendere dal punto di arresto e reinvierà 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 utilizzato nel file del log delle transazioni è quasi pieno, verrà avviato un ripristino del database per liberare lo spazio occupato dal log.

Cause della reinizializzazione automatica livello 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
  • Tronca/rinomina tabella
  • Aggiungere una chiave primaria non clusterizzata

Il ripristino viene attivato 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 il reinsedimento

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 è stata attivata una nuova inizializzazione a livello di database

Se l'intero database viene reinviato, cercare le condizioni seguenti.

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

Controllare se è stato attivato un reinserimento nel contesto della 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