Share via

Risolvere i problemi di SQL Server Always On

  • Articolo

Questo articolo consente di risolvere il problema comune relativo alla configurazione Always On in SQL Server.

Nota

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

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 configurare e configurare i gruppi di disponibilità Always On

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

Introduzione con Always On gruppi di disponibilità (SQL Server): il documento fornisce risposte a molte domande sui gruppi di disponibilità e la configurazione. Seguendo tutti i passaggi descritti in questo articolo e esaminando i prerequisiti, le restrizioni e le raccomandazioni per i gruppi di disponibilità Always On (SQL Server) è possibile evitare molti problemi che possono verificarsi durante 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à Always On.

Si verificano problemi durante la configurazione dei gruppi di disponibilità Always On

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

Risolvere Always On configurazione dei gruppi di disponibilità (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à Always On.

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:

  • Msg 19471, Level 16, State 0, Line 2Il cluster WSFC non è riuscito a portare online la risorsa Nome rete con nome DNS ''. Il nome DNS potrebbe essere stato acquisito o avere un conflitto con i servizi dei nomi esistenti oppure il servizio cluster WSFC potrebbe non essere in esecuzione o essere inaccessibile. Usare un nome DNS diverso per risolvere i conflitti di nomi o controllare il log del cluster WSFC per altre informazioni.

  • Msg 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 essere inaccessibile 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 delle volte, 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 del listener. Per risolvere il problema, vedere gli articoli seguenti:

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

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 Always On SQL Server 2012.

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

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

Si verificano problemi di connessione ai gruppi di disponibilità Always On

Dopo aver configurato il listener del gruppo di disponibilità per un gruppo di disponibilità Always On 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 dell'accesso scaduto.

Per risolvere questi errori e simili, vedere quanto segue:

Altri collegamenti alle informazioni:

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

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

  1. Molti problemi correlati 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 di 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 la macchina virtuale è stata spostata di recente in un servizio diverso o se gli indirizzi IP sono stati modificati, è necessario aggiornare il valore della risorsa indirizzo IP per 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à Always On.

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 del tempo di ripristino.After an automatic failover or a planned manual failover without data loss on an availability group, you may find that the failover time exceed your recovery time objective (RTO). Per risolvere i problemi relativi alle cause e alle potenziali risoluzioni, vedere Risoluzione dei problemi: Il gruppo di disponibilità ha superato l'RTO.

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

Le modifiche nella replica primaria non vengono riflesse o lente per la replica nella replica secondaria

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

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

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à Always On.

Server primari o secondari colpiti nella risoluzione dello stato o si verificano failover imprevisti

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

Non è possibile portare online le risorse

Controllare se il ripristino dei database richiede molto tempo esaminando i messaggi in Sql ErrorLog.

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

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 il gruppo di disponibilità per comunicare in una rete dedicata.

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

    Questo argomento nella 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 Always On istanze di replica del gruppo di disponibilità.

  7. Come aggiungere il 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 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 Always On gruppi:

Altre informazioni sui gruppi di disponibilità Always On