web-dev-qa-db-fra.com

Comment déterminer la cause première de l'échec de la liaison de communication TCP Provider: le nom de réseau spécifié n'est plus disponible?

Voici mon dernier effort pour réviser cette question. Mais cette fois, j'essaie de suivre les bons conseils donnés par Oded dans son article Obtenir de bonnes réponses sur StackOverflow .

J'ai besoin de savoir comment je peux déterminer la cause première de l'erreur suivante:

Échec de la liaison de communication

Fournisseur TCP: le nom de réseau spécifié n'est plus disponible

De temps en temps, je vois cette erreur lors de l'exécution d'un ensemble de packages SSIS. Cette erreur peut se produire lorsqu'un à plusieurs packages sont exécutés à partir de:

  1. Un travail d'agent SQL Server
  2. Un fichier batch
  3. En mode débogage depuis BIDS

Le message d'erreur complet que je vois est le suivant:

Code d'erreur SSIS DTS_E_OLEDBERROR. Une erreur de base de données OLE s'est produite. Code d'erreur: 0x80004005. Un enregistrement de base de données OLE est disponible. Source: "Microsoft SQL Server Native Client 10.0" Résultat: 0x80004005 Description: "Échec de la liaison de communication". Un enregistrement de base de données OLE est disponible. Source: "Microsoft SQL Server Native Client 10.0" Résultat: 0x80004005 Description: "Fournisseur TCP: le nom de réseau spécifié n'est plus disponible.".

Code d'erreur SSIS DTS_E_OLEDBERROR. Une erreur de base de données OLE s'est produite. Code d'erreur: 0x80004005. Un enregistrement de base de données OLE est disponible. Source: "Microsoft SQL Server Native Client 10.0" Résultat: 0x80004005 Description: "Erreur de protocole dans le flux TDS". Un enregistrement de base de données OLE est disponible. Source: "Microsoft SQL Server Native Client 10.0" Résultat: 0x80004005 Description: "Échec de la liaison de communication". Un enregistrement de base de données OLE est disponible. Source: "Microsoft SQL Server Native Client 10.0" Résultat: 0x80004005 Description: "Fournisseur TCP: une connexion existante a été fermée de force par l'hôte distant."

Voici un aperçu de la façon dont j'ai conçu le processus ETL:

  • Deux serveurs
  • Les deux sont des machines virtuelles
  • Les packages SSIS s'exécutent sur un serveur d'applications
  • La base de données SQL Server vit sur un serveur de base de données

J'utilise un gestionnaire de connexions OLE DB pour me connecter du package SSIS sur le serveur d'applications à la base de données SQL Server sur le serveur de base de données.

Les packages s'exécutent en tant que déploiement de système de fichiers sur le serveur d'applications et non en tant que déploiement de base de données sur le serveur de base de données.

La raison principale en est que l'ETL est intégré à un ensemble d'outils introuvables et aux lecteurs non accessibles au serveur de base de données. Ces outils incluent Apex Data Loader pour Salesforce et pgAdmin III.

Jusqu'à présent, je ne peux pas reproduire systématiquement cette erreur. Cependant, c'est ce que j'ai observé:

  • L'échec se produit plus fréquemment pendant les heures normales de bureau
  • L'échec se produit moins fréquemment pendant les heures creuses

Pendant environ deux heures un vendredi matin, j'ai réussi à reproduire l'erreur sur un package spécifique.

L'erreur s'est produite lors d'un flux de données volumineux si un appel de package enfant qui précède le flux de données volumineux a été activé.

L'erreur ne s'est pas produite pendant le même flux de données volumineux si l'appel de package enfant qui précède le flux de données volumineux a été désactivé.

Le package enfant en question rappelle à la base de données pour récupérer une petite quantité d'informations à utiliser dans un corps de courrier électronique, puis envoie le courrier électronique.

On dirait que peut-être une limite de ressources est dépassée?

Peut-être une limite de connexion?

Je me demande quels outils je devrais utiliser pour essayer de déterminer la cause première de l'erreur.

Les détails techniques sur les deux serveurs impliqués sont répertoriés ci-dessous:

