Monitorare le prestazioni dei gruppi di disponibilità Always On

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:

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:

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:

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.

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:

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

2. 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_readyrelativi valori , last_commit_timee 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 e last_received_lsnlast_redone_lsn. Il last_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 di last_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.

Creare una procedura memorizzata per stimare l'RTO

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

2. Eseguire proc_calculate_RTO con il nome del database secondario di destinazione:

   EXECUTE proc_calculate_RTO @secondary_database_name = N'DB_sec';
   

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

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

2. 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';
   

3. 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à:

1. Avviare il servizio SQL Server Agent se non è già stato avviato.

2. In SQL Server Management Studio, dal menu Strumenti , selezionare le Opzioni .

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

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

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

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

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

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

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

Eventi estesi utili

Gli eventi estesi seguenti sono utili quando vengono risolti i problemi delle repliche che hanno lo stato Sincronizzazione in corso.