В процессе эксплуатации и разработки на платформе 1С:Предприятие 8.3 системные администраторы и разработчики могут столкнуться с ситуацией, когда штатное обновление конфигурации базы данных прерывается ошибкой. Наиболее неприятным последствием становится состояние «зависшей» реструктуризации, когда при попытке зайти в конфигуратор система выдает сообщение: «Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?». Если стандартные средства не помогают, а обычное обновление (F7) приводит к повторению ошибки, в то время как «Обновление на сервере» проходит успешно, значит, в системных таблицах базы данных нарушена логическая целостность. Рассмотрим подробно, как вернуть базу в нормальное состояние.
Проанализируем ситуацию: почему возникает такое разделение? Обычное обновление конфигурации выполняется в рамках одной транзакции и требует монопольного доступа к таблицам для их физической перестройки. Если в таблице Config или ConfigSave остались записи от предыдущей неудачной попытки, механизм блокирует операцию. Фоновое обновление (на сервере) работает иначе: оно создает временные таблицы для новой структуры, постепенно переносит туда данные и лишь в финальной фазе подменяет старые таблицы новыми. Если «обычное» обновление не работает, значит, система «видит» незавершенную транзакцию в метаданных, которую фоновый механизм игнорирует или обходит за счет своей специфики.
Разберем, какие записи в таблице Config отвечают за состояние процесса обновления. Когда мы запускаем обновление, 1С создает временные маркеры. В случае сбоя они не удаляются автоматически. Для исправления ситуации нам необходимо выполнить SQL-запросы в консоли управления SQL Server (SSMS).
В первую очередь проверим наличие записей commit и dbStruFinal, которые блокируют запуск. Рассмотрим запрос для удаления этих записей:
DELETE FROM config WHERE FileName = 'commit';
DELETE FROM config WHERE FileName = 'dbStruFinal';
Однако, как показывает практика, этого может быть недостаточно. Важно проверить еще один маркер — dbStruInitial. Эта запись фиксирует состояние схемы до начала реструктуризации. Если она остается в таблице, система считает, что процесс находится в промежуточной фазе. Выполним удаление:
DELETE FROM config WHERE FileName = 'dbStruInitial';
Выясним роль таблицы ConfigSave. В нормальном состоянии, когда в конфигураторе нет несохраненных изменений (синий значок конфигурации неактивен), эта таблица должна быть абсолютно пустой. Если в ней содержатся данные, система будет пытаться сопоставить их с основной конфигурацией при каждом обновлении.
Проанализируем состояние таблицы. Если мы уверены, что все важные изменения уже перенесены или у нас есть актуальный файл .cf, таблицу следует полностью очистить. Используем команду:
TRUNCATE TABLE ConfigSave;
Важно: Перед выполнением этой команды убедитесь, что у вас есть резервная копия конфигурации, так как TRUNCATE удалит все несохраненные в основную конфигурацию правки.
Если предыдущие шаги не помогли и обновление по-прежнему доступно только через сервер, проблема может крыться в несоответствии бинарного описания структуры в записи DBSchema. Эта запись содержит информацию о том, как объекты метаданных 1С связаны с физическими таблицами SQL.
Посмотрим на радикальный способ решения: удаление записи DBSchema. После этого при открытии конфигуратора система будет вынуждена заново проанализировать все таблицы базы данных и сопоставить их с метаданными. Это длительный процесс, особенно для баз объемом более 400 Гб.
DELETE FROM config WHERE FileName = 'DBSchema';
После удаления этой записи необходимо запустить конфигуратор и выполнить команду «Конфигурация — Обновить конфигурацию базы данных». Система предложит создать структуру заново — это штатное поведение в данном случае.
Иногда информация о «зависшей» реструктуризации кэшируется на стороне сервера 1С:Предприятие. Рассмотрим последовательность действий для полной очистки серверного окружения:
1C:Enterprise 8.3 Server Agent).C:\Program Files\1cv8\srvinfo).snccntx (данные сеансов) и config (кэш конфигурации).Эти действия помогут исключить ситуацию, когда конфигуратор обращается к устаревшим данным, хранящимся в оперативной памяти сервера.
Разберем еще один инструмент, который часто помогает «протолкнуть» зависшее обновление. Запуск конфигуратора в режиме дизайнера с использованием специальных ключей позволяет игнорировать некоторые ошибки графического интерфейса. Попробуем выполнить обновление через командную строку Windows:
"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /S"ServerName\BaseName" /N"Admin" /P"Pass" /UpdateDBCfg -Force
Параметр /UpdateDBCfg -Force инициирует принудительное завершение всех транзакций реструктуризации и попытку фиксации изменений в базе данных.
В ситуациях с базами большого объема (как в нашем примере — 430 Гб), когда выгрузка .dt практически невозможна из-за временных затрат, эффективным методом «лечения» таблицы Config является полная перезапись конфигурации. Посмотрим, как это сделать:
Конфигурация -> Сохранить конфигурацию в файл...).Конфигурация -> Загрузить конфигурацию из файла... и укажем только что созданный .cf.Config в SQL, удаляя все лишние записи и исправляя возможные ошибки в структуре хранения.Проанализировав причины сбоя, мы можем сделать вывод, что основной «враг» стабильности в данном случае — динамическое обновление. Постоянное использование функции «Обновить конфигурацию базы данных» при работающих пользователях («демоническое обновление») накапливает мусорные записи в системных таблицах и часто приводит к невозможности последующей реструктуризации.
Рекомендация: Всегда старайтесь выполнять обновление монопольно, особенно если изменения касаются структуры таблиц (добавление реквизитов, изменение типов данных). Если же ситуация с ошибкой повторилась, начинайте с очистки записей commit и dbStruFinal в SQL, так как это самый безопасный и быстрый метод восстановления работоспособности.