lundi 18 juin 2007

Gestion des requêtes sur les vues partitionnées...

Bonsoir à tous !

Suite à de nombreux problèmes rencontrés avec les vues partitionnées, je souhaite clarifier certaines règles d'usage pour éviter tout problème avec ces éléments capricieux.

Tout d'abord, je voudrai parler du cas des champs date utilisés comme clé de partition. L'optimiseur de SQL Server n'est pas capable d'interpréter correctement les clauses CHECK sur ce type de données.
Le plus simple est alors de créer un champ acceptant l'optimisation des vues partitionnées. Par exemple, le plus simple avec une clé de partition sur l'année est de créer un champ de type INT contenant cette information.

Ainsi, la clé de partition ne sera plus le champ date qui nous posait problème, mais bien le champ INT qui lui sera supporté sans aucun problème.

Je souhaiterai ensuite évoquer les problèmes liés au mode de requêtage. En effet, l'optimiseur de requête de SQL Server effectuant le processus de Paramétrisation avant le processus de Planification de la requête, SQL Server ne procède pas aux optimisations nécessaires lors de la requête suivante :
DECLARE @TEST INT
SET @TEST = 50
SELECT Id, PartitionCol FROM VALL WHERE PartitionCol = @TEST


Nous pouvons alors privilégier le SQL Dynamique dans ce cas bien particulier, seule solution pour obtenir le résultat escompté.

Enfin, je voulai attirer ici l'attention sur l'importance des statistiques dans le cadre de l'utilisation des vues partitionnées. En effet, de mauvaises statistiques induisent le stockage d'un mauvais plan d'exécution. Les performances s'en ressentent alors de façon très importante, en particulier dans le cadre de l'utilisation de procédures stockées, où en cas de paramétrisation des requêtes ad hoc.

Bonne soirée !

Aucun commentaire: