← На главную

Каждый администратор и разработчик 1С рано или поздно сталкивается с последствиями так называемого «демонического» (динамического) обновления конфигурации. Динамическое обновление — это крайне удобный инструмент, позволяющий вносить изменения в код модулей без необходимости выгонять пользователей из базы данных. Однако у этого механизма есть обратная, очень опасная сторона. При возникновении малейшего сбоя сети, отключения питания или зависания сеанса в момент применения изменений база данных может полностью заблокироваться. При этом пользователи и разработчик получают критическую ошибку: «При обновлении данных, после последней реструктуризации, произошла ошибка» или сопутствующее ей системное сообщение «Обнаружена незавершенная операция сохранения конфигурации». В этой ситуации войти в базу невозможно ни в режиме «Предприятие», ни в режиме «Конфигуратор».

В данной статье мы подробно разберем, почему возникает этот сбой, детально проанализируем структуру хранения конфигурации в СУБД и изучим пошаговые алгоритмы реанимации базы данных для различных СУБД (MS SQL Server, PostgreSQL), а также для файлового варианта работы.

Почему происходит этот сбой и как устроена база данных 1С

Чтобы понять природу ошибки, рассмотрим внутреннее устройство хранения метаданных в 1С. Платформа использует специализированные системные таблицы для управления конфигурацией. Основными из них являются:

1. Config — таблица, в которой хранится текущая рабочая конфигурация базы данных. Именно с ней работают пользователи в режиме «1С:Предприятие».
2. ConfigSave — таблица, в которую записываются промежуточные изменения, сделанные разработчиком в Конфигураторе до нажатия клавиши F7 (Обновить конфигурацию базы данных).

Когда мы запускаем процесс обновления конфигурации базы данных, платформа инициирует транзакцию, в рамках которой данные из таблицы ConfigSave переносятся и перезаписывают записи в таблице Config. Для того чтобы контролировать целостность этого процесса, 1С использует систему маркеров (флагов). В поле FileName таблицы Config временно записываются служебные маркеры:

• commit — сообщает системе о начале записи изменений и открытии транзакции.
• dynamicCommit — указывает на то, что выполняется именно динамическое обновление.
• dbStruFinal — отвечает за завершающую стадию реструктуризации таблиц данных.

В штатном режиме после успешного завершения транзакции эти маркеры автоматически удаляются платформой. Но если в процессе записи произошел сбой (например, отключился сетевой сокет, аварийно завершился процесс rphost или SQL-сервер ушел в перезагрузку), транзакция прерывается, а маркеры «зависают» в таблице Config. При последующей попытке запуска платформы 1С считывает эти флаги, понимает, что предыдущая операция записи была прервана, и аварийно завершает работу, предотвращая дальнейшее разрушение данных.

Способ 1. Восстановление клиент-серверной базы на MS SQL Server

Если ваша база данных развернута на сервере MS SQL Server, исправление ситуации займет не более нескольких минут. Нам потребуется среда администрирования SQL Server Management Studio (SSMS).

Выполним следующие шаги для восстановления работоспособности базы данных:

1. Создадим резервную копию базы данных СУБД. Это обязательное правило перед любым прямым вмешательством в таблицы базы данных. В SSMS нажмите правой кнопкой мыши по вашей базе данных, выберите «Задачи» (Tasks) -> «Создать резервную копию» (Back Up) и завершите процесс создания бэкапа.
2. Откройте редактор запросов, нажав кнопку «Создать запрос» (New Query) на панели инструментов, предварительно выбрав вашу поврежденную базу данных в проводнике объектов.
3. Проанализируем состояние системной таблицы. Выполним проверочный запрос, чтобы убедиться в наличии проблемных маркеров:
   Скопировать код

   
   SELECT * FROM Config WHERE FileName IN ('commit', 'dynamicCommit', 'dbStruFinal');
   

   Если запрос вернул одну или несколько строк, значит, наши догадки подтвердились, и в таблице действительно остались маркеры незавершенной транзакции.
