В процессе активной эксплуатации информационных систем на базе 1С:Предприятие размер базы данных неизбежно растет, достигая сотен гигабайт или даже терабайт. Для комфортной работы программистов создание полных копий таких баз становится нерациональным: это требует колоссальных дисковых мощностей и замедляет процесс развертывания тестовых окружений. Рассмотрим подробнее, как можно «обрезать» базу, оставив в ней только актуальные данные за короткий период, сохранив при этом работоспособность системы для целей разработки.
Один из наиболее элегантных и безопасных способов получить «тонкую» базу — это использование механизма планов обмена. Вместо того чтобы удалять данные из огромной базы, мы создаем пустую базу с аналогичной конфигурацией и «наполняем» её нужной информацией из рабочей базы. Разберем этот алгоритм по шагам:
Проанализируем преимущество этого метода: платформа 1С при обмене автоматически следит за ссылочной целостностью, если правильно настроены правила или используется типовой механизм. Однако стоит помнить, что если мы выгружаем только «Реализации» за август, а связанные с ними «Закупки» остались в июле, то в тестовой базе мы можем получить неполную картину движений по регистрам. Чтобы избежать этой ситуации, можно использовать программную регистрацию объектов с учетом их связей.
Если нам нужно быстро собрать небольшой «слепок» данных для отладки конкретной задачи, лучше всего воспользоваться стандартной обработкой от фирмы 1С. Рассмотрим, как правильно настроить процесс:
Откроем обработку и выберем необходимые типы документов. Главный секрет кроется в опции «Выгружать с объектами по ссылкам». При активации этого режима система, обнаружив ссылку на контрагента, договор или номенклатуру в документе, автоматически добавит эти объекты в файл выгрузки. Выясним причину, почему это важно: без этой опции в базе-приемнике вы получите множество записей с пометкой Объект не найден, что сделает тестирование невозможным.
Для ограничения объема данных установим период (например, последние 10 дней) или отфильтруем документы по конкретной организации. Полученный XML-файл загружается в пустую базу той же конфигурации. В результате мы получаем рабочую среду размером в несколько сотен мегабайт, содержащую полноценные цепочки документов.
Этот метод является самым быстрым, но требует предельной осторожности и понимания структуры таблиц 1С. Рассмотрим вариант прямого удаления данных через SQL-запросы. Посмотрим на примерную логику удаления данных из таблиц документов и регистров:
-- Пример логики удаления старых записей из таблицы регистра накопления
DELETE FROM _AccumReg123
WHERE _Period < '2023-01-01 00:00:00';
-- Пример очистки таблицы итогов, которая должна быть пересчитана
TRUNCATE TABLE _AccumRegTotals123;
Проанализируем критические риски этого подхода. В 1С данные хранятся в множестве связанных таблиц. Если вы удалите записи из таблицы документов _Document123, но оставите записи в таблицах движений регистров _AccumReg... или в таблицах критериев отбора, система начнет выдавать ошибки при попытке обращения к этим данным.
Важный момент: после любого прямого удаления данных через SQL обязательно необходимо запустить процедуру «Пересчет итогов» в конфигураторе. Таблицы итогов (с суффиксом Totals) хранят рассчитанные агрегаты, и если вы удалили записи из основной таблицы, итоги в отчетах останутся старыми, что приведет к некорректным результатам тестирования.
Типовой механизм «Свертка информационной базы», который есть во многих конфигурациях (БП, УТ, ERP), можно использовать «наоборот». Обычно его применяют для архивации старых лет, но мы можем использовать его для создания тестовой среды. Разберем, как это работает:
Мы запускаем свертку на дату начала нужного нам периода (например, на начало текущего месяца). Система автоматически создает документы Ввод остатков и удаляет старые документы. После завершения операции мы получаем базу, где нет «истории», но есть актуальные остатки и все документы за последний период. Это позволяет программисту работать с актуальными цифрами, не перегружая диск лишними гигабайтами архивных данных.
Если основной проблемой является именно дисковое пространство, а не производительность базы, стоит рассмотреть системные подходы. Использование файловых систем с поддержкой Copy-on-Write (CoW), таких как ZFS или Btrfs, позволяет создавать мгновенные снимки (snapshots) базы данных.
Выясним, в чем преимущество: когда программист создает копию базы, она фактически не занимает нового места на диске. Дисковое пространство расходуется только на те блоки данных, которые программист изменит в процессе своей работы. Таким образом, можно иметь 10 копий базы по 500 Гб каждая на диске объемом всего в 600 Гб. Это избавляет от необходимости «резать» базу и позволяет работать на полных данных.
Независимо от выбранного метода, создание качественной среды для разработки должно включать следующие этапы:
SHRINKDATABASE в SQL).Подводя итог, можно сказать, что наиболее сбалансированным методом для программиста является выгрузка по ссылкам через XML для малых задач или свертка базы для комплексного тестирования производительности на актуальных данных.