Что делать, если база SQL Server перешла в статус «Ожидает восстановления» (Recovery Pending)?

← На главную

Ситуация, когда база данных 1С:Предприятие в консоли MS SQL Server Management Studio (SSMS) внезапно приобретает статус «Ожидает восстановления» (Recovery Pending), является критической. Это означает, что SQL Server при запуске обнаружил проблемы, препятствующие нормальному открытию базы: файлы могут быть заблокированы, повреждены или отсутствовать. Особенно неприятно, когда это сопровождается техническими ошибками вроде 5172 (Header Error), указывающими на повреждение заголовка файла. В этой статье мы разберем по шагам, как диагностировать и исправить эту проблему, опираясь на практический опыт администраторов и технические особенности работы SQL-сервера.

Разберем причины возникновения статуса Recovery Pending

Прежде чем приступать к активным действиям, давайте проанализируем ситуацию и выясним, почему SQL Server перевел базу в этот режим. Основными причинами обычно становятся:

Некорректное завершение работы сервера: Сбой питания или принудительная перезагрузка в момент активной записи в базу.
Отсутствие файлов: SQL Server не может найти файл данных .mdf или файл журнала транзакций .ldf по указанным путям (например, если сетевой диск «отвалился»).
Повреждение заголовков (Ошибка 5172): Вирусы-шифровальщики или сбои дисковой подсистемы могут повредить нулевую страницу файла (page 0), где хранится метаинформация.
Блокировка антивирусом: Иногда защитное ПО блокирует доступ к файлам базы в момент старта службы SQL.

Метод 1. Простой перезапуск и манипуляции со статусом

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

Попробуем выполнить перезапуск службы SQL Server. Это освободит все зависшие дескрипторы файлов. Если это не помогло, проанализируем метод перевода базы в OFFLINE и обратно в ONLINE. Для этого в консоли запросов выполним следующий код:


-- Переводим базу в автономный режим
ALTER DATABASE [Имя_Вашей_Базы] SET OFFLINE WITH ROLLBACK IMMEDIATE;
GO
-- Возвращаем базу в оперативный режим
ALTER DATABASE [Имя_Вашей_Базы] SET ONLINE;
GO

Использование параметра WITH ROLLBACK IMMEDIATE критически важно: это принудительно разрывает все существующие соединения, позволяя команде выполниться немедленно. Если после перевода в ONLINE статус сменился на обычный, значит, проблема была в кратковременной блокировке файлов.

Метод 2. Восстановление при повреждении журнала транзакций (LDF)

Часто база висит в ожидании восстановления, если файл .mdf в порядке, а .ldf (лог транзакций) поврежден или не соответствует версии базы. Посмотрим на пример использования команды ATTACH_REBUILD_LOG. Этот метод создаст новый пустой файл лога, если старый пришел в негодность.

Внимание: этот метод сработает только в том случае, если база была корректно выключена. Если же произошел жесткий сбой, SQL Server может потребовать более глубокого ремонта.


-- Попытка создания базы с перестроением лога
CREATE DATABASE [Имя_Вашей_Базы] 
ON (FILENAME = 'D:\Path\To\Your\Base.mdf') 
FOR ATTACH_REBUILD_LOG;

Если вы получили ошибку 5172 («Заголовок файла не является действительным»), это означает, что повреждена структура самого файла. В этом случае обычный ATTACH не сработает.

Метод 3. Использование аварийного режима EMERGENCY и ремонт данных

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

Проанализируем последовательность действий для восстановления целостности:

Переводим базу в аварийный режим.
Переводим в однопользовательский режим для возможности ремонта.
Запускаем проверку и исправление DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS.


-- Шаг 1: Переход в аварийный режим
ALTER DATABASE [Имя_Вашей_Базы] SET EMERGENCY;
GO

-- Шаг 2: Установка монопольного доступа
ALTER DATABASE [Имя_Вашей_Базы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO

-- Шаг 3: Проверка и исправление (может привести к потере данных!)
DBCC CHECKDB ([Имя_Вашей_Базы], REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS;
GO

-- Шаг 4: Возврат в многопользовательский режим
ALTER DATABASE [Имя_Вашей_Базы] SET MULTI_USER;
GO

Важно понимать: использование REPAIR_ALLOW_DATA_LOSS — это крайняя мера. Команда буквально удаляет битые страницы данных, чтобы база стала структурно правильной. Для 1С это может означать потерю записей в некоторых таблицах, но это позволит базе «завестись».

Метод 4. Что делать, если заголовок файла (MDF) поврежден вирусом?

Выясним причину ошибки 5172 подробнее. Если вирус-шифровальщик успел изменить начало .mdf файла, SQL Server больше не распознает его как файл базы данных. В этом случае даже EMERGENCY mode может не помочь, так как сервер не может прочитать системные таблицы.

В такой ситуации рассмотрим следующие варианты:

Теневые копии (VSS): Проверьте свойства папки с базой, вкладку «Предыдущие версии». Иногда служба архивации Windows сохраняет снимки файлов.
Сторонние утилиты восстановления: Программы типа Stellar Repair for MS SQL или Recovery Toolbox for SQL Server умеют сканировать .mdf файл напрямую, игнорируя поврежденный заголовок, и выгружать данные в новую чистую базу.

Особенности восстановления для 1С:Предприятие

После того как нам удалось вернуть базу в статус ONLINE на уровне SQL Server, работа не заканчивается. База данных 1С имеет сложную логическую структуру, и «физическое» исправление страниц на уровне SQL могло нарушить «логическую» целостность объектов 1С. Для поиска и восстановления поврежденных данных можно использовать обработку для поиска битых ссылок и создания отсутствующих объектов.

Обязательно выполним следующие действия в конфигураторе:

Запустим Тестирование и исправление (ТиИ). Выберем пункты: «Реиндексация таблиц», «Проверка логической целостности», «Проверка ссылочной целостности».
В поле «При наличии ссылок на несуществующие объекты» выберем «Очищать» или «Создавать объекты» (в зависимости от ситуации).
Если база не открывается даже в конфигураторе, попробуем очистить содержимое таблицы Config (только если есть понимание структуры и бэкап!), так как повреждение метаданных конфигурации блокирует запуск системы.

Резюмируем: Статус Recovery Pending — это сигнал о том, что SQL Server потерял уверенность в целостности файлов. Начинайте с перезапуска службы и перевода базы OFFLINE/ONLINE. Если это не помогает, используйте режим EMERGENCY. И самое главное — никогда не проводите операции исправления (REPAIR_ALLOW_DATA_LOSS) без предварительного создания физической копии файлов .mdf и .ldf в надежное место.