Почему зависает сравнение конфигураций 1С на 0% при обновлении базы SQL и как это исправить?

Системный администратор 1С v8.3 (Обычные формы) IT и автоматизация бизнеса
← На главную

При обновлении крупных или сильно доработанных конфигураций (таких как «Управление производственным предприятием» редакции 1.3 или «ERP Управление предприятием») администраторы и разработчики часто сталкиваются с неприятной проблемой. Процесс сравнения и объединения конфигураций в Конфигураторе полностью зависает на отметке 0%. При этом нагрузка на процессор может отсутствовать, либо, наоборот, один из процессов загружает ядро на максимум, но сдвига не происходит часами. Попытка запустить стандартное «Тестирование и исправление» из Конфигуратора также заканчивается аварийным завершением работы программы.

Интересной особенностью данной проблемы является то, что при выгрузке информационной базы в файловый вариант (в формате .1cd) сравнение и объединение конфигураций проходит абсолютно штатно и без ошибок. Это прямо указывает на то, что физические таблицы данных не повреждены, а корень проблемы кроется в механизмах взаимодействия платформы 1С с СУБД SQL, повреждении служебных таблиц метаданных или в нехватке системных ресурсов. Рассмотрим подробнее причины этого поведения и разберем по шагам действенные методы устранения зависания.

Причина 1. Недостаток памяти и разрядность Конфигуратора (32-bit против 64-bit)

Выясним причину, почему файловая база может успешно обрабатывать сравнение, а клиент-серверный вариант зависает. Конфигурация УПП 1.3 содержит колоссальное количество объектов метаданных. В процессе сравнения на SQL-базе Конфигуратор пытается считать и сопоставить структуры таблиц СУБД и конфигурации поставщика, загружая огромный объем информации в оперативную память клиентского компьютера.

Если для запуска Конфигуратора используется 32-разрядный клиент 1С:Предприятия, процесс гарантированно упрется в жесткое ограничение адресного пространства для 32-битных приложений Windows (которое составляет около 2 ГБ для одного процесса). Преодолев этот лимит, Конфигуратор не всегда выдает ошибку Недостаточно памяти. Гораздо чаще он просто уходит в бесконечный цикл, визуально зависая на 0%, или аварийно закрывается без объяснения причин.

Что необходимо сделать:

  1. Установите на рабочую станцию, с которой выполняется обновление, 64-разрядную версию технологической платформы 1С:Предприятие (клиентское приложение x64).
  2. При добавлении информационной базы в список в настройках запуска явно укажите разрядность «64 (x64)» вместо «Выбирать автоматически».
  3. Запустите Конфигуратор и повторите попытку сравнения. В большинстве случаев использование 64-битного клиента полностью решает проблему нехватки памяти при сопоставлении метаданных крупных конфигураций.

Причина 2. Накопление «хвостов» динамического обновления в SQL

Динамическое обновление (так называемое «обновление на лету» или «hot-update») — это очень удобный инструмент, который позволяет вносить изменения в конфигурацию без выгона пользователей из базы. Однако за это удобство приходится платить стабильностью структуры данных. При частом динамическом обновлении таблицы СУБД, отвечающие за хранение конфигурации, начинают фрагментироваться, и в них накапливаются некорректные или дублирующиеся записи. Рано или поздно это приводит к ситуации, когда база отказывается обновляться обычным способом, а Конфигуратор зависает.

В базе данных SQL за хранение конфигурации отвечают служебные таблицы Config (основная конфигурация) и ConfigSave (сохраняемая, но еще не примененная конфигурация). При сбое динамического обновления в них зависают маркеры транзакций, которые блокируют процесс сравнения.

Проанализируем ситуацию и выполним очистку этих таблиц. Перед выполнением любых операций в СУБД обязательно создайте полную резервную копию базы данных (бэкап)!

Запустите Microsoft SQL Server Management Studio (SSMS), создайте новый запрос к вашей базе данных и выполните следующие команды:


-- 1. Очищаем таблицу ConfigSave, которая хранит промежуточные несохраненные конфигурации
DELETE FROM dbo.ConfigSave;

-- 2. Удаляем зависшие маркеры незавершенных или аварийно прерванных транзакций динамического обновления из таблицы Config
DELETE FROM dbo.Config WHERE FileName = 'commit';
DELETE FROM dbo.Config WHERE FileName = 'dynamicCommit';
DELETE FROM dbo.Config WHERE FileName = 'dbStruFinal';

После успешного выполнения скрипта запустите Конфигуратор, выполните команду «Конфигурация — Открыть конфигурацию» (если она была закрыта), а затем попробуйте запустить сравнение/объединение заново.

Причина 3. Испорченный кэш (пользовательский и серверный)

Платформа 1С активно кэширует структуру метаданных для ускорения работы. Кэш создается как на локальном компьютере пользователя (в папках %AppData%\Local\1C и %AppData%\Roaming\1C), так и на сервере приложений 1С:Предприятие. При некорректном завершении процессов обновления файлы кэша могут повредиться, из-за чего Конфигуратор при сравнении обращается к битым локальным файлам и зависает.

Разберем по шагам процедуру полной очистки кэша:

  1. Очистка пользовательского кэша: Самый простой способ — удалить базу из списка запуска в стартере 1С и добавить ее заново под тем же именем. При этом временные папки кэша для этой базы отвяжутся. Для гарантии можно вручную удалить все папки с буквенно-цифровыми GUID-именами из каталогов %localappdata%\1C\1cv8 и %appdata%\1C\1cv8 при закрытых сеансах 1С.
  2. Очистка серверного кэша метаданных:
    • Остановите службу сервера «1С:Предприятие» (например, через оснастку services.msc).
    • Перейдите в каталог службы на сервере приложений (по умолчанию это C:\Program Files\1cv8\srvinfo\reg_1541\).
    • Найдите папку с GUID-идентификатором вашей информационной базы.
    • Внутри этой папки найдите и удалите каталог snccg. Именно в нем хранится кэш скомпилированных модулей конфигурации. Внимание: не удаляйте файлы настроек и журналы регистрации (папку 1Cv8Log).
    • Очистите системную папку Temp на самом сервере приложений 1С.
    • Запустите службу сервера «1С:Предприятие».

Причина 4. Полная замена поврежденной таблицы Config из «здоровой» базы

Если очистка маркеров динамического обновления не помогла, а Конфигуратор продолжает зависать или вылетать при попытке сравнения (или даже при открытии конфигурации), это говорит о серьезном логическом повреждении структуры таблицы Config. В этом случае мы можем полностью заменить данные таблицы конфигурации, взяв их из «здоровой» копии той же самой версии программы.

Посмотрим на пример решения этой задачи:

  1. Разверните из старого бэкапа или создайте новую пустую базу данных на SQL и загрузите туда конфигурацию той же самой версии, которая установлена у вас в рабочей базе (в виде файла конфигурации .cf). Назовем эту базу Clean_Base, а вашу рабочую базу — Work_Base.
  2. Убедитесь, что все пользователи вышли из рабочей базы, и остановите все сеансы в консоли администрирования 1С.
  3. Откройте SQL Server Management Studio и выполните запрос, который полностью очистит поврежденную таблицу конфигурации в рабочей базе и заполнит ее актуальными и целыми данными из чистой базы:

-- Очищаем поврежденную таблицу конфигурации в рабочей базе
DELETE FROM Work_Base.dbo.Config;

-- Копируем структуру и данные из заведомо исправной базы-донора
INSERT INTO Work_Base.dbo.Config
SELECT * FROM Clean_Base.dbo.Config;

После выполнения данного скрипта структура метаданных в вашей рабочей базе будет приведена в абсолютно корректное состояние, идентичное конфигурации-донору, при этом все пользовательские данные (документы, справочники, регистры) останутся нетронутыми. Запустите Конфигуратор рабочей базы и выполните сравнение конфигураций.

Причина 5. Нехватка места на диске и ограничения TempDB в SQL Server

Во время сравнения метаданных таких тяжелых конфигураций, как УПП, SQL-сервер производит колоссальное количество вычислений и транзакций во временных таблицах. Для этого используется системная база данных СУБД — tempdb.

Проанализируем настройки вашего SQL-сервера. Если диск, на котором располагаются файлы базы данных tempdb, переполнен, или если для файлов tempdb установлены жесткие ограничения по максимальному размеру (например, отключено авторасширение Autogrow), СУБД приостановит выполнение транзакции сравнения. Конфигуратор при этом будет бесконечно ожидать ответа от SQL-сервера, создавая видимость зависания на 0%.

Рекомендации по настройке:

Причина 6. Использование монопольного режима базы данных

Иногда процессу сравнения и реструктуризации мешают неявные блокировки таблиц со стороны фоновых заданий, сессий веб-сервисов или зависших соединений, которые не видны в консоли кластера 1С. Для гарантированного исключения блокировок рекомендуется временно перевести базу данных на стороне SQL-сервера в однопользовательский режим (Single User).

Выполните следующий скрипт в SSMS перед началом обновления:


-- Переводим базу данных в монопольный режим, сбрасывая все активные соединения
ALTER DATABASE Work_Base SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

После перевода базы в этот режим доступ к ней сможет получить только один сеанс (в данном случае — ваш Конфигуратор). Запустите Конфигуратор, выполните сравнение, объединение и сохранение конфигурации базы данных. По завершении всех процедур обязательно верните базу в многопользовательский режим работы:


-- Возвращаем базу данных в обычный режим работы для пользователей
ALTER DATABASE Work_Base SET MULTI_USER;

Резюме и превентивные меры

Мы подробно разобрали причины, по которым зависает процесс сравнения конфигураций 1С на SQL-сервере. В подавляющем большинстве случаев виной тому является накопление ошибок после динамических обновлений или нехватка оперативной памяти у 32-битного клиента Конфигуратора.

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

← На главную