В выходные дни веб-сайт, который я запустил, перестал работать, и каждый раз при отправке запроса на веб-сайт в средстве просмотра событий записывалась следующая ошибка:
Идентификатор события: 9001
Журнал для базы данных 'имя базы данных' недоступно. Проверьте журнал событий на наличие связанных сообщений об ошибках. Устраните все ошибки и перезапустите базу данных.
Веб-сайт размещен на выделенном сервере, поэтому я могу подключиться к серверу по протоколу RDP и осмотреться. В 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% (или близко к ней) по замыслу.
Я смог решить эту проблему, отключив базу данных в Management Studio, а затем сразу же вернув ее в оперативный режим. dbcc checkdb возникли ошибки, которые были устранены после этого. Я не могу сказать Зачем это сработало только это сделал работай.
У меня тоже была эта проблема недавно, и после множества исследований она стала обычным явлением, когда для базы данных установлено значение AUTO CLOSE. Я установил для всех баз данных значение 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 на совершенно другой диск. БЫСТРО! (копия файла)
Также попробуйте выполнить полное резервное копирование базы данных.
Далее попробуйте следующее. Используя текущую базу данных, отсоедините ее, если можете, а затем удалите файл журнала или переместите его в совершенно другое место на диске. Затем повторно подключите базу данных, и она отобразится в графическом интерфейсе с файлом журнала, щелкните удалить (или удалить) для файла журнала, чтобы он не отображался, а затем нажмите кнопку ОК. По сути, присоединение его без журнала заставит его создать файл журнала для базы данных в местоположении по умолчанию.
Дай мне знать.
Да, у меня тоже была такая же проблема, она касалась ошибки tempDb 9001, т.е. журнал недоступен. Мы перезапустили службы, и все было в порядке.
Причиной этого была проблема с SAN или хранилищем, во время операции записи ввода-вывода запись не производилась более 15 секунд.
Вчера я получил ту же ошибку «журнал для базы данных«% »недоступен. Неустранимая ошибка 9001, сообщение 21. Обратитесь к администратору» -
Обходной путь - я проверил TempDB, но он не был доступен, как и остальные системные базы данных. Затем, прежде чем перейти к варианту ремонта, я просто перезапустил службы SQL для этого экземпляра, и проблема была решена :) :)
Я также обнаружил ту же ошибку «журнал для базы данных TempDB недоступен. Неустранимая ошибка 9001. Обратитесь к администратору» -
Я просто перезапустил все службы SQL, и проблема решена :)
Я только что видел это с SQL Azure при переключении уровня eDTU. Когда он возвращался в сеть, я получил ошибку 9001. Я не думаю, что это предполагало какое-либо повреждение данных, просто побочный эффект прерывания соединения и напоминание о необходимости сделать это в непиковые часы - или пересмотреть логику повторных попыток.
Обратите внимание, что он также сопровождался 3314 ошибка.
System.Data.SqlClient.SqlException (0x80131904): The service has encountered an error processing your request. Please try again. Error code 9001.
The service has encountered an error processing your request. Please try again. Error code 9001.
The service has encountered an error processing your request. Please try again. Error code 3314.
Я видел, как это происходило, когда на диске не хватало места для расширения журнала; Можете ли вы убедиться, что на диске C: \ достаточно места, и что вашими журналами управляют, т. е. создается резервная копия, если вы находитесь в режиме полного восстановления.
Я бы убрал ваши файлы ldf (и mdf) с загрузочного тома, если у вас есть такая возможность.