Condividi tramite

Risolvere i problemi intermittenti o periodici relativi alla connessione a SQL Server

  • Articolo

Note

Prima di iniziare la risoluzione dei problemi, è consigliabile controllare i prerequisiti e verificare l'elenco di controllo. Per altre informazioni, vedere Articoli self-help.

La stabilità della rete è essenziale per il corretto funzionamento di vari servizi e applicazioni. Tuttavia, ci sono momenti in cui i problemi di rete interrompono questa stabilità. Questo articolo illustra e risolve i problemi di rete intermittenti o periodici e i relativi messaggi di errore tipici. Questi problemi possono essere frustranti, ma è possibile risolverli in modo più efficace con una migliore comprensione e tecniche di risoluzione dei problemi appropriate.

Messaggi di errore più comuni

I problemi intermittenti si verificano in modo irregolare, mentre i problemi periodici tendono a verificarsi a intervalli prevedibili. L'identificazione del tipo di problema è il primo passaggio per la risoluzione dei problemi. Quando si verificano problemi di rete intermittenti o periodici, è possibile che vengano visualizzati i messaggi di errore seguenti:

  • Errore di collegamento di comunicazione: questo errore indica un'interruzione della comunicazione tra i componenti di rete.
  • Timeout connessione scaduto: timeout della connessione al server, che suggerisce un ritardo o un'indisponibilità del server.
  • Errore di rete generale: un messaggio di errore di rete generale spesso indica un problema non specificato con la rete.
  • Errore a livello di trasporto: questo errore si verifica a livello di trasporto, suggerendo problemi con la trasmissione dei dati.
  • Il nome di rete specificato non è più disponibile: questo messaggio implica che non è possibile raggiungere la risorsa di rete specificata.
  • Timeout semaforo: questo errore punta a una condizione di timeout correlata all'uso di semafori nella rete.
  • Timeout dell'operazione di attesa: un'operazione di attesa ha superato il tempo consentito, in genere a causa di ritardi di rete.
  • Si è verificato un errore irreversibile durante la lettura del flusso di input dalla rete: questo messaggio suggerisce un errore critico durante la lettura dei dati dalla rete.
  • Errore del protocollo nel flusso TDS: il flusso TDS (Tabular Data Stream) è un protocollo usato da SQL Server. Questo errore indica un problema con il protocollo.
  • Il server non è stato trovato o non è accessibile: questo messaggio di errore suggerisce che il server a cui si sta tentando di accedere non è disponibile o non è stato trovato.
  • SQL Server non esiste o non è stato negato l'accesso: questo errore può indicare l'assenza di SQL Server o un errore di autenticazione durante il tentativo di accesso a SQL Server.

Causa

I problemi più comuni sono correlati alle gocce di pacchetti dovute a antivirus, ottimizzazione di rete, driver di rete meno recenti, router o commutatori non danneggiati e connessioni non in pool nell'applicazione.

Alcune cause, ad esempio antivirus, possono essere difficili da dimostrare, ma sono ancora comuni. Potrebbe essere necessario disinstallare e riavviare il computer per dimostrarlo, senza prove chiare. Anche la creazione di un'eccezione per SQL Server potrebbe funzionare. Ma la disattivazione dell'antivirus in genere non funziona perché i driver di filtro di rete vengono ancora caricati anche se non vengono monitorati.

Processo di risoluzione dei problemi

Note

Questo processo è progettato per le connessioni client e server di SQL Server. Altre comunicazioni, ad esempio il mirroring di SQL Server, Always-On e il traffico di sincronizzazione di Service Broker sulla porta 5022, non vengono risolte.

In generale, la risoluzione dei problemi deve essere basata sui dati, che può dare modo a test empirici in un contesto più mirato. Se il problema è molto intermittente e le tracce di rete saranno difficili da acquisire, i metodi empirici possono essere applicati per primi.

Raccogliere un report usando SQLCHECK in ogni computer

Eseguire SQLCHECK in ogni computer per produrre un report. È utile determinare il motivo per cui una connessione potrebbe non riuscire.

Raccogliere tracce di rete nel client e nel server

  • Nei computer Windows raccogliere tracce di rete usando SQLTRACE.

    Seguire questa procedura per preparare ed eseguire la traccia. I passaggi 2 e 3 devono essere eseguiti una sola volta.

    1. Scaricare la versione più recente di SQLTRACE e decomprimerla in una cartella, ad esempio C:\MSDATA.

    2. Aprire il file SQLTrace.ini e disattivare le impostazioni seguenti:

      BIDTrace=no, AuthTrace=no e EventViewer=no

    3. Salvare il file.

    4. Aprire PowerShell come amministratore e passare alla cartella contenente SQLTrace.ps1.

      CD C:\MSDATA

    5. Avviare la raccolta di tracce.

      .\SQLTrace.ps1 -start

    6. Riprodurre il problema o attendere che si verifichi l'errore.

    7. Interrompere la traccia.

      .\SQLTrace.ps1 -stop

    Una cartella di output viene generata nella directory corrente ed è possibile usarla per un'ulteriore analisi.

  • Nei computer non Windows usare TCPDUMP o WireShark per raccogliere un'acquisizione di pacchetti.

Eseguire SQL Server Network Analyzer

L'interfaccia utente di SQL Network Analyzer (SQLNAUI) offre un'interfaccia grafica per selezionare i file di traccia per l'analisi e l'impostazione delle opzioni. Scaricarlo da SQL Network Analyzer (SQLNA).

Elaborare le tracce client e server separatamente. Se sono presenti tracce concatenati, elaborarle contemporaneamente. Le dimensioni totali di questi file non devono superare l'80% della memoria del computer. Assicurarsi di disporre di memoria sufficiente per elaborare tutti i file di traccia correlati.

Questo strumento genererà un report di problemi sospetti e un file CSV che è possibile esplorare in Excel per ricerche alternative.

Provare a individuare le conversazioni corrispondenti nella traccia client e nella traccia del server. In genere, gli indirizzi IP e i numeri di porta corrispondono. Tuttavia, se le connessioni passano attraverso qualsiasi tipo di mapping di indirizzi di rete o porta, potrebbe essere più difficile e potrebbe essere necessario eseguire la riga usando GLI ID pacchetto IPV4 e confrontare i payload.

Modelli da cercare nell'analisi della traccia di rete

Esaminare il modo in cui le conversazioni terminano in NETMON o WireShark. Controllare se il client e il server sono d'accordo sulla stessa cosa o se raccontano una storia diversa.

Connessione chiusa durante l'handshake SSL

Nel pacchetto ServerHello, se la suite di crittografia usata è una suite Diffie-Hellman e il traffico si trova tra Windows 2012 o versioni precedenti e Windows 2016 o versioni successive, questo algoritmo cambia a partire dalle patch di sicurezza di Windows 2016. È consigliabile disabilitare questo gruppo di pacchetti di crittografia. Per maggiori informazioni, consultare L'esperienza delle applicazioni ha chiuso forzatamente gli errori di connessione TLS durante la connessione a SQL Server in Windows.

Se la connessione viene chiusa dopo ClientHello, verificare se è presente una mancata corrispondenza tra il client e il server di TLS 1.0 o TLS 1.2. Se sono uguali, controllare le suite di crittografia abilitate e gli hash abilitati in entrambi i computer.

Per altre informazioni, vedere Advanced Secure Sockets Layer Data Capture.

Pacchetti eliminati

Visualizzare la fine delle conversazioni corrispondenti. Se uno ha molti pacchetti ritrasmessi (o 10 pacchetti Keep-Alive, a parte 1 secondo) seguiti da ACK+RESET e l'altro non segnala una risposta tempestiva e l'altra la vede ritardata e chiude o reimposta la conversazione, questo indica un problema con il dispositivo di rete e i pacchetti vengono eliminati o ritardati.

È anche possibile visualizzare il report client che indica che il server reimposta la conversazione e il report del server che indica che il client reimposta la conversazione. Ciò è dovuto a un commutatore non valido o a un router che chiude la connessione dal centro e a volte possono essere configurati per farlo se rilevano che la connessione è stata inattiva per un po', spesso ignorando i pacchetti Keep-Alive.

Per altre informazioni sulle connessioni eliminate, vedere:

Sia la traccia del server che la traccia client accettano che il problema si trova nel client

Se entrambe le tracce mostrano un ritardo o nessuna risposta sul client oppure se il client emette un ACK+RESET dopo aver riconosciuto una risposta del server o in caso contrario chiude la connessione all'inizio durante la sequenza di accesso, è necessario acquisire una traccia BID e una traccia NETSH sul client per esaminare lo stack TCP/IP e il driver. Ciò è comune se l'antivirus o altri driver di filtro di rete ritarda la ricezione del pacchetto o l'invio della risposta. I timeout di connessione possono anche essere dovuti a una risposta DNS lenta o a un'API di sicurezza lenta chiamata prima dell'invio del pacchetto SYN iniziale tramite rete.

Controllare il report delle porte temporanee di SQL Network Analyzer e assicurarsi che il client non esaurisca le porte in uscita.

