Version imprimable
Salut,
J'aimerai comparer 2 requêtes différentes sur une base en production :
Les 2 dernières permettent les mesures sans se baser sur le cache, mais sur une base en production c'est un peu problématique de vider ce cache non ?Code:
2
3
4
Bonjour,
SET STATISTICS TIME vous détaille la quantité de temps CPU consommé par la requête, ainsi que sa durée totale d'exécution.
Si le temps CPU est supérieur à la durée d'exécution, c'est que la requête a été parallélisée.
SET STATISTICS IO vous détaille les IOs, en donnant :
- les lectures logiques (faites directement en RAM)
- les lectures physiques en avance de phase : données récupérées sur les disques et chargées en RAM avant que le moteur ne les traite
- les lectures physiques : données récupérées sur les disques au moment de les traiter car elles n'étaient pas déjà en RAM
- dans le cas des index columnstore, les segments éliminés et lus, et d'autres éléments
En effet toute modification de données dans tout bon SGBDR se fait uniquement en RAM, vitesse d'accès oblige.
DBCC DROPCLEANBUFFERS, quand on souhaite comparer les performances de deux requêtes, me semble être peu intéressant.
Cela vous permet de tester la performance des disques, et il faudrait, pour bien faire, l'exécuter entre les deux requêtes.
Quoi qu'il en soit, cette instruction est globale à l'instance et évince de la RAM toutes les pages qui n'ont pas été modifiées depuis qu'elles sont été copiées depuis les disques, ou depuis qu'elles ont été persistées sur disque après leur modification. Par ailleurs, cette instruction est globale à l'instance, donc si vos collègues travaillent sur la même que vous, ils vont se retrouver avec des lenteurs pendant quelques minutes. On imagine aisément le désagrément causé si l'on exécute une telle instruction en production : ce sont les disques qui vont chauffer ! ;)
DBCC FREEPROCCACHE évince du cache tous les plans de requête. Cette instruction est aussi globale à l'instance lorsqu'on ne lui passe pas en paramètre un handle de plan pour en évincer un en particulier et forcer ainsi sa recompilation.
En effet toute requête est compilée en un plan qui est réutilisé lors des exécution subséquentes de la même requête (au caractères près). Ceci existe car le processus de compilation est gourmand en temps CPU; donc si on devait optimiser les requêtes comme elles arrivent, on consommerait plus de CPU à les optimiser qu'à les exécuter.
Cette dernière instruction est intéressante lorsqu'on teste les performances des requêtes sous deux versions de l'optimiseur, c'est à dire au moins sous SQL Server 2014.
En effet, sous cette version, la base de données en mode de compatibilité 120 utilise le nouvel optimiseur par défaut; un niveau de compatibilité inférieur utilise l'ancien par défaut.
Sous SQL Server 2016, l'option de configuration de base de données LEGACY_CARDINALITY_ESTIMATION permet de conserver le mode de compatibilité 130 tout en utilisant l'ancien optimiseur.
Tout cela pour dire qu'il faut bien comprendre l'effet de chacune de ces instructions. Les deux dernières que vous donnez sont aussi répandues qu'incomprises ;)
@++ ;)
Ok, merci bien Elsuket pour ces précisions sur les 2 DBCC. ;)