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

Si applica a:Istanza gestita di SQL di Azure SQL

Questo articolo illustra le procedure consigliate per l'uso del collegamento Istanza gestita per replicare i dati tra Istanza gestita di SQL di Azure e le istanze di SQL Server ospitate ovunque. Il collegamento fornisce 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, eseguire il primo backup del log in SQL Server dopo il termine del seeding iniziale, quando il database non è più nello stato di Ripristino... su Istanza gestita di SQL di Azure. Eseguire quindi regolarmente i backup del log delle transazioni di SQL Server per mantenere integre le dimensioni del file di log delle transazioni mentre SQL Server è nel ruolo primario.

La funzionalità di collegamento replica i dati usando la tecnologia dei gruppi di disponibilità distribuiti in base ai gruppi di disponibilità Always On. La replica dei dati del gruppo di disponibilità distribuito si basa sulla replica dei record del log delle transazioni. L'istanza primaria di SQL Server non può troncare i record del log delle transazioni dal database fino a quando non vengono replicati nel database nella replica secondaria. Se i problemi di connessione di rete causano un rallentamento o un blocco della replica dei record del log delle transazioni, il file di log continua a crescere nell'istanza primaria. L'intensità del carico di lavoro e la velocità di rete determinano la velocità di crescita. Se un'interruzione della connessione di rete è prolungata e il carico di lavoro nell'istanza primaria è elevato, 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:

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 indicano in genere che è necessario 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.

Trovare la corrispondenza della capacità delle prestazioni tra le repliche

Quando si utilizza la funzionalità di collegamento, abbina la capacità delle prestazioni tra SQL Server e Istanza Gestita di SQL. Questo abbinamento consente di evitare problemi di prestazioni se la replica secondaria non riesce a sincronizzarsi con la sincronizzazione dalla replica primaria o in seguito al failover. La capacità delle prestazioni include core CPU (o vCore in Azure), memoria e velocità effettiva di I/O.

È possibile monitorare le prestazioni della replica controllando le dimensioni della coda di redo nella replica secondaria. La dimensione della coda di redo indica il numero di record di log in attesa di essere rifatti sulla replica secondaria. Una dimensione costantemente elevata della coda di redo indica che la replica secondaria non riesce a tenere il passo con la replica primaria. È possibile controllare le dimensioni della coda di rollforward nei modi seguenti:

• Valore redo_queue_size nella vista a gestione dinamica sys.dm_hadr_database_replica_states nella replica primaria.
• Valore InstanceRedoLagReplicationSeconds in Get-AzSqlInstanceLink nella replica primaria.

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

Ruotare il certificato

Potrebbe essere necessario aggiornare manualmente il certificato utilizzato per proteggere l'endpoint del mirroring del database su SQL Server. Poiché il servizio gestisce e ruota automaticamente il certificato usato per proteggere l'endpoint del mirroring del database in Istanza gestita di SQL, non è necessario ruotarlo manualmente.

SQL Server

Il certificato usato per proteggere l'endpoint del mirroring del database in SQL Server può scadere. Se il certificato scade, può causare una riduzione delle prestazioni dei collegamenti. Per evitare questo problema, ruotare il certificato prima della scadenza.

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

Istanza gestita di SQL

Il certificato dell'endpoint del mirroring del database nell'Istanza SQL Gestita viene ruotato automaticamente a intervalli regolari. Non è necessario monitorare la data di scadenza per il certificato dell'endpoint del mirroring del database in Istanza gestita di SQL, purché sia possibile convalidare correttamente la catena di certificati in SQL Server .

Convalidare la catena di certificati in SQL Server

I problemi relativi alla catena di certificati possono compromettere il collegamento. Per evitare questo problema, convalidare regolarmente la catena di certificati in SQL Server.

Gli scenari seguenti possono causare problemi con la catena di certificati in SQL Server:

• Rotazione pianificata dei certificati in Istanza gestita di SQL.
• Modifiche accidentali o accidentali ai certificati in SQL Server, ad esempio l'eliminazione o la modifica del certificato usato per proteggere l'endpoint del mirroring del database.

Prima di tutto, determinare il valore certificate_id del certificato dell'endpoint MI importato sostituendo il valore di <ManagedInstanceFQDN> e successivamente eseguire la seguente query in SQL Server.

-- Run on SQL Server 
USE master 
SELECT name, subject, certificate_id, start_date, expiry_date 
FROM sys.certificates 
WHERE issuer_name LIKE '%Microsoft Corporation%' AND name = '<ManagedInstanceFQDN>' 
GO 

Convalidare quindi il certificato sostituendo il valore di <certificate_id> dal risultato della query precedente e quindi eseguendo la query seguente in SQL Server:

-- Run on SQL Server 
USE master
EXEC sp_validate_certificate_ca_chain <certificate_id> 
GO 

Una risposta di Commands completed successfully. Completion time: ... indica che il certificato dell'endpoint MI è stato convalidato correttamente.

Se si verifica un errore, la mitigazione più affidabile consiste nel ripristinare la catena di certificati eliminando prima tutti i certificati creati nelle sezioni Ottenere la chiave pubblica del certificato da Istanza gestita di SQL e importarla in SQL Server e importarele chiavi dell'autorità di certificazione radice attendibile di Azure in SQL Server e quindi reimportarle di nuovo.

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.

Usare il commit sincrono con cautela

La modalità commit predefinita per il collegamento è asincrona. Anche se è possibile modificare la modalità commit in sincrona, non è consigliabile e non è necessario proteggersi da potenziali perdite di dati.

Durante un failover collegato pianificato, la replica viene temporaneamente impostata in modalità di commit sincrono fino al completamento del failover. Dopo il failover, la modalità commit torna all'asincrona, anche se è impostata in modo esplicito sulla modalità commit sincrono prima del failover.

L'uso della modalità commit sincrono per il collegamento può influire sulle prestazioni della replica primaria, soprattutto se è presente una latenza di rete elevata tra le repliche. In modalità commit sincrono, le transazioni nella replica primaria devono attendere la conferma della protezione avanzata dei record del log delle transazioni nella replica secondaria prima di poter eseguire il commit della transazione nel database primario. Questo tempo di attesa aumenta con una latenza di rete più elevata, con conseguente aumento dei tempi di risposta delle transazioni e riduzione della velocità effettiva nella replica primaria.

Contenuto correlato

Per usare il collegamento:

• Allestire l’ambiente per il collegamento a Istanza gestita
• Configurare il collegamento tra SQL Server e Istanza gestita di SQL con SSMS
• Configurare il collegamento tra SQL Server e istanza gestita di SQL con script
• Eseguire il failover con il collegamento
• Eseguire la migrazione con il collegamento
• Risolvere i problemi relativi al collegamento

Per altre informazioni sul collegamento:

• Panoramica del collegamento a Istanza gestita
• Ripristino di emergenza con il collegamento all'istanza gestita
• Procedure consigliate per la gestione del collegamento

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

• Replica transazionale con Istanza gestita di SQL
• Servizio di riproduzione log (LRS)