MSSQL Ошибка 8980: Table error Previous page was not seen
- Сообщение DBCC CHECKDB:
Msg 8980, Level 16, State 1: Table error: Object ID ..., index ID ..., page ID (1:22334). Previous page (1:22333) was not seen in the scan. - Нарушение целостности и порядка следования смежных страниц индекса.
- Зависание регламентных заданий бэкапа и обслуживания баз данных.
- Ошибки чтения строк при прямом поиске по кластерному индексу в 1С.
1. Экспресс-проверка поврежденного объекта
DBCC CHECKTABLE ('dbo._Reference123') WITH NO_INFOMSGS, ALL_ERRORMSGS;2. Перестроение структуры таблицы и индексов
-- Пересоздание всех индексов таблицы с принудительным пересчетом метаданных
ALTER INDEX ALL ON dbo._Reference123 REBUILD WITH (ONLINE = OFF);3. Восстановление страниц из резервной копии
RESTORE DATABASE [DatabaseName]
PAGE = '1:22333, 1:22334'
FROM DISK = 'C:\Backup\Full.bak'
WITH NORECOVERY;
RESTORE LOG [DatabaseName] FROM DISK = 'C:\Backup\Log.trn' WITH RECOVERY;4. Аварийный ремонт через DBCC CHECKDB
ALTER DATABASE [DatabaseName] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB ('DatabaseName', REPAIR_ALLOW_DATA_LOSS);
ALTER DATABASE [DatabaseName] SET MULTI_USER;
💡 Практика специалистов:
Если ошибки B-дерева (8976, 8978, 8980) повторяются после перестроения индексов, проверьте настройки дискового кэша RAID-контроллера (Write-Back без исправного BBU/Flash-кэша может приводить к потере незаписанных блоков при сбоях питания).
Частые вопросы (FAQ)
В чем физический смысл ошибки 8980?
При сканировании страницы обнаруживается, что ее поле m_prevPage ссылается на страницу, которая не принадлежит данному объекту, не выделена в IAM или отсутствует в файле данных.
Теряются ли данные при перестроении индекса при ошибке 8980?
Если повреждение не затронуло физические строки данных на самих страницах, операция ALTER INDEX ... REBUILD полностью восстанавливает дерево без потери единой строки.
Как убедиться, что после исправления ошибок не осталось?
Выполните повторную полную проверку: DBCC CHECKDB ('DatabaseName') WITH NO_INFOMSGS, ALL_ERRORMSGS, EXTENDED_LOGICAL_CHECKS.
Что делать, если база находится в состоянии SUSPECT?
Переведите базу в EMERGENCY (ALTER DATABASE DB SET EMERGENCY), выполните REPAIR_ALLOW_DATA_LOSS и переведите обратно в MULTI_USER.