Справочник системных ошибок и решений

Windows Server, Active Directory, 1С:Предприятие, СУБД, Linux, Cisco, MikroTik, Asterisk.

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

MSSQL_DB_SUSPECT 1С:Предприятие и СУБД

База 1С в статусе Suspect (Подозрительная) в MS SQL: аварийный ремонт Emergency

Обновлено: 26.08.2026 · Официальная документация ↗
  • В среде SQL Server Management Studio (SSMS) рядом с именем базы 1С горит статус (Suspect) или (Подозрительный).
  • Пользователи 1С получают ошибку: База данных не доступна / Database in suspect mode.
  • Сбой произошел после аварийного отключения электричества, сбоя RAID-контроллера или переполнения диска с логами (.LDF).

Что означает статус Suspect простыми словами

Статус Suspect означает, что SQL Server при запуске обнаружил физическое повреждение файла данных (.mdf) или журнала транзакций (.ldf) и заблокировал доступ к базе, чтобы избежать дальнейшего разрушения данных.

Шаг 1. Перевод базы в аварийный режим (EMERGENCY)

Откройте SQL Server Management Studio (SSMS), нажмите New Query (Создать запрос) и выполните следующий T-SQL скрипт:

-- 1. Переводим базу в аварийный режим только для чтения
ALTER DATABASE [baza_1c] SET EMERGENCY;
GO

-- 2. Переводим в монопольный режим одного пользователя
ALTER DATABASE [baza_1c] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO

Шаг 2. Проверка и ремонт поврежденных таблиц

-- 3. Запуск процедуры исправления ошибок (с возможной утерей поврежденных транзакций)
DBCC CHECKDB (N'baza_1c', REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS, NO_INFOMSGS;
GO

Шаг 3. Возврат базы в нормальный многопользовательский режим

-- 4. Перевод базы обратно в обычный режим
ALTER DATABASE [baza_1c] SET MULTI_USER;
GO
ALTER DATABASE [baza_1c] SET ONLINE;
GO

Шаг 4. Обязательное тестирование в Конфигураторе 1С

После ремонта средствами SQL откройте базу в Конфигураторе 1С и запустите Администрирование → Тестирование и исправление информационной базы.

💡 Практика специалистов: Перед запуском REPAIR_ALLOW_DATA_LOSS скопируйте файлы базы .mdf и .ldf на другой диск в режиме EMERGENCY. Это сохранит шанс на побитовое восстановление, если скрипт удалит критические системные таблицы.

Частые вопросы (FAQ)

Что делает параметр REPAIR_ALLOW_DATA_LOSS?

Он принудительно удаляет поврежденные страницы данных и незавершенные транзакции, чтобы вернуть базу в рабочее состояние. Небольшая часть последних несохраненных данных может быть потеряна.

Почему база переходит в статус Suspect?

Главные причины: внезапный сброс питания сервера без ИБП, битые сектора на диске, повреждение файла LDF или нехватка места на диске во время роста транзакции.

Что делать, если база не выходит из режима SINGLE_USER?

Найдите сессию, удерживающую монопольный захват (sp_who2), выполните KILL <SPID> и повторите команду SET MULTI_USER.

Поможет ли простое удаление файла журнала .ldf?

В обычном режиме нет. Но в режиме EMERGENCY SQL Server может принудительно пересоздать пустой файл лога командой ALTER DATABASE ... REBUILD LOG.

Полезные материалы
Рекомендуем