Condividi tramite

Risolvere i problemi dei gruppi di disponibilità Always On in SQL Server

  • Articolo

Questo articolo illustra come risolvere il problema comune relativo alla configurazione AlwaysOn in SQL Server.

Note

Per un'esperienza guidata di questo articolo, vedere Risoluzione dei problemi di SQL Server AlwaysOn.

Versione originale del prodotto: SQL Server 2012 Enterprise, SQL Server 2014 Enterprise, SQL Server 2016 Enterprise
Numero KB originale: 10179

Note importanti

Sono necessari puntatori per la configurazione e la configurazione dei gruppi di disponibilità AlwaysOn

Se si sta cercando la documentazione sulla configurazione di Always On, vedere i documenti seguenti:

Introduzione ai gruppi di disponibilità AlwaysOn (SQL Server): il documento fornisce le risposte a molte domande sui gruppi di disponibilità e sulla configurazione. Seguendo tutti i passaggi descritti in questo articolo ed esaminando prerequisiti, restrizioni e consigli per i gruppi di disponibilità AlwaysOn (SQL Server) è possibile evitare molti problemi che possono verificarsi con la configurazione e la gestione dei gruppi di disponibilità nell'ambiente.

Risorse aggiuntive

Se queste informazioni non sono utili, vedere Altre informazioni sui gruppi di disponibilità AlwaysOn.

Si verificano problemi durante la configurazione dei gruppi di disponibilità AlwaysOn

I problemi di configurazione tipici includono i gruppi di disponibilità AlwaysOn sono disabilitati, gli account non sono configurati correttamente, l'endpoint del mirroring del database non esiste, l'endpoint è inaccessibile (errore di SQL Server 1418), l'accesso alla rete non esiste e un comando del database di join ha esito negativo (errore di SQL Server 35250). Per informazioni sulla risoluzione di questi problemi, vedere il documento seguente:

Risolvere i problemi relativi alla configurazione di Gruppi di disponibilità Always On (SQL Server)

Collegamento aggiuntivo: Correzione: Errore 41009 quando si tenta di creare più gruppi di disponibilità

Se il problema persiste, vedere Altre informazioni sui gruppi di disponibilità AlwaysOn.

Si verificano problemi con la configurazione del listener (19471, 19476 e altri errori)

Uno dei problemi di configurazione più comuni riscontrati dai clienti è la creazione del listener del gruppo di disponibilità. Gli errori sono simili ai seguenti:

  • Messaggio 19471, livello 16, stato 0, riga 2Il cluster WSFC non è riuscito a portare online la risorsa Nome di rete con nome DNS ''. È possibile che il nome DNS sia stato acquisito o che si sia verificato un conflitto con i servizi dei nomi esistenti oppure che il servizio cluster WSFC non sia in esecuzione o non sia accessibile. Usare un nome DNS diverso per risolvere i conflitti di nomi o controllare il log del cluster WSFC per altre informazioni.

  • Messaggio 19476, livello 16, stato 4, riga 2Il tentativo di creare il nome di rete e l'indirizzo IP per il listener non è riuscito. Il servizio WSFC potrebbe non essere in esecuzione o potrebbe non essere accessibile nello stato corrente oppure i valori specificati per il nome di rete e l'indirizzo IP potrebbero non essere corretti. Controllare lo stato del cluster WSFC e convalidare il nome di rete e l'indirizzo IP con l'amministratore di rete.

La maggior parte del tempo, l'errore di creazione del listener risultante nei messaggi precedenti è dovuto alla mancanza di autorizzazioni per l'oggetto CNO (Cluster Name Object) in Active Directory per creare e leggere l'oggetto computer listener. Per la risoluzione di questo problema, vedere gli articoli seguenti:

Se il problema persiste, vedere Altre informazioni sui gruppi di disponibilità AlwaysOn.

Il failover automatico non funziona come previsto

