Ситуация, когда сервер экстренно завершает работу в процессе реструктуризации базы данных, является одной из самых критических для администратора или программиста 1С. В этот момент структура таблиц на уровне СУБД (например, MS SQL Server) находится в «подвешенном» состоянии: часть индексов может быть удалена, таблицы переименованы, а новые поля добавлены лишь частично. В результате при попытке входа в Конфигуратор система выдает ошибки: «Критическая ошибка, повторить обновление?» или «Пользователь ИБ не идентифицирован». Давайте подробно разберем, как восстановить работоспособность системы и почему возникают эти ошибки.
Рассмотрим, почему после сбоя реструктуризации платформа перестает «узнавать» пользователей. При запуске любой клиентской части (включая Конфигуратор) 1С:Предприятие обращается к служебным таблицам, чтобы проверить права доступа. Ключевыми здесь являются таблицы v8users и записи в таблице Params.
Проанализируем ситуацию: в процессе обновления конфигурации платформа часто переводит базу в монопольный режим и начинает масштабную трансформацию метаданных. Если в этот момент питание сервера отключается, транзакция реструктуризации обрывается. Платформа фиксирует флаг «обновление начато, но не закончено». При следующем входе система пытается завершить процесс, но так как связь между именами таблиц в конфигурации и физическими таблицами в SQL нарушена, она не может корректно прочитать список пользователей. Для системы база выглядит «пустой» или поврежденной на уровне метаданных, что и вызывает сообщение о неидентифицированном пользователе.
Если вы уверены, что физическая структура таблиц не успела пострадать необратимо, можно попытаться обмануть платформу, сообщив ей, что реструктуризация якобы завершена успешно. Для этого нам понадобится среда SQL Server Management Studio (SSMS).
Выясним причину: за состояние процесса обновления отвечает системная таблица SchemaStorage. В ней хранится статус последней операции над схемой базы данных. Разберем по шагам выполнение запроса:
UPDATE SchemaStorage
SET Status = 100
Значение 100 сигнализирует платформе 1С, что последняя операция изменения схемы завершена корректно. После выполнения этого запроса попробуем снова зайти в Конфигуратор. Важно: этот метод помогает далеко не всегда. Если платформа уже успела переименовать основные таблицы данных (например, таблицу проводок или остатков) во временные, то после входа вы получите «Ошибку уровня СУБД», так как 1С будет искать данные в таблицах, которых нет.
Часто информация о прерванном обновлении «залипает» в кэше сервера приложений 1С. Даже если вы поправили таблицы в SQL, менеджер кластера может продолжать выдавать ошибку, основываясь на своих старых данных. Проанализируем алгоритм очистки:
C:\Program Files\1cv8\srvinfo).snccntx и reg_1541 (будьте осторожны, лучше сначала сделать их бэкап).%AppData%\Local\1C\1cv8 и %AppData%\Roaming\1C\1cv8.Такая глубокая очистка позволяет убрать «фантомные» блокировки и заставить платформу заново пересчитать состояние базы данных из SQL-таблиц.
Рассмотрим ситуацию, описанную в теме форума: переход с Комплексной автоматизации 2.4 на 2.5. Это не просто минорное обновление, а глобальная переработка структуры регистров, учета затрат и механизмов ФСБУ. В процессе такого перехода выполняются сотни обработок и реструктурируются тысячи таблиц.
Если реструктуризация прервалась на середине, вероятность «рассинхрона» между Config (логической структурой) и DBSchema (физической структурой) составляет почти 100%. Посмотрим на последствия: даже если вы прорветесь в базу с помощью SQL-запросов, вы можете столкнуться с тем, что часть данных окажется в «старых» таблицах, а часть — в «новых». Это приведет к неверным отчетам и ошибкам при проведении документов в будущем.
Поэтому, если у вас есть резервная копия, сделанная непосредственно перед началом обновления — не раздумывая, откатывайтесь на нее.
Если ситуация безвыходная (база тестовая, бэкапа нет, а работа проделана большая), можно попробовать метод «подмены конфигурации». Разберем этот сложный процесс:
Config пустой базы в поврежденную..cf файл нужной версии).Посмотрим на этот метод критически: он крайне рискован и требует глубокого понимания структуры таблиц DBSchema и Config. Используйте его только в самом крайнем случае.
Выясним причину, почему обновление КА 2.4 на 2.5 так часто вызывает сбои. В версии 2.5 радикально изменен учет ОС и НМА в связи с требованиями ФСБУ 6/2020. Платформа во время обновления выполняет не только изменение структуры таблиц, но и пересчет итогов «на лету». Это создает огромную нагрузку на дисковую подсистему и логи транзакций SQL-сервера.
Рекомендации для предотвращения подобных ситуаций:
В завершение проанализируем итог: если штатное нажатие кнопки «Да» в окне «Повторить обновление» не помогает в течение первых нескольких минут, значит, процесс зациклился или встретил физическое препятствие. В 90% случаев при падении сервера в момент реструктуризации единственным профессиональным решением остается восстановление из бэкапа и повторный запуск обновления в более стабильных условиях.