Устранение повреждений страниц MSSQL с помощью DBCC CHECKDB: исправление ошибок
Повреждение страниц базы данных (Torn Page, Bad Checksum) проявляется следующими ошибками в журнале ERRORLOG и приложениях:
- Error 823: Ошибка ввода-вывода операционной системы при чтении или записи страницы;
- Error 824: Нарушение логической целостности страницы (не совпадает контрольная сумма CHECKSUM);
- Error 825 (Read-Retry Required): Предупреждение о том, что страница прочиталась только после повторной попытки (симптом деградации диска);
- Сбои регламентных заданий 1С:Предприятие с сообщением 'Ошибка СУБД: Таблица повреждена...'.
1. Экспресс-диагностика повреждений через DBCC CHECKDB
Запустите полную проверку базы с подробным выводом ошибок:
DBCC CHECKDB ([ERP_1C]) WITH NO_INFOMSGS, ALL_ERRORMSGS, PHYSICAL_ONLY;Опция PHYSICAL_ONLY проверяет физическую целостность заголовков страниц и контрольные суммы B-дерева, минимизируя нагрузку на сервер.
Для глубокой логической проверки запустите:
DBCC CHECKDB ([ERP_1C]) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY;2. Анализ системной таблицы suspects
Проверьте список зарегистрированных битых страниц ядра СУБД:
SELECT database_id, file_id, page_id, event_type, error_count, last_update_date
FROM msdb.dbo.suspect_pages
WHERE database_id = DB_ID('ERP_1C');3. Алгоритм устранения без потери данных (Best Practice)
- Повреждение некластеризованного индекса: Перестройте или удалите сбойный индекс:
ALTER INDEX [IX_Sales_DocNum] ON [dbo].[Document_Sales] REBUILD;- Повреждение страниц данных (Data Pages): Если есть рабочие бэкапы, выполните постраничное восстановление (Page Restore) без остановки базы.
4. Исправление через DBCC (Крайняя мера)
Если бэкапов нет, используйте безопасный режим ремонта (исправляет только индексы без риска для данных):
ALTER DATABASE [ERP_1C] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
DBCC CHECKDB ([ERP_1C], REPAIR_REBUILD);
GO
ALTER DATABASE [ERP_1C] SET MULTI_USER;
GO Частые вопросы (FAQ)
Чем отличается REPAIR_REBUILD от REPAIR_ALLOW_DATA_LOSS?
REPAIR_REBUILD перестраивает поврежденные вторичные индексы без удаления информации. REPAIR_ALLOW_DATA_LOSS принудительно освобождает и удаляет поврежденные страницы данных из цепочек распределения, что гарантированно ведет к частичной потере строк таблицы.
Почему опция PAGE_VERIFY CHECKSUM обязательна?
Механизм CHECKSUM вычисляет 4-байтный хеш всей 8-килобайтной страницы при записи на диск. При чтении хеш сверяется. Если произошел сбой дискового контроллера, MSSQL мгновенно зафиксирует ошибку 824, предотвратив тихую порчу смежных данных.
Как очистить системную таблицу suspect_pages после исправления ошибок?
После успешного исправления страниц вручную удалите записи: EXEC msdb.dbo.sp_delete_backuphistory @oldest_date = '...' или обновите статус через DELETE FROM msdb.dbo.suspect_pages WHERE database_id = DB_ID('ERP_1C').
Что делать, если CHECKDB зависает на этапе создания скрытого Database Snapshot?
CHECKDB создает внутренний моментальный снимок базы. Если на диске с файлом MDF недостаточно свободного места под разряженный файл (sparse file), проверка аварийно завершится. Запустите DBCC с опцией WITH TABLOCK, чтобы избежать создания снимка.