Informations sur SQL Server et Database Server:
Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) 17 juin 2011 00:54:03 Copyright (c) Microsoft Corporation Enterprise Edition (64 bits) sur Windows NT 6.1 (Build 7601: Service Pack 1) (Hyperviseur)

Informations SSIS:
Microsoft Visual Studio 2008 version 9.0.30729.1 SP Microsoft .NET Framework version 3.5 SP1

Informations sur le serveur d'applications:
Nom du système d'exploitation: Microsoft Windows Server 2008 R2 Version standard: 6.1.7601 Service Pack 1 Build 7601

J'ai recherché le message d'erreur en ligne et l'ai trouvé, mais j'aimerais vraiment obtenir l'avis d'un expert avant de continuer:

Toute aide est appréciée.

Merci

MISE À JOUR:

Des tests supplémentaires montrent que ce n'est pas "une chose SSIS" car la même erreur est observée au même rythme lors de l'utilisation de SQL Server Management Studio. La complexité de la requête ne rend pas l'erreur plus ou moins probable. Dans une tentative de résolution, nous avons essayé un correctif (ci-dessous):

C'était notre première tentative. TCP Chimney est maintenant désactivé sur le serveur d'applications et le serveur de bases de données. Les tests montrent que la même erreur se produit au même rythme.

Alors où aller d'ici? Honnêtement, je ne suis pas sûr. Une option apparemment bonne demeure:

  • Les installations d'Application Server et de Database Server SQL Server ne correspondent pas exactement
  • Serveur d'applications = SQL Server 2008 (SP1) - 10.0.2531.0 (X64)
  • Serveur de base de données = SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64)

Le plan consiste à mettre à niveau l'installation de SQL Server sur le serveur d'applications. C'est une sorte de succès et d'espoir, mais à ce stade, cela semble être la meilleure option. Quelque chose dans mon cerveau me dit que cela pourrait être résolu en corrigeant un problème matériel (j'entends par là une réparation ou un remplacement) et qu'il n'y aurait peut-être rien que la configuration matérielle et logicielle puisse faire à ce sujet.

Cependant, je ne sais toujours pas comment procéder pour déterminer une cause profonde. Je me demande toujours quels outils je devrais utiliser pour diagnostiquer la cause première.

sql-server-2008networkingssiswindows-server-2008virtual-machine
25
Jon Jaussi

Avez-vous un logiciel AV côté serveur d'applications? Si oui, essayez de désactiver AV - parfois AV bloque le trafic TCP/IP. Un problème avec "Le nom de réseau spécifié n'est plus disponible" a été résolu en désactivant AV ici: https://community.spiceworks.com/topic/239423-the-specified-network-name-is-no-longer -available-while-writing-to-shared-dir

1
Serge

Le message d'erreur indique que la connexion a été fermée de force. Vous avez également mentionné que cela se produit lorsque vous exécutez de nombreux travaux. Il y a de fortes chances que le pare-feu réseau soit à blâmer. Vous devez contacter l'administrateur du pare-feu pour rechercher les journaux afin de voir si le pare-feu a fermé la connexion. Si tel est le cas, deux solutions potentielles existent:

  1. Ajoutez une exception à la règle de pare-feu déclenchée et provoquant la fermeture de la connexion.
  2. Arrêtez d'exécuter autant de travaux simultanément. Vous devriez envisager de les exécuter en séquence. Cela adhère également à l'idée d'être un bon citoyen du réseau.
1
J Weezy
  1. Tout d'abord, avez-vous essayé de supprimer le paramètre de déchargement d'envoi important sur le NIC?
  2. Deuxième point, pouvez-vous exécuter un wirehark pour capturer les paquets si vous pouvez reproduire l'erreur?
  3. Troisième point, avez-vous essayé de changer le vnic du VM? Certains modèles peuvent causer des problèmes. (Si vous utilisez vmxnet3, essayez e1000, etc.))
  4. Dernier point, avez-vous un vswitch entre eux, ils sont sur le même hôte, un commutateur physique entre, etc ... Un commutateur mal configuré peut réduire le trafic, si à l'intérieur de l'hôte le même hôte et le même vswitch c'est le meilleur test, comme le trafic ne quitte jamais le serveur.
0
yagmoth555