När SQL Server skriver data till dina hårddiskar antar den att allt är okej tills den behöver läsa tillbaka data igen.
Olyckligtvis är lagringsutrymmet inte så snällt att det varnar SQL Server om det uppstår korruption i lagret. Och ibland har SQL Server till och med varit känd för att korrumpera sig själv.
Vi måste regelbundet kontrollera att datan på disken fortfarande är meningsfull, och det är där DBCC CHECKDB kommer in i bilden. Den kontrollerar både allokeringsfel och konsistensfel. Om det dessutom finns några problem kommer felmeddelandena tillbaka med information om var felen finns, felets allvarlighetsgrad samt föreslaget reparationsalternativ.
Det är viktigt att köra CHECKDB regelbundet för att hitta fel om de finns, för om det finns korruption måste vi åtgärda det innan våra sista bra säkerhetskopior försvinner.
För att hitta problemet kontrollerar vi varje databas för att se om DBCC CHECKDB har genomfört en lyckad kontroll under de senaste två veckorna.
Trodde du inte på det?
”Men jag kör CHECKDB hela tiden”, säger du kanske – men låt oss ta reda på det:
|
1
|
DBCC DBINFO(’StackOverflow’) WITH TABLERESULTS
|
Det är allt. Men resultatet är en mardröm. Det är ungefär 80 rader med saker som du förmodligen aldrig kommer att bry dig om. Runt rad 50 finns det du letar efter.
Hej, jag är nonsens.
Och det här är förmodligen vad du kommer att se! Ett datum 1900-01-01-01 osv. Det betyder aldrig. Om du kör DBCC CHECKDB på databasen, kanske så här:
|
1
|
DBCC CHECKDB(’StackOverflow’) WITH NO_INFOMSGS, ALL_ERRORMSGS
|
Och kör sedan DBCC DBINFO-kommandot igen, vårt datum är nu uppdaterat till aktuellt:
Se hur roligt vi har det
Om datumet inte uppdateras betyder det en av två saker: SQL Server kan inte skriva till databasen (som om den är skrivskyddad), eller så hittar den fel (hoowee, inte bra.)
För att åtgärda problemet
Beslut om du vill använda inbyggda underhållsplaner eller ett gratis verktyg som Ola Hallengrens gratis CHECKDB-skript. Några överväganden:
- Underhållsplaner har ett grafiskt gränssnitt, om du inte kan T-SQL.
- Ola Hallengrens kostnadsfria skript tar hand om finjusterade alternativ, som att automatiskt köra data_purity-kontroller (vilket är en bra sak).
Hur du ställer in regelbundet underhåll för att kontrollera korruption
Option 1: Använd en underhållsplan för att köra DBCC CHECKDB
Om du använder underhållsplaner kan du redigera underhållsplaner i SQL Server Management Studio under Management, Maintenance Plans. Din server kan ha flera underhållsplaner som kör CHECKDB för olika typer av databaser, till exempel en för systemdatabaser och en för användardatabaser.
Expander noden Hantering i SSMS, högerklicka på Underhållsplaner och välj Ny plan.
Från fönstret Verktygslåda, som ibland döljs till vänster, drar du uppgiften Kontrollera databasintegritet över till fliken Underhållsplan.
När du dubbelklickar på rutan Kontrollera databasintegritet i fliken Underhållsplan kan du välja vilka databaser du vill ha kontrollerade under processen.
Därifrån återstår bara att schemalägga den, vilket är precis som att schemalägga ett agentjobb.
När du har sparat och stängt underhållsplanen ska du se till att hitta det relaterade jobbet i SQL Server Agent och ställa in Notifieringsegenskaperna så att en operatör får veta om det misslyckas.
Option 2: Konfigurera SQL Agent-jobb för att köra DBCC CHECKDB med hjälp av Ola Hallengrens kostnadsfria skript
Om du implementerar integritetskontroller för första gången kan du överväga att använda Ola Hallengrens kostnadsfria underhållsskript. De är inte riktigt lika enkla som underhållsplaner, men de är mycket mer flexibla. De innehåller också möjligheten att dela upp DBCC-operationer i mindre bitar för stora databaser. På mycket stora databaser kan CHECKDB ta mycket tid och resurser i anspråk – alternativet WITH PHYSICAL_ONLY är snabbare, men utelämnar de logiska kontrollerna.
När agentjobben är på plats kan du schemalägga dem så att de körs lika enkelt som underhållsplaner, eller så kan du finjustera dem med de ytterligare alternativ som dokumenteras här.