4. Для исправления ситуации удалим эти записи напрямую из таблицы Config. Выполним следующий SQL-запрос:
   Скопировать код

   
   DELETE FROM Config WHERE FileName = 'commit';
   DELETE FROM Config WHERE FileName = 'dynamicCommit';
   DELETE FROM Config WHERE FileName = 'dbStruFinal';
   

5. Также рекомендуется полностью очистить таблицу временного сохранения конфигурации ConfigSave, чтобы исключить попытки повторного наката битых изменений. Выполним команду: DELETE FROM ConfigSave;
6. После выполнения запросов обязательно очистим локальный кэш конфигурации на сервере 1С (каталог srvinfo) и на локальном компьютере пользователя. Это исключит ситуацию, когда платформа пытается запустить базу, используя старые закэшированные файлы метаданных.

После проведения этих манипуляций попробуем запустить Конфигуратор. В 95% случаев база успешно откроется. Сразу после входа в Конфигуратор обязательно запустите процедуру «Тестирование и исправление» (меню «Администрирование» -> «Тестирование и исправление») с установленными флагами проверки логической и ссылочной целостности.

Способ 2. Замена поврежденной конфигурации из резервной копии (для SQL)

Иногда простое удаление флагов-маркеров не помогает. Это происходит в тех случаях, когда сбой случился на этапе глубокой реструктуризации таблиц, и сама структура метаданных в таблице Config записалась лишь частично, оказавшись поврежденной. При попытке зайти в базу платформа будет выдавать ошибки формата потока или другие системные исключения.

Если у вас есть архивная копия (пусть даже недельной давности), но вам крайне важно сохранить все документы и проводки, которые пользователи ввели за текущий день (как упоминалось в сообщении 6 на форуме), мы можем пойти путем перезаписи конфигурации. При этом физические данные таблиц документов и справочников не пострадают.

Разберем этот продвинутый метод восстановления по шагам:

1. Развернем на нашем SQL-сервере рабочую резервную копию базы данных (которая была сделана до сбоя) под другим именем, например, base_backup.
2. Откроем среду SSMS и создадим новый запрос.
3. Полностью очистим поврежденную таблицу Config в нашей сломанной рабочей базе данных (пусть она называется base_broken):
   Скопировать код

   
   USE [base_broken];
   DELETE FROM [dbo].[Config];
   

4. Перенесем рабочую структуру метаданных из развернутой архивной копии в сломанную базу. Для этого выполним запрос:
   Скопировать код

   
   INSERT INTO [base_broken].[dbo].[Config] 
   SELECT * FROM [base_backup].[dbo].[Config];
   

5. Дополнительно полностью очистим таблицу временных сохранений в сломанной базе: DELETE FROM [base_broken].[dbo].[ConfigSave];
6. Запустим Конфигуратор поврежденной базы base_broken. База должна успешно открыться, так как теперь в ней находится полностью корректная структура метаданных из архивной копии. При этом все документы, введенные за сегодняшний день, останутся на месте, так как таблицы данных (такие как _Document, _Reference и т.д.) мы не затрагивали.
7. Выполним команду «Обновить конфигурацию базы данных» (F7) для синхронизации структуры СУБД и запустим «Тестирование и исправление».

Способ 3. Восстановление клиент-серверной базы на PostgreSQL

Если ваша база данных работает под управлением СУБД PostgreSQL, методология исправления остается абсолютно аналогичной, меняется лишь инструмент администрирования и слегка корректируется синтаксис (хотя стандартные запросы полностью идентичны).

Для работы с PostgreSQL рассмотрим использование утилиты pgAdmin:

1. Запустим pgAdmin и подключимся к нашему серверу баз данных.
2. Найдем в дереве объектов нашу поврежденную базу, раскроем ветку «Schemas» -> «public» -> «Tables».
3. Найдем таблицы config и configsave (обратите внимание, что в PostgreSQL имена таблиц и полей чаще всего хранятся в нижнем регистре).
4. Нажмем на базу правой кнопкой мыши и выберем инструмент «Query Tool».
5. Выполним SQL-запрос для очистки зависших маркеров транзакции:
   Скопировать код

   
   DELETE FROM config WHERE filename IN ('commit', 'dynamicCommit', 'dbStruFinal');
   DELETE FROM configsave;
   

