Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

Problèmes courants de SQL Server

J'enseigne et j'écris sur les erreurs courantes de SQL Server depuis de nombreuses années. J'ai également écrit un blog à ce sujet il y a des années, mais avec le temps, les conseils ont un peu changé. Cet article développe mon article précédent et explique comment ceux-ci s'appliquent à SQL Server, Azure SQL Database et Azure SQL Managed Instance.

Pendant de nombreuses années, j'ai trouvé des utilisateurs faisant les mêmes erreurs. Je les appelle des erreurs cependant, dans la plupart des cas, il s'agit plutôt de choses qui ne sont pas faites correctement parce que les personnes qui gèrent l'environnement ne savent pas mieux. Voici quelques-uns des éléments les plus critiques que toute personne installant et prenant en charge SQL Server doit connaître :

  • Sauvegardes
  • DBCC CHECKDB
  • Paramètres de mémoire
  • Statistiques
  • Maintenance de l'index
  • MAXDOP et seuil de coût pour le parallélisme
  • Alertes de l'Agent SQL Server

Sauvegardes

Je vérifie toujours les sauvegardes en premier lorsque je regarde un nouveau système. Il est essentiel de disposer de sauvegardes appropriées pour atteindre les objectifs de récupération. La perte de données peut être préjudiciable à une organisation. Lorsque je regarde les sauvegardes, je vérifie le modèle de récupération et l'historique actuel des sauvegardes pour chaque base de données. Je trouve généralement une combinaison des éléments suivants :

  • Pas de sauvegarde du tout :aucun enregistrement de sauvegarde pour la base de données
  • Sauvegardes manquantes :aucune sauvegarde de journal pour une base de données utilisant le modèle de récupération complète
  • Aucune sauvegarde récente :la dernière sauvegarde date de plusieurs semaines/mois/années

Les sauvegardes mal configurées sont préjudiciables à une organisation lorsqu'une situation de récupération se présente. Travailler avec et devoir dire aux clients qu'ils ont perdu des données n'est jamais amusant ni facile. Avoir des sauvegardes appropriées pour respecter les SLA devrait être la priorité absolue de toute organisation en plus de s'assurer que des copies de ces sauvegardes sont stockées dans un emplacement secondaire hors site.

Cette situation s'applique à SQL Server et IaaS sur site. Azure SQL Database et Azure Managed Instance ont des sauvegardes gérées.

DBCC CHECKDB

La corruption de la base de données se produit malheureusement. Sans vérifier régulièrement la corruption, les clients peuvent se retrouver dans un mauvais endroit en n'ayant pas de sauvegardes afin de récupérer lorsque cette corruption affecte les données physiques. Pour vérifier la corruption, DBCC CHECKDB doit être exécuté régulièrement sur chaque base de données. Ce que je trouve ressemble beaucoup aux sauvegardes :

  • Aucun DBCC CHECKDB effectué
  • DBCC CHECKDB exécuté uniquement sur certaines bases de données
  • Les vérifications DBCC CHECKDB ont été effectuées pour la dernière fois il y a des mois ou des années

Dans le pire des cas, une tâche planifiée signalant l'échec de DBCC CHECKDB

Il n'est jamais agréable de trouver une corruption ou de demander à un client de contacter un problème de corruption lorsque la corruption est un tas ou un index clusterisé et qu'il n'y a pas de sauvegardes avant que la corruption ne se produise. Dans ces cas, la corruption concerne les données réelles et le démarrage de la restauration avant la corruption est dans la plupart des cas la seule option. Dans les cas où la corruption est un index non clusterisé, la reconstruction de l'index est la solution.

Dans quelques situations, j'ai dû travailler avec des clients qui avaient une mauvaise corruption sans sauvegardes appropriées où j'ai pu scripter la base de données et copier manuellement toutes les données utilisables dans une base de données nouvellement créée. Ces situations coûteuses peuvent être facilement évitées en exécutant DBCC CHECKDB et en conservant correctement les sauvegardes.

