source ejemplo data connectionstring c# sql-server tsql ado.net sql-server-2000

c# - ejemplo - data source sql server



¿Cómo maneja los errores de nivel de transporte en SqlConnection? (12)

De vez en cuando, en una aplicación .NET de alto volumen, es posible que vea esta excepción cuando intente ejecutar una consulta:

System.Data.SqlClient.SqlException: se ha producido un error de nivel de transporte al enviar la solicitud al servidor.

Según mi investigación, esto es algo que "simplemente sucede" y no se puede hacer mucho para prevenirlo. No sucede como resultado de una mala consulta, y generalmente no se puede duplicar. Simplemente surge una vez cada pocos días en un sistema OLTP ocupado cuando la conexión TCP a la base de datos falla por alguna razón.

Me veo obligado a detectar este error analizando el mensaje de excepción y luego volviendo a intentar toda la operación desde cero, para incluir el uso de una nueva conexión. Nada de eso es bonito.

¿Alguien tiene alguna solución alternativa?

He visto esto suceder en mi propio entorno varias veces. La aplicación cliente en este caso está instalada en muchas máquinas. Algunas de esas máquinas son computadoras portátiles, la gente deja la aplicación abierta desconectándola y luego conectándola de nuevo e intentando usarla. Esto provocará el error que ha mencionado.

Mi primer punto sería mirar la red y asegurar que los servidores no estén en DHCP y renovar las direcciones IP que causan este error. Si ese no es el caso, entonces tiene que comenzar a atravesar los registros de eventos buscando otras redes relacionadas.

Desafortunadamente es como se indicó anteriormente un error de red. Lo principal que puedes hacer es simplemente monitorear las conexiones usando una herramienta como netmon y trabajar desde allí.

Buena suerte.

Estoy usando una capa de confiabilidad alrededor de mis comandos DB (abstraída en la interfaz del repositorio). Básicamente es solo código que intercepta cualquier excepción esperada (DbException y también InvalidOperationException, que sucede por problemas de conectividad), lo registra, captura estadísticas y vuelve a intentar todo nuevamente.

Con esa capa de confiabilidad presente, el servicio ha sido capaz de sobrevivir a pruebas de estrés de manera elegante (bloqueos muertos constantes, fallas de red, etc.). La producción es mucho menos hostil que eso.

PD: Aquí hay más sobre eso (junto con una manera simple de definir la confiabilidad con la interceptación DSL)

Para responder a su pregunta original:

Una manera más elegante de detectar este error en particular, sin analizar el mensaje de error, es inspeccionar la propiedad Number de SqlException .

(Esto realmente devuelve el número de error del primer SqlError en la colección Errors , pero en su caso el error de transporte debería ser el único en la colección).

Yo tuve el mismo problema. Le pregunté a mis amigos geek de la red, y todos dijeron lo que las personas han respondido aquí: es la conexión entre la computadora y el servidor de la base de datos. En mi caso, fue mi proveedor de servicios de Internet, o el enrutador ese el problema. Después de una actualización de enrutador, el problema desapareció. Pero, ¿tiene algún otro problema de conexión a Internet de su computadora o servidor? Tuve...

Tuve el mismo problema, aunque fue con las solicitudes de servicio a una base de datos SQL.

Esto es lo que tenía en mi registro de errores de servicio:

System.Data.SqlClient.SqlException: se ha producido un error de nivel de transporte al enviar la solicitud al servidor. (provider: TCP Provider, error: 0 - Una conexión existente fue cerrada a la fuerza por el host remoto.)

Tengo un conjunto de pruebas de C # que prueba un servicio. El servicio y DB estaban en servidores externos, así que pensé que ese podría ser el problema. Así que implementé el servicio y DB localmente en vano. El problema continuó. El conjunto de pruebas ni siquiera es una prueba de rendimiento apremiante, así que no tenía idea de lo que estaba sucediendo. La misma prueba fallaba cada vez, pero cuando deshabilitaba esa prueba, otra fallaba continuamente.

