Raccogliere dati per risolvere i problemi di connettività di SQL Server
Questo articolo illustra come identificare la causa radice dei problemi di connettività di SQL Server ponendo domande rilevanti in base a categorie specifiche. Anche se l'articolo Prerequisiti e elenco di controllo consigliati per la risoluzione dei problemi di connettività di SQL Server include gli elementi più importanti da raccogliere, le domande contenute in questo articolo consentono di limitare la causa dei problemi di connettività e risolverli in modo efficace.
Note
Non tutte le domande sono applicabili a tutti i problemi. Tuttavia, queste domande possono essere utili per valutare come risolvere i problemi di connettività.
Usando le informazioni fornite in questo articolo, dopo aver eseguito zero-in sulla natura esatta del problema, vedere Panoramica dei problemi di autenticazione coerenti in SQL Server per il tipo di errori.
Metodo di raccolta dei dati
Per raccogliere dati, è possibile usare strumenti come Registrazione passaggi dei problemi (PSR), Traccia di rete e Traccia NETLOGON. Questa sezione illustra i passaggi dettagliati per installare e configurare una combinazione di tutti questi strumenti.
Seguire questi passaggi simultaneamente nei computer client e server. Se l'applicazione è un'architettura a 3 livelli o a più livelli, eseguire anche l'installazione su server intermedi.
Installare WireShark in tutti i computer interessati o usare il comando predefinito
NETSH
(Windows 2008 o versioni successive). Non occorre eseguire nessun riavvio.Abilitare la registrazione di debug NETLOGON nel client e in tutti i server eseguendo il comando seguente:
NLTEST /DBFLAG:2080FFFF
Se possibile, eseguire una delle operazioni seguenti:
- Riavviare il computer client.
- Chiedere all'utente di disconnettersi e accedere di nuovo.
- Chiudere e riaprire l'applicazione client.
Nel computer client avviare Problem Steps Recorder (psr.exe) e quindi selezionare Avvia record.
Questo strumento acquisisce accuratamente tutte le azioni utente che precedono il problema e salva i risultati in un file .zip.
Avviare l'acquisizione di rete in tutti i computer.
Se si usa NETSH, eseguire il
NETSH TRACE START CAPTURE=YES TRACEFILE=C:\TEMP%computername%.ETL
comando (usare un nome di file o percorso appropriato).Scaricare la cache DNS (Domain Name System) in tutti i computer eseguendo il
IPCONFIG /FLUSHDNS
comando .Cancellare la cache NETBIOS in tutti i computer eseguendo il
NBTSTAT /RR
comando .Eliminare i ticket Kerberos client eseguendo il
KLIST purge
comando .Cancellare i ticket in ogni server eseguendo il
KLIST -li 0x3e7 purge
comando .Note
Digitare il comando . Non copiare e incollare nella riga di comando perché il trattino potrebbe essere convertito in un trattino lungo (em).
KLIST
supporta la distinzione tra maiuscole e minuscole.Riprodurre il problema.
Arrestare la registrazione psr.exe .
Arrestare le acquisizioni di rete. Salvare il file registrato eseguendo il comando NETSH:
NETSH TRACE STOP
usando un nome significativo. Ad esempio, il nome del file può essere SQLProd01.netmon.cap.Attendere che il prompt dei comandi venga visualizzato nuovamente e quindi chiudere la finestra. Non chiudere la finestra del prompt dei comandi prima che venga visualizzata la richiesta.
Copiare il log NETLOGON in C:\windows\debug\netlogon.log e assegnare al file un nome significativo. Ad esempio, SQLProd01.netlogon.log.
Disabilitare la registrazione eseguendo il
NLTEST /DBFLAG:0x0
comando .
Raccogliere dati per classificare i problemi
Il set di domande seguente è progettato per aiutare a trovare la categoria in cui si trova un problema, guidando così verso la giusta direzione della risoluzione dei problemi. Selezionare ogni elenco a discesa per le domande correlate.
Prima di passare alle domande specifiche, assicurarsi che siano stati soddisfatti tutti i prerequisiti necessari per le connessioni di SQL Server. Per altre informazioni sui prerequisiti, vedere Prerequisiti consigliati ed elenco di controllo per la risoluzione dei problemi di connettività di SQL Server.
Domande più ampie sulla prospettiva
- Il problema riguarda solo le connessioni al database o influisce anche sulle connessioni Web e di condivisione file? Molti casi vengono segnalati al team di SQL Server perché si verificano nel server di database. Tuttavia, potrebbe essere possibile che il problema non sia correlato al database e potrebbe richiedere un supporto di Windows o Active Directory più generale.
- Esiste una relazione di trust tra il dominio utente, il dominio client o il dominio del server se sono diversi? È esterno, foresta, unidirezionale, bidirezionale o nessuno?
- La connessione funziona correttamente se tutte le risorse si trovano nello stesso dominio?
- Il problema è intermittente o periodico o è coerente?
- Il problema si verifica solo se più utenti usano l'applicazione? Si verifica più spesso se lo usano più utenti?
- Il problema si verifica solo in determinati momenti del giorno o in determinati giorni della settimana?
- Il problema si verifica solo quando viene eseguito un backup o il database viene ri-indicizzato?
- Il problema influisce su più server?
- Il problema influisce su un solo nodo in un cluster n-node? In caso affermativo, potrebbe essere più efficiente valutare la possibilità di ricompilare il nodo specifico.
- Il problema riguarda solo uno o due client su diversi? In caso affermativo, forse la ricompilazione sarebbe più efficiente.
- Il problema riguarda solo named pipe e non TCP (o viceversa)?
- Il problema si verifica quando si usa un account di accesso di SQL Server e TCP/IP?
- Esiste un caso di lavoro che può essere confrontato con il caso di errore? In che modo i sistemi differiscono?
Computer client
Usare le domande seguenti per raccogliere dati sui diversi componenti del computer client. Questi dati potrebbero essere utili per identificare i problemi.
Qual è il nome, l'edizione e la versione del sistema operativo (WinVer)?
Qual è il nome e la versione del driver o del provider di SQL Server?
Quali sono il nome del computer e l'indirizzo IP?
Qual è lo stato del dominio del computer? Se è stato aggiunto a un dominio, qual è il nome di dominio?
Quale ambiente di runtime dell'applicazione viene usato? Ad esempio, Internet Information Services (IIS), Windows Form, Web Sphere o processo di SQL Server Integration Services (SSIS).
Quale lingua dell'applicazione viene usata?
Qual è il stringa di connessione usato?
Quale tipo di autenticazione viene usato per connettersi al server? Ad esempio, New Technology LAN Manager (NTLM), Kerberos, SQL o Azure Active Directory (AAD).
Se l'applicazione è un server o un servizio, delega le credenziali utente al database back-end?
Viene usata la delega vincolata?
Che cosa sono l'account e il dominio del servizio dell'applicazione?
Quale tipo di servizio viene usato? È fisico, virtuale o cloud? Ad esempio, IaaS, App Web, Ruolo Web o Power BI.
Che cos'è il driver client? Si tratta di Java Database Connectivity (JDBC) o è in esecuzione in Linux o Mac?
Note
I flussi di lavoro sono attualmente più orientati a Windows.
Il problema riguarda solo i provider legacy, ad esempio
Provider=SQLOLEBD
oDriver={SQL Server}
e non SQL Native Client e i driver successivi (o viceversa)?Il problema si verifica in una sola applicazione o in più applicazioni?
Un file UDL (Universal Data Link) non riesce quando tenta di connettersi ad altri server basati su SQL Server o non riesce a eseguire solo il server che presenta il problema?
L'utente accede al server basato su SQL Server e prova a connettersi usando SQL Server Management Studio (SSMS)?
Il problema si verifica solo quando si usa il nome NETBIOS del server e non quando si usa il nome di dominio completo (FQDN) o viceversa? Funziona usando l'indirizzo IP?
Il client che esegue Windows 10 edizione Enterprise la funzionalità Credential Guard è attivata? In caso affermativo, questo potrebbe influire sugli scenari di delega completa.
Informazioni sul log
Usare le domande seguenti per raccogliere dati sui file di log:
- Qual è il messaggio di errore esatto nello stack di chiamate?
- Il log è stato raccolto dai file ERRORLOG e ERRORLOG.1 di SQL Server?
- I registri eventi dell'applicazione sono stati raccolti dal client e dal server?
- Sono stati raccolti i file di log dell'applicazione client e i file di configurazione? Ad esempio, web.config, rsreportserver.config, *.config o *.ini.
- Esiste una rappresentazione visiva disponibile della rete che mostra i computer, i router e così via?
Problemi nuovi o esistenti
Si riferisce a determinare se il problema è uno sviluppo recente o se è persistente per un po':
- Il problema esiste sempre (nuova installazione) o l'applicazione funziona correttamente per qualche tempo prima che si sia interrotta di recente?
- Se l'applicazione funziona correttamente, quali modifiche sono state apportate all'ambiente? Ad esempio, gli aggiornamenti installati, i controller di dominio aggiornati, le modifiche apportate alle impostazioni del firewall, i controller di dominio rimossi o uno spostamento in un'unità organizzativa diversa nel dominio.
Computer server
Per un server collegato, raccogliere informazioni sul server sia per il server di livello intermedio che per il server back-end. Per un problema di delega da IIS a SQL, raccogliere informazioni sul server Web, incluse le impostazioni web.config e di autenticazione.
- Qual è il nome del sistema operativo, dell'edizione e della versione (Winver)?
- Qual è il nome e la versione del database?
- Qual è il nome del computer?
- Qual è l'indirizzo IP?
- Qual è il nome di dominio se il computer è aggiunto a un dominio?
- Che cos'è l'account e il dominio del servizio SQL Server?
- Qual è il nome dell'istanza di SQL Server?
- Quali protocolli sono abilitati?
- Qual è la porta su cui il server è in ascolto?
- Qual è il nome della pipe del server? Queste informazioni sono disponibili nel log degli errori.
- Quale tipo di ambiente viene usato? È fisico, virtuale o cloud? Ad esempio, IaaS (SQL in una macchina virtuale di Azure) o PaaS (database SQL di Azure, Istanza gestita di SQL (MI)).
- Il database viene distribuito come autonomo, cluster, con mirroring o tramite Always On?
- Qual è il nome e l'indirizzo IP del partner di failover?
- Qual è il nome del cluster virtuale o il nome e la porta del listener?
- Qual è l'INDIRIZZO IP virtuale o listener?
- In quale sistema operativo è installato il database? Si tratta di Windows, Linux o Mac? Ciò potrebbe influire sulla raccolta dei dati.
- Qual è il percorso del database? Si trova in Azure?
- Qual è lo stato corrente del server in termini di Aggiornamento cumulativo e Service Pack più recente? Non è possibile eseguire il debug di un problema già risolto.
- SQL Server è stato aggiornato di recente per supportare Transport Layer Security (TLS) 1.2? I client sono stati aggiornati anche? TLS 1.0 è stato disattivato?
- Qual è lo stato corrente del servizio SQL Server? È in esecuzione?
- Qual è lo stato del servizio SQL Browser? È in esecuzione?
- Qual è la specificità del problema per un account del servizio? L'esecuzione del server con un account del servizio diverso risolve il problema?
Informazioni sull'utente
Raccogliere i dettagli utente seguenti:
- L'utente accede direttamente o accede al computer client in modalità remota? Ad esempio, l'utente usa un browser?
- L'utente è un servizio, ad esempio SQL Agent? L'identità del processo viene usata o viene usata una credenziale archiviata?
- Qual è il tipo di autenticazione usato per connettersi all'applicazione client? È Windows, l'autenticazione basata su Form o AAD?
- L'utente si connette al server usando la sicurezza integrata?
- Quali sono il nome utente e il nome di dominio?
Se l'utente è remoto all'applicazione client, raccogliere i dettagli seguenti:
- Quali sono il nome del computer e l'indirizzo IP?
- Il dominio del computer è aggiunto? In caso affermativo, qual è il nome di dominio?
- L'utente si connette tramite una VPN o un server proxy? Il problema si verifica se uno dei due metodi è connesso direttamente?
- Se l'utente si connette a un server Web, il carico del server è bilanciato?
- Vengono usate sessioni permanenti o affinità di sessione?
- L'utente accede a un server terminal o jump box e accede all'applicazione?
- Il problema riguarda solo gli utenti in unità organizzative specifiche?
- L'utente, il client o il server è stato spostato in un'unità organizzativa diversa in Active Directory?
- Il problema riguarda solo gli utenti non amministrativi?
- Il problema interessa tutti o solo alcuni utenti in un determinato dominio?
Vedi anche
Dichiarazione di non responsabilità sulle informazioni di terze parti
I prodotti di terzi citati in questo articolo sono prodotti da società indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti