← На главную

Длительное обновление конфигурации 1С:Управление торговлей (УТ) с версии 11.4 на 11.5 является весьма распространенной проблемой, с которой сталкиваются многие администраторы и программисты. Это связано с существенными изменениями в архитектуре конфигурации, особенно в части механизмов взаиморасчетов и работы с остатками. Если вы столкнулись с тем, что обновление занимает часы или даже дни, блокируя работу пользователей, давайте вместе разберем основные причины и эффективные методы для ускорения этого процесса.

Предварительная подготовка и диагностика проблемы

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

1. Полная архивная копия базы данных: Это критически важный шаг. Мы всегда начинаем с создания полной и актуальной резервной копии базы данных. Это наша "страховка" на случай непредвиденных ошибок или сбоев во время обновления.
2. Анализ размера и производительности базы: Мы видим, что выгрузка файла .dt составляет 3 ГБ, а развернутая база — 50 ГБ. Для УТ это можно считать небольшой или средней базой. Однако, даже при небольшом документообороте, объем данных может быть значительным для пересчета. Мы должны оценить, какой объем данных будет обрабатываться, чтобы спрогнозировать длительность переноса или обработки.
3. Проверка аппаратного обеспечения: Мы выясняем, что вся нагрузка упирается в процессор (например, i7-7700k). Мы должны понимать, что этот процессор уже достаточно старый, и с тех пор сменилось порядка семи поколений процессоров. 1С является частотозависимым приложением, поэтому производительность процессора, особенно его тактовая частота, играет ключевую роль. Мы рассматриваем вопрос серьезного апгрейда оборудования как один из первых шагов, иначе проблем с производительностью не избежать. Дополнительно, мы обеспечиваем достаточный объем оперативной памяти, а для экстремальных случаев можем рассмотреть временное размещение базы на диске в ОЗУ (RAM-диске) на время обновления для максимального ускорения дисковых операций.
4. Проведение регламентных процедур (ТиИ): Мы обязательно выполняем тестирование и исправление базы данных (ТиИ) до начала обновления. Это помогает выявить и устранить логические и физические ошибки в структуре данных, которые могут замедлить или остановить процесс обновления.
5. Очистка базы данных: Мы проводим инвентаризацию и сверку остатков, завершаем все возможные незакрытые заказы, очищаем систему от неактуальных элементов справочников и проверяем связи между документами. Это уменьшает объем данных, которые необходимо будет пересчитывать и преобразовывать в процессе обновления.
6. Идентификация монопольных обработчиков: Если система не дает войти, пока не закончены обработчики, это означает, что мы имеем дело с монопольными обработчиками обновления. Они блокируют доступ к базе данных для всех пользователей до своего завершения. Это отличается от отложенных обработчиков, которые могут выполняться в фоновом режиме или вместе с работой пользователей.
7. Проблемные участки: Мы видим, что обновление зависает на процедурах Справочники.Контрагенты.ЗарегистрироватьДанныеКГенерацииОбъектовРасчетов и работе с регистром РасчетыСКлиентамиПоДокументам. Это очень важная информация, так как «объекты расчетов» — одно из ключевых отличий УТ 11.5 (2.5) от предыдущих версий. Эти процедуры требуют значительных вычислительных ресурсов для перестройки логики взаиморасчетов.

Оптимизация оборудования и настроек сервера 1С/СУБД

Для ускорения процесса обновления мы можем применить ряд оптимизаций на уровне оборудования и программного обеспечения.

