Interrogez deux bases de données SQL Server sur deux serveurs différents
Supposons que j'ai deux serveurs de base de données (DB-SERVER-1 & DB-SERVER-2) et il existe une seule base de données sur chaque serveur (DB1 & DB2). Les deux sont des bases de données SQL Server.
Est-il possible d'interroger les deux bases de données dans la même commande ou fonction T-SQL? Peut-être en se connectant à l'un, puis en obtenant un ensemble de résultats, puis en se connectant à l'autre et en obtenant cet ensemble de résultats. Ensuite, effectuer une union avec les deux jeux de résultats?
Je peux le faire à partir de .NET ou Java code, mais je veux le faire strictement du côté de la base de données. Est-ce même possible?
Vous pouvez en effet le faire, mais je vous le déconseille. Vous pouvez créer un serveur lié sur DB-SERVER-1, en le connectant à DB-SERVER-2.
(Une définition de serveur lié est configurée par le DBA. Elle contient les informations d'identification de connexion au serveur distant. Si vous souhaitez fournir vous-même les informations d'identification de connexion à chaque fois, ce serait un openquery ou openrowset commander.)
Vous pouvez alors écrire une requête en utilisant la convention de dénomination en quatre parties comme suit, en supposant que vous exécutez cette requête sur DB-SERVER-1:
select *
from DB1.dbo.YourTable a
join [DB-SERVER-2].DB2.dbo.OtherTable b on b.ID = a.ID
Les jointures entre serveurs sont connues pour leurs problèmes de performances. Je ne le ferais qu'à des fins administratives, et certainement pas contre de grands ensembles de résultats.
J'ai voté positivement réponse de Datagod parce que, techniquement, c'est correct sur la façon de l'accomplir. Cependant, je ferais la recommandation contraire. Cela signifie que je recommanderais d'utiliser des serveurs liés pour ce que vous faites. En effet, il semble que vous posiez la question de l'architecture Serveurs fédérés utilisant les techniques des vues partitionnées distribuées .
Il existe de nombreuses règles et normes à mettre en œuvre lors de l’architecture. Il est vrai que les serveurs liés ne doivent pas simplement être lancés dans n'importe quel mélange pour connecter plus d'un jeu de résultats de serveur. Il y a des raisons d'utiliser des objets et des techniques pour les bonnes raisons.
Exemple: j'ai utilisé avec succès des serveurs fédérés/vues distribuées dans un scénario VLDB qui nécessitait plusieurs serveurs. C'est à cela que sert cette technique. Ce sont des choses avancées, alors soyez prévenu, mais cela répond exactement à ce que vous devez faire pour utiliser correctement les serveurs liés dans le but des serveurs fédérés/vues distribuées.
Je voulais qu'un serveur soit notre année actuelle de données d'expédition, puis les 2 à 7 prochaines années sur des serveurs supplémentaires pour l'archivage. J'avais besoin d'utiliser plusieurs serveurs en raison du volume de données et d'utiliser les ressources du serveur indépendant pour chaque jeu de résultats de requête, en fonction de l'année de la demande.
La technologie de la vue distribuée dans le moteur savait à quel serveur aller et obtenir les résultats. En raison des contraintes de vérification. Est-ce cher: oui; ça marche comme il faut: oui. Les serveurs liés sont-ils stables: oui, mais nous avons dû tenir compte du point de défaillance. Donc, ce n'est pas quelque chose qui ne peut pas être planifié normalement avec des exigences similaires.
Assurez-vous que les requêtes distribuées sont correctement architecturées et testées pour les points de performances et d'échec.
En résumé: possible, oui; Faisable, oui; Recommandé car il est nécessaire pour les serveurs fédérés et les requêtes distribuées, oui; FORTEMENT recommandé, non sans une compréhension approfondie et des tests des techniques.