При обновлении конфигурации 1С:Бухгалтерия Предприятия 3.0 (особенно при переходе с релизов ветки 3.0.82 на 3.0.85 и выше) многие технические специалисты сталкиваются с критической проблемой. Внешне обновление конфигурации проходит успешно, однако при первом запуске программы в режиме «1С:Предприятие» процесс «замирает» на отметке 93%. Ожидание в течение нескольких часов или даже всей ночи не приносит результата. В этой статье мы подробно разберем, почему это происходит и как успешно завершить обновление информационной базы.
Проанализируем ситуацию: зависание происходит в момент выполнения отложенных обработчиков обновления. Конкретная процедура, вызывающая сбой — РегистрыСведений.СтатусыДокументов.ЗаполнитьНомераСчетовФактурПоДокументамРеализация. Если мы запустим сеанс в режиме отладки и прервем его в момент зависания, то увидим, что система бесконечно долго выполняет следующий запрос:
ВЫБРАТЬ ПЕРВЫЕ 1000
РеализацияТоваровУслуг.Организация КАК Организация,
РеализацияТоваровУслуг.Ссылка КАК Документ,
ЕСТЬNULL(СтатусыДокументов.Статус, &СтатусПоУмолчанию) КАК Статус,
ЕСТЬNULL(СчетФактураВыданныйДокументыОснования.Ссылка.ПредставлениеНомера, "") КАК НомерСчетаФактуры
ИЗ
Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
ЛЕВОЕ СОЕДИНЕНИЕ Документ.СчетФактураВыданный.ДокументыОснования КАК СчетФактураВыданныйДокументыОснования
ПО РеализацияТоваровУслуг.Ссылка = СчетФактураВыданныйДокументыОснования.ДокументОснование
И (НЕ СчетФактураВыданныйДокументыОснования.Ссылка.ПометкаУдаления)
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СтатусыДокументов КАК СтатусыДокументов
ПО РеализацияТоваровУслуг.Ссылка = СтатусыДокументов.Документ
ГДЕ
НЕ СчетФактураВыданныйДокументыОснования.Ссылка ЕСТЬ NULL
И НЕ СтатусыДокументов.Документ ЕСТЬ NULL
И СтатусыДокументов.НомерСчетаФактуры = ""
И СчетФактураВыданныйДокументыОснования.Ссылка.ПредставлениеНомера <> ""
УПОРЯДОЧИТЬ ПО
РеализацияТоваровУслуг.Дата УБЫВ
Рассмотрим структуру этого запроса подробнее. Система пытается сопоставить документы РеализацияТоваровУслуг с их счетами-фактурами через табличную часть ДокументыОснования. Выясним причину низкой производительности: использование ЛЕВОЕ СОЕДИНЕНИЕ с табличной частью документа в сочетании с жестким условием ГДЕ ... НЕ ... ЕСТЬ NULL создает колоссальную нагрузку на СУБД (или файловый движок), заставляя его выполнять полное сканирование таблиц вместо использования индексов.
Основная причина «мертвого» зависания в файловом варианте базы данных кроется в ошибке оптимизатора запросов платформы 1С:Предприятие 8.3.17 и ранних версий 8.3.18. В этих релизах был изменен механизм работы с временными таблицами и соединениями, что привело к деградации производительности в типовых механизмах БСП (Библиотеки стандартных подсистем).
Для решения проблемы выполним следующие шаги:
ЗаполнитьНомераСчетовФактурПоДокументамРеализация отрабатывает за несколько секунд или минут).Если по каким-то причинам вы не можете сменить платформу, проанализируем возможность изменения самого кода обновления. Рассмотрим, как можно ускорить работу процедуры вручную:
Откроем конфигуратор и найдем модуль менеджера регистра сведений СтатусыДокументов. Найдем процедуру ЗаполнитьНомераСчетовФактурПоДокументамРеализация. Мы можем уменьшить порцию обрабатываемых данных. В оригинальном запросе стоит ограничение ВЫБРАТЬ ПЕРВЫЕ 1000. Попробуем изменить это значение на 100 или даже 50.
Хотя общее количество итераций увеличится, СУБД будет проще строить план запроса для небольшого объема данных. Посмотрим на результат: после внесения изменений в код (при условии, что конфигурация находится на поддержке с возможностью редактирования) обновление начнет «двигаться», и вы увидите прогресс в процентах в пользовательском интерфейсе.
Часто причиной зависания становятся некорректные данные («битые» ссылки) в регистре СтатусыДокументов или в табличных частях документов, которые образовались в результате обменов. Перед запуском обновления крайне важно выполнить Тестирование и исправление (ТиИ).
Выполним по шагам:
Важный момент: Реиндексация таблиц обновляет статистику для файловой СУБД, что позволяет оптимизатору запросов платформы 1С корректно выбирать индексы при выполнении соединений документов.
Если ваша база работает на сервере PostgreSQL, проблема может быть связана с параметром nestloop. В некоторых случаях сервер выбирает неэффективную стратегию вложенных циклов. Проанализируем настройки сервера:
Попробуйте временно установить параметр enable_nestloop = off в конфигурационном файле postgresql.conf или выполните команду актуализации статистики ANALYZE для всей базы данных перед запуском обновления. Для MS SQL Server аналогичным действием будет выполнение UPDATE STATISTICS. Это поможет серверу «увидеть» реальное распределение данных и не уходить в бесконечное ожидание при выполнении LEFT JOIN.
Если никакие методы не помогают, а завершить обновление критически важно, мы можем принудительно сообщить системе, что обработчик выполнен. Рассмотрим, как это сделать с помощью регистра сведений ОбновлениеИнформационнойБазы:
РегистрыСведений.СтатусыДокументов.ЗаполнитьНомераСчетовФактурПоДокументамРеализация.Внимание: Этот метод является «костылем». После такого действия номера счетов-фактур в формах списка реализаций могут отображаться некорректно. Чтобы это исправить позже, вам потребуется запустить перепроведение документов или написать небольшую обработку, которая перезапишет данные в регистре СтатусыДокументов в фоновом режиме, когда база уже будет доступна пользователям.
Подводя итог, отметим, что наиболее эффективным и безопасным способом является использование стабильной платформы 8.3.16 для прохождения этапа обновления данных. Это исключает необходимость вмешательства в программный код и гарантирует целостность данных в регистре статусов документов.