Partager via

Résoudre les problèmes de connectivité sur un pool SQL dédié

S’applique à : Azure Synapse Analytics

Les problèmes de connectivité qui se produisent sur un pool SQL dédié peuvent avoir différentes causes. Cet article fournit des outils et des méthodes pour vous aider à résoudre les problèmes de connectivité les plus courants.

Liste de contrôle de connectivité initiale

La liste suivante décrit les raisons couramment ignorées des problèmes de connectivité sur un pool SQL dédié. Consultez la liste pour voir comment vous pouvez contourner les problèmes.

Description de la tâche Solution de contournement
Recherchez les interruptions de service Azure. Vérifiez le tableau de bord du service Microsoft Azure pour déterminer s’il existe des problèmes connus.
Vérifiez la disponibilité du service. Dans le Portail Azure, accédez au pool SQL dédié auquel vous essayez de vous connecter, puis sélectionnez Diagnostiquer et résoudre les problèmes dans le volet gauche pour vérifier la disponibilité du service.
Recherchez la présence d’une opération interrompue ou de mise à l’échelle. Vérifiez si votre service est actuellement en pause ou en cours de mise à l’échelle. Dans le portail Azure, accédez au pool SQL dédié auquel vous essayez de vous connecter. Pour plus d’informations, consultez la documentation de résolution des problèmes.
Consultez le panneau Intégrité des ressources dans le Portail Azure pour connaître les mises à jour d’état. Un état non disponible signifie que l’intégrité des ressources a détecté des échecs de connexion cohérents en raison d’une erreur système dans votre base de données SQL. L’état de détérioré signifie que l’intégrité des ressources a détecté principalement des connexions réussies, mais il existe également des échecs. Ces échecs de connexion peuvent être causés par des erreurs temporaires.
Vérifiez les paramètres de pare-feu. Le pool SQL dédié communique par le biais du port 1433. Si vous essayez de vous connecter à partir d’un réseau d’entreprise, le trafic sortant sur le port 1433 peut être bloqué par le pare-feu de votre réseau. Dans ce cas, vous ne pouvez pas vous connecter à votre serveur Azure SQL Database, sauf si votre service informatique ouvre le port 1433. Pour plus d’informations, consultez Créer et gérer des règles de pare-feu IP.
Vérifier vos paramètres de votre réseau virtuel/point de terminaison de service. Si vous voyez des erreurs « 40914 » et « 40615 », consultez la description et la résolution des erreurs dans la section référence des messages d’erreur courants.
Recherchez les derniers pilotes. Vérifiez que vous utilisez la dernière version de l’outil et des pilotes pour vous connecter à votre pool SQL dédié. Pour plus d’informations, consultez Rechercher les pilotes les plus récents.

Ressources :
* Se connecter à votre pool SQL dédié et le gérer à l’aide du portail Azure
* Connectez et gérez votre pool SQL dédié à l’aide de PowerShell.
Vérifiez votre chaîne de connexion. Vérifiez que vos chaîne de connexion sont correctement définies. Vérifiez votre chaîne de connexion pour voir des exemples de chaîne de connexion pour ADO.NET, ODBC, PHP et JDBC. Pour plus d’informations, consultez Chaînes de connexion.

Résoudre les erreurs de connectivité persistante

L’outil de vérification de la connectivité Azure SQL est un script PowerShell qui automatise une série de vérifications pour les problèmes de configuration les plus courants. La plupart des problèmes détectés par le script seront accompagnés de recommandations pour la résolution.

Le script PowerShell suivant télécharge et exécute la dernière version du vérificateur de connectivité Azure SQL. Vous pouvez l’exécuter à partir de n’importe quel ordinateur client sur lequel des problèmes de connectivité persistants se produisent.

Note

  1. Ouvrez Windows PowerShell ISE (en mode Administrateur si possible).

    Note

    Pour collecter une trace réseau avec les tests (CollectNetworkTrace paramètre), vous devez exécuter PowerShell en tant qu’administrateur.

  2. Ouvrez une fenêtre Nouveau script.

  3. Copiez et collez le texte suivant dans la fenêtre de script :

    $parameters = @{
# Supports Single, Elastic Pools and Managed Instance (MI public endpoint is supported)
# Supports Azure Synapse / Azure SQL Data Warehouse (*.sql.azuresynapse.net / *.database.windows.net)
# Supports Public Cloud (*.database.windows.net), Azure China (*.database.chinacloudapi.cn), Azure Germany (*.database.cloudapi.de) and Azure Government (*.database.usgovcloudapi.net)
Server = '.database.windows.net' # or any other supported FQDN
Database = ''  # Set the name of the database you wish to test, 'master' will be used by default if nothing is set
User = ''  # Set the login username you wish to use, 'AzSQLConnCheckerUser' will be used by default if nothing is set
Password = ''  # Set the login password you wish to use, 'AzSQLConnCheckerPassword' will be used by default if nothing is set

# Optional parameters (default values will be used if omitted)
SendAnonymousUsageData = $true  # Set as $true (default) or $false
RunAdvancedConnectivityPolicyTests = $true  # Set as $true (default) or $false, this will load the library from Microsoft's GitHub repository needed for running advanced connectivity tests
ConnectionAttempts = 1 # Number of connection attempts while running advanced connectivity tests
DelayBetweenConnections = 1 # Number of seconds to wait between connection attempts while running advanced connectivity tests
CollectNetworkTrace = $true  # Set as $true (default) or $false
#EncryptionProtocol = '' # Supported values: 'Tls 1.0', 'Tls 1.1', 'Tls 1.2'; Without this parameter operating system will choose the best protocol to use
 }

$ProgressPreference = "SilentlyContinue";
if ("AzureKudu" -eq $env:DOTNET_CLI_TELEMETRY_PROFILE) {
$scriptFile = '/ReducedSQLConnectivityChecker.ps1'
} else {
$scriptFile = '/AzureSQLConnectivityChecker.ps1'
}
$scriptUrlBase = 'http://raw.githubusercontent.com/Azure/SQL-Connectivity-Checker/master'
cls
Write-Host 'Trying to download the script file from GitHub (https://github.com/Azure/SQL-Connectivity-Checker), please wait...'
try {
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 -bor [Net.SecurityProtocolType]::Tls11 -bor [Net.SecurityProtocolType]::Tls
Invoke-Command -ScriptBlock ([Scriptblock]::Create((Invoke-WebRequest ($scriptUrlBase + $scriptFile) -UseBasicParsing -TimeoutSec 60).Content)) -ArgumentList $parameters
}
catch {
Write-Host 'ERROR: The script file could not be downloaded:' -ForegroundColor Red
$_.Exception
Write-Host 'Confirm this machine can access https://github.com/Azure/SQL-Connectivity-Checker/' -ForegroundColor Yellow
Write-Host 'or use a machine with Internet access to see how to run this from machines without Internet. See how at https://github.com/Azure/SQL-Connectivity-Checker/' -ForegroundColor Yellow
}
#end

  4. Définissez les paramètres sur le script.

    • Spécifiez le nom du serveur et celui de la base de données.
    • Spécifiez les informations d’utilisateur et de mot de passe.

      Note

      Cette étape est facultative, mais est une bonne pratique.

  5. Exécutez le script. Les résultats s’affichent dans la fenêtre de sortie. Si l’utilisateur dispose des autorisations nécessaires pour créer des dossiers, un dossier qui inclut le fichier journal résultant est créé, ainsi qu’un fichier .zip (AllFiles.zip). Dans Windows, le dossier s’ouvre automatiquement une fois le script en cours d’exécution.

  6. Examinez la sortie des problèmes détectés et suivez les étapes recommandées pour résoudre le problème. Si le problème ne peut pas être résolu, envoyez le AllFiles.zip fichier à Microsoft à l’aide de l’option Chargement de fichier à l’étape Détails lorsque vous créez votre demande de support.

Résoudre les erreurs de connectivité intermittentes