Se il client ha un lungo ritardo prima di inviare il pacchetto SYN, è possibile che venga visualizzato un modello che mostra solo l'handshake di apertura TCP a 3 vie, seguito immediatamente o a volte dopo l'invio del pacchetto PreLogin, da un ACK+FIN proveniente dal client.

Raccogliere una traccia di rete e una traccia BID per isolare i problemi del client in Windows

  1. Aprire il file SQLTrace.ini e riattivare le impostazioni seguenti:

    BIDTrace=Yes, AuthTrace=Yes e EventViewer=Yes

  2. Configurare in BIDProviderList SQLTrace.ini in modo che corrisponda al driver usato dall'applicazione.

    .NET System.Data.SqlClient è abilitato per impostazione predefinita. Se non è il driver in uso, disabilitare BIDProviderList aggiungendo # alla parte anteriore della riga e rimuovendolo dall'inizio dell'elenco ODBC o OLEDB. Verranno acquisiti tutti i driver supportati di quel tipo. Per altre informazioni, vedere Configurazione INI.

  3. Salvare il file.

  4. Aprire PowerShell come amministratore e passare alla cartella contenente SQLTrace.ps1.

    CD C:\MSDATA

  5. Inizializzare il registro di traccia BID, se si raccolgono tracce BID.

    Note

    La traccia BID è abilitata per impostazione predefinita.

    .\SQLTrace.ps1 -setup

  6. Riavviare il servizio o l'applicazione di cui si esegue la traccia.

    Per alcune applicazioni, ad esempio pacchetti SQL Server Integration Services (SSIS), viene avviata una nuova istanza di DTEXEC o ISServerExec quando viene eseguito il pacchetto, quindi un riavvio non ha senso.

  7. Avviare la raccolta di tracce.

    .\SQLTrace.ps1 -start

  8. Riprodurre il problema o attendere che si verifichi l'errore.

  9. Interrompere la traccia.

    .\SQLTrace.ps1 -stop

Una cartella di output viene generata nella directory corrente ed è possibile usarla per un'ulteriore analisi.

Per tracciare altri driver di Microsoft SQL Server, vedere gli articoli seguenti. Eseguire l'esecuzione usando una traccia di rete.

Per tracciare i driver di terze parti, vedere la documentazione del fornitore.

Sia la traccia del server che la traccia client accettano che il problema si trova nel server

Se entrambe le tracce mostrano un ritardo o nessuna risposta nel server oppure se il server chiude la connessione in un punto imprevisto nella sequenza di accesso oppure se il server chiude molte connessioni contemporaneamente, ciò indica che si sono verificati alcuni problemi nel server.

Le cause più probabili sono prestazioni server scarse, MAXDOP e query parallele di grandi dimensioni e blocco. Questi possono causare la fame di thread, impedendo la gestione tempestiva di una richiesta di accesso, soprattutto se molti timeout di connessione terminano contemporaneamente e la colonna LoginAck mostra "Late". Il file ERRORLOG di SQL Server può mostrare le operazioni di I/O che richiedono più di 15 secondi, un altro indicatore dei problemi di prestazioni. Nella traccia di rete potrebbero essere visualizzate anche molte conversazioni nel report Reimposta con sei fotogrammi o meno, a indicare che l'handshake TCP a 3 vie potrebbe non essere stato completato. Per altre informazioni, vedere Raccogliere il buffer circolare della connettività.

Eseguire la RingBufferConnectivity query e incollare i risultati in Excel. Poiché si tratta di un elenco cronologico, può essere eseguito dopo che si verifica il problema. Ma per un server occupato, potrebbe terminare rapidamente. Per un server lento, potrebbero essere presenti dati per un paio di giorni.

Se l'applicazione usa mars (Multiple Active Result Sets), termina con reset come parte della sequenza di chiusura. Ciò non è dannoso se i pacchetti SMP:FIN e ACK+FIN sono già stati inviati dal client. Il pacchetto SMP:FIN del server arriverà dopo ACK+FIN dal client e Windows emetterà un ACK+RESET e quindi un reset per tutte le altre risposte del server come parte della sequenza di chiusura della connessione.

Pool di connessioni

Per altre informazioni, vedere Pool di connessioni.

Se si usa il pool di connessioni, le conversazioni nella traccia di rete in genere saranno piuttosto lunghe. È possibile usare il file CSV generato da SQL Server Network Analyzer per ordinare e filtrare in base a protocolli e frame. Probabilmente non vedrai i frame iniziali o finali se l'acquisizione di rete è inferiore a mezz'ora. Se molte conversazioni sono più brevi di 30 fotogrammi dal pacchetto SYN al pacchetto ACK+FIN, indica connessioni non in pool. Se questi sono misti con alcune conversazioni più lunghe, sospettare connessioni in background non in pool causate dall'esecuzione di comandi su una connessione non MARS durante la lettura di un set di risultati.

Il report delle porte temporanee mostrerà il numero di nuove connessioni per tutta la durata della traccia. È possibile giudicare la frequenza di connessione in base al numero di connessioni al secondo.

RESET e ACK+RESET

ACK+RESET viene in genere visualizzato quando l'applicazione o Windows interrompe una connessione. Ciò è in genere dovuto a un errore TCP di basso livello. Il pacchetto informa l'altro computer di interrompere immediatamente l'invio. Tuttavia, se il server si trova al centro della trasmissione, uno o due pacchetti possono arrivare al client dopo l'invio di ACK+RESET. Poiché la porta è chiusa, il sistema operativo invia un pacchetto RESET. Ciò si verifica anche se i pacchetti arrivano dopo il pacchetto ACK+FIN che non fa parte del normale handshake di chiusura.

Alcuni driver di terze parti inviano anche un pacchetto ACK+RESET per chiudere la connessione anziché ACK+FIN. Alcune connessioni probe possono anche eseguire questa operazione. Se il pacchetto ACK+RESET non è preceduto da pacchetti Keep-Alive, Pacchetti ritrasmessi o Pacchetti zero di Windows e proviene dal client quando è prevista una normale chiusura di ACK+FIN, potrebbe non essere dannoso.

Usare NETSTAT per analizzare i problemi di rete

NETSTAT viene raccolto automaticamente quando si esegue SQLTrace.ps1 per la raccolta dati.

In alternativa, è possibile eseguire NETSTAT -abon > c:\ports.txt al prompt dei comandi come amministratore per raccogliere informazioni correlate ai problemi di rete.

Il file ports.txt conterrà un elenco di tutte le porte in ingresso e in uscita, i numeri di porta, gli ID di processo e i nomi delle applicazioni proprietarie delle porte. È possibile usarlo per vedere i peggiori criminali e se è stato raggiunto il limite di porte. Attivare la barra di stato nel Blocco note e disattivare il ritorno a capo automatico. La barra di stato assegna un conteggio delle righe. È possibile dividere per due per ottenere un utilizzo approssimativo delle porte.

Regolare TcpTimedWaitDelay e MaxUserPort

Se un'applicazione esaurisce le porte in uscita nel computer host e non è possibile apportare modifiche immediate all'applicazione, è possibile diminuire TcpTimedWaitDelay da 240 a un minimo di 30 secondi, consentendo così il riciclo più rapido delle porte in uscita.

Per windows 2003 e versioni successive, è anche possibile aumentare .MaxUserPort Per Windows Vista e versioni successive, è possibile impostare questa impostazione tramite il NETSH comando . Questo corso di azione non elimina le inefficienze delle connessioni non in pool o delle connessioni in background non in pool e lo sviluppatore deve essere altamente incoraggiato a modificare le applicazioni per l'uso del pool di connessioni.

Per Windows 2008 e versioni successive, l'intervallo è stato aumentato da circa 4.000 porte temporanee a 16.000 porte, per impostazione predefinita.

Per altre informazioni, vedere Regolare le impostazioni MaxUserPort e TcpTimedWaitDelay.

Quasi tutti i pacchetti inviati dal client al server o al server al client vengono risposti con un pacchetto ACK che si trova nella direzione opposta. Il livello TCP.SYS genera l'ACK. Se un pacchetto viene ricevuto sul client e la traccia client lo mostra in arrivo ma non viene restituito alcun ACK al server, si tratta di una buona indicazione che l'antivirus o un altro driver di filtro di rete ha perso o eliminato il pacchetto o mantenuto su di esso per molto tempo (oltre la fine della raccolta di tracce di rete). Analogamente, se la traccia del server mostra un pacchetto proveniente da un client ma nessun ACK viene inviato al client, ciò indica che l'antivirus server nel server potrebbe avere un problema.

Tuttavia, durante il caricamento o il download di una grande quantità di dati, i pacchetti ACK possono venire dopo una serie di pacchetti di dati per facilitare il controllo del flusso.

L'antivirus e i driver di filtro sono molto difficili da dimostrare come il colpevole. Un test empirico è quasi sempre necessario. Creare un'eccezione per l'applicazione o SQL Server nell'antivirus e quindi monitorarla per 48 ore per verificare se il comportamento migliora. Se non è possibile impostare un'eccezione, disinstallare il programma antivirus e riavviare. La disabilitazione in genere non è utile perché il driver di filtro antivirus continuerà a essere caricato. Eseguire questa operazione solo come ultima risorsa se è attiva la protezione dei bordi.

