Condividi tramite

Procedura consigliata di collegamento Istanza gestita - Istanza gestita di SQL di Azure

  • Articolo

Si applica a: Istanza gestita di SQL di Azure SQL

Questo articolo illustra le procedure consigliate quando si usa il collegamento Istanza gestita per replicare i dati tra Istanza gestita di SQL di Azure e le istanze di SQL Server ospitate ovunque, fornendo la replica dei dati quasi in tempo reale tra le repliche collegate.

Eseguire regolarmente i backup del log

Se SQL Server è il server primario iniziale, è importante eseguire il primo backup del log in SQL Server dopo il completamento del seeding iniziale, quando il database non è più nello stato Ripristino… in Istanza gestita di SQL di Azure. Eseguire quindi regolarmente i backup del log delle transazioni di SQL Server per mantenere le dimensioni integre del file di log delle transazioni mentre SQL Server è nel ruolo primario.

La funzionalità di collegamento replica i dati tramite i gruppi di disponibilità distribuiti basati sui gruppi di disponibilità Always On. La replica dei dati con gruppi di disponibilità distribuiti si basa sulla replica dei record del log delle transazioni. Nessun record del log delle transazioni può essere troncato dal database nell'istanza primaria di SQL Server fino a quando non vengono replicati nel database nella replica secondaria. Se la replica dei record del log delle transazioni è lenta o bloccata a causa di problemi di connessione di rete, il file di log continua a crescere nell'istanza primaria. La velocità di crescita dipende dall'intensità del carico di lavoro e dalla velocità di rete. Se si verifica un'interruzione prolungata della connessione di rete e un carico di lavoro elevato nell'istanza primaria, il file di log può occupare tutto lo spazio di archiviazione disponibile.

L'esecuzione di backup regolari del log delle transazioni tronca il log delle transazioni e riduce al minimo il rischio di esaurimento dello spazio nell'istanza primaria di SQL Server a causa della crescita dei file di log. Non è necessaria alcuna azione aggiuntiva quando Istanza gestita di SQL è il principale perché i backup del log sono già stati eseguiti automaticamente. Eseguendo regolarmente i backup dei log nell'istanza primaria di SQL Server, il database è più resiliente agli eventi di crescita dei log non pianificati. Valutare la possibilità di pianificare le attività di backup giornaliere del log usando un processo di SQL Server Agent.

È possibile usare uno script Transact-SQL (T-SQL) per eseguire il backup del file di log, ad esempio l'esempio fornito in questa sezione. Sostituire i segnaposto nello script di esempio con il nome del database, il nome e il percorso del file di backup e la descrizione.

Per eseguire il backup del log delle transazioni, usare lo script Transact-SQL (T-SQL) di esempio seguente in SQL Server:

-- Execute on SQL Server
-- Take log backup
BACKUP LOG [<DatabaseName>]
TO DISK = N'<DiskPathandFileName>'
WITH NOFORMAT, NOINIT,
NAME = N'<Description>', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 1

Usare il comando Transact-SQL (T-SQL) seguente per controllare lo spazio del log usato dal database in SQL Server:

-- Execute on SQL Server
DBCC SQLPERF(LOGSPACE);

L'output della query è simile all'esempio seguente per il database di esempio tpcc:

Screenshot con i risultati del comando che mostra le dimensioni e lo spazio del file di log usati

In questo esempio il database ha usato il 76% del log disponibile, con dimensioni del file di log assolute di circa 27 GB (27.971 MB). Le soglie per l'azione variano in base al carico di lavoro. Nell'esempio precedente, le dimensioni del log delle transazioni e la percentuale di utilizzo del log sono in genere un'indicazione che è consigliabile eseguire un backup del log delle transazioni per troncare il file di log e liberare spazio oppure eseguire backup del log più frequenti. Potrebbe anche essere un'indicazione che il troncamento del log delle transazioni è bloccato da transazioni aperte. Per altre informazioni sulla risoluzione dei problemi relativi a un log delle transazioni in SQL Server, vedere Risolvere i problemi relativi a un log delle transazioni completo (errore di SQL Server 9002). Per altre informazioni sulla risoluzione dei problemi relativi a un log delle transazioni in Istanza gestita di SQL di Azure, vedere Risolvere gli errori del log delle transazioni con Istanza gestita di SQL di Azure.

Nota

Quando si partecipa a un collegamento, i backup automatici del log delle transazioni e completi vengono eseguiti da Istanza gestita di SQL indipendentemente dal fatto che si tratti o meno della replica primaria. I backup differenziali non vengono eseguiti, il che può causare tempi di ripristino più lunghi.

Trovare la corrispondenza della capacità delle prestazioni tra le repliche

Quando si usa la funzionalità di collegamento, è importante trovare una corrispondenza con la capacità delle prestazioni tra SQL Server e Istanza gestita di SQL per evitare problemi di prestazioni se la replica secondaria non riesce a tenere il passo con la replica dalla replica primaria o dopo il failover. La capacità delle prestazioni include core CPU (o vCore in Azure), memoria e velocità effettiva di I/O.

È possibile controllare le prestazioni della replica con le dimensioni della coda di rollforward nella replica secondaria. La dimensione della coda di rollforward indica il numero di record di log in attesa di essere di nuovo nella replica secondaria. Una dimensione della coda di rollforward costantemente elevata indica che la replica secondaria non è in grado di mantenere il passo con la replica primaria. È possibile controllare le dimensioni della coda di rollforward nei modi seguenti:

Se le dimensioni della coda di rollforward sono costantemente elevate, prendere in considerazione l'aumento delle risorse nella replica secondaria.

Ruotare il certificato

È possibile che il certificato usato per proteggere l'endpoint del mirroring del database scada; questo può causare una riduzione delle prestazioni del collegamento. Per evitare questo problema, ruotare il certificato prima che scada.

Usare il comando Transact-SQL (T-SQL) seguente per controllare la data di scadenza del certificato corrente:

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK'

Se il certificato sta per scadere o è già scaduto, è possibile creare un nuovo certificato e quindi modificare l'endpoint esistente per sostituire il certificato corrente.

Dopo aver configurato l'endpoint per l'uso del nuovo certificato, è possibile eliminare il certificato scaduto.

Aggiungere flag di traccia di avvio

In SQL Server sono presenti due flag di traccia (-T1800 e -T9567) che, se aggiunti come parametri di avvio, possono ottimizzare le prestazioni della replica dei dati tramite il collegamento. Per altre informazioni, vedere Abilitare i flag di traccia di avvio.

Contenuto correlato

Per usare il collegamento:

Per altre informazioni sul collegamento:

Per altri scenari di replica e migrazione, prendere in considerazione: