← На главную

Нередко администраторы и программисты 1С сталкиваются с ситуацией, когда размер информационной базы начинает стремительно увеличиваться без видимых на то причин. Особенно часто это происходит после массовых операций, таких как групповое перепроведение документов. Один из главных «виновников» — регистр бухгалтерии Хозрасчетный, а точнее, его таблицы итогов, например, таблица для хранения итогов по трем субконто (в SQL она может иметь имя вида _AccRgAT...).

Давайте разберемся, почему это происходит и как системно подойти к диагностике и решению этой проблемы, чтобы не просто временно «сбить» размер базы, а устранить первопричину.

Выясняем причину: пошаговая диагностика

Резкий рост таблиц итогов почти всегда сигнализирует об изменениях в структуре аналитики. Система начинает хранить остатки в новых, более детализированных разрезах, что и приводит к взрывному росту количества записей. Проанализируем ситуацию по шагам.

1. Проверяем недавние изменения в Плане счетов

   Это самая вероятная причина. Вспомните или посмотрите по журналу регистрации, не вносились ли недавно изменения в План счетов. Особое внимание уделите следующим моментам:

   • Добавление новых субконто. Если на счет с большим количеством движений (например, счет учета материалов, расчетов или, как в обсуждаемом случае, транзитный счет 79 «Внутрихозяйственные расчеты») добавили новое субконто, это гарантированно увеличит таблицу итогов. Каждая уникальная комбинация «Счет + Субконто1 + Субконто2 + Субконто3» создает новую запись в таблице итогов.
   • Снятие флага «Только обороты». У видов субконто есть важный признак «Только обороты». Он предназначен для аналитики, которая не должна иметь остатка на конец периода (например, «Статьи затрат», «Статьи движения денежных средств»). Если для такого субконто не установить этот флаг, система будет пытаться хранить по нему остатки, которые никогда не закроются. Это приводит к накоплению «мусорных» записей и раздуванию итогов.

   В разобранном на форуме случае именно добавление третьего субконто «Номенклатура» на субсчет 79.05 стало причиной проблемы. Счет 79 является транзитным и по своей методологии должен закрываться в ноль в разрезе корреспондирующих подразделений. Хранить по нему остатки в разрезе каждой номенклатурной позиции — некорректно с точки зрения учета и губительно для производительности базы.

2. Ищем некорректные данные в регистре

   Иногда рост может быть спровоцирован ошибками ввода данных. Проверим несколько гипотез:

   • Операции с некорректными датами. Ошибочно введенная дата (например, 2042 год вместо 2024, или 01.01.0001) создает итоги на очень далекий период, что также может приводить к росту таблиц. Выполним простой запрос в консоли запросов, чтобы найти такие записи:

     Скопировать код

     
     ВЫБРАТЬ
         Период,
         Регистратор
     ИЗ
         РегистрБухгалтерии.Хозрасчетный
     ГДЕ
         Период < ДАТАВРЕМЯ(2000, 1, 1)
         ИЛИ Период > ДАТАВРЕМЯ(2025, 1, 1)
     

   • Разница между NULL и пустой ссылкой. Для СУБД значение NULL и пустая ссылка (например, на элемент справочника) — это разные вещи. Если в проводках по одной и той же аналитике в одних случаях субконто не заполнено (пустая ссылка), а в других программно записывается NULL, система создаст две разные записи в итогах. Это редкая ситуация, часто связанная с доработками, но ее стоит иметь в виду.

3. Анализируем изменения в учетной политике

   Некоторые настройки учетной политики напрямую влияют на количество записей в регистрах. Например, включение раздельного учета НДС или переход на партионный учет по складам (если ранее он не велся) резко увеличивает количество движений и, соответственно, записей в таблицах итогов.

4. Проверяем редкие, но возможные ошибки

   В плане видов характеристик ВидыСубконтоХозрасчетные случайно может быть указан примитивный тип данных (например, Число, Строка). Это считается грубой ошибкой проектирования, которая может привести к колоссальному росту таблиц индексов и итогов. Убедитесь, что типы всех видов субконто — ссылочные.

Устраняем проблему: от анализа к действию

После того как причина найдена, необходимо ее правильно устранить. Простое удаление субконто со счета в режиме «Предприятие» не приведет к немедленному уменьшению размера базы.

Решение 1: Корректировка настроек аналитического учета

Это самый правильный и системный подход. Он направлен на устранение первопричины.

1. Обсудите с бухгалтерией целесообразность изменений. Выясните, зачем было добавлено новое субконто. Возможно, необходимую аналитику можно получить стандартными отчетами, анализируя обороты по корреспондирующим счетам, и вносить изменения в План счетов не требуется.

2. Установите флаг «Только обороты». Если аналитика все же нужна, но она не должна формировать остаток (как статьи затрат), то необходимо для соответствующего вида субконто установить флаг «Только обороты». Это ключевой момент для поддержания итогов в оптимальном состоянии.

3. Выполните реструктуризацию базы данных. После отвязки субконто от счета или изменения его свойств (например, установки флага «Только обороты») физическая структура таблиц в SQL не меняется. Чтобы платформа применила изменения, необходимо выполнить реструктуризацию.
   Важно! Перед этой операцией обязательно сделайте резервную копию базы данных.
   Для выполнения реструктуризации зайдите в Конфигуратор, откройте меню «Администрирование» -> «Тестирование и исправление...». В открывшемся окне установите флаг «Реструктуризация таблиц информационной базы» и запустите процесс.

4. Полностью пересчитайте итоги. После реструктуризации необходимо заново рассчитать все итоги. Это делается также в Конфигураторе через меню «Администрирование» -> «Пересчет итогов».

5. Сожмите базу данных (Shrink) в SQL. Даже после удаления данных и пересчета итогов файлы базы данных на диске (.mdf) могут не уменьшиться в размере. SQL Server резервирует это место для будущих данных. Чтобы вернуть место операционной системе, можно выполнить операцию сжатия (shrink) средствами SQL Server Management Studio.
   Внимание! К этой операции следует подходить с осторожностью. Частое сжатие может привести к сильной фрагментации индексов и снижению общей производительности системы. Используйте ее как разовую меру после глобальной чистки.

Решение 2: Управление периодом хранения итогов

Если кардинально менять настройки учета по каким-то причинам нельзя, можно воспользоваться механизмом управления итогами, который позволяет хранить рассчитанными только актуальные данные.

В режиме «Предприятие» в разделе «Администрирование» -> «Обслуживание» -> «Управление итогами и агрегатами» можно установить период итогов для регистров бухгалтерии. Например, можно установить дату начала прошлого или текущего года.

• Плюсы: Таблицы итогов будут значительно меньше, что ускорит выполнение регламентных операций и уменьшит размер резервных копий.
• Минусы: Построение отчетов за периоды, предшествующие установленной дате, будет занимать больше времени, так как итоги для них будут рассчитываться динамически «на лету» из таблицы движений.

Этот метод является хорошим компромиссом для больших баз, где отчеты по старым периодам запрашиваются редко.

В заключение, важно понимать разницу между разными способами пересчета итогов. Пересчет в Конфигураторе просто перестраивает таблицы итогов на основе уже существующих записей в таблице движений регистра. А вот групповое перепроведение документов в режиме «Предприятие» заново формирует сами движения, применяя актуальные на текущий момент настройки (Плана счетов, учетной политики), что и может приводить к кардинальному изменению состава и количества записей в регистре, а следовательно, и к росту таблиц итогов.