Діагностика помилки 9001 Microsoft SQL Server: Журнал для бази даних недоступний

У вихідні веб-сайт, який я запускаю, перестав функціонувати, записуючи таку помилку в Переглядачі подій щоразу, коли на нього надсилається запит:

Ідентифікатор події: 9001

Журнал для бази даних " ім'я бази даних " недоступний. Перевірте журнал подій на наявність пов’язаних повідомлень про помилки. Вирішіть будь-які помилки та перезавантажте базу даних.

Веб-сайт розміщений на спеціалізованому сервері, тож я в змозі перейти на сервер і обміняти його. LDFФайл для бази даних існує в C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATAпапці, але намагається зробити будь-яку роботу з базою даних з результатів Management Studio в діалоговому вікні звітів ту ж помилку - 9001: Журнал для бази даних не доступний ...

Це перший раз, коли я отримав цю помилку, і я розміщую цей сайт (та інші) на цьому спеціалізованому веб-сервері вже більше двох років.

Наскільки я розумію, що ця помилка вказує на пошкоджений файл журналу. Мені вдалося повернути веб-сайт в Інтернеті, відключивши базу даних, а потім відновив резервну копію пару днів тому, але я занепокоєний тим, що ця помилка свідчить про більш зловісну проблему, а саме провал жорсткого диска.

Я надіслав електронною поштою підтримку в веб-хостинговій компанії, і це була їх відповідь:

Інших вказівок на причину в Журналі подій немає, тому можливо, що журнал був пошкоджений. В даний час ресурс пам'яті становить 87%, що також може мати вплив, але малоймовірно.

Чи може журнал просто "зіпсуватися?"

Моє запитання: Які наступні кроки я повинен зробити для діагностики цієї проблеми? Як я можу визначити, чи справді це апаратні проблеми? І якщо це так, чи є якісь варіанти, крім заміни диска?

Спасибі

Більше 99% проблем із корупцією в базі даних - це система зберігання. Половина решти проблем пов’язана з поганою пам'яттю, інша половина - помилки в SQL Server.

Швидше за все це проблема зберігання.

Якщо це повториться, запустіть DBCC CHECKDB проти бази даних, і це дасть вам більше інформації про пошкодження, і якщо проблему можна буде усунути без відновлення. Можливо, вам доведеться привести базу даних в режимі надзвичайної ситуації, щоб запустити checkdb проти бази даних.

Використання пам'яті на 87% не має нічого спільного з проблемою. SQL Server буде заряджати пам'ять повністю на 100% (або близько до неї).

Мені вдалося вирішити це, взявши базу даних в автономному режимі в студії управління, а потім негайно повернувши її в Інтернет. dbcc checkdbкинув помилки, які були вирішені після цього. Я не можу сказати , чому це працює тільки , що він зробив роботу.

У мене ця проблема була і нещодавно, і після гірських досліджень, як видається, вона є звичайною, коли база даних встановлена ​​на АВТОМАТИЧНИЙ ЗАКРІТ. Я встановлюю всі бази даних на AUTO CLOSE = FALSE. Це почалося з однієї бази даних, потім перейшло до двох, а наступна - на всіх. Я просто перезапустив службу екземплярів SQL Server замість відновлення баз даних. Ще один спосіб виправити симптом - зняти проблемну базу даних в режимі офлайн і знову повернути її в Інтернет.

MS SQL візьме журнали пошкодженої бази даних в автономному режимі, щоб уникнути пошкодження бази даних. Ось чому ви отримуєте помилку 9001.

Коли ви зайняте базу даних, що зачіпається в режимі офлайн / онлайн, MS SQL увімкне журнали пошкоджених баз даних до повторної появи помилки.

Ще один спосіб вирішити це - змінити параметр Auto_Close на OFF

http://sqlmag.com/blog/worst-practice-allowing-autoclose-sql-server-databases

Я здогадаюсь / сподіваюся, що у вас відбувся наліт на диск для вашого sql-сервера. якщо ви підозрюєте проблеми з обладнанням, перше, що я зробив би, це запустити ваші інструменти для обслуговування / діагностики.

друга річ (можливо, якщо це можливо) - запустити dbcc checkdb в базі даних (можливо, також і ваші системні бази даних).

Добре, перший крок, зробіть резервну копію свого журналу та файлів mdf на зовсім іншому диску. ШВИДКО! (копія файлу)

Також спробуйте виконати повне резервне копіювання бази даних.

Далі спробуйте наступне. Використовуючи поточну базу даних, від'єднайте її, якщо можете, а потім видаліть файл журналу або перенесіть його на зовсім інше місце на диску. Потім знову приєднайте базу даних, і вона з’явиться в gui з файлом журналу, натисніть кнопку видалити (або видалити) для файлу журналу, щоб він не відображався, а потім натисніть кнопку ОК. В основному приєднання його без журналу змусить створити файл журналу для бази даних у місці за замовчуванням.

Дай мені знати.

Так, я теж отримав цю саму проблему, це стосувалося помилки tempDb 9001, тобто журнал недоступний. Ми перезапустили послуги і все було добре.

Проблема, що стоїть за цим питанням, була проблемою SAN або зберігання, тоді як операція запису вводу / виводу не змогла записати більше 15 секунд.

Вчора я отримав ту саму помилку "журнал для бази даних"% "недоступний. Фатальна помилка 9001, мг. 21. Будь-ласка, зв'яжіться зі своїм адміністратором" -

Обхід - я перевірив 'TempDB', але він не був доступний аналогічно решті системних баз даних. Тоді перед тим, як перейти до варіанту ремонту, я просто перезапустив служби SQL для цього примірника і вирішив проблему :)

Я бачив, що це відбувається, коли немає місця на диску для розширення журналу; чи можете ви перевірити, чи було достатньо місця на C: \, і що ваші журнали керуються, тобто отримують резервну копію, якщо ви перебуваєте в повному режимі відновлення.

Я б перемістив ваші ldf-файли (та mdf-файли) із завантажувального обсягу, якщо у вас є можливість.