SQL Server DBCC CHECKDB Översikt

By: Brady Upton | Uppdaterad: 2016-07-26 | Kommentarer (2) | Relaterad: Mer > Databaskonsolkommandon DBCCs

Problem

SQL Server-databaskorruption kan vara ett problem och kan orsaka allvarlig skada på en databas. Om du är en erfaren DBA har du förmodligen skyddsåtgärder för att upptäcka detta, men under årens lopp har jag sett hundratals SQL-servrar som inte har några upptäcktsmetoder alls och detta är ett problem. Det finns några sätt att upptäcka databaskorruption, men det här tipset kommer att fokusera mer på DBCC CHECKDB.

Lösning

Du kanske har hört talas omDBCC-uttalanden (database console commands) eller inte. Dessa uttalanden används för att utföra olika operationer i din databas och kan delas in i fyra kategorier: Underhåll, Diverse, Information och Validering. Jag använder några av DBCC-anvisningarna dagligen, men ingen mer än DBCC CHECKDB.

Vad är SQL Server DBCC CHECKDB

DBCC CHECKDB, frånMicrosoft MSDN Library, kontrollerar den logiska och fysiska integriteten hos alla objekt i den angivna databasen genom att utföra följande operationer:

• Kör DBCC CHECKALLOC på databasen – Kontrollerar konsistensen av strukturerna för diskutrymmeallokering för en angiven databas.
• Kör DBCC CHECKTABLE på varje tabell och vy i databasen – Kontrollerar integriteten hos alla sidor och strukturer som utgör tabellen eller den indexerade vyn.
• Kör DBCC CHECKCATALOG på databasen – Kontrollerar katalogens konsistens i databasen.
• Validerar innehållet i varje indexerad vy i databasen.
• Validerar konsistensen på länknivå mellan metadata för tabeller och kataloger och filer i filsystemet när du lagrar varbinära (max) data i filsystemet med hjälp avFILESTREAM.
• Validerar Service Broker-data i databasen

Om du någonsin har kört DBCC CHECKDB vet du att det tar tid för stora databaser.Nu när du känner till alla steg som körs kan du förstå varför det tar tid att slutföra.

Hur kan SQL Server DBCC CHECKDB hjälpa mig?

Datakorruption är illa. Det kan orsaka alla möjliga problem i databasen som kan inkludera felaktiga dataresultat, misslyckade SQL-utsagor och i vissa fall kan det ta ner hela SQL-instansen. DBCC CHECKDB varnar dig för korruption så att du kan åtgärda det innan det (förhoppningsvis) blir för illa.

Hur använder jag SQL Server DBCC CHECKDB?

DBCC CHECKDB är ganska enkelt. Det finns några alternativ som du kan använda med uttalandet och vi kommer att gå igenom några av dem i nästa avsnitt, men den grundläggande syntaxen ser ut så här:

DBCC CHECKDB ('DatabaseName') 

Ganska enkelt.

Automate SQL Server DBCC CHECKDB

Självklart vill du inte logga in varje morgon och köra det här uttalandet på varje databas, så du kan automatisera den här processen med hjälp av några olika metoder:

• SQL Server Underhållsplaner -Underhållsplaner är en del av SQL Server från början (såvida du inte kör ExpressEdition). Jag gillar inte att använda underhållsplaner för det mesta, men jag har inget emot att använda dem för den här typen av uppgift. I verktygslådan Maintenance Plan måste du använda uppgiften Check Database Integrity. Det enda konfigurerbara alternativet är att inkludera index så det är inte riktigt användarvänligt, men i vissa fall är det allt du behöver. Återigen kommer vi att tala om andra alternativ i nästa avsnitt.

• Anpassade skript – Anpassade skript är vanligtvis vad jag använder och erbjuder den bästa flexibiliteten när det gäller att lägga till de alternativ du vill ha. Mina go-toscripts är redan skapade och gratis att använda frånOla Hallengren. Han har gjort ett fantastiskt arbete med att skapa dessa och dela med sig av dem till världen. TackOla!
• Kontrollera skript på MSSQLTips.com:
• Upprätta underhåll med SQL Server-databaser i fullständigt återställningsläge
• SQL Server Database Maintenance Plans and Backup File Management
• Upprätta SQL Server-underhåll utan underhållsfönster

SQL Server DBCC CHECKDB-alternativ

Det finns ett fåtal alternativ som man kan använda med DBCC CHECKDB och jag kommer att gå igenom ett par av de mer populära här:

