Optimisation des requêtes distribuées
Pour améliorer les performances, SQL Server effectue les types d'optimisation suivants spécifiques aux requêtes distribuées :
Exécution de requêtes distantes à l'aide des fournisseurs de commandes SQL OLE DB.
Un fournisseur OLE DB est considéré comme un fournisseur de commandes SQL si le fournisseur OLE DB répond aux exigences minimales suivantes :
Prise en charge de l'objet Command et de toutes ses interfaces obligatoires.
Prise en charge de la syntaxe DBPROPVAL SQL SUBMINIMUM, d'ISO au niveau d'entrée ou supérieur ou d'ODBC au niveau principal ou supérieur. Le fournisseur devra présenter ce niveau de dialecte par l'intermédiaire de la propriété DBPROP_SQLSUPPORT OLE DB.
Accès indexés à l'aide des fournisseurs d'index OLE DB.
Un fournisseur OLE DB Provider est considéré comme un fournisseur d'index si le fournisseur OLE DB répond aux exigences minimales suivantes :
Prise en charge de l'interface IDBSchemaRowset avec les ensembles de lignes de schéma TABLES, COLUMNS et INDEXES.
Prise en charge de l'ouverture d'un ensemble de lignes sur un index à l'aide de IOpenRowset en spécifiant le nom d'index et le nom de la table de base correspondante.
L'objet Index doit prendre en charge toutes ses interfaces obligatoires : IRowset, IRowsetIndex, IAccessor, IColumnsInfo, IRowsetInfo et IConvertTypes.
Les ensembles de lignes ouverts sur une table de base indexée (à l'aide de IOpenRowset) doivent prendre en charge l'interface IRowsetLocate pour effectuer des placements sur une ligne marquée par un signet récupéré dans l'index.
Exécution de requêtes distantes
SQL Server tente autant que possible de déléguer l'évaluation d'une requête distribuée au fournisseur de commandes SQL. Une requête SQL qui n'accède qu'aux tables distantes stockées dans la source de données du fournisseur est extraite de la requête distribuée d'origine et exécutée sur le fournisseur. Ce comportement a pour effet de réduire le nombre de lignes retournées à partir du fournisseur et permet à ce dernier d'utiliser ses index lors de l'évaluation de la requête.
Les considérations qui affectent dans quelle mesure la requête distribuée d'origine est déléguée au fournisseur de commandes SQL sont les suivantes :
le niveau de dialecte pris en charge par le fournisseur de commandes SQL ;
la compatibilité du classement.
Niveau de dialecte pris en charge par le fournisseur de commandes SQL
SQL Server ne délègue les opérations que si elles sont prises en charge par le niveau de dialecte spécifique. Les niveaux de dialecte du plus élevé au moins élevé sont : SQL Server, niveau d'Entrée ISO, niveau principal ODBC et Jet. Plus le niveau de dialecte est élevé, plus SQL Server peut déléguer d'opérations au fournisseur.
[!REMARQUE]
Le niveau de dialecte SQL Server est utilisé quand le fournisseur correspond à un serveur lié SQL Server.
Chaque niveau de dialecte est un sur-ensemble des niveaux inférieurs. Par conséquent, si une opération est déléguée à un niveau particulier, elle est également déléguée à tous les niveaux supérieurs.
Les requêtes qui impliquent les types de données bit et uniqueidentifer ne sont jamais déléguées à un fournisseur et sont toujours évaluées localement :
Lorsque l'option SET CONCAT_NULL_YIELDS_NULL est OFF, la concaténation de chaînes est toujours effectuée localement.
Les opérations/éléments syntaxiques suivants sont délégués au niveau de dialecte indiqué (et à tous les niveaux supérieurs) :
SQL Server : jointure externe, CUBE, ROLLUP, opérateur modulo (%), opérateurs bit-wise, fonctions de chaîne et fonctions système arithmétiques.
Niveau d'entrée ISO : UNION et UNION ALL.
Niveau principal ODBC : fonctions d'agrégation avec DISTINCT et constantes de chaîne.
Jet : fonctions d'agrégation sans DISTINCT, tri (ORDER BY), jointures internes, prédicats, opérateurs de sous-requêtes (EXISTS, ALL, SOME, IN), DISTINCT, opérateurs arithmétiques non mentionnés dans les niveaux supérieurs, constantes non mentionnées dans les niveaux supérieurs et tous les opérateurs logiques.
Par exemple, toutes les opérations à l'exception de celles qui impliquent CUBE, ROLLUP, jointure externe, opérateur modulo (%), opérateurs bit-wise, fonctions de chaîne et fonctions système arithmétiques sont déléguées à un fournisseur de niveau d'entrée ISO qui n'est pas en même temps SQL Server.
Compatibilité du classement
Pour une requête distribuée, la sémantique de comparaison de toutes les données de caractères est définie par le jeu de caractères et l'ordre de tri de l'instance locale de SQL Server. SQL Server prend en charge les classements multiples. Le classement des données peut être différent d'une colonne à l'autre et chaque valeur de caractère est associée à une propriété de classement. SQL Server interprète la propriété de classement des données de caractère provenant d'une source de données distante et la traite en conséquence. Pour plus d'informations sur le classement des colonnes distantes, consultez Classements dans les requêtes distribuées.
SQL Server ne peut déléguer les opérations de comparaison et ORDER BY sur des colonnes de caractères à un fournisseur que s'il est capable de déterminer les éléments suivants :
La source de données sous-jacente utilise la séquence de classement et le jeu de caractères de la colonne.
La sémantique de comparaison de caractères respecte la norme ISO (et SQL Server).
La rubrique Classements dans les requêtes distribuées récapitule la façon dont SQL Server détermine un classement pour chaque colonne. Si la source de données distante prend en charge ce classement, le fournisseur est considéré comme compatible avec le classement.
Autres considérations de prise en charge de SQL
Les éléments de syntaxe SQL suivants ne sont pas dictés par les niveaux de dialecte de SQL :
Prise en charge des requêtes imbriquées
Si le fournisseur prend en charge les requêtes imbriquées (sous-requêtes),SQL Server peut lui déléguer ces opérations. La prise en charge des requêtes imbriquées ne pouvant pas être déterminée automatiquement à partir des propriétés OLE DB, l'administrateur système doit définir l'option du fournisseur NestedQueries afin d'indiquer à SQL Server que le fournisseur prend en charge les requêtes imbriquées.
Prise en charge des marqueurs de paramètres
Si le fournisseur prend en charge l'exécution des requêtes paramétrées à l'aide du marqueur de paramètre ? à l'intérieur d'une requête, SQL Server peut lui déléguer l'exécution des requêtes paramétrées. La prise en charge des marqueurs de paramètres ne pouvant pas être déterminée automatiquement à partir des propriétés OLE DB, l'administrateur système doit définir l'option du fournisseur DynamicParameters afin d'indiquer à SQL Server que le fournisseur prend en charge les marqueurs de paramètres.
Prise en charge de LIKE
Si le fournisseur prend en charge l'opérateur LIKE tel qu'implémenté dans la syntaxe et la sémantique SQL Server, l'option de fournisseur SqlServerLike peut être définie afin d'indiquer la prise en charge.
Pour plus d'informations sur la définition de ces options de fournisseur, consultez Configuration des fournisseurs OLE DB pour l'exécution de requêtes distribuées.
Accès indexé
SQL Server peut utiliser des stratégies d'exécution qui impliquent l'utilisation des index du fournisseur d'index pour évaluer les prédicats et effectuer des opérations de tri sur des tables distantes. Pour activer l'accès indexé sur un fournisseur, définissez l'option de fournisseur IndexAsAccessPath.
De plus, en cas d'utilisation d'index impliquant des colonnes de caractères, attribuez à l'option de configuration du serveur lié collation compatible la valeur true pour le serveur lié correspondant. Pour plus d'informations, consultez sp_serveroption (Transact-SQL).
[!REMARQUE]
Affichez graphiquement le plan d'exécution à l'aide de SQL Server Management Studio afin de déterminer le plan d'exécution pour une requête distribuée donnée. Lorsque l'exécution des requêtes distantes est employée dans le plan d'exécution, elle est représentée à l'aide de l'opérateur logique et physique Remote Query. L'argument de cet opérateur montre la requête exécutée à distance.