Ocorreu um erro no nível de transporte ao receber resultados do servidor [fechado]

Estou recebendo um erro do SQL Server:

Ocorreu um erro no nível de transporte ao receber resultados do servidor. (provedor: provedor de memória compartilhada, erro: 0 - o identificador é inválido.)

Estou executando o Sql Server 2008 SP1, Windows 2008 Standard de 64 bits.

É um aplicativo da web .Net 4.0. Isso acontece quando uma solicitação é feita ao servidor. É intermitente. Alguma idéia de como posso resolver isso?

A conexão com o banco de dados é fechada pelo servidor de banco de dados. A conexão permanece válida no pool de conexões do seu aplicativo; como resultado, quando você pega a cadeia de conexão compartilhada e tenta executar, ela não consegue acessar o banco de dados. Se você estiver desenvolvendo o Visual Studio, basta fechar o servidor da Web temporário na barra de tarefas.

Se isso ocorrer na produção, a redefinição do pool de aplicativos para o site deve reciclar o pool de conexões.

Tente o seguinte comando no prompt de comando:

netsh interface tcp set global autotuning=disabled

Isso desativa as habilidades de dimensionamento automático da pilha de rede

Eu tive o mesmo problema. Eu reiniciei o Visual Studio e resolvi o problema

Para aqueles que não usam o IIS, tive esse problema ao depurar com o Visual Studio 2010. Finalizei todos os processos do depurador: WebDev.WebServer40.EXE que resolveu o problema.

Erros de nível de transporte geralmente estão vinculados à conexão com o servidor sql sendo interrompida ... geralmente na rede.

O tempo limite expirado geralmente é lançado quando uma consulta sql leva muito tempo para ser executada.

Tão poucas opções podem ser:

1. Verifique a conexão na VPN (se usada) ou qualquer outra ferramenta
2. Reinicie o IIS
3. Reinicie a máquina
4. Otimize consultas sql.

Tudo o que você precisa é parar o servidor de desenvolvimento ASP.NET e executar o projeto novamente

Se você estiver conectado ao seu banco de dados via Microsoft SQL Server Management, feche todas as suas conexões e tente novamente. Este erro ocorreu quando conectado a outro banco de dados do Azure e funcionou para mim quando o fechou. Ainda não sei por que ..

Estava conseguindo isso, sempre após cerca de 5 minutos de operação. Investigamos e descobrimos que um aviso do e1iexpress sempre ocorria antes da falha. Aparentemente, isso é um erro relacionado a determinados adaptadores TCP / IP. Mas mudar de WiFi para conectado não afetou.

Então tentei o Plano B e reiniciei o Visual Studio. Então funcionou bem.

Em um estudo mais detalhado, notei que, ao funcionar corretamente, a mensagem The Thread '<No Name>' has exited with code 0ocorreu quase exatamente no momento em que a execução falhou nas tentativas anteriores. Alguns pesquisadores do Google revelam que essa mensagem aparece quando (entre outras coisas) o servidor está cortando o pool de threads.

Presumivelmente, havia um encadeamento falso no pool de encadeamentos e toda vez que o servidor tentava "apará-lo", o aplicativo era desativado.

Veja o blog do MSDN que detalha esse erro:

Removendo conexões

O pooler de conexões remove uma conexão do pool após ficar inativo por um longo período de tempo ou se o pooler detectar que a conexão com o servidor foi cortada.

Observe que uma conexão cortada pode ser detectada somente após a tentativa de comunicação com o servidor. Se for encontrada uma conexão que não está mais conectada ao servidor, ela será marcada como inválida.

As conexões inválidas são removidas do pool de conexões somente quando são fechadas ou recuperadas.

Se existir uma conexão com um servidor que desapareceu, essa conexão poderá ser estabelecida no pool, mesmo que o pooler de conexões não tenha detectado a conexão cortada e marcado como inválido.

É esse o caso, porque a sobrecarga de verificar se a conexão ainda é válida eliminaria os benefícios de ter um pooler, causando outra ocorrência de ida e volta ao servidor.

Quando isso ocorre, a primeira tentativa de usar a conexão detectará que a conexão foi cortada e uma exceção será lançada.

Basicamente, o que você está vendo é essa exceção na última frase.

Uma conexão é obtida do pool de conexões, o aplicativo não sabe que a conexão física se foi, uma tentativa de usá-la é feita sob a suposição de que a conexão física ainda está lá.

E você recebe sua exceção.

Existem alguns motivos comuns para isso.

1. O servidor foi reiniciado, isso fechará as conexões existentes.

Nesse caso, consulte o log do SQL Server, geralmente encontrado em: C: \ Arquivos de Programas \ Microsoft SQL Server \\ MSSQL \ LOG

Se o registro de data e hora da inicialização for muito recente, podemos suspeitar que foi isso que causou o erro. Tente correlacionar esse carimbo de data / hora com o horário da exceção.

2009-04-16 11: 32: 15.62 Servidor Registrando mensagens do SQL Server no arquivo 'C: \ Arquivos de Programas \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ LOG \ ERRORLOG'.

