Как вывести базу данных SQL из режима Recovery Pending?

← На главную

Состояние Recovery Pending в Microsoft SQL Server — это критический статус, при котором сервер понимает, что база данных требует восстановления, но процесс запуска не может быть завершен. Это не всегда означает необратимую поломку, но требует аккуратного вмешательства. Давайте разберем, как диагностировать проблему и вернуть работоспособность вашей базе данных.

Этап 1: Диагностика и проверка путей к файлам

Первая и самая распространенная причина появления ошибки Operating system error 2 заключается в том, что SQL Server не может найти физические файлы .mdf или .ldf по путям, которые прописаны в его системных метаданных. Даже если вы переместили файлы в другое место, сервер будет искать их «по старому адресу».

Для начала давайте выясним, где, по мнению сервера, должны лежать файлы. Выполните следующий запрос в SQL Server Management Studio:


USE master;
SELECT name, physical_name 
FROM sys.master_files 
WHERE database_id = DB_ID('ИмяВашейБазы');

Если в результате вы видите путь, который не соответствует фактическому расположению файлов, проблема найдена. Если же запрос ничего не возвращает, возможно, база данных некорректно «отцепилась» от экземпляра.

Этап 2: Проверка прав доступа

Часто система не может открыть файл не потому, что его нет, а потому, что у службы MSSQLSERVER (или учетной записи, от имени которой запущен SQL Server) нет прав на доступ к папке. Чтобы исключить эту проблему, выполните следующие действия:

Откройте свойства папки, где физически лежат файлы базы данных.
Перейдите на вкладку Безопасность.
Добавьте учетную запись NT SERVICE\MSSQLSERVER (или ту, что указана в службах Windows для вашего экземпляра SQL).
Установите для этой записи права Полный доступ или Чтение и запись.
Попробуйте снова перевести базу в рабочий режим.

Этап 3: Перевод базы в аварийный режим

Если пути верны и права настроены, необходимо принудительно перевести базу из состояния Recovery Pending в режим EMERGENCY. Это позволит выполнить операции обслуживания. Выполните этот скрипт:


ALTER DATABASE [ИмяВашейБазы] SET EMERGENCY;
GO
ALTER DATABASE [ИмяВашейБазы] SET SINGLE_USER;
GO
DBCC CHECKDB ([ИмяВашейБазы], REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS;
GO
ALTER DATABASE [ИмяВашейБазы] SET MULTI_USER;
GO

Важно: Флаг REPAIR_ALLOW_DATA_LOSS — это крайняя мера. Он может удалить поврежденные страницы данных для восстановления целостности базы. Используйте его только если у вас нет свежего бэкапа или если база является тестовой.

Этап 4: Что делать, если потерян или поврежден файл лога (.ldf)?

Если при попытке запуска SQL Server не находит файл журнала транзакций, он может уйти в режим ожидания. В некоторых случаях помогает остановка службы SQL Server, удаление или переименование поврежденного .ldf файла и последующий запуск базы с принудительной пересборкой лога:


ALTER DATABASE [ИмяВашейБазы] SET EMERGENCY;
GO
ALTER DATABASE [ИмяВашейБазы] REBUILD LOG ON (NAME = 'ИмяЛога_Log', FILENAME = 'Путь_К_Файлу_Лога.ldf');
GO

Этот метод заставит сервер создать новый чистый лог транзакций, что в большинстве случаев позволяет базе «подняться».

Этап 5: Рекомендации по предотвращению проблем

Чтобы в будущем не сталкиваться с подобными инцидентами на боевых базах, придерживайтесь правил:

Никогда не перемещайте файлы базы данных вручную, пока база активна. Используйте команду ALTER DATABASE [Имя] MODIFY FILE для изменения путей в системном каталоге.
Всегда проверяйте наличие прав доступа при миграции данных на новые диски.
При замене оборудования следите за тем, чтобы все файлы (включая журналы транзакций) были доступны серверу до его запуска.
Регулярно делайте резервные копии (Backup). В случае серьезного повреждения файлов никакие скрипты не заменят полноценную копию базы данных.

Надеемся, что эти шаги помогли вам разобраться с причиной ошибки и успешно вернуть базу данных в рабочий режим. Для комплексной диагностики состояния базы и настроек СУБД можно использовать обработку для проведения чек-апа СУБД под 1С.