1. Апгрейд оборудования: Мы уже обсудили важность процессора. Если бюджет позволяет, мы настоятельно рекомендуем приобрести более мощный сервер с современным многоядерным процессором (желательно серверного класса, но для 1С десктопные процессоры с высокой тактовой частотой часто показывают себя хорошо), достаточным объемом быстрой оперативной памяти (минимум 32-64 ГБ) и быстрой дисковой подсистемой (SSD NVMe).
2. Настройки SQL Server (для клиент-серверного варианта):
   • Перевод базы в режим Simple Recovery: На время обновления мы можем временно перевести базу данных MS SQL Server в режим восстановления Simple Recovery. Это значительно уменьшит размер журнала транзакций и ускорит операции записи, так как не будет необходимости сохранять полную историю транзакций для восстановления на произвольный момент времени. После обновления мы не забываем вернуть режим восстановления обратно в Full.
   • Отключение журнала регистрации 1С: Аналогично, мы можем отключить журнал регистрации 1С на время обновления. Это снизит нагрузку на дисковую подсистему и базу данных, поскольку система не будет записывать каждое действие. После обновления мы обязательно включаем журнал обратно.
   • Выделение памяти для MS SQL: Мы проверяем и, при необходимости, увеличиваем объем памяти, выделенной для MS SQL Server, чтобы он мог эффективно кэшировать данные и индексы.
   • Добавление индексов: С осторожностью, и только после тщательного анализа, мы можем рассмотреть возможность добавления пучка индексов по рекомендациям опытных специалистов. Однако, это должно быть сделано очень аккуратно, чтобы не нарушить лицензионное соглашение и не создать дополнительные проблемы.
   • Сдвиг границ итогов регистров накопления: В некоторых случаях может помочь временный сдвиг границ итогов регистров накопления на начало месяца. Это может уменьшить объем данных, которые СУБД должна обрабатывать при построении итогов.
3. Настройки сервера 1С:Предприятие:
   • Количество ядер и потоков: Мы проверяем, сколько ядер и потоков выделено для работы сервера 1С. Если приоритет в данный момент — это обработка данных обновления, мы можем временно перевыставить приоритет на обработку данных и указать оптимальное количество потоков.
   • Запуск обновления в пользовательском режиме: Мы запускаем обновление не из конфигуратора, а в пользовательском режиме (1С:Предприятие). Это позволяет использовать все ресурсы сервера 1С и SQL, а также специфические оптимизации платформы для пакетной обработки данных.

Стратегии обновления и работа с проблемными обработчиками

Когда речь идет о таком масштабном обновлении, как с УТ 11.4 на 11.5, мы часто рассматриваем несколько стратегий, чтобы минимизировать время простоя и обеспечить целостность данных.

1. Обновление на копии с последующим переносом данных (рекомендуемый вариант):

   Это самый надежный подход, особенно когда у предприятия нет выходных или возможности остановить работу надолго. Мы действуем по следующей схеме:

   1. Создание актуальной копии: Мы создаем полную копию рабочей базы данных.
   2. Обновление копии: Мы обновляем эту копию до целевой версии 11.5. Этот процесс может занять несколько дней, так как монопольные обработчики будут выполняться. Мы следим за процессом, устраняем возможные ошибки.
   3. Параллельная работа: Пока копия обновляется, пользователи продолжают работать в старой базе 11.4.
   4. Перенос данных: После успешного обновления копии и завершения всех обработчиков, мы должны перенести документы, созданные и измененные в старой базе за период обновления, в новую базу 11.5. Для этого мы можем использовать различные методы:
      • Журнал регистрации (ЖР): Мы анализируем журнал регистрации, чтобы выявить все новые и измененные объекты.
      • Версионирование объектов: Если версионирование было включено, мы можем использовать его для определения изменений.
      • Написание правил конвертации данных: Часто для такого масштабного перехода требуется написание собственных правил конвертации данных. Это полноценный проект, который требует знаний структуры данных обеих версий. Мы обращаем особое внимание на "объекты расчетов", так как их структура и использование кардинально изменились.
      • Обмен данными: Для небольшого документооборота, как в вашем случае, мы можем договориться с пользователями, чтобы они не делали лишних справочников и лишних документов, которые не нужны оперативно. Затем мы допереносим только один-два вида критически важных документов обработкой за период работы.
   5. Контрольный период: После переноса данных мы проводим контрольный период работы в обновленной базе, чтобы убедиться в корректности всех операций и отчетов.

   Мы видим пример успешного использования такого подхода для ERP с базой 2 ТБ, где перегрузка данных заняла 14 часов после недели обновления копии.

2. Прямое обновление в рабочей базе:

   Если нет возможности использовать стратегию с копией, и мы готовы к длительному простою, мы выполняем прямое обновление. Мы запускаем процесс обновления в пользовательском режиме. Важно использовать режим реструктуризации v2 (режим второго поколения). Этот режим существует уже около 10 лет и многие специалисты рекомендуют его как более стабильный и часто более быстрый, хотя для мелких обновлений он может стартовать дольше из-за инициализации Java.

   Мы помним, что при обновлении с 11.4 на 11.5 происходит не простое обновление, а "тектоническое" изменение конфигурации. Например, были удалены регистры СвободныеОстатки, ГрафикДвижения, ГрафикПоступления и введены новые. Это требует значительной перестройки данных и переписывания запросов.

3. Работа с обработчиками обновления:

   Если обновление зависает на процедурах, как Справочники.Контрагенты.ЗарегистрироватьДанныеКГенерацииОбъектовРасчетов или регистре РасчетыСКлиентамиПоДокументам, это означает, что система перестраивает механизмы взаиморасчетов. Мы должны понимать, что эти процедуры, такие как Документы.ПриходныйКассовыйОрдер.ЗарегистрироватьДанныеДляГенерацииОбъектовРасчетов, являются обязательными, так как объекты расчетов — это одно из ключевых отличий УТ 11.5.

   Мы отслеживаем статус обработчиков в окне "Результаты обновления и дополнительная обработка данных". Если обработчик зависает, мы можем попытаться перезапустить его точечно. В крайних случаях, если мы уверены в своих действиях, можем разрешить редактирование необновленных объектов, но это требует глубокого понимания внутренних механизмов.

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

Выбор актуальной версии конфигурации

Выбор правильной целевой версии УТ 11.5 также играет важную роль в успешности обновления.

1. Избегаем проблемных релизов: Мы знаем, что в некоторых выпущенных версиях УТ 11.5.26.93, 11.5.26.96 и 11.5.26.100 были выявлены проблемы, которые могли проявиться при обновлении конфигурации. Мы стараемся избегать таких релизов для первоначального перехода.
2. Рекомендованные версии для перехода: Для перехода с 11.4 на 11.5 часто рекомендуются определенные стабильные версии. Например, если обновление требуется для работы с "Честным знаком", мы рекомендуем обновиться на 11.5.22.170. Если вы пробовали 11.5.7 и 11.5.8.329 и столкнулись с проблемами, мы можем попробовать версию 11.5.8.443, которая, возможно, содержит исправления производительности в обработчиках по сравнению с предыдущими версиями.
3. Постоянное развитие 1С: Мы помним, что фирма "1С" постоянно работает над оптимизацией производительности в УТ 11.5, сокращая время запрета на вход при обновлении, уменьшая размер базы и ускоряя проведение документов и фоновые расчеты. Поэтому всегда лучше стремиться к наиболее актуальным и стабильным релизам.

Особенности доработанных конфигураций

Если у вас доработанная конфигурация, мы должны быть готовы к дополнительным трудностям.

1. Адаптация доработок: Наличие большого количества доработок, особенно затрагивающих регистры остатков и взаиморасчетов, значительно усложняет обновление. Мы должны быть готовы к тому, что все эти доработки придется адаптировать под новую архитектуру 11.5, а в некоторых случаях — полностью рефакторить.
2. Возможная несовместимость данных: Из-за масштабных изменений в логике и структуре данных, особенно связанных с "объектами расчетов", могут возникать проблемы с целостностью данных. Мы видим, что это часто вызывает опасения по поводу возможной "каши в данных" после обновления.
3. Написание правил переноса: В случае сильно доработанных баз, где прямой перенос через обновление может не сработать, мы рассматриваем переход как полноценный проект с написанием правил переноса остатков и документов.

Проверка после обновления

После завершения всех этапов обновления и обработки данных, мы не расслабляемся, а переходим к критически важному этапу проверки.

1. Проверка корректности данных: Мы тщательно проверяем все ключевые данные:
   • Остатки товаров: Убеждаемся, что все остатки товаров на складах перенесены корректно.
   • Взаиморасчеты: Проверяем отчеты по взаиморасчетам с клиентами и поставщиками, чтобы убедиться, что данные не задвоились, не потерялись и полностью соответствуют действительности.
   • Резервы: Контролируем правильность резервов и распределения товаров.
   • Ставки НДС: Убеждаемся в корректности применяемых ставок НДС.
2. Тестовая эксплуатация: Мы проводим тестовую эксплуатацию с участием ключевых пользователей, чтобы выявить возможные проблемы в реальной работе.

Таким образом, долгое обновление УТ с 11.4 на 11.5 — это не просто техническая задача, а комплексный проект, требующий тщательной подготовки, оптимизации ресурсов, продуманной стратегии и внимательной проверки. Следуя этим рекомендациям, мы значительно повысим шансы на успешное и наименее болезненное завершение этого процесса.