Ситуация, когда после многочасовой разработки и внезапного отключения электроэнергии часть объектов метаданных (справочники, документы, общие модули) исчезает из дерева конфигурации, способна вызвать панику у любого разработчика. Особенно странно выглядит картина, когда часть кода в формах сохраняется, но ссылки в этом коде ведут на «несуществующие» объекты. Проанализируем технические причины такого сбоя в связке 1С:Предприятие 8.3 и MS SQL Server 2014, а также разберем по шагам методы восстановления данных.
Первым делом рассмотрим самую распространенную причину — повреждение или рассинхронизацию локального кэша. В системе 1С существует несколько уровней кэширования, и при аварийном завершении работы данные в них могут начать противоречить друг другу. Если вы переустановили сервер 1С и прописали базу заново, серверный кэш обновился, но локальный кэш пользователя на рабочей станции мог остаться в «прошлом» или поврежденном состоянии.
Выясним причину странного поведения, когда формы видят новые объекты, а дерево метаданных — нет. Это происходит из-за того, что список объектов основной конфигурации и содержимое конкретных форм могут считываться из разных кэшированных файлов. Разберем шаги по полной очистке:
%AppData%\1C\1cv8 и %LocalAppData%\1C\1cv8. Именно здесь хранятся пользовательские настройки и закэшированные описания метаданных.ragent. Рекомендуется вручную удалить содержимое папки с GUID конкретной базы внутри каталога reg_1541 в srvinfo.Если очистка кэша не помогла, проанализируем ситуацию на уровне СУБД. Конфигурация в 1С хранится в специальных системных таблицах SQL. Посмотрим на их назначение:
F7).Ctrl+S).При сбое питания может возникнуть рассинхронизация. Платформа при открытии конфигуратора пытается «собрать» дерево метаданных. Если записи в ConfigSave повреждены или индексы этих таблиц «слетели» из-за некорректного закрытия транзакции SQL, 1С может откатиться к последней стабильной версии, игнорируя последние изменения. В этом случае объекты физически могут присутствовать в базе (например, в таблице DBSCHEMA или в виде созданных таблиц _DocumentXX), но логическая связь в конфигураторе будет разорвана.
Выясним, почему SQL Server мог «потерять» данные, которые 1С уже считала записанными. В версии MS SQL Server 2014 появилась функция отложенной фиксации транзакций (Delayed Durability). Если этот параметр включен, сервер подтверждает успешное завершение транзакции еще до того, как лог транзакций физически сброшен на диск.
Рассмотрим риски: при внезапном отключении электричества транзакции, находящиеся в оперативной памяти (в буфере лога), безвозвратно теряются. Для 1С это критично, так как платформа уверена, что объект метаданных создан, а СУБД фактически его не сохранила. Чтобы проверить или изменить этот режим, можно использовать следующий запрос:
SELECT name, delayed_durability_desc
FROM sys.databases
WHERE name = 'Имя_Вашей_Базы';
-- Если значение DISABLED, данные записываются сразу.
-- Если ALLOWED или FORCED, возможны потери при сбое питания.
Если вы обнаружили, что режим включен, рекомендуем перевести его в DISABLED для баз разработки, где нет бесперебойного питания (ИБП).
Если объекты пропали, но вы уверены, что они были записаны, проанализируем состояние базы с помощью встроенных инструментов. Рассмотрим последовательность действий:
.dt, загрузить её в файловый вариант и прогнать через chdbfl. Она жестче проверяет заголовки внутренних объектов.Проанализируем еще один фактор — динамическое обновление («демоническое»). Если в процессе разработки часто использовалось обновление конфигурации БД без выгона пользователей, риск повреждения таблицы Config возрастает многократно. При сбое питания платформа может «запутаться» в версиях объектов, хранящихся в базе. В такой ситуации наиболее эффективным методом восстановления является полная выгрузка базы в формат .dt и загрузка в абсолютно новую, пустую базу SQL. Это принудительно пересоберет таблицы метаданных и очистит их от мусорных записей и старых версий объектов.
Важный совет: для предотвращения подобных ситуаций в будущем обязательно используйте источники бесперебойного питания (ИБП) не только для сервера СУБД, но и для дисковых массивов, а также старайтесь избегать длительных сессий разработки без промежуточного сохранения конфигурации в файл .cf.