Как восстановить базу данных MS SQL Server при ошибке прикрепления (Attach) файлов MDF и NDF?

При работе с крупными информационными базами 1С на СУБД MS SQL Server часто возникает необходимость распределения данных по нескольким файлам или дискам для оптимального распределения нагрузки. В этом случае к основному файлу данных .mdf добавляются вторичные файлы данных .ndf и файл журнала транзакций .ldf. Однако при переносе, удалении базы из списка или настройке путей можно столкнуться с ситуацией, когда SQL Server отказывается монтировать (Attach) базу данных и выдает ошибки формата или отсутствия файлов.

В данной статье мы разберем причину возникновения таких сбоев, выясним, влияют ли расширения файлов на работу СУБД, и рассмотрим алгоритм решения проблемы при прикреплении базы данных к SQL Server.

Анализ проблемы: как MS SQL Server работает с расширениями MDF и NDF

Рассмотрим распространенное заблуждение: часто специалисты считают, что создание файла с расширением .ndf вместо .mdf является ошибкой, из-за которой база данных выходит из строя. Проанализируем назначение этих расширений в архитектуре MS SQL Server:

1. .mdf (Primary Data File) — главный файл данных, содержащий системные таблицы, служебную информацию о базе и указатели на все остальные файлы. В базе данных может быть только один первичный файл данных.
2. .ndf (Secondary Data File) — вторичные файлы данных. Они используются для размещения таблиц и индексов на разных физических дисках или файловых группах. Расширение .ndf является официально рекомендуемым стандартом Microsoft для всех дополнительных файлов данных.
3. .ldf (Transaction Log) — файл журнала транзакций, обеспечивающий целостность данных и возможность отката операций.

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

Шаг 1. Проверка и правильное прикрепление всех файлов базы данных

Если база данных была случайно удалена из списка SQL Server Management Studio (SSMS) или перемещена на другой диск, разберем по шагам порядок ее восстановления через монтирование:

1. Откроем SQL Server Management Studio (SSMS) и подключимся к нужному экземпляру сервера.
2. В дереве объектов щелкнем правой кнопкой мыши по узлу Databases и выберем пункт Attach...
3. В появившемся окне нажмем кнопку Add и укажем путь к первичному файлу .mdf. Важно: убедитесь, что выбирается именно тот файл .mdf, который соответствует восстанавливаемой базе, а не временный или старый файл из другой директории.
4. После выбора главного файла .mdf MS SQL Server автоматически прочитает его заголовок и отобразит в нижней таблице "Database details" список всех связанных вторичных файлов (.ndf) и файлов журнала (.ldf).
5. Проверим пути к каждому файлу в колонке Current File Path. Если файлы были перенесены в другую папку, необходимо вручную указать их актуальное расположение.
6. Нажмем OK для завершения операции прикрепления.

Шаг 2. Что делать, если файл журнала (LDF) поврежден или утерян

Рассмотрим ситуацию, когда первичный файл .mdf и все вторичные файлы .ndf доступны, но файл журнала транзакций .ldf отсутствует или поврежден. В этом случае обычное прикрепление завершится ошибкой. Пересоздать журнал транзакций можно с помощью специального T-SQL запроса:

CREATE DATABASE [Наша_База_1С]
ON (FILENAME = 'D:\SQLData\UPP_main.mdf'),
   (FILENAME = 'D:\SQLData\UPP_data1.ndf'),
   (FILENAME = 'E:\SQLData\UPP_data2.ndf')
FOR ATTACH_REBUILD_LOG;

Данный запрос заново сформирует файл журнала транзакций при условии, что на момент отключения база данных находилась в согласованном состоянии (Clean Shutdown).

Шаг 3. Аварийный режим и проверка целостности (EMERGENCY Mode)

Если при попытке прикрепить базу данных SQL Server выдает ошибки повреждения структуры и не позволяет открыть доступ к данным 1С, проанализируем порядок действий по переводу базы в аварийный режим:

1. Создадим новую чистую базу данных с аналогичными именами файлов и структурой файловых групп.
2. Остановим службу SQL Server.
3. Заменим созданные пустые файлы данных оригинальными файлами .mdf и .ndf.
4. Запустим службу SQL Server (база перейдет в состояние RECOVERY_PENDING или SUSPECT).
5. Выполним следующий T-SQL скрипт в SSMS для перевода базы в режим чтения и запуска процедур восстановления:

-- Перевод базы в аварийный однопользовательский режим
ALTER DATABASE [Наша_База_1С] SET EMERGENCY;
ALTER DATABASE [Наша_База_1С] SET SINGLE_USER;

-- Проверка и исправление структуры с возможной потерей данных
DBCC CHECKDB ('Наша_База_1С', REPAIR_ALLOW_DATA_LOSS);

-- Возврат базы в многопользовательский режим
ALTER DATABASE [Наша_База_1С] SET MULTI_USER;

После успешного перевода базы в режим EMERGENCY появится доступ к таблицам в режиме "только для чтения". Это позволит выгрузить актуальные документы и справочники в новую чистую базу данных 1С.

Рекомендации по предотвращению подобных проблем

Разберем основные правила безопасности при проведении обслуживающих работ на сервере СУБД:

1. Создание резервных копий: перед любыми манипуляциями с файлами базы (перемещение, переименование, изменение конфигурации файловых групп) обязательно создавайте полный бэкап средствами SQL Server (файл .bak) или выгрузку 1С (файл .dt).
2. Проверка прав доступа: при переносе файлов данных на новые диски убедитесь, что учетная запись службы SQL Server имеет полные права (Full Control) на новую директорию в свойствах безопасности NTFS.
3. Контроль за метаданными: избегайте ручного переименования файлов .mdf/.ndf на диске без предварительного изменения их логических имен и путей через команды T-SQL ALTER DATABASE MODIFY FILE.