Risolvere i problemi di SQL Server Always On
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
I dati CSS di Microsoft indicano che una percentuale significativa di problemi dei clienti viene spesso affrontata in precedenza in un'unità di certificazione rilasciata, ma non applicata in modo proattivo e pertanto consiglia l'installazione proattiva e continuativa delle unità di certificazione man mano che diventano disponibili. Per altre informazioni, vedere Annuncio degli aggiornamenti al modello di manutenzione incrementale (ISM) SQL Server.
Per controllare le CU più recenti che potrebbero essere disponibili per la versione, vedere Come determinare la versione, l'edizione e il livello di aggiornamento di SQL Server e dei relativi componenti.
È possibile vedere Strumenti utili per la risoluzione dei problemi e il monitoraggio Always On gruppi di disponibilità in Always On Guida alla risoluzione dei problemi e al monitoraggio dei gruppi di disponibilità per altre informazioni sugli strumenti che è possibile usare per diagnosticare diversi tipi di problemi e per monitorare i gruppi di disponibilità. La guida include anche scenari aggiuntivi che potrebbero non essere trattati in questa procedura guidata.
Il nodo padre per Always On documentazione sui gruppi di disponibilità e fornisce un riferimento di arresto unico per varie domande, vedere Always On Gruppi di disponibilità (SQL Server).
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
- Procedura dettagliata: Creazione di un gruppo di disponibilità SQL Server 2012 Always On
- Guide all'architettura Always On
- Collegamento esterno: SQL Server Always On gruppi di disponibilità
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:
- Errore di timeout e non è possibile connettersi a un listener del gruppo di disponibilità SQL Server 2012 Always On in un ambiente con più subnet
- Timeout di connessione nel gruppo di disponibilità multi subnet
Altri collegamenti alle informazioni:
- Un aggiornamento introduce il supporto per le funzionalità di Always On in SQL Server 2012 o versione successiva a the.NET Framework 3.5 SP1
- SQL Server clustering multi subnet (SQL Server)
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)
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,
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.
In caso di dubbi, è possibile eliminare e ricreare il listener in base al documento precedente.
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 oSet
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:
Per gli ambienti SQL Server 2012 e SQL Server 2014, vedere CORREZIONE: Sincronizzazione lenta quando i dischi hanno dimensioni di settore diverse per i file di log di replica primaria e secondaria negli ambienti SQL Server gruppo di disponibilità e logshipping.
Controllare se i nodi secondari si trovano in uno stato Sospeso nell'amministratore del cluster.
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:
- Offload dei backup supportati nelle repliche secondarie di un gruppo di disponibilità
- Esecuzione di backup del log delle transazioni tramite Always On gruppo di disponibilità Read-Only repliche secondarie - Parte 1
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
Controllare i log eventi di sistema e dell'applicazione per verificare la presenza di problemi hardware e altri errori e collaborare con il fornitore per risolverli.
Se si usano macchine virtuali, verificare la relativa knowledge base per verificare se sono presenti problemi segnalati di recente che potrebbero contribuire al problema. Ad esempio, la perdita di pacchetti di grandi dimensioni a livello di sistema operativo guest nella scheda di interfaccia di rete virtuale VMXNET3 in ESXi (2039495) ha causato problemi con la configurazione del gruppo di disponibilità in alcuni casi.
Ulteriori informazioni:
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
È 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).
È 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.
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.
Come eseguire il ripristino in caso di errore in tutti i nodi del cluster?
Vedere Ripristino di emergenza WSFC tramite quorum forzato (SQL Server).
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.
Come aggiornare le configurazioni Always On?
Vedere Aggiornamento Always On istanze di replica del gruppo di disponibilità.
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.
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
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:
Gestione basata su criteri per problemi operativi con i gruppi di disponibilità Always On
Collegamento esterno: Uso della gestione basata su criteri per gli avvisi di perdita di dati dei gruppi di disponibilità SQL Server
Comportamento del controllo dinamico in Windows Server 2012 clustering di failover R2