Se si nota che il failover automatico non funziona come previsto durante i test o nell'ambiente di produzione, vedere Risoluzione dei problemi di failover automatico negli ambienti AlwaysOn di SQL Server 2012.

La configurazione non corretta degli errori massimi nel periodo specificato è una delle cause principali per il failover automatico del database primario nel database secondario. Il valore predefinito per questa impostazione è N-1, dove N è il numero di repliche. Per altre informazioni, vedere Limite massimo errori del cluster di failover (gruppo).

Se il problema persiste, vedere Altre informazioni sui gruppi di disponibilità AlwaysOn.

Si verificano problemi di connessione ai gruppi di disponibilità AlwaysOn

Dopo aver configurato il listener del gruppo di disponibilità per un gruppo di disponibilità AlwaysOn in SQL Server 2012, potrebbe non essere possibile effettuare il ping del listener o connettersi a esso da un'applicazione. È possibile che venga visualizzato un errore simile al seguente:

Sqlcmd: Errore: Microsoft SQL Native Client: timeout di accesso scaduto.

Per risolvere questi e simili errori, esaminare quanto segue:

Altri collegamenti alle informazioni:

Se il problema persiste, vedere Altre informazioni sui gruppi di disponibilità AlwaysOn.

Si verificano problemi durante la configurazione dei gruppi di disponibilità Always On nella macchina virtuale di Azure (IaaS)

  1. Molti problemi relativi a Always On si verificano a causa di una configurazione non corretta del listener. Se si verificano problemi di connessione al listener,

    1. Assicurarsi di leggere tutte le limitazioni del listener ILB e seguire tutti i passaggi descritti nell'articolo seguente prestando particolare attenzione alla configurazione delle dipendenze, all'indirizzo IP e a vari altri parametri nello script di PowerShell.

    2. In caso di dubbi, è possibile eliminare e ricreare il listener in base al documento precedente.

  2. Se di recente la macchina virtuale è stata spostata in un servizio diverso o se gli indirizzi IP sono stati modificati, è necessario aggiornare il valore della risorsa indirizzo IP in modo da riflettere il nuovo indirizzo ed è necessario ricreare l'endpoint con carico bilanciato per il gruppo di disponibilità. È possibile aggiornare l'indirizzo IP usando i Get comandi o Set come indicato di seguito:

    Get-ClusterResource "IPResourceName" | Set-ClusterParameter -name Address -value "w.x.y.z"

Documenti consigliati:

Se il problema persiste, vedere Altre informazioni sui gruppi di disponibilità AlwaysOn.

Il failover da primario a secondario o viceversa richiede molto tempo

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 tempo di ripristino (RTO, Recovery Time Objective). Per risolvere i problemi relativi alle cause e alle possibili risoluzioni, vedere Risolvere i problemi relativi al superamento dell'obiettivo RTO del gruppo di disponibilità.

Se il problema persiste, vedere Altre informazioni sui gruppi di disponibilità AlwaysOn.

Le modifiche nella replica primaria non vengono riflesse su o lente da replicare nella replica secondaria

È possibile notare che le modifiche nella replica primaria non vengono propagate in modo tempestivo al database secondario. Per risolvere questi problemi, provare a eseguire le operazioni seguenti:

Se il problema persiste, vedere Altre informazioni sui gruppi di disponibilità AlwaysOn.

Come gestire le dimensioni del log delle transazioni per i database del gruppo di disponibilità

È possibile ridurre le dimensioni del log delle transazioni configurando backup regolari in server primari o secondari.

Per altre informazioni, vedere gli argomenti seguenti:

Se queste informazioni non sono utili, vedere Altre informazioni sui gruppi di disponibilità AlwaysOn.

Server primari o secondari colpiti in Risoluzione dello stato oppure si verificano failover imprevisti

Se il problema persiste, vedere Altre informazioni sui gruppi di disponibilità AlwaysOn.

Non è possibile portare le risorse online

