Comment traitez-vous au niveau du transport des erreurs dans SqlConnection?
Chaque maintenant et puis dans un volume élevé .NET application, vous pouvez voir cette exception lorsque vous essayez d'exécuter une requête:
Système.Les données.SqlClient.SqlException: Une erreur de niveau transport a
s'est produite lors de l'envoi de la requête vers le serveur.
D'après mes recherches, c'est quelque chose que "ça arrive" et pas beaucoup peut être fait pour l'empêcher. Il ne se passe pas comme un résultat d'une mauvaise requête, et ne peuvent généralement pas être dupliqué. Il a juste les cultures en place, peut-être une fois tous les quelques jours dans un lieu occupé OLTP système lors de la connexion TCP à la base de données va mal pour une raison quelconque.
Je suis forcé de détecter cette erreur par l'analyse du message de l'exception, et puis de retenter l'ensemble de l'opération à partir de zéro, à inclure l'utilisation d'une nouvelle connexion. Rien de tout cela est joli.
Quelqu'un a des solutions de rechange?
- Avez-vous des statistiques pour la charge sur votre serveur de base de données lorsque ces erreurs sont jetés? Vous pourriez avoir quelques problèmes de base de données qui sont à l'origine des connexions à l'échec.
- Cela ne devrait pas arriver, même en cas de fort volume transactionnel. Nous avons une moyenne de 25 000 transactions par seconde sur SQL Server 2005 Standard, et nous n'obtenons pas cette erreur. (À moins que le cluster de basculement, qui est tous les 12 mois et+, pas tous les quelques jours.) Sans plus d'info, ça sonne comme il est un problème de réseau entre votre serveur de base de données et serveurs d'application. Pouvez-vous poster plus d'info?
- Je soupçonne que c'est en raison de la merde à bord de Dell NIC, je suis obligé d'utiliser depuis mes deux slots PCIe sont pris avec des cartes HBA connecté à mon DAS. Je me suis mise à niveau vers une plus grande machine donc je peux adapter le (beaucoup) mieux NIC Intel. Comment êtes-vous clustering avec l'Édition Standard? C'est une Édition Entreprise fonctionnalité.
- le clustering, l'envoi de journaux, et de la mise en miroir sont tous disponibles en Standard. http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx
- Aussi loin que je peux dire, la classe 20 est au niveau transport.
Vous devez vous connecter pour publier un commentaire.
J'ai posté une réponse à une autre question sur un autre sujet qui pourrait avoir une certaine utilité ici. Cette réponse impliqués connexions SMB, pas SQL. Cependant, il est identique en ce qu'il comportait un faible niveau d'erreur de transport.
Ce que nous avons trouvé était que, dans une situation de charge importante, il était relativement facile pour le serveur distant en temps de connexions au niveau de la couche TCP tout simplement parce que le serveur est occupé. Partie de la raison en était que les valeurs par défaut pour combien de temps TCP retransmet les données sur Windows ne sont pas adaptés à notre situation.
Prendre un coup d'oeil à la les paramètres du registre pour le paramétrage TCP/IP sur Windows. En particulier, vous voulez regarder TcpMaxDataRetransmissions et peut-être TcpMaxConnectRetransmissions. Valeur par défaut: 5 et 2 respectivement, essayez de monter un peu sur le système client et le double de la charge de la situation.
Ne pas devenir fou! TCP double le délai d'attente à chaque retransmission, de sorte que le délai de comportement pour de mauvaises connexions peuvent aller exponentielle sur vous si vous augmentez ces trop. Je me souviens de monter TcpMaxDataRetransmissions à 6 ou 7 résolu notre problème dans la grande majorité des cas.
Ce post de blog par Michael Aspengren explique le message d'erreur "Une erreur de niveau transport s'est produite lors de l'envoi de la requête vers le serveur."
Pour répondre à votre question initiale:
Une façon plus élégante de détecter cette erreur particulière, sans analyse le message d'erreur, est d'inspecter la
Numberpropriété de laSqlException.(En fait, cela retourne le numéro d'erreur de la première
SqlErrordans leErrorscollection, mais dans votre cas, l'erreur de transport doit être le seul de la collection).utilisation des Services de l'Entreprise avec les composants transactionnels
J'ai vu cela se produire dans mon propre environnement un certain nombre de fois. L'application cliente dans ce cas est installé sur de nombreuses machines. Certaines de ces machines se trouvent être les ordinateurs portables de gens ont été en laissant l'application, ouvrez le débrancher puis de le rebrancher et d'essayer de l'utiliser. Ce sera alors la cause de l'erreur que vous avez mentionnés.
Mon premier point serait de regarder le réseau et de s'assurer que les serveurs ne sont pas sur le DHCP et le renouvellement des Adresses IP à l'origine de ce message d'erreur. Si ce n'est pas le cas, alors vous devez commencer à trawlling à travers les journaux d'événements, à la recherche pour le réseau.
Malheureusement, il est comme indiqué ci-dessus, une erreur de réseau. La principale chose que vous pouvez faire est de surveiller les connexions à l'aide d'un outil comme netmon et travail en arrière à partir de là.
Bonne Chance.
Vous devriez également vérifier le matériel de la connectivité à la base de données.
Peut-être ce fil sera utile:
http://channel9.msdn.com/forums/TechOff/234271-Conenction-forcibly-closed-SQL-2005/
Je suis à l'aide de la fiabilité de la couche autour de ma DB commandes (disparaît dans le référentiel interfaece). Fondamentalement, c'est juste le code qui intercepte tout prévu exception (DbException et aussi InvalidOperationException, qui se jettent sur les problèmes de connectivité), il enregistre, enregistre les statistiques et les tentatives de tout nouveau.
Avec que la fiabilité de la couche actuelle, le service a été en mesure de survivre au stress-tests gracieusement (constante de dead-locks, les pannes de réseau, etc). La Production est beaucoup moins hostile que cela.
PS: Il n'y a plus à ce sujet ici (avec un moyen simple de définir la fiabilité avec l'interception DSL)
J'ai eu le même problème. J'ai demandé à mon réseau geek amis, et de tous dit ce que les gens ont répondu ici: Son la connexion entre l'ordinateur et le serveur de base de données. Dans mon cas, c'était mon Fournisseur de Services Internet, ou il y a un routeur qui était le problème. Après un Routeur de mise à jour, le problème a disparu. Mais avez-vous d'autres abandons de connexion internet depuis votre ordinateur ou le serveur? J'ai eu...
J'ai eu le même problème mais c'est avec les demandes de service pour SQL DB.
C'est ce que j'ai eu dans mon service journal des erreurs:
Système.Les données.SqlClient.SqlException: Un niveau transport erreur s'est produite lors de l'envoi de la requête vers le serveur. (fournisseur: Fournisseur TCP, erreur: 0 - Une connexion existante a dû être fermée par l'hôte distant.)
J'ai un C# suite de test qui teste un service. Le service de base de données et ont été à la fois sur des serveurs externes, alors j'ai pensé que peut-être la question. J'ai donc déployé le service de base de données et localement en vain. Le problème continue. La suite de test n'est même pas un dur en appuyant sur test de performance à tous, donc je n'avais aucune idée de ce qui se passait. Le même test a échoué à chaque fois, mais quand j'ai désactivé ce test, un autre échec en permanence.
J'ai essayé d'autres méthodes proposées sur l'Internet qui ne fonctionne pas non plus:
Mon dernier recours était d'utiliser la vieillesse en disant: "Essayer encore et encore". J'ai donc imbriquée try-catch états à s'assurer que si le protocole TCP/IP de la connexion est perdue dans le bas du protocole de communication qu'il ne donnez pas simplement là-haut, mais essaie de nouveau. C'est maintenant à travailler pour moi, mais ce n'est pas très élégant.
J'ai vécu le transport d'erreur ce matin dans SSMS, tout en étant connecté à SQL 2008 R2 Express.
J'ai essayé d'importer un fichier CSV avec \r\n. J'ai codé mon indicateur de fin de ligne pour 0x0d0x0a. Quand je l'ai changé pour 0x0a, l'erreur s'est arrêté. Je peux le changer en arrière et regarder passer/ne pas se produire.
Je pense que je n'écris pas ma marque de fin de ligne correctement parce que SQL analyse d'un caractère à la fois à droite alors que je suis en train de passer deux personnages.
En tout cas, cette erreur est de 4 ans maintenant, mais il peut donner un peu d'information pour le prochain utilisateur.
Je voulais juste poster un correctif ici qui ont travaillé pour notre société sur un nouveau logiciel que nous avons installé. Nous avons été l'erreur suivante se produit depuis le jour 1 sur le fichier journal client: Serveur n'a pas pu traiter la demande. ---> Une erreur de niveau transport a eu lieu lors de la réception des résultats à partir du serveur. (fournisseur: Fournisseur TCP, erreur: 0 - Le délai de temporisation de sémaphore a expiré.) ---> Le délai de temporisation de sémaphore a expiré.
Ce que complètement résolu le problème était de mettre en place un lien globale (GAL) sur notre switch. Nos Dell FX1 serveur a la fibre redondante lignes venant de l'arrière. Nous n'avons pas réalisé que le commutateur ils sont connectés au besoin d'avoir un temps de retard configuré sur ces deux ports. Voir plus de détails ici: https://docs.meraki.com/display/MS/Switch+Ports#SwitchPorts-LinkAggregation