Si è verificato un errore a livello di trasporto durante la ricezione dei risultati dal server [chiuso]

Ricevo un errore di SQL Server:

Si è verificato un errore a livello di trasporto durante la ricezione dei risultati dal server. (provider: provider di memoria condivisa, errore: 0 - l'handle non è valido.)

Sto eseguendo SQL Server 2008 SP1, Windows 2008 Standard 64 bit.

È un'applicazione web .Net 4.0. Succede quando viene fatta una richiesta al server. È intermittente. Qualche idea su come posso risolverlo?

La connessione al database è chiusa dal server del database. La connessione rimane valida nel pool di connessioni della tua app; di conseguenza, quando si preleva la stringa di connessione condivisa e si tenta di eseguire, non è in grado di raggiungere il database. Se stai sviluppando Visual Studio, chiudi semplicemente il web server temporaneo sulla barra delle attività.

Se ciò accade durante la produzione, il ripristino del pool di applicazioni per il sito Web dovrebbe riciclare il pool di connessioni.

Prova il seguente comando sul prompt dei comandi:

netsh interface tcp set global autotuning=disabled

Ciò disattiva le capacità di ridimensionamento automatico dello stack di rete

Ho avuto lo stesso problema. Ho riavviato Visual Studio e questo ha risolto il problema

Per coloro che non utilizzano IIS, ho riscontrato questo problema durante il debug con Visual Studio 2010. Ho terminato tutti i processi di debug: WebDev.WebServer40.EXE che ha risolto il problema.

Gli errori a livello di trasporto sono spesso collegati alla rottura della connessione al server sql ... di solito rete.

Il timeout scaduto viene in genere generato quando l'esecuzione di una query sql richiede troppo tempo.

Quindi poche opzioni possono essere:

1. Controlla la connessione in VPN (se utilizzata) o in qualsiasi altro strumento
2. Riavvia IIS
3. Riavvia la macchina
4. Ottimizza le query sql.

Tutto ciò che serve è arrestare ASP.NET Development Server ed eseguire nuovamente il progetto

Se si è connessi al database tramite Microsoft SQL Server Management, chiudere tutte le connessioni e riprovare. Ha avuto questo errore quando è stato collegato a un altro database di Azure e ha funzionato per me quando è stato chiuso. Ancora non so perché ...

Stavo ottenendo questo, sempre dopo circa 5 minuti di funzionamento. Indagato e scoperto che un avviso da e1iexpress si verificava sempre prima del fallimento. Questo a quanto pare è un errore relativo a determinati adattatori TCP / IP. Ma il passaggio da WiFi a cablato non ha influito.

Quindi ho provato Plan B e riavviato Visual Studio. Quindi ha funzionato bene.

A uno studio più attento, ho notato che, quando funzionava correttamente, il messaggio si The Thread '<No Name>' has exited with code 0verificava quasi esattamente nel momento in cui la corsa si era bloccata nei precedenti tentativi. Alcuni googling rivelano che quel messaggio appare quando (tra le altre cose) il server sta tagliando il pool di thread.

Presumibilmente c'era un thread fasullo nel pool di thread e ogni volta che il server ha tentato di "tagliare", ha bloccato l'app.

Guarda il blog MSDN che descrive in dettaglio questo errore:

Rimozione delle connessioni

Il pool di connessioni rimuove una connessione dal pool dopo che è rimasto inattivo per lungo tempo o se il pooler rileva che la connessione con il server è stata interrotta.

Si noti che una connessione interrotta può essere rilevata solo dopo aver tentato di comunicare con il server. Se viene rilevata una connessione che non è più connessa al server, viene contrassegnata come non valida.

Le connessioni non valide vengono rimosse dal pool di connessioni solo quando vengono chiuse o recuperate.

Se esiste una connessione a un server che è scomparso, questa connessione può essere disegnata dal pool anche se il pool di connessioni non ha rilevato la connessione interrotta e l'ha contrassegnata come non valida.

Questo è il caso perché il sovraccarico di verificare che la connessione sia ancora valida eliminerebbe i vantaggi di avere un pooler causando un altro round trip al server.

In questo caso, il primo tentativo di utilizzare la connessione rileverà che la connessione è stata interrotta e viene generata un'eccezione.

Fondamentalmente quello che stai vedendo è quell'eccezione nell'ultima frase.

Viene presa una connessione dal pool di connessioni, l'applicazione non è a conoscenza del fatto che la connessione fisica sia sparita, un tentativo di usarla si presuppone che la connessione fisica sia ancora presente.

E ottieni la tua eccezione.

Ci sono alcuni motivi comuni per questo.

1. Il server è stato riavviato, questo chiuderà le connessioni esistenti.

In questo caso, dai un'occhiata al registro di SQL Server, generalmente disponibile in: C: \ Programmi \ Microsoft SQL Server \\ MSSQL \ LOG

Se il timestamp per l'avvio è molto recente, allora possiamo sospettare che questo sia ciò che ha causato l'errore. Prova a correlare questo timestamp con il tempo di eccezione.

16-04-2009 11: 32: 15.62 Server Registrazione dei messaggi di SQL Server nel file "C: \ Programmi \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ LOG \ ERRORLOG".

2. Qualcuno o qualcosa ha ucciso lo SPID in uso.

Ancora una volta, dai un'occhiata al registro di SQL Server. Se trovi un kill, prova a correlare questo timestamp con il tempo di eccezione.

16-04-2009 11: 34: 09.57 L'ID processo spidXX XX è stato ucciso dal nome host xxxxx, ID processo host XXXX.

3. C'è di nuovo un failover (ad esempio in una configurazione mirror), dai un'occhiata al registro di SQL Server.

In caso di failover, provare a correlare questo timestamp con l'ora dell'eccezione.

16-04-2009 11: 35: 12.93 spidXX Il database con mirroring “” sta cambiando i ruoli da “PRINCIPALE” a “SPECCHIO” a causa del Failover.

Questo messaggio viene visualizzato quando lo script fa arrestare il servizio SQL per alcuni motivi. quindi se riavvii il servizio SQL forse il tuo problema verrà risolto.

So che questo potrebbe non aiutare tutti (chissà, forse sì), ma ho avuto lo stesso problema e dopo qualche tempo, ci siamo resi conto che la causa era qualcosa fuori dal codice stesso.

Il computer che cercava di raggiungere il server, si trovava in un'altra rete, la connessione poteva essere stabilita ma poi interrotta.

Il modo in cui lo risolvevamo era quello di aggiungere una route statica al computer, consentendo l'accesso diretto al server senza passare attraverso il firewall.

route add –p YourServerNetwork mask NetworkMask Router 

Campione:

route add –p 172.16.12.0 mask 255.255.255.0 192.168.11.2 

Spero che aiuti qualcuno, è meglio avere questo, almeno come un indizio, quindi se lo affronti, sai come risolverlo.

Ho riscontrato lo stesso errore nell'ambiente di sviluppo di Visual Studion 2012, ho bloccato IIS Express e rieseguito l'applicazione, ha iniziato a funzionare.

Nel mio caso il servizio server "SQL Server" si è interrotto. Quando ho riavviato il servizio che mi ha permesso di eseguire la query ed eliminare l'errore.

È anche una buona idea esaminare la query per scoprire perché la query ha interrotto questo servizio

Ho avuto lo stesso problema. L'ho risolto troncando il LOG di SQL Server. Controlla di farlo, e poi dicci se questa soluzione ti ha aiutato.

Per me la risposta è aggiornare il sistema operativo da 2008R2 a 2012R2, la soluzione di iisreset o il riavvio di apppool non ha funzionato per me. Ho anche provato a disattivare l'impostazione TCP Chimney Offload, ma non ho riavviato il server perché è un server di produzione, che non ha funzionato.

Per me la soluzione era totalmente diversa.

Nel mio caso avevo una fonte di oggetti che richiedeva un parametro datetimestamp. Anche se quel parametro ODS ConvertEmptyStringToNull era vero, 1/1/0001 veniva passato a SelectMethod. Ciò a sua volta ha causato un'eccezione di overflow del datetime sql quando quel datetime è stato passato al server sql.

Aggiunto un ulteriore controllo per datetime.year! = 0001 e questo lo ha risolto per me.

Strano che genererebbe un errore a livello di trasporto e non un errore di overflow del datetime. In ogni modo ..

Di recente abbiamo riscontrato questo errore tra il nostro server aziendale e il nostro server di database. La soluzione per noi era disabilitare "Offloading IP" sulle interfacce di rete. Quindi l'errore è scomparso.

Uno dei motivi per cui ho riscontrato questo errore è " Dimensione pacchetto = xxxxx " nella stringa di connessione. se il valore di xxxx è troppo grande, vedremo questo errore. Rimuovere questo valore e lasciare che il server SQL lo gestisca o lo mantenga basso, a seconda delle funzionalità di rete.

Mi è successo quando stavo cercando di ripristinare un database SQL e ho controllato la casella di controllo nella Optionsscheda,

Dato che è un server di database autonomo, chiudere SSMS e riaprirlo ha risolto il problema per me.

Ciò si verifica quando il database viene eliminato e ricreato alcune risorse condivise stanno ancora considerando che il database esiste ancora, quindi quando si esegue nuovamente eseguire la query per creare tabelle nel database dopo che è stato ricreato, l'errore non verrà più visualizzato e il Command(s) completed successfully.messaggio mostrerà invece del messaggio di errore Msg 233, Level 20, State 0, Line 0 A transport-level error has occurred when sending the request to the server. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe.).

Ignora semplicemente questo errore quando elimini e ricrea i database e riesegui le tue query DDL senza preoccupazioni.

Di recente ho riscontrato lo stesso problema, ma non sono stato in grado di ottenere risposta su Google. Quindi ho pensato di condividerlo qui, in modo che possa aiutare qualcuno in futuro.

Errore:

Durante l'esecuzione della query, la query fornirà pochi output, quindi genererà un errore inferiore.

"Si è verificato un errore a livello di trasporto durante la ricezione dell'output dal server (TCP: provider, errore: 0- il nome di rete specificato non è più disponibile"

Soluzione:

1. Controllare il provider di quel server collegato
2. Nelle proprietà del provider, abilita l'opzione "Consenti in-process" per quel determinato provider per risolvere il problema.