sql server 2008 - una - Se ha producido un error de nivel de transporte al recibir los resultados del servidor
error en el nivel del transporte al recibir los resultados del servidor. (21)
Me aparece un error de SQL Server:
Se ha producido un error de nivel de transporte al recibir los resultados del servidor. (proveedor: Proveedor de memoria compartida, error: 0 - El identificador no es válido).
Estoy ejecutando Sql Server 2008 SP1, Windows 2008 Standard 64 bit.
Es una aplicación web .Net 4.0. Sucede cuando se realiza una solicitud al servidor. Es intermitente. ¿Alguna idea de cómo puedo resolverlo?
Estaba recibiendo esto, siempre después de aproximadamente 5 minutos de operación. Investigado y encontrado que una advertencia de e1iexpress siempre ocurrió antes del fracaso. Esto aparentemente es un error que tiene que ver con ciertos adaptadores TCP / IP. Pero cambiar de WiFi a cableado no lo afectó.
Así que probé Plan B y reinicié Visual Studio. Entonces funcionó bien.
En un estudio más detallado noté que, cuando funcionaba correctamente, el mensaje The Thread ''<No Name>'' has exited with code 0 ocurrido casi exactamente en el momento en que la ejecución se bloqueó en intentos anteriores. Algunas búsquedas en Google revelan que ese mensaje aparece cuando (entre otras cosas) el servidor está recortando el grupo de subprocesos.
Es de suponer que había un hilo falso en el grupo de subprocesos y cada vez que el servidor intentaba "recortarlo", bajaba la aplicación.
Esto ocurre cuando la base de datos se descarta y se vuelve a crear. Algunos recursos compartidos aún consideran que la base de datos aún existe, por lo que cuando vuelva a ejecutar la ejecución de la consulta para crear tablas en la base de datos después de volver a crearse, el error no volverá a aparecer y Command(s) completed successfully. aparecerá un mensaje en lugar del mensaje de error 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.) 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.) .
Simplemente ignore este error cuando esté abandonando y recreando bases de datos y vuelva a ejecutar sus consultas DDL sin preocupaciones.
La conexión de la base de datos está cerrada por el servidor de la base de datos. La conexión sigue siendo válida en el grupo de conexiones de su aplicación; como resultado, cuando recoges la cadena de conexión compartida e intentas ejecutarla, no puede llegar a la base de datos. Si está desarrollando Visual Studio, simplemente cierre el servidor web temporal en su barra de tareas.
Si ocurre en la producción, restablecer el grupo de aplicaciones para su sitio web debe reciclar el grupo de conexiones.
Los errores de nivel de transporte a menudo están vinculados a la conexión al servidor sql que se rompe ... generalmente a la red.
El tiempo de espera expirado generalmente se genera cuando una consulta sql tarda demasiado en ejecutarse.
Muy pocas opciones pueden ser:
- Verifique la conexión en VPN (si se usa) o cualquier otra herramienta
- Reiniciar IIS
- Reiniciar la máquina
- Optimizar consultas SQL
Me enfrenté al mismo problema recientemente, pero no pude obtener una respuesta en Google. Así que pensé en compartirlo aquí, para que pueda ayudar a alguien en el futuro.
Error:
Mientras se ejecuta la consulta, la consulta proporcionará pocos resultados y arrojará el siguiente error.
"Error de nivel de transporte al recibir el resultado del servidor (TCP: proveedor, error: el nombre de red especificado 0 ya no está disponible"
Solución:
- Compruebe el proveedor de ese servidor vinculado
- En las propiedades de ese proveedor, habilite la opción "Permitir en el proceso" para que ese proveedor en particular resuelva el problema.
Mire el blog de MSDN que detalla este error:
Eliminar conexiones
El conjunto de conexiones elimina una conexión del grupo después de que ha estado inactiva durante mucho tiempo, o si el grupo de servidores detecta que la conexión con el servidor se ha cortado.
Tenga en cuenta que una conexión cortada solo se puede detectar después de intentar comunicarse con el servidor. Si se encuentra una conexión que ya no está conectada al servidor, se marca como no válida.
Las conexiones no válidas se eliminan del grupo de conexiones solo cuando se cierran o recuperan.
Si existe una conexión con un servidor que ha desaparecido, esta conexión puede extraerse del grupo incluso si el grupo de conexión no ha detectado la conexión cortada y la ha marcado como no válida.
Este es el caso porque la sobrecarga de verificar que la conexión sigue siendo válida eliminaría los beneficios de tener un colector haciendo que se produzca otro viaje de ida y vuelta al servidor.
Cuando esto ocurre, el primer intento de utilizar la conexión detectará que la conexión se ha cortado y se lanzará una excepción.
Básicamente, lo que estás viendo es esa excepción en la última oración.
Se toma una conexión del grupo de conexiones, la aplicación no sabe que la conexión física se ha ido, un intento de usarla se realiza bajo la suposición de que la conexión física todavía está allí.
Y obtienes tu excepción.
Hay algunas razones comunes para esto.
- El servidor se ha reiniciado, esto cerrará las conexiones existentes.
En este caso, eche un vistazo al registro de SQL Server, que generalmente se encuentra en: C: / Archivos de programa / Microsoft SQL Server // MSSQL / LOG
Si la marca de tiempo para el inicio es muy reciente, entonces podemos sospechar que esto fue lo que causó el error. Intente correlacionar esta marca de tiempo con el momento de la excepción.
2009-04-16 11: 32: 15.62 Registro de servidor Mensajes de SQL Server en el archivo ''C: / Archivos de programa / Microsoft SQL Server / MSSQL.1 / MSSQL / LOG / ERRORLOG''.
- Alguien o algo ha matado al SPID que se está utilizando.
De nuevo, eche un vistazo en el registro de SQL Server. Si encuentra una muerte, intente correlacionar esta marca de tiempo con la hora de la excepción.
2009-04-16 11: 34: 09.57 spidXX Proceso ID XX fue asesinado por nombre de host xxxxx, proceso de host ID XXXX.
- Hay una conmutación por error (en una configuración espejo, por ejemplo) de nuevo, eche un vistazo en el registro de SQL Server.
Si hay una conmutación por error, intente correlacionar esta marca de tiempo con el momento de la excepción.
2009-04-16 11: 35: 12.93 spidXX La base de datos duplicada "" está cambiando los roles de "PRINCIPAL" a "ESPEJO" debido a la conmutación por error.
Obtuve el mismo error en el entorno de desarrollo de Visual Studio 2012, detuve IIS Express y volví a ejecutar la aplicación, comenzó a funcionar.
Para aquellos que no usan IIS, tuve este problema al depurar con Visual Studio 2010. Terminé todos los procesos de depuración: WebDev.WebServer40.EXE que resolvió el problema.
Para mí, la respuesta es actualizar el sistema operativo de 2008R2 a 2012R2, la solución de iisreset o reiniciar el grupo de aplicaciones no funcionó para mí. También intenté desactivar la configuración de descarga de la Chimenea TCP, pero no reinicié el servidor porque es un servidor de producción, que tampoco funcionaba.
Para mí, la solución fue totalmente diferente.
En mi caso, tenía una fuente de objetos que requería un parámetro datetimestamp. Aunque el parámetro ODS ConvertEmptyStringToNull era verdadero, el 1/1/0001 se pasaba a SelectMethod. A su vez, esto provocó una excepción de desbordamiento de fecha y hora de sql cuando esa fecha y hora se pasó al servidor sql.
Agregué un cheque adicional para datetime.year! = 0001 y eso lo resolvió para mí.
Es extraño que arroje un error de nivel de transporte y no un error de desbordamiento de fecha y hora. De todos modos ..
Pruebe el siguiente comando en el símbolo del sistema:
netsh interface tcp set global autotuning=disabled
Esto desactiva las capacidades de escalado automático de la pila de red
Recibes este mensaje cuando tu script hace que el servicio SQL se detenga por alguna razón. entonces, si inicia SQL Service de nuevo, tal vez su problema se resuelva.
Recientemente encontramos este error entre nuestro servidor comercial y nuestro servidor de base de datos. La solución para nosotros fue desactivar la "descarga de IP" en las interfaces de red. Entonces el error desapareció.
Sé que esto puede no ayudar a todos (quién sabe, quizás sí), pero tuve el mismo problema y después de un tiempo, nos dimos cuenta de que la causa era algo fuera del código en sí.
La computadora que intentaba llegar al servidor estaba en otra red, la conexión se pudo establecer pero luego se eliminó.
La forma en que solíamos arreglarlo era agregar una ruta estática a la computadora, lo que permitía el acceso directo al servidor sin pasar por el firewall.
route add –p YourServerNetwork mask NetworkMask Router
Muestra:
route add –p 172.16.12.0 mask 255.255.255.0 192.168.11.2
Espero que ayude a alguien, es mejor tener esto, al menos como pista, así que si lo enfrentas, sabes cómo resolverlo.
Si está conectado a su base de datos a través de Microsoft SQL Server Management, cierre todas sus conexiones y vuelva a intentarlo. Tuve este error cuando me conecté a otra base de datos de Azure, y funcionó para mí cuando lo cerré. Todavía no sé por qué ...
Todo lo que necesita es detener el servidor de desarrollo ASP.NET y ejecutar el proyecto nuevamente
Tuve el mismo problema. Lo resolví, truncando el SQL Server LOG. Verifique eso y cuéntenos si esta solución lo ayudó.
Una de las razones que encontré para este error es '' Packet Size = xxxxx '' en la cadena de conexión. si el valor de xxxx es demasiado grande, veremos este error. Elimine este valor y permita que el servidor SQL lo maneje o lo mantenga bajo, dependiendo de las capacidades de la red.
Yo tuve el mismo problema. Reinicié Visual Studio y eso solucionó el problema