Controllare se i database richiedono molto tempo per il ripristino esaminando i messaggi nel log degli errori SQL.

Se il problema persiste, vedere Altre informazioni sui gruppi di disponibilità AlwaysOn.

Domande frequenti

  1. È possibile avere due listener per un gruppo di disponibilità?

    Sì, è possibile configurare più listener per lo stesso gruppo di disponibilità. Vedere Come creare più listener per lo stesso gruppo di disponibilità (Goden Yao).

  2. È possibile avere una scheda di interfaccia di rete separata per il traffico sempre attivo e la connettività client?

    Sì, è possibile avere una scheda di interfaccia di rete dedicata per il traffico Always On. Vedere Configurare un gruppo di disponibilità per comunicare in una rete dedicata.

  3. Quali edizioni supportano le istanze del cluster di failover Always On?

    Questo argomento della documentazione online di SQL Server contiene altre informazioni: Edizioni e funzionalità supportate per SQL Server 2016.

  4. Come eseguire il ripristino in caso di errore in tutti i nodi del cluster?

    Vedere Ripristino di emergenza WSFC tramite quorum forzato (SQL Server).

  5. Dove è possibile trovare informazioni sul supporto per le transazioni distribuite nelle configurazioni del gruppo di disponibilità?

    Vedere Transazioni - gruppi di disponibilità e mirroring del database.

  6. Come aggiornare le configurazioni Always On?

    Vedere Aggiornamento delle istanze di replica del gruppo di disponibilità AlwaysOn.

  7. Come aggiungere un database abilitato per TDE (Transparent Data Encryption) alla configurazione del gruppo di disponibilità?

    Per aggiungere il database abilitato per TDE al gruppo di disponibilità, vedere Come configurare Always On per un database TDE.

  8. Come configurare gli avvisi per verificare se il database secondario è in ritardo rispetto al database primario?

    È possibile usare lo script seguente:

    SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server,
dr_state.database_id AS database_id,
is_ag_replica_local = CASE
    WHEN ar_state.is_local = 1 THEN N'LOCAL'
    ELSE 'REMOTE'
    END,
ag_replica_role = CASE
    WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED'
    ELSE ar_state.role_desc
    END,
dr_state.last_hardened_lsn, dr_state.last_hardened_time,
datediff(s,last_hardened_time, getdate()) AS 'seconds behind primary'
FROM (( sys.availability_groups AS ag
JOIN sys.availability_replicas AS ar
    ON ag.group_id = ar.group_id)
JOIN sys.dm_hadr_availability_replica_states AS ar_state
    ON ar.replica_id = ar_state.replica_id)
JOIN sys.dm_hadr_database_replica_states dr_state
    ON ag.group_id = dr_state.group_id AND dr_state.replica_id = ar_state.replica_id

  9. Come ricevere un avviso se lo stato del database è diverso da quello sincronizzato?

    È possibile usare lo script seguente:

    SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server,
dr_state.database_id AS database_id,
is_ag_replica_local = CASE
    WHEN ar_state.is_local = 1 THEN N'LOCAL'
    ELSE 'REMOTE'
    END,
ag_replica_role = CASE
    WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED'
    ELSE ar_state.role_desc
    END,
ar_state.connected_state_desc, ar.availability_mode_desc, dr_state.synchronization_state_desc
FROM (( sys.availability_groups AS ag
JOIN sys.availability_replicas AS ar
    ON ag.group_id = ar.group_id )
JOIN sys.dm_hadr_availability_replica_states AS ar_state
    ON ar.replica_id = ar_state.replica_id)
JOIN sys.dm_hadr_database_replica_states dr_state
    ON ag.group_id = dr_state.group_id AND dr_state.replica_id = ar_state.replica_id

    È anche possibile esaminare i collegamenti seguenti per altri metodi per monitorare i gruppi AlwaysOn:

Altre informazioni sui gruppi di disponibilità AlwaysOn