Databasens konsolkommando CHECKDB (DBCC CHECKDB)används för att kontrollera integriteten (fysisk & logisk) för objekt i en SQL Server-databas.Kommandot stöds i databaser som innehåller minnesoptimerade tabeller men valideringen stöds endast i diskbaserade tabeller. Alternativet DBCC repair är inte tillgängligt i minnesoptimerade tabeller och leder därför till ett behov av regelbunden säkerhetskopiering av databasen.Om ett problem uppstår i en minnesoptimerad tabell kan data återställas från den senast gjorda säkerhetskopian.
De olika operationer som utförs av CHECKDB är:
- DBCC CHECKALLOC exekvering på SQL-databasen.
- DBCC CHECKTABLE exekvering på varje tabell och vy i SQL-databasen.
- DBCC CHECKCATALOG exekvering på SQL-databasen.
- Validering av innehåll i den indexerade vyn i databasen.
- Validering av konsistens på länknivå bland filkataloger och tabellmetadata.
- Validering av data från servicemäklare.
Då DBCC CHECKDB kör alla andra kommandon är det inte nödvändigt att köra kommandona CHECKALLOC, CHECKTABLE och CHECKCATALOG separat.
DBCC CHECKDB Syntax
Argumenten som används i syntaxen ovan betyder följande:
database_name | database_id | 0 Detta är namnet på databasen.Om namnet inte anges eller endast 0 skrivs används den aktuella databasen. NOINDEX Anger att integritetskontrollen av icke klustrade indextabeller inte ska utföras. Detta leder till att den fullständiga exekveringstiden minskar.Syntaxen påverkar inte de data som finns i tabellerna. REPAIR_ALLOW_DATA_LOSS Syntaxen reparerar de fel som finns i databasen, vilket kan leda till förlust av vissa data.
Notera: Denna syntax stöds av Microsoft och visar sig inte alltid vara en idealisk lösning för att återställa databasen i ett bra fysiskt tillstånd. Detta beror på att den raderar hela den data som upptäcks vara skadad och kan leda till större dataförlust än vad som ursprungligen gjordes i databasen.
REPAIR_FAST Detta argument upprätthåller endast bakåtkompatibilitet och utför inga reparationer. REPAIR REBUILD Detta argument innehåller en snabbare reparationsprocess som inte innebär någon risk för dataförlust. ALL_ERRORMSGS Detta visar alla fel som genereras i alla objekt. Att inkludera eller utesluta denna syntax har ingen effekt eftersom felmeddelanden vanligtvis sorteras efter objekt-ID. Det maximala antalet felmeddelanden som genereras kan uppgå till 1000. EXTENDED_LOGICAL_CHECKS Med detta argument körs en kontroll av logisk konsistens på vyer och index, endast om kompatibilitetsnivån är 100. NO_INFOMSGS Det tar bort alla informationsmeddelanden. TABLOCK Denna syntax erhåller ett exklusivt lås på databasen och ökar hastigheten för DBCC CHECKDB på en databas vid hög belastning. Men den minskar databasens tillgänglighet för samtidiga operationer. ESTIMATEONLY Detta anger eller uppskattar hur mycket utrymme databasen skulle behöva för att köra CHECKDB-kommandot. PHYSICAL_ONLY Detta innebär en begränsning för att endast kontrollera databasens fysiska struktur. En kort kontroll av den fysiska databasen åtföljs av upptäckt av rivna sidor, fel och vanliga problem som användarna stöter på. DATA PURITY Denna syntax kontrollerar kolumnvärden som antingen ligger utanför intervallet eller inte är giltiga. Integritetskontroller av kolumnvärden är aktiverade som standard och behöver inte syntaxen DATA_PURITY.
Ting att tänka på
- Deaktiverade index kan inte kontrolleras av DBCC CHECKDB.
- De användardefinierade och byteordnade typerna måste serialiseras om DBCC CHECKDB måste exekveras. I alla andra fall uppstår fel 2537.
- DBCC CHECKDB kan inte köras direkt på resursdatabasen eftersom den endast kan ändras i single-mode.
Felmeddelanden som genereras av DBCC CHECKDB
När CHECKDB-kommandot är färdigt skrivs ett meddelande till SQL-felloggen. Vid framgång genereras ett meddelande som anger framgång och den totala tiden som kommandot kördes under. Vid misslyckande avslutas processen på grund av att något fel inträffat, vilket indikeras av ett meddelande. De olika tillståndsvärdena som representerar felmeddelandet är:
Felrapport
När korruption upptäcks av CHECKDB-kommandot skapas en dumpfil med namnet SQLDUMPNNNNNN.txt i loggkatalogen på SQL-servern. Om Feature Usage Data Collection och Error Reporting är aktiverade i SQL skickas felrapporten till Microsoft för förbättringsändamål.
Databasåterställning
I scenariot med felgenerering i SQL-server rekommenderas att återställa databasen från den senast skapade säkerhetskopian i stället för att reparera databasen.Om det inte finns någon säkerhetskopia kan du välja reparationsalternativ. Men att välja reparation med REPAIR_ALLOW_DATA_LOSS kan leda till att vissa data raderas.
Alternativ lösning för databasåterställning
Basiskt sett kontrollerar DBCC CHECKDB-kommandot databasens konsistenser, inklusive fysiska eller logiska. Detta kommando kontrollerar sidor, index och vissa andra komponenter i SQL server-databasen, men vid vissa kritiska punkter väljer detta kommando att vägra att återställa SQL-databasen. Om det inte finns någon säkerhetskopia av MS SQL server-databasen kan de valda reparationsalternativen radera en betydande mängd data.För att återställa databasen utan att kompromissa med dataintegriteten kan du därför välja en lösning för återställning av Microsoft SQL-databaser. De garanterar fullständig återställning av databasen utan att ta bort någon mängd data.