Давайте подробно рассмотрим критическую ситуацию, с которой периодически сталкиваются администраторы и разработчики: после аварийного завершения сеанса (например, в момент пересчета итогов регистров накопления) база данных перестает пускать пользователей в режим "Предприятие". В конфигуратор доступ есть, но при попытке запуска пользовательского режима платформа выдает ошибку "Нарушение прав доступа". При этом проверка показывает, что все права и роли у пользователей настроены корректно.
Проанализируем стандартные действия, которые обычно предпринимают в таких случаях, но которые не приносят результата:
.dt (завершается пустой критической ошибкой)..cf) — приводит к критической ошибке в процессе обновления ИБ.v8users средствами СУБД (приводит лишь к зависанию базы).Если резервная копия была сделана только утром, а за день введено множество документов, потеря данных критична. Разберем по шагам, как можно спасти базу в такой ситуации.
Выясним истинную причину ложного сообщения о нарушении прав доступа. В 1С существует служебная таблица SchemaStorage, которая располагается в СУБД (в нашем случае MS SQL). Эта таблица используется платформой для хранения внутренних метаданных, структуры базы данных и кэшированной информации, включая данные о подключенных расширениях конфигурации.
Если во время структурных изменений (таких как реструктуризация или массовый пересчет итогов) происходит аварийное завершение работы, данные в этой таблице могут повредиться. Платформа 1С из-за поврежденного системного кэша метаданных не может корректно прочитать и сопоставить права пользователей на объекты базы. В целях безопасности система блокирует доступ всем без исключения (даже администраторам с полными правами). Именно поэтому манипуляции с правами, ролями и таблицей v8users абсолютно бесполезны.
Посмотрим на наиболее безопасный и быстрый метод реанимации базы, который не требует копирования таблиц из других баз. Нам нужно "объяснить" платформе, что кэш структуры поврежден и его необходимо перестроить.
Для этого мы воспользуемся средой SQL Server Management Studio (SSMS). Выполните следующий запрос к вашей поврежденной базе данных:
USE [ИмяВашейБазыДанных];
GO
UPDATE dbo.SchemaStorage SET Status = 100;
GO
Изменение статуса на 100 сигнализирует серверу 1С о необходимости заново инициализировать и перечитать данные структуры при следующем запуске. Во многих случаях этого простого действия достаточно, чтобы платформа сама восстановила работоспособность при следующем входе в Конфигуратор или Предприятие.
Если первый метод не помог, рассмотрим более радикальный способ, который сработал в исходной ситуации. Он заключается в полной замене поврежденной таблицы структурой из рабочей копии.
[dbo].[SchemaStorage] из сломанной базы.[dbo].[SchemaStorage] из развернутой утренней копии в вашу сломанную рабочую базу.dbo.Config, files или params, если повреждения затронули и их.Проанализируем еще один интересный обходной путь. Современные релизы платформы 1С очень строго относятся к целостности системных таблиц. Если при повреждении базы процесс выгрузки в .dt или Тестирование и исправление (ТИИ) падают с критической ошибкой, иногда помогает использование более старых версий платформы (например, из ветки 8.3.17).
Старые релизы платформы в некоторых сценариях менее чувствительны к поврежденным системным таблицам. Попробуйте запустить Конфигуратор на старой версии и выполнить полное ТИИ. Если процесс завершится успешно, база "починится", после чего её можно будет снова запускать на вашей актуальной версии платформы.
В завершение разберем критически важный вопрос администрирования. В описанной ситуации базу можно было бы спасти без "танцев с бубном", если бы в MS SQL была правильно настроена модель восстановления.
Если для базы данных установлена модель Simple (Простая), журнал транзакций автоматически усекается. Вы можете восстановиться только на момент создания последнего полного бэкапа (в данном случае — на утро). Вся работа пользователей за день теряется.
Для продуктивных баз данных 1С (особенно таких масштабных как ERP или Комплексная автоматизация) настоятельно рекомендуется использовать модель восстановления Full (Полная) и настроить регулярное резервное копирование журнала транзакций (например, каждые 15-30 минут). В случае подобной аварии администратор базы данных сможет выполнить восстановление базы (Restore) с применением логов на конкретный момент времени (Point-in-time recovery) — ровно за одну минуту до злополучного сбоя. Потеря данных в таком случае составит лишь несколько минут работы.