Каждый администратор баз данных рано или поздно сталкивается со сбоями в работе СУБД MS SQL Server. Одной из наиболее неприятных является ситуация, когда из-за повреждения системной базы данных msdb графический интерфейс среды SQL Server Management Studio (SSMS) частично или полностью блокируется. При попытке раскрыть список баз данных или зайти в стандартные разделы мониторинга система выдает критическую ошибку:
«Не удалось открыть базу данных "msdb" вследствие недоступности файлов, нехватки памяти или места на диске. Подробности см. в журнале ошибок SQL Server. (Microsoft SQL Server, ошибка: 945)»
В этой ситуации стандартный путь просмотра логов через дерево объектов SSMS (раздел Управление -> Журналы SQL Server) становится недоступным, так как среда администрирования пытается прочитать метаданные из поврежденной базы msdb и аварийно завершает запрос. В данной статье мы подробно разберем, как обойти это ограничение, где физически найти файлы журналов ошибок, как их открыть и какими способами можно восстановить работоспособность СУБД.
Если графическая консоль управления заблокирована, мы можем обратиться к первоисточнику — текстовым файлам журналов, которые SQL Server создает непосредственно в операционной системе. Давайте разберем по шагам, где они находятся и как их правильно открыть.
По умолчанию файлы журналов хранятся в подкаталоге Log внутри папки установки вашего экземпляра SQL Server. Путь зависит от версии СУБД и имени инстанса:
C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log\C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Log\C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Log\C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Log\C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Log\Если у вас установлен именованный экземпляр (например, SQLEXPRESS), вместо папки MSSQLSERVER в пути будет использоваться имя вашего инстанса, например: MSSQL15.SQLEXPRESS.
В целевой папке вы обнаружите файлы со следующими именами:
ERRORLOG — это текущий активный журнал ошибок. В него SQL Server записывает события с момента последнего запуска службы. Этот файл не имеет расширения.ERRORLOG.1, ERRORLOG.2, ERRORLOG.3 (и так далее) — архивные файлы журналов. При каждом перезапуске службы или принудительном вызове процедуры ротации логов текущий файл переименовывается в ERRORLOG.1, а более старые сдвигаются по цепочке. По умолчанию хранится до 6 архивов.Важный момент: файлы журналов ошибок записываются в кодировке Unicode (UTF-16LE). Вы можете легко открыть их для чтения и анализа с помощью любого текстового редактора, например, обычного встроенного Блокнота (Notepad) или Notepad++. Также, если сама среда SSMS у вас запущена, вы можете открыть лог напрямую через ее меню: Файл -> Открыть -> Файл (File -> Open -> File) и указать путь к физическому файлу ERRORLOG. Это позволит проанализировать записи без обращения к заблокированному дереву объектов.
Если файлы не удалось обнаружить по стандартным путям (например, если администратор перенес папки данных на другой логический диск при установке), мы можем оперативно выяснить точное расположение логов двумя альтернативными путями.
Способ А. Через Диспетчер конфигурации SQL Server (SQL Server Configuration Manager):
SQL Server Configuration Manager на сервере.SQL Server (MSSQLSERVER)), кликнем по ней правой кнопкой мыши и выберем Свойства (Properties).-e. Например: -eC:\SQLData\Log\ERRORLOG. Путь, указанный сразу после ключа -e, и есть актуальное физическое местоположение текущего файла журнала ошибок.Способ Б. Через Реестр Windows:
Если утилита конфигурации недоступна, мы можем прочитать параметры запуска службы напрямую из системного реестра:
Win + R, введем regedit и нажмем Enter.HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQLServer\Parameters
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\[Имя_Экземпляра]\MSSQLServer\Parameters
SQLArg1 (или другой порядковый номер). Его значение будет содержать ключ запуска -e с полным путем к файлу лога.Теперь, когда мы научились извлекать информацию из журналов ошибок, давайте разберем саму суть проблемы. Ошибка 945 означает, что критически важная системная база данных msdb, отвечающая за расписания, задания Агента (SQL Server Agent), историю резервного копирования и почту СУБД, перешла в состояние Suspect (Подозреваемая) или Recovery Pending (Ожидание восстановления).
Давайте проанализируем основные причины этого сбоя и пошагово восстановим работоспособность системы:
Часто проблема возникает после переноса файлов баз данных, изменения учетной записи службы SQL Server или системных обновлений. Учетная запись, под которой запущена служба СУБД в Windows, теряет права на чтение и запись в папке с базой данных.
Перейдем в каталог, где лежат физические файлы базы msdb (обычно это папка DATA в каталоге установки, файлы msdbdata.mdf и msdblog.ldf). Откроем их свойства, перейдем во вкладку Безопасность и убедимся, что сервисному аккаунту (например, NT SERVICE\MSSQLSERVER или локальной системе) предоставлен Полный доступ (Full Control).
Если файлы базы копировались вручную с архивных носителей, операционная система могла установить для них флаг защиты от записи. В свойствах файлов msdbdata.mdf и msdblog.ldf снимем галочку Только для чтения (Read-only) и сохраним изменения.
Недостаточно просто проверить, что на жестком диске есть свободное место. Необходимо проанализировать настройки автоматического расширения файлов (Auto-Growth) для базы msdb. Если для файлов базы был установлен жесткий лимит размера (Maximum Size), при его достижении СУБД заблокирует запись и переведет базу в режим аварии. Освободим место на диске или скорректируем лимиты.
После того как права исправлены и место на диске обеспечено, база данных может автоматически не выйти из аварийного состояния. Нам потребуется принудительно запустить процесс восстановления. Откроем в SSMS новое окно запроса (кнопка Создать запрос на панели инструментов) и выполним следующий T-SQL скрипт:
ALTER DATABASE msdb SET ONLINE;
После выполнения этой команды SQL Server попытается заново перечитать файлы транзакций и вернуть базу в строй. Проверить статус всех баз данных можно с помощью запроса:
SELECT name, state_desc FROM sys.databases;
Если база данных по-прежнему выдает ошибку, нам обязательно нужно заглянуть в системные журналы Windows, которые фиксируют сбои дисковой подсистемы и ошибки ввода-вывода. Откроем утилиту Просмотр событий (Event Viewer), развернем узел Журналы Windows -> Приложение (Application) и выполним фильтрацию по источнику MSSQLSERVER. Здесь будут детально описаны физические ошибки секторов диска или повреждения страниц данных, если они имели место.
В случае серьезного повреждения файлов msdbdata.mdf и отсутствии актуальной резервной копии, штатный запуск СУБД может стать невозможным. В такой ситуации потребуется пересоздать системные базы с помощью программы установки SQL Server. Для этого запустим командную строку от имени администратора и выполним команду перестроения системных баз с оригинального дистрибутива:
Setup.exe /Quiet /Action=RebuildDatabase /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS="Администраторы" /SAPWD="Новый_Пароль_SA"
Важное предупреждение: процедура перестроения баз данных (Rebuild) полностью сотрет текущую базу msdb и создаст ее чистый шаблон. При этом будут безвозвратно утеряны все настроенные вами регламентные задания Агента (Jobs), планы обслуживания 1С-баз, а также история резервного копирования. Рекомендуется использовать этот метод только при полном отсутствии бэкапов и невозможности восстановить файлы иными путями.