Serveurs liés (Moteur de base de données)

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 des sources de données distantes et d'exécuter des commandes sur les 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 général, les serveurs liés sont configurés pour permettre au moteur de base de données d’exécuter une instruction Transact-SQL qui inclut des tables situées dans une autre instance de SQL Server ou un autre produit de base de données comme Oracle. De nombreux types de sources de données OLE DB peuvent être configurés comme serveurs liés, notamment des fournisseurs de bases de données tiers et Azure Cosmos DB.

Remarque

Les serveurs liés sont disponibles dans le moteur de base de données SQL Server et dans Azure SQL Managed Instance. Ils ne sont pas activés dans les pools élastiques et Singleton Azure SQL Database. Il existe certaines contraintes dans SQL Managed Instance qui sont décrites ici.

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. Ils constituent une bonne solution dans les scénarios où vous devez implémenter le partitionnement de base de données sans avoir à 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 (Transact-SQL). 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 (Transact-SQL). 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 accessible 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 différents fichiers et formats de fichiers, dont les fichiers texte, les données incluses dans des feuilles de calcul et les résultats de recherches de contenu.

À partir de SQL Server 2019 (15.x), le pilote Microsoft OLE DB Driver pour SQL Server (MSOLEDBSQL) (PROGID : MSOLEDBSQL) est le fournisseur OLE DB par défaut. Dans les versions antérieures, le fournisseur OLE DB SQL Server Native Client (SQLNCLI) (PROGID : SQLNCLI11) était le fournisseur OLE DB par défaut.

Important

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.

Les serveurs liés à des sources Microsoft Access et Excel ne sont pris en charge par Microsoft que lors de l'utilisation du fournisseur Microsoft.JET.OLEDB.4.0 OLE DB de 32 bits.

Remarque

Les requêtes distribuées de SQL Server ont été conçues pour être utilisées avec tout 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.

Diagram showing client tier, server tier, and database server tier

Généralement, les serveurs liés sont utilisés pour le traitement des 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.

Remarque

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.

Important

Lorsqu'un fournisseur OLE DB est utilisé, le compte sous lequel le service SQL Server. s'exécute doit disposer d'autorisations de lecture et d'exécution sur le répertoire et sur tous les sous-répertoires correspondants dans lequel le fournisseur est installé. Cela inclut les fournisseurs mis en production par Microsoft, ainsi que tous les fournisseurs tiers.

Remarque

Les serveurs liés prennent en charge l’authentification directe Active Directory au moment de l’utilisation de la délégation totale. À partir 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.

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

Pendant que vous configurez un serveur lié, inscrivez les informations de connexion et les informations relatives aux sources de données dans SQL Server. Une fois cette source de données enregistrée, vous pouvez y faire référence avec un nom logique unique.

Vous pouvez utiliser des procédures stockées et des affichages catalogue pour gérer les définitions de serveurs liés :

  • 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 serveuret sélectionnez Nouveau, puis 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 nom_serveur_lié.catalog.schéma.nom_objet.

Remarque

Les serveurs liés peuvent être définis de façon à repointer (en bouclage) vers le serveur sur lequel ils sont définis. 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 conçus à des fins de test et ne sont pas pris en charge pour de nombreuses opérations, telles que les transactions distribuées.

Authentification du serveur lié Azure SQL Managed Instance

Les serveurs liés à Azure SQL Managed Instance prennent en charge l'authentification SQL et l'authentification avec Microsoft Entra ID (ancien Azure Active Directory). Les deux modes d'authentification Microsoft Entra pris en charge sont les suivants : authentification avec identité managée et authentification directe. L’authentification avec identité managée peut être utilisée pour autoriser les connexions locales à interroger des serveurs liés distants. L’authentification directe autorise un principal qui peut s’authentifier auprès d’une instance locale pour accéder à une instance distante par le biais d’un serveur lié. L’authentification directe exige que le même principal soit ajouté en tant que connexion sur le serveur distant et que les deux instances soient membres du groupe d’approbations SQL.

Remarque

Les définitions existantes des serveurs liés qui ont été configurés pour l'authentification directe prennent en charge l'authentification Microsoft Entra. Pour ce faire, la seule exigence est l'ajout de SQL Managed Instance au groupe d'approbations de serveurs.

Limitations de l'authentification Microsoft Entra

  • L'authentification Microsoft Entra n'est pas prise en charge pour 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.
  • L'authentification Microsoft Entra pour les serveurs liés de SQL Managed Instance à SQL Server est prise en charge uniquement pour les connexions locales mappées. La propagation du contexte de sécurité n’est pas prise en charge. Cela signifie que l’authentification avec identité managée est prise en charge, mais que l’authentification directe ne l’est pas.

MSOLEDBSQL19 et serveurs liés

Actuellement, MSOLEDBSQL19 empêche la création de serveurs liés sans chiffrement et sans certificat approuvé (un certificat auto-signé est insuffisant). Si vous avez besoin de serveurs liés, utilisez la version prise en charge existante de MSOLEDBSQL.

Voir aussi

Étapes suivantes