Partager via

Collecter des données pour résoudre les problèmes de connectivité SQL Server

  • Article

Cet article vous aide à identifier la cause racine des problèmes de connectivité SQL Server en posant des questions pertinentes en fonction de catégories spécifiques. Bien que l’article Conditions préalables recommandées et liste de contrôle pour la résolution des problèmes de connectivité SQL Server inclut les éléments les plus importants à collecter, les questions de cet article peuvent vous aider à identifier la cause des problèmes de connectivité et à les résoudre efficacement.

Remarque

Toutes les questions ne s’appliquent pas à tous les problèmes. Toutefois, ces questions peuvent vous guider lorsque vous réfléchissez à la résolution des problèmes de connectivité.

À l’aide des informations fournies dans cet article, une fois que vous êtes en mesure de déterminer la nature exacte du problème, consultez Vue d’ensemble des problèmes d’authentification cohérente dans SQL Server pour connaître le type d’erreurs.

Méthode de collecte des données

Pour collecter des données, vous pouvez utiliser des outils tels que l’enregistreur d’étapes de problème (PSR),la trace réseau et la trace NETLOGON . Cette section fournit des étapes détaillées pour installer et configurer une combinaison de tous ces outils.

Suivez ces étapes simultanément sur les ordinateurs client et serveur. Si l’application est une architecture à 3 ou à n niveaux, exécutez également l’installation sur des serveurs intermédiaires.

  1. Installez WireShark sur tous les ordinateurs affectés ou utilisez la commande intégrée NETSH (Windows 2008 ou versions ultérieures). Aucun redémarrage n’est nécessaire.

  2. Activez la journalisation de débogage NETLOGON sur le client et tous les serveurs en exécutant la commande suivante :

    NLTEST /DBFLAG:2080FFFF

  3. Si possible, effectuez l’une des étapes suivantes :

    • Redémarrez l’ordinateur client.
    • Demandez à l’utilisateur de se déconnecter et de se reconnecter.
    • Fermez et rouvrez l’application cliente.

  4. Sur l’ordinateur client, démarrez l’enregistreur d’étapes de problème (psr.exe), puis sélectionnez Démarrer l’enregistrement.

    Cet outil capture avec précision toutes les actions utilisateur qui précèdent le problème et enregistre les résultats dans un fichier .zip.

  5. Démarrez la capture réseau sur tous les ordinateurs.

  6. Si vous utilisez NETSH, exécutez la NETSH TRACE START CAPTURE=YES TRACEFILE=C:\TEMP%computername%.ETL commande (utilisez un nom de fichier ou de chemin d’accès approprié).

  7. Videz le cache DNS (Domain Name System) sur tous les ordinateurs en exécutant la IPCONFIG /FLUSHDNS commande .

  8. Effacez le cache NETBIOS sur tous les ordinateurs en exécutant la NBTSTAT /RR commande .

  9. Videz les tickets Kerberos du client en exécutant la KLIST purge commande .

  10. Effacez les tickets sur chaque serveur en exécutant la KLIST -li 0x3e7 purge commande .

    Remarque

    Tapez la commande . Ne copiez pas et ne collez pas dans la ligne de commande, car le trait d’union peut être converti en tiret long (em). KLIST respecte la casse.

  11. Reproduisez le problème.

  12. Arrêtez l’enregistrement psr.exe .

  13. Arrêtez les captures réseau. Enregistrez le fichier enregistré en exécutant la commande NETSH : NETSH TRACE STOP à l’aide d’un nom explicite. Par exemple, le nom du fichier peut être SQLProd01.netmon.cap.

  14. Attendez que l’invite de commandes réapparaisse, puis fermez la fenêtre. Ne fermez pas la fenêtre d’invite de commandes avant que l’invite ne s’affiche.

  15. Copiez le journal NETLOGON dans C :\windows\debug\netlogon.log et donnez un nom explicite au fichier. Par exemple, SQLProd01.netlogon.log.

  16. Désactivez la journalisation en exécutant la NLTEST /DBFLAG:0x0 commande .

Collecter des données pour catégoriser les problèmes

L’ensemble de questions suivant est conçu pour vous aider à trouver la catégorie dans laquelle se situe un problème, vous guidant ainsi vers la bonne direction de la résolution des problèmes. Sélectionnez chaque liste déroulante pour les questions connexes.

Avant de passer aux questions spécifiques, assurez-vous que toutes les conditions préalables requises pour les connexions SQL Server ont été remplies. Pour plus d’informations sur les prérequis, consultez Prérequis recommandés et liste de contrôle pour résoudre les problèmes de connectivité SQL Server.

