Connexion de diagnostic pour les administrateurs de base de données

s’applique à :SQL Server Azure SQL Database Azure SQL Managed Instance

SQL Server fournit aux administrateurs une connexion de diagnostic spéciale lorsque des connexions standard au serveur sont impossibles. Cette connexion de diagnostic permet aux administrateurs d’accéder à SQL Server pour exécuter des requêtes de diagnostic et résoudre des problèmes, même lorsque SQL Server ne répond pas à des demandes de connexion standard.

Cette connexion administrateur dédiée (DAC) prend en charge le chiffrement et d'autres fonctions de sécurité de SQL Server. Elle permet uniquement de changer de contexte utilisateur pour un autre administrateur.

SQL Server effectue chaque tentative de connexion DAC avec succès, mais dans des situations extrêmes, il peut ne pas réussir.

Se connecter avec une connexion administrateur dédiée

Par défaut, la connexion est uniquement autorisée à partir d'un client s'exécutant sur le serveur. Les connexions réseau ne sont pas autorisées, sauf si elles sont configurées à l’aide de la sp_configure procédure stockée avec l’option de configuration du serveur de connexions d’administration distantes .

Seuls les membres du rôle administrateur système SQL Server peuvent se connecter à l'aide de la connexion DAC.

La connexion DAC est disponible et prise en charge par le biais de l’utilitaire d’invite de commandes sqlcmd au moyen d’un commutateur d’administrateur spécial (-A). Pour plus d’informations sur l’utilisation sqlcmd, consultez sqlcmd - Utiliser avec des variables de script. Vous pouvez également vous connecter en ajoutant le préfixe admin: au nom de l’instance, selon le format sqlcmd -S admin:<instance_name>. Vous pouvez également lancer une session DAC à partir d’un éditeur de requête SQL Server Management Studio au moyen d’une connexion à admin:<instance_name>.

Pour établir une connexion DAC à partir de SQL Server Management Studio :

Déconnectez toutes les connexions à l’instance de SQL Server associée, notamment l’Explorateur d’objets et toutes les fenêtres de requête ouvertes.
Dans le menu, sélectionnez Fichier > Nouveau > Requête de moteur de base de données.
Dans la boîte de dialogue de connexion dans le champ Nom du serveur, entrez admin:<server_name> si vous utilisez l’instance par défaut ou admin:<server_name>\<instance_name> si vous utilisez une instance nommée.

Port DAC

SQL Server est à l'écoute de la connexion DAC sur le port TCP 1434 s'il est disponible ou un port TCP attribué dynamiquement lors du démarrage du Moteur de base de données . Le journal des erreurs contient le numéro de port sur lequel la connexion DAC écoute. Par défaut, l'écouteur DAC n'accepte une connexion que sur le port local. Pour obtenir un exemple de code qui active les connexions d’administration à distance, consultez Configuration du serveur : connexions d’administrateur distant.

Une fois que la connexion d’administration distante est configurée, l’écouteur DAC est activé sans nécessiter un redémarrage de SQL Server et un client peut maintenant se connecter à la DAC à distance. Vous pouvez permettre à l’écouteur DAC d’accepter des connexions à distance même si SQL Server ne répond pas en vous connectant d’abord à SQL Server en utilisant la DAC localement, et en exécutant ensuite la procédure stockée sp_configure pour accepter la connexion à partir de connexions distantes.

Sur les configurations cluster, la connexion DAC est désactivée par défaut. Les utilisateurs peuvent exécuter l’option remote admin connection de sp_configure pour permettre à l’écouteur DAC d’accéder à une connexion distante. Si SQL Server ne répond pas et si l’écouteur DAC n’est pas activé, vous risquez de devoir redémarrer SQL Server pour établir une connexion avec la DAC. Nous recommandons par conséquent d'activer l'option de configuration remote admin connections sur les systèmes en cluster.

Le port DAC est affecté dynamiquement par SQL Server pendant le démarrage. Lors d’une connexion à l’instance par défaut, la DAC évite d’utiliser une demande SSRP ( SQL Server Resolution Protocol) à SQL Server Browser Service lors de la connexion. Elle se connecte d'abord sur le port TCP 1434. Si cette tentative échoue, elle effectue un appel SSRP pour obtenir le port. Si SQL Server Browser n’écoute pas les demandes SSRP, la demande de connexion retourne une erreur. Reportez-vous au journal des erreurs pour trouver le numéro de port que la DAC écoute. Si SQL Server est configuré pour accepter les connexions d'administration distante, la DAC doit être initialisée avec un numéro de port explicite :

sqlcmd -S tcp:<server>,<port>

Le journal des erreurs de SQL Server indique le numéro de port de la connexion DAC, qui est 1434 par défaut. Si SQL Server est configuré pour accepter uniquement des connexions DAC locales, connectez-vous au moyen de l'adaptateur de bouclage en utilisant la commande suivante :

sqlcmd -S 127.0.0.1,1434

Limites

Comme la connexion DAC n'est prévue que pour diagnostiquer des problèmes de serveur dans de rares circonstances, certaines restrictions sont imposées sur la connexion :

Pour garantir que des ressources sont disponibles pour la connexion, une seule connexion DAC est autorisée par instance de SQL Server. Si une connexion DAC est déjà active, toute nouvelle demande de connexion établie par son intermédiaire est refusée avec l'erreur 17810.
Pour conserver les ressources, SQL Server Express n’écoute pas sur le port DAC, sauf si vous avez démarré avec l’indicateur de trace 7806.
Au départ, la connexion DAC tente une connexion à la base de données par défaut associée à la connexion. Une fois connecté, vous pouvez vous connecter à la master base de données. Si la base de données par défaut est hors connexion ou non disponible pour une raison quelconque, la connexion retourne l'erreur 4060. Cependant, elle réussit si vous remplacez la base de données par défaut pour vous connecter à la base de données master au lieu d’utiliser la commande suivante :
```
sqlcmd -A -d master
```
Nous vous conseillons de vous connecter à la base de données master avec une connexion DAC, car la disponibilité de master est garantie si l’instance du moteur de base de données a été démarrée.
SQL Server interdit l'exécution de requêtes ou de commandes parallèles avec la connexion DAC. Par exemple, l'erreur 3637 est générée si vous exécutez l'une des instructions ci-dessous avec la connexion DAC :
- RESTORE...
- BACKUP...
Seules des ressources limitées sont garanties disponibles avec la connexion DAC. N’utilisez pas la DAC pour exécuter des requêtes ou des requêtes gourmandes en ressources qui peuvent bloquer d’autres requêtes. Cela permet d'éviter que la connexion DAC n'amplifie d'éventuels problèmes de serveur existants. Pour éviter les scénarios de blocage potentiels, si vous devez exécuter des requêtes qui peuvent bloquer, exécutez la requête sous des niveaux d’isolation basés sur des instantanés si possible ; sinon, définissez le niveau READ UNCOMMITTED d’isolation des transactions sur et définissez la LOCK_TIMEOUT valeur sur une valeur courte telle que 2 000 millisecondes, ou les deux. Vous éviterez ainsi le blocage de la session DAC. Cependant, selon l'état de SQL Server , la session DAC pourrait se bloquer sur un verrou. La session DAC peut éventuellement être terminée avec Ctrl+C, mais ceci n’est pas garanti. Dans ce cas, votre seule option peut être de redémarrer SQL Server.
Pour garantir la connectivité et le dépannage avec la connexion DAC, SQL Server réserve des ressources limitées pour traiter les commandes exécutées sur la connexion DAC. Ces ressources ne permettent généralement que de simples fonctions de diagnostic et de dépannage, telles que celles répertoriées ci-dessous.

Même si vous pouvez théoriquement exécuter une instruction Transact-SQL qui n’a pas besoin d’être exécutée en parallèle sur la connexion DAC, nous vous recommandons fortement de vous limiter aux commandes de diagnostic et de résolution de problèmes suivantes :

Interrogation de vues de gestion dynamique (DMV) pour des diagnostics de base, comme sys.dm_tran_locks pour l’état de verrouillage, sys.dm_os_memory_cache_counters pour vérifier l’état des caches, et sys.dm_exec_requests et sys.dm_exec_sessions pour les sessions et les demandes actives. Évitez les vues de gestion dynamiques qui consomment beaucoup de ressources (par exemple, sys.dm_tran_version_store analyse le magasin de versions complet et peut provoquer des E/S intensives) ou qui utilisent des jointures complexes. Pour plus d'informations sur les implications sur les performances, consultez la documentation relative à la vue de gestion dynamiquespécifique.
Interrogation d'affichages catalogue.
Les commandes DBCC de base, comme DBCC FREEPROCCACHE, DBCC FREESYSTEMCACHE, DBCC DROPCLEANBUFFERS et DBCC SQLPERF. Évitez d’exécuter des commandes consommant beaucoup de ressources, comme DBCC CHECKDB, DBCC DBREINDEX ou DBCC SHRINKDATABASE.
Commande Transact-SQL KILL <spid>. En fonction de l’état de SQL Server, la KILL commande peut ne pas réussir. La seule option peut être de redémarrer l’instance, dans le cas de SQL Server ou d’Azure SQL Managed Instance. Voici quelques directives générales :
- Vérifiez que le SPID a été supprimé en interrogeant SELECT * FROM sys.dm_exec_sessions WHERE session_id = <spid>;. S'il ne retourne aucune ligne, la session a été supprimée.
- Si la session est toujours active, vérifiez si des tâches sont affectées à cette session en exécutant la requête SELECT * FROM sys.dm_os_tasks WHERE session_id = <spid>;. Si vous y voyez la tâche, votre session est très probablement en cours de fermeture. Cela peut prendre beaucoup de temps et peut ne pas réussir du tout.
- Si aucune tâche sys.dm_os_tasks n’est associée à cette session, mais que la session reste en sys.dm_exec_sessions cours après l’exécution de la KILL commande, cela signifie que vous n’avez pas de worker disponible. Sélectionnez l’une des tâches en cours d’exécution (une tâche répertoriée dans l’affichage sys.dm_os_tasks avec un sessions_id <> NULL), puis supprimez la session associée pour libérer le worker. Il peut ne pas suffire de tuer une seule session : vous devrez peut-être tuer plusieurs.

Limitation dans Azure SQL Database

Lors de la connexion à Azure SQL Database via une connexion DAC, vous devez également spécifier le nom de la base de données dans la chaîne de connexion, à l’aide de l’option -d.

Limitation dans Azure SQL Managed Instance

La DAC ne fonctionne pas sur un point de terminaison privé pour Azure SQL Managed Instance. Sur les instances managées SQL, la DAC écoute sur le port 1434. Étant donné que les points de terminaison privés vers des instances managées SQL autorisent uniquement les connexions sur le port 1433, vous ne pouvez pas utiliser de point de terminaison privé pour établir une connexion DAC. Vous devez être dans le même réseau virtuel que l’instance managée SQL pour vous connecter à DAC.

Examples

Dans cet exemple, un administrateur note que le serveur contoso-server ne répond pas et souhaite diagnostiquer le problème. Pour ce faire, l'utilisateur active l'utilitaire de ligne de commande sqlcmd et se connecte au serveur contoso-server en utilisant -A pour indiquer la connexion DAC.

sqlcmd -S contoso-server -U sa -P <StrongPassword> -A

L'administrateur peut maintenant exécuter des requêtes pour diagnostiquer le problème et éventuellement terminer les sessions sans réponse.

Un exemple similaire de connexion à SQL Database utilise la commande suivante, notamment le -d paramètre pour spécifier la base de données :

sqlcmd -S serverName.database.windows.net,1434 -U sa -P <StrongPassword> -d AdventureWorks

Rétroaction

Cette page vous a-t-elle été utile ?

Last updated on 2025-08-28