2. Alguém ou alguma coisa matou o SPID que está sendo usado.

Mais uma vez, dê uma olhada no log do SQL Server. Se você encontrar uma morte, tente correlacionar esse carimbo de data / hora com o horário da exceção.

16-04-2009 11: 34: 09.57 spidXX O ID do processo XX foi eliminado pelo nome do host xxxxx, ID do processo do host XXXX.

3. Há um failover (em uma configuração de espelho, por exemplo) novamente, consulte o log do SQL Server.

Se houver um failover, tente correlacionar esse carimbo de data / hora com o horário da exceção.

16-04-2009 11: 35: 12.93 spidXX O banco de dados espelhado “” está alterando as funções de “PRINCIPAL” para “MIRROR” devido ao Failover.

Você recebe esta mensagem quando seu script faz o Serviço SQL parar por alguns motivos. portanto, se você iniciar o SQL Service novamente, talvez seu problema seja resolvido.

Eu sei que isso pode não ajudar a todos (quem sabe, talvez sim), mas eu tive o mesmo problema e depois de algum tempo, percebemos que a causa era algo fora do próprio código.

O computador que estava tentando acessar o servidor estava em outra rede e a conexão pôde ser estabelecida, mas depois caiu.

A maneira como costumávamos corrigi-lo era adicionar uma rota estática ao computador, permitindo acesso direto ao servidor sem passar pelo firewall.

route add –p YourServerNetwork mask NetworkMask Router 

Amostra:

route add –p 172.16.12.0 mask 255.255.255.0 192.168.11.2 

Espero que ajude alguém, é melhor ter isso, pelo menos como uma pista, por isso, se você enfrentar, sabe como resolvê-lo.

Eu recebi o mesmo erro no ambiente de desenvolvimento do Visual Studion 2012, parei o IIS Express e execute novamente o aplicativo, ele começou a funcionar.

No meu caso, o serviço do servidor "SQL Server" parou. Quando reiniciei o serviço que me permitiu executar a consulta e eliminar o erro.

Também é uma boa ideia examinar sua consulta para descobrir por que a consulta interrompeu esse serviço

Eu tive o mesmo problema. Eu o resolvi, truncando o LOG do SQL Server. Verifique isso e diga-nos se esta solução o ajudou.

Para mim, a resposta é atualizar o sistema operacional de 2008R2 para 2012R2, a solução do iisreset ou reiniciar o pool de aplicativos não funcionou para mim. Também tentei desativar a configuração TCP Chimney Offload, mas não reiniciei o servidor porque é um servidor de produção, que também não funcionou.

Para mim, a solução foi totalmente diferente.

No meu caso, eu tinha uma fonte de objetos que exigia um parâmetro datetimestamp. Mesmo que o parâmetro ConvertEmptyStringToNull do ODS fosse verdadeiro, 1/1/0001 estava sendo passado para SelectMethod. Por sua vez, isso causou uma exceção de estouro de data e hora do sql quando esse horário foi passado para o servidor sql.

Adicionada uma verificação adicional para datetime.year! = 0001 e isso resolveu a questão para mim.

Estranho que isso geraria um erro de nível de transporte e não um erro de estouro de data e hora. Enfim..

Recentemente, encontramos esse erro entre o servidor comercial e o servidor de banco de dados. A solução para nós foi desativar o "IP Offloading" nas interfaces de rede. Então o erro foi embora.

Um dos motivos pelos quais encontrei esse erro é ' Tamanho do pacote = xxxxx ' na cadeia de conexão. se o valor de xxxx for muito grande, veremos esse erro. Remova esse valor e deixe o SQL Server tratá-lo ou mantê-lo baixo, dependendo dos recursos da rede.

Aconteceu comigo quando eu estava tentando restaurar um banco de dados SQL e marquei a seguinte caixa de seleção na Optionsguia

Como é um servidor de banco de dados independente, basta fechar o SSMS e reabri-lo e resolvi o problema.

Isso ocorre quando o banco de dados é descartado e recriado alguns recursos compartilhados ainda estão considerando o banco de dados ainda existente; portanto, quando você executa novamente a consulta de execução para criar tabelas no banco de dados após a recriação, o erro não será exibido novamente e a Command(s) completed successfully.mensagem será exibido em vez da mensagem de erro 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.).

Simplesmente ignore esse erro quando estiver eliminando e recriando bancos de dados e reexecutando suas consultas DDL sem preocupações.

Enfrentei o mesmo problema recentemente, mas não consegui obter resposta no google. Pensei em compartilhá-lo aqui, para que ele possa ajudar alguém no futuro.

Erro:

Durante a execução da consulta, a consulta fornecerá poucos resultados e será lançada abaixo do erro.

"Ocorreu um erro no nível de transporte ao receber a saída do servidor (TCP: provedor, erro: 0 - o nome da rede especificado não está mais disponível"

Solução:

1. Verifique o provedor desse servidor vinculado
2. Nas propriedades desse provedor, ative a opção "Permitir processo em andamento" para esse provedor específico para corrigir o problema.