Как исправить ошибку файловой операции в ConfigSave при входе в конфигуратор 1С после перезагрузки сервера?

← На главную

После внезапной перезагрузки сервера СУБД или аварийного завершения работы конфигуратора специалисты могут столкнуться с ситуацией, когда база данных открывается в режиме предприятия без видимых проблем, однако вход в конфигуратор блокируется критической ошибкой вида: Ошибка при выполнении файловой операции 'v8srvr://.../basename/ConfigSave/deleted'. Обычная очистка локального кэша и серверных сеансовых данных в каталоге srvinfo в таком случае не дает положительного результата.

Разберем детально, почему возникает данная проблема и какими способами можно восстановить нормальную работу конфигуратора и целостность информационной базы.

Причины возникновения ошибки

Выясним причину сбоя. В клиент-серверном варианте платформа 1С:Предприятие хранит метаданные конфигурации непосредственно в таблицах СУБД (MS SQL Server, PostgreSQL и др.) в виде виртуальной файловой структуры. Основными таблицами являются:

Config — содержит актуальную конфигурацию базы данных, с которой работают пользователи в режиме предприятия.
ConfigSave — хранит временно сохраняемую основную конфигурацию, которая находится в процессе редактирования разработчиком до нажатия клавиши F7 («Обновить конфигурацию базы данных»).
CONFIGCAS и CONFIGCASF — служебные таблицы кэша версионирования метаданных платформы 8.3.
Params — параметры конфигурации и служебные флаги обновлений.

Если в момент внезапной перезагрузки сервера конфигуратор был открыт или выполнялась процедура сохранения, транзакция прерывается некорректно. В таблицах метаданных остаются «висячие» маркеры незавершенных операций и битые ссылки на несуществующие виртуальные файлы (например, путь к временным файлам удаления .../ConfigSave/deleted). В результате при попытке открыть конфигуратор платформа не может сопоставить структуру из ConfigSave с основной конфигурацией.

Способ 1. Синхронизация таблиц метаданных на уровне СУБД

Рассмотрим вариант прямого восстановления целостности таблиц конфигурации с помощью SQL-запросов. Перед выполнением любых прямых операций в СУБД обязательно создадим полную резервную копию базы данных.

Если таблица ConfigSave повреждена или пуста, синхронизируем ее с рабочей таблицей Config и очистим служебный кэш метаданных платформы:


DELETE FROM ConfigSave;
INSERT INTO ConfigSave SELECT * FROM Config;

TRUNCATE TABLE CONFIGCAS;
TRUNCATE TABLE CONFIGCASF;

Также проверим и удалим зависшие маркеры динамического обновления и незавершенных реструктуризаций из таблицы Config:


DELETE FROM Config WHERE FileName IN ('commit', 'dbStruFinal', 'dynamicCommit', 'DynamicallyUpdated');

После выполнения запросов перезапускаем службу сервера 1С:Предприятия и проверяем вход в конфигуратор.

Способ 2. Восстановление конфигурации из эталонной копии через SQL

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

Разворачиваем резервную копию на том же SQL-сервере под временным именем.
Очищаем таблицы конфигурации в поврежденной рабочей базе и копируем данные из резервной базы запросом:


DELETE FROM TargetBase.dbo.Config;
DELETE FROM TargetBase.dbo.ConfigSave;
DELETE FROM TargetBase.dbo.DBSchema;

INSERT INTO TargetBase.dbo.Config SELECT * FROM SourceBase.dbo.Config;
INSERT INTO TargetBase.dbo.ConfigSave SELECT * FROM SourceBase.dbo.Config;
INSERT INTO TargetBase.dbo.DBSchema SELECT * FROM SourceBase.dbo.DBSchema;

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

Способ 3. Пакетная выгрузка и откат конфигурации через командную строку

Если графический интерфейс падает, попробуем использовать служебные параметры пакетного запуска платформы без интерактивного входа.

Посмотрим на пример принудительного отката редактируемой конфигурации к конфигурации базы данных:

1cv8.exe DESIGNER /IBConnectionString "Srvr=Server1C;Ref=BaseName;" /RollbackCfg

Если откат не помог, выполним пакетную выгрузку конфигурации базы данных в файл и ее повторную загрузку:


1cv8.exe DESIGNER /IBConnectionString "Srvr=Server1C;Ref=BaseName;" /DumpCfg "C:\Backup\current.cf"
1cv8.exe DESIGNER /IBConnectionString "Srvr=Server1C;Ref=BaseName;" /LoadCfg "C:\Backup\current.cf"

Способ 4. Выгрузка в архивный файл данных (.dt) и повторная загрузка

Разберем по шагам практический способ, который часто помогает обойти поврежденные участки кэша метаданных:

Используем специализированные утилиты пакетной работы или командную строку для формирования файла выгрузки .dt из поврежденной базы.
Даже если попытка автоматической загрузки обратно завершается ошибкой структуры или индексов, сам процесс экспорта данных и очистки временных сеансов может сбросить зависшие состояния метаданных на сервере 1С.
Пробуем зайти в конфигуратор в обычном режиме — доступ восстанавливается.
Выполняем штатную загрузку полученного файла .dt непосредственно через меню конфигуратора (пункт Администрирование -> Загрузить информационную базу...).

Устранение последствий: поиск и исправление неуникальных индексов

Обратим внимание на важный нюанс: если в процессе восстановления или загрузки базы платформа выдает сообщение о невозможности создания уникального индекса в каком-либо регистре, в таблицах базы данных присутствуют дублирующиеся записи.

Запуск полного «Тестирования и исправления» на базах объемом более 100 Гб может длиться часами и завершиться аварийно на этапе создания уникального индекса. Поэтому локализуем и устраним дубли точечно прямым SQL-запросом.

Найдем дубликаты записей в подозрительном регистре сведений по комбинации периода и основных измерений:


SELECT _Period, _Fld1234RRef, _Fld1235RRef, COUNT(*)
FROM _InfoRg1230
GROUP BY _Period, _Fld1234RRef, _Fld1235RRef
HAVING COUNT(*) > 1;

После удаления дубликатов на уровне СУБД запускаем стандартную процедуру Тестирование и исправление информационной базы из меню конфигуратора с установленными флагами Реиндексация таблиц информационной базы и Проверка логической и физической целостности.