Ранее мы писали, как подбирать промежуточных (ключевые) конфигурации для обновления и какие методы оптимизации можно применить, чтобы ускорить установку обновления на базу.
Расскажем, как эти знания помогли в конкретных проектах при обновлении сильно доработанных конфигураций на новые подредакции или при большом количестве пропущенных релизов.
Случай 1: долго устанавливается обновление
Исходные данные:
- «1С: Управление торговлей» версии 11.4.13,
- целевой релиз 11.5.17,
- 4 промежуточных конфигурации.
Описание проблемы:
мы подготовили четыре промежуточные конфигурации версий 11.4.14, 11.5.8, 11.5.12, 11.5.17 (целевой релиз), но установка обновлений на версии 11.5.8 и 11.5.12 серьезно затягивают обновление. Согласно замерам, общее время обновления занимало 58 часов. Целевое время обновления — 48 часов.
- Общее время реструктуризации до оптимизации — 11:14:00.
- Общее время основных обработчиков до оптимизации — 5:32:00.
- Общее время отложенных обработчиков до оптимизации — 40:25:00.
После анализа отложенных обработчиков версий 11.5.8, 11.5.12 была выявлена основная проблема задержки: данные заказов в версии 11.4.13 хранились в регистре накопления «Свободные остатки».
В версии 11.5.8 обработчик перекидывает данные в регистр накопления «Распределение запасов движений», а регистр «Свободные остатки» безвозвратно удален. Также заполняется новый регистр сведений «Распределение запасов».
В версии 11.5.12 данные из регистра накопления «Распределение запасов движений» переносятся в новый регистр накопления «Запасы и потребности». Записи в «Распределение запасов движений» сохраняются. Записи в регистре сведений «Распределение запасов» корректируются.
В версии 11.5.17 безвозвратно удаляется регистр накопления «Распределение запасов движений», остаются регистры «Запасы и потребности» и «Распределение запасов».
Раз в этих версиях обработчики переносят данные по остаткам через промежуточный регистр накопления «Распределение запасов движений», то можно сократить общее время обновления, если сформировать все записи один раз и сразу в конечный регистр накопления «Запасы и потребности».
Что мы предприняли: в версиях 11.5.8, 11.5.12 полностью отключили обработчики обновления регистра накопления «Распределение запасов движений», регистра сведений «Распределение запасов», регистра накопления «Запасы и потребности».
В 11.5.17 разработали свой обработчик обновления регистра накопления «Запасы и потребности» взяв за основу обработчик из версии 11.5.12. В него же добавили функционал заполнения регистра сведений «Распределение запасов» таким образом, чтобы он выполнялся только после заполнения регистра накопления.
После тестирования обновления выполнили замеры установки промежуточных на базу:
- Общее время реструктуризации — 11:14:00.
- Общее время основных обработчиков — 5:00:00.
- Общее время отложенных обработчиков — 22:00:00.
Итого, общее время установки обновления сократилось до 38 часов. Mission clear!
Случай 2: потеря данных из-за изменений в архитектуре типовой конфигурации
Исходные данные:
- 1С:ERP. Управление холдингом версии 3.1.11,
- целевой релиз 3.2.1,
- одна промежуточная конфигурация 3.1.13.
Описание проблемы:
заказчик остро нуждался в новом функционале по аренде, лимитированию, бюджетированию. Этот функционал сильно изменился между подредакциями, а также был сильно доработан в рабочей конфигурации. После обновления доработанный функционал некорректно работал из-за отсутствия данных.
Документ «Оперативный план» в новой версии переименован в неиспользуемый и разделен на два новых документа в соответствии с видами операций: новый «Оперативный план» и «Резервирование». Этот документ был доработан в рабочей конфигурации, поэтому при обновлении надо было также разделить по разным документам изменения в структуре данных. Необходимо было выявить какие обработчики отвечают за перенос данных, проанализировать и доработать их и новые документы.
Помимо этого в рабочей конфигурации документ «Оперативный план» использовался в добавленных объектах (в реквизитах, движениях), а после обновления в этих объектах уже были ссылки на неиспользуемые документы. Для решения этой проблемы были разработаны обработчики обновления, которые заполнили новые реквизиты и заменили регистраторы в движениях актуальными данными.
Случай 3: долго идет реструктуризация
Исходные данные:
- 1С: Бухгалтерия предприятия КОРП 3.0.103.21 + Бит.Финанс 3.1.50.4,
- целевой релиз 3.0.163.26 + 3.1.61.13, без промежуточных.
Описание проблемы:
на сервере заказчика реструктуризация шла трое суток из-за плана счетов «Хозрасчетный», это непозволительно долго для их небольшой по объему базы.
Мы включили и настроили оптимизированный механизм реструктуризации (v2). Замеры показали ускорение в несколько раз.
Время реструктуризации на нашем сервере:
- v1 — 4 часа.
- v2 — 20 минут.
Время реструктуризации на сервере заказчика:
- v1 — 108 часов.
- v2 — 3 часа.
Случай 4: сильно увеличивается размер базы
Исходные данные:
- 1С: ERP 2.2.3.231,
- целевой релиз 2.4.13.103,
- 4 промежуточных — 2.2.4, 2.4.7, 2.4.11, 2.4.13,
- база 1.6 ТБ.
Описание проблемы:
по коду конфигурации было видно, что база претерпела несколько частичных обновлений из версий 2.2.4, 2.5.7, 2.4.13. При обновлении на вторую промежуточную конфигурации (с 2.2.4 на 2.4.7) база на выполнении некоторых отложенных обработчиков зависала на неделю, сильно увеличивалась в размере, а процесс так и не завершался. Допустимый промежуток установки обновления на базу составлял 5 дней на все промежуточные.
Мы проанализировали данные в базе и нашли два источника зависания.
Первый — зависал обработчик обновления графика работ в производственном календаре. При этом все графики работ уже актуальны и заполнены в ходе ранее сделанных частичных обновлений. Было принято решение отключить обработчик насовсем, так как в нем не было необходимости.
Второй — обновление проходило с допустимой скоростью, а 90% времени занимал расчет итогов, выполнявшийся при записи данных регистров накопления в обработчиках обновления, который вел к разрастанию TempDB и увеличению файла базы с исходного размера 1.6 ТБ до 6 ТБ.
В связи с этим мы определили обработчики обновления регистров накопления, в коде которых не использовались обращения к виртуальным таблицам остатков и оборотов и приняли решение отключить итоги программно перед выполнением обработчика и включить после выполнения обработчика.
Такое действие сделали с регистрами накопления ТрудозатратыКОформлению, ТоварыКПоступлению, СебестоимостьТоваров, РасчетыСКлиентами, ДвиженияНоменклатураНоменклатура, ВыпускПродукции, ВыручкаИСебестоимостьПродаж, ОбеспечениеПроизводственныхПроцессов, ТрудозатратыНезавершенногоПроизводства, ТоварыОрганизаций, ПрочиеРасходыНезавершенногоПроизводства.
По последним замерам эта промежуточная с 2.2.4 на 2.4.7 устанавливалась на базе целиком за 36 часов без разрастания базы до 6 ТБ, что позволяло уложить обновление со всеми промежуточными этапами в заданные 5 суток. После установки обновления база стала весить 2.2 ТБ.
Случай 5: обработчик обновления выполняется без ошибок, но данные остаются необновленными
Исходные данные:
- 1С:CRM 3.0.16.11,
- целевой релиз 3.1.31.25,
- 6 промежуточных — 3.0.21, 3.0.22, 3.0.23, 3.0.27, 3.0.29, 3.0.31,
- база 100 Гб.
Описание проблемы:
при тестировании обновления выяснилось, что по какой-то причине данные справочника «Партнеры» не были обработаны. Проблема началась еще на первом шаге обновления с исходной 3.0.16 на первую промежуточную 3.0.21. Если обновлять последовательно через все регламентированные 1С релизы (3.0.17, 3.0.18, 3.0.19, 3.0.20, 3.0.21), то ошибки нет, а если с 3.0.16 сразу на 3.0.21, то ошибка есть. При этом все обработчики обновления с предыдущих версий присутствуют в 3.0.21.
По отчету о прогрессе отложенного обновления мы обнаружили, что обработчики из 3.0.18 и 3.0.19 версий обрабатывают один и тот же объект — справочник «Партнеры» и регистрируют данные к обновлению на один узел обмена плана обмена «ОбновлениеИнформационнойБазы».
В отчете по прогрессу обновления обработчики перечислены через запятую, а очередь у них одна
Вместе с этим обнаружили, что аналогичная проблема будет и с документом «CRM_Интерес».
Обработчики документа «CRM_Интерес»
На примере справочника «Партнеры» в коде тоже можно это увидеть, как это было реализовано в конфигурации.
Обработчики в 1С:CRM 3.0.18.6
Обработчики в 1С:CRM 3.0.19.5
Получилось так, что при обновлении с оптимизацией обработчики начинают работать с одной и той же очередью данных. После обработки данных обработчик версии 3.0.18 снимает объекты с регистрации, и второму обработчику версии 3.0.19 уже никаких данных не остается, и он выполнился без ошибок, потому что ничего не обновил.
Проблема решилась доработкой обработчика 3.0.19 версии — мы перенесли регистрацию данных на другой узел.
Перенос регистрации данных обработчика
