Diagnostic de l'erreur 9001 de Microsoft SQL Server: le journal de la base de données n'est pas disponible

20

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 LDFfichier de la base de données existe dans le C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATAdossier, mais une tentative de travail avec la base de données 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 je crains 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

sql-server-2008 Scott Mitchell
la source

Réponses:

16

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é) de par sa conception.

mrdenny
la source
Merci pour les suggestions. J'ai en fait essayé de faire DBCC CHECKDB, mais j'ai eu beaucoup d'erreurs, y compris une erreur disant qu'il n'a pas pu trouver le fichier journal. Mais je n'ai pas essayé de mettre la DB en ligne en mode d'urgence.
Scott Mitchell
Habituellement, si le journal des transactions est corrompu, c'est une très mauvaise chose. CHECKDB peut être en mesure de le réparer, ou non, selon la gravité de la corruption. Si vous avez des sauvegardes du journal des transactions (votre fournisseur peut ne pas les autoriser), vous pourriez avoir perdu presque aucune donnée. À la fin de la sortie checkdb se trouvera le niveau de réparation requis pour corriger les problèmes avec les fichiers de base de données.
mrdenny
Correct. L'utilisation de la mémoire n'aura rien à voir avec cela - à moins que la mémoire ne soit corrompue et juste transférée sur le disque. Dans tous les cas, vous devriez voir d'autres indications de problèmes d'E / S dans vos journaux d'événements. Quelque part.
Michael K Campbell
Vous pouvez essayer d'exécuter un checkdisk (chkdsk) sur le disque pour voir si Windows voit des problèmes avec le disque. Il y a de fortes chances que vous deviez remplacer le disque. Cependant, il pourrait simplement s'agir d'un bug dans le code du contrôleur de disque ou dans le BIOS du disque. Dans les deux cas, je chercherais à remplacer les disques et / ou le contrôleur.
mrdenny
8

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 checkdbavait jeté des erreurs qui ont été résolues après avoir fait cela. Je ne peux pas dire pourquoi cela a fonctionné seulement que cela a fonctionné.

Facteur mystique
la source
5

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.

Clarice Bouwer
la source
1

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

Saul A. Greco V.
la source
0

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).

Soif42
la source
0

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. Re-attachez ensuite la base de données, et elle apparaîtra dans l'interface graphique avec un fichier journal, cliquez sur le supprimer (ou supprimer) pour le fichier journal afin qu'il ne s'affiche pas, puis cliquez sur OK. Fondamentalement, le joindre sans journal, le forcera à créer un fichier journal pour la base de données à l'emplacement par défaut.

Faites le moi savoir.

Ryk
la source
0

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 un problème de SAN ou de stockage, alors que l'opération d'écriture d'E / S, il n'a pas pu écrire pendant plus de 15 secondes.

lapin
la source
0

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 :) :)

Poonam Choudhary
la source
-2

J'ai vu cela se produire lorsqu'il n'y a pas d'espace disque disponible pour l'expansion du journal; pouvez-vous vérifier qu'il y avait suffisamment d'espace sur le C: \ et que vos journaux sont gérés, c'est-à-dire être sauvegardés si vous êtes en mode de récupération complète.

Je déplacerais vos ldf (et mdf) hors du volume de démarrage si vous en avez la possibilité.

SqlACID
la source
Le manque d'espace sur le disque dur n'entraînera JAMAIS la corruption de la base de données, sauf si vous utilisez un stockage alloué léger et que le stockage de base manque d'espace. Mais c'est un tout autre cauchemar.
mrdenny
Je vais reformuler ... peut-être pas la corruption de la base de données, mais certainement une cause d'indisponibilité des fichiers journaux, comme indiqué par l'op.
SqlACID
1
Il y a plus de 25 Go d'espace libre sur le lecteur et la base de données en question a une taille inférieure à 25 Mo.
Scott Mitchell
La seule erreur que vous verrez jamais en cas de manque d'espace est une erreur de fichier plein lorsque vous tentez de modifier des lignes dans la base de données car la transaction ne peut pas être écrite dans le journal (pas ce que l'OP a déclaré). Le manque d'espace ne rendrait pas la base de données indisponible (ce que l'OP a déclaré).
mrdenny
Être en désaccord. Manqué d'espace sur le lecteur où se trouvait le fichier journal, puis j'ai commencé à voir exactement le même problème en question.
ADNow