Diagnostic de l'erreur 9001 de Microsoft SQL Server: le journal de la base de données n'est pas disponible
Au cours du week-end, un site Web que j'ai exécuté a cessé de fonctionner, enregistrant l'erreur suivante dans l'Observateur d'événements chaque fois qu'une demande est adressée au site Web:
ID d'événement: 9001
Le journal de la base de données ' nom de la base de données ' n'est pas disponible. Vérifiez le journal des événements pour les messages d'erreur associés. Résolvez les erreurs et redémarrez la base de données.
Le site Web est hébergé sur un serveur dédié, je suis donc en mesure de RDP dans le serveur et de fouiner. Le fichier LDF pour la base de données existe dans le C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA dossier, mais une tentative de travail avec la base de données à partir de Management Studio entraîne une boîte de dialogue signalant la même erreur - 9001: le journal de la base de données n'est pas disponible ...
C'est la première fois que je reçois cette erreur et j'héberge ce site (et d'autres) sur ce serveur Web dédié depuis plus de deux ans maintenant.
Je crois comprendre que cette erreur indique un fichier journal corrompu. J'ai pu remettre le site Web en ligne en détachant la base de données puis en restaurant une sauvegarde d'il y a quelques jours, mais mon inquiétude est que cette erreur indique un problème plus sinistre, à savoir une défaillance du disque dur.
J'ai envoyé un e-mail au support de la société d'hébergement Web et voici leur réponse:
Il ne semble pas y avoir d'autres indications de la cause dans le journal des événements, il est donc possible que le journal ait été corrompu. Actuellement, les ressources de la mémoire sont à 87%, ce qui peut également avoir un impact mais est peu probable.
Le journal peut-il simplement "être corrompu?"
Ma question: Quelles sont les prochaines étapes à suivre pour diagnostiquer ce problème? Comment puis-je déterminer s'il s'agit effectivement d'un problème matériel? Et si c'est le cas, existe-t-il d'autres options que le remplacement du disque?
Merci
Plus de 99% des problèmes de corruption de base de données concernent le système de stockage. La moitié des problèmes restants sont dus à une mauvaise mémoire, l'autre moitié étant des bogues dans SQL Server.
Il y a de fortes chances que ce soit un problème de stockage.
Si cela se produit à nouveau, exécutez DBCC CHECKDB sur la base de données et cela vous donnera plus d'informations sur la corruption et si le problème peut être résolu sans effectuer de restauration. Vous devrez probablement mettre la base de données en ligne en mode d'urgence pour exécuter checkdb sur la base de données.
L'utilisation de la mémoire à 87% n'a rien à voir avec le problème. SQL Server exécutera la mémoire jusqu'à 100% (ou à proximité) par conception.
J'ai pu résoudre ce problème en mettant la base de données hors ligne dans Management Studio, puis en la remettant immédiatement en ligne. dbcc checkdb a généré des erreurs qui ont été résolues après cette opération. Je ne peux pas dire pourquoi cela a fonctionné seulement que cela a fonctionné.
J'ai également eu ce problème récemment et après des montagnes de recherches, il semble courant qu'une base de données soit définie sur AUTO CLOSE. J'ai défini toutes les bases de données sur AUTO CLOSE = FALSE. Cela a commencé avec une base de données puis est passé à deux et la suivante était sur chacun d'eux. J'ai simplement redémarré le service d'instance SQL Server au lieu de restaurer les bases de données. Une autre façon de résoudre le problème consiste à mettre la base de données problématique hors ligne et à la remettre en ligne.
MS SQL mettra les journaux d'une base de données affectée hors ligne pour éviter la corruption de la base de données. C'est pourquoi vous obtenez l'erreur 9001.
Lorsque vous mettez la base de données affectée hors ligne/en ligne, MS SQL active les journaux de base de données concernés jusqu'à ce que l'erreur se reproduise.
Une autre façon de résoudre ce problème consiste à modifier l'option Auto_Close sur OFF
http://sqlmag.com/blog/worst-practice-allowing-autoclose-sql-server-databases
Je vais deviner/espérer que vous avez un raid pour le disque de votre serveur SQL. si vous soupçonnez des problèmes matériels, la toute première chose que je ferais serait d'exécuter vos outils de maintenance/diagnostic de raid.
la deuxième chose (probablement simultanément si vous le pouvez) est d'exécuter dbcc checkdb sur la base de données (peut-être aussi vos bases de données système).
Ok, première étape, faites une sauvegarde de votre journal et de vos fichiers mdf sur un lecteur complètement différent. RAPIDEMENT! (copie du fichier)
Essayez également d'effectuer une sauvegarde complète de la base de données.
Ensuite, essayez ce qui suit. En utilisant votre base de données actuelle, détachez-la, si vous le pouvez, puis supprimez le fichier journal, ou déplacez-le vers un emplacement complètement différent sur le disque. Rattachez ensuite la base de données et elle s'affichera dans l'interface graphique avec un fichier journal, cliquez sur supprimer (ou supprimer) pour le fichier journal afin qu'il n'apparaisse pas, puis cliquez sur OK. Fondamentalement, l'attacher sans journal le forcera à créer un fichier journal pour la base de données à l'emplacement par défaut.
Faites le moi savoir.
Hier, j'avais reçu la même erreur "le journal de la base de données '%' n'est pas disponible. Erreur fatale 9001, msg 21. Veuillez contacter votre administrateur" -
Solution de contournement - J'ai vérifié le "TempDB" mais il n'était pas accessible de la même manière que le reste des bases de données système. Ensuite, avant de choisir l'option de réparation, j'ai simplement redémarré les services SQL pour cette instance et le problème a été résolu :) :)
Oui, j'ai aussi eu ce même problème, il s'agissait de l'erreur tempDb 9001, c'est-à-dire du journal non disponible. Nous avons redémarré les services et tout allait bien.
Le problème derrière cela était SAN ou problème de stockage, alors que l'opération d'écriture d'E/S, il n'a pas pu écrire pendant plus de 15 secondes.