Et si vous vous donniez la peine d'implémenter ou de mettre à niveau vers un nouveau serveur SQL pour une meilleure expérience pour vos clients, et qu'ils se plaignaient que les choses étaient en fait pires ?
Ne seriez-vous pas pris au dépourvu si vous franchissiez toutes ces étapes commerciales et techniques pour obtenir de meilleures performances SQL Server, et que vous ne le fassiez pas ?
Vous auriez peut-être dû effectuer des tests de performances SQL Server avant de passer en production. Vous sauriez alors si vos performances allaient s'améliorer, rester les mêmes ou, pire que tout, décliner.
Mais au moins, vous n'auriez pas été désagréablement surpris.
Le pont de performances SQL Server que nous traversons tous
Qu'il s'agisse de passer d'une autre base de données à SQL Server ou de passer d'une ancienne version de SQL Server à une version plus récente, vous deviez éventuellement franchir le pont des performances.
"Est-ce que ça va vraiment mieux fonctionner qu'avant ?" a demandé votre patron.
« Oh, bien sûr », avez-vous dit. « Avec la virtualisation des données dans SQL Server 2019, nous pouvons exécuter des requêtes sans déplacer ni répliquer les données. Et il y a un réglage automatique avec Intelligence Query Processing pour faire évoluer les requêtes. Les données vont VOLER hors des serveurs. Vous étiez si sûr de vous que vous avez mis en majuscule "VOL".
Alors, comment auriez-vous pu mieux tester vos performances ?
4 façons de tester les performances . . .
Brent Ozar, expert extraordinaire de SQL Server, vous explique comment vérifier les performances d'un nouveau serveur SQL :
- le moyen le plus simple, en comparant les temps avant et après sur une sauvegarde complète et CHECKDB
- la méthode la plus simple mais la plus erronée, avec une charge de travail synthétique et TPC-C dans HammerDB
- la méthode la plus difficile consiste à tester des requêtes individuelles avec sp_BlitzCache, son script d'analyse du cache de plan
- à la dure, en exécutant les mêmes requêtes que vous exécutez en production
Mais comme Brent le précise, surveiller les performances de votre serveur SQL et constater qu'il a chuté de X % n'est que le début; vous devez encore déterminer d'où vient le coup.
Cela signifie rechercher des tendances dans les données de performances sur des semaines et des mois entiers, et pas seulement sur les dernières heures.
Plus vous avez de points de données et d'historique, meilleure est l'image que vous pouvez assembler de ce qui se passe à l'intérieur, sous et autour de votre environnement SQL Server.
Et plus vous pouvez calculer toutes ces données, plus vous pouvez les analyser rapidement.
Surveillance des performances de SQL Server :cela ressemble à un travail pour le cloud
Ouais. C'est un travail pour le cloud, le seul endroit où vous pouvez évoluer suffisamment pour collecter et analyser toutes ces données afin d'obtenir une image large et approfondie de la façon dont SQL Server consomme les ressources. Et comment il a consommé ces ressources au fil du temps. Par exemple :
- À certains moments de la journée ou du mois, les requêtes fréquemment exécutées doivent lire à partir du disque au lieu du cache tampon, qui est la copie en mémoire des pages de base de données récemment utilisées. Avez-vous besoin d'allouer plus de mémoire à votre cache de tampon ? Pouvez-vous lui consacrer plus de mémoire ?
- Idem pour l'espérance de vie des pages. S'il est faible, c'est probablement parce que SQL Server supprime trop fréquemment les pages du cache de tampon et doit exécuter des recherches à partir du stockage au lieu de la mémoire. Cela nuit aux performances.
- Le temps d'attente maximal d'E/S devient-il trop élevé ? Quelle est la tendance ? C'est un indice que le périphérique d'E/S est peut-être saturé.
- Combien de temps dure la file d'attente du processeur ? C'est combien de temps en général ? Trop de threads en attente constante peuvent indiquer une congestion du processeur.
- Le processeur ne respecte-t-il pas les limites que votre serveur peut gérer ? Et si vous ne pouvez plus faire évoluer le serveur ? Si vous êtes sûr que vos requêtes sont bien réglées et que vos autres ressources système sont adéquates, vous devrez peut-être ajouter un socket pour le matériel physique ou les vCPU à vos VM.
- Les index fragmentés sont des index lents, mais vous ne savez pas qu'ils sont le coupable tant que vous n'avez pas vérifié les niveaux de fragmentation. Observer les effets de la réorganisation et de la reconstruction au fil du temps peut vous aider à mettre en place un processus de maintenance d'index fiable.
La détection de problèmes tels que ceux dans toutes vos bases de données sur site et dans le cloud devient plus facile et plus rapide lorsque vous pouvez surveiller les performances de votre serveur SQL à partir du cloud. Mieux encore, vous pouvez surveiller depuis n'importe où dans la galaxie connue lorsque tout le calcul, le stockage et l'analyse se trouvent dans le cloud et que vous n'êtes qu'à quelques clics de souris dans n'importe quel navigateur.
Commencez à tester les performances de votre serveur SQL dans le cloud
Chez Quest, personne n'a besoin de nous dire deux fois que nos clients veulent des outils basés sur le cloud, que ce soit pour la migration vers le cloud, la surveillance des performances ou Office 365. Nous proposons davantage de nos produits sous forme d'offres cloud parce que les technologies et les marchés les y attirent.
Alors, comment exécutez-vous des tests de performances sur vos serveurs SQL nouveaux ou mis à niveau ?
- J'exécute CHECKDB.
- J'utilise HammerDB.
- J'exécute les outils de Brent Ozar.
- Je teste avec des charges de travail de production.
- Je lance les dés et j'attends que les utilisateurs se plaignent.
- J'ai des gens qui font ça pour moi.
- J'utilise Spotlight Cloud de Quest. Vous devriez aussi.
