Risoluzione dei problemi: Il gruppo di disponibilità ha superato la soglia RTO

Si applica a:SQL Server

Dopo un failover automatico o un failover manuale pianificato senza perdita di dati in un gruppo di disponibilità, è possibile che il tempo di failover superi l'obiettivo del tempo di ripristino (RTO, Recovery Time Objective). Oppure, quando si stima il tempo di failover di una replica secondaria con commit sincrono (ad esempio un partner per il failover automatico) utilizzando il metodo descritto in Monitorare le prestazioni per i gruppi di disponibilità Always On, si riscontra che supera l'RTO.

Se il failover automatico non è ancora completato, vedere Risoluzione dei problemi di failover automatico in ambienti SQL Server 2012 AlwaysOn.

Le sezioni seguenti descrivono le cause comuni di un tempo di failover che supera l'RTO.

  1. Il carico di lavoro di reportistica blocca l'esecuzione del thread di redo

  2. Il thread redo subisce rallentamenti a causa della contesa delle risorse

Un carico di lavoro di creazione di report blocca l'esecuzione del thread di rollforward

L'esecuzione di modifiche DDL (Data Definition Language) del thread di rollforward nella replica secondaria viene bloccata da una query di sola lettura con esecuzione prolungata.

Spiegazione

Nella replica secondaria, le query di sola lettura acquisiscono blocchi di stabilità dello schema (Sch-S). Questi blocchi Sch-S sono in grado di impedire al thread di rollforward di acquisire blocchi di modifica dello schema (Sch-M) e di apportare eventuali modifiche DDL. Un thread di redo bloccato non può applicare i record del log finché non viene sbloccato. Dopo lo sblocco, può continuare ad aggiornarsi rispetto alla fine del log e consentire l'esecuzione del processo di rollback e di failover successivo.

Diagnosi e risoluzione

Quando il thread di rollforward è bloccato, viene generato un evento esteso denominato sqlserver.lock_redo_blocked. Inoltre, è possibile interrogare la DMV sys.dm_exec_request sulla replica secondaria per individuare quale sessione blocca il thread REDO e quindi intraprendere l'azione correttiva necessaria. La query seguente restituisce l'ID di sessione della query di sola lettura che sta bloccando il thread di redo.

select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource   
from sys.dm_exec_requests where command = 'DB STARTUP'

È possibile lasciar finire il carico di lavoro di creazione di report, e a questo punto il thread di rollforward viene sbloccato, oppure è possibile sbloccare il thread di rollforward immediatamente eseguendo il comando KILL (Transact-SQL) sull'ID di sessione che causa il blocco.

Il thread di redo rimane indietro a causa della contesa delle risorse

Un elevato carico di reportistica sulla replica secondaria ha rallentato le prestazioni di quest’ultima e il thread di redo ha accumulato ritardo.

Spiegazione

Quando si applicano record di log alla replica secondaria, il thread di rollforward legge tali record dal disco dei log e quindi per ogni record di log accede alle pagine di dati corrispondenti per applicarlo. Se una pagina non è ancora nel pool di buffer, l'accesso a questa può avvenire tramite binding I/O (accesso al disco fisico). Se è presente un carico di lavoro di generazione di report limitato dall'I/O, tale carico di lavoro compete per le risorse I/O con il thread di redo e può rallentarlo.

Diagnosi e risoluzione

È possibile usare la query DMV seguente per vedere di quanto il thread di redo sia rimasto indietro, misurando la differenza del divario tra last_redone_lsn e last_received_lsn.

select recovery_lsn, truncation_lsn, last_hardened_lsn, last_received_lsn,   
   last_redone_lsn, last_redone_time  
from sys.dm_hadr_database_replica_states

Se il thread di redo è effettivamente in ritardo, è necessario indagare sulla causa principale del degrado delle prestazioni nella replica secondaria. Se è presente una contesa per le risorse I/O con il carico di lavoro di creazione di report, è possibile usare Resource Governor per controllare i cicli della CPU usati dal carico di lavoro di creazione di report e controllare indirettamente, in una certa misura, i cicli di I/O eseguiti. Ad esempio, se il carico di lavoro di reporting consuma il 10% della CPU ma è vincolato dall'I/O, è possibile usare Resource Governor per limitare l'utilizzo delle risorse della CPU al 5% in modo da rallentare il carico di lavoro di lettura, riducendo così al minimo l'impatto sull'I/O.

Contenuti correlati

  • Last updated on