Pourquoi le réglage des performances SQL est-il si important pour la gestion des bases de données ?
Parce que cela peut vous faire économiser beaucoup d'argent. Restez avec moi et vous verrez comment.
Optimisation des performances SQL et gestion de la base de données :faire le lien
La plupart des professionnels des bases de données passent leur temps à garder les lumières allumées. Ils investissent la majeure partie de leurs efforts pour garantir la disponibilité en gardant un œil sur les ressources telles que la mémoire, le stockage et le débit du réseau. C'est une grande partie de la gestion des bases de données, mais à mesure que de plus en plus d'entreprises déplacent leurs bases de données vers des ressources cloud presque illimitées comme AWS et Azure, d'autres aspects sont devenus plus importants.
Le réglage des performances SQL est l'un de ces aspects. Une fois que les lumières sont allumées en toute sécurité et que vous remontez la hiérarchie des besoins dans la gestion de la base de données, la prochaine chose que vous voulez est une meilleure performance, et cela nécessite un réglage.
Premières questions à se poser lors du réglage des performances en SQL
Tôt ou tard, de nombreux professionnels des bases de données se retrouvent devant un serveur SQL qu'ils n'ont pas construit. Il n'y a pas beaucoup de guides pratiques pour cette situation. Le réglage des performances SQL est un exercice consistant à creuser, à déterminer ce qui ne va pas, puis à le corriger de manière itérative.
Dans vos premiers correctifs, vous ne pouvez même pas toucher du tout aux instructions SQL. Certains professionnels des bases de données commencent au niveau de l'utilisateur/de la session. Ils vont là où les utilisateurs sont mécontents, écoutent leurs plaintes et posent des questions.
- Quels écrans ou pages prennent trop de temps à s'afficher ?
- L'application est-elle plus lente lors de la création d'un nouveau ticket ou de l'ouverture d'un ticket existant ?
- L'enregistrement d'un enregistrement prend-il beaucoup de temps ?
- Combien de temps dure "longtemps ?"
Une fois qu'ils ont ces réponses, ils vont voir ce qui en est la cause dans la base de données.
C'est mieux que de s'asseoir le premier jour et de décider de gérer quelque chose comme la fragmentation, qui peut ne pas du tout affecter les utilisateurs. Le but est de commencer par ce qui intéresse les utilisateurs.
Pensez également au niveau de l'instance/de la base de données. Dans le monde Microsoft, par exemple, les tâches SQL Server Agent sont un bon point de départ. Il s'agit d'une série d'actions qui définissent généralement une tâche administrative dont vous pouvez surveiller la réussite ou l'échec. Ils sont censés être pratiques, mais comme beaucoup de choses dans la gestion de bases de données, ils ont tendance à s'accumuler à mesure que les gens oublient leur origine et ce qu'ils font.
Vous pouvez trouver plusieurs tâches faisant la même chose, comme exécuter différentes versions d'un script d'index ou, pire encore, travailler les unes contre les autres. Examinez les tâches déjà configurées à la lumière de deux questions :"Que fait cette tâche ?" et, plus important, "Si j'arrête ce travail, est-ce que quelque chose de mal arrivera ?"
Quels facteurs devez-vous rechercher ?
Une fois que vous atteignez le niveau de réglage des performances SQL, il prend ses repères pour le comportement de plusieurs facteurs. Comme décrit lors de notre webcast Ask the Experts :Database Performance Roundtable , vous pouvez passer moins de temps à régler le SQL lui-même si vous trouvez et interprétez correctement des facteurs comme ceux-ci :
- Blocage : Si le serveur bloque, c'est comme une bombe à retardement. Supposons qu'un script démarre une transaction et ne la ferme pas ; cela pourrait conduire à un fichier journal qui ne fait que grandir et grandir jusqu'à ce que l'espace soit épuisé. Le blocage est une mauvaise nouvelle pour les performances, alors recherchez-le dès le départ.
- Agents : En ce qui concerne les travaux de l'Agent SQL Server, les administrateurs sont connus pour encapsuler par inadvertance des tâches affectant les performances dans des travaux. Ils peuvent exécuter des transactions ou reconstruire des index dans une tâche, ou réduire la base de données dans une transaction. Dans un tel cas, envisagez de désactiver temporairement l'agent pour arrêter toutes les tâches associées. C'est une technique agressive, mais si elle améliore les performances, vous saurez pourquoi.
- Statistiques d'attente : Demandez-vous :« Qu'est-ce que le serveur attend en ce moment ? Des métriques telles que l'espérance de vie des pages et la longueur de la file d'attente du disque ont des réponses, mais elles n'offrent qu'une vue étroite. Les statistiques d'attente vous montrent tout à travers le prisme des types d'attente et des catégories d'attente, vous permettant de vous concentrer sur les cinq événements d'attente environ qui consomment le plus de temps. sp_BlitzFirst de Brent Ozar est une procédure stockée fiable pour découvrir ce que vos requêtes SQL Server attendent en ce moment. Ensuite, lorsque vous souhaitez étudier les tendances à long terme des statistiques d'attente de votre serveur, recherchez un outil de surveillance des performances.
- Activité de l'administrateur : Ceci est également connu sous le nom d '«erreur de pilote», car certains problèmes de performances découlent de ce que vous faites vous-même. Supposons que vous exécutiez à la fois SQL Server Activity Monitor et SQL Server Profiler en même temps, en essayant d'apprendre Query Store. Vous ne pouvez pas dépasser l'effet observateur ; quand vous suivez tout comme ça, vous demandez simplement à la base de données de ralentir.
- Index — Pour quelque chose qui est censé être bénéfique, les index peuvent certainement vous donner mal au cou. En fait, ils méritent plus qu'une seule balle. Continuez à lire.
L'optimisation des performances SQL implique d'examiner de près les index
Le réglage des performances SQL se résume en grande partie au réglage de l'index. Heureusement, si vous maîtrisez cela pour la gestion de bases de données sur site, vos compétences sont facilement transférables à la gestion de bases de données dans le cloud.
Le réglage des index gagne en importance en raison de l'évolution de la variété des index : cluster, non cluster, unique, filtré, columnstore, hachage, mémoire optimisée non cluster, XML, spatial et texte intégral, pour n'en nommer que quelques-uns. Mais une chose qui n'a jamais changé est la première colonne de l'index, qui pilote les décisions d'index prises par le moteur de base de données.
De nombreux fournisseurs vendent et déploient des applications avec de nombreux index bien intentionnés qui finissent par ne jamais être utilisés ou, pire encore, qui entravent les performances. Si vous examinez les scripts d'index inutilisés ou les scripts de consommation d'index dans certains produits logiciels, vous trouverez une surabondance d'index sur une clé étrangère. Si le produit utilise, par exemple, 20 clés étrangères, les fournisseurs peuvent fournir jusqu'à 20 index, plus dix index à colonne unique, plus dix autres index sur un index clusterisé unique, et ainsi de suite.
Chaque fois que vous en avez la possibilité, la meilleure façon d'aborder l'architecture de la base de données est de commencer avec un index clusterisé qui, selon vous, représentera le mieux la table. Ensuite, laissez le système s'exécuter pendant un certain temps. Si et comme vous avez besoin de plus d'index, créez-les. L'ajout d'index est un exercice consistant à échanger de meilleures performances ici avec des problèmes tels que le remplissage de l'espace disque et le verrouillage là-bas. Il devient difficile de voir comment chaque index supplémentaire affecte le système dans son ensemble.
D'ailleurs, envisagez d'éliminer les indices - la façon dont une personne souffrant d'allergies éliminerait les groupes d'aliments - pour voir comment les performances changent. Essayez de supprimer tous les index de votre instance de développement et voyez lesquels affectent vos cinq principales requêtes.
Optimisation des performances dans SQL Server :outils fournis avec
Notez que vous n'êtes pas seul dans cette entreprise. SQL Server inclut des fonctionnalités conçues pour améliorer les performances.
Les guides de planification vous permettent de modifier la façon dont SQL Server exécute une requête donnée, et même s'il ne s'agit pas d'un réglage des performances SQL pur, cela affecte les performances. De nombreuses applications contiennent des requêtes SQL écrites par un fournisseur externe, et même si ces requêtes entraînent de mauvaises performances, certains professionnels des bases de données sont naturellement réticents à les modifier. Avec les repères de plan, vous pouvez joindre un indice de requête ou un plan fixe à la requête et influencer son exécution.
Cependant, l'inconvénient des guides de plan est que, même s'ils ne changent pas avec le temps, l'environnement qui les entoure change. Comme une feuille de route imprimée, ils peuvent bien fonctionner à court terme et devenir obsolètes avant longtemps, donc si vous comptez sur eux, vous feriez mieux de les revoir de temps en temps.
Le magasin de requêtes est lié aux guides de planification. Il s'agit d'une fonctionnalité de SQL Server qui vous aide à identifier et à régler les requêtes qui consomment le plus de ressources dans votre système. Le magasin de requêtes n'est pas activé par défaut pour les nouvelles bases de données SQL Server et Azure Synapse Analytics (SQL DW). Mais il est activé par défaut dans les nouvelles bases de données Azure SQL.
En général, il n'est pas difficile d'activer Query Store, mais tous les serveurs SQL n'en ont pas besoin dès le départ. Certains administrateurs ne connaissent pas Query Store, et certains le savent mais n'ont pas encore pris le temps de l'explorer de manière adéquate; ils feraient mieux de le laisser désactivé. Plus tard, lorsqu'ils comprendront le fonctionnement de Query Store, ils pourront l'utiliser pour rechercher les différences de performances causées par les modifications du plan de requête.
Enfin, le Database Engine Tuning Advisor analyse les charges de travail et recommande des index ou des stratégies de partitionnement pour améliorer les performances des requêtes. Exécuter Tuning Advisor sur votre base de données est une bonne idée; ne l'exécutez pas trop tôt. Assurez-vous que votre base de données contient suffisamment de données pour que les recommandations d'index soient valides. Lorsque vous construisez votre application pour la première fois, vous pouvez n'avoir qu'un millier de lignes dans chaque table. Les recommandations de Tuning Advisor sont plus utiles une fois que la base de données a augmenté.
Montrez-moi l'argent
Comme je l'ai mentionné au début, le réglage des performances SQL est important pour la gestion de la base de données car il peut vous faire économiser de l'argent. Comment ?
Surtout dans le cloud, où la mise à l'échelle par carte de crédit est populaire, les équipes informatiques découvrent à quel point le stockage mensuel peut être coûteux. De plus, ils commencent à comprendre que l'exécution de requêtes mal écrites et le fait de laisser AWS et Azure gérer leurs index augmentent leurs coûts de cloud computing. Les requêtes lentes et les mauvais index vous coûtent de l'argent.
Le réglage des performances SQL consiste à faire en sorte que toutes ces choses soient correctes. Ainsi, que vous restiez dans le monde des OpEx sur site ou que vous migriez vers le monde CapEx du cloud, vous gardez le contrôle de vos dépenses.
