Az a baj ezekkel a system page-ekkel, hogy ha elromlanak, akkor a DBCC semmilyen formája nem szokta javítani, viszont az SQL szerver meg használná őket. A neten sem írnak semmi biztatót, leginkább azt javasolják, hogy pumpáljunk át mindent egy újonnan létrehozott db-be vagy vegyük elő a backup-ot.
Anno én is kaptam egy DB-t system page error-al és a szerveren vészesen fogyó hellyel, ráadásul évek óta nem volt mentés róla. A feladat helyet felszabadítani vagy költöztetni a DB-t egy nagyobb tárkapacitással rendelkező szerverre, na meg persze valamit kezdeni a korrupt lapokkal. A probléma még az volt, hogy a DB-t aktívan használták. Mivel az adatbázisban volt párszáz GB szabad hely, ezért arra hajlottam, hogy inkább próbáljunk shrink-elni, a system page error-ra meg majd kitalálunk valamit. Végül sikerült a shrink is és kivédtük a korrupciós hibákat is, de kellett hozzá szerencse. Mielőtt megírom a megoldást, ami sokkal egyszerűbb, mint maga a probléma, nézzük a szerencsés esetet.
- Egy adatbázis 200+ fájlal és fájlgroup-pal: ezek közül volt egy vagy több hibás, az egészséges fájlok viszont shrink-elhetőek
- A DB működött
- A teszt szerveren a restore után online-ba tudott jönni az adatbázis
A menet a következő volt: Copy only backup (hogy ne akarjon a DCM system page-re írni) az éles szerveren, majd restore egy teszt szerveren és máris mehet a játék. A restore sikeres, látszólag semmi gond, használható az adatbázis, viszont az SQL szerver szépen csendben irkálja a memory dump-okat a C:-re. Mielőtt azt gondolnátok, hogy ez rossz, valójában ez nagyon jó dolog, mert semmit nem kellett tennem ahhoz, hogy előidézzem azt a hibát, ami egyébként is bekövetkezett volna. Stopper indul, annyi időm van, amíg elfogy a hely a C:-ről. Egyetlen saját tervem van, mégpedig, hogy readonly-ba teszem a fájlgroup-okat. Bejött, megszűntek a memory dump-ok. Elkezdtem visszaállítani readwrite-ba a fájlgroup-okat, és ahol ismét jöttek a memory dump-ok azok tartalmazták a hibás lapokat, ezek mentek vissza readonly-ba, hogy még véletlen se jusson eszébe az SQL szervernek írni őket. Szóval a readonly volt a fegyverem a korrupt system page-k ellen. Akinek hasonló gondja van, megpróbálhatja ezzel a módszerrel is oltani a tüzet, hátha neki is szerencséje lesz vele.
Akit érdekel még, hogy mit tegyen ilyen esetben, annak tudom ajánlani Bitemo Eriktől a mit tegyünk a korrupt adatbázisokkal blogbejegyzését, az övé profibb 🙂
Végezetül nézzük néhány ilyen system page-es error üzenetet:
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Msg 5243, Level 22, State 8, Line 3
An inconsistency was detected during an internal operation. Please contact technical support.
Msg 8909, Level 16, State 1, Line 1
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 0 (type Unknown), page ID (30:16176) contains an incorrect page ID in its page header. The PageId in the page header = (0:0)
Msg 8998, Level 16, State 2, Line 1
Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID 13 pages from (30:16176) to (30:24263). See other errors for cause.
A select * from sys.dm_db_file_space_usage parancsra jött ez:
Msg 824, Level 24, State 2, Line 1
SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 30:8088; actual 0:0). It occurred during a read of page (30:8088) in database ID 13 at offset 0x00000003f30000 in file ‘Fájl elérési útvonala’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
Ms-sql online 
Hozzászólás