SQL Server DBCC CHECKDB-oversigt

Af: Brady Upton | Opdateret: 2016-07-26 | Kommentarer (2) | Relateret: Mere > Database Console Commands DBCCs

Problem

SQL Server database korruption kan være et problem og kan forårsage alvorlig skade på en database. Hvis du er en erfaren DBA, så har du sikkert sikkerhedsforanstaltninger på plads for at opdage dette, men i årenes løb har jeg set hundredvis af SQL-servere uden nogen som helst detektionsmetoder, og det er et problem. Der er et par måder at detekteredatabase korruption på, men dette tip vil fokusere mere på DBCC CHECKDB.

Løsning

Du har måske eller måske ikke hørt omDBCC (database console commands) statements. Disse instruktioner bruges til at udføre forskellige operationer i din database og kan opdeles i fire kategorier: Vedligeholdelse, Diverse, Information og Validering. Jeg bruger nogle af DBCC-angivelserne dagligt, men ikke mere end DBCC CHECKDB.

Hvad er SQL Server DBCC CHECKDB

DBCC CHECKDB fra Microsoft MSDN Library kontrollerer den logiske og fysiske integritet af alle objekter i den angivne database ved at udføre følgende operationer:

• Kører DBCC CHECKALLOC på databasen – Kontrollerer konsistensen af diskpladsallokeringsstrukturer for en angivet database.
• Kører DBCC CHECKTABLE på alle tabeller og visninger i databasen – Kontrollerer integriteten af alle de sider og strukturer, der udgør tabellen eller den indekserede visning.
• Kører DBCC CHECKCATALOG på databasen – Kontrollerer katalogkonsistens i databasen.
• Validerer indholdet af alle indekserede visninger i databasen.
• Validerer konsistensen på linkniveau mellem tabelmetadata og filsystemmapper og filer, når der lagres varbinære (max) data i filsystemet ved hjælp afFILESTREAM.
• Validerer Service Broker-data i databasen

Hvis du nogensinde har kørt DBCC CHECKDB, ved du, at det tager noget tid for store databaser.Nu hvor du kender alle de trin, der køres, kan du se, hvorfor det tager tid at gennemføre.

Hvordan kan SQL Server DBCC CHECKDB hjælpe mig?

Datakorruption er slemt. Det kan forårsage alle mulige problemer i databasen, der kan omfatte ukorrekte dataresultater, mislykkede SQL-angivelser og i nogle tilfælde kan det ødelægge hele SQL-instansen. DBCC CHECKDB advarer dig om korruption, så du kan rette det, før det (forhåbentlig) bliver for slemt.

Hvordan bruger jeg SQL Server DBCC CHECKDB?

DBCC CHECKDB er ret ligetil. Der er et par muligheder, du kan bruge med erklæringen, og vi vil gennemgå nogle af dem i næste afsnit, men den grundlæggende syntaks ser således ud:

DBCC CHECKDB ('DatabaseName') 

Ganske simpelt.

Automatiser SQL Server DBCC CHECKDB

Du ønsker naturligvis ikke at logge ind hver morgen og køre denne erklæring på hver database, så du kan automatisere denne proces ved hjælp af et par forskellige metoder:

• SQL Server Vedligeholdelsesplaner – Vedligeholdelsesplaner er en del af SQL Server out of the box (medmindre du kører ExpressEdition). Jeg bryder mig for det meste ikke om at bruge vedligeholdelsesplaner, men jeg har ikke noget imod at bruge dem til denne type opgave. I værktøjskassen Maintenance Plan toolbox skal du bruge opgaven Check Database Integrity. Den eneste konfigurerbare mulighed er at inkludere indekser, så det er ikke særlig brugervenligt, men i nogle tilfælde er det alt, hvad du har brug for. Igen, vi vil tale om andre muligheder i næste afsnit.

• Brugerdefinerede scripts – Brugerdefinerede scripts er normalt det, jeg bruger, og giver den bedste fleksibilitet med hensyn til at tilføje de muligheder, du ønsker. Mine go-toscripts er allerede oprettet og gratis at bruge fraOla Hallengren. Han har gjort et fantastisk stykke arbejde med at skabe disse og dele dem med verden. TakOla!
• Kig på scripts på MSSQLTips.com:
• Udfør vedligeholdelse med SQL Server-databaser i Full Recovery-tilstand
• SQL Server Database Maintenance Plans and Backup File Management
• Udfør SQL Server Maintenance with No Maintenance Window

SQL Server DBCC CHECKDB Options

Der er et par muligheder at bruge med DBCC CHECKDB, og jeg vil gennemgå et par af de mere populære af dem her:

• NOINDEX – Angiver, at der ikke skal udføres intensive kontroller af ikke-clusteredindexes for brugertabeller. Dette mindsker den overordnede udførelsestid. NOINDEX påvirker ikke systemtabeller, da integritetskontroller altid udføres på indekser til systemtabeller.
• NO_INFOMSGS – Undertrykker alle informationsmeddelelser.
• PHYSICAL_ONLY – Begrænser kontrollen til integriteten af den fysiske struktur af side- og recordoverskrifter og databasens allokeringskonsistens. Denne kontrol er designet til at give en lille overheadkontrol af databasens fysiske konsistens, men den kan også opdage revnede sider, fejl i checksummen og almindelige hardwarefejl, der kan kompromittere en brugers data.
• TABLOCK – Får DBCC CHECKDB til at indhente låse i stedet for at bruge et internt snapshot af databasen. Dette omfatter en kortvarig eksklusiv (X)lås på databasen. TABLOCK får DBCC CHECKDB til at køre hurtigere på en database under stor belastning, men reducerer den samtidighed, der er tilgængelig på databasen, mensDBCC CHECKDB kører.
• DATA_PURITY – Får DBCC CHECKDB til at kontrollere databasen for kolonneværdier, der ikke er gyldige eller uden for intervallet. DBCC CHECKDB opdager f.eks. kolonner med dato- og tidsværdier, der er større end eller mindre end det acceptable område for datatypen datetime, eller kolonner af typen decimal- eller tilnærmet-numerisk data med skala- eller præcisionsværdier, der ikke er gyldige.

Vi gennemgår nogle af mulighederne for REPARATION i et andet afsnit nedenfor.

Hvor ofte skal jeg kontrollere for SQL Server-korruption?

Hvert minut af hver dag. Det var bare for sjov.

Hvis du har et dagligt vedligeholdelsesvindue, ville det være rart at kontrollere for datakorruption dagligt. Jo hurtigere du kan fange det, jo mindre skade kan det gøre. Jeg har bemærket en lotof folk køre dette i weekenden især med større databaser. Der er ikke noget rigtigt eller forkert ved dette, bare sørg for at få det planlagt med jævne mellemrum.

Har jeg brug for at køre DBCC CHECKDB i mit produktionsmiljø?

Nej, godt nok Ja. På en måde.

For at kontrollere for datakorruption nytter det ikke noget at køre DBCC CHECKDB på dit testmiljø…MEDMINDRE du ikke gendanner en kopi af dit produktionsmiljø til test og derefter kører det. BRILLIANT!

Du stiller måske spørgsmålstegn ved, om nogle HA-muligheder er egnede, såsom AlwaysOn, LogShipping osv. Nej, du skal tjekke dit produktionsmiljø *live*.

Nu når DBCC CHECKDB er konfigureret og kører, hvad skal jeg så kigge efter?

Godt tillykke! Du har fået DBCC CHECKDB automatiseret og kørt, men hvad nu? Hvis du har enSQL ServerAgent Job setup, så sørg for at du setupDatabase Mail, en operatør og en notifikation på jobbet. Hvis jobbet lykkes, så fortsæt med din smukke dag. Hvis jobbet mislykkes, har vi noget arbejde at gøre.

Du kan se en fejl som denne:

eller dette:

Først skal du ikke gå i panik. For det andet skal du kontrollere sikkerhedskopier. DBCC CHECKDB-fejl fortæller dig normalt, hvad der skal gøres.

For den første fejl vil en DBCC UPDATEUSAGE korrigere de unøjagtigheder i side- og rækkeantallet i katalogvisningerne. Det er ret harmløst.

Den anden fejl rapporterer om datakorruption. Fejlen nævner, at der skal anvendes repair_allow_data_loss som det mindste reparationsniveau. Det betyder, at du kan køre erklæringen med dette argument,men du kan miste data. Det er derfor, at jeg altid anbefaler at gendanne til en sikkerhedskopi, hvis du kan. Du skal sikre dig, at sikkerhedskopien ikke indeholder beskadigede data, og du vil sikre dig, at der ikke er noget datatab.

Sådan reparerer du en SQL Server-database

Hvis du ikke har en sikkerhedskopi, skal vi muligvis bruge DBCC CHECKDB med en reparationsindstilling.Her er de reparationsindstillinger, der er tilgængelige at bruge. Disse virker måske eller måske ikke og skal bruges som en sidste udvej:

• REPAIR_ALLOW_DATA_LOSS – Forsøger at reparere alle rapporterede fejl.Disse reparationer kan medføre et vist tab af data.
• REPAIR_REBUILD – Udfører reparationer, der ikke har nogen mulighed for tab af data. Dette kan omfatte hurtige reparationer, f.eks. reparation af manglende rækker i ikke-clusterede indekser, og mere tidskrævende reparationer, f.eks. genopbygning af et indeks.

Som jeg sagde ovenfor, er det meget vigtigt at have op til datobackups for at genoprette efter korruption. Korruption er ligeglad med hvor mange data du har, hvilken version af SQL du kører, eller hvor fancy dit datacenter er.

Jeg har det ret godt med dette, men hvad kan jeg ellers bruge til at beskytte mine SQL-instanser?

DBCC CHECKDB bør køres på alle SQL-instanser, du har, men der er et par andre måder, der kan hjælpe med at opdage/forebygge datakorruption.

• SQL Server Agent Alerts – Brian Kelley skrev et godt tip om dette emneher.
• Sideverifikation – Sørg for, at dine databaser brugerCHECKSUM sideverifikation. Hvis du stadig kører SQL 2005 eller lavere, er dette ikke tilgængeligt, men når du opgraderer, skal du sørge for at ændre denne indstilling. For at se sideverificeringsindstillingerne skal du bruge følgende erklæring:

select name, page_verify_option_desc from sys.databases 

Næste trin

• Sørg for at tjekkeMSDN Library for mere dybdegående oplysninger om DBCC CHECKDB
• MSSQLTips.com har en fin samling af tips omDatabase Consistency Checks, som også kan være nyttige.

Sidst opdateret: 2016-07-26

Om forfatteren

Brady Upton er databaseadministrator og SharePoint-superstjerne i Nashville, TN.
Se alle mine tips

Relaterede ressourcer

• Mere SQL Server DBA-tips…