Переход с 1С:УПП 1.3 на 1С:ERP 2.4 часто преподносит неприятный сюрприз системным администраторам и владельцам бизнеса: объем базы данных начинает расти в геометрической прогрессии. Ситуация, когда за полгода работы база достигает 100 Гб (при аналогичном объеме в УПП за 7-8 лет), является типовой для производственных предприятий. Проанализируем ситуацию, выясним причины такого поведения системы и рассмотрим конкретные шаги по оптимизации хранения данных.
В ходе анализа таблиц базы данных в 80% случаев выясняется, что основным «пожирателем» дискового пространства является регистр накопления СебестоимостьТоваров. Рассмотрим подробнее, почему это происходит. В 1С:УПП расчет себестоимости был более линейным и менее детализированным в разрезе движений. В 1С:ERP реализована концепция «Ключей аналитики». Вместо того чтобы записывать в каждую строку регистра прямые ссылки на номенклатуру, склад, серию и заказ, система создает уникальную комбинацию этих параметров в справочнике КлючиАналитикиУчетаНоменклатуры и записывает в регистр только идентификатор (ссылку) этого ключа.
Однако при включенном производственном учете количество таких комбинаций становится огромным. Каждая операция (этап производства, выпуск продукции, распределение затрат) порождает множество записей. Проанализируем ситуацию: если в производстве используется серийный учет или детальный учет по назначениям (под конкретные заказы), количество записей в регистре СебестоимостьТоваров увеличивается кратно количеству этих заказов и серий.
Многие пользователи замечают, что торговая база на 1С:ERP практически не растет, в то время как производственная «пухнет» на глазах. Выясним причину этого различия. В торговле товар просто поступает на склад и отгружается. В производстве же товар проходит через цепочку переделов. Каждая единица продукции на каждом этапе (ЭтапПроизводства) «собирает» на себя затраты: материальные, трудовые, постатейные. Система фиксирует промежуточные состояния стоимости, что приводит к формированию колоссального объема временных и корректирующих записей при закрытии месяца.
Самым эффективным способом борьбы с размером базы без потери данных является использование механизмов сжатия на уровне SQL-сервера. Проанализируем, как это работает. По умолчанию данные в SQL хранятся в несжатом виде. Однако таблицы регистров 1С (особенно индексы) отлично поддаются компрессии.
Рассмотрим применение PAGE или ROW сжатия. Для тяжелых таблиц, таких как _AccumRgTXXX (таблицы итогов) и _AccumRgXXXX (таблицы движений регистра себестоимости), рекомендуется использовать сжатие страниц (PAGE). Это позволяет уменьшить физический размер базы на диске в 3–5 раз. При этом нагрузка на процессор возрастает незначительно, а скорость чтения данных с диска часто увеличивается за счет уменьшения объема считываемых блоков.
Пример запроса для оценки эффективности сжатия (выполняется в SQL Management Studio):
EXEC sp_estimate_data_compression_savings 'dbo', '_AccumReg12345', NULL, NULL, 'PAGE';
Где _AccumReg12345 — имя таблицы вашего самого большого регистра в SQL.
Проанализируем состояние справочников ключей. В системе часто накапливаются записи в справочниках КлючиАналитикиУчетаНоменклатуры, КлючиАналитикиЗатрат и КлючиАналитикиНоменклатурыПоПартнерам, которые уже не используются в текущих движениях (например, после изменения настроек учета или удаления документов). Существуют типовые обработки (в составе конфигурации или на портале ИТС) для поиска и удаления неиспользуемых ключей аналитики. Очистка этих справочников косвенно помогает оптимизировать таблицы итогов регистров накопления.
Рассмотрим, какие настройки 1С напрямую влияют на «раздувание» базы. Если мы хотим прекратить неуправляемый рост, необходимо проанализировать следующие пункты:
Несмотря на опасения некоторых партнеров, редакция 1С:ERP 2.5 содержит значительно оптимизированный движок учета затрат. В версии 2.4 используется архитектура «Партионный учет 2.1», которая во многом была переходной. В 2.5 механизмы записи в регистры стали более «плотными», оптимизировано формирование временных таблиц при закрытии месяца. Переход на 2.5 часто позволяет замедлить темп роста базы и ускорить процедуру закрытия месяца за счет сокращения избыточных движений.
Выясним техническую сторону вопроса. В 1С:ERP количество индексов на одну таблицу регистра может достигать 20-30 штук. Часто размер индексов превышает размер самих данных. Регулярная дефрагментация и реиндексация (Rebuild Index) позволяют держать размер файлов базы под контролем. Также рекомендуется настроить регламентное задание 1С ОчисткаНенужныхДанных, которое удаляет технический мусор, остающийся после незавершенных процедур расчета себестоимости.
Подведем итог. Рост производственной базы 1С:ERP на 20 Гб в месяц — это не ошибка программы, а следствие высокой детализации учета, заложенной в архитектуру системы. Чтобы минимизировать этот эффект, мы рекомендуем:
Эти меры позволят сократить объем базы в несколько раз и сделать работу системы более стабильной.