Крайняя мера восстановления базы данных применяется в следующих безвыходных ситуациях:

• Полное физическое уничтожение или повреждение заголовка файла журнала транзакций (.ldf) при отсутствии бэкапов;
• Фатальные повреждения критических системных каталогов базы данных (sysallocunits, sysrowsets, Allocation Maps);
• База зависает в цикличном сбое при старте, блокируя любой доступ пользователям.

1. Архитектура аварийного восстановления

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

• Восстанавливает целостность распределения страниц (PFS, GAM, SGAM);
• Удаляет битые страницы данных из цепочек таблиц и индексов;
• При отсутствии или разрушении LDF файла — принудительно генерирует новый пустой журнал транзакций.

2. Пошаговый сценарий спасения базы

USE [master];
GO

-- 1. Переводим базу в Emergency и Single-User режим
ALTER DATABASE [ERP_1C] SET EMERGENCY;
GO
ALTER DATABASE [ERP_1C] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO

-- 2. Запуск деструктивного восстановления и пересоздания журнала транзакций
DBCC CHECKDB ([ERP_1C], REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS;
GO

-- 3. Возврат в многопользовательский режим
ALTER DATABASE [ERP_1C] SET MULTI_USER;
GO

3. Пересоздание LDF принудительно через ATTACH_REBUILD_LOG

Если файл LDF полностью утерян, а MDF цел:

CREATE DATABASE [ERP_1C] ON 
( FILENAME = N'D:\Data\ERP_1C.mdf' )
FOR ATTACH_REBUILD_LOG;
GO

4. Обязательные действия после восстановления

После применения REPAIR_ALLOW_DATA_LOSS логическая целостность бизнес-логики нарушена. Выполните:

1. Тестирование и исправление в конфигураторе 1С:Предприятие (ТИИ);
2. Создание полного бэкапа (Full Backup), так как цепочка LSN была разорвана;
3. Сверка ключевых балансовых отчетов и регистров.