Requête distribuée (en quatre parties) ou OPENQUERY lors de l'exécution de requêtes de serveur lié dans SQL Server – Canal SQL Server de Sakthi – Bien choisir son serveur d impression

Je souhaitais partager ces informations avec tous ceux qui recherchent une meilleure performance en matière de requête distribuée par rapport à openquery pour l'exécution de requêtes de serveur lié.

Requête distribuée: Les requêtes en quatre parties d'un serveur lié sont également appelées requêtes distribuées. À l'aide de requêtes distribuées, vous pouvez faire référence à des tables sur différentes sources de données / serveurs en une seule requête. L'optimiseur de requêtes crée un plan d'exécution en consultant la nomenclature des requêtes et en le découpant en requêtes distantes et locales. Les requêtes locales sont exécutées localement et les données des requêtes distantes sont collectées à partir des serveurs distants, nettoyées localement, combinées et présentées à l'utilisateur final sous la forme d'un jeu d'enregistrements unique.

OpenQuery: Exécute la requête directe spécifiée sur le serveur lié spécifié. SQL Server envoie des requêtes directes sous forme de chaînes de requête non interprétées à une source de données OLE DB. Autrement dit, SQL n'appliquera aucune logique à la requête et n'essayera pas d'estimer son rôle, mais transmettra simplement la requête spécifiée telle quelle au serveur lié cible. Les requêtes ouvertes sont utiles lorsque vous ne faites pas référence à plusieurs serveurs dans une requête. Il est généralement rapide car SQL ne le divise pas en plusieurs opérations et n’exécute aucune action locale sur la sortie reçue.

Alors, quelle est la requête distribuée ou la requête ouverte la plus rapide et pourquoi?

La réponse est, en général, OPENQUERY serait plus rapide mais les requêtes distribuées pourraient être aussi rapides.

Par exemple, disons que j’ai lié le serveur entre deux instances SQL SQL1 et SQL2. Et je dois faire le compte compte (*) sur la table d'emp dans la base de données d'essai sur le serveur distant SQL2.

Requête distribuée serait quelque chose comme SELECT count (*) FROM [SQL2].[test].[dbo].[emp]

OPENQUERY serait SELECT * de OPENQUERY ([SQL2], 'SELECT count (*) FROM [test].[dbo].[emp]')

Si vous examinez le plan d'exécution en exécutant SET STATISTICS PROFILE ON, vous pouvez constater que, pour exécuter une requête distribuée, SQL1 envoie une demande à SQL2 afin d'envoyer les informations statistiques relatives à la table emp dans le test de base de données. Notez que le compte d'utilisateur qui exécute cette requête distribuée doit disposer de certaines autorisations sur le serveur distant, comme indiqué dans http://msdn.microsoft.com/en-us/library/ms175537.aspx pour pouvoir collecter des statistiques de distribution des données à partir du serveur. serveur distant sinon SQL Server risque de générer un plan de requête moins efficace et des performances médiocres. MISE À JOUR: Cela va être corrigé dans SQL Server 2012 afin que, si vous disposez de l'autorisation SELECT sur les colonnes de l'index / statistics ET que vous ayez l'autorisation SELECT sur toutes les colonnes de la clause FILTER (WHERE / HAVING) du serveur cible, vous pourrez pour obtenir l'histogramme. Important: La version de SQL Server 2012 avec le correctif doit être appliquée sur le serveur cible ou distant.

Nous avons constaté des problèmes dus à un nombre excessif de connexions exécutant des requêtes distribuées lors d'une attente SOSHOST_MUTEX pendant que SQL Server collectait des statistiques de distribution de données à partir du serveur distant. En outre, il convient de noter qu’une seule requête établit une connexion au moins deux fois avec le serveur distant en cas de requête distribuée, une première connexion pour rassembler des statistiques et une seconde connexion pour collecter les données réelles de la table.

Un autre inconvénient en cas de requête distribuée est que, bien que vous ayez une clause WHERE dans votre requête, vous remarquerez peut-être que lorsque la requête est envoyée pour extraire les lignes d'une table du serveur distant, SQL Server n'enverra qu'un SELECT * FROM table distante puis, localement, il filtre les données nécessaires après l’application des prédicats.

Mais dans OPENQUERY, SQL Server envoie la requête complète au serveur distant SQL2 et les ressources de SQL2 sont utilisées pour traiter la requête, comme pour analyser les instructions SQL, générer un plan et filtrer les lignes en fonction des prédicats. Le résultat final est ensuite envoyé à SQL1, qui n'affiche alors que ce qu'il a reçu de SQL2.

Maintenant, vous me dites lequel est le meilleur?

Autres lectures:

Requêtes distribuées – http://msdn.microsoft.com/en-us/library/ms188721.aspx

OPENQUERY – http://msdn.microsoft.com/en-us/library/ms188427.aspx

Consignes d'utilisation des requêtes distribuées – http://msdn.microsoft.com/en-us/library/ms175129.aspx

Comment passer une variable à une requête de serveur lié – http://support.microsoft.com/kb/314520

http://connect.microsoft.com/SQL/feedback/ViewFeedback.aspx?FeedbackID=475804 (demande de la communauté d'autorisations requise sur le serveur distant)