При работе с крупными внедрениями 1С администраторы и разработчики часто сталкиваются с необходимостью развертывания тестовых контуров на основе актуальных данных. Когда объем базы превышает 1 терабайт, стандартные процедуры RESTORE из бэкапа могут занимать часы, что критически замедляет процесс разработки. В этой статье мы подробно разберем, как ускорить этот процесс, используя как стандартные средства MS SQL Server, так и современные технологии оптимизации файловых систем.
Прежде чем переходить к методам ускорения, давайте проанализируем ситуацию. Если база объемом 1,5 ТБ восстанавливается 6 часов, это означает среднюю скорость около 70 МБ/с. Для современных серверных систем это довольно низкий показатель. Основными узкими местами обычно являются дисковая подсистема, сеть (если бэкап тянется по сети) и процесс инициализации файлов SQL-сервером. Выясним причину такой медленной работы и рассмотрим способы оптимизации инфраструктуры.
Если вам нужно создать несколько копий одной и той же уже развернутой базы, метод копирования файлов .mdf и .ldf может быть быстрее, чем многократный повтор RESTORE. Разберем по шагам этот алгоритм:
SHRINK файла лога (ldf), чтобы не копировать лишний объем транзакций.Offline или выполните Detach. Это освободит файловые дескрипторы.robocopy с флагом многопоточности, это может существенно ускорить процесс.Attach для исходной базы и всех новых копий под разными именами.Рассмотрим пример SQL-скрипта для быстрого подключения копии:
CREATE DATABASE [Test_Dev_1]
ON (FILENAME = 'D:\SQL_Data\Test_Dev_1.mdf'),
(FILENAME = 'L:\SQL_Logs\Test_Dev_1_log.ldf')
FOR ATTACH;
Одной из причин долгого восстановления является то, что MS SQL Server при создании файлов базы данных заполняет всё пространство нулями. Для базы в 1,5 ТБ это колоссальная нагрузка на диски. Мы можем пропустить этот этап, включив Instant File Initialization.
Проанализируем ситуацию: чтобы включить этот механизм, учетной записи, под которой работает служба SQL Server, нужно выдать право Perform volume maintenance tasks (Выполнение задач по обслуживанию томов) в локальных политиках безопасности Windows (secpol.msc). После перезапуска службы SQL Server создание и расширение файлов (в том числе при RESTORE) будет происходить мгновенно, так как система просто зарезервирует место без записи нулей.
Если ваши тестовые сервера работают на Windows Server 2016 или новее, а диски отформатированы в файловой системе ReFS, вы можете использовать «магию» блочного клонирования. Рассмотрим подробнее, как это работает:
При копировании файла .mdf средствами системы на том же разделе ReFS, физического копирования данных не происходит. Создаются только новые ссылки на те же блоки данных. Копирование файла объемом 1,5 ТБ завершается за несколько секунд. Физическое место на диске начнет расходоваться только тогда, когда разработчики начнут вносить изменения в свои базы (метод Copy-on-Write).
Для реализации этого метода через PowerShell можно использовать команду:
# Копирование с использованием блочного клонирования на ReFS
Copy-Item -Path "D:\SQL_Data\Base_Full.mdf" -Destination "D:\SQL_Data\Base_Clone1.mdf"
Часто разработчикам не требуются абсолютно все данные. Если в базе хранятся тяжелые лог-таблицы, версии объектов или присоединенные файлы, их можно выпилить перед созданием дополнительных копий. Посмотрим на примеры таблиц 1С, которые обычно занимают много места:
_InfoRgChngR — таблицы регистрации изменений (могут быть огромными при проблемах с планами обмена)._DataExchangeHistory — история обмена данными._InfoRgXXXX — регистры сведений с историей версий объектов или логами.Проанализируем размеры таблиц с помощью стандартного отчета SQL Disk Usage by Top Tables. Выяснив причину раздувания, мы можем очистить эти таблицы в первой развернутой тестовой базе, сделать SHRINK и только потом клонировать её. Это сократит время копирования для всех последующих разработчиков.
Если база нужна разработчикам в режиме «только чтение» или для быстрого тестирования с возможностью мгновенного отката, стоит рассмотреть технологию Database Snapshots. Снимок создается практически мгновенно и работает по принципу сохранения только измененных страниц данных.
Рассмотрим пример создания снимка:
CREATE DATABASE [Test_Snapshot] ON
( NAME = [Base_Data_File_Name], FILENAME = 'D:\Snapshots\Test_Snapshot.ss' )
AS SNAPSHOT OF [Source_Database_Name];
Важно помнить: снимок живет до тех пор, пока жива основная база, и замедляет запись в основную базу, так как при каждом изменении SQL Server должен скопировать старую страницу данных в файл снимка.
Если задача стоит не просто в разовом создании трех баз, а в их регулярном обновлении, разберем по шагам стратегию разностного копирования:
DIFFERENTIAL BACKUP рабочей базы.Это значительно быстрее, чем каждый раз переливать 1,5 ТБ данных, так как объем изменений за сутки обычно не превышает нескольких процентов от общего объема базы.
Для быстрого клонирования терабайтных баз 1С мы рекомендуем следующий комбинированный подход:
DBCC CLONEDATABASE, которая создает пустую схему со всей статистикой исходной базы за считанные мгновения.Применяя эти методы, мы превращаем многочасовой процесс ожидания в рутинную задачу, занимающую не более 15–30 минут, что существенно повышает эффективность команды разработки.