Свертка информационной базы — это всегда ответственный процесс, а когда речь идет о распределенной системе (РИБ), сложность возрастает в разы. Нам необходимо не только корректно обрезать данные в центральном узле, но и обеспечить синхронность этого состояния во всех периферийных базах, не «сломав» при этом механизм обмена. Рассмотрим подробно, как подступиться к этой задаче, какие существуют стратегии и каких технических «ловушек» следует избегать.
Перед тем как приступать к свертке, проанализируем причины. Часто пользователи решаются на свертку, когда объем файловой базы достигает 6–10 Гб, опасаясь фатальных сбоев. Разберем ситуацию: в платформе 1С существует ограничение не на общий размер файла .1CD, а на размер **одной таблицы** внутри этого файла, который составляет 4 Гб. Если ваша база весит 12 Гб, но данные распределены по разным таблицам (товары, остатки, цены), она будет прекрасно работать. Однако, если вы планируете массово загружать изображения (например, для выгрузки на сайт), таблица двоичных данных может быстро достичь этого предела. В таком случае свертка — лишь временная мера, и правильнее будет рассмотреть переход на клиент-серверный вариант (SQL) или хранение картинок вне базы (в томах).
Это самый простой с точки зрения реализации метод, который подходит для баз небольшого и среднего объема. Рассмотрим его по шагам:
basetrimming.epf (Свертка информационной базы) в центральном узле. Выберем дату свертки и сформируем документы ввода остатков.Проблема «Out of Memory»: Проанализируем главный риск этого метода. При удалении сотен тысяч документов в ЦБ, записи в таблицах регистрации изменений создают колоссальную нагрузку. При попытке выгрузки файл обмена XML может достичь нескольких гигабайт. При чтении такого файла периферийная база может выдать ошибку нехватки памяти. Если вы столкнулись с этим, рекомендуем выполнять обмен порциями или временно увеличить лимит виртуальной памяти процесса 1С.
Если база данных велика и передача миллионов удалений через XML физически невозможна, рассмотрим метод «автономной» свертки. Проанализируем последовательность действий:
basetrimming.epf в каждом узле (в ЦБ и во всех периферийных базах) с абсолютно одинаковыми настройками.Разберем пример кода для полной очистки регистрации изменений в конкретном узле, чтобы предотвратить выгрузку «мусора» после свертки:
// Выбираем узел, для которого нужно очистить регистрацию
УзелОбмена = ПланыОбмена.По Организациям.НайтиПоКоду("П01");
// Удаляем регистрацию всех изменений для этого узла
ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена);
После выполнения этого кода во всех базах, мы можем снова включить обмен. Система будет считать, что базы синхронны, и не попытается передавать удаления старых объектов.
Выясним причину, по которой этот метод часто называют самым «чистым». Если в базе накопилось много ошибок в регистрах или механизм обмена работает нестабильно, проще всего пересоздать структуру РИБ.
Этот метод гарантирует, что периферийные базы будут иметь минимально возможный размер и не будут содержать «хвостов» от удаленных данных.
Просто пометить объекты на удаление и нажать кнопку «Удалить» недостаточно для уменьшения размера файла на диске. Рассмотрим, что нужно сделать обязательно:
Для файловых баз: Обязательно запустите «Тестирование и исправление» из конфигуратора. Выберите пункт «Сжатие таблиц информационной базы». В файловой версии 1С удаленные данные физически остаются в файле .1CD, просто помечаются как свободное место. Сжатие перестроит файл и реально уменьшит его размер, что ОС увидит как освобождение места на диске.
Для клиент-серверных баз (SQL): После удаления большого объема данных лог транзакций (файл .ldf) может вырасти до огромных размеров. Проанализируем ситуацию: необходимо выполнить операцию Shrink Database (Сжатие базы данных) средствами SQL Server Management Studio. Это вернет неиспользуемое пространство операционной системе.
Посмотрим на нюансы работы самой обработки с ИТС. Она эффективно сворачивает регистры накопления, создавая корректировки, но часто не затрагивает независимые регистры сведений. Если у вас есть самописные регистры, в которых хранятся логи или история каких-то событий, их придется вычищать вручную или с помощью специализированных обработок «Очистка регистров». Также помните, что свертка может повлиять на интеграцию с сайтом (например, на Битриксе). Если идентификаторы объектов изменятся или удалятся связи, сайт может потребовать полной перевыгрузки каталога. Всегда проверяйте узлы обмена с сайтом после проведения подобных процедур.
Подводя итог: если ваша база весит около 6 Гб и не испытывает явных проблем с производительностью, возможно, со сверткой стоит повременить, сосредоточившись на оптимизации кода или переходе на SQL. Если же свертка неизбежна — используйте Стратегию №1 для простоты или Стратегию №3 для достижения максимальной чистоты системы.