Как правильно перенести базу данных MS SQL Server на другой диск и избежать режима Только для чтения

← На главную

Перенос файлов базы данных MS SQL Server на другой физический диск или в другой каталог — это стандартная задача системного администратора при дефиците свободного места или модернизации дисковой подсистемы. Однако часто после выполнения привычных действий база данных оказывается в режиме Read-Only (только для чтения), либо вовсе отказывается подключаться. В этой статье мы подробно разберем, как избежать этих ошибок, проанализируем причины возникновения проблем с правами доступа и рассмотрим несколько альтернативных способов миграции данных. Для детального анализа причин нехватки места на диске можно использовать инструмент для анализа распределения объёмов таблиц базы 1С.

Причина проблемы: Почему база становится Read-Only?

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

Проанализируем ситуацию с правами подробнее. Когда мы копируем файл через проводник Windows под своей учетной записью администратора, файл наследует права новой папки или сохраняет старые, но учетная запись службы SQL Server (например, NT SERVICE\MSSQLSERVER) может не иметь к ним доступа. В результате SQL Server может «увидеть» заголовок файла, но не может открыть его для записи, что и приводит к принудительному режиму «Только для чтения».

Метод 1: Правильная настройка прав доступа (Решение проблемы Read-Only)

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

Перейдем в проводник Windows к папке, куда были перенесены файлы .mdf и .ldf.
Нажмем правой кнопкой мыши на папку (или конкретные файлы) и выберем Свойства.
Перейдем на вкладку Безопасность и нажмем кнопку Изменить, затем Добавить.
В поле ввода имен выбираемых объектов введем NT SERVICE\MSSQLSERVER (для именованного экземпляра формат будет NT SERVICE\MSSQL$ИМЯ_ЭКЗЕМПЛЯРА).
Нажмем Проверить имена. Система должна подчеркнуть имя, подтверждая его корректность.
В списке разрешений установим галочку Полный доступ (Full Control).
Применим изменения ко всем вложенным объектам.

После настройки прав в операционной системе вернемся в среду SQL Server Management Studio (SSMS). Если база все еще в Read-Only, выполним следующий скрипт:


ALTER DATABASE [Имя_Вашей_Базы] SET READ_WRITE;
GO

Проанализируем результат: теперь SQL Server имеет все необходимые полномочия для работы с файловой системой, и база вернется в штатный режим.

Метод 2: Перенос через ALTER DATABASE (Рекомендуемый способ)

Вместо небезопасного метода Detach/Attach, при котором можно легко «потерять» базу при повреждении заголовков, рассмотрим более профессиональный подход. Он позволяет изменить пути к файлам в метаданных сервера еще до их физического перемещения.

Разберем этот процесс по шагам:

Определим логические имена файлов базы данных, которые мы хотим перенести:
```
USE [master];
SELECT name, physical_name AS CurrentLocation, state_desc
FROM sys.master_files
WHERE database_id = DB_ID(N'Имя_Вашей_Базы');
```

Выполним команду изменения пути в метаданных SQL Server:


ALTER DATABASE [Имя_Вашей_Базы] 
MODIFY FILE ( NAME = [Логическое_Имя_Данных], FILENAME = 'D:\NewPath\BaseData.mdf' );

ALTER DATABASE [Имя_Вашей_Базы] 
MODIFY FILE ( NAME = [Логическое_Имя_Лога], FILENAME = 'E:\NewPath\BaseLog.ldf' );

Переведем базу в режим OFFLINE, чтобы освободить файлы: ALTER DATABASE [Имя_Вашей_Базы] SET OFFLINE WITH ROLLBACK IMMEDIATE;
Теперь физически скопируем или переместим файлы в указанные новые места. Важно убедиться, что права на новые папки уже настроены, как описано в Методе 1.
Вернем базу в онлайн: ALTER DATABASE [Имя_Вашей_Базы] SET ONLINE;

Преимущество этого метода в том, что SQL Server сохраняет все настройки базы, включая владельца (owner) и параметры репликации, которые могут сброситься при обычном отсоединении.

Метод 3: Использование DBCC SHRINKFILE с опцией EMPTYFILE (Без остановки базы)

Существует продвинутый способ переноса данных между файлами внутри одной файловой группы без перевода базы в режим офлайн. Это полезно для высоконагруженных систем 1С, где простой недопустим.

Рассмотрим алгоритм действий:

Добавим новый файл данных на новый диск в ту же файловую группу (обычно PRIMARY):
```
ALTER DATABASE [Имя_Вашей_Базы] 
ADD FILE ( NAME = [New_File_Data], FILENAME = 'D:\NewPath\New_File.mdf', SIZE = 100GB );
```
Выполним перенос данных из старого файла в новый: DBCC SHRINKFILE (Логическое_Имя_Старого_Файла, EMPTYFILE);
Эта команда заставит SQL Server переместить все занятые страницы данных из старого файла в новый. После завершения операции старый файл станет пустым и его можно будет безопасно удалить: ALTER DATABASE [Имя_Вашей_Базы] REMOVE FILE [Логическое_Имя_Старого_Файла];

Важные практические советы

При выполнении любых операций по перемещению баз данных, особенно тяжелых конфигураций 1С, проанализируем следующие рекомендации:

Проверка целостности: Перед началом работ обязательно выполните DBCC CHECKDB. Если в базе есть скрытые повреждения, она может просто не прикрепиться (Attach) после отсоединения.
Размер кластера: Если вы форматируете новый диск под SQL Server, выбирайте размер кластера 64 КБ. Это стандарт де-факто для высокопроизводительных баз данных, обеспечивающий оптимальную работу дисковой подсистемы.
Мгновенная инициализация файлов (Instant File Initialization): Убедитесь, что у учетной записи SQL Server есть право на «Выполнение задач по обслуживанию томов» (Perform volume maintenance tasks) в локальных политиках безопасности Windows. Это позволит мгновенно создавать файлы MDF большого объема без забивания их нулями.
Использование Robocopy: Для физического переноса файлов между дисками лучше использовать утилиту командной строки robocopy с ключом /SEC. Это позволит скопировать файлы вместе со всеми настроенными правами доступа, что предотвратит проблему Read-Only еще на этапе копирования.
Резервное копирование: Как бы ни был надежен метод, всегда делайте полный бэкап перед манипуляциями с файлами. В случае сбоя диска во время копирования бэкап будет вашим единственным спасением. Для регулярного выполнения этой задачи в автоматическом режиме можно настроить пакетное резервное копирование и обслуживание баз 1С по расписанию.

Выясним еще один нюанс: если вы переносите базу 1С, которая активно использует полнотекстовый поиск, не забудьте проверить пути к полнотекстовым каталогам. В старых версиях SQL Server они могли храниться отдельно от MDF файла и требовать дополнительного внимания при миграции.

Таким образом, мы рассмотрели несколько способов переноса базы. Выбор конкретного метода зависит от ваших требований к доступности системы и вашего уровня владения инструментами T-SQL. Самым безопасным для целостности данных остается метод ALTER DATABASE MODIFY FILE, а самым быстрым для администратора — правильная настройка прав безопасности Windows при Attach. Для комплексной проверки параметров и корректности работы базы на сервере после переноса подойдёт инструмент для чек-апа настроек СУБД под 1С.