При обновлении или сравнении конфигураций в 1С:Предприятие 8 на базе MS SQL Server специалисты иногда сталкиваются с неприятной ситуацией: процесс зависает на 0% и не продвигается в течение длительного времени. Часто это свидетельствует о повреждении внутренних таблиц метаданных или накоплении ошибок после динамических обновлений. Разберем подробно структуру хранения конфигурации в SQL и методы исправления подобных проблем.
Для начала проанализируем, в каких именно таблицах SQL-базы располагаются данные конфигурации. В отличие от версии 7.7, где конфигурация хранилась в файле 1cv7.md, в версии 8.x вся информация находится внутри таблиц БД. Основными являются следующие:
Config и DBSchema — критическая ошибка.Важно понимать, что данные в этих таблицах хранятся в виде BLOB (Binary Large Objects). Они сжаты алгоритмом Deflate (zlib) и представляют собой сложную древовидную структуру. Попытка ручного редактирования этих данных через SQL Management Studio без специального инструментария практически невозможна и опасна для целостности базы.
Рассмотрим основные причины, по которым процесс сравнения может «замереть» в самом начале:
Config и Params могут накопиться противоречивые записи, так называемые «хвосты».snccntx) может содержать устаревшие или битые ссылки на объекты метаданных.Прежде чем переходить к радикальным мерам в SQL, выполним стандартные действия по очистке окружения. Проанализируем состояние кэша сервера и клиентских машин.
Остановите службу сервера 1С:Предприятие. Перейдите в каталог с данными сервера (обычно это C:\Program Files\1cv8\srvinfo\reg_1541) и найдите папку с UID вашей базы. Внутри нее удалите папки snccntx и Config (если она есть). Это принудит систему перечитать данные непосредственно из SQL при следующем запуске.
Также попробуйте выполнить стандартное Тестирование и исправление (ТиИ) в Конфигураторе. В данном случае нас интересует пункт «Проверка логической целостности конфигурации». Если Конфигуратор не открывается или зависает на этом этапе, переходим к работе с SQL.
Если зависание происходит в момент сравнения, велика вероятность, что проблема кроется в таблице ConfigSave. Мы можем безопасно очистить её, чтобы «сбросить» состояние редактируемой конфигурации к состоянию основной конфигурации базы данных.
Выполним следующий скрипт в SQL Management Studio (предварительно убедитесь, что у вас есть бэкап):
-- Очищаем таблицу сохраняемой конфигурации
TRUNCATE TABLE ConfigSave;
-- Удаляем признаки динамического обновления, если они мешают
DELETE FROM Params WHERE Name = 'v8.DynamicUpdate';
После выполнения этих команд попробуйте снова зайти в Конфигуратор. Система увидит, что редактируемая конфигурация пуста, и подгрузит её из основной таблицы Config. Часто это решает проблему зависания.
Иногда «хвосты» динамического обновления не дают корректно сравнить конфигурации. В таблице Config могут присутствовать дублирующие записи для одних и тех же объектов. Выясним причину через технологический журнал или попытаемся принудительно очистить признаки обновления.
Рассмотрим ситуацию, когда в таблице Params зависли старые идентификаторы. Специалисты рекомендуют аккуратно проверить записи:
-- Проверка наличия записей о версии конфигурации
SELECT * FROM Params WHERE Name IN ('DBID', 'RootCfgLastCommit', 'v8.DynamicUpdate');
Если вы уверены, что база находится в неконсистентном состоянии, удаление записи v8.DynamicUpdate поможет системе игнорировать незавершенные сеансы обновления метаданных.
Если прямое сравнение в рабочей базе всё равно не проходит, проанализируем альтернативный метод. Это самый надежный способ «вылечить» структуру метаданных, не вмешиваясь в структуру хранения данных (таблицы документов и справочников).
.cf), полученную из последнего живого бэкапа или выгруженную из текущей базы (если это возможно)..cf.Этот метод позволяет обойти ошибки кэширования и внутренних блокировок, так как сравнение идет с внешним файлом, а не с внутренними таблицами ConfigSave. Если и это не помогает, используйте режим «Загрузить конфигурацию из файла» (предварительно сделав бэкап!), что полностью перезапишет таблицу Config в SQL новыми данными из .cf.
Никогда не пытайтесь подменять таблицу Config простым копированием данных из одной базы в другую через INSERT INTO ... SELECT, если версии структуры баз различаются. Это приведет к ошибке «Конфигурация не соответствует схеме базы данных». Причина в том, что таблица DBSchema должна строго соответствовать описанию объектов в Config. Если в Config вы добавили реквизит, а в DBSchema (и физически в таблицах SQL) его еще нет — база не запустится.
Посмотрим на рекомендации по обслуживанию SQL для стабильной работы 1С:
DBCC CHECKDB для проверки физической целостности страниц.SQL Server Profiler, чтобы увидеть, на каком именно запросе к таблице Config происходит зависание во время сравнения.Таким образом, решение проблемы зависания на 0% чаще всего сводится к очистке кэша сервера приложений и обнулению таблицы ConfigSave в SQL. Это наиболее безопасные методы, которые позволяют вернуть Конфигуратор в рабочее состояние без риска потери данных пользователя.