Проблема подготовки актуальных и компактных копий рабочих баз данных для разработки — одна из самых острых в Enterprise-сегменте. Когда объем информационной базы переваливает за несколько терабайт (в нашем случае — 5 Тб на базе 1С:Управление холдингом), стандартные методы копирования и последующей очистки средствами 1С перестают работать. Время подготовки такой базы может исчисляться сутками, что недопустимо для оперативной разработки. Рассмотрим комплексный подход к решению этой задачи, сочетающий инструменты платформы 1С и возможности СУБД MS SQL Server.
Прежде чем приступать к подготовке, проанализируем, почему стандартные подходы неэффективны на таких объемах. Основное препятствие при удалении данных через Объект.Удалить() или даже через НаборЗаписей.Записать() в 1С — это колоссальные затраты времени на контроль ссылочной целостности, пересчет итогов и запись в лог транзакций SQL Server. Если же использовать прямой SQL-запрос DELETE FROM ... WHERE ..., мы рискуем получить переполненный файл лога (ldf) и нарушить логическую целостность базы данных, так как 1С хранит связи не на уровне FOREIGN KEY в СУБД, а на уровне логики платформы.
Существует две глобальные стратегии решения:
Разберем детально оба метода и выберем наиболее эффективные инструменты для каждого.
Если нам требуется получить «почти полную» копию для нагрузочного тестирования или глубокой отладки подсистем, проще удалять лишнее. Чтобы сделать это быстро, проанализируем структуру таблиц. В 1С:Управление холдингом основной объем занимают регистры сведений и регистры бухгалтерии. Рассмотрим алгоритм быстрой очистки через SQL:
Использование команды DELETE неэффективно. Вместо этого применим комбинацию TRUNCATE и RENAME. Команда TRUNCATE TABLE выполняется мгновенно и практически не пишет в лог транзакций. Проанализируем пример сценария для очистки тяжелых таблиц, но сохранения данных за последний месяц:
Шаг 1. Получаем имена таблиц SQL, соответствующих объектам 1С, с помощью функции ПолучитьСтруктуруХраненияБазыДанных().
Шаг 2. Выполняем скрипт на стороне SQL Server:
-- Пример для таблицы регистра накопления или сведений
-- Создаем временную таблицу с данными, которые нужно ОСТАВИТЬ
SELECT * INTO TempTable_Keep FROM _InfoRg12345 WHERE _Period > '2023-12-31';
-- Очищаем основную таблицу полностью (мгновенно)
TRUNCATE TABLE _InfoRg12345;
-- Возвращаем нужные данные обратно
INSERT INTO _InfoRg12345 SELECT * FROM TempTable_Keep;
-- Удаляем временную таблицу
DROP TABLE TempTable_Keep;
Разберем, почему это быстрее: TRUNCATE освобождает страницы данных без сканирования каждой строки. Этот подход позволяет сократить время очистки 5-терабайтной базы с дней до нескольких часов. Важно: Перед выполнением таких операций переведите базу в модель восстановления SIMPLE, чтобы избежать роста лога транзакций.
Для массовой очистки «в ноль» (например, протоколов работы пользователей или версий объектов) используем системные представления SQL:
DECLARE @sql NVARCHAR(MAX) = '';
SELECT @sql += 'TRUNCATE TABLE ' + QUOTENAME(name) + ';'
FROM sys.tables
WHERE name LIKE '%_InfoRg%' -- Условие по маске таблиц регистров сведений
AND name NOT IN ('_InfoRgSpecific'); -- Исключаем критичные таблицы
EXEC sp_executesql @sql;
Этот метод считается более «чистым» и предпочтительным для ежедневной разработки. Мы создаем пустую базу из cf-файла и наполняем её только необходимым. Для сохранения ссылочной целостности проанализируем использование обработки «ЗагрузкаВыгрузкаДанныхXML» или «Конвертация данных 2.0» (КД2).
Рассмотрим алгоритм действий при использовании КД2:
ДоговорКонтрагента, то он попадет в базу вместе с самим Контрагентом и Организацией.Проанализируем ситуацию, когда база слишком велика даже для выгрузки в XML. В этом случае эффективно использовать механизм автоматизированного создания заданий. Разработчик описывает состав данных (например: «Все документы подсистемы Казначейство за январь»), и система на сервере выполняет выгрузку/загрузку в фоновом режиме.
Если ваша СУБД работает на современных системах хранения данных (СХД), поддерживающих технологию Copy-on-Write (Snapshots), создание копии 5 Тб базы может занимать считанные секунды. Снапшот не занимает места, пока в него не начинают писать.
Схема работы может быть следующей:
TRUNCATE для исторических данных).SHRINKDATABASE) для уменьшения физического размера файла (только для тестовых целей!).Выясним причину, почему в УХ данные занимают так много места. В этой конфигурации активно используются регистры сведений для хранения движений, которые в других базах (например, в ERP) хранятся в регистрах накопления. При удалении документов в УХ часто остаются «ошметки» в регистрах сведений, не связанных с документами напрямую через Регистратор.
Для обеспечения целостности в УХ при частичной выгрузке данных рекомендуем:
Организации, Проекты и Периоды целиком, так как они являются базовыми разрезами для большинства регистров._InfoRg..., предварительно сопоставив их с метаданными через Metadata.InformationRegisters.Для крупных команд разработки оптимальным решением станет создание «сервиса подготовки баз». Проанализируем концепцию такого сервиса:
Программист в специальном интерфейсе (это может быть небольшая база 1С) выбирает параметры: Период данных, Список подсистем, Необходимость обезличивания (маскирования) персональных данных. Система по расписанию или по кнопке запускает цепочку заданий (Job) в SQL и скрипты 1С, которые на выходе выдают готовую строку подключения к «легкой» базе.
Рассмотрим пример кода на 1С для выгрузки констант и настроечных регистров, которые нужны в любой копии:
// Пример функции для программного запуска выгрузки
Процедура ВыгрузитьНастройкиДляРазработчика(ПутьКФайлу)
ПараметрыВыгрузки = Новый Структура;
ПараметрыВыгрузки.Вставить("ВыгружатьТолькоНастройки", Истина);
// Используем типовую обработку ВыгрузкаЗагрузкаДанныхXML
Обработка = Обработки.ВыгрузкаЗагрузкаДанныхXML.Создать();
// Настраиваем список объектов (Константы, Справочники НСИ)
// ... заполнение дерева объектов ...
Обработка.ВыполнитьВыгрузку(ПутьКФайлу);
КонецПроцедуры
Для достижения цели — подготовки копии базы в 5 Тб за несколько часов — рекомендуем придерживаться следующего алгоритма:
TRUNCATE для тяжелых таблиц логов и истории.Такой системный подход позволит вашей команде не зависеть от тяжести рабочей базы и обеспечит высокую скорость цикла разработки и тестирования.