Cet article fournit un exemple de création d'un serveur lié dans SQL Server à l'aide de Transact-SQL. L'utilisation de T-SQL vous permet de créer le serveur lié sans recourir à une interface utilisateur graphique (telle que SSMS).
Syntaxe
Pour créer un serveur lié à l'aide de T-SQL, utilisez le sp_addlinkedserver procédure stockée système.
La syntaxe officielle ressemble à ceci :
sp_addlinkedserver [ @server= ] 'server' [ , [ @srvproduct= ] 'product_name' ]
[ , [ @provider= ] 'provider_name' ]
[ , [ @datasrc= ] 'data_source' ]
[ , [ @location= ] 'location' ]
[ , [ @provstr= ] 'provider_string' ]
[ , [ @catalog= ] 'catalog' ]
La plupart des arguments sont facultatifs, mais vous devrez fournir le nom du serveur lié.
Vous souhaiterez probablement également spécifier la source de données ou l'emplacement du serveur lié, et peut-être un nom de fournisseur. Le catalog L'argument vous permet de spécifier une base de données par défaut à laquelle le serveur lié est mappé. Consultez la documentation officielle de Microsoft pour une explication de chacun de ces arguments.
Exemple - Créer le serveur lié
Pour créer un serveur lié à l'aide de T-SQL, exécutez le sp_addlinkedserver procédure stockée en passant le nom du serveur lié ainsi que sa source.
Voici un exemple de création d'un serveur lié :
EXEC sp_addlinkedserver
@server=N'Homer',
@srvproduct=N'',
@provider=N'MSOLEDBSQL',
@datasrc=N'172.17.0.2,1433',
@catalog='Music';
Dans ce cas, le nom du serveur lié est "Homer" et je spécifie l'adresse IP du serveur, suivie du port TCP (dans mon cas, il s'agit en fait d'un conteneur Docker sur la même machine). Modifiez le nom du serveur et l'adresse IP/le port selon vos besoins. Je spécifie également une base de données par défaut appelée "Musique".
Cet exemple utilise MSOLEDBSQL comme nom de fournisseur, mais vous pouvez utiliser le nom de fournisseur qui s'applique à votre situation. Dans mon cas, je suis lié à une autre instance de SQL Server.
Notez que MSOLEDBSQL est le fournisseur recommandé pour SQL Server. Si vous avez déjà utilisé SQLOLEDB ou SQLNCLI , ces deux éléments sont désormais obsolètes. Microsoft a décidé de déprécier OLE DB et de le publier en 2018.
Si vous deviez créer un lien vers Oracle, vous pourriez utiliser OraOLEDB.Oracle , pour MS Access, vous pouvez utiliser Microsoft.Jet.OLEDB.4.0 (pour Access les formats 2002-2003) ou Microsoft.ACE.OLEDB.12.0 (pour le format 2007). La documentation officielle contient un tableau des paramètres à utiliser pour différents scénarios.
Tester le serveur lié
Une fois que vous avez ajouté le serveur lié, vous pouvez utiliser sp_testlinkedserver pour le tester :
EXEC sp_testlinkedserver Homer;
Résultat (si réussi) :
Commands completed successfully.
Si vous obtenez une erreur "Échec de la connexion", il est probable que vous n'ayez pas de connexion correspondante sur le serveur distant. Vous aurez besoin d'avoir une connexion correspondante avec les mêmes informations d'identification que celle sur le serveur local.
La façon dont cela fonctionne est que, lorsque vous ajoutez le serveur lié pour la première fois, un mappage par défaut entre toutes les connexions sur le serveur local et les connexions distantes sur le serveur lié est automatiquement créé. SQL Server utilise les informations d'identification de la connexion locale lors de la connexion au serveur lié au nom de la connexion. Si votre connexion locale n'a pas de connexion correspondante sur le serveur distant, vous obtiendrez une erreur "Échec de la connexion".
Ajouter une connexion pour le serveur lié
Si vous ne souhaitez pas que le serveur lié utilise votre propre identifiant, vous pouvez spécifier un identifiant différent à utiliser. Tant que le serveur distant a une connexion correspondante avec les mêmes informations d'identification, vous serez prêt à partir. Évidemment, vous devrez vous assurer que le compte distant dispose des autorisations appropriées pour faire ce dont vous avez besoin.
Voici un exemple d'ajout d'une connexion SQL Server pour le serveur lié.
EXEC sp_addlinkedsrvlogin
@rmtsrvname=N'Homer',
@useself=N'FALSE',
@locallogin=NULL,
@rmtuser=N'Marge',
@rmtpassword=N'BigStrong#Passw0rd';
Exécutez ceci sur le serveur local après avoir créé le serveur lié. Vous aurez besoin d'une connexion correspondante avec les mêmes informations d'identification sur le serveur lié réel (distant).
Cela ajoute une connexion appelée "Marge" pour le serveur lié appelé "Homer". Tant que le serveur distant a une connexion avec les mêmes informations d'identification, le serveur local pourra se connecter au serveur lié.
Voir Ajouter une connexion au serveur lié dans SQL Server pour un exemple d'ajout d'une connexion correspondante sur le serveur distant.
Supprimer un serveur lié
Voici un exemple de suppression du serveur lié appelé "Homer" et de toutes les connexions associées.
EXEC sp_dropserver 'Homer', 'droplogins';
Les droplogins est facultatif, mais si vous ne le spécifiez pas lors de la suppression d'un serveur lié auquel sont associées des entrées de connexion de serveur distant et lié, ou qui est configuré en tant qu'éditeur de réplication, un message d'erreur est renvoyé.
Voir Supprimer un serveur lié à l'aide de T-SQL pour plus d'exemples de suppression d'un serveur lié.
Exécuter une requête distribuée sur le serveur lié
Maintenant que nous avons créé le serveur lié, voici un exemple d'exécution d'une requête distribuée sur celui-ci :
SELECT * FROM Homer.Music.dbo.Artists;
La seule différence entre cela et une requête locale est que vous devez ajouter le nom du serveur lié au FROM clause.
Comme ceci :
LinkedServer.Database.Schema.Table
Alternativement, vous pouvez utiliser OPENQUERY() pour exécuter une requête directe :
SELECT *
FROM OPENQUERY(
Homer,
'SELECT * FROM Music.dbo.Artists;'
);
