Partager via

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

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

Note

Toutes les questions ne sont pas applicables à tous les problèmes. Toutefois, ces questions peuvent vous guider à mesure que vous envisagez de résoudre les problèmes de connectivité.

À l’aide des informations fournies dans cet article, une fois que vous êtes en mesure de zéro sur la nature exacte du problème, consultez Vue d’ensemble des problèmes d’authentification cohérents 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 clients et serveurs. Si l’application est une architecture à 3 niveaux ou n, exécutez également l’installation sur des serveurs intermédiaires.

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

  2. Activez la journalisation du 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 des étapes du 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 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.

    Note

    Tapez la commande . Ne copiez pas et collez 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 en utilisant un nom explicite. Par exemple, le nom du fichier peut être SQLProd01.netmon.cap.

  14. Attendez que l’invite de commandes réapparaît, puis fermez la fenêtre. Ne fermez pas la fenêtre d’invite de commandes avant l’affichage de l’invite.

  15. Copiez le journal NETLOGON dans C :\windows\debug\netlogon.log et donnez au fichier un nom explicite. 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 un problème tombe, 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 vous lancer dans les questions spécifiques posées, vérifiez que toutes les conditions préalables requises pour les connexions SQL Server ont été remplies. Pour plus d’informations sur les prérequis, consultez la liste de vérification et les prérequis recommandés pour résoudre les problèmes de connectivité SQL Server.

Questions de perspective plus larges
  • Le problème affecte-t-il uniquement les connexions de base de données, ou affecte-t-il également les connexions de partage de fichiers et web ? De nombreux cas sont signalés à l’équipe SQL Server, car ils se produisent sur le serveur de base de données. Toutefois, il peut être possible que le problème ne soit pas lié à la base de données du tout 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 utilisateur, le domaine client ou le domaine serveur s’ils sont différents ? Est-ce externe, forestier, 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 plus d’utilisateurs l’utilisent ?
  • Le problème ne se produit-il qu’à certains moments de la journée ou sur 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-node ? Si c’est le cas, il peut être plus efficace 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 inversement) ?
  • 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é à la casse défaillante ? Comment 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 de l’ordinateur et l’adresse IP ?

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

  • Quel environnement d’exécution de l’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é ?

  • Qu’est-ce que 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 ?

  • Qu’est-ce que 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 la connectivité de base de données Java (JDBC) ou s’exécute-t-elle sur Linux ou Mac ?

    Note

    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 ne parvient-il pas uniquement au serveur qui a 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 ?

  • Le client exécutant Windows 10 Entreprise Edition a-t-il activé la fonctionnalité Credential Guard ? Si c’est le cas, cela peut affecter des scénarios de délégation complets.

Informations sur le 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 SQL Server ERRORLOG et ERRORLOG.1 ?
  • Les journaux des événements d’application ont-ils été collectés à partir du client et du serveur ?
  • Les fichiers journaux de l’application cliente et les fichiers de configuration ont-ils été collectés ? Par exemple, web.config, rsreportserver.config, *.config ou *.ini.
  • Existe-t-il une représentation visuelle disponible du réseau qui affiche 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 existe-t-il toujours (nouvelle installation) ou l’application fonctionne-t-elle correctement pendant un certain temps avant qu’elle ait récemment rompu ?
  • Si l’application était utilisée pour fonctionner 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 unité d’organisation différente dans le domaine.
Ordinateur serveur

Pour un serveur lié, collectez les informations du 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 web.config et d’authentification.

  • Quel est le nom du 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 ?
  • Qu’est-ce que 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 du 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 que base de données autonome, en cluster, mise en miroir ou à l’aide d’Always On ?
  • Quel est le nom du partenaire de basculement et l’adresse IP ?
  • 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 ?
  • Quel système d’exploitation la base de données est-elle installée ? Est-ce Windows, Linux ou Mac ? Cela peut affecter la collecte de données.
  • Quel est l’emplacement de la base de données ? Est-ce dans Azure ?
  • Quel est l’état actuel du serveur en termes de dernière mise à jour cumulative et Service Pack ? Il n’y a aucun point dans le débogage d’un problème qui est 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 à 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 de l’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 les informations d’identification stockées sont-elles utilisées ?
  • Quel est le type d’authentification utilisé pour se connecter à l’application cliente ? Existe-t-il une authentification Windows, Forms ou AAD ?
  • L’utilisateur se connecte-t-il au serveur à l’aide de la sécurité intégrée ?
  • Qu’est-ce que le nom d’utilisateur et le nom de domaine ?

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

  • Quel est le nom de l’ordinateur et l’adresse IP ?
  • Le domaine de l’ordinateur est-il joint ? 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 ou l’autre méthode est directement connectée ?
  • Si l’utilisateur se connecte à un serveur web, la charge du serveur est-elle équilibrée ?
  • Les sessions sticky ou l’affinité de session sont-elles utilisées ?
  • L’utilisateur se connecte-t-il à un serveur terminal ou à une zone de rebond et accède-t-il à l’application ?
  • Le problème affecte-t-il uniquement les utilisateurs dans des unités organisationnelles particulières ?
  • L’utilisateur, le client ou le serveur est-il 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 tout 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.