В практике разработчика 1С иногда возникает специфическая и довольно неприятная ситуация: записи из регистра накопления (например, Продажи) программно удалены, основная таблица регистра пуста, однако база данных продолжает занимать огромный объем, а виртуальные таблицы оборотов по-прежнему содержат «фантомные» данные. Попытка включить использование итогов или выполнить их пересчет в файловой базе приводит к аварийному завершению работы платформы с ошибкой нехватки памяти. Это происходит из-за того, что 32-битный процесс платформы ограничен адресным пространством в 4 Гб, а накопленные «хвосты» в таблице AccumRgTn требуют для обработки значительно больше ресурсов.
В данной статье мы подробно разберем, почему так происходит, и рассмотрим эффективные методики очистки регистра «по месту», не прибегая к выгрузке базы в клиент-серверный вариант (SQL).
Для начала проанализируем внутренние механизмы платформы 1С. Оборотный регистр накопления физически состоит из нескольких таблиц в базе данных. Основная таблица (AccumRgX) хранит сами записи (движения), а вспомогательная таблица оборотов (AccumRgTn) хранит предварительно рассчитанные итоги за периоды (месяц, день и т.д.).
Когда мы удаляем записи перебором или через НаборЗаписей с установленным отбором, платформа должна автоматически корректировать таблицу итогов. Однако, если ведение итогов было предварительно отключено программно или через Конфигуратор, записи из основной таблицы исчезают, а в таблице оборотов данные «зависают». Платформа просто перестает отслеживать актуальность итогов в выключенном режиме. При последующей попытке включить итоги, система инициирует масштабный процесс сканирования и сопоставления данных, который в условиях файловой базы .1CD крайне ресурсозатратен. Если объем «мусорных» данных исчисляется миллионами строк, 32-битный клиент 1С неизбежно падает.
Это наиболее «чистый» и эффективный способ заставить платформу полностью пересоздать физические таблицы регистра в файле базы данных. Суть метода заключается в том, чтобы внести такое изменение в структуру регистра, которое сделает старые таблицы несовместимыми с новыми.
Разберем по шагам этот алгоритм:
УдалитьПослеОчистки и типом Число). Также можно изменить периодичность регистра или длину кода связанного измерения, но добавление реквизита — самый безопасный путь.F7 для обновления конфигурации базы данных.F7).В результате этих манипуляций мы получаем абсолютно чистый регистр без единой лишней записи в таблице AccumRgTn, при этом нам не потребовалось включать итоги и ждать их мучительного пересчета.
Если реструктуризация по каким-то причинам не помогает (например, из-за специфических повреждений файла .1CD), мы можем применить радикальный метод удаления объекта из метаданных.
Выполним следующие действия:
F7). На этом этапе платформа физически уничтожит все таблицы, связанные с этим регистром, в файле .1CD..cf файлом или копией базы.Этот метод гарантирует 100% очистку, так как таблицы создаются «с нуля». Однако помните, что если на этот регистр ссылаются другие объекты (отчеты, документы), вам придется восстанавливать эти связи.
Проанализируем ситуацию: память часто заканчивается не на самом факте включения итогов, а на попытке рассчитать их за весь период существования данных (от 0001 года). Мы можем попробовать программно «обмануть» систему, установив период рассчитанных итогов в глубокое прошлое.
Для этого в режиме 1С:Предприятие создадим внешнюю обработку и используем следующий код:
РегистрМенеджер = РегистрыНакопления.Продажи;
// Устанавливаем период расчета итогов на минимально возможную дату
РегистрМенеджер.УстановитьПериодРассчитанныхИтогов(Дата('00010101'));
После установки такой границы попробуем включить использование итогов. Платформа может проигнорировать старые записи, так как они окажутся за пределами периода актуальности. Если это не помогло напрямую, попробуем выполнить Тестирование и исправление с единственным выбранным пунктом «Реструктуризация таблиц информационной базы». В отличие от обычного пересчета, реструктуризация в ТиИ работает более оптимально с точки зрения потребления памяти.
Если «решение по месту» не срабатывает из-за колоссального объема данных, проанализируем возможность временного использования x64 клиента. Ошибка Out of memory при достижении 3.8 Гб — это фундаментальное ограничение 32-битной архитектуры Windows. Процесс просто не может адресовать больше памяти, даже если на сервере установлено 64 Гб.
Рассмотрим порядок действий:
Выясним причину, почему обычный пересчет может не помогать. Если в данных присутствуют логические ошибки (например, движения с пустыми датами или некорректными регистраторами), итоги могут уходить в бесконечный цикл расчета. Перед любыми манипуляциями крайне рекомендуется запустить проверку логической целостности в режиме ТиИ.
Также стоит проверить размер страницы файла базы данных. Если ваша база создана давно, размер страницы может быть 4 Кб. Современные версии позволяют использовать 16 Кб или 32 Кб, что значительно повышает стабильность работы с большими таблицами итогов. Смена размера страницы также происходит в процессе реструктуризации при изменении параметров базы.
Подводя итог, можно сказать, что наиболее надежным и быстрым способом очистки «зависших» оборотов в файловой базе без использования стороннего ПО является метод временного добавления реквизита в метаданные. Это позволяет использовать штатные механизмы платформы для полной физической пересоздачи табличного пространства регистра, обходя ограничения оперативной памяти при расчете виртуальных таблиц.