При обновлении конфигураций 1С, особенно таких крупных, как 1С:ERP, с одной версии на другую, например, с 2.4.14.181 на 2.5.7.402, мы часто сталкиваемся с этапом «отложенного обновления данных». Этот процесс критически важен для адаптации структуры и содержимого информационной базы к новой версии конфигурации. Однако, иногда процесс отложенного обновления может остановиться, оставив нас с незавершенными обработчиками и отсутствием прогресса. В данной статье мы подробно разберем, почему это происходит, как диагностировать проблему и какие шаги предпринять для ее устранения.
Для начала, давайте выясним основные факторы, которые могут привести к зависанию процесса отложенного обновления. Понимание корневых причин поможет нам выбрать наиболее эффективный путь решения.
Переполнение журнала транзакций SQL Server. Одна из наиболее частых причин остановки или замедления обновлений в клиент-серверных базах. Журнал транзакций (transaction log) в SQL Server активно заполняется во время обширных операций по изменению данных, а обновление 1С — это именно такая операция. Если журнал транзакций исчерпывает свободное место на диске или достигает своего максимального размера, все транзакции, включая операции обновления, могут быть приостановлены или отменены. Автоматическое сжатие (shrink) журнала транзакций во время активного процесса обновления, хотя и может освободить место, не всегда является рекомендованным решением, поскольку оно влияет на возможности восстановления базы данных. Важно убедиться в наличии достаточного свободного места на дисках перед началом объемных обновлений.
Эффективное управление журналом транзакций в SQL Server включает в себя следующие методы:
SIMPLE. В этом режиме SQL Server автоматически усекает журнал транзакций, освобождая место, без необходимости регулярного создания резервных копий журнала. После завершения обновления, крайне важно вернуть модель восстановления в исходное состояние (часто это FULL), если требуется детализированное восстановление на момент времени.FULL, единственным способом усечения журнала транзакций и освобождения места является регулярное создание резервных копий журнала транзакций. Если бэкапы журнала не делаются, он будет постоянно расти, даже если место на диске еще есть.Тайм-ауты и ошибки обработчиков. Отдельные обработчики отложенного обновления могут прерываться по истечении установленного времени (тайм-ауту), особенно если они выполняют сложные или длительные операции над большим объемом данных. Также возможны ситуации, когда обработчик сталкивается с ошибками в самих данных, которые не были предусмотрены его логикой, или попадает в бесконечный цикл. Не исключены и ошибки в коде самих обработчиков, допущенные разработчиками платформы или конфигурации.
Блокировка или отключение регламентных заданий. В клиент-серверном режиме работы 1С, отложенное обновление выполняется с помощью регламентных заданий. Если регламентное задание с именем "Отложенное обновление ИБ" отключено, заблокировано, или если у пользователя, от имени которого оно выполняется, недостаточно прав, процесс обновления, разумеется, остановится.
Прерывание процесса обновления. Случайное или принудительное прерывание процесса обновления (например, закрытие окна обновления, перезагрузка сервера приложений или СУБД) может привести к некорректному завершению транзакций и, как следствие, к блокировке информационной базы и остановке выполнения обработчиков.
Недостаток ресурсов. Нехватка оперативной памяти на сервере 1С:Предприятия или SQL Server, недостаточное дисковое пространство для временных файлов или журнала транзакций, а также общая нехватка ресурсов СУБД (процессорного времени, операций ввода/вывода) могут привести к замедлению, зависанию или остановке транзакций и всего процесса обновления.
Прежде чем приступать к устранению проблемы, нам необходимо провести тщательную диагностику, чтобы точно определить, на каком этапе и по какой причине остановилось обновление. Это позволит нам применить наиболее целесообразные решения.
Отчет "ПрогрессОтложенногоОбновления". Этот отчет является нашим основным инструментом для мониторинга хода отложенного обновления. Мы можем найти его в разделе "Администрирование" - "Обслуживание" - "Результаты обновления и дополнительная обработка данных". Отчет "ПрогрессОтложенногоОбновления" предоставляет детальную информацию о статусе каждого обработчика: сколько из них выполнено, сколько осталось, какие зависли, и какую диагностическую информацию они содержат. Анализ этого отчета позволяет нам понять, на каком конкретном обработчике возникла проблема.
Журнал регистрации 1С. Журнал регистрации является неоценимым источником информации о событиях, происходящих в информационной базе, включая ошибки выполнения обработчиков обновления. Нам следует тщательно проанализировать записи журнала регистрации, фильтруя их по событиям, связанным с обновлением данных или выполнением регламентных заданий. Автор сообщения привел пример записи из журнала регистрации, указывающей на зависшую процедуру:
<Structure xmlns="http://v8.1c.ru/8.1/data/core" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Structure">
<Property name="Библиотека">
<Value xsi:type="xs:string">УправлениеТорговлей</Value>
</Property>
<Property name="Версия">
<Value xsi:type="xs:string">11.5.7.319</Value>
</Property>
<Property name="Процедура">
<Value xsi:type="xs:string">РегистрыНакопления.ТоварыКОтгрузке.ОбработатьДанныеДляПереходаНаНовуюВерсию</Value>
</Property>
<Property name="ВерсияРегистрации">
<Value xsi:type="xs:string">11.5.7.319</Value>
</Property>
<Property name="РежимВыполнения">
<Value xsi:type="xs:string">Отложенно</Value>
</Property>
<Property name="ОбластьДанныхЗначение">
<Value xsi:type="xs:decimal">-1</Value>
</Property>
<Property name="ОбластьДанныхИспользование">
<Value xsi:type="xs:boolean">false</Value>
</Property>
<Property name="ЗначениеНаНачало">
<Value xsi:type="xs:decimal">63805835232922</Value>
</Property>
<Property name="Выполнен">
<Value xsi:type="xs:boolean">false</Value>
</Property>
<Property name="Длительность">
<Value xsi:type="xs:decimal">11.359</Value>
</Property>
</Structure>
Из этой записи мы видим ключевые поля:
Процедура: Указывает на конкретную процедуру, которая не завершилась (в данном случае РегистрыНакопления.ТоварыКОтгрузке.ОбработатьДанныеДляПереходаНаНовуюВерсию).РежимВыполнения: Отложенно подтверждает, что процедура ожидает выполнения.Выполнен: false показывает, что процедура еще не завершена.Такая информация позволяет нам точно определить проблемный обработчик и сосредоточить усилия на его решении.
Фоновые задания. В клиент-серверной архитектуре 1С, отложенное обновление выполняется через фоновые задания. Мы должны проверить список фоновых заданий (который также находится в разделе "Администрирование" - "Обслуживание" - "Регламентные и фоновые задания") на предмет наличия зависших или завершившихся с ошибками задач, особенно тех, которые называются "Отложенное обновление ИБ". Если такое задание зависло или завершилось с ошибкой, мы увидим причину в его свойствах.
После того как мы провели диагностику и определили вероятную причину остановки, давайте рассмотрим, как мы можем возобновить процесс отложенного обновления и довести его до конца.
Ручной перезапуск отложенного обновления. Если процесс остановился из-за падения сервера 1С:Предприятия (rphost) или СУБД (SQL Server), регламентное задание по отложенному обновлению может перестать работать автоматически. В таких случаях нам потребуется "пнуть" его вручную. Важно понимать: все объекты, требующие обновления, регистрируются в специальном плане обмена отложенного обновления. После успешной обработки объект удаляется из этого плана и не будет обновляться повторно. Это означает, что при перезапуске система продолжит работу с того места, где остановилась, пропуская уже обработанные элементы.
Мы можем перезапустить процесс несколькими способами:
ОбновлениеИнформационнойБазыСлужебный и его процедура ВыполнитьОтложенноеОбновлениеСейчас().Пример кода для программного перезапуска:
ОбновлениеИнформационнойБазыСлужебный.ВыполнитьОтложенноеОбновлениеСейчас();
Мы запускаем этот код в режиме 1С:Предприятие от имени пользователя с полными правами.
Изменение статуса обработчика вручную. Если отчет "ПрогрессОтложенногоОбновления" или журнал регистрации указали на конкретный зависший обработчик, который не завершается, мы можем попробовать изменить его статус вручную. Для этого переходим в "Администрирование" - "Обслуживание" - "Результаты обновления программ". Находим проблемную процедуру (часто мы можем перейти к ней, дважды щелкнув по строке с ошибкой в отчете или журнале регистрации). В свойствах этого обработчика мы можем изменить его статус.
Важное предостережение: Не следует вручную изменять параметры "Очереди", так как эти номера используются при регистрации объектов в плане обмена отложенного обновления, и их некорректное изменение может нарушить логику и целостность процесса обновления.
Для ускорения обработки зависшего обработчика можно попробовать изменить его режим выполнения на "Монопольно". Прежде чем делать это, мы должны обязательно убедиться, что в базе нет других активных пользовательских сеансов, так как монопольный режим требует единоличного доступа к базе данных.
Работа с проблемными данными. Если причиной остановки обработчика являются ошибки в данных (например, некорректные ссылки, дубликаты, или данные, не соответствующие новой структуре), нам потребуется исправить эти данные. Если ошибка в данных критическая и не позволяет обработчику завершиться, иногда может потребоваться временная разблокировка объекта для редактирования. В "Результатах обновления и дополнительной обработки данных", в меню "Еще" может быть опция "Разблокировать объект для редактирования". После исправления данных (или установки патча, если ошибка в типовой логике), мы можем точечно перезапустить проблемный обработчик.
Управление журналом транзакций SQL Server. Как мы уже обсуждали, переполнение журнала транзакций является распространенной причиной. Вместо простого сжатия (shrink), которое может быть опасным и временным решением, мы должны применить системный подход:
FULL (с регулярным резервным копированием журнала), либо SIMPLE (если не требуется детализированное восстановление на момент времени). Мы можем проверить это в свойствах базы данных в SQL Server Management Studio.FULL, создавайте резервные копии журнала транзакций регулярно. Это позволит SQL Server усекать журнал и освобождать место.SIMPLE: На время проведения масштабного обновления, которое заполняет журнал, мы можем временно переключить модель восстановления на SIMPLE. После завершения обновления и успешной проверки целостности данных, вернитесь к модели FULL, если это требуется для вашей стратегии резервного копирования и восстановления.Переход с версии 1С:ERP 2.4 на 2.5 является масштабным мероприятием и требует особого внимания. Обновление с 2.4.14 на 2.5.7, как в исходном сообщении, представляет собой значительный скачок, который сопряжен с серьезными изменениями в структуре данных и функционале.
Планирование и время. Обновление нетиповой конфигурации 1С:ERP (особенно с доработками) с версии 2.4 на 2.5 может занять очень много времени. Один из участников форума упоминает, что подготовка файла конфигурации (cf) заняла полтора месяца, а обработка отложенного обновления — еще две недели. Мы должны быть готовы к тому, что этот процесс может быть длительным и потребует значительных ресурсов.
Актуальность версии. Важно помнить, что поддержка 1С:ERP 2.4 завершилась в апреле 2022 года. Это означает, что переход на версию 2.5 является не только желательным, но и необходимым для получения актуальных обновлений и поддержки.
Нетиповые конфигурации. Если ваша конфигурация доработана, то при обновлении до 2.5, скорее всего, потребуется адаптация существующих модификаций. Этот процесс может быть сложным и трудоемким, и существуют специальные решения для автоматизированного переноса кода, но они не всегда способны решить все проблемы.
Возможные проблемы с функционалом. В процессе перехода на новые версии 2.5 (например, 2.5.7), пользователи сообщали о возможных проблемах с корректировками и расчетом себестоимости. Нам следует быть особенно внимательными к этим участкам функционала после обновления и провести тщательное тестирование.
Сохранение журнала регистрации. Если вы работаете с файловой базой и планируете обновление платформы или перенос базы, всегда рекомендуется перед началом обновления скопировать папку 1cv8Log/, чтобы сохранить историю журнала регистрации. После обновления мы можем вернуть ее на место.
В заключение, проблема остановки отложенного обновления в 1С:ERP — это сложная, но решаемая задача. Ключ к успеху лежит в тщательной диагностике, понимании механизмов работы 1С и SQL Server, а также в методичном применении проверенных решений. Всегда проводите обновление на тестовой копии базы данных и имейте актуальные резервные копии перед началом любых критических операций. Это позволит нам минимизировать риски и обеспечить успешный переход на новую версию конфигурации. Для минимизации времени простоя при обновлении масштабных баз можно использовать методику проведения обновления через копию.