Questions de perspective plus large
  • Le problème affecte-t-il uniquement les connexions de base de données ou affecte-t-il également les connexions web et les connexions de partage de fichiers ? De nombreux cas sont signalés à l’équipe SQL Server, car ils se produisent sur le serveur de base de données. Toutefois, il est possible que le problème ne soit pas lié à la base de données et nécessite une prise en charge plus générale de Windows ou d’Active Directory.
  • Existe-t-il une relation d’approbation entre le domaine d’utilisateur, le domaine client ou le domaine serveur s’ils sont différents ? Est-ce externe, forêt, unidirectionnel, bidirectionnel ou aucun ?
  • La connexion fonctionne-t-elle correctement si toutes les ressources se trouvent dans le même domaine ?
  • Le problème est-il intermittent ou périodique ou est-il cohérent ?
  • Le problème se produit-il uniquement si plusieurs utilisateurs utilisent l’application ? Est-ce que cela se produit plus souvent si un plus grand nombre d’utilisateurs l’utilisent ?
  • Le problème se produit-il uniquement à certains moments de la journée ou à certains jours de la semaine ?
  • Le problème se produit-il uniquement lorsqu’une sauvegarde est effectuée ou que la base de données est réindexée ?
  • Le problème affecte-t-il plusieurs serveurs ?
  • Le problème affecte-t-il un seul nœud dans un cluster à n nœuds ? Si oui, il peut être plus efficace d’envisager de reconstruire ce nœud particulier.
  • Le problème n’affecte-t-il qu’un ou deux clients sur plusieurs ? Si oui, la reconstruction serait peut-être plus efficace.
  • Le problème affecte-t-il uniquement les canaux nommés et non TCP (ou vice versa) ?
  • Le problème se produit-il lorsque vous utilisez une connexion SQL Server et TCP/IP ?
  • Existe-t-il un cas de travail qui peut être comparé au cas d’échec ? En quoi les systèmes diffèrent-ils ?
Ordinateur client

Utilisez les questions suivantes pour collecter des données sur les différents composants de l’ordinateur client. Ces données peuvent être utiles pour identifier les problèmes.

  • Quel est le nom, l’édition et la version du système d’exploitation (WinVer) ?

  • Quel est le nom et la version du pilote ou du fournisseur SQL Server ?

  • Quel est le nom et l’adresse IP de l’ordinateur ?

  • Quel est l’état du domaine de l’ordinateur ? S’il est joint à un domaine, quel est le nom de domaine ?

  • Quel environnement d’exécution d’application est utilisé ? Par exemple, Internet Information Services (IIS), Windows Forms, Web Sphere ou SQL Server Integration Services (SSIS).

  • Quel langage d’application est utilisé ?

  • Quelle est la chaîne de connexion utilisée ?

  • Quel type d’authentification est utilisé pour se connecter au serveur ? Par exemple, New Technology LAN Manager (NTLM), Kerberos, SQL ou Azure Active Directory (AAD).

  • Si l’application est un serveur ou un service, délègue-t-elle les informations d’identification de l’utilisateur à la base de données principale ?

  • La délégation contrainte est-elle utilisée ?

  • Que sont le compte et le domaine du service d’application ?

  • Quel type de service est utilisé ? Est-il physique, virtuel ou cloud ? Par exemple, IaaS, Application web, Rôle web ou Power BI.

  • Qu’est-ce que le pilote client ? S’agit-il de JDBC (Java Database Connectivity) ou s’exécute-t-il sur Linux ou Mac ?

    Remarque

    Les flux de travail sont actuellement plus orientés Windows.

  • Le problème affecte-t-il uniquement les fournisseurs hérités, tels que Provider=SQLOLEBD ou Driver={SQL Server}, et non SQL Native Client et les pilotes ultérieurs (ou inversement) ?

  • Le problème se produit-il dans une seule application ou dans plusieurs applications ?

  • Un fichier UDL (Universal Data Link) échoue-t-il lorsqu’il tente de se connecter à d’autres serveurs SQL Server, ou échoue-t-il uniquement sur le serveur qui rencontre le problème ?

  • L’utilisateur se connecte-t-il au serveur SQL Server et tente-t-il de se connecter à l’aide de SQL Server Management Studio (SSMS) ?

  • Le problème se produit-il uniquement lorsque vous utilisez le nom NETBIOS du serveur et non lorsque vous utilisez le nom de domaine complet (FQDN) (ou vice versa) ? Fonctionne-t-il à l’aide de l’adresse IP ?

  • La fonctionnalité Credential Guard est-elle activée pour le client exécutant Windows 10 Édition Entreprise ? Si oui, cela peut affecter les scénarios de délégation complète.

Informations de journal

Utilisez les questions suivantes pour collecter des données sur les fichiers journaux :

  • Quel est le message d’erreur exact dans la pile des appels ?
  • Le journal a-t-il été collecté à partir des fichiers ERRORLOG et ERRORLOG.1 de SQL Server ?
  • Les journaux des événements d’application ont-ils été collectés à partir du client et du serveur ?
  • Les fichiers journaux et les fichiers de configuration de l’application cliente ont-ils été collectés ? Par exemple, web.config, rsreportserver.config, *.configou *.ini.
  • Existe-t-il une représentation visuelle disponible du réseau qui montre les ordinateurs, les routeurs, et ainsi de suite ?
Problèmes nouveaux ou existants

