Разберем одну из самых неприятных и критических ситуаций, с которой может столкнуться любой администратор или разработчик систем на платформе «1С:Предприятие 8» — крах базы данных в результате так называемого «демонического» (динамического) обновления.
Динамическое обновление — это удобный инструмент, позволяющий вносить изменения в конфигурацию без монопольного выгона пользователей из системы. Однако при малейшем сбое сети, зависании рабочего процесса или некорректном завершении сеанса Конфигуратора база данных может полностью заблокироваться. При попытке входа пользователи будут получать критические ошибки, а стандартные методы исправления через Конфигуратор станут недоступны. Восстановление из бэкапа — это всегда крайняя мера, так как за время с момента обновления до проявления первых симптомов пользователи могли ввести огромное количество документов и данных, которые не хочется терять.
Для того чтобы понять, как исправить возникшую проблему, проанализируем, как именно платформа 1С хранит метаданные в СУБД MS SQL Server. Платформа использует несколько служебных таблиц для управления конфигурациями:
dbo.Config — содержит основную и актуальную конфигурацию базы данных, по которой в текущий момент работают пользователи в режиме «Предприятие».dbo.ConfigSave — содержит промежуточные изменения конфигурации, которые разработчик сохранил в Конфигураторе, но еще не применил к базе данных (до нажатия кнопки «Обновить конфигурацию базы данных»).dbo.Params — хранит служебные параметры системы, настройки сеансов и флаги обновлений.Во время штатного динамического обновления новые объекты из таблицы dbo.ConfigSave переносятся в таблицу dbo.Config. Поскольку пользователи продолжают работать, система создает специальные временные записи-маркеры с именами файлов, содержащими ключевое слово dyn или dynamic. Если в этот момент происходит сбой транзакции, маркеры блокировки «застревают» в таблице dbo.Config, переводя базу в неопределенное состояние. При этом СУБД блокирует штатный запуск системы, выдавая ошибки структуры метаданных.
Рассмотрим базовый и наиболее быстрый способ восстановления работоспособности базы данных, который помог автору темы на форуме. Этот метод применим, когда структура метаданных пострадала незначительно, и нам нужно лишь удалить «зависшие» маркеры динамического обновления.
Выполним следующие шаги вместе:
.cf на жесткий диск.
DELETE FROM dbo._Config WHERE filename LIKE '%dyn%'
Примечание: в зависимости от версии платформы и структуры базы имя таблицы может начинаться с подчеркивания (например, _Config) или идти напрямую как Config. Перед выполнением запроса проверьте точное имя таблицы в списке таблиц вашей базы.
.cf. Это позволит синхронизировать кэш платформы с реальной структурой базы данных СУБД и окончательно устранить конфликт метаданных.Бывают ситуации, когда простого удаления строк с фильтром %dyn% оказывается недостаточно. Это происходит, если платформа успела частично зафиксировать транзакцию реструктуризации, и в таблицах прописались жесткие маркеры незавершенного обновления. Для полного восстановления возможности входа в Конфигуратор и сброса зависшего обновления на уровне SQL используют более широкий пакет запросов.
Выполним последовательно следующие команды очистки:
1. Очистка незавершенных транзакций обновления (удаление флагов блокировки):
DELETE FROM dbo.Config WHERE FileName = 'commit'
DELETE FROM dbo.Config WHERE FileName = 'dbStruFinal'
DELETE FROM dbo.Config WHERE FileName = 'dynamicCommit'
DELETE FROM dbo.Config WHERE FileName = 'DynamicallyUpdated'
Эти запросы принудительно убирают маркеры блокировок и флаги, сообщающие платформе о том, что база находится в процессе обновления структуры метаданных.
2. Сброс параметров сеанса в таблице Params:
DELETE FROM dbo.Params WHERE FileName = 'DynamicallyUpdated'
Этот шаг необходим для того, чтобы убрать признак динамического обновления на уровне общих параметров информационной базы.
3. Очистка таблицы редактируемой конфигурации:
TRUNCATE TABLE dbo.ConfigSave
Данная команда полностью очищает несовершенные изменения конфигурации, возвращая среду разработки к стабильной конфигурации базы данных.
После выполнения этого пакета запросов база данных гарантированно «откатится» к стабильному состоянию, которое предшествовало запуску аварийного обновления.
Что делать, если повреждения таблицы dbo.Config оказались критическими, структура таблиц нарушена, а очистка флагов не возвращает базу к жизни? В этом случае нас спасет метод подмены конфигурации из рабочей резервной копии (базы-донора).
Огромный плюс этого метода заключается в том, что мы полностью восстановим структуру метаданных, сохранив при этом абсолютно все данные документов, справочников и регистров, которые пользователи успели ввести за последние часы работы.
Разберем метод «Донора» по шагам:
DELETE FROM [Имя_Поврежденной_Базы].[dbo].[Config]
INSERT INTO [Имя_Поврежденной_Базы].[dbo].[Config]
SELECT * FROM [Имя_Базы_Донора].[dbo].[Config]
После выполнения этой подмены структура метаданных вашей рабочей базы станет идентична той, что была в бэкапе, но таблицы с фактическими данными (документы, проводки, записи регистров) останутся нетронутыми.
Даже после успешного исправления таблиц на уровне MS SQL Server администраторы часто сталкиваются с тем, что у некоторых пользователей продолжают сыпаться ошибки вида «Нарушена целостность структуры конфигурации» или «Ошибка формата потока». Это связано с тем, что локальные кэши на компьютерах пользователей и кэш на сервере приложений 1С продолжают хранить старые, поврежденные версии метаданных.
Выясним, как правильно очистить кэш на всех уровнях:
1. Очистка серверного кэша 1С:
services.msc).C:\Program Files\1cv8\srvinfo\reg_1cv8\).snccntx, v8system и другие временные файлы).2. Очистка клиентского кэша на компьютерах пользователей:
Для каждого пользователя необходимо очистить локальные папки с GUID-именами. Самый быстрый способ — удалить каталоги по следующим путям:
%userprofile%\AppData\Local\1C\1Cv8%userprofile%\AppData\Roaming\1C\1Cv8Альтернативный вариант: просто удалите базу из списка в стартере 1С и добавьте ее заново под тем же именем — это автоматически пересоздаст папку локального кэша с новым уникальным идентификатором.
Проанализируем причины, по которым опытные администраторы и разработчики 1С настоятельно рекомендуют полностью отказаться от использования динамического обновления в рабочих базах:
relation does not exist.rphost) и снижает общую скорость работы всей системы до тех пор, пока серверные процессы не будут полностью перезапущены.Рекомендуется применять динамическое обновление исключительно в тестовых средах, а на продуктивных базах устанавливать монопольный режим и планировать штатные обновления только на нерабочее время!