Dans mon article précédent sur les alertes de l'Agent SQL Server, j'ai fourni des instructions détaillées sur la configuration et la configuration des alertes de l'Agent SQL pour les erreurs de gravité élevée 19-25 ainsi que l'erreur 825. Dans cet article, je vais discutez de ces erreurs en détail et partagez ce que vous devez faire si elles se produisent dans votre environnement.
Les erreurs dont le niveau de gravité est égal ou supérieur à 19 interrompent l'exécution du lot en cours. Les erreurs d'une gravité de 20 et plus sont des erreurs fatales et mettent fin à la connexion client en cours. Ces erreurs peuvent également avoir un impact sur tous les processus de la base de données. Les erreurs fatales sont exactement ce que leur nom implique :le processus en cours d'exécution est terminé et la connexion client est fermée.
Erreurs de gravité 19
Une erreur de gravité 19 est une erreur due au manque de ressource. Cela signifie qu'une limite interne (que vous ne pouvez pas configurer) a été dépassée et a entraîné la fin du lot en cours. Ces erreurs se produisent rarement et vous ne pouvez pas faire grand-chose pour corriger le problème. Si une erreur de gravité 19 se produit, vous devez contacter votre fournisseur de support principal; généralement, ce serait Microsoft.
Au cours de toutes mes années de travail avec SQL Server, je ne me souviens d'aucun incident où une erreur de gravité 19 a été générée. Même en cherchant sur Bing, j'ai eu du mal à trouver des occurrences de l'erreur; les quelques références que j'ai trouvées étaient liées à une première version de SQL Server et faisaient référence à un bogue dans SQL Server lui-même.
Erreurs de gravité 20
Une erreur de gravité 20 est une erreur fatale dans le processus en cours. Cela indique qu'une instruction a rencontré un problème et a été interrompue. Comme cela n'affecte que le processus en cours, il est très peu probable que la base de données elle-même ait été endommagée. Ces erreurs sont liées à une déclaration individuelle, vous devrez donc rassembler l'intégralité du message d'erreur et contacter la personne ou l'équipe responsable de ce morceau de code. Il peut s'agir de l'entreprise ou éventuellement du fournisseur de l'application. Un exemple d'erreur est :
Erreur :18056, Gravité 20, État :29Le client n'a pas pu réutiliser une session avec le SPID 123, qui avait été réinitialisé pour le regroupement de connexions.
Pour cette erreur, je contacterais le développeur ou le fournisseur de l'application, car l'erreur est liée à une connexion groupée rencontrant une erreur lors de la tentative de réinitialisation. J'examinerais également les journaux SQL Server qui peuvent contenir un message d'erreur plus détaillé concernant ce qui se passe réellement pour provoquer l'erreur.
Erreurs de gravité 21
Une erreur de gravité 21 est une erreur fatale dans la base de données qui affecte tous les processus utilisant cette base de données.
J'ai vu cette erreur se produire lors de la tentative de restauration d'une base de données à l'aide des fonctionnalités Enterprise sur une instance Standard Edition, ainsi que lorsqu'une base de données est corrompue et que l'utilisateur tente d'accéder à une page corrompue. Un exemple de message d'erreur de ce type est :
Erreur : 605, gravité :21, état 1
Lorsque vous tentez de restaurer une base de données qui utilise les fonctionnalités Enterprise sur une instance Standard Edition, vous devez d'abord supprimer les fonctionnalités Enterprise. Par exemple, si vous utilisez la compression de données ou modifiez la capture de données, vous devrez d'abord arrêter d'utiliser et supprimer ces fonctionnalités de la base de données, sauvegarder la base de données, puis la restaurer sur l'instance Standard Edition. Vous pouvez utiliser le DMV sys.dm_db_persisted_sku_features pour vérifier si vous utilisez des fonctionnalités réservées aux entreprises.
Pour les erreurs de corruption, vous devrez exécuter DBCC CHECKDB pour déterminer l'étendue de la corruption et partir de là. Si vous avez de la chance, l'erreur se trouvera dans un index non clusterisé que vous pourrez reconstruire et résoudre le problème. Si la corruption est plus grave, vous pourriez envisager une opération de restauration. Pour mieux comprendre la corruption et comment résoudre divers aspects de la corruption, je vous encourage à consulter les différents articles de blog de Paul Randal. Paul a une catégorie entière sur la corruption que vous pouvez voir ici :
- http://www.sqlskills.com/blogs/paul/category/corruption/
Exécution de DBCC CHECKDB dans le cadre d'un travail régulièrement planifié sur vos bases de données est fortement recommandé pour détecter la corruption le plus tôt possible. Si vous ne vérifiez pas régulièrement la corruption, vous courez un risque énorme de ne pas pouvoir récupérer les données corrompues.
Erreurs de gravité 22
Une erreur de gravité 22 est une erreur fatale car l'intégrité de la table est suspecte, indiquant essentiellement que la table ou l'index spécifié dans le message est endommagé. La corruption arrive et arrive souvent. Notre expérience est que la majorité de la corruption se produit en raison d'un problème lié au sous-système d'E/S. Si vous rencontrez une erreur de gravité 22, vous devrez exécuter DBCC CHECKDB pour déterminer l'étendue des dégâts. Un exemple d'erreur est :
Impossible d'ouvrir XYZ pour un ID de fichier invalide ## dans la base de données. La table ou la base de données est peut-être corrompue.
Si l'erreur se trouve dans un index non clusterisé, vous pouvez simplement reconstruire l'index et corriger la corruption. Si la corruption se trouve dans un tas ou un index clusterisé, vous devrez restaurer la base de données dans un état cohérent.
J'ai vu des rapports où la corruption était en mémoire mais pas sur le disque. Dans ce cas, un redémarrage de l'instance ou la mise hors ligne puis en ligne de la base de données devrait résoudre l'erreur.
Erreurs de gravité 23
Une erreur de gravité 23 est une autre erreur fatale signalant que la base de données elle-même présente un problème d'intégrité. La résolution ressemble beaucoup à celle d'une erreur de gravité 22, où vous devez exécuter immédiatement DBCC CHECKDB pour trouver l'étendue complète des dommages causés à la base de données.
Ce niveau de corruption est détecté comme affectant l'ensemble de la base de données. Il peut s'agir d'une corruption dans le fichier de données lui-même ou d'une corruption dans le fichier journal. Les détails de l'erreur vous dirigeront vers le problème racine. Par exemple, l'erreur suivante indique que nous aurions besoin de restaurer notre base de données ou d'essayer de reconstruire le journal. Par souci de cohérence, je restaurerais à partir de ma sauvegarde la plus récente et de toutes les sauvegardes de journaux de transactions disponibles.
Erreur :9004, Gravité :23 État :6Une erreur s'est produite lors du traitement du journal de la base de données 'db_name'. Si possible, restaurez à partir de la sauvegarde. Si une sauvegarde n'est pas disponible, il peut être nécessaire de reconstruire le journal.
Erreurs de gravité 24
Une erreur de gravité 24 est une erreur fatale liée à un matériel. Ce message se produirait en raison d'un certain type de panne de support. Les types d'erreurs les plus courants que j'ai vus sont liés à des problèmes de mémoire et d'erreurs d'E/S. Par exemple :
Erreur :832, Gravité :24, État :1Une page qui aurait dû être constante a changé (somme de contrôle attendue :
Lorsque des erreurs comme celle-ci se produisent, vous devez contacter votre équipe de support système pour exécuter un test de mémoire sur votre serveur et donner au serveur un bon bilan de santé. Cette erreur peut être une mauvaise mémoire ou un gribouillis de mémoire (un processus du noyau ou quelque chose qui modifie la mémoire de SQL Server).
Autre exemple :
Erreur :824, Gravité :24, État :2SQL Server a détecté une erreur d'E/S basée sur la cohérence logique :ID de page incorrect (attendu 1:123 ; réel 0:0). Cela s'est produit lors d'une lecture de page (1:123) dans l'ID de base de données
Cette erreur indique une erreur de cohérence dans le fichier de données principal de la base de données. Vous auriez besoin d'exécuter immédiatement DBCC CHECKDB pour déterminer l'étendue de la corruption et prendre les mesures appropriées pour réparer ou restaurer la base de données.
Erreurs de gravité 25
Une erreur de gravité 25 est une erreur système fatale. J'ai entendu dire que la gravité 25 est plus ou moins un fourre-tout pour diverses erreurs fatales. Je n'ai vu cette erreur que lorsqu'elle était liée à des mises à niveau ayant échoué :quelque chose empêche l'exécution de l'un des scripts de mise à niveau et une erreur de gravité 25 est générée. Vous obtiendrez une erreur semblable à :
La mise à niveau du niveau de script pour la base de données 'maître' a échoué car l'étape de mise à niveau 'sqlagent90_sysdbupg.sql' a rencontré l'erreur 598, état 1, gravité 25. Il s'agit d'une condition d'erreur grave qui peut interférer avec le fonctionnement normal et la base de données sera mise hors ligne. Si l'erreur s'est produite lors de la mise à niveau de la base de données "maître", elle empêchera le démarrage de l'intégralité de l'instance SQL Server. Examinez les entrées précédentes du journal des erreurs à la recherche d'erreurs, prenez les mesures correctives appropriées et redémarrez la base de données afin que les étapes de mise à niveau du script s'exécutent jusqu'à la fin.Dans ce cas, des erreurs antérieures à ce message indiquaient un chemin incorrect pour l'emplacement des données par défaut pour SQL Server. Une fois que cela a été corrigé, la mise à niveau s'est déroulée avec succès.
Erreur 825
L'erreur 825 est souvent appelée avertissement de nouvelle tentative de lecture, mais la condition concerne à la fois les opérations de lecture et d'écriture. Cette erreur vous permet de savoir qu'une nouvelle tentative de l'opération était nécessaire et combien de fois SQL Server a dû réessayer la tentative avant qu'elle ne réussisse. SQL Server réessayera les opérations jusqu'à quatre fois, après quatre tentatives, il déclenchera une erreur 823 ou 824. Les messages d'erreur 825 ressembleront à ce qui suit :
Une lecture du fichier 'chemin d'accès au nom de fichier\nom_db.mdf' à l'offset 0x00000002000 a réussi après avoir échoué 2 fois avec erreur :somme de contrôle incorrecte (attendue : XYZ ; ABC réel). Des messages supplémentaires dans le journal des erreurs et le journal des événements système de SQL Server peuvent fournir plus de détails. Cette condition d'erreur menace l'intégrité de la base de données et doit être corrigée. Effectuez une vérification complète de la cohérence de la base de données (DBCC CHECKDB). Cette erreur peut être causée par de nombreux facteurs; pour plus d'informations, consultez la documentation en ligne de SQL Server.
Ces messages sont importants car ils indiquent que vous avez un problème plus important avec votre sous-système de disque. Les méthodes de dépannage consisteraient à exécuter DBCC CHECKDB pour vous assurer que la base de données est cohérente, comme le recommande l'erreur, ainsi que pour examiner les journaux d'événements Windows à la recherche d'erreurs provenant du système d'exploitation ou des périphériques de stockage. Vous devez demander à votre équipe de stockage et d'assistance matérielle d'examiner également le sous-système d'E/S sous-jacent à la recherche d'erreurs.
Résumé
La configuration des alertes SQL Agent est gratuite et simple. Il est important d'être proactif et réactif face à ces alertes afin de minimiser les temps d'arrêt pour vous et vos clients. Comme vous l'avez maintenant appris, beaucoup de choses peuvent affecter SQL Server et la cohérence de vos bases de données, et la meilleure défense pour pouvoir récupérer de ces erreurs est d'avoir de bonnes sauvegardes et de connaître les différentes options de réparation pour DBCC CHECKDB . Il est toujours recommandé d'exécuter DBCC CHECKDB régulièrement sur vos bases de données pour détecter la corruption le plus tôt possible, car plus vite vous trouvez la corruption, plus vous avez de chances d'avoir les données sauvegardées afin que vous puissiez restaurer sans perte de données.