Fait référence à déterminer si le problème est un développement récent ou s’il a persisté pendant un certain temps :

  • Le problème a-t-il toujours existé (nouvelle installation) ou l’application a-t-elle fonctionné correctement pendant un certain temps avant de se briser récemment ?
  • Si l’application fonctionnait correctement, quelles modifications ont été apportées à l’environnement ? Par exemple, les mises à jour installées, les contrôleurs de domaine mis à niveau, les modifications apportées aux paramètres du pare-feu, les contrôleurs de domaine désactivés ou un déplacement vers une autre unité d’organisation dans le domaine.
Ordinateur serveur

Pour un serveur lié, collectez les informations de serveur pour le serveur de niveau intermédiaire et le serveur principal. Pour un problème de délégation IIS à SQL, collectez des informations sur le serveur web, notamment les paramètres deweb.config et d’authentification.

  • Quel est le nom du système d’exploitation, de l’édition et de la version (Winver) ?
  • Quel est le nom et la version de la base de données ?
  • Quel est le nom de l’ordinateur ?
  • Quelle est l’adresse IP ?
  • Quel est le nom de domaine si l’ordinateur est joint à un domaine ?
  • Qu’est-ce que le compte et le domaine de service SQL Server ?
  • Quel est le nom de l’instance SQL Server ?
  • Quels protocoles sont activés ?
  • Quel est le port sur lequel le serveur écoute ?
  • Quel est le nom du canal de serveur ? Vous trouverez ces informations dans le journal des erreurs.
  • Quel type d’environnement est utilisé ? Est-il physique, virtuel ou cloud ? Par exemple, IaaS (SQL dans une machine virtuelle Azure) ou PaaS (Azure SQL Database, SQL Managed Instance (MI)).
  • La base de données est-elle déployée en tant qu’autonome, en cluster, mise en miroir ou à l’aide d’Always On ?
  • Qu’est-ce que le nom et l’adresse IP du partenaire de basculement ?
  • Quel est le nom du cluster virtuel ou le nom et le port de l’écouteur ?
  • Quelle est l’adresse IP virtuelle ou l’adresse IP de l’écouteur ?
  • Sur quel système d’exploitation la base de données est-elle installée ? S’agit-il de Windows, Linux ou Mac ? Cela peut affecter la collecte de données.
  • Quel est l’emplacement de la base de données ? Est-il dans Azure ?
  • Quel est l’état actuel du serveur en termes de service pack et de mise à jour cumulative les plus récents ? Il est inutile de déboguer un problème déjà résolu.
  • SQL Server a-t-il été mis à niveau récemment pour prendre en charge TLS (Transport Layer Security) 1.2 ? Les clients ont-ils également été mis à jour ? Tls 1.0 a-t-il été désactivé ?
  • Quel est l’état actuel du service SQL Server ? Est-ce qu’il est en cours d’exécution ?
  • Quel est l’état du service SQL Browser ? Est-ce qu’il est en cours d’exécution ?
  • Quelle est la spécificité du problème pour un compte de service ? L’exécution du serveur à l’aide d’un autre compte de service résout-elle le problème ?
Informations utilisateur

Collectez les détails utilisateur suivants :

  • L’utilisateur se connecte-t-il directement à l’ordinateur client ou y accède-t-il à distance ? Par exemple, l’utilisateur utilise-t-il un navigateur ?
  • L’utilisateur est-il un service, tel que SQL Agent ? L’identité du processus est-elle utilisée ou des informations d’identification stockées sont-elles utilisées ?
  • Quel est le type d’authentification utilisé pour se connecter à l’application cliente ? S’agit-il de Windows, d’authentification Forms ou d’AAD ?
  • L’utilisateur se connecte-t-il au serveur à l’aide de la sécurité intégrée ?
  • Que sont le nom d’utilisateur et le nom de domaine ?

Si l’utilisateur est distant de l’application cliente, collectez les détails suivants :

  • Quel est le nom et l’adresse IP de l’ordinateur ?
  • L’ordinateur est-il joint au domaine ? Si oui, quel est le nom de domaine ?
  • L’utilisateur se connecte-t-il via un VPN ou un serveur proxy ? Le problème se produit-il si l’une des méthodes est directement connectée ?
  • Si l’utilisateur se connecte à un serveur web, la charge du serveur est-elle équilibrée ?
  • Les sessions collantes ou l’affinité de session sont-elles utilisées ?
  • L’utilisateur se connecte-t-il à un serveur Terminal Server ou à un serveur de rebond et accède-t-il à l’application ?
  • Le problème affecte-t-il uniquement les utilisateurs d’unités d’organisation particulières ?
  • L’utilisateur, le client ou le serveur a-t-il été déplacé vers une autre unité d’organisation (UO) dans Active Directory ?
  • Le problème affecte-t-il uniquement les utilisateurs non administratifs ?
  • Le problème affecte-t-il la totalité ou seulement certains utilisateurs d’un domaine particulier ?

Voir aussi

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.