Résolution de vues distribuées partitionnées

Le processeur de requêtes SQL Server 2005 optimise les performances des vues partitionnées de données distribuées. L'aspect le plus important des performances d'une vue distribuée partitionnée est de minimiser la quantité de données à transférer entre des serveurs membres.

SQL Server 2005 construit des plans intelligents et dynamiques qui utilisent efficacement les requêtes distribuées pour accéder aux données à partir des tables membres distantes :

• Le processeur de requêtes utilise d'abord OLE DB pour récupérer les définitions des contraintes CHECK de chaque table membre. Ceci permet au processeur de requêtes de mapper la distribution des valeurs de clés entre les tables membres.
• Le processeur de requêtes compare les plages clés spécifiées dans la clause WHERE d'une instruction SQL au mappage qui représente la distribution des lignes dans les tables membres. Le processeur de requêtes construit alors un plan d'exécution des requêtes qui utilise les requêtes distribuées pour récupérer uniquement les lignes distantes requises pour exécuter l'instruction SQL. Le plan d'exécution est également construit de telle sorte que tout accès aux tables membres distantes pour les données ou les métadonnées est différé jusqu'à ce que les informations soient requises.

Par exemple, prenons un système où une table de clients est partitionnée entre Server1 (CustomerID de 1 à 3299999), Server2 (CustomerID de 3300000 à 6599999) et Server3 (CustomerID de 6600000 à 9999999).

Étudiez le plan d'exécution qui est construit pour chaque requête exécutée sur Server1 :

SELECT *
FROM CompanyData.dbo.Customers
WHERE CustomerID BETWEEN 3200000 AND 3400000

Le plan d'exécution pour cette requête extrait les lignes avec des valeurs de clés CustomerID de 3200000 à 3299999 de la table membre locale et émet une requête distribuée pour récupérer les lignes dont les valeurs de clés sont comprises entre 3300000 et 3400000 de Server2.

Le processeur de requêtes SQL Server 2005 peut également créer une logique dynamique dans les plans d'exécution de requêtes pour les instructions SQL dont les valeurs de clés ne sont pas connues au moment de la construction du plan. Prenons par exemple cette procédure stockée :

CREATE PROCEDURE GetCustomer @CustomerIDParameter INT
AS
SELECT *
FROM CompanyData.dbo.Customers
WHERE CustomerID = @CustomerIDParameter

SQL Server 2005 ne peut pas prévoir quelle valeur de clé sera fournie par le paramètre @CustomerIDParameter à chaque exécution de la procédure. Puisque la valeur de la clé ne peut pas être prévue, le processeur de requêtes ne peut pas non plus prévoir quelle table membre devra faire l'objet d'un accès. Pour gérer ce cas, SQL Server construit un plan d'exécution comportant une logique conditionnelle, qu'on appelle aussi des filtres dynamiques, pour contrôler quelle table membre fait l'objet d'un accès en fonction de la valeur du paramètre d'entrée. En partant du principe que la procédure stockée GetCustomer a été exécutée sur Server1, la logique du plan d'exécution peut être représentée sous la forme suivante :

IF @CustomerIDParameter BETWEEN 1 and 3299999
   Retrieve row from local table CustomerData.dbo.Customer_33
ELSEIF @CustomerIDParameter BETWEEN 3300000 and 6599999
   Retrieve row from linked table Server2.CustomerData.dbo.Customer_66
ELSEIF @CustomerIDParameter BETWEEN 6600000 and 9999999
   Retrieve row from linked table Server3.CustomerData.dbo.Customer_99

SQL Server 2005 crée parfois ces types de plans d'exécution dynamique même pour des requêtes qui ne sont pas paramétrées. L'optimiseur peut paramétrer une requête de façon à ce que le plan d'exécution puisse être réutilisé. Si l'optimiseur paramètre une requête faisant référence à une vue partitionnée, il ne peut plus supposer que les lignes requises proviendront d'une table de base spécifiée. Il devra alors utiliser des filtres dynamiques dans le plan d'exécution. Pour plus d'informations, consultez Paramétrage simple.