Je conseille aux clients d'exécuter DBCC CHECKDB sur site, IaaS, Azure SQL Database et Azure SQL Managed Instance. Azure fait un excellent travail en vérifiant la corruption physique ; cependant, je pense que les consommateurs doivent vérifier la corruption logique.

Paramètres de mémoire

Une installation par défaut de Microsoft SQL Server a une valeur de mémoire minimale définie sur 0 et une valeur de mémoire serveur maximale définie sur 2147483647 Mo, soit 2 pétaoctets. Avant SQL Server 2012, la valeur maximale de la mémoire du serveur ne s'appliquait qu'au pool de mémoire tampon, les clients devaient donc limiter la quantité de mémoire que le pool de mémoire tampon pouvait utiliser pour économiser de la mémoire pour le système d'exploitation et d'autres processus. SQL Server 2012 a introduit une réécriture du gestionnaire de mémoire afin que la valeur de mémoire maximale du serveur s'applique à toutes les allocations de mémoire SQL Server.

Il est fortement conseillé de définir une valeur maximale pour votre instance SQL Server. Jonathan Kehayias a écrit un article de blog sur la quantité de mémoire dont mon serveur SQL a réellement besoin, avec une formule qui permet d'établir la référence pour la valeur de mémoire maximale. Dans le cas d'un serveur SQL partagé, je recommande à mes clients de définir la valeur minimale à 30 % de la mémoire sur le serveur.

Dans les situations avec plusieurs instances ou lorsque le serveur est utilisé pour SQL Server, SSIS, SSAS ou SSRS, vous devez évaluer la quantité de mémoire dont ces autres systèmes ont besoin et réduire la valeur de mémoire maximale du serveur pour permettre une mémoire adéquate pour le système d'exploitation et les autres systèmes. services.

Ce problème est valable pour les locaux, IaaS et partiellement pour Azure SQL Managed Instance. L'instance gérée définit une valeur de mémoire maximale du serveur en fonction du niveau déployé, mais lorsque j'ai testé le redimensionnement de l'environnement, la valeur de mémoire maximale n'a pas été modifiée dynamiquement. Dans cette situation, vous devrez mettre à jour manuellement la valeur. Ce problème ne s'applique pas à Azure SQL Database.

Statistiques

L'optimiseur de requête utilise des statistiques pour créer des plans d'exécution. Cela signifie que SQL Server a besoin que les statistiques soient à jour pour que l'optimiseur de requête ait une meilleure chance de créer un bon plan d'exécution. Par défaut, les statistiques sont mises à jour après que 20 % + 500 lignes de données ont été modifiées. Cela peut prendre beaucoup de temps sur des tables plus grandes. À partir du niveau de compatibilité 130, le seuil de mise à jour des statistiques pour les grandes tables a été abaissé. Pour SQL Server 2008R - 2014, vous pouvez abaisser ce seuil à l'aide de l'indicateur de trace 2371.

Je constate régulièrement que les clients ne mettent pas à jour manuellement les statistiques et même avec le seuil inférieur, j'ai constaté que la mise à jour manuelle rend un environnement plus stable.

Je recommande aux clients d'utiliser un script tiers pour mettre à jour les statistiques. Ola Hallengren a publié une solution de maintenance largement utilisée pour SQL Server. Une partie de ce processus est sa procédure Index Optimize, qui peut prendre des paramètres supplémentaires pour mettre à jour les statistiques.

@UpdateStatistics 
    ALL     = update index and column statistics
    INDEX   = update index statistics
    COLUMNS = update column statistics
    NULL    = Do not perform statistics maintenance (this is the default)

@OnlyModifiedStatistics
    Y = Update statistics only if rows have been modified since most recent stats update
    N = Update statistics regardless of whether any rows have been modified

J'ai constaté que les clients qui utilisent des produits ou des scripts tiers pour effectuer la maintenance de l'index en fonction du niveau de fragmentation de l'index ne considèrent pas que les réorganisations ne mettent pas à jour les statistiques comme le font les reconstructions. Beaucoup de ces applications tierces ont des options pour mettre à jour les statistiques, tout comme la procédure Index Optimize d'Ola, il vous suffit de l'activer.