6. Запустим Конфигуратор 1С и проверим работоспособность системы.

Способ 4. Восстановление файловой базы данных (формат .1CD)

Сложнее обстоит дело, если база данных файловая. В файловом варианте у нас нет возможности открыть консоль SQL-запросов и выполнить инструкции DELETE. Однако решение существует и здесь. Для этого нам понадобятся специализированная утилита для работы с файлами баз данных 1С — Tool_1CD (инструмент сторонних разработчиков для низкоуровневого редактирования таблиц файлов .1CD), а также штатная утилита конвертации базы из комплекта платформы.

Посмотрим на алгоритм спасения файловой базы по шагам:

1. Сделаем копию файла базы данных. Скопируем файл 1Cv8.1CD в отдельную папку. Это критически важно, так как при низкоуровневом редактировании файлов высок риск окончательно повредить базу.
2. Современные версии платформы 1С 8.3 используют новый формат файловой базы данных (версии 8.3.8 и выше), который утилита Tool_1CD может не открыть напрямую на запись или чтение. Чтобы обойти это ограничение, нам нужно временно понизить версию формата базы данных до совместимой версии 8.2.14.
3. Для этого воспользуемся штатной утилитой конвертации cnvdbfl.exe. Откроем командную строку Windows (cmd) и перейдем в каталог bin установленной платформы 1С: cd "C:\Program Files\1cv8\8.3.22.1709\bin" (замените версию платформы в пути на вашу актуальную).
4. Выполним команду конвертации файла нашей поврежденной базы в формат старой версии: cnvdbfl.exe -c -f 8.2.14 "C:\MyBases\BrokenBase\1Cv8.1CD"
5. После успешного завершения конвертации откроем программу **Tool_1CD** и выберем наш файл базы данных.
6. В левой панели программы найдем таблицу CONFIG. Перейдем на вкладку просмотра данных этой таблицы.
7. Отсортируем таблицу по колонке FileName и найдем строки со значениями commit, dynamicCommit и dbStruFinal. Удалим эти строки с помощью инструментов редактирования утилиты.
8. Перейдем к таблице CONFIGSAVE и полностью очистим все строки в ней.
9. Сохраним изменения в Tool_1CD и закроем программу.
10. Теперь нам нужно вернуть базу обратно в современный формат. Для этого откроем Конфигуратор 1С версии 8.3 и укажем путь к нашей отредактированной базе. Платформа обнаружит старый формат файла 8.2.14 и автоматически предложит выполнить конвертацию обратно в актуальный формат 8.3. Соглашаемся с предложением.

После прохождения всех этапов база будет успешно запущена, а незавершенная транзакция динамического обновления будет полностью устранена без потери накопленных за день данных.

Рекомендации по предотвращению подобных сбоев в будущем

Чтобы минимизировать риски возникновения подобных аварийных ситуаций, рекомендуем придерживаться нескольких простых правил при администрировании систем на базе 1С:

• Избегайте динамического обновления при серьезных изменениях. Если вы вносите изменения в структуру метаданных (добавляете реквизиты, меняете типы данных, создаете новые объекты), динамическое обновление использовать категорически запрещено. Динамически можно обновлять только простые изменения в коде модулей (и то с осторожностью).
• Всегда делайте архивные копии. Настройте автоматическое резервное копирование баз данных (например, ежечасное создание бэкапов транзакций в MS SQL или ежедневное создание полных копий). Регулярное выполнение этих процедур и последующее тестирование нескольких баз 1С обеспечивает инструмент автоматического архивирования, обновления и тестирования 1С в тихом режиме.
• Очищайте кэш серверов и пользователей. Регулярная очистка кэша помогает избежать ложных срабатываний и конфликтов версий метаданных.
• Используйте качественное сетевое оборудование и источники бесперебойного питания (ИБП). Большинство сбоев при обновлении происходит из-за кратковременной потери связи между сервером приложений 1С и сервером СУБД. Стабильная гигабитная сеть и ИБП на серверах уберегут вас от множества проблем.