В практике администрирования 1С:Предприятие одна из самых неприятных ситуаций — это сбой после динамического обновления конфигурации. Часто это приводит к появлению ошибки SDBL (например, "SDBL: Ожидается имя таблицы") или "Ошибка формата потока", при этом доступ блокируется как в режим "1С:Предприятие", так и в "Конфигуратор". Рассмотрим подробно, почему это происходит, и разберем по шагам, как восстановить работоспособность базы данных, используя средства SQL Server и инструменты платформы.
Прежде чем мы приступим к "лечению", давайте разберем анатомию проблемы. Когда мы запускаем динамическое обновление, платформа не перезаписывает основную конфигурацию сразу. Вместо этого она создает временные записи изменений.
На уровне базы данных (SQL) это выглядит следующим образом:
Config — это наша основная, рабочая конфигурация.ConfigSave — это таблица, куда записывается новая версия конфигурации в процессе обновления базы данных (когда мы нажимаем F7).При штатном обновлении данные из ConfigSave должны заменить данные в Config. Однако при динамическом обновлении, если происходит сбой сети, отключение электричества или ошибка процесса rphost, транзакция может "зависнуть". В результате платформа видит несоответствие между версиями конфигурации в этих таблицах и кэшем, что и вызывает ошибки уровня SDBL (Simple Data Base Layer).
Проанализируем ситуацию, когда база находится на MS SQL Server (наиболее частый случай для таких ошибок), и разберем решение для файлового варианта.
Критически важно: перед любыми манипуляциями с таблицами SQL напрямую, мы обязаны сделать резервную копию. Даже если база не запускается, мы можем сделать бэкап средствами СУБД (SQL Server Management Studio).
Выполним следующие действия:
Только после того, как у нас есть "страховка", переходим к активным действиям. В будущем для предотвращения проблем стоит настроить автоматическую архивацию баз данных.
Основным методом лечения "битого" динамического обновления является очистка таблицы, содержащей незавершенные изменения конфигурации. Рассмотрим этот процесс детально.
Нам необходимо проверить содержимое таблицы ConfigSave. В нормальном состоянии работающей базы эта таблица должна быть пустой. Для глубокого анализа структуры БД можно использовать обработку для анализа размера таблиц SQL.
Откроем окно запроса (New Query) к нашей базе данных и выполним проверку:
SELECT *
FROM ConfigSave
Если запрос возвращает строки, значит, в таблице остались "ошметки" неудачного обновления. Именно они мешают запуску. Наша задача — очистить эту таблицу. Это безопасно, так как мы удаляем только непримененные изменения конфигурации. Сама конфигурация базы данных (таблица Config) останется нетронутой.
Выполним команду очистки:
DELETE FROM ConfigSave
В большинстве случаев (около 90% ситуаций) этого действия достаточно. После выполнения запроса попробуйте зайти в Конфигуратор. Если вход успешен, проблема решена. Платформа увидит, что обновлений нет, и загрузит текущую рабочую конфигурацию.
Иногда проблема залегает глубже. Если очистка ConfigSave не помогла, нам потребуется проанализировать SQL сервер глазами 1С-ника и проверить параметры системы в таблице Config.
Существует методика, при которой мы принудительно сбрасываем флаг наличия изменений. В более старых версиях платформы или в специфических ситуациях может потребоваться удаление записи о коммите.
Посмотрим на таблицу Params или Config в поисках записи с именем файла commit. Эта запись сигнализирует системе, что происходит процесс фиксации.
SELECT *
FROM Config
WHERE FileName = 'commit'
Если такая запись существует, удалим её:
DELETE FROM Config
WHERE FileName = 'commit'
Внимание! Будьте предельно осторожны с таблицей Config. Удаление лишних записей оттуда (например, метаданных объектов) может разрушить конфигурацию безвозвратно. Удаляем только служебные записи статусов, если мы точно уверены в диагнозе.
Даже если мы исправили ситуацию в базе данных (SQL), на сервере приложений 1С могли остаться кэшированные данные старой или "битой" конфигурации. Ошибка SDBL часто указывает на рассинхронизацию между тем, что ожидает сервер 1С, и тем, что реально лежит в таблицах SQL.
Разберем процедуру полной очистки серверного кэша:
services.msc).C:\Program Files\1cv8\srvinfo.reg_1541 (порт может отличаться, если вы меняли настройки).snccntx....snccntx (сеансовые данные).1CV8Clst.lst — в нем хранятся настройки вашего кластера и список баз.После очистки запустим службу 1С снова. Теперь сервер будет вынужден заново считать конфигурацию из базы данных SQL, которую мы "починили" на предыдущем этапе.
Если вы столкнулись с такой же проблемой, но база не на SQL Server, а в файловом варианте (файл 1Cv8.1CD), нам понадобятся другие инструменты. Стандартная утилита chdbfl.exe (проверка физической целостности) часто не помогает при логических ошибках динамического обновления, но запустить её стоит первым делом.
Если chdbfl.exe не нашла ошибок или исправление не помогло, воспользуемся специализированными инструментами для чтения формата 1CD (например, Tool_1CD, который широко известен в сообществе).
Порядок действий:
1Cv8.1CD.CONFIGSAVE.Однако для файловых баз самым надежным и быстрым способом часто остается восстановление из ежедневного бэкапа, так как структура файла 1CD более хрупкая, чем SQL база.
Не забудем и про клиентскую сторону. После всех манипуляций на сервере, у пользователей (и у вас, как администратора) в локальном кэше (AppData) могут остаться старые версии метаданных.
Выполним очистку кэша пользователя. Самый простой способ — удалить базу из списка запуска 1С и добавить её снова. Это создаст новую папку с уникальным ID и гарантирует чистый кэш.
Более продвинутый способ — удалить папки вручную по путям:
%userprofile%\AppData\Local\1C\1cv8\%userprofile%\AppData\Roaming\1C\1cv8\Удаляем папки с длинными непонятными именами (GUID). Файлы 1CEStart.cfg и ibases.v8i трогать не нужно, чтобы не потерять список баз.
Проанализировав причины возникновения ошибки, мы можем сформулировать главное правило эксплуатации высоконагруженных систем 1С:
Избегайте динамического обновления на продуктивных базах данных!
Почему это важно:
ConfigSave или Params без полноценной реструктуризации увеличивает риск краха.Config и очистит временные данные.Мы разобрали критическую ситуацию с ошибкой SDBL после динамического обновления. Резюмируем алгоритм спасения:
DELETE FROM ConfigSave.commit в таблице Config.Следуя этим инструкциям, вы сможете вернуть базу к жизни за 15–20 минут, минимизировав простой работы компании.