De nombreux facteurs influent sur les performances de la base de données. Connaître les fluctuations normales de votre instance particulière en surveillant votre serveur SQL vous aide à identifier les comportements incontrôlables et à anticiper les problèmes avant qu'ils ne surviennent.
Cela vous aide également à faire la distinction entre les difficultés de croissance naturelles causées par une charge de travail accrue ou des pics saisonniers qui peuvent simplement nécessiter plus de ressources et des problèmes de performances plus profonds qui nécessitent un réglage du code, une optimisation de l'index ou un réglage de la configuration.
Une fois que vous avez établi une liste de serveurs SQL dans votre environnement, vous voudrez poser quelques questions critiques :
- Quel est l'état de santé de cette instance ?
- Quand a-t-elle été sauvegardée pour la dernière fois ?
- Dispose-t-il d'un processeur, d'une mémoire et d'un espace de stockage suffisants pour respecter son SLA ?
- Quels types de charges de travail s'exécutent sur cette instance ?
- Quelles applications et quels utilisateurs utilisent cette instance ?
- Quand la charge de travail est-elle la plus chargée ?
- Une stratégie de basculement est-elle en place ?
- S'agit-il d'une instance critique ?
- Faut-il être disponible 24h/24 et 7j/7 ?
- Quel type de problèmes de performances cette instance rencontre-t-elle ?
Ces questions peuvent sembler évidentes, mais si vous commencez à surveiller les charges de travail de votre serveur SQL pour la première fois, vous serez surpris et peut-être un peu horrifié de voir combien d'entre elles ont des problèmes fondamentaux.
Définir des objectifs de performances pour la surveillance de SQL Server
Réfléchissez à ce que vous souhaitez accomplir avec vos efforts de surveillance de serveur SQL et hiérarchisez ces objectifs. En encadrant vos activités en termes d'indicateurs clés de performance, vous facilitez l'articulation de la valeur de l'énergie et des investissements nécessaires. La liste suivante vous aidera à démarrer.
Haute disponibilité
Quelles sont vos statistiques de disponibilité ? N'oubliez pas que l'indisponibilité pour l'utilisateur correspond au moment où il ne peut pas accéder au service. Cela peut être dû à une panne complète ou à un goulot d'étranglement des performances qui rend effectivement le service indisponible. Avez-vous une configuration permanente en place ? Si oui, connaissez-vous son statut ?
Temps de réponse
À partir du moment où un problème est signalé, à quelle vitesse pouvez-vous isoler la source, diagnostiquer les symptômes et répondre aux personnes concernées ?
Temps de résolution
Combien de temps pouvez-vous résoudre le symptôme pour rétablir le fonctionnement normal ? La solution « plâtre collant » est un début important, mais ne devrait pas représenter la fin de l'affaire. Avez-vous exploré la cause première du problème ? Pouvez-vous être sûr que vous ne verrez pas une réapparition ?
Comprendre le coût de possession de vos instances SQL Server
Le coût de possession est un facteur critique lorsque vous décidez où vos instances de serveur SQL doivent résider. Il est important d'évaluer les coûts d'investissement initiaux associés à l'infrastructure et aux licences, les coûts de maintenance continus et tous les coûts basés sur la consommation associés à une charge de travail basée sur le cloud.
Si vous essayez de déterminer le coût de votre instance dans le cloud, les métriques critiques incluent l'utilisation du processeur, l'activité de lecture et d'écriture et le stockage. Vous devrez les mesurer sur une longue période pour déterminer les limites de votre charge de travail afin de vous assurer que vous disposez des ressources nécessaires pour le spectre de charge de travail que vous attendez pour une instance particulière.
En vous familiarisant avec les caractéristiques particulières des charges de travail exécutées sur vos instances de serveur SQL, vous serez mieux placé pour vous assurer que tout continue de fonctionner comme il se doit et pour répondre aux besoins actuels et futurs de votre entreprise.
Étudier les performances au fil du temps avec la surveillance de SQL Server
Les bases de données sont des systèmes fluides. Très peu ont des charges de travail stables, répétitives et prévisibles. Il est beaucoup plus courant de voir de grandes variations dans le temps qui fluctuent en fonction du nombre d'utilisateurs, des tâches automatisées, du nombre de transactions, du volume de données, etc.
Une base de données des ventes s'activera à la fin du mois. Il verra également un pic d'activité autour d'événements saisonniers ou motivé par des promotions marketing.
Classer vos performances sur la base de petits instantanés n'est pas une bonne politique. Plus vous collectez et analysez d'historique, plus vous obtenez d'informations sur les variations et les limites de chacune des caractéristiques de vos charges de travail.
Vous devrez juger de la quantité d'historique qu'il est pratique de conserver et si vous disposez des ressources nécessaires pour le traiter. Il y a des implications en termes de coûts et de performances à prendre en compte.
Obtenez une image complète de la surveillance de votre base de données
Chaque base de données est un système complexe avec de nombreuses pièces mobiles. De nombreux critères de configuration peuvent avoir un effet sur ses performances.
La conception et l'architecture de la base de données elle-même influenceront les résultats. L'efficacité du code peut également faire ou défaire les performances. Les options de configuration détermineront comment l'instance du serveur SQL consomme les ressources disponibles.
Considérez le scénario suivant :une instance ralentit jusqu'à s'arrêter et l'administrateur de base de données détecte un pic dans l'attente CXPACKET ou CXCONSUMER. La réaction instinctive est d'arrêter le parallélisme. Les attentes disparaissent et le goulot d'étranglement actuel est temporairement soulagé. Désormais, l'intégralité de l'instance s'exécute plus lentement, mais l'administrateur de base de données ne souhaite pas réactiver le parallélisme. Si une enquête plus approfondie avait été effectuée, cela aurait révélé qu'une requête s'exécutait particulièrement lentement et que la cause était un index manquant.
La surveillance de nombreuses métriques différentes en parallèle permet d'identifier avec précision la cause première et d'éviter les erreurs de diagnostic coûteuses qui peuvent entraîner une répétition ou même une escalade du même problème.
