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

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

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

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

MSSQL Error 9003: The log scan number (LSN) is not valid — Восстановление

Обновлено: 25.08.2026 · Официальная документация ↗

Ошибка 9003 возникает при запуске (восстановлении/REDO-фазе) базы данных или репликации, когда менеджер транзакций встречает недействительный номер последовательности журнала (LSN), нарушающий непрерывность цепочки транзакций.

  • Сообщение: The log scan number %S_LSN passed to log scan in database '%.*ls' is not valid (Severity 20, State 1).
  • База данных зависает в статусе Recovery Pending или Suspect после аварийного отключения электропитания или сбоя хоста гипервизора.
  • Сбой выполнения команды RESTORE DATABASE ... WITH RECOVERY.
  • Отказ монтирования базы данных через sp_attach_db.

1. Проверка текущего статуса базы данных

SELECT name, state_desc FROM sys.databases WHERE name = 'YourDatabaseName';

2. Попытка стандартного перевода в EMERGENCY и проверка

ALTER DATABASE [YourDatabaseName] SET EMERGENCY;
ALTER DATABASE [YourDatabaseName] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
DBCC CHECKDB ([YourDatabaseName], NOINDEX);
GO

3. Принудительное пересоздание журнала транзакций (Rebuild Log)

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

ALTER DATABASE [YourDatabaseName] SET EMERGENCY;
ALTER DATABASE [YourDatabaseName] SET SINGLE_USER;
GO
-- Принудительное удаление старого LDF и создание чистого нового лога
ALTER DATABASE [YourDatabaseName] REBUILD LOG ON 
(NAME = YourDatabaseName_Log, FILENAME = 'D:\MSSQL\Data\YourDatabaseName_Log_New.ldf');
GO
ALTER DATABASE [YourDatabaseName] SET MULTI_USER;
GO

4. Аварийный ремонт при невозможности пересборки лога

ALTER DATABASE [YourDatabaseName] SET EMERGENCY;
ALTER DATABASE [YourDatabaseName] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
DBCC CHECKDB ([YourDatabaseName], REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS, NO_INFOMSGS;
GO
ALTER DATABASE [YourDatabaseName] SET MULTI_USER;
GO

5. Проверка логической целостности в 1С

После успешного старта базы запустите тестирование и исправление через Конфигуратор 1С с реструктуризацией таблиц.

💡 Практика специалистов: После выполнения REBUILD LOG или REPAIR_ALLOW_DATA_LOSS цепочка резервных копий журнала транзакций полностью аннулируется. Обязательно выполните новый полный бэкап (FULL BACKUP) немедленно после ввода базы в эксплуатацию.

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

Почему повреждается LSN номер в журнале транзакций?

Главные причины: аварийный сброс питания сервера с отключенным дисковым кэшем записи (Write-Caching without BBU), сбой виртуализации при snapshot-бэкапах или повреждение секторов диска с файлом .ldf.

Приведет ли REBUILD LOG к потере данных?

Операция REBUILD LOG сбрасывает все незафиксированные транзакции, которые находились в логе на момент падения. Данные, уже записанные на страницы данных (MDF), сохраняются.

Что делать, если REBUILD LOG выдает ошибку Checkpoint LSN mismatch?

В таком случае единственным методом восстановления без бэкапа остается DBCC CHECKDB (... REPAIR_ALLOW_DATA_LOSS) в режиме EMERGENCY.

Можно ли предотвратить ошибку 9003 в будущем?

Отключите Write-Caching на дисках без аппаратного BBU/NVRAM, используйте ИБП с автоматическим graceful shutdown и настройте регулярные полные и лог-бэкапы.

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