Почему тестирование и исправление базы 1С с маркировкой занимает несколько дней и как решить проблему?

Рассмотрим частую и очень болезненную ситуацию, с которой сталкиваются компании, занимающиеся оптовой или розничной продажей маркированных товаров (особенно сигарет и обуви). При попытке выполнить стандартную процедуру «Тестирование и исправление» (ТИИ) в конфигурации 1С:Управление торговлей 11 процесс может затянуться на 6 и более дней. Проанализируем причину этой проблемы, выясним, почему мощное оборудование (SSD, RAM-диски) не спасает ситуацию, и разберем по шагам, как правильно обслуживать такие базы.

Выясним причину: архитектурная особенность 1С и специфика маркировки

Проблема кроется не в СУБД PostgreSQL или слабости компьютера, а в архитектуре самой платформы 1С:Предприятие и специфике учета маркированных товаров. Если мы посмотрим на структуру данных торговой базы, работающей с табачной продукцией (Честный ЗНАК), то обнаружим, что самый тяжелый объект — это Справочник.ШтрихкодыУпаковокТоваров.

В этот справочник записывается каждая проданная пачка, блок и коробка. В оптовой торговле сигаретами объем записей растет лавинообразно. В рассматриваемом примере таблица хранения этого справочника (например, Reference23920) разрослась до более чем 3,5 миллионов записей. Проанализируем, что происходит при запуске ТИИ:

1. Проверка логической целостности: Платформа проверяет внутреннюю структуру каждой из миллионов записей штрихкодов.
2. Проверка ссылочной целостности: Это самый ресурсоемкий этап. Для каждой из 3,5 миллионов записей справочника система начинает сканировать все связанные таблицы в базе (документы, табличные части, регистры), чтобы убедиться, что на этот объект нет «битых» ссылок. Это генерирует колоссальный объем запросов, который физически невозможно обработать быстро.

Даже если мы перенесем базу на сверхбыстрый RAM-диск или разгоним процессор до 5.1 ГГц, алгоритм платформы всё равно будет выполнять перебор огромного массива данных. Значит, проблему нужно решать на уровне оптимизации объема данных и методологии обслуживания.

Разберем решения проблемы долгого тестирования

Разберем по шагам практические подходы, которые помогут избежать недельных простоев из-за ТИИ.

Решение 1. Регулярная очистка отработанных штрихкодов

Главный метод решения проблемы — радикальное уменьшение объема самого справочника ШтрихкодыУпаковокТоваров. Хранить миллионы кодов маркировки уже реализованных товаров бессмысленно, так как они больше никогда не вернутся в оборот.

Рекомендуем настроить процесс очистки:

1. Используйте типовые регламентные задания по очистке пула кодов маркировки и устаревших статусов (если они предусмотрены вашей версией конфигурации).
2. Напишите внешнюю обработку, которая будет искать штрихкоды товаров, отгруженных в прошлых закрытых периодах (например, старше 3-6 месяцев), помечать их на удаление и удалять штатным механизмом платформы.
3. Настройте запуск этой обработки порциями (партиями) по ночам, чтобы не блокировать работу пользователей.

Важно: Никогда не удаляйте записи напрямую через SQL-запросы в PostgreSQL (например, через команду DELETE FROM). Это неизбежно нарушит логическую структуру базы и приведет к появлению тех самых «битых ссылок», которые потом "повесят" базу при ТИИ.

Решение 2. Правильный подход к Тестированию и исправлению

Для объемных баз с маркировкой от регулярного полного ТИИ со всеми галочками стоит отказаться. Рассмотрим альтернативный сценарий обслуживания:

1. Запускайте «Проверку ссылочной целостности» только в экстренных случаях: например, если в базе реально появились «битые ссылки» после жестких сбоев обмена данными или некорректного физического повреждения базы.
2. Для регулярной профилактики в 1С достаточно выполнять только Пересчет итогов.
3. Для поиска битых ссылок используйте профильные внешние обработки. Они работают быстрее штатного ТИИ, так как позволяют исключить из проверки тяжелые справочники (вроде штрихкодов упаковок) и проверять только критически важные финансовые и складские документы.

Решение 3. Обслуживание на стороне СУБД PostgreSQL

Хотя тюнинг СУБД не ускорит саму алгоритмическую проверку ссылок 1С в 10 раз, правильная настройка PostgreSQL критически важна для баз с постоянной текучкой данных (когда мы регулярно записываем и удаляем штрихкоды).

Посмотрим на рекомендуемые настройки для файла конфигурации postgresql.conf:

• Если вы используете PostgreSQL 12 и выше, рекомендуется установить параметр jit = off. Компиляция «на лету» (JIT) часто негативно сказывается на специфических запросах 1С.
• Включите агрессивный autovacuum.
• Периодически проводите VACUUM FULL (полную очистку таблиц от мертвых строк), REINDEX и ANALYZE (обновление статистики) средствами самой СУБД в нерабочее время. Это освободит физическое место на диске после массового удаления штрихкодов из базы.

Небольшое отступление: Как правильно считать огромное количество записей

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

При вычислении количества записей на языке запросов 1С следует всегда использовать агрегатную функцию КОЛИЧЕСТВО, а не СУММА(1). При количестве записей 10 миллионов и более использование суммы единиц приведет к переполнению, так как платформа по умолчанию использует для этого числа длину 7 разрядов.

Неправильно:

ВЫБРАТЬ 
    СУММА(1) КАК КоличествоЗаписей
ИЗ 
    Справочник.ШтрихкодыУпаковокТоваров

Правильно:

ВЫБРАТЬ 
    КОЛИЧЕСТВО(*) КАК КоличествоЗаписей
ИЗ 
    Справочник.ШтрихкодыУпаковокТоваров

Подведем итоги

Долгое тестирование и исправление базы 1С с маркированным товаром — это нормальное поведение платформы при объеме справочника штрихкодов в миллионы строк. Чтобы база "дышала" свободно, регулярно очищайте справочник от отгруженных марок средствами 1С, настройте правильное регламентное обслуживание PostgreSQL и откажитесь от тотальной проверки ссылочной целостности без острой необходимости.