DBCC CHECKDB Not Run Recently

Wanneer SQL Server gegevens naar uw schijven schrijft, gaat hij ervan uit dat alles in orde is totdat hij de gegevens weer moet lezen.

In het geval van beschadiging van de opslag is de opslag helaas niet zo vriendelijk om SQL Server te waarschuwen. En soms is het zelfs bekend dat SQL Server zelf corrupt is.

We moeten periodiek controleren of de gegevens op de schijf nog steeds zinvol zijn, en dat is waar DBCC CHECKDB om de hoek komt kijken. Het controleert op zowel allocatie fouten en consistentie fouten. Bovendien, als er problemen zijn, zullen de foutmeldingen terugkomen met informatie over waar de fouten zich voordoen, de ernst van de fout, evenals de voorgestelde reparatie-optie.

Het is essentieel om CHECKDB op regelmatige basis uit te voeren om fouten te vinden als ze bestaan, want als er corruptie is, moeten we het repareren voordat onze laatste goede back-ups verdwijnen.

Om het probleem te vinden, controleren we elke database om er zeker van te zijn dat DBCC CHECKDB een succesvolle controle heeft uitgevoerd in de laatste twee weken.

Gelooft u het niet?

“Maar ik draai CHECKDB de hele tijd,” zou je kunnen zeggen – nou, laten we eens kijken:

Transact-SQL

1
DBCC DBINFO(‘StackOverflow’) WITH TABLERESULTS

Dat is het. Maar de uitvoer is een nachtmerrie. Het zijn ongeveer 80 regels met dingen die je waarschijnlijk nooit interesseren. Rond regel 50 is wat je zoekt.

Hoi, ik ben onzin.

En dit is waarschijnlijk wat je zult zien! Een datum van 1900-01-01 enz. Dat betekent nooit. Als je DBCC CHECKDB op de database uitvoert, misschien zo:

Transact-SQL

1
DBCC CHECKDB(‘StackOverflow’) WITH NO_INFOMSGS, ALL_ERRORMSGS

En voer dan het DBCC DBINFO commando opnieuw uit, onze datum is nu bijgewerkt naar huidig:

LOOK HOW MUCH FUN WE’RE HAVING

Als de datum niet wordt bijgewerkt, betekent dat een van de twee dingen: SQL Server kan niet schrijven naar de database (alsof het alleen-lezen is), of het vindt fouten (hoowee, niet goed.)

Om het probleem op te lossen

Beslis of je de ingebouwde Onderhoudsplannen wilt gebruiken, of een gratis tool zoals Ola Hallengren’s gratis CHECKDB scripts. Een paar overwegingen:

  • Onderhoudsplannen hebben een grafische interface, voor het geval je geen T-SQL kent.
  • De gratis scripts van Ola Hallengren zorgen voor fijnafgestemde opties, zoals het automatisch uitvoeren van data_purity checks (wat een goede zaak is).

Hoe regelmatig onderhoud in te stellen om te controleren op corruptie

Optie 1: Gebruik een onderhoudsplan om DBCC CHECKDB uit te voeren

Als u onderhoudsplannen gebruikt, kunt u onderhoudsplannen bewerken in SQL Server Management Studio onder Beheer, Onderhoudsplannen. Uw server kan meerdere onderhoudsplannen hebben voor het uitvoeren van CHECKDB voor verschillende typen databases, bijvoorbeeld een voor systeemdatabases en een voor gebruikersdatabases.

Bouw het knooppunt Beheer in SSMS uit, klik met de rechtermuisknop op Onderhoudsplannen en selecteer Nieuw plan.

Vanuit de Toolbox, die soms aan de linkerkant wordt verborgen, sleept u de taak Database-integriteit controleren naar het tabblad Onderhoudsplan.

Wanneer u dubbelklikt op het vakje Database-integriteit controleren op het tabblad Onderhoudsplan, kunt u kiezen welke databases u tijdens het proces wilt laten controleren.

Van daaruit hoeft u de taak alleen nog maar in te plannen, wat net zo gaat als het inplannen van een Agent Job.

Nadat u het onderhoudsplan hebt opgeslagen en afgesloten, moet u de desbetreffende taak in de SQL Server Agent opzoeken en de eigenschappen voor kennisgeving instellen om een operator te laten weten of de taak mislukt.

Optie 2: Stel SQL Agent Jobs in om DBCC CHECKDB uit te voeren met behulp van Ola Hallengren’s gratis scripts

Als u voor het eerst integriteitscontroles uitvoert, overweeg dan het gebruik van Ola Hallengren’s gratis onderhoudsscripts. Ze zijn niet zo eenvoudig als onderhoudsplannen, maar ze zijn veel flexibeler. Ze bevatten ook de mogelijkheid om DBCC operaties op te splitsen in kleinere brokken voor grote databases. Op zeer grote databases kan CHECKDB veel tijd en middelen kosten – de optie WITH PHYSICAL_ONLY is sneller, maar laat de logische controles achterwege.

Zodra de agenttaken zijn geïnstalleerd, kunt u deze net zo eenvoudig plannen als onderhoudsplannen, of u kunt ze verfijnen met de aanvullende opties die hier worden beschreven.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.