Brent Ozar sait tout sur la rapidité - il fait la course avec des voitures et il accélère les serveurs SQL avec des résultats de performances de base de données à couper le souffle quotidiennement. Dans son webcast "Comment mesurer SQL Server", pour la série Quest's Database Training Days, Brent nous a rappelé que la performance est une question de mesure.
Accélération pour la performance
Brent en a profité pour pratiquer la distanciation sociale et a habillé le rôle en enfilant une combinaison de course complète et un casque. Lors de quelques plaisanteries pré-webcast, nous avons appris qu'il devait brancher un microphone dans le casque et coller les oreillettes sur ses oreilles ! Mais on s'égare. La webdiffusion était entièrement consacrée aux performances, et il y avait beaucoup d'analogies avec les voitures.
Pour améliorer les performances de SQL Server, les prémisses sont :
- Choisir des statistiques sur lesquelles se concentrer sur l'amélioration
- Mesurer les performances avant et après avoir effectué des modifications limitées (méthode scientifique de base)
- Comprendre quand vous avez le mauvais équipement pour ce que vous essayez d'accomplir
Métriques de réglage des performances de la base de données
Une longue discussion sur les camions Ford F150, les Ford Fiesta et quelques autres véhicules intéressants a montré qu'il existe différentes façons d'améliorer le temps nécessaire pour passer de 0 à 60 miles par heure. Vous pouvez réduire le poids du véhicule, ajouter un moteur plus gros ou commencer à éliminer les éléments non essentiels, comme un pare-brise. Il va y avoir un compromis entre performance et utilité. Les bases de données sont comme ça – elles sont souvent chargées. C'est à ce moment qu'un réglage personnalisé des performances est nécessaire, ce qui nécessite de connaître et d'améliorer les métriques.
Brent affirme qu'il existe trois paramètres principaux dont vous avez besoin pour régler les performances des voitures et des bases de données :le poids, la référence de vitesse (comme 0 à 60) et la force de travail du moteur (serveur).
Mesure de la taille de la base de données
Le poids pour SQL Server se traduit par la taille totale de la base de données et la quantité de données dont vous disposez. Ceci est généralement mesuré en gigaoctets ou téraoctets. De 1 à 150 Go environ, SQL Server Standard Edition devrait suffire. De 150 à 500 Go est une charge facile pour l'édition Enterprise. Au-delà de 500 Go, il importe de savoir s'il s'agit de données actives et comment elles sont accessibles. Et tout ce qui dépasse 1 To de données OLTP peut être très difficile.
Suivi de la vitesse des performances
La référence de vitesse dans les voitures est facile - MPH. Pour la base de données, il s'agit de requêtes par lot par seconde, mais cela doit être suivi toutes les heures pendant différentes périodes. Évidemment, plus il y a de requêtes, plus les performances seront lentes en fonction du matériel.
Évaluer les charges de travail des requêtes
Enfin, pour comprendre à quel point la base de données fonctionne, vous devez comprendre quelles requêtes sont en cours d'exécution et ce qui attend dans la file d'attente. Cela vous donnera un ratio de temps d'attente - en gros, combien de temps les tâches attendent-elles que les autres soient terminées. Votre ratio de temps d'attente sera exprimé en heures de temps d'attente par heure (ou en secondes de temps d'attente par seconde) - ne mélangez pas vos unités de mesure. Lorsque vous avez une bonne maîtrise de ces statistiques au fil du temps, vous pouvez voir ce qui affecte le temps d'attente, par exemple, s'il y a plus ou moins de requêtes par lots, des requêtes mieux ou moins bien réglées, etc. Ensuite, vous pouvez résoudre ces problèmes.
Regardez l'enregistrement du webinaire à la demande pour tous les conseils avisés et l'humour de Brent.
