Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Si applica a:SQL Server
Le prestazioni di Gruppi di disponibilità Always On sono un aspetto importante per garantire il contratto di servizio per i database cruciali. Comprendere come i gruppi di disponibilità trasferiscono i log alle repliche secondarie può aiutarti a stimare gli obiettivi di tempo di ripristino (RTO, recovery time objective) e di punto di ripristino (RPO, recovery point objective) della tua implementazione di disponibilità e a identificare e risolvere i colli di bottiglia nei gruppi o nelle repliche di disponibilità con prestazioni scarse. In questo articolo viene descritto il processo di sincronizzazione, viene illustrato come calcolare alcune delle metriche chiave e vengono specificati i collegamenti ad alcuni scenari comuni per la risoluzione dei problemi relativi alle prestazioni.
Processo di sincronizzazione dei dati
Per stimare il tempo di sincronizzazione completa e identificare il collo di bottiglia, è necessario conoscere il processo di sincronizzazione. Un collo di bottiglia delle prestazioni può verificarsi in qualsiasi punto del processo. Individuare il collo di bottiglia può aiutarti ad analizzare in modo più approfondito i problemi sottostanti. La figura e la tabella seguenti illustrano il processo di sincronizzazione dei dati:
Sequenza | Descrizione fase | Commenti | Metrica utile |
---|---|---|---|
1 | Generazione del registro | I dati del log vengono scaricati su disco. Il log deve essere replicato alle repliche secondarie. I record del log entrano nella coda di invio. | SQL Server:Byte del log del database > scaricati/sec |
2 | Catturare | I log per ogni database vengono acquisiti e inviati alla coda partner corrispondente (una per ogni coppia di repliche di database). Questo processo di acquisizione viene eseguito in modo continuo, purché la replica di disponibilità sia connessa e lo spostamento dei dati non venga sospeso per qualsiasi motivo e la coppia di repliche di database venga visualizzata come sincronizzazione o sincronizzazione. Se il processo di acquisizione non è in grado di analizzare e accodare i messaggi in modo sufficientemente rapido, la coda di invio dei log viene compilata. |
SQL Server:Availability Replica > Byte inviati alla replica/sec, ovvero un'aggregazione della somma di tutti i messaggi di database accodati per la replica di disponibilità. log_send_queue_size (KB) e log_bytes_send_rate (KB/sec) nella replica primaria. |
3 | Invia | I messaggi in ogni coda di replica di database vengono dequeuati e inviati attraverso la rete alla rispettiva replica secondaria. | SQL Server:Byte di replica > di disponibilità inviati al trasporto/sec |
4 | Ricezione e memorizzazione nella cache | Ogni replica secondaria riceve il messaggio e lo memorizza nella cache. | Contatore delle prestazioni SQL Server:Replica di disponibilità > Byte log ricevuti/sec |
5 | Rafforzare | Il log viene svuotato nella replica secondaria per il consolidamento. Dopo aver scaricato il log, alla replica primaria viene inviata una conferma. Una volta che il log viene consolidato, si evita la perdita di dati. |
Contatore delle prestazioni SQL Server:Database > Byte di log scaricati/sec Tipo di attesa HADR_LOGCAPTURE_SYNC |
6 | Ripeti | Rifare le pagine scolrate nella replica secondaria. Le pagine vengono mantenute nella coda di reinserimento in attesa di essere reinserite. |
SQL Server:Replica di database > Byte ripristinati/sec redo_queue_size (KB) e redo_rate. Tipo di attesa REDO_SYNC |
Paratoie di controllo del flusso
I gruppi di disponibilità sono progettati con meccanismi di controllo del flusso sulla replica primaria per evitare un consumo eccessivo delle risorse, come quelle di rete e di memoria, su tutte le repliche di disponibilità. Questi gate di controllo del flusso non influiscono sullo stato di integrità della sincronizzazione delle repliche di disponibilità, ma possono influire sulle prestazioni complessive dei database di disponibilità, incluso il RPO.
Dopo che i log sono stati acquisiti nella replica primaria, vengono sottoposti a due livelli di controllo di flusso. Dopo che la soglia di messaggi di uno dei gate è stata raggiunta, i messaggi di log non vengono più inviati a una replica specifica o per un database specifico. È possibile inviare i messaggi quando vengono ricevuti i messaggi di acknowledgement per i messaggi inviati in modo che il numero di messaggi inviati sia al di sotto della soglia.
Oltre ai controlli di controllo del flusso, esiste un altro fattore che può impedire l'invio dei messaggi di log. La sincronizzazione di repliche assicura che i messaggi siano inviati e applicati nell'ordine dei numeri di sequenza del file di log (LSN). Prima dell'invio di un messaggio di log, l'LSN del messaggio viene confrontato con il numero LSN riconosciuto più basso per assicurarsi che sia inferiore a una delle soglie stabilite (a seconda del tipo di messaggio). Se il divario tra i due numeri LSN è maggiore della soglia, i messaggi non vengono inviati. Una volta che il divario è di nuovo al di sotto della soglia, i messaggi vengono inviati.
SQL Server 2022 (16.x) aumenta i limiti al numero di messaggi consentiti da ogni gate. Usando il flag di traccia 12310, è disponibile anche l'aumento del limite per le versioni seguenti di SQL Server: SQL Server 2019 (15.x) CU9, SQL Server 2017 (14.x) CU18, SQL Server 2016 (13.x) SP1 CU16.
La tabella seguente confronta i limiti dei messaggi:
Per le versioni di SQL Server che abilitano il flag di traccia 12310, ovvero SQL Server 2022 (16.x), SQL Server 2019 (15.x) CU9, SQL Server 2017 (14.x) CU18, SQL Server 2016 (13.x) SP1 CU16 e versioni successive, vedere i limiti seguenti:
Livello | Numero di uscite | Numero di messaggi | Metrica utile |
---|---|---|---|
Trasporto | 1 per replica di alta disponibilità | 16384 | Evento esteso database_transport_flow_control_action |
Banca dati | 1 per database di disponibilità | 7168 |
DBMIRROR_SEND Evento esteso hadron_database_flow_control_action |
Due utili contatori delle prestazioni, SQL Server:Replica di disponibilità > Controllo di flusso/sec e SQL Server:Replica di disponibilità > Ora controllo di flusso (ms/sec), indicano, all'ultimo secondo, il numero di volte in cui il controllo di flusso è stato attivato e il tempo di attesa per il controllo di flusso. Maggiore è il tempo di attesa per il controllo di flusso, più alto sarà l'RPO. Per ulteriori informazioni sui tipi di problemi che possono causare un lungo tempo di attesa nel controllo del flusso, vedere Risoluzione dei problemi: Potenziale perdita di dati con repliche del gruppo di disponibilità con commit asincrono.
Stimare il tempo di failover (RTO)
Il Recovery Time Objective (RTO) nel tuo SLA dipende dal tempo di failover dell'implementazione Always On in qualsiasi momento. Può essere espresso con la formula seguente:
Importante
Se un gruppo di disponibilità contiene più di un database di disponibilità, il database di disponibilità con il Tfailover più alto diventa il valore limitante per la conformità all'obiettivo RTO.
Il tempo di rilevamento di errori (Tdetection) è il tempo necessario al sistema per rilevare l'errore. Questo tempo dipende dalle impostazioni a livello di cluster e non dalle singole repliche di disponibilità. A seconda della condizione di failover automatico configurata, il failover può essere attivato come risposta immediata a un errore interno critico di SQL Server, ad esempio spinlock orfani. In questo caso, il rilevamento può essere veloce quanto la segnalazione errori di sp_server_diagnostics viene inviata al Windows Server Failover Cluster (WSFC). L'intervallo predefinito è 1/3 del timeout del controllo integrità. È anche possibile attivare un failover a causa di un timeout, ad esempio il timeout del controllo integrità del cluster scaduto (30 secondi per impostazione predefinita) o il lease tra la DLL della risorsa e l'istanza di SQL Server è scaduto (20 secondi per impostazione predefinita). In questo caso, il tempo di rilevamento è uguale all'intervallo di timeout. Per altre informazioni, vedere Criteri di failover flessibili per failover automatico di un gruppo di disponibilità (SQL Server).
L'unica cosa che la replica secondaria deve fare per essere pronta per un failover è sincronizzarsi fino alla fine del log tramite il redo. Il tempo di ripetizione (Tredo) viene calcolato usando la formula seguente:
dove redo_queue è il valore in redo_queue_size e redo_rate è il valore in redo_rate.
Il tempo di overhead del failover, Toverhead, include il tempo necessario per eseguire il failover del cluster WSFC e rendere operativi i database. Si tratta solitamente di un tempo breve e costante.
Stimare la potenziale perdita di dati (RPO)
L'obiettivo RPO nel contratto di servizio dipende dalla possibile perdita di dati della tua implementazione Always On in ogni momento determinato. La perdita dei dati può essere espressa con la formula seguente:
dove log_send_queue è il valore di log_send_queue_size e velocità di generazione dei log è il valore di SQL Server:Database > Byte/sec log scaricati.
Avviso
Se un gruppo di disponibilità contiene più di un database di disponibilità, il database di disponibilità con la più alta perdita dei dati (Tdata_loss) diventa il valore di limitazione per la conformità dell'obiettivo RPO.
La coda di invii del log rappresenta tutti i dati persi in seguito a un errore irreversibile. A prima vista, è curioso che venga usata la frequenza di generazione del log anziché la frequenza di invio del log (vedere log_send_rate). Tenere tuttavia presente che l'uso della frequenza di invio del log offre solo il tempo necessario per la sincronizzazione, mentre RPO misura la perdita di dati in base alla velocità di generazione, non alla velocità con cui viene sincronizzata.
Usare last_commit_time per stimare in modo semplice il valore Tdata_loss. La DMV nella replica primaria segnala questo valore per tutte le repliche. È possibile calcolare la differenza tra il valore della replica primaria e il valore della replica secondaria per stimare la velocità con cui il log della replica secondaria aggiorna la replica primaria. Come indicato in precedenza, questo calcolo non indica la potenziale perdita di dati in base alla velocità con cui viene generato il log, ma deve essere un'approssimazione stretta.
Stimare RTO e RPO con il dashboard di SSMS
Nei gruppi di disponibilità AlwaysOn, gli RTO e RPO vengono calcolati e visualizzati per i database ospitati nelle repliche secondarie. Nel dashboard SSMS (SQL Server Management Stuiod) nella replica primaria il RTO e RPO vengono raggruppati in base alla replica secondaria.
Per visualizzare gli obiettivi RTO e RPO all'interno del dashboard, seguire i seguenti passaggi:
In SQL Server Management Studio espandere il nodo Disponibilità elevata Always On, fare clic con il pulsante destro del mouse sul nome del gruppo di disponibilità e scegliere Mostra dashboard.
Selezionare Aggiungi/Rimuovi colonne nella scheda Raggruppa per. Controllare il Tempo di recupero stimato (secondi) [RTO] e la Perdita di dati stimata (tempo) [RPO].
Calcolo dell'RTO del database secondario
Il calcolo del tempo di recupero determina il tempo necessario per recuperare il database secondario dopo che si verifica un failover. Il tempo di failover è solitamente breve e costante. Il tempo per il rilevamento dipende dalle impostazioni a livello di cluster e non dalle singole repliche di disponibilità.
Per un database secondario (DB_sec
), il calcolo e la visualizzazione del relativo RTO si basa su redo_queue_size
e redo_rate
:
Tranne nei casi limite, la formula per il calcolo del valore RTO di un database secondario è la seguente:
Calcolo dell'RPO del database secondario
Per un database secondario (DB_sec
), il calcolo e la visualizzazione del relativo RPO si basa sui is_failover_ready
relativi valori , last_commit_time
e sul relativo database primario correlato (DB_pri
).last_commit_time
Quando il valore di DB_sec.is_failover_ready
è 1
, i dati tra i database primari e secondari vengono sincronizzati e non si verifica alcuna perdita di dati al failover. Tuttavia, se questo valore è 0
, esiste un divario tra nel last_commit_time
database primario e nel last_commit_time
database secondario.
Per il database primario, è last_commit_time
l'ora in cui è stato eseguito il commit della transazione più recente. Per il database secondario, last_commit_time
è l'ora di commit più recente per la transazione dal database primario con protezione avanzata anche nel database secondario. Questo numero è lo stesso per il database primario e secondario. Tuttavia, un divario tra questi due valori è la durata in cui le transazioni in sospeso non sono state rafforzate nel database secondario e potrebbero essere perse in caso di failover.
Metriche delle prestazioni usate nelle formule RTO/RPO
redo_queue_size
(KB): le dimensioni della coda di rollforward, usate in RTO, sono le dimensioni dei log delle transazioni tra elast_received_lsn
last_redone_lsn
. Illast_received_lsn
valore è l'ID blocco di log che identifica il punto a cui sono stati ricevuti tutti i blocchi di log dalla replica secondaria che ospita questo database secondario. Il valore di è il numero dilast_redone_lsn
sequenza di log dell'ultimo record di log di cui è stato eseguito il rollforward nel database secondario. In base a questi due valori, è possibile trovare gli ID del blocco di log iniziale (last_received_lsn
) e del blocco di log finale (last_redone_lsn
). Lo spazio tra questi due blocchi di log può quindi rappresentare il numero di blocchi del log delle transazioni non ancora ridisatti. Il valore viene misurato in kilobyte (KB).redo_rate
(KB/sec): usato nel calcolo RTO, si tratta di un valore cumulativo che mostra la quantità di log delle transazioni (KB) di cui è stato eseguito il rollforward o la riproduzione nel database secondario al secondo.last_commit_time
(datetime): usato in RPO, questo valore ha un significato diverso tra il database primario e quello secondario. Per il database primario,last_commit_time
è l'ora in cui è stato eseguito il commit della transazione più recente. Per il database secondario,last_commit_time
è il commit più recente per la transazione nel database primario con protezione avanzata anche nel database secondario. Poiché questo valore del database secondario deve essere sincronizzato con lo stesso valore del database primario, eventuali differenze tra questi due valori rappresentano la stima della perdita dei dati (RPO).
Stimare i valori RTO e RPO mediante le Visualizzazioni di Gestione Dinamica (DMV)
È possibile eseguire una query sui DMV sys.dm_hadr_database_replica_states e sys.dm_hadr_database_replica_cluster_states per stimare l'RPO e l'RTO di un database. Le seguenti query creano stored procedure che svolgono entrambi gli obiettivi.
Nota
Assicurarsi di creare ed eseguire la stored procedure per stimare prima il valore RTO, in quanto i valori generati sono necessari per eseguire la stored procedure per stimare il valore RPO.
Creare una procedura memorizzata per stimare l'RTO
Nella replica secondaria di destinazione creare la stored procedure
proc_calculate_RTO
. Se questa stored procedure esiste già, eliminala prima, quindi ricreala.IF object_id(N'proc_calculate_RTO', 'p') IS NOT NULL DROP PROCEDURE proc_calculate_RTO; GO RAISERROR ('creating procedure proc_calculate_RTO', 0, 1) WITH NOWAIT; GO -- name: proc_calculate_RTO -- -- description: Calculate RTO of a secondary database. -- -- parameters: @secondary_database_name nvarchar(max): name of the secondary database. -- -- security: this is a public interface object. -- CREATE PROCEDURE proc_calculate_RTO @secondary_database_name NVARCHAR (MAX) AS BEGIN DECLARE @db AS sysname; DECLARE @is_primary_replica AS BIT; DECLARE @is_failover_ready AS BIT; DECLARE @redo_queue_size AS BIGINT; DECLARE @redo_rate AS BIGINT; DECLARE @replica_id AS UNIQUEIDENTIFIER; DECLARE @group_database_id AS UNIQUEIDENTIFIER; DECLARE @group_id AS UNIQUEIDENTIFIER; DECLARE @RTO AS FLOAT; SELECT @is_primary_replica = dbr.is_primary_replica, @is_failover_ready = dbcs.is_failover_ready, @redo_queue_size = dbr.redo_queue_size, @redo_rate = dbr.redo_rate, @replica_id = dbr.replica_id, @group_database_id = dbr.group_database_id, @group_id = dbr.group_id FROM sys.dm_hadr_database_replica_states AS dbr INNER JOIN sys.dm_hadr_database_replica_cluster_states AS dbcs ON dbr.replica_id = dbcs.replica_id AND dbr.group_database_id = dbcs.group_database_id WHERE dbcs.database_name = @secondary_database_name; IF @is_primary_replica IS NULL OR @is_failover_ready IS NULL OR @redo_queue_size IS NULL OR @replica_id IS NULL OR @group_database_id IS NULL OR @group_id IS NULL BEGIN PRINT 'RTO of Database ' + @secondary_database_name + ' is not available'; RETURN; END ELSE IF @is_primary_replica = 1 BEGIN PRINT 'You are visiting wrong replica'; RETURN; END IF @redo_queue_size = 0 SET @RTO = 0; ELSE IF @redo_rate IS NULL OR @redo_rate = 0 BEGIN PRINT 'RTO of Database ' + @secondary_database_name + ' is not available'; RETURN; END ELSE SET @RTO = CAST (@redo_queue_size AS FLOAT) / @redo_rate; PRINT 'RTO of Database ' + @secondary_database_name + ' is ' + CONVERT (VARCHAR, ceiling(@RTO)); PRINT 'group_id of Database ' + @secondary_database_name + ' is ' + CONVERT (NVARCHAR (50), @group_id); PRINT 'replica_id of Database ' + @secondary_database_name + ' is ' + CONVERT (NVARCHAR (50), @replica_id); PRINT 'group_database_id of Database ' + @secondary_database_name + ' is ' + CONVERT (NVARCHAR (50), @group_database_id); END
Eseguire
proc_calculate_RTO
con il nome del database secondario di destinazione:EXECUTE proc_calculate_RTO @secondary_database_name = N'DB_sec';
L'output visualizza il valore RTO del database di replica secondaria di destinazione. Salvare i valori group_id, replica_id e group_database_id da usare con la stored procedure per la stima del valore RPO.
Output di esempio:
RTO of Database DB_sec' is 0 group_id of Database DB4 is F176DD65-C3EE-4240-BA23-EA615F965C9B replica_id of Database DB4 is 405554F6-3FDC-4593-A650-2067F5FABFFD group_database_id of Database DB4 is 39F7942F-7B5E-42C5-977D-02E7FFA6C392
Creare una stored procedure per stimare il valore RPO
Creare la stored procedure
proc_calculate_RPO
nella replica primaria. Se esiste già, eliminarla e quindi ricrearla.IF object_id(N'proc_calculate_RPO', 'p') IS NOT NULL DROP PROCEDURE proc_calculate_RPO; GO RAISERROR ('creating procedure proc_calculate_RPO', 0, 1) WITH NOWAIT; GO -- name: proc_calculate_RPO -- -- description: Calculate RPO of a secondary database. -- -- parameters: @group_id uniqueidentifier: group_id of the secondary database. -- @replica_id uniqueidentifier: replica_id of the secondary database. -- @group_database_id uniqueidentifier: group_database_id of the secondary database. -- -- security: this is a public interface object. -- CREATE PROCEDURE proc_calculate_RPO @group_id UNIQUEIDENTIFIER, @replica_id UNIQUEIDENTIFIER, @group_database_id UNIQUEIDENTIFIER AS BEGIN DECLARE @db_name AS sysname; DECLARE @is_primary_replica AS BIT; DECLARE @is_failover_ready AS BIT; DECLARE @is_local AS BIT; DECLARE @last_commit_time_sec AS DATETIME; DECLARE @last_commit_time_pri AS DATETIME; DECLARE @RPO AS NVARCHAR (MAX); SELECT @db_name = dbcs.database_name, @is_failover_ready = dbcs.is_failover_ready, @last_commit_time_sec = dbr.last_commit_time FROM sys.dm_hadr_database_replica_states AS dbr INNER JOIN sys.dm_hadr_database_replica_cluster_states AS dbcs ON dbr.replica_id = dbcs.replica_id AND dbr.group_database_id = dbcs.group_database_id WHERE dbr.group_id = @group_id AND dbr.replica_id = @replica_id AND dbr.group_database_id = @group_database_id; SELECT @last_commit_time_pri = dbr.last_commit_time, @is_local = dbr.is_local FROM sys.dm_hadr_database_replica_states AS dbr INNER JOIN sys.dm_hadr_database_replica_cluster_states AS dbcs ON dbr.replica_id = dbcs.replica_id AND dbr.group_database_id = dbcs.group_database_id WHERE dbr.group_id = @group_id AND dbr.is_primary_replica = 1 AND dbr.group_database_id = @group_database_id; IF @is_local IS NULL OR @is_failover_ready IS NULL BEGIN PRINT 'RPO of database ' + @db_name + ' is not available'; RETURN; END IF @is_local = 0 BEGIN PRINT 'You are visiting wrong replica'; RETURN; END IF @is_failover_ready = 1 SET @RPO = '00:00:00'; ELSE IF @last_commit_time_sec IS NULL OR @last_commit_time_pri IS NULL BEGIN PRINT 'RPO of database ' + @db_name + ' is not available'; RETURN; END ELSE BEGIN IF DATEDIFF(ss, @last_commit_time_sec, @last_commit_time_pri) < 0 BEGIN PRINT 'RPO of database ' + @db_name + ' is not available'; RETURN; END ELSE SET @RPO = CONVERT (VARCHAR, DATEADD(ms, datediff(ss, @last_commit_time_sec, @last_commit_time_pri) * 1000, 0), 114); END PRINT 'RPO of database ' + @db_name + ' is ' + @RPO; END -- secondary database's last_commit_time -- correlated primary database's last_commit_time
Eseguire
proc_calculate_RPO
con il group_id, l'replica_id e l'group_database_id del database secondario di destinazione.EXECUTE proc_calculate_RPO @group_id = 'F176DD65-C3EE-4240-BA23-EA615F965C9B', @replica_id = '405554F6-3FDC-4593-A650-2067F5FABFFD', @group_database_id = '39F7942F-7B5E-42C5-977D-02E7FFA6C392';
L'output visualizza il valore RPO del database di replica secondaria di destinazione.
Monitorare per RTO e RPO
In questa sezione viene illustrato come monitorare i gruppi di disponibilità per le metriche degli obiettivi RTO e RPO. Questa dimostrazione è simile all'esercitazione per la GUI descritta in The Always On health model, part 2: Extending the health model (Modello di integrità Always On, parte 2: Estensione del modello di integrità).
Gli elementi del tempo di failover e dei potenziali calcoli della perdita di dati in Stima del tempo di failover (RTO) e la stima della potenziale perdita di dati (RPO) vengono forniti comodamente come metriche delle prestazioni nel facet di gestione dei criteri Stato replica di database. Per altre informazioni, vedere Visualizzare i facet di gestione basata su criteri in un oggetto SQL Server. È possibile monitorare queste due metriche in una pianificazione e ricevere un avviso quando la metrica supera rispettivamente gli obiettivi RTO e RPO.
Gli script della dimostrazione creano due criteri di sistema che vengono eseguiti nelle rispettive pianificazioni, con le caratteristiche seguenti:
Un criterio RTO che ha esito negativo quando il tempo di failover stimato supera i 10 minuti, valutato ogni 5 minuti
Criterio RPO che fallisce quando la perdita di dati stimata supera 1 ora, valutato ogni 30 minuti
La configurazione dei due criteri è identica in tutte le repliche di disponibilità
Le politiche vengono valutate su tutti i server, ma solo sui gruppi di disponibilità per i quali la replica di disponibilità locale è la replica primaria. Se la replica di disponibilità locale non è la replica primaria, i criteri non vengono valutati.
I fallimenti delle politiche sono comodamente visualizzati sul dashboard Always On quando li visualizzi sulla replica primaria.
Per creare i criteri, seguire queste istruzioni in tutte le istanze del server che partecipano al gruppo di disponibilità:
Avviare il servizio SQL Server Agent se non è già stato avviato.
In SQL Server Management Studio, dal menu Strumenti , selezionare le Opzioni .
Nella scheda SQL Server Always On selezionare Abilita i criteri Always On definiti dall'utente e selezionare OK.
Questa impostazione consente di visualizzare i criteri personalizzati configurati correttamente nel dashboard Always On.
Creare una condizione della gestione basata su criteri usando le specifiche seguenti:
-
Nome:
RTO
- Facet: Stato della replica del database
-
Campo:
Add(@EstimatedRecoveryTime, 60)
- Operatore: <=
-
Valore:
600
Questa condizione ha esito negativo quando il tempo di failover potenziale supera i 10 minuti, incluso un sovraccarico di 60 secondi per il rilevamento degli errori e il failover.
-
Nome:
Creare una seconda condizione della gestione basata su criteri usando le specifiche seguenti:
-
Nome:
RPO
- Facet: Stato della replica del database
-
Campo:
@EstimatedDataLoss
- Operatore: <=
-
Valore:
3600
Questa condizione ha esito negativo quando la possibile perdita dei dati supera 1 ora.
-
Nome:
Creare una terza condizione della gestione basata su criteri usando le specifiche seguenti:
-
Nome:
IsPrimaryReplica
- Facet: Gruppo di disponibilità
-
Campo:
@LocalReplicaRole
- Operatore: =
-
Valore:
Primary
Questa condizione controlla se la replica di disponibilità locale per un determinato gruppo di disponibilità è la replica primaria.
-
Nome:
Creare una gestione basata su criteri usando le seguenti specifiche:
PaginaGenerale:
Nome:
CustomSecondaryDatabaseRTO
Condizioni di controllo:
RTO
Contro gli obiettivi: Ogni DatabaseReplicaState in IsPrimaryReplica Gruppo di Disponibilità
Questa impostazione controlla che i criteri vengano valutati solo nei gruppi di disponibilità per cui la replica di disponibilità locale è la replica primaria.
Modalità di valutazione: In programma
Pianificazione: PianificazioneCollettore_Ogni_5min
Abilitata: selezionato
Pagina Descrizione:
Categoria: avvisi del database di disponibilità
Questa impostazione consente di visualizzare i risultati della valutazione dei criteri nel dashboard Always On.
Descrizione: La replica corrente ha un RTO che supera i 10 minuti, presupponendo un overhead di 1 minuto per l'individuazione e il failover. È necessario analizzare immediatamente i problemi di prestazioni dell'istanza sul server rispettivo.
Testo da visualizzare: RTO superato!
Creare un secondo criterio di gestione basato su policy usando le specifiche seguenti:
PaginaGenerale:
-
Nome:
CustomAvailabilityDatabaseRPO
-
Condizioni di controllo:
RPO
- Contro gli obiettivi: Ogni DatabaseReplicaState in IsPrimaryReplica Gruppo di Disponibilità
- Modalità di valutazione: In programma
- Pianificazione: PianificazioneCollettore_Ogni_30min
- Abilitata: selezionato
-
Nome:
Pagina Descrizione:
Categoria: avvisi del database di disponibilità
Descrizione: Il database di disponibilità ha superato il tuo obiettivo di punto di ripristino (RPO) impostato di 1 ora. Dovresti investigare immediatamente i problemi di performance nelle repliche di disponibilità.
Testo da visualizzare: RPO superato!
Una volta completato, vengono creati due nuovi processi di SQL Server Agent, uno per ciascuna pianificazione della valutazione dei criteri. Questi processi devono avere nomi che iniziano con syspolicy_check_schedule
.
È possibile visualizzare la cronologia del processo per ispezionare i risultati della valutazione. Anche gli errori di valutazione vengono registrati nel registro applicazioni di Windows (nel Visualizzatore eventi) con l'ID evento 34052. È anche possibile configurare SQL Server Agent per l'invio di avvisi in caso di errori dei criteri. Per altre informazioni, vedere Configurare gli avvisi per notificare agli amministratori dei criteri gli errori dei criteri.
Scenari di risoluzione dei problemi relativi alle prestazioni
Nella tabella seguente sono elencati gli scenari comuni di risoluzione dei problemi relativi alle prestazioni.
Scenario | Descrizione |
---|---|
Risoluzione dei problemi: Il gruppo di disponibilità ha superato la soglia RTO | Dopo un failover automatico o un failover manuale pianificato senza perdita di dati, il tempo di failover supera l'RTO previsto. Oppure, quando si stima il tempo di failover di una replica secondaria con commit asincrono (ad esempio un partner di failover automatico), si scopre che supera l'obiettivo RTO. |
Risoluzione dei problemi: Il gruppo di disponibilità ha superato la soglia RPO | Dopo aver eseguito un failover manuale forzato, la perdita di dati supera l'obiettivo definito dal tuo RPO. In alternativa, quando si calcola la potenziale perdita di dati di una replica secondaria con commit asincrono, si constata che supera il tuo Recovery Point Objective (RPO). |
Risoluzione dei problemi: Le modifiche nella replica primaria non vengono riflesse nella replica secondaria | L'applicazione client completa correttamente un aggiornamento nella replica primaria, ma l'esecuzione di query sulla replica secondaria indica che la modifica non viene riflessa. |
Eventi estesi utili
Gli eventi estesi seguenti sono utili quando vengono risolti i problemi delle repliche che hanno lo stato Sincronizzazione in corso.
Nome evento | Categoria | Canale | replica della disponibilità |
---|---|---|---|
redo_caught_up |
transazioni | Debug | Secondario |
redo_worker_entry |
transazioni | Correzione errori | Secondario |
hadr_transport_dump_message |
alwayson |
Eliminazione degli errori | Primario |
hadr_worker_pool_task |
alwayson |
Debug | Primario |
hadr_dump_primary_progress |
alwayson |
Debug | Primario |
hadr_dump_log_progress |
alwayson |
Esegui debug | Primario |
hadr_undo_of_redo_log_scan |
alwayson |
Analitiche | Secondario |