При переходе на 1С:ERP многие специалисты сталкиваются с резким, лавинообразным ростом объема базы данных. Особенно остро это ощущается после выполнения процедуры Закрытия месяца. Рассмотрим ситуацию, когда всего две таблицы — регистр Прочие расходы незавершенного производства и Себестоимость товаров — начинают занимать десятки и сотни гигабайт. Разберемся, почему в документе может быть всего три строки, а в регистре — почти тысяча, и выясним, является ли это нормой или ошибкой настройки.
Одной из главных причин роста регистров в 1С:ERP является сложная комбинаторика аналитик. Разберем ситуацию на примере регистра Прочие расходы незавершенного производства. В этом регистре система фиксирует затраты, которые еще не включены в стоимость готовой продукции, но уже распределены на производственные процессы.
Проанализируем, почему 3 строки в первичном документе (например, «Производство без заказа») превращаются в 900 записей в регистре:
Таким образом, мы видим не ошибку программы, а работу алгоритма распределения. Если аналитик слишком много, система генерирует избыточный объем данных.
Выясним, какие настройки системы напрямую влияют на «вес» регистров себестоимости. Одной из самых критичных настроек в 1С:ERP является Детализация стоимости до первоначальных затрат. Рассмотрим подробнее ее влияние:
Когда эта опция включена, система не просто хранит итоговую сумму себестоимости единицы продукции, а «протаскивает» через всю цепочку производственных переделов структуру этой себестоимости. Если деталь прошла через 5 цехов, в итоговом регистре Себестоимость товаров будет храниться информация о том, сколько в ее стоимости металла, сколько электроэнергии и сколько трудозатрат от каждого этапа. Это увеличивает количество записей в десятки раз.
Рекомендация: Если для управленческого учета не требуется видеть структуру затрат вплоть до каждого первичного документа в отчете по себестоимости, эту опцию стоит отключить в разделе НСИ и администрирование — Настройка НСИ и разделов — Финансовый результат и контроллинг.
Часто пользователей пугает разрыв: файл выгрузки .dt весит 5 Гб, а развернутая база в SQL — 120 Гб. Разберем по шагам, почему это происходит:
.dt — это плоский упакованный архив. В нем не хранятся индексы, а сами данные максимально сжаты.Проанализируем ситуацию с индексами. Для проверки можно использовать стандартные средства SQL-сервера или запросы к системным таблицам, чтобы увидеть реальный размер данных без учета индексов. Если индексы занимают в 3-4 раза больше самих данных, возможно, требуется их пересоздание или оптимизация структуры регистра (что в типовых конфигурациях делать не рекомендуется, но стоит иметь в виду).
Иногда причиной аномального роста является человеческий фактор или ошибки миграции данных. Рассмотрим алгоритм проверки:
Ключи аналитики учета номенклатуры и Ключи аналитики учета затрат. Если эти справочники содержат миллионы записей, система будет создавать движения на каждый чих.Для выявления документов, создающих максимальное количество строк, воспользуемся консолью запросов. Разберем пример запроса, который поможет найти «виновников»:
ВЫБРАТЬ
Регистр.Регистратор КАК Документ,
КОЛИЧЕСТВО(*) КАК КоличествоСтрок
ИЗ
РегистрНакопления.ПрочиеРасходыНезавершенногоПроизводства КАК Регистр
СГРУППИРОВАТЬ ПО
Регистр.Регистратор
УПОРЯДОЧИТЬ ПО
КоличествоСтрок УБЫВ
Этот запрос позволит нам увидеть, какой конкретно документ «раздувает» базу. Если это регламентный документ Распределение расходов, значит, проблема в настройках распределения статей.
Выясним, как можно уменьшить размер базы без ущерба для учета:
_InfoRg..., соответствующей регистру сведений Версии объектов. Если в ERP включено версионирование для всех документов без ограничения срока хранения, эта таблица может занимать львиную долю базы.Reorganize/Rebuild Index, для PostgreSQL — VACUUM FULL и REINDEX. Это поможет вернуть «лишнее» место операционной системе.Резюмируем: Рост базы ERP до 100-200 Гб при активном производстве за год — это во многом штатная ситуация, обусловленная архитектурой системы. Однако, грамотная настройка статей расходов, отключение избыточной детализации и регулярное техническое обслуживание СУБД позволяют держать этот рост под контролем.