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 punto qualsiasi del processo. Se si individua il punto del collo di bottiglia è possibile analizzare in modo 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:Database > Byte di log scaricati\sec |
| 2 | Catturare | I log di ogni database vengono acquisiti e inviati alla coda del partner corrispondente (uno per ogni coppia di replica/database). Il processo di acquisizione viene eseguito ininterrottamente, purché la replica di disponibilità sia connessa e lo spostamento dei dati non sia sospeso per qualsiasi motivo, e la coppia replica-database risulti essere Sincronizzazione in corso o Sincronizzato. Se il processo di acquisizione non è in grado di analizzare e accodare i messaggi abbastanza velocemente, si accumula la coda di invio dei log. |
SQL Server: Replica di Disponibilità > Byte inviati alla Replica/sec, il che rappresenta un'aggregazione della somma di tutti i messaggi di database accodati per quella replica di disponibilità. log_send_queue_size (KB) e log_bytes_send_rate (KB/sec) nella replica primaria. |
| 3 | Invia | I messaggi in ciascuna coda della replica di database vengono rimossi dalla coda e inviati su filo alla rispettiva replica secondaria. | SQL Server:Replica di disponibilità > Byte 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 | Finalizzazione | 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 controlli di flusso nella replica primaria che consentono di evitare un consumo eccessivo delle risorse, ad esempio delle risorse di rete e di memoria, in tutte le repliche di disponibilità. Questi controlli non condizionano lo stato di integrità della sincronizzazione delle repliche di disponibilità, ma possono influenzare le prestazioni complessive dei database di disponibilità, incluso l'obiettivo 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 alle portelle di controllo del flusso, esiste un altro fattore che può impedire l'invio di 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 che venga inviato un messaggio di log, il suo numero LSN viene controllato rispetto al numero LSN più basso riconosciuto per assicurarsi che sia inferiore a una delle soglie (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 aumenta i limiti del numero di messaggi consentiti da ogni gate. Usando il flag di traccia 12310, è disponibile anche il limite aumentato per le versioni seguenti di SQL Server, a partire da: SQL Server 2019 CU9, SQL Server 2017 CU18 e SQL Server 2016 SP1 CU16.
La tabella seguente confronta i limiti dei messaggi:
SQL Server 2022 e le versioni supportate di SQL Server (a partire da SQL Server 2019 CU9, SQL Server 2017 CU18 e SQL Server 2016 SP1 CU16) che abilitano il flag di traccia 12310 vedono i limiti seguenti:
| Livello | Numero di uscite | Numero di messaggi | Metrica utile |
|---|---|---|---|
| Trasporto | 1 per replica di disponibilità | 16384 | Evento avanzato 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 altre informazioni sui tipi di problemi che possono incrementare il tempo di attesa per il controllo di flusso, vedere Risoluzione dei problemi: Il gruppo di disponibilità ha superato la soglia RPO.
Stima del 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 più alto tempo di failover (Tfailover) diventa il valore di limitazione per la conformità dell'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 di errore sp_server_diagnostics (Transact-SQL) inviata al cluster WSFC. L'intervallo predefinito è 1/3 del timeout del controllo integrità. È possibile attivare un failover anche in seguito a un timeout, ad esempio il timeout del controllo integrità del cluster è scaduto (30 secondi per impostazione predefinita) o il lease tra la DLL risorse e l'istanza di SQL Server è scaduto (20 secondi per impostazione predefinita). In questo caso, il tempo di rilevamento è lungo quanto l'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.
Stima della possibile perdita dei dati (RPO)
L'obiettivo RPO nel contratto di servizio varia in base alla possibile perdita dei dati dell'implementazione Always On in un qualsiasi momento specificato. 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 scaricamento log.
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, sembrerebbe singolare usare la velocità di generazione del log anziché la velocità di invio log (vedere log_send_rate). Tuttavia, ricorda che utilizzare la velocità di invio dei log fornisce solo il tempo necessario per la sincronizzazione, mentre l'RPO misura la perdita di dati in base alla rapidità con cui vengono generati, non alla velocità di sincronizzazione.
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 specifica la possibile perdita dei dati in base alla velocità con cui il log viene generato. Deve essere inteso come valore approssimativo.
Stimare i valori RTO e RPO con il dashboard di SSMS
Nei gruppi di disponibilità Always On, i valori RTO e RPO vengono calcolati e visualizzati per i database ospitati nelle repliche secondarie. Nel dashboard della replica primaria i valori RTO e RPO sono raggruppati in base alla replica secondaria.
Per visualizzare i valori RTO e RPO all'interno del dashboard, eseguire le operazioni seguenti:
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 valore RTO prende in considerazione i valori di 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 del valore RPO del database secondario
Per un database secondario (DB_sec), il calcolo e la visualizzazione del valore RPO prende in considerazione i valori di is_failover_ready, last_commit_time e last_commit_time del database primario correlato (DB_pri). Quando secondary database.is_failover_ready = 1, i dati sono sincronizzati e in caso di failover non si verificherà alcuna perdita di dati. Tuttavia, se questo valore è 0, c'è una differenza tra il valore last_commit_time del database primario e il last_commit_time del database secondario.
Per il database primario, last_commit_time corrisponde all'ora in cui è stato eseguito il commit della transazione più recente. Per il database secondario, last_commit_time corrisponde all'ora in cui è stato eseguito il commit della transazione più recente nel database primario che è stata finalizzata correttamente anche nel database secondario. Questo numero deve essere lo stesso per il database primario e secondario. Qualsiasi differenza tra questi due valori corrisponde al lasso di tempo a cui appartengono le transazioni in sospeso non ancora finalizzate nel database secondario e che andranno perse in caso di failover.
Contatori delle prestazioni utilizzati nelle formule RTO/RPO
- redo_queue_size (KB) [usato nell'RTO]: la dimensione della coda di redo è la dimensione dei registri delle transazioni tra last_received_lsn e last_redone_lsn. last_received_lsn è l'ID del blocco di log che identifica il punto fino a cui tutti i blocchi di log sono stati ricevuti dalla replica secondaria che ospita questo database secondario. Last_redone_lsn è il numero di sequenza di log dell'ultimo record che è stato ripristinato nel database secondario. Sulla base di 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 quanti blocchi di log delle transazioni non siano ancora stati ripetuti. Il valore viene misurato in kilobyte (KB).
- redo_rate (KB/sec) [usato in RTO]: Un valore cumulativo che rappresenta, in un periodo di tempo trascorso, la quantità di log delle transazioni (KB) che è stata ripetuta nel database secondario in Kilobyte (KB)/secondo.
- last_commit_time (Datetime) [usato per l'RPO]: per il database primario, last_commit_time corrisponde all'ora in cui è stato eseguito il commit della transazione più recente. Per il database secondario, last_commit_time corrisponde all'ora in cui è stato eseguito il commit della transazione più recente nel database primario che è stata finalizzata correttamente 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 DMV
È possibile eseguire query sulle DMV sys.dm_hadr_database_replica_states e sys.dm_hadr_database_replica_cluster_states per stimare i valori RPO e RTO di un database. Le query seguenti creano stored procedure che svolgono entrambe le operazioni.
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 sysname
declare @is_primary_replica bit
declare @is_failover_ready bit
declare @redo_queue_size bigint
declare @redo_rate bigint
declare @replica_id uniqueidentifier
declare @group_database_id uniqueidentifier
declare @group_id uniqueidentifier
declare @RTO 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 dbr join sys.dm_hadr_database_replica_cluster_states 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 di database secondario di destinazione:
exec 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:
Il valore RTO di DB_sec del database è 0
Il valore group_id del database DB4 è F176DD65-C3EE-4240-BA23-EA615F965C9B
Il valore replica_id del database DB4 è 405554F6-3FDC-4593-A650-2067F5FABFFD
Il valore group_database_id del database DB4 è 39F7942F-7B5E-42C5-977D-02E7FFA6C392
Creare una stored procedure per stimare il valore RPO
- Nella replica primaria, creare la stored procedure proc_calculate_RPO. 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 sysname
declare @is_primary_replica bit
declare @is_failover_ready bit
declare @is_local bit
declare @last_commit_time_sec datetime
declare @last_commit_time_pri datetime
declare @RPO nvarchar(max)
-- secondary database's last_commit_time
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 dbr join sys.dm_hadr_database_replica_cluster_states 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
-- correlated primary database's last_commit_time
select
@last_commit_time_pri = dbr.last_commit_time,
@is_local = dbr.is_local
from sys.dm_hadr_database_replica_states dbr join sys.dm_hadr_database_replica_cluster_states 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
- Eseguire proc_calculate_RPO con i valori group_id, replica_id e group_database_id del database secondario di destinazione.
exec 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.
Monitoraggio di 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 per il calcolo del tempo di failover e della possibile perdita dei dati in Stima del tempo di failover (RTO) e in Stima della potenziale perdita dei dati (RPO) vengono specificati come metrica delle prestazione nel facet della gestione basata su criteri Stato replica di database (vedere View the policy-based management facets on a SQL Server object) (Visualizzare i facet della gestione basata su criteri in un oggetto di 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 le istruzioni riportate di seguito in tutte le istanze del server che fanno parte del gruppo di disponibilità:
Avviare il servizio SQL Server Agent se non è già stato avviato.
Selezionare Opzioni dal menu Strumenti di SQL Server Management Studio.
Nella scheda SQL Server Always On selezionare Abilita criteri Always On definiti dall'utente e fare clic su 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:
RTOFacet: 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 l'overhead di 60 secondi per il rilevamento degli errori e il failover.
Creare una seconda condizione della gestione basata su criteri usando le specifiche seguenti:
Nome:
RPOFacet: Stato della replica del database
Campo:
@EstimatedDataLossOperatore: <=
Valore:
3600
Questa condizione ha esito negativo quando la possibile perdita dei dati supera 1 ora.
Creare una terza condizione della gestione basata su criteri usando le specifiche seguenti:
Nome:
IsPrimaryReplicaFacet: Gruppo di disponibilità
Campo:
@LocalReplicaRoleOperatore: =
Valore:
Primary
Questa condizione controlla se la replica di disponibilità locale per un determinato gruppo di disponibilità è la replica primaria.
Creare una gestione basata su criteri usando le seguenti specifiche:
PaginaGenerale:
Nome:
CustomSecondaryDatabaseRTOCondizioni di controllo:
RTOContro 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: CollectorSchedule_Every_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:
CustomAvailabilityDatabaseRPOCondizioni di controllo:
RPOIn base alle destinazioni: Ogni DatabaseReplicaState in IsPrimaryReplica AvailabilityGroup
Modalità di valutazione: In programma
Pianificazione: PianificazioneCollettore_Ogni_30min
Abilitata: selezionato
Pagina Descrizione:
Categoria: avvisi del database di disponibilità
Descrizione: il database di disponibilità ha superato il valore RPO di 1 ora. È consigliabile analizzare immediatamente i problemi di prestazioni nelle repliche di disponibilità.
Testo da visualizzare: RPO superato!
Al termine, vengono creati due nuovi processi di SQL Server Agent, uno per ciascuna pianificazione di valutazione delle policy. I nomi di questi processi devono iniziare 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 Configure alerts to notify policy administrators of policy failures (Configurare avvisi per notificare agli amministratori eventuali 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 è maggiore dell'obiettivo RPO. In alternativa, quando si calcola la potenziale perdita di dati di una replica secondaria con commit asincrono, si scopre che supera l'obiettivo RPO. |
| Risoluzione dei problemi: Le modifiche nella replica primaria non vengono riflesse nella replica secondaria | L'applicazione client completa con esito positivo un aggiornamento per la replica primaria, ma l'esecuzione di query sulla replica secondaria rivela che qui la modifica non è stata eseguita. |
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 di disponibilità |
|---|---|---|---|
| rifare_aggiornato | transazioni | Debug | Secondario |
| riedo_inserimento_lavoratore | transazioni | Risoluzione errori | Secondario |
| hadr_transport_dump_message | alwayson |
Debug | Primario |
| hadr_worker_pool_task | alwayson |
Debug | Primaria |
| hadr_dump_primary_progress | alwayson |
Eseguire il debug | Primario |
| hadr_dump_log_progress | alwayson |
Debug | Primario |
| hadr_undo_of_redo_log_scan | alwayson |
Analitiche | Secondario |