Что делать, если реструктуризация регистра бухгалтерии зависла при переходе с БП 2.0 на 3.0

Переход с конфигурации «Бухгалтерия предприятия 2.0» на «Бухгалтерию предприятия 3.0» — это не просто обновление версии, а глобальная смена архитектуры данных. Одним из самых тяжелых этапов этого процесса является реструктуризация основного регистра — РегистрБухгалтерии.Хозрасчетный. На больших информационных базах (от 50 Гб и выше) этот процесс может занимать десятки часов или даже несколько суток. Проанализируем, как понять, действительно ли процесс завис, и что можно сделать для ускорения этой процедуры.

Анализируем состояние процесса: зависание или длительная обработка

Когда окно обновления 1С часами показывает одну и ту же цифру в строке «Реструктуризация», первым делом необходимо определить состояние сеанса на стороне сервера СУБД. Рассмотрим ситуацию на примере PostgreSQL, так как именно на этой СУБД чаще всего возникают сложности с длительными блокировками и «тяжелыми» запросами UPDATE.

Проанализируем действия, которые помогут нам прояснить ситуацию:

1. Мониторинг через консоль кластера 1С: Проверим колонки «Захват СУБД» и «Чтение/Запись». Если показатели меняются хотя бы на несколько байт в течение 10–15 минут, процесс идет. Если показатели замерли намерто — это повод для беспокойства.
2. Мониторинг через PGAdmin или SQL Shell: Нам нужно найти активный запрос, который выполняет платформа. Обычно при реструктуризации регистра «Хозрасчетный» выполняется масштабный UPDATE. Пример такого запроса мы можем увидеть в логах:

UPDATE _AccRg634NG SET _ValueDt1_TYPE = T4._Value_TYPE, _ValueDt1_RTRef = T4._Value_RTRef, 
_ValueDt1_RRRef = T4._Value_RRRef, _KindDt1RRef = T4._KindRRef ...
FROM _AccRg634NG T2
LEFT OUTER JOIN _Acc16_ExtDim627NG T3 ON T3._Acc16_IDRRef = T2._AccountDtRRef

Этот запрос выполняет перенос данных субконто в новую структуру таблиц. В PostgreSQL выполнение одного гигантского UPDATE на миллионы строк крайне неэффективно из-за механизма MVCC (каждая обновляемая строка помечается как удаленная и создается новая копия), что приводит к «раздуванию» таблицы (bloat) и огромной нагрузке на дисковую подсистему.

Почему процесс может «зависнуть» на PostgreSQL

Выясним основные причины, по которым реструктуризация регистра бухгалтерии длится бесконечно долго:

• Транзакционный лог (WAL): Если объем генерируемых логов при обновлении регистра превышает выделенное дисковое пространство или настройки max_wal_size слишком малы, СУБД будет постоянно делать контрольные точки (checkpoints), приостанавливая запись.
• Недостаток оперативной памяти для обслуживания: Для создания индексов после вставки данных PostgreSQL использует maintenance_work_mem. Если этот параметр установлен в значение по умолчанию (например, 64МБ), создание индексов на таблице в 80ГБ будет происходить с использованием жесткого диска, что замедлит процесс в десятки раз.
• Потерянные ссылки и дубли: Наличие в базе 2.0 объектов с битой ссылочной целостностью или дублирующихся записей в итогах заставляет механизм реструктуризации 1С тратить колоссальное время на попытки сопоставить данные.

Подготовка информационной базы перед переходом

Чтобы избежать многодневных простоев, выполним предварительную подготовку базы в конфигурации 2.0. Рассмотрим пошагово, какие операции критически важны:

1. Тестирование и исправление (ТиИ). Проанализируем состояние базы. Обязательно выберем пункты: «Реиндексация таблиц», «Проверка логической целостности», «Проверка ссылочной целостности» (с параметром «Очищать объекты»).

2. Управление итогами. Это «секретный» способ ускорить реструктуризацию. Перед запуском обновления в режиме Конфигуратора или через «Операции — Управление итогами» отключим использование итогов для всех регистров. В этом случае 1С будет реструктуризировать только таблицы движений, не тратя время на пересчет итоговых таблиц, которые все равно будут пересозданы в 3.0. После успешного перехода итоги можно будет рассчитать уже в новой базе.

3. Свертка информационной базы. Если база имеет размер более 50–70 Гб, рассмотрим вариант свертки данных на начало текущего или прошлого года. Удаление неактуальных записей из регистра Хозрасчетный до конвертации — самый эффективный способ сократить время перехода. Как показывает практика, свертка 85-гигабайтной базы может уменьшить время реструктуризации с 3 суток до 4–6 часов.

Оптимизация настроек PostgreSQL для тяжелого обновления

Разберем параметры postgresql.conf, которые следует временно изменить на период реструктуризации для достижения максимальной производительности:

1. maintenance_work_mem = 2GB (или больше, если позволяет RAM) — ускорит перестроение индексов после обновления данных.
2. checkpoint_timeout = 30min — уменьшит частоту сброса данных на диск.
3. max_wal_size = 10GB — позволит накапливать больше изменений в логах перед их очисткой.
4. autovacuum = off — на время массового UPDATE его можно отключить, чтобы процесс очистки не конкурировал за ресурсы с основным запросом (после завершения обязательно включить обратно и выполнить VACUUM FULL).

Использование режима «Новая реструктуризация»

Проанализируем возможности платформы 1С:Предприятие 8.3. В новых версиях платформы (8.3.11+) существует два режима реструктуризации. Если мы сталкиваемся с проблемами, можно попробовать изменить параметр dbmsRequestsOutputMethods или в свойствах конфигурации в Конфигураторе изменить «Режим совместимости» и «Режим реструктуризации».

По умолчанию используется деструктивный метод: создается временная таблица, в нее копируются данные, старая удаляется. Если места на диске меньше, чем 2.5 размера самой крупной таблицы базы, процесс гарантированно остановится из-за нехватки дискового пространства.

Выводы и рекомендации

Если процесс остановился на Реструктуризация РегистрБухгалтерии.Хозрасчетный, и вы видите активный SQL-запрос — не прерывайте его. Прерывание транзакции на этапе обновления регистра приведет к откату (rollback), который может длиться столько же времени, сколько уже прошло, и в итоге вы получите «битую» базу.

Рассмотрим краткий чек-лист действий, если вы только планируете переход:

• Проверьте соотношение размеров .dt и базы в SQL. Если разница огромная (например, 30 Гб против 100 Гб), выполните сжатие таблиц и очистку итогов.
• Убедитесь, что на диске СУБД свободно не менее 2-кратного объема всей базы данных.
• Если база на PostgreSQL работает слишком медленно, рассмотрите возможность временного переноса на MS SQL Server (режим Simple), проведения конвертации там, и возврата на PostgreSQL. MS SQL зачастую эффективнее обрабатывает массовые изменения схем данных.
• Обязательно удалите все расширения конфигурации перед началом конвертации, так как они часто вызывают неявные конфликты в структуре метаданных.

Помните, что переход на 3.0 для крупных организаций — это проект, требующий технического окна минимум в 2–3 дня. Как показал опыт пользователей, иногда нужно просто подождать 48 часов, пока система завершит пересчет итогов и индексов.