Assurez-vous que toutes les applications de production ont une logique de nouvelle tentative robuste pour gérer les pertes de connexion et erreurs temporaires.

Configuration de la stratégie de connexion pour les problèmes de passerelle

La passerelle Azure SQL Database met fin aux sessions inactives pendant plus de 30 minutes. Ce scénario affecte fréquemment les connexions mises en pool et inactives. Pour un pool SQL dédié (anciennement SQL DW) , vous pouvez faire passer la stratégie de connexion de votre serveur du mode proxy au mode redirection. Le paramètre de redirection contourne la passerelle une fois qu’elle est connectée. Cela élimine le problème.

TCP KeepAlive dans Microsoft JDBC Driver

Le pilote Microsoft JDBC et certains pilotes tiers n’activent pas TCP KeepAlive. Cela entraîne la suppression de la couche réseau TCP après une certaine période d’inactivité. Vérifiez que les pilotes clients les plus récents sont installés et que le pilote active KeepAlive.

Configuration du délai d’expiration

Toutes les applications qui se connectent aux pools Synapse SQL doivent utiliser un délai de connexion d’au moins 15 secondes. Des durées plus courtes peuvent rencontrer des délais d’attente pendant une reconfiguration de base de données.

Utilisation élevée des ressources

  • Vérifiez si vous rencontrez des charges lourdes sur le serveur avec un grand nombre de demandes en file d’attente. Vous devrez peut-être effectuer un scale-up de votre entrepôt de données pour plus de ressources.
  • Essayez d’ajouter une logique de nouvelle tentative dans votre application cliente pour atténuer ces situations et rendre les erreurs transparentes pour les utilisateurs.
  • Azure Synapse Analytics fournit une expérience de supervision enrichie dans le Portail Azure pour intégrer des insights concernant la charge de travail de votre entrepôt de données. Vous pouvez passer en revue l’utilisation du processeur, de la mémoire et de l’utilisation locale tempdb en ce qui concerne votre charge de travail dans Azure Monitor du Portail Azure.

Informations de référence sur les messages d’erreur courants

Utilisez ce tableau pour rechercher des descriptions et des atténuations pour les messages d’erreur les plus courants que vous recevez lorsque vous essayez de vous connecter à un pool SQL dédié.

Message d’erreur Description et atténuation
Erreur 18456 : Échec de la connexion pour l’utilisateur « NT AUTHORITY\ANONYMOUS LOGON ». (Microsoft SQL Server, erreur : 18456) Cette erreur se produit lorsqu’un utilisateur Microsoft Entra tente de se connecter à la base de données master, mais qu’il n’a pas d’utilisateur dans la base de données master. Pour corriger ce problème, spécifiez le pool SQL dédié auquel vous souhaitez vous connecter au moment de la connexion, ou ajoutez l’utilisateur à la base de données master. Pour plus d’informations, consultez La vue d’ensemble de la sécurité et [erreurs de connexion avec l’état et la description](/sql/relational-databases/errors-events/ du jeton SAP. Envisagez de passer à l’identité managée ou à l’authentification directe Microsoft Entra pour accéder au stockage protégé. Pour plus d’informations, consultez Accorder l’accès aux services Azure approuvés et contrôler l’accès au compte de stockage pour le pool SQL serverless.
Erreur 916 : Le principal du serveur « MyUserName » n’est pas en mesure d’accéder à la base de données « master » dans le contexte de sécurité actuel. La base de données utilisateur par défaut ne peut pas être ouverte. Échec de la connexion. Échec de la connexion pour l'utilisateur 'MyUserName'. (Microsoft SQL Server, erreur : 916) Cette erreur se produit lorsqu’un utilisateur Microsoft Entra tente de se connecter à la base de données master, mais qu’il n’a pas d’utilisateur dans la base de données master. Pour corriger ce problème, spécifiez le pool SQL dédié auquel vous souhaitez vous connecter au moment de la connexion ou ajoutez l’utilisateur à la base de données master. Pour plus d’informations, consultez La vue d’ensemble de la sécurité et les erreurs de connexion avec l’état et la description.
Erreur 40613: La base de données X sur le serveur Y n’est pas disponible actuellement L’erreur 40613 est une erreur non spécifique et temporaire retournée par Azure chaque fois que votre base de données n’est pas disponible. Vous devez vous attendre à des périodes brèves occasionnelles (par exemple, moins de 60 secondes) pendant lesquelles vous voyez l’erreur « 40613 ». Pour prendre en charge ce scénario, assurez-vous que toutes les applications de production ont une logique de nouvelle tentative robuste.
Erreur 40615 : Impossible d’ouvrir le serveur «{0} » demandé par la connexion. Le client avec l’adresse IP '{1}' n’est pas autorisé à accéder au serveur Le client tente de se connecter à partir d’une adresse IP qui n’est pas autorisée à se connecter au serveur Azure SQL Database. Le pare-feu du serveur ne dispose d’aucune règle d’adresse IP qui autorise un client à communiquer à partir de l’adresse IP donnée vers la base de données SQL Database. Entrez l’adresse IP du client en tant que nouvelle règle IP dans les paramètres de pare-feu de la ressource dans Portail Azure. Une liste de plusieurs messages d’erreur de base de données SQL Database est documentée ici.
Erreur 40914 : Impossible d’ouvrir le nom> du serveur <demandé par la connexion. Le client n’est pas autorisé à accéder au serveur Dans ce scénario, le client se trouve dans un sous-réseau qui a des points de terminaison de serveur de réseau virtuel. Toutefois, le serveur Azure SQL Database n’a aucune règle de réseau virtuel qui accorde le droit de communiquer avec la base de données SQL au sous-réseau. Dans le volet Pare-feu du portail Azure, utilisez le contrôle des règles de réseau virtuel pour ajouter une règle de réseau virtuel pour le sous-réseau.
Erreur 9002 : « Le journal des transactions pour le nom> de base de données de base de données <est complet en raison de « ACTIVE_TRANSACTION ». (Microsoft SQL Server, Erreur : 9002)' Cette erreur indique généralement une transaction de longue durée qui n’est pas encore validée ou qu’il existe une session non réactive. Cela rend un journal des transactions complet. Recherchez les sessions suspendues qui journaliser SELECT * FROM sys.dm_exec_sessions, and end them by using KILL <session_id>. S’il n’y a pas de sessions suspendues, vous devrez peut-être annuler la requête longue ou tuer cette session pour atténuer ce problème.
Une erreur liée au réseau ou propre à une instance s’est produite lors de l’établissement d’une connexion à SQL Server. Le serveur est introuvable ou inaccessible. Vérifiez que le nom de l’instance est correct et que SQL Server est configuré pour autoriser les connexions à distance. Les connexions pour SQL Database ou les pools SQL dédiés (anciennement SQL DW) dans Azure Synapse peuvent se faire sur n’importe quelle passerelle dans une région. Pour une connectivité cohérente à SQL Database ou aux pools SQL dédiés (anciennement SQL DW) dans Azure Synapse, autorisez le trafic réseau vers et depuis toutes les adresses IP et sous-réseaux de passerelle pour la région. Consultez Adresses IP de la passerelle.
Impossible d’ouvrir le fichier, car il n’existe pas ou est utilisé par un autre processus Si votre requête échoue et retourne ce message d’erreur et que vous vérifiez que le fichier existe et n’est pas utilisé par un autre processus, le pool SQL serverless ne peut pas accéder au fichier. Si le stockage est protégé par un pare-feu, passez en revue les étapes décrites dans l’interrogation du stockage protégé par le pare-feu.
Échec de l’exécution de la requête. Erreur : le nom de table de table <> externe n’est pas accessible, car le contenu du répertoire ne peut pas être répertorié. Si le stockage est protégé à l’aide d’un pare-feu, consultez l’interrogation du stockage protégé par le pare-feu. Utilisez le script PowerShell précédent pour vérifier que les règles réseau du compte de stockage sont correctement configurées.

Ressources