Intenté con otros métodos sugeridos en Internet que tampoco funcionaron:

  • Aumente los valores de registro de TcpMaxDataRetransmissions y TcpMaxConnectRetransmissions .
  • Desactive la opción "Memoria compartida" dentro del Administrador de configuración de SQL Server en "Protocolos de cliente" y clasifique TCP / IP en el 1er lugar de la lista.
  • Esto puede ocurrir cuando prueba la escalabilidad con una gran cantidad de intentos de conexión del cliente. Para resolver este problema, utilice la utilidad regedit.exe para agregar un nuevo valor DWORD llamado SynAttackProtect a la clave de registro HKEY_LOCAL_MACHINE / SYSTEM / CurrentControlSet / Services / Tcpip / Parameters / con datos de valor de 00000000.

Mi último recurso fue utilizar la vejez diciendo "Intenta y vuelve a intentarlo". Así que he anidado las declaraciones try-catch para asegurarme de que si la conexión TCP / IP se pierde en el protocolo de comunicaciones inferior, no se da por vencido, sino que lo intenta de nuevo. Esto ahora me funciona, sin embargo, no es una solución muy elegante.

use Enterprise Services con componentes transaccionales

Por lo que puedo decir, la clase 20 es el nivel de transporte.

Experimenté el error de transporte esta mañana en SSMS mientras estaba conectado a SQL 2008 R2 Express.

Estaba intentando importar un archivo CSV con / r / n. Codifiqué mi terminador de fila para 0x0d0x0a. Cuando lo cambié a 0x0a, el error se detuvo. Puedo cambiarlo de un lado a otro y verlo suceder / no suceder.

BULK INSERT #t1 FROM ''C:/123/Import123.csv'' WITH ( FIRSTROW = 1, FIELDTERMINATOR = '','', ROWTERMINATOR = ''0x0d0x0a'' )

Sospecho que no estoy escribiendo correctamente mi terminador de fila porque SQL analiza un carácter a la vez, mientras trato de pasar dos caracteres.

De todos modos, este error tiene 4 años ahora, pero puede proporcionar un poco de información para el próximo usuario.

Solo quería publicar una solución aquí que funcionó para nuestra empresa en el nuevo software que hemos instalado. Recibimos el siguiente error desde el día 1 en el archivo de registro del cliente: El servidor no pudo procesar la solicitud. ---> Se ha producido un error de nivel de transporte al recibir resultados del servidor. (provider: TCP Provider, error: 0 - El período de tiempo de espera del semáforo ha expirado.) ---> El período de tiempo de espera del semáforo ha expirado.

Lo que solucionó completamente el problema fue configurar un agregado de enlace (LAG) en nuestro conmutador. Nuestro servidor Dell FX1 tiene líneas de fibra redundantes que salen de la parte posterior. No nos dimos cuenta de que el interruptor en el que están enchufados necesitaba tener un LAG configurado en esos dos puertos. Ver detalles aquí: https://docs.meraki.com/display/MS/Switch+Ports#SwitchPorts-LinkAggregation

Publiqué una respuesta a otra pregunta sobre otro tema que podría ser útil aquí. Esa respuesta involucraba conexiones SMB, no SQL. Sin embargo, era idéntico en que implicaba un error de transporte de bajo nivel.

Lo que encontramos fue que en una situación de carga pesada, era bastante fácil para el servidor remoto agotar las conexiones en la capa TCP simplemente porque el servidor estaba ocupado. Parte de la razón fue que el número predeterminado de veces que TCP retransmitiría datos en Windows no era apropiado para nuestra situación.

Eche un vistazo a la configuración del registro para sintonizar TCP / IP en Windows. En particular, desea ver TcpMaxDataRetransmissions y tal vez TcpMaxConnectRetransmissions . Estos valores predeterminados son 5 y 2 respectivamente, intente subirlos un poco en el sistema cliente y duplicar la situación de carga.

No te vuelvas loco! TCP duplica el tiempo de espera con cada retransmisión sucesiva, por lo que el comportamiento de tiempo de espera para las conexiones incorrectas puede ser exponencial si usted las aumenta demasiado. Como recuerdo, el aumento de TcpMaxDataRetransmissions a 6 o 7 resolvió nuestro problema en la gran mayoría de los casos.