• NOINDEX – Anger att intensiva kontroller av icke klustrade index för användartabeller inte ska utföras. Detta minskar tiden för utförande av överväxling. NOINDEX påverkar inte systemtabeller eftersom integritetskontroller alltid utförs på index för systemtabeller.
• NO_INFOMSGS – Undertrycker alla informationsmeddelanden.
• PHYSICAL_ONLY – Begränsar kontrollen till integriteten av den fysiska strukturen för sid- och registerhuvuden och databasens allokeringskonsistens. Den här kontrollen är utformad för att ge en liten overheadkontroll av databasens fysiska konsistens, men den kan också upptäcka rivna sidor, fel i kontrollsumman och vanliga maskinvarufel som kan äventyra en användares data.
• TABLOCK – Föranleder DBCC CHECKDB att hämta lås i stället för att använda en intern ögonblicksbild av databasen. Detta inkluderar ett kortsiktigt exklusivt (X)lås på databasen. TABLOCK gör att DBCC CHECKDB körs snabbare på en databas med hög belastning, men minskar den tillgängliga samtidigheten i databasen medan DBCC CHECKDB körs.
• DATA_PURITY – Gör att DBCC CHECKDB kontrollerar databasen efter kolumnvärden som inte är giltiga eller som ligger utanför intervallet. DBCC CHECKDB upptäcker till exempel kolumner med datum- och tidsvärden som är större eller mindre än det acceptabla intervallet för datatypen datetime, eller kolumner av decimal- eller approximativ numerisk datatyp med skal- eller precisionsvärden som inte är giltiga.

Vi kommer att gå igenom några av alternativen för REPAIR i ett annat avsnitt nedan.

Hur ofta ska jag kontrollera om SQL Server är skadad?

Varje minut av varje dag. Jag skojar bara.

Om du har ett dagligt underhållsfönster skulle det vara bra att kontrollera datakorruption dagligen. Ju snabbare du kan fånga upp det, desto mindre skada kan det göra. Jag har märkt att många kör detta på helgen, särskilt med större databaser. Det finns inget rätt eller fel med detta, se bara till att du har det schemalagt med jämna mellanrum.

Måste jag köra DBCC CHECKDB i min produktionsmiljö?

Nej, ja, ja. På sätt och vis.

För att kontrollera om data korrumperas är det inte bra att köra DBCC CHECKDB i testmiljön…UTAN att du återställer en kopia av produktionsmiljön till testmiljön och sedan kör den. BRILLANT!

Du kanske undrar om vissa HA-alternativ är lämpliga, t.ex. AlwaysOn, LogShipping etc.? Nej, du måste kontrollera din *live* produktionsmiljö.

Nu när DBCC CHECKDB är konfigurerad och körs, vad letar jag efter?

Grattis! Du har automatiserat och kört DBCC CHECKDB, men vad händer nu? Om du har ettSQL ServerAgent Job inställt, se till att du ställer inDatabase Mail, en operatör och ett meddelande på jobbet. Om jobbet lyckas fortsätter du med din vackra dag. Om jobbet misslyckas har vi en del att göra.

Du kan se ett fel som detta:

eller så här:

För det första, ingen panik. För det andra, kontrollera säkerhetskopior. DBCC CHECKDB-fel brukar berätta vad som behöver göras.

För det första felet kommer en DBCC UPDATEUSAGE att korrigera de felaktiga sid- och radräkningarna i katalogvyerna. Ganska ofarligt.

Det andra felet rapporterar datakorruption. I felet nämns repair_allow_data_loss som minsta reparationsnivå. Det betyder att du kan köra kommandot med detta argument, men att du kan förlora data. Det är därför jag alltid rekommenderar att du återställer till en säkerhetskopia om du kan. Du måste se till att säkerhetskopian inte innehåller skadade data och du vill vara säker på att det inte sker någon dataförlust.

Hur man reparerar en SQL Server-databas

Om du inte har någon säkerhetskopia kan det hända att vi måste använda DBCC CHECKDB med ett reparationsalternativ.Här är de reparationsalternativ som finns tillgängliga att använda. Dessa kan fungera eller inte och måste användas som en sista utväg:

• REPAIR_ALLOW_DATA_LOSS – Försöker reparera alla rapporterade fel.Dessa reparationer kan orsaka viss dataförlust.
• REPAIR_REBUILD – Utför reparationer som inte har någon möjlighet till dataförlust. Detta kan inkludera snabba reparationer, t.ex. reparation av saknade rader i icke klustrade index, och mer tidskrävande reparationer, t.ex. återuppbyggnad av ett index.

Som jag sa ovan är det mycket viktigt att ha uppdaterade säkerhetskopior för att kunna återhämta sig från korruption. Korruption bryr sig inte om hur mycket data du har, vilken version av SQL du kör eller hur flott ditt datacenter är.

Jag känner mig ganska nöjd med detta, men vad mer kan jag använda för att skydda mina SQL-instanser?

DBCC CHECKDB bör köras på varje SQL-instans du har, men det finns ett par andra sätt som kan hjälpa till att upptäcka/förhindra datakorruption.

• SQL Server Agent Alerts – Brian Kelley har skrivit ett trevligt tips på det här ämnet här.
• Sidverifiering – Kontrollera att dina databaser använder sig avCHECKSUM sidverifiering. Om du fortfarande kör SQL 2005 eller lägre är detta inte tillgängligt, men när du har uppgraderat ska du se till att ändra den här inställningen. För att se inställningar för sidverifiering använder du följande instruktion:

select name, page_verify_option_desc from sys.databases 

Nästa steg

• Se till att kolla inMSDN Library för mer djupgående information om DBCC CHECKDB
• MSSQLTips.com har en trevlig samling tips om konsistenskontroller av databaser som också kan vara till hjälp.

Sist uppdaterad: 2016-07-26

Om författaren

Brady Upton är en databasadministratör och SharePoint superstar i Nashville, TN.
Se alla mina tips

Relaterade resurser

• Mer SQL Server DBA Tips…