← На главную

Рассмотрим ситуацию, с которой часто сталкиваются администраторы баз данных: после внезапного сбоя системного диска и потери связи с файлами логов (.ldf), при попытке подключения (attach) существующего файла данных (.mdf) к MS SQL Server возникает критическая ошибка 5173. Разберемся, почему это происходит и как действовать в такой сложной ситуации, чтобы минимизировать потерю данных.

Суть проблемы: почему возникает ошибка 5173

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

Шаг 1: Подготовка и оценка рисков

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

1. Остановите работу сервера, чтобы не допустить перезаписи поврежденных данных.
2. Создайте полную копию текущих файлов .mdf, даже если они кажутся нерабочими. Любая попытка восстановления через REPAIR_ALLOW_DATA_LOSS может быть необратимой.
3. Определите ценность данных: если данные критически важны, лучше отказаться от рискованных команд SQL в пользу специализированного программного обеспечения для восстановления данных.

Шаг 2: Анализ методов восстановления

Разберем основные подходы, которые используют специалисты при возникновении подобных инцидентов.

Метод А: Использование специализированного ПО

Наиболее безопасным способом, как отмечают опытные администраторы, является использование специализированных инструментов для восстановления SQL баз. Такие программы, как DataNumen SQL Recovery, работают на низком уровне: они сканируют структуру .mdf файла, минуя стандартные процедуры подключения SQL Server, и пытаются извлечь данные напрямую. Это позволяет собрать таблицы и записи даже в том случае, если целостность лога транзакций полностью нарушена.

Метод Б: Принудительное восстановление через пересоздание лога (опасно!)

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

1. Создается новая пустая база данных с тем же именем, что и «битая».
2. Сервис SQL Server останавливается.
3. Файлы .mdf подменяются «битыми» оригиналами.
4. Сервис запускается, база переводится в режим EMERGENCY.
5. Выполняется команда DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS.

Рассмотрим пример того, как система реагирует на этот процесс. При использовании команды REPAIR_ALLOW_DATA_LOSS, сервер будет удалять те страницы данных, которые содержат повреждения, вызванные отсутствием корректного лога. В 1С это может привести к нарушению ссылочной целостности и ошибкам в конфигурации.

Практические рекомендации

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

• Регулярные бэкапы: как показывает практика, фраза «база была для тестов» — самый частый сценарий потери данных. Всегда настраивайте автоматизированное резервное копирование SQL через SQL Server Agent или средства 1С.
• Разделение дисков: хранение .mdf и .ldf на разных физических носителях — правильное решение с точки зрения производительности, но при выходе одного из дисков из строя вы получаете именно ту проблему, которую мы сегодня разбираем.
• Мониторинг целостности: периодически выполняйте команду DBCC CHECKDB на ваших базах, чтобы вовремя обнаружить скрытые повреждения до того, как произойдет фатальный сбой.

В заключение отметим: если вы оказались в ситуации, когда оригинальный файл лога утерян или поврежден, не пытайтесь «обмануть» систему множественными попытками аттача. Каждое действие меняет внутренние заголовки файлов. Сделайте копию, используйте проверенное стороннее ПО для восстановления, и только в крайнем случае прибегайте к командам восстановления с потерей данных.