La mise à jour des statistiques s'applique aux instances locales, IaaS, Azure SQL Database et Azure SQL Managed Instance.

Maintenance de l'index

Effectuer la maintenance des index en supprimant la fragmentation de vos index est toujours important. Certaines documentations obsolètes de Microsoft indiquaient que la fragmentation des index pouvait avoir un impact négatif de 13 à 460 % selon la taille de l'environnement et le niveau de fragmentation. Alors que le matériel tel que les SAN intelligents, les disques SSD et d'autres avancées ont contribué à accélérer les choses, l'espace gaspillé dans l'index peut se traduire par de l'espace gaspillé dans le pool de mémoire tampon ainsi que par le gaspillage d'E/S supplémentaires.

La fragmentation se produit par des opérations régulières telles que des insertions, des mises à jour et des suppressions. Pour remédier à cela, une maintenance appropriée des index de reconstruction ou de réorganisation de vos index est nécessaire. Je me tourne à nouveau vers Ola Hallengren, pour son script Index Optimize. Le script d'Ola offre la possibilité de spécifier la reconstruction ou la réorganisation en fonction du niveau de fragmentation et des pages minimales. De nombreux outils tiers proposent la même logique. Les plans de maintenance de la base de données SQL Server antérieurs à SQL Server 2016 permettaient uniquement de reconstruire ou de réorganiser tous les index. À partir de SQL Server 2016, vous pouvez désormais spécifier une logique similaire basée sur les niveaux de fragmentation. N'oubliez pas ces statistiques si vous utilisez une logique intelligente basée sur les niveaux de fragmentation.

J'aime le script d'Ola et les outils tiers qui se connectent à une table. Je peux ensuite interroger la table pour voir si j'ai des points chauds d'index où la fragmentation se produit constamment à des niveaux élevés et dépanner pourquoi la fragmentation est si répandue et si quelque chose peut être fait.

Il existe des exceptions à chaque règle ou pratique exemplaire. Certains modèles d'accès aux données entraînent une fragmentation constante. Le coût de la reconstruction/réorganisation constante de ces tables peut ne pas en valoir la peine et peut être exclu de la maintenance. Ces situations doivent être évaluées au cas par cas.

Cela s'applique aux instances locales, IaaS, Azure SQL Database et Azure SQL Managed Instance.

MAXDOP

Je trouve que le degré maximum de parallélisme et le seuil de coût pour le parallélisme sont généralement laissés aux valeurs par défaut sur les serveurs clients. Pour MAXDOP, la valeur par défaut est zéro, ce qui signifie qu'un nombre "illimité" de processeurs peut être utilisé pour exécuter une région parallèle d'une requête. Techniquement jusqu'à 64 processeurs, sauf si vous activez un indicateur de trace pour en utiliser davantage.

Il y a dix ans, lorsque les processeurs avaient un nombre de cœurs inférieur, cette valeur était acceptable. Aujourd'hui, avec une densité de cœur élevée et des serveurs multi-sockets, un nombre illimité de processeurs pour le parallélisme n'est pas si bon. Microsoft a donné des conseils sur les valeurs à utiliser pour MAXDOP.

Si vous utilisez SQL Server 2008 – SQL Server 2014, pour un seul nœud NUMA avec moins de 8 processeurs logiques, maintenez MAXDOP égal ou inférieur au nombre de processeurs logiques. Si vous avez plus de 8 processeurs logiques, maintenez MAXDOP à 8. Si vous avez plusieurs nœuds NUMA avec moins de 8 processeurs logiques par nœud NUMA, maintenez MAXDOP égal ou inférieur au nombre de processeurs logiques par nœud NUMA. Supérieur à 8, gardez MAXDOP à 8.

SQL Server 2016 a introduit les nœuds soft-NUMA. Lors du démarrage du service, si le moteur de base de données détecte plus de 8 cœurs physiques par nœud ou socket NUMA, des nœuds soft-NUMA sont créés automatiquement. Le moteur se charge de placer les processeurs logiques du même cœur physique dans différents nœuds soft-NUMA. Pour cette raison, nous avons des conseils légèrement différents pour MAXDOP pour SQL Server 2016 et ultérieur.

Si vous utilisez SQL Server 2016 et versions ultérieures, pour un seul nœud NUMA avec moins de 16 processeurs logiques, maintenez MAXDOP égal ou inférieur au nombre de processeurs logiques. Si vous avez plus de 16 processeurs logiques, maintenez MAXDOP à 16. Si vous avez plusieurs nœuds NUMA avec moins de 16 processeurs logiques par nœud NUMA, maintenez MAXDOP égal ou inférieur au nombre de processeurs logiques par nœud NUMA. Supérieur à 16, maintenez MAXDOP à la moitié du nombre de processeurs logiques par nœud NUMA avec une valeur MAX de 16.

Si vous êtes principalement virtualisé sur des machines avec 8 processeurs logiques ou moins avec un MAXDOP par défaut, vous êtes probablement dans OK. Si vous avez un gros matériel physique avec des valeurs par défaut, vous devriez envisager d'optimiser MAXDOP.

Tous les chiffres ci-dessus sont des lignes directrices, pas des vérités dures. Vos charges de travail varient et vous devez en tenir compte lorsque vous déterminez la valeur la plus optimale pour votre charge de travail.

La configuration de MAXDOP s'applique aux instances locales, IaaS et Azure SQL Managed Instance. Cependant, il existe une configuration étendue à la base de données qui peut être appliquée par base de données à partir de SQL Server 2016, et cela s'applique à Azure SQL Database.

Seuil de coût pour le parallélisme

Le seuil de coût pour le parallélisme a une valeur par défaut de 5. L'historique de ce nombre remonte aux premiers jours de SQL Server et au poste de travail sur lequel les tests de charge de travail ont été effectués. Avec le matériel moderne, l'estimation du coût de 5 est obsolète. Les tests ont montré que l'augmentation du nombre de 5 à une valeur supérieure empêchera les requêtes à exécution plus courte d'avoir un plan parallèle. J'ai tendance à recommander d'augmenter cette valeur à un nombre plus élevé après avoir examiné le Plan Cache. Dans de nombreux cas, je finis par commencer avec une valeur de 25, puis je surveille davantage et j'ajuste à partir de là, si nécessaire. Pour plus d'informations sur le réglage du seuil de coût pour le parallélisme, Jonathan Kehayias a écrit :Réglage du « seuil de coût pour le parallélisme » à partir du Plan Cache.

Cela s'applique aux instances locales, IaaS et Azure SQL Managed Instance.

Alertes de l'agent SQL Server

Tout le monde devrait tirer parti des alertes de l'Agent SQL, sauf s'il dispose d'une application tierce surveillant les mêmes conditions d'erreur. La configuration des alertes est simple et gratuite, et les faire configurer vous donnera des informations critiques lorsque vos serveurs rencontrent des problèmes.

J'ai écrit un article intitulé SQL Server Agent Alerts, fournissant des instructions étape par étape sur la façon de créer des alertes pour les erreurs de gravité 19-25 et l'erreur 825. L'activation de ces alertes est simple :activez la messagerie de base de données, créez un opérateur de messagerie, puis créez le alertes. Cela peut être accompli à l'aide de l'interface graphique ou avec T-SQL. J'encourage tout le monde à scripter ce processus à l'aide de T-SQL et à l'intégrer à la construction de votre serveur standard.

Cela s'applique aux instances locales, IaaS et Azure SQL Managed Instance.

Résumé

Comme vous pouvez le constater, de nombreux paramètres doivent être modifiés par rapport aux valeurs par défaut après l'installation de SQL Server. Il ne s'agit pas d'une liste exhaustive ; cependant, il couvre bon nombre des problèmes les plus critiques et ayant un impact sur les performances que je trouve, et que j'ai regroupés dans ma catégorie "incidents SQL Server".