Raccogliere dati per risolvere i problemi di connettività di SQL Server
Questo articolo consente di identificare la causa radice dei problemi di connettività di SQL Server ponendo domande pertinenti in base a categorie specifiche. Anche se l'articolo Prerequisiti consigliati ed elenco di controllo 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 di risolverli in modo efficace.
Nota
Non tutte le domande sono applicabili a tutti i problemi. Tuttavia, queste domande possono essere utili per la risoluzione dei problemi di connettività.
Usando le informazioni fornite in questo articolo, una volta che si è in grado di azzeramento 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 i dati, è possibile usare strumenti come Registrazione passaggi dei problemi ,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 contemporaneamente nei computer client e server. Se l'applicazione è un'architettura a 3 livelli o a più livelli, eseguire l'installazione anche nei server intermedi.
Installare WireShark in tutti i computer interessati o usare il comando predefinito
NETSH
(Windows 2008 o versioni successive). Non è necessario alcun 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 Registrazione passaggi problemi (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 .Nota
Digitare il comando . Non copiare e incollare nella riga di comando perché il trattino potrebbe essere convertito in un trattino lungo (em).
KLIST
fa 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 la riapparizione del prompt dei comandi e quindi chiudere la finestra. Non chiudere la finestra del prompt dei comandi prima che venga visualizzato il prompt.
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 individuare la categoria in cui si verifica 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 di prospettiva più ampie
- Il problema interessa 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 affatto correlato al database e potrebbe richiedere un supporto più generale di Windows o Active Directory.
- 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 più utenti lo usano?
- Il problema si verifica solo in determinati orari del giorno o in determinati giorni della settimana?
- Il problema si verifica solo quando viene eseguito un backup o il database viene nuovamente indicizzato?
- Il problema interessa più di un server?
- Il problema riguarda solo un nodo in un cluster a n nodi? In caso affermativo, potrebbe essere più efficiente prendere in considerazione la ricompilazione di quel nodo specifico.
- Il problema riguarda solo uno o due client su più client? In caso affermativo, forse la ricostruzione sarebbe più efficiente.
- Il problema riguarda solo named pipe e non TCP (o viceversa)?
- Il problema si verifica quando si usano 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 sono diversi?
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 è aggiunto a un dominio, qual è il nome di dominio?
Quale ambiente di runtime dell'applicazione viene usato? Ad esempio, processo Internet Information Services (IIS), Windows Form, Web Sphere o SQL Server Integration Services (SSIS).
Quale lingua dell'applicazione viene usata?
Qual è la stringa di connessione usata?
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?
Quali sono l'account e il dominio del servizio 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? È java database connectivity (JDBC) o viene eseguito in Linux o Mac?
Nota
I flussi di lavoro sono attualmente più orientati a Windows.
Il problema riguarda solo i provider legacy, ad
Provider=SQLOLEBD
esempio oDriver={SQL Server}
, e non i driver SQL Native Client e versioni successive (o viceversa)?Il problema si verifica in una sola applicazione o in più applicazioni?
Un file UDL (Universal Data Link) ha esito negativo quando tenta di connettersi ad altri server basati su SQL Server o non riesce solo al 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 Enterprise Edition ha attivato la funzionalità Credential Guard? In caso affermativo, ciò potrebbe influire sugli scenari di delega completa.
Informazioni di 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 log eventi dell'applicazione sono stati raccolti dal client e dal server?
- I file di log dell'applicazione client e i file di configurazione sono stati raccolti? Ad esempio, web.config, rsreportserver.config, *.configo *.ini.
- È disponibile una rappresentazione visiva 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 è sempre esistito (nuova installazione) o l'applicazione ha funzionato correttamente per qualche tempo prima che si interrompesse di recente?
- Se l'applicazione usata per funzionare correttamente, quali modifiche sono state apportate all'ambiente? Ad esempio, gli aggiornamenti installati, i controller di dominio aggiornati, le modifiche nelle impostazioni del firewall, i controller di dominio rimossi o lo 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 diweb.config e autenticazione.
- Qual è il nome del nome, dell'edizione e della versione del sistema operativo (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 è in ascolto il server?
- 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 (VM) di Azure o PaaS (database SQL di Azure, istanza gestita di SQL ).
- Il database viene distribuito come autonomo, in cluster, con mirroring o con Always On?
- Qual è il nome e l'indirizzo IP del partner di failover?
- Qual è il nome e la porta del cluster virtuale o del listener?
- Qual è l'IP virtuale o l'IP del listener?
- In quale sistema operativo è installato il database? Si tratta di Windows, Linux o Mac? Ciò potrebbe influire sulla raccolta dei dati.
- Qual è la posizione del database? Si trova in Azure?
- Qual è lo stato corrente del server in termini di Service Pack e aggiornamento cumulativo più recenti? Non serve eseguire il debug di un problema già risolto.
- SQL Server è stato aggiornato di recente per supportare Transport Layer Security (TLS) 1.2? Anche i client sono stati aggiornati? 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 di servizio diverso risolve il problema?
Informazioni utente
Raccogliere i dettagli utente seguenti:
- L'utente accede direttamente al computer client o vi accede in remoto? Ad esempio, l'utente usa un browser?
- L'utente è un servizio, ad esempio SQL Agent? Viene usata l'identità del processo o vengono usate credenziali archiviate?
- Qual è il tipo di autenticazione usato per connettersi all'applicazione client? Si tratta di Autenticazione Di Windows, 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 nell'applicazione client, raccogliere i dettagli seguenti:
- Quali sono il nome del computer e l'indirizzo IP?
- Il computer è aggiunto al dominio? 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 terminale o a una 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 (OU) diversa in Active Directory?
- Il problema interessa solo gli utenti non amministratori?
- Il problema interessa tutti o solo alcuni utenti di un determinato dominio?
Vedere 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