Consultare gli amministratori della sicurezza di rete. Se la situazione migliora, potrebbe essere necessario collaborare con il fornitore dell'antivirus per attenuare il problema. In caso contrario, altri driver di filtro di rete potrebbero essere il colpevole.

Abilitare il controllo di Windows Firewall

Per determinare se il firewall ha eliminato pacchetti, abilitare il controllo del firewall in Windows.

Per SQL Server, questo problema potrebbe essere correlato al client o al computer server. La traccia di rete mostrerà che il computer ha ricevuto un pacchetto ma non ha risposto. Il pacchetto può quindi essere ritrasmesso, ottenere di nuovo nessuna risposta e infine la connessione viene reimpostata.

Azioni empiriche e altre

Porte temporanee

L'esaurimento delle porte temporanee è una causa relativamente comune di timeout di connessione intermittenti, soprattutto se non viene visualizzato il pacchetto SYN in transito.

Per le richieste in ingresso sul server, le porte, ad esempio 80 o 1433, possono richiedere fino a 64.000 connessioni in ingresso per ogni indirizzo IP client e sono in genere "illimitate" per tutti gli scopi pratici.

Per le connessioni in uscita, invece, il numero di porte è limitato e condiviso tra tutte le connessioni server. Per Windows Vista, Windows 2008 e versioni successive, l'intervallo predefinito è compreso tra la porta 49152 e 65535 (2^16 = 16.384 porte).

In genere, le porte vengono mantenute per quattro minuti (240 secondi) dal sistema operativo prima che vengano riciclate e possano essere riutilizzate dalle applicazioni. Ciò consente di evitare lo spoofing delle porte da parte di software dannoso o il reindirizzamento accidentale di una nuova connessione al titolare precedente di tale porta. A causa di questo ritardo, in Windows 2003, un'applicazione client può effettuare solo 17 connessioni al secondo a SQL Server e l'intervallo di porte in uscita viene esaurito in meno di quattro minuti. Per Windows Vista, tale numero aumenta a 68 connessioni al secondo.

Per le applicazioni come IIS, ogni client HTTP può avere una porta in uscita per SQL Server. Per un server Web occupato, l'esaurimento delle porte in uscita è una reale possibilità quando il carico è elevato. Una Web farm può attenuare questa situazione.

Regolare la memoria massima del server (MB)

Per risolvere i problemi relativi alla memoria kernel insufficiente, regolare la memoria massima del server (MB).

Disabilitare l'offload

A scopo di test, è possibile disabilitare l'offload tramite un prompt dei comandi amministrativo:

netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
netsh int tcp set global NetDMS=disabled
netsh int tcp set global autotuninglevel=disabled

Non mantenere queste impostazioni disabilitate per molto tempo, a meno che non possano alleviare un problema. Devono essere abilitati per impostazione predefinita in Windows 2008 e versioni successive.

Per altre operazioni di offload, è necessario passare alle proprietà della scheda di rete per visualizzarle e disabilitarle.

Problemi relativi al buffer di rete VMware

L'host ESX che contiene la macchina virtuale ha un piccolo buffer di rete che può causare problemi di affidabilità se si verifica un burst di traffico. L'articolo VMware seguente descrive come aumentare le dimensioni del buffer. Non è necessario alcun riavvio. Questa operazione deve essere eseguita nel computer host ESX, non nella macchina virtuale.

Perdita di pacchetti di grandi dimensioni nel sistema operativo guest tramite VMXNET3 in ESXi

Provare inoltre a spostare le macchine virtuali in un server host ESX diverso o spostare il client e il server nello stesso server host ESX e verificare se il problema va via. In caso affermativo, si tratta di un problema di rete di base.

Snapshot VMware

Verificare la presenza di snapshot VMware che si verificano durante l'errore e disabilitarli.

Receive Side Scaling (RSS) disabilitato nel computer host

Quando RSS è disabilitato, l'host di SQL Server usa una sola CPU per elaborare tutte le richieste di rete. Questo potrebbe picchiare la CPU al 100% e causare problemi, anche se gli altri livelli di CPU (e cpu complessiva) sono bassi.

Per altre informazioni, vedere Introduction to Receive Side Scaling and Receive Side Scaling Version 2 (RSSv2).For more information, see Introduction to Receive Side Scaling and Receive Side Scaling Version 2 (RSSv2).

Ulteriori informazioni

Problemi di autenticazione intermittenti o periodici in SQL Server

Raccogliere una traccia di rete

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