Risoluzione dei problemi relativi al clustering di failover
In questo argomento sono riportate informazioni sui seguenti argomenti:
Procedura di base per la risoluzione dei problemi.
Recupero da un errore del clustering di failover.
Risoluzione dei problemi più comuni relativi al clustering di failover.
Utilizzo di stored procedure estese e di oggetti COM.
Procedura di base per la risoluzione dei problemi
Quando si utilizza il clustering di failover di SQL Server, tenere presente che il cluster di server è costituito da un'istanza del cluster di failover eseguita in Microsoft Cluster Services (MSCS). L'istanza di SQL Server potrebbe essere ospitata da nodi basati su Microsoft MSCS che forniscono il cluster di server Microsoft.
Gli eventuali problemi esistenti sui nodi che ospitano il cluster di server possono manifestarsi in relazione all'istanza del cluster di failover. Per analizzare e risolvere questi problemi, attenersi nell'ordine ai passaggi della procedura di risoluzione dei problemi del cluster di failover SQL Server riportati di seguito:
Componenti hardware: esaminare il registro eventi di sistema di Microsoft Windows.
Sistema operativo: esaminare il registro eventi di sistema e il registro eventi applicazioni di Windows.
Rete: esaminare i registri eventi di sistema e il registro eventi applicazioni di Windows. Confrontare l'attuale configurazione con quanto indicato nell'articolo della Knowledge Base Recommended Private "Heartbeat" Configuration on a Cluster Server.
Protezione: esaminare i registri eventi di protezione e il registro eventi applicazioni di Windows.
MSCS: esaminare il registro di sistema di Windows, il registro eventi applicazioni e il registro cluster.
SQL Server: eseguire la normale procedura di risoluzione dei problemi dopo aver verificato che i componenti hardware, il sistema operativo, la rete, il sistema di protezione e MSCS non presentano problemi.
Recupero da un errore del clustering di failover
Sono in genere due le cause di un errore del clustering di failover:
Errore hardware in uno dei nodi di un cluster a due nodi. L'errore hardware può essere causato dal danneggiamento della scheda SCSI o da un errore del sistema operativo.
Per eseguire il recupero in presenza di questo errore, utilizzare il programma di installazione di SQL Server per rimuovere il nodo bloccato dal cluster di failover, risolvere il problema hardware con il computer non in linea, ripristinare il computer, quindi aggiungere nuovamente il nodo riparato all'istanza del cluster di failover.
Per ulteriori informazioni, vedere Procedura: Creazione di un nuovo cluster di failover di SQL Server (programma di installazione) e Procedura: Recupero da un errore del cluster di failover. Scenario 1.
Errore del sistema operativo. In questo caso, il nodo non è in linea ma è irrimediabilmente danneggiato.
Per eseguire il recupero in presenza di un errore del sistema operativo, recuperare il nodo e testare il cluster di failover. Se il failover dell'istanza di SQL Server non viene eseguito correttamente, è necessario utilizzare il programma di installazione di SQL Server per rimuovere SQL Server dal cluster di failover, apportare le necessarie correzioni, ripristinare il computer, quindi aggiungere nuovamente il nodo riparato all'istanza del cluster di failover.
L'utilizzo di questa procedura per eseguire il recupero in presenza di un errore del sistema operativo può richiedere tempo. Se è possibile eseguire il recupero in modo più agevole, evitare di utilizzare questa tecnica.
Per ulteriori informazioni, vedere Procedura: Creazione di un nuovo cluster di failover di SQL Server (programma di installazione) e Como recuperar-se de falhas no cluster de failover no cenário 2.
Risoluzione di problemi comuni
Di seguito vengono elencati alcuni problemi comuni relativi all'utilizzo e le rispettive modalità di risoluzione.
Problema: uso non corretto della sintassi del prompt dei comandi per installare SQL Server
Problema 1: è difficile diagnosticare problemi di installazione quando si utilizza l'opzione /qn dal prompt dei comandi, in quanto tale opzione determina l'eliminazione di tutte le finestre di dialogo dell'interfaccia utente e dei messaggi di errore del programma di installazione. Se l'opzione /qn viene specificata, tutti i messaggi del programma di installazione, compresi i messaggi di errore, vengono inseriti nei file di log del programma. Per ulteriori informazioni sui file di log, vedere Procedura: Visualizzazione e lettura dei file di log del programma di installazione di SQL Server.
Risoluzione 1: utilizzare l'opzione /qb anziché l'opzione /qn. Se si utilizza l'opzione /qb, per ogni passaggio verrà visualizzata l'interfaccia utente di base, inclusi i messaggi di errore.
Problema: SQL Server non è in grado di accedere alla rete dopo la migrazione in un altro nodo
Problema 1: gli account del servizio SQL Server non sono in grado di contattare un controller di dominio.
Risoluzione 1: controllare la presenza di problemi di rete, quali errori della scheda o problemi DNS, nei log eventi. Verificare che sia possibile effettuare il ping del controller di dominio.
Problema 2: le password dell'account del servizio SQL Server non sono identiche in tutti i nodi del cluster oppure il nodo non è in grado di riavviare un servizio SQL Server di cui è stata eseguita la migrazione da un nodo bloccato.
Risoluzione 2: modificare le password dell'account del servizio SQL Server tramite Gestione configurazione SQL Server. In caso contrario, se si modificano le password dell'account del servizio SQL Server in un nodo, sarà necessario modificare le password anche in tutti gli altri nodi. Questa operazione viene eseguita automaticamente in Gestione configurazione SQL Server.
Problema: SQL Server non è in grado di accedere ai dischi del cluster
Problema 1: il firmware o i driver non sono aggiornati in tutti i nodi.
Risoluzione 1: verificare che in tutti i nodi vengano utilizzate le versioni corrette del firmware e le stesse versioni del driver.
Problema 2: un nodo non è in grado di recuperare i dischi del cluster di cui è stata eseguita la migrazione da un nodo bloccato in un disco cluster condiviso che utilizza una diversa lettera di unità.
Risoluzione 2: le lettere di unità disco dei dischi del cluster devono essere identiche su entrambi i server. In caso contrario, modificare l'installazione originale del sistema operativo e del servizio cluster (MSCS, Microsoft Cluster Service).
Problema: un servizio SQL Server in errore determina il failover
Risoluzione: per impedire che un errore in servizi specifici determini il failover del gruppo SQL Server, configurare i servizi tramite Amministrazione cluster in Windows, come descritto di seguito:
- Deselezionare la casella di controllo Influisce sul gruppo nella scheda Avanzate della finestra di dialogo Proprietà full-text. Se tuttavia SQL Server causa un failover, il servizio Ricerca full-text verrà riavviato.
Problema: SQL Server non viene avviato automaticamente
Risoluzione: per avviare automaticamente un cluster di failover, utilizzare Amministrazione cluster in MSCS. Impostare il servizio SQL Server per l'avvio manuale. Configurare inoltre Amministrazione cluster in MSCS per l'avvio del servizio SQL Server. Per ulteriori informazioni, vedere Gestione di servizi.
Problema: il nome di rete è offline e non è possibile connettersi a SQL Server tramite TCP/IP
Problema 1: DNS non è disponibile e la risorsa del cluster è impostata in modo da richiedere DNS.
Risoluzione 1: Risolvere i problemi relativi a DNS.
Problema 2: nella rete è presente un nome duplicato.
Risoluzione 2: utilizzare NBTSTAT per individuare il nome duplicato e risolvere il problema.
**Problema 3:**SQL Server non esegue la connessione tramite named pipe.
Risoluzione 3: per la connessione tramite named pipe, creare un alias utilizzando Gestione configurazione SQL Server per connettersi al computer appropriato. Se, ad esempio, si utilizzano un cluster con due nodi (Node A e Node B) e un'istanza del cluster di failover (Virtsql) con un'istanza predefinita, è possibile eseguire la procedura seguente per connettersi al server la cui risorsa Nome di rete non è in linea:
Utilizzare Amministrazione cluster per determinare il nodo in cui è esecuzione il gruppo che contiene l'istanza di SQL Server. In questo esempio si tratta del nodo Node A.
Avviare il servizio SQL Server nel computer tramite net start. Per ulteriori informazioni sull'utilizzo di net start, vedere Avvio manuale di SQL Server.
Avviare Gestione configurazione SQL Server di SQL Server su Node A. Visualizzare il nome della pipe sulla quale il server è in attesa. Il nome dovrebbe avere il formato seguente: \\.\$$\VIRTSQL\pipe\sql\query.
Sul computer client, avviare Gestione configurazione SQL Server.
Creare l'alias SQLTEST1 per connettersi alla pipe tramite named pipe. A tale scopo, immettere Node A come nome del server e modificare il nome della pipe in \\.\pipe\$$\VIRTSQL\sql\query.
Connettersi all'istanza utilizzando l'alias SQLTEST1 come nome del server.
Problema: impossibile installare SQL Server in un cluster con errore 11001
Problema: Chiave orfana del Registro di sistema in [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.X\Cluster]
Risoluzione: accertarsi che l'hive del Registro di sistema MSSQL.X non sia attualmente in uso, quindi eliminare la chiave relativa al cluster.
Problema: messaggio di errore "Impossibile continuare l'installazione. Windows Installer non dispone di privilegi sufficienti per l'accesso alla directory <unità>\Microsoft SQL Server. Accedere come amministratore oppure contattare l'amministratore del sistema"
Problema: questo errore è causato da un'unità condivisa SCSI non partizionata correttamente.
Risoluzione: utilizzare la procedura seguente per ricreare una singola partizione nel disco condiviso:
Eliminare la risorsa disco dal cluster.
Eliminare tutte le partizioni presenti nel disco.
Nelle proprietà del disco verificare che si tratta di un disco di base.
Creare un'unica partizione nel disco condiviso, formattare il disco e assegnarvi una lettera di unità.
Aggiungere il disco al cluster tramite Amministrazione cluster (cluadmin).
Eseguire il programma di installazione di SQL Server.
Problema: le applicazioni non sono in grado di integrare le risorse di SQL Server in una transazione distribuita
**Problema:**Microsoft Distributed Transaction Coordinator (MS DTC) non è completamente configurato in Windows, pertanto è possibile che le applicazioni non siano in grado di visualizzare l'elenco delle risorse SQL Server in una transazione distribuita. Questo problema può interessare server collegati, query distribuite e stored procedure remote che utilizzano transazioni distribuite. Per ulteriori informazioni sulla configurazione di MS DTC, vedere Operazione preliminari all'installazione del clustering di failover.
Risoluzione: per evitare tali problemi, è necessario abilitare completamente i servizi MS DTC nei server in cui è installato SQL Server e MS DTC è configurato.
Per abilitare completamente MS DTC, effettuare le operazioni seguenti:
Nel Pannello di controllo aprire Strumenti di amministrazione e quindi Gestione computer.
Nel riquadro sinistro di Gestione computer espandere Servizi e applicazioni e quindi fare clic su Servizi.
Nel riquadro destro di Gestione computer fare clic con il pulsante destro del mouse su Distributed Transaction Coordinator e quindi scegliere Proprietà.
Nella finestra Distributed Transaction Coordinator fare clic sulla scheda Generale e quindi su Arresta per interrompere il servizio.
Nella finestra Distributed Transaction Coordinator fare clic sulla scheda Connessione e impostare l'account di accesso NT AUTHORITY\NetworkService.
Fare clic su Applica e quindi su OK per chiudere la finestra Distributed Transaction Coordinator. Chiudere la finestra Gestione computer. Chiudere la finestra Strumenti di amministrazione.
Utilizzo delle stored procedure estese e degli oggetti COM
Le stored procedure estese con un cluster di failover devono essere installate in un disco del cluster dipendente da SQL Server. In tal modo quando un nodo cede il controllo a un altro nodo mediante il failover, sarà comunque possibile utilizzare le stored procedure estese.
Se le stored procedure estese utilizzano componenti COM, l'amministratore dovrà registrare i componenti COM in ogni nodo del cluster. Per consentire la creazione dei componenti COM, le informazioni per il caricamento e l'esecuzione dei componenti stessi devono trovarsi nel Registro di sistema del nodo attivo. In caso contrario, le informazioni resteranno nel Registro di sistema del computer in cui i componenti COM sono stati registrati per la prima volta.