Переход со старых редакций конфигурации «1С:Управление торговлей» (в частности, переход с ветки 11.3 на 11.4) на базах объемом от 50–60 гигабайт и выше часто превращается в настоящую головную боль для администраторов и программистов. Стандартный запуск обновления в режиме «1С:Предприятие» запускает так называемые отложенные обработчики обновления, которые могут выполняться сутками, создавая иллюзию «зависания» системы. В этой статье мы подробно разберем, почему попытки выгрузить данные через XML обречены на провал, как правильно подготовить СУБД и сервер «1С:Предприятие» к этой процедуре, и как форсировать выполнение дополнительных процедур обновления.
Почему выгрузка документов через XML — это тупиковый путь?
У многих разработчиков при виде зависшего на сутки обновления возникает соблазн пойти по «простому» пути: создать чистую базу редакции 11.4 и перенести туда данные (например, документы за последний месяц или год) с помощью обработки УниверсальныйОбменДаннымиXML. Рассмотрим, почему этот способ не просто неэффективен, но и опасен для учета:
Кардинальные различия в структуре метаданных. Редакция 11.4 существенно отличается от 11.3 архитектурой регистров. В ней полностью переработаны механизмы партионного учета, расчета себестоимости и схемы передачи товаров между организациями (Intercompany). Прямой перенос документов через XML без написания сложнейших правил конвертации в программе «Конвертация данных» приведет к тому, что загруженные документы либо не проведутся, либо сформируют некорректные движения.
Нарушение баланса и потеря ссылочной целостности. Если переносить документы частично (например, только реализации за месяц), вы получите разорванные связи со справочниками, отсутствие исторических остатков на складах и взаиморасчетов с контрагентами. Восстановить финансовый результат в такой базе будет невозможно.
Проблема производительности XML-парсера. На больших базах данных (60 Гб и более) выгрузка и чтение XML-файлов объемом в десятки гигабайт гарантированно вызовут ошибку нехватки памяти (Out of Memory) на этапе разбора DOM-модели файла. Специфика формата XML требует огромных аппаратных ресурсов для обработки дерева метаданных в памяти.
Таким образом, единственным методологически верным решением является полноценное последовательное обновление существующей конфигурации. Наша задача — не пытаться обойти этот процесс, а оптимизировать его проведение.
Анатомия проблемы: почему отложенные обработчики зависают?
Проанализируем, что происходит на техническом уровне, когда мы запускаем первый сеанс «1С:Предприятия» после обновления конфигурации базы данных (накатывания метаданных). В этот момент управление берет на себя Библиотека стандартных подсистем (БСП). Она запускает обработчики обновления информационных баз.
Эти обработчики делятся на два типа:
Оперативные: выполняются до запуска пользователей в монопольном режиме. Без их завершения войти в программу невозможно.
Отложенные (фоновые): выполняются в фоновом режиме, позволяя пользователям работать. Именно они на больших базах «висят» сутками.
При переходе на УТ 11.4 система выполняет масштабную реструктуризацию тяжелых регистров накопления, таких как ВыручкаИСебестоимостьПродаж и СебестоимостьТоваров. Миллионы строк исторических данных начинают перезаписываться с учетом новых реквизитов и измерений. Если в базе за прошлые годы есть логические ошибки (например, документы с незаполненными ключевыми аналитиками, которые в 11.4 стали обязательными), фоновый обработчик БСП может уйти в бесконечный цикл попыток проведения документа или завершиться со скрытой ошибкой блокировки транзакции, не сообщая об этом пользователю.
Пошаговый алгоритм оптимизации СУБД (MS SQL Server) перед обновлением
Чтобы обновление 60-гигабайтной базы прошло в адекватные сроки, необходимо временно перенастроить СУБД, убрав все «узкие места» дисковой подсистемы и транзакционного механизма. Разберем необходимые действия на примере MS SQL Server:
Перевод базы данных в модель восстановления Simple (Простая). По умолчанию рабочие базы часто работают в модели Full (Полная) для возможности создания бэкапов транзакций. При массовом изменении данных в процессе обновления файл лога транзакций (.ldf) может разрастись до размеров, превышающих саму базу данных (100–150 Гб), что приведет к переполнению диска и остановке работы. Переведите базу в режим Simple на время обновления.
Предварительное увеличение размеров файлов БД и лога. Чтобы MS SQL Server не тратил время на динамическое расширение файлов базы данных (autigrow) во время тяжелых транзакций, заранее увеличьте размер файлов .mdf и .ldf на диске с запасом в 20–30%.
Обновление статистики и дефрагментация индексов. Перед началом обновления выполните регламентные процедуры СУБД. Устаревшая статистика заставит оптимизатор SQL строить неэффективные планы запросов, из-за чего выборка миллионов записей из регистров затянется. Запустите следующие SQL-скрипты:
-- Обновление статистики для всей базы данных
EXEC sp_updatestats;
Временное отключение Журнала регистрации 1С. Запись огромного объема служебных сообщений о проведении и модификации документов во время работы обработчиков БСП создает колоссальную нагрузку на диск. В настройках администрирования базы на сервере «1С:Предприятие» временно установите уровень детализации журнала регистрации в положение «Регистрировать только ошибки» или полностью выключите его.
Включение многопоточности в БСП для ускорения обновления
По умолчанию отложенное обновление БСП выполняется в один или два потока, чтобы минимизировать нагрузку на сервер и дать возможность пользователям комфортно работать. Но в нашей ситуации, когда мы проводим технологическое обновление на копии базы (в монопольном режиме для пользователей), нам нужно задействовать все свободные ресурсы сервера.
Выясним, как перевести обновление в многопоточный режим высокой производительности:
Запустите обновленную базу в режиме «1С:Предприятие» под пользователем с административными правами.
Перейдите в раздел НСИ и администрирование — Обслуживание — Результаты обновления программы.
Найдите гиперссылку «Техническая информация о результатах обновления» (или «Отложенное обновление»).
В открывшейся форме измените приоритет обновления. Переключите его с режима «Работа пользователей» на режим «Обработка данных (максимальная скорость)».
Укажите количество потоков обновления. Рекомендуется устанавливать значение, равное числу ядер процессора на сервере «1С:Предприятие» (например, 8 или 16 потоков).
Этот простой шаг позволяет сократить время выполнения тяжелых процедур БСП в 5–10 раз за счет параллельной обработки документов в несколько потоков фоновыми заданиями.
Что делать, если обработчик «завис» на конкретном документе или регистре?
Если процесс все же остановился, не нужно паниковать и прерывать его аварийно. Сначала выполним диагностику:
Откройте консоль кластера серверов 1С и посмотрите на сеансы фоновых заданий. Обратите внимание на показатели захвата СУБД и процессорного времени. Если показатели меняются, значит, процесс идет, просто таблица слишком велика.
Если показатели замерли, откройте форму контроля обновления в режиме «Предприятие». Найдите процедуру, которая выполняется в данный момент.
Если конкретная процедура обновления регистра выдает ошибку, проанализируйте возможность ее временного обхода. В БСП существует возможность пропустить некоторые необязательные обработчики или запустить их повторно вручную после устранения логических ошибок в данных (например, битых ссылок). Для исправления битых ссылок предварительно запустите процедуру «Тестирование и исправление» с включенной опцией «Очищать объекты» при наличии несуществующих ссылок.
Альтернативный подход: Свертка базы перед переходом на 11.4
Рассмотрим ситуацию, когда база объемом 60 Гб содержит исторические данные за последние 7–10 лет, при этом актуальный период работы менеджеров охватывает только последний год. В этом случае пытаться обновить всю историю — нерационально.
Рекомендуем применить следующую стратегию:
Проведение свертки базы данных в исходной редакции 11.3. Выполните свертку на начало текущего или прошлого года с помощью стандартной обработки «Свертка информационной базы». При этом все документы прошлых лет будут удалены, а вместо них создадутся документы ввода остатков.
Очистка базы и сжатие таблиц СУБД. После удаления старых документов выполните операцию SHRINK (сжатие) базы данных на SQL-сервере. Объем базы уменьшится с 60 Гб до 10–15 Гб.
Обновление «легкой» базы. Обновление свернутой базы до редакции 11.4 пройдет за считанные часы, так как объем обрабатываемых регистров себестоимости и расчетов сократится на 80%. Старую базу 11.3 оставьте в качестве архивной для просмотра истории.
Аппаратные требования к серверу на время обновления
Проанализируем требования к «железу» сервера 1С и СУБД для проведения таких тяжелых операций. На время обновления настоятельно рекомендуется перенести копию базы на производительный тестовый контур (так называемую «убер-машину»), даже если для этого придется арендовать облачные мощности на пару дней.
Ключевые требования к оборудованию:
Оперативная память (RAM): Объем оперативной памяти на сервере должен быть не меньше физического размера базы данных на диске плюс еще 20–30% для кэширования таблиц в СУБД. Для базы 60 Гб целесообразно выделить сервер с 96–128 Гб RAM. Это позволит SQL Server держать критически важные индексы и таблицы целиком в оперативной памяти, исключая медленные операции чтения с диска.
Дисковая подсистема: Процедуру обновления необходимо выполнять исключительно на быстрых твердотельных накопителях (SSD корпоративного класса или NVMe). Использование классических HDD-дисков увеличит время обновления в десятки раз.
Можно ли использовать файловый режим для промежуточного обновления?
В сообщении 42 участники обсуждения упоминают, что в современных версиях платформы 8.3 снято ограничение на размер одной таблицы в 4 Гб за счет изменения размера страницы файловой базы данных до 8 Кб. Однако использовать файловый вариант для обновления базы объемом 60 Гб — категорически не рекомендуется.
Файловая СУБД не способна эффективно распараллеливать запросы на запись и использовать многопоточность так, как это делает полноценный MS SQL или PostgreSQL. Попытка обновить базу такого объема в файловом варианте на обычном ПК приведет к многократному замедлению процесса по сравнению с клиент-серверным вариантом работы.
Выводы
Мы выяснили, что лучшим способом обновления базы «1С:Управление торговлей 11» является стандартный последовательный переход по релизам, выполненный на копии базы данных на мощном оборудовании. Отказ от сомнительных схем с частичной XML-выгрузкой документов убережет вас от потери финансового результата и ошибок в учете себестоимости. Используя настройки многопоточности БСП и оптимизацию СУБД MS SQL, вы сможете успешно провести обновление даже самой крупной информационной базы в кратчайшие сроки.