Ошибка 824 в MS SQL Server при открытии поврежденного .mdf файла (1С:УНФ)?

Question

[amir94]

Здравствуйте! Столкнулся с критическим повреждением файла базы данных .mdf (платформа MS SQL Server 2019, инстанс SQL Server).

При попытке подключения базы (mdf) или переводе в аварийный режим (EMERGENCY) для проверки через DBCC CHECKDB ядро СУБД блокирует работу из-за фатальной ошибки ввода-вывода.

Текст ошибки:
> Сообщение 824, уровень 24, состояние 2: SQL Server обнаружил логическую ошибку ввода-вывода, связанную с согласованностью: неверный идентификатор страницы (ожидаемый 1:9; фактический 0:0).

Что уже предпринималось:
1. Попытки прямого ATTACH и ATTACH_REBUILD_LOG.
2. Перевод в режим EMERGENCY с выполнением `DBCC CHECKDB ([base], REPAIR_ALLOW_DATA_LOSS)`, но проверка прерывается на системных страницах из-за той же ошибки 824.
3. Попытка сканирования файла через сторонние утилиты восстановления (например, SysTools SQL Recovery): сам бинарный файл размером ~2.5 ГБ читается, но стандартный каталог таблиц возвращает 0 элементов из-за поврежденного заголовка.
4. Проверка теневых копий Windows (VSS) — чистых ранних версий папки DATA не оказалось.

Вопрос:
Подскажите, как можно восстановить читаемость заголовка или вытащить данные (таблицы документов 1С) при такой ошибке страниц `1:9`? Есть ли смысл пробовать низкоуровневую правку в Hex-редакторе или использовать специализированные утилиты глубокого сканирования (Raw Scan)?

Можете помочь с восстановлением, пожалуйста? И сколько это будет стоить?

Comments

[Антон Жиляев]

Ошибка 824 на boot-странице 1:9 означает, что загрузочная страница базы забита нулями/мусором — штатный CHECKDB это уже не чинит. Рабочий путь: взять любую старую копию этой же базы (.bak), снять с неё первые 8 КБ со смещения 0x12000 и подменить в битом .mdf (только на копии файла), затем ATTACH и вытянуть таблицы через BCP или raw-сканер. Если бэкапов нет вообще, остаются платные побайтовые сканеры — тут лучше доверить восстановление специалистам.

Answer 1

[Пума Тайланд]

1:9 это не просто «какая-то системная страница», а boot-страница базы. Фактический pageid 0:0 значит, что на её месте нули или мусор, и CHECKDB такое не чинит принципиально. Проверь на копии файла: 8192 байта со смещения 0x12000 (73728) в .mdf. Сплошные нули = диагноз подтверждён.

Лечится подменой: возьми любую старую копию ЭТОЙ ЖЕ базы (хоть месячной давности .bak, развёрнутый через RESTORE ... WITH MOVE), скопируй из её первого mdf те же 8192 байта с 0x12000 и запиши поверх битых в своём файле (перезапись, не вставка). Дальше ATTACH или EMERGENCY + DBCC CHECKDB: вылезут другие битые страницы, но таблицы станут читаться. Если старых копий нет вообще, остаются платные raw-сканеры.

p.s. правь только копию mdf.

Answer 2

[Olesya Dekhand]

Ошибка 601 при работающем хинте NOLOCK в процессе DBCC CHECKDB означает, что подмена загрузочной страницы 1:9 вернула базу в строй лишь частично. СУБД смогла инициализироваться, но при попытке построить дерево объектов наткнулась на битые страницы распределения данных (IAM — Index Allocation Map или PFS — Page Free Space). SQL Server теряет физические указатели прямо во время сканирования, из-за чего проверка падает.Штатными средствами SQL Server эту базу восстановить уже не получится, так как разрушены внутренние метаданные.Единственный рабочий вариант сейчас — вытягивать данные «в сырую» (Raw Scan), полностью минуя стандартный движок СУБД:Потабличный экспорт через BCP: База сейчас находится в режиме EMERGENCY, поэтому можно попробовать принудительно выгрузить самые важные таблицы документов и справочников 1С (в УНФ они обычно начинаются с _Document или _InfoRg) через стандартную консольную утилиту командной строки:bcp "ИмяБазы.dbo._Document123" out "C:\doc123.bcp" -c -S ИмяСервера -TЕсли физические страницы конкретной таблицы целы, утилита скопирует данные в файл.Сторонние Raw-парсеры: Использовать специализированный софт (Recovery Toolbox for SQL Server, Stellar Repair for MS SQL или аналоги). В режиме глубокого анализа они сканируют файлы .mdf побайтово, находят структуры таблиц 1С по сигнатурам данных и позволяют экспортировать их содержимое напрямую в новую, чистую базу данных.

Answer 3

[amir94]

Пума Тайланд Спасибо за ответ. После подмены EMERGENCY + DBCC CHECKDB падает с такой ошибкой:
Выполнение DBCC завершено. Если DBCC выдает сообщения об ошибках, обратитесь к системному администратору.
Сообщение 601, уровень 12, состояние 3, строка 6
Не удалось продолжить просмотр с NOLOCK вследствие перемещения данных.
Время выполнения: 2026-09-22T07:47:59.0363957+05:00

p.s. в базе данных не силен. Если можете помочь, можем обсудить цену вопроса.