Plusieurs méthodes permettent
d'améliorer le temps de réponse pour
des requêtes portant sur des données
faussées :
• Utiliser des threads multiples pour
balayer une table. Si votre système
SQL Server fonctionne sur un ordinateur
SMP, l'optimiseur de requêtes applique des balayages de tables parallèles.
• Diviser la table en
utilisant les vues
partitionnées locales.
• Eviter d’utiliser des variables dans
des batch.
Vous pouvez appliquer toutes ces
méthodes dans des cas où l’optimiseur
de requêtes utilise un balayage de
tables – c’est-à -dire quand la sélectivité
de la valeur d’une colonne est basse.
Si votre ordinateur a plusieurs processeurs,
SQL Server pourrait diviser
les lignes d’une table en parties logiques
différentes et traiter ces parties
sur des processeurs différents, permettant
ainsi des balayages de tables parallèles.
Si l’optimiseur de requêtes s’applique
à un balayage de tables
parallèle, vous pouvez augmenter
grandement le temps de réponse de la
requête du listing 3, qui accède aux
données faussées dans la table customers. En utilisant sp_configure, SQL
Server auto-configure l’option de
configuration max degree of parallelism,
qui contrôle l’utilisation des requêtes
parallèles.
Quand vous appliquez des balayages
parallèles, SQL Server groupe
les lignes de la table. Ce groupage s’effectuant
en interne, l’utilisateur ne
peut pas l’influencer directement. En
revanche, si vous utilisez des vues partitionnées
distribuées (disponibles uniquement dans SQL Server 2000),
vous pouvez indiquer comment les
lignes de la table seront partitionnées.
Le principal avantage des vues partitionnées
distribuées est que l’optimiseur
de requêtes sait quelles valeurs
de la colonne de partitionnement se
trouvent dans quelle partition et peut
omettre la recherche dans les vues
qui ne contiennent pas la valeur provenant
d’un certain prédicat. Voyons
par exemple la requête du listing 4. Si
vous créez deux vues partitionnées
distribuées, une avec females et une
avec males, l’optimiseur de requêtes
recherchera les lignes de la vue allmale
pour satisfaire la requête.
Quant à éviter d’utiliser des variables
dans des batch, revenons au
listing 5. Pour exécuter la requête du
listing 5, l’optimiseur de requêtes ne
peut pas utiliser les statistiques existantes
parce qu’une variable dans l’un
des prédicats est jointe par l’opérateur
AND. C’est pour cette raison qu’il
faut éviter des batch contenant une
variable. Si vous devez utiliser une
telle requête dans un batch et si la valeur
de la colonne de jointure a une
haute sélectivité, il vaut mieux utiliser
le conseil de la requête INDEX pour
maintenir l’accès par index.
Téléchargez cette ressource
Guide EDI : Pratiques de Performance Opérationnelle
Comment mieux satisfaire les directions métiers, rationaliser les échanges, améliorer la qualité des données et gérer l’obsolescence ? Découvrez dans ce livre blanc, les principaux enjeux autour de l’échange de données informatisé, les technologies complémentaires à l’EDI pour gagner en efficacité et les innovations d’offres de services fournis par Generix Group pour digitaliser vos processus.