Задать вопрос
@amir94
базы-данных

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

Здравствуйте! Столкнулся с критическим повреждением файла базы данных .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)?

Можете помочь с восстановлением, пожалуйста? И сколько это будет стоить?
  • Вопрос задан
  • 29 просмотров
Комментировать
Подписаться 1 Сложный Комментировать
Помогут разобраться в теме Все курсы
  • Нетология
    DevOps-инженер с нуля
    15 месяцев
    Далее
  • Академия Эдюсон
    Python-разработчик + ИИ
    9 месяцев
    Далее
  • ProductStar × РБК
    Профессия: Python-разработчик + ИИ
    8 месяцев
    Далее
Пригласить эксперта
Ответы на вопрос 1
opium
@opium
Просто люблю качественно работать
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.
Ответ написан
Комментировать
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы