Les requêtes entre bases de données sont-elles coûteuses dans SQL Server?

15

Les requêtes entre bases de données sont-elles coûteuses dans SQL Server? Toutes les bases de données sont dans la même instance.

sql-server Jonathan Allen
la source
3
Je n'ai jamais trouvé de preuve qu'ils le soient, non. Les seules exceptions auxquelles je pourrais même penser (mais que je n'ai pas testées) sont (a) que l'optimiseur ne peut pas bénéficier de relations qui ne peuvent pas être explicites (par exemple, il peut bénéficier de définitions de clés étrangères, qui ne peuvent pas exister croisées). -database) ou (b) il y a des problèmes avec les statistiques étant un problème sur les serveurs liés, mais j'imagine qu'il peut y avoir des cas où même dans la base de données un utilisateur exécutant une requête ne peut pas voir les statistiques. Je ne sais pas si (b) est réel ou non - n'a pas été testé, sachez simplement que cela peut être un problème grave sur tous les serveurs.
Aaron Bertrand
2
Je suis avec @AaronBertrand sur celui-ci, je n'ai rien vu pour dire définitivement qu'il y a un énorme succès. La seule chose que je pourrais penser ajouterait quelque chose à l'équation serait peut-être une certaine forme d'opérations d'authentification, mais je doute que ce soit significatif. C'est juste moi qui pense à haute voix, je ne suis pas sûr. Votre meilleur pari ici serait de mettre en place un test / benchmark automatisé avec une base de données croisée, puis avec la même requête inter-base de données et d'exécuter ce test des milliers de fois. Obtenez la moyenne, le maximum, etc. et prenez votre décision en fonction de cela.
Thomas Stringer
1
@thomas pourriez-vous voir une différence définitive en regardant les plans de requête réels?
Max Vernon
@Jonathan: la définition de "cher" est relative à des alternatives. Alors, qu'essayez-vous de faire et que décidez-vous entre? Sans plus d'informations, il est tout à fait possible d'obtenir une réponse qui semble correcte à cette question à sa valeur nominale, mais en même temps, c'est absolument faux pour votre situation. Tout a un coût, mais ce coût peut être bon marché ou cher selon ce à quoi vous le comparez. Et les coûts des requêtes (c'est-à-dire le temps, les conflits, etc.) doivent être mis en balance avec les coûts de maintenance, les coûts de matériel, etc.
Solomon Rutzky
Je voudrais connaître le coût par rapport à une requête dans le même tableau.
Jonathan Allen

Réponses:

6

Désolé, je n'ai pas assez de réputation pour commenter la question, mais d'après mon expérience, si l'application cliente génère une transaction pour une requête qui utilise des jointures de bases de données croisées, elle favoriserait la transaction à distribuer et aurait les frais généraux d'une transaction DTC .

Les frais généraux DTC dans ce cas pourraient être considérés comme négatifs pour les performances. En général, la différence serait négligeable bien que Microsoft décrive les transactions DTC comme telles:

Les transactions distribuées consomment généralement des ressources système importantes

Promotion des transactions

... ce qui suggérerait une dégradation des performances si votre serveur ne peut pas offrir les ressources dont il a besoin.

Juste pour clarifier, l'article ci-dessus décrit les transactions locales promues lorsque des systèmes distants sont introduits, mais j'ai vu que cela devenait le cas pour les transactions sur le même serveur lors de l'utilisation de requêtes inter-bases de données.

Comme le souligne Thomas Stringer dans son commentaire, il y aura des frais supplémentaires pour l'authentification, bien que je pense que comme cela sera piloté par SID, il y aura des frais minimes là-bas, sauf si vous devez utiliser des informations d'identification distinctes pour accéder à l'autre base de données.

S'il y avait une différence dans les paramètres de la base de données qui entraînait une surcharge supplémentaire dans la jointure qui pourrait avoir un impact plus important que les suggestions précédentes - par exemple le classement de la base de données. Le classement de la base de données peut se manifester comme une différence fonctionnelle, et pas seulement comme une différence de performances.

Je pense qu'Aaron a l'argument le plus fort pour les performances, l'optimiseur n'ayant pas l'avantage d'utiliser des relations pour les requêtes inter-bases de données, alors que dans une base de données autonome, vous pouvez utiliser les relations à votre avantage.

LeedsDBA
la source
1
If a local transaction spans two or more databases on the same instance of the Database Engine, the instance uses an internal two-phase commit to commit all of the databases involved in the transaction.- Si vous avez trouvé le contraire, veuillez signaler un bug sur Connect avec des étapes de reproduction claires.
Jon Seigel
1
L'article sur la promotion des transactions concerne les transactions CLR.
stacylaray
-2

Dans SQL Server 2014, les tables optimisées en mémoire ne prennent pas en charge les transactions entre bases de données. Vous ne pouvez pas accéder à une autre base de données à partir de la même transaction ou de la même requête qui accède également à une table optimisée en mémoire. Vous ne pouvez pas facilement copier des données d'une table dans une base de données vers une table optimisée en mémoire dans une autre base de données. http://msdn.microsoft.com/en-us/library/dn584627(v=sql.120).aspx Les transactions distribuées et inter-bases de données ne sont pas prises en charge pour la mise en miroir de bases de données / AOAG. http://technet.microsoft.com/en-us/library/hh393530.aspx . Si vous allez utiliser le chaînage de propriété, soyez conscient des risques de sécurité http://msdn.microsoft.com/en-us/library/ms188676.aspx

stacylaray
la source
Cela ne s'applique qu'aux scénarios qui "des ressources qui s'étendent sur plusieurs instances ou serveurs". Dans ce cas, nous parlons d'une seule instance avec plusieurs bases de données.
Jonathan Allen
1
Mon mauvais ... j'ai raté la partie sur le fait qu'il soit dans la même instance
stacylaray