Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier les répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer de répertoire.
S’applique à :
SQL ServerAzure SQL Managed Instance
Les serveurs liés permettent au moteur de base de données SQL Server et à Azure SQL Managed Instance de lire des données à partir de sources de données distantes et d’exécuter des commandes sur des serveurs de base de données distants (par exemple, des sources de données OLE DB), en dehors de l’instance de SQL Server. En règle générale, vous configurez des serveurs liés pour permettre au moteur de base de données d’exécuter une instruction Transact-SQL qui inclut des tables dans une autre instance de SQL Server ou un autre produit de base de données tel qu’Oracle. Vous pouvez configurer de nombreux types de sources de données OLE DB en tant que serveurs liés, notamment des fournisseurs de base de données tiers et Azure Cosmos DB.
Remarque
Les serveurs liés sont disponibles dans SQL Server et dans Azure SQL Managed Instance (avec des contraintes). Les serveurs liés ne sont pas disponibles dans Azure SQL Database.
Quand utiliser des serveurs liés ?
Les serveurs liés permettent d’implémenter des bases de données distribuées qui peuvent extraire et mettre à jour des données dans d’autres bases de données. Utilisez des serveurs liés dans des scénarios où vous devez implémenter le partitionnement de base de données sans créer de code d’application personnalisé ou charger directement à partir de sources de données distantes. Les serveurs liés offrent les avantages suivants :
La possibilité d'accéder à des données extérieures à SQL Server.
la possibilité d'émettre des requêtes, des mises à jour, des commandes et des transactions partagées sur des sources de données hétérogènes situées dans les différents services de l'entreprise ;
la possibilité de traiter diverses sources de données de manière identique.
Vous pouvez configurer un serveur lié en utilisant SQL Server Management Studio ou à l’aide de l’instruction sp_addlinkedserver. Le type et le nombre de paramètres requis sont très différents en fonction des fournisseurs OLE DB. Par exemple, certains fournisseurs exigent que vous fournissiez un contexte de sécurité pour la connexion à l’aide de sp_addlinkedsrvlogin. Certains fournisseurs OLE DB autorisent SQL Server à mettre à jour les données sur la source OLE DB. D'autres fournissent uniquement un accès en lecture seule aux données. Pour plus d'informations sur chaque fournisseur OLE DB, consultez sa documentation.
Composants des serveurs liés
Une définition de serveur lié spécifie les objets suivants :
Un fournisseur OLE°DB
Une source de données OLE°DB
Un fournisseur OLE°DB représente une DLL qui gère une source de données spécifique et interagit avec elle. Une source de données OLE DB identifie la base de données spécifique que vous pouvez accéder via OLE DB. Bien que les sources de données interrogées au moyen des définitions de serveurs liés soient d'ordinaire des bases de données, des fournisseurs OLE°DB existent pour divers fichiers et formats de fichiers, Ces fichiers incluent du texte brut, des données de feuille de calcul et les résultats des recherches de contenu en texte intégral.
À partir de SQL Server 2019 (15.x), le pilote Microsoft OLE DB Driver pour SQL Server (PROGID : MSOLEDBSQL) est le fournisseur OLE DB par défaut. Dans les versions antérieures, le SQL Server Native Client (PROGID : SQLNCLI11) était le fournisseur OLE DB par défaut.
Importante
SQL Server Native Client (souvent abrégé en SNAC) a été supprimé dans SQL Server 2022 (16.x) et SQL Server Management Studio 19 (SSMS). Le fournisseur OLE DB pour SQL Server Native Client (SQLNCLI ou SQLNCLI11) et le fournisseur Microsoft OLE DB hérité pour SQL Server (SQLOLEDB) ne sont pas recommandés dans les nouveaux développements. Utilisez à la place le nouveau Microsoft OLE DB Driver (MSOLEDBSQL) pour SQL Server.
Microsoft prend en charge les serveurs liés à des sources Excel et Access uniquement lorsque vous utilisez le fournisseur OLE DB Microsoft.JET.4.0 32 bits.
Remarque
Les requêtes distribuées SQL Server fonctionnent avec n’importe quel fournisseur OLE DB qui implémente les interfaces OLE DB requises. Toutefois, SQL Server a été testé par rapport au fournisseur OLE DB par défaut.
Détails des serveurs liés
L'illustration suivante montre les aspects fondamentaux d'une configuration de serveurs liés.
En règle générale, vous utilisez des serveurs liés pour gérer les requêtes distribuées. Lorsqu'une application cliente exécute une requête distribuée par le biais d'un serveur lié, SQL Server analyse la commande et envoie des demandes à OLE DB. La requête d'ensemble de lignes peut se présenter sous la forme d'une exécution de requête vers le fournisseur, ou par l'ouverture d'une table de base à partir du fournisseur.
Pour qu'une source de données renvoie les données par le biais d'un serveur lié, le fournisseur OLE DB (DLL) associé à cette source de données doit se trouver sur le même serveur que l'instance de SQL Server.
Les serveurs liés prennent en charge l’authentification directe Active Directory au moment de l’utilisation de la délégation totale. À compter de SQL Server 2017 (14.x) CU17, l’authentification directe avec délégation contrainte est également prise en charge ; Toutefois, la délégation contrainte basée sur les ressources n’est pas prise en charge.
Importante
Lorsque vous utilisez un fournisseur OLE DB, le compte sous lequel le service SQL Server s’exécute doit disposer d’autorisations de lecture et d’exécution pour l’annuaire, ainsi que de tous les sous-répertoires dans lesquels le fournisseur est installé. Cette exigence s’applique aux fournisseurs publiés par Microsoft et à tous les fournisseurs tiers.
Gérer les fournisseurs
Un ensemble d'options permettent de contrôler la façon dont SQL Server charge et utilise des fournisseurs OLE DB spécifiés dans le Registre.
Gérer des définitions de serveurs liés
Lorsque vous configurez un serveur lié, inscrivez les informations de connexion et les informations de source de données auprès de SQL Server. Une fois inscrit, vous pouvez faire référence à cette source de données avec un nom logique unique.
Utilisez des procédures stockées et des affichages catalogue pour gérer les définitions de serveur lié :
Créez une définition de serveur lié en exécutant
sp_addlinkedserver.Visualisez les informations relatives aux serveurs liés définis dans une instance spécifique de SQL Server en exécutant une requête sur la vue catalogue système
sys.servers.Supprimez une définition de serveur lié en exécutant
sp_dropserver. Vous pouvez également utiliser cette procédure stockée pour supprimer un serveur distant.
Vous pouvez également définir les serveurs liés à l'aide de SQL Server Management Studio. Dans l’Explorateur d’objets, cliquez avec le bouton droit sur Objets serveur, sélectionnez Nouveau, puis sélectionnez Serveur lié. Pour supprimer une définition de serveur lié, vous pouvez cliquer avec le bouton droit sur le nom du serveur lié, puis sélectionner Supprimer.
Lorsque vous exécutez une requête distribuée sur un serveur lié, veillez à inclure pour chaque source de données à interroger un nom de table en quatre parties complet. Ce nom en quatre parties doit être au format <linked_server_name>.<catalog>.<schema>.<object_name>.
Les références aux objets temporaires sont toujours résolues dans l'instance locale tempdb lorsqu'applicables, même lorsqu'elles sont préfixées par le nom du serveur lié.
Vous pouvez définir des serveurs liés pour qu’ils pointent (effectuent une boucle) vers le serveur sur lequel vous les définissez. Les serveurs en boucle sont particulièrement utiles pour tester une application utilisant des requêtes distribuées sur un réseau comportant un seul serveur. Les serveurs liés en boucle sont destinés aux tests et ne sont pas pris en charge pour de nombreuses opérations, telles que les transactions distribuées.
Serveurs liés avec Azure SQL Managed Instance
Les serveurs liés Azure SQL Managed Instance prennent en charge l’authentification SQL et l’authentification avec l’ID Microsoft Entra.
Pour utiliser des travaux SQL Agent sur Azure SQL Managed Instance pour interroger un serveur distant via un serveur lié, utilisez sp_addlinkedsrvlogin pour créer, à partir d’une connexion sur le serveur local, un mappage à une connexion sur le serveur distant. Lorsque le travail SQL Agent se connecte au serveur distant via le serveur lié, il exécute la requête T-SQL dans le contexte de la session à distance. Pour plus d’informations, consultez Travaux SQL Agent avec Azure SQL Managed Instance.
Authentification Microsoft Entra
Les deux modes d'authentification Microsoft Entra pris en charge sont les suivants : authentification avec identité managée et authentification directe. Utilisez l’authentification d’identité managée pour autoriser les connexions locales à interroger des serveurs liés distants. Utilisez l’authentification directe pour autoriser un principal qui peut s’authentifier auprès d’une instance locale pour accéder à une instance distante via un serveur lié.
Pour utiliser l’authentification directe Microsoft Entra pour un serveur lié dans Azure SQL Managed Instance, vous avez besoin des prérequis suivants :
- le même principal est ajouté en tant que connexion sur le serveur distant ; et
- les deux instances sont membres du groupe d’approbations SQL.
Remarque
Les définitions existantes des serveurs liés que vous avez configurés pour le mode pass-through prennent en charge l’authentification Microsoft Entra. La seule exigence est d’ajouter SQL Managed Instance au groupe d’approbations serveur.
Les limitations suivantes s’appliquent à l’authentification Microsoft Entra pour les serveurs liés dans Azure SQL Managed Instance :
- L'authentification Microsoft Entra n'est pas prise en charge pour les instances SQL Managed Instance dans différents clients Microsoft Entra.
- L'authentification Microsoft Entra pour les serveurs liés est prise en charge uniquement avec le pilote OLE DB version 18.2.1 et ultérieure.
SQL Server 2025 et MSOLEDBSQL version 19
À compter de SQL Server 2025 (17.x), le fournisseur MSOLEDBSQL utilise Microsoft OLE DB Driver 19 par défaut. Ce pilote mis à jour introduit des améliorations significatives de la sécurité, notamment la prise en charge de TDS 8.0 et TLS 1.3.
TDS 8.0 améliore la sécurité en ajoutant une nouvelle option de chiffrement et introduit un changement majeur : le paramètre Encryption n’est plus facultatif. Vous devez le définir dans votre chaîne de connexion lors de la cible d’une autre instance SQL Server.
Remarque
Sans le paramètre Encrypt, les serveurs liés dans SQL Server 2025 (17.x) utilisent par défaut Encrypt=Mandatory et nécessitent un certificat valide. Les connexions sans certificat valide échouent.
Le Encryption paramètre offre trois paramètres distincts :
-
Yes, ou , ouTrue, ouMandatory -
No, ou , ouFalse, ouOptional Strict
L’option Strict impose l’utilisation de TDS 8.0 et nécessite un certificat de serveur pour les connexions sécurisées. Pour Yes/True/Mandatory, un certificat approuvé est attendu. Vous ne pouvez pas utiliser un certificat auto-signé.
| Version OLE DB | Paramètre de chiffrement | Valeurs possibles | Valeur par défaut |
|---|---|---|---|
| OLE DB 18 | Optionnel |
Trueou , Mandatory ou FalseNo |
No |
| OLE DB 19 | Required |
No ou False, Yes ou Mandatory, Strict (nouveau) |
Yes |
Le TrustServerCertificate paramètre est pris en charge, mais pas recommandé. Définir Certificat de Confiance du Serveur à Yes désactive la validation des certificats, ce qui affaiblit la sécurité des connexions chiffrées. Pour utiliser le certificat de serveur d’approbation , le client doit également l’activer dans le registre d’ordinateurs. Pour plus d’informations sur l’activation du certificat de serveur d’approbation, consultez les paramètres du Registre. Le paramètre TrustServerCertificate=Yes n’est pas recommandé pour les environnements de production.
Lorsque vous utilisez Encrypt=False ou Encrypt=Optional:
- Aucun certificat n’est requis.
- Si un certificat approuvé est fourni, le pilote ne le valide pas.
- La connexion ne fournit aucun chiffrement.
Lorsque vous utilisez Encrypt=True ou Encrypt=Mandatory, et que vous n’utilisez TrustServerCertificate=Yespas :
- La connexion nécessite un certificat signé par l’autorité de certification valide.
- Le certificat doit correspondre au nom de domaine complet du serveur.
- Si le nom alternatif du certificat diffère du nom d'hôte SQL Server, il
HostNameInCertificatedoit être défini sur le FQDN. - Le certificat doit être installé dans le magasin Autorités de Certification Racines de confiance sur l'ordinateur client.
Lorsque vous utilisez Encrypt=Strict:
- La connexion applique TDS 8.0.
- La connexion nécessite un certificat signé par l’autorité de certification valide avec une correspondance de nom de domaine complet.
-
HostNameInCertificatedoit être défini sur le FQDN (nom de domaine complet). - Le certificat doit être approuvé par le système client.
-
TrustServerCertificatela configuration n’est pas prise en charge. Un certificat valide doit être présent.
| Paramètre client Faire confiance au certificat de serveur | Chaîne de connexion/attribut de connexion Trust Server Certificate | Validation de certificat |
|---|---|---|
| 0 |
No (valeur par défaut) |
Oui |
| 0 | Yes |
Oui |
| 1 |
No (valeur par défaut) |
Oui |
| 1 | Yes |
Non |
Vous devez spécifier correctement ces paramètres dans la chaîne de connexion lors de la configuration des connexions de serveur lié pour garantir la compatibilité et la sécurité avec le nouveau pilote.
Mise à jour des versions précédentes d’OLEDB
S’applique à : SQL Server 2025 (17.x) et versions ultérieures
Lorsque vous migrez des éditions précédentes de SQL Server vers SQL Server 2025 (17.x) avec Microsoft OLE DB Driver 19, les configurations de serveur liées existantes peuvent échouer. Différentes valeurs par défaut pour le paramètre de chiffrement peuvent entraîner cet échec, sauf si vous fournissez un certificat valide.
Vous pouvez également recréer le serveur lié et l’inclure Encrypt=Optional dans la chaîne de connexion. Si vous ne pouvez pas modifier la configuration du serveur lié, activez l’indicateur 17600 de trace pour maintenir le comportement et les valeurs par défaut OLE DB 18.
Dans l’Assistant Création de serveur lié SQL Server Management Studio (SSMS), utilisez l’option Autres sources de données pour configurer manuellement les options de chiffrement du serveur lié.
Pour plus d’informations sur le chiffrement et le chiffrement OLE DB 19, le comportement de certificat et de certificat de serveur de confiance pour OLE DB 19, consultez Chiffrement et validation de certificat dans OLE DB.