Beschädigte Seiten finden (suspect_pages) und einzelne Seiten wiederherstellen
SQL ServerRestore & RecoveryBefehl
-- Pages that hit 823/824 or checksum errors:
SELECT DB_NAME(sp.database_id) AS db, sp.file_id, sp.page_id,
CASE sp.event_type WHEN 1 THEN '823/824 error' WHEN 2 THEN 'bad checksum'
WHEN 3 THEN 'torn page' WHEN 4 THEN 'restored'
WHEN 5 THEN 'repaired' WHEN 7 THEN 'deallocated by DBCC' END AS event_desc,
sp.error_count, sp.last_update_date
FROM msdb.dbo.suspect_pages sp
ORDER BY sp.last_update_date DESC;
-- Page restore (example 1:336): FULL + later logs + a new log backup
RESTORE DATABASE [Musteri] PAGE = '1:336'
FROM DISK = N'D:\Backup\Musteri_full_20261008.bak' WITH NORECOVERY;
RESTORE LOG [Musteri] FROM DISK = N'D:\Backup\Musteri_log_1200.trn' WITH NORECOVERY;
BACKUP LOG [Musteri] TO DISK = N'D:\Backup\Musteri_log_pagetail.trn' WITH INIT;
RESTORE LOG [Musteri] FROM DISK = N'D:\Backup\Musteri_log_pagetail.trn' WITH RECOVERY;
-- Verify:
DBCC CHECKDB (N'Musteri') WITH NO_INFOMSGS, ALL_ERRORMSGS;Was es tut
Listet aus msdb.dbo.suspect_pages Seiten mit I/O-Fehlern (823/824), Checksum- oder Torn-Page-Fehlern; repariert einzelne beschädigte Seiten, indem sie aus dem FULL-Backup geholt und mit Logs vorwärtsgerollt werden, ohne die ganze Datenbank wiederherzustellen.
Wann einsetzen
Bei Fehlern 823/824 im Error Log, bei auf wenige Seiten begrenzten Konsistenzfehlern in CHECKDB oder wenn eine Benutzerabfrage mit "incorrect checksum" fehlschlägt.
Vorsicht
Erfordert Recovery Model FULL oder BULK_LOGGED und eine ununterbrochene Log-Kette. Online Page Restore gibt es nur in Enterprise/Developer; in anderen Editionen ist die Datenbank während des Restores offline. Allokationsseiten (GAM/SGAM/PFS), Dateiheader und die Boot Page (1:9) lassen sich so nicht wiederherstellen. 823/824 bedeutet meist ein Speicherproblem; schließe den Fall nicht, ohne Platte/Controller/SAN zu prüfen, sonst tritt er erneut auf. Bei vielen defekten Seiten ist ein vollständiger Datenbank-Restore schneller.