Hej, jeg hedder Kirk. Jeg er Senior Principal Engineer og arbejder i GSE-teamet. Denne video omhandler Microsoft SQL Server TSQL-databaseværktøjet DBCC CHECKDB. Vi diskuterer, hvorfor og hvornår DBCC CHECKDB skal køres, sammen med kommandoindstillinger, der bestemmer niveauet for databasekontrol og kørselstid, der er involveret.
Først et par punkter, som vi gerne vil gennemgå, før vi kommer til demoen. DBCC CHECKDB er et TSQL-værktøj, der ser på den logiske og fysiske integritet af alle objekter i en given SQL-serverdatabase. Vi har nogle reparationsmuligheder, der også er tilgængelige, og vi har også noget, der hedder "TABLOCK" som en mulighed, der involverer brug eller ikke-brug af et øjebliksbillede af databasen. Vi skal se på indstillingen "ESTIMATEONLY", hvorfor vi vil bruge den, og det er i forhold til "TEMPDB" -brug under en CHECKDB-proces.
Vi vil også se på "PHYSICAL_ONLY", hvorfor vi vil bruge denne mulighed, og hvornår. Og vi vil også se på, hvordan vi kan kontrollere antallet af processorer, der er involveret i CHECKDB-processen med noget, der hedder "MAXDOP". Så på dette tidspunkt vil vi se på nogle af eksemplerne på, hvad vi ville se, når vi kører DBCC CHECKDB. Så den første kommando selv vil bogstaveligt talt kontrollere alt, hvad der er muligt for DBCC CHECKDB at se på inden for en given database.
Her ses resultaterne. Den returlinje, vi er mest interesseret i, når vi kører den, er antallet af "allokeringsfejl" og "konsistensfejl", der findes i databasen. Så jeg har en sund "AdventureWorks2019" database, så alt kommer tilbage uden fejl. Dette også en lille database, så det kører virkelig hurtigt. Hvis vi har en meget større database, en database for eksempel 100 gange størrelsen af denne, vil det tage meget længere tid at køre denne.
Og mange mennesker spekulerer på, hvor ofte vi skal prøve at køre DBCC CHECKDB, og normalt vil SQL-masterne fortælle dig, at du vil prøve at køre det så hurtigt som muligt. Hvis der er uoverensstemmelser eller nogen form for softwareskade i databasen, vil du opdage det så hurtigt som muligt og håndtere det. Så den næste mulighed, vi skal se på, er den, der hedder "MED PHYSICAL_ONLY".
Det er den samme kommando, bortset fra i dette tilfælde kontrollerer det bogstaveligt talt kun den fysiske enhed eller selve databasens struktur. Det vil normalt køre meget hurtigere end en fuld kontrol, og derfor vil vi gerne køre dette i produktionsmiljøer, hvor vi har begrænsninger på vores vedligeholdelsestider. Vi har også en anden mulighed kaldet "MED TABLOCK", så en ting, vi har brug for at forstå om DBCC CHECKDB, en af de første ting, den gør, er, at den opretter en snapshot-fil, der er indeholdt i "TEMPDB" -databasen, og der er tidspunkter, hvor vi muligvis ikke kan bruge "TEMPDB" til noget lignende med en CHECKDB-proces.
Så uanset hvad vi angiver "MED TABLOCK", fortæller vi DBCC CHECKDB ikke at oprette en snapshot-fil, så den vil ikke optage den plads i "TEMPDB", og den vil normalt køre hurtigere som følge af det. En af de andre ting, vi kan køre som en mulighed, er "WITH ESTIMATEONLY". Denne særlige kommando fortæller os, hvor meget plads vi ville forvente at have brugt i vores "TEMPDB" -database, når vi kører CHECKDB.
Og her er et eksempel på outputtet af det, det kommer tilbage i kilobyte, så dette er omkring 230 megabyte. En anden mulighed, vi har, er "WITH MAXDOP". Uanset hvad DBCC CHECKDB kører, forsøger den nu at bruge så mange processorer, som den har brug for for at køre parallelt. Det ønsker at køre flere tråde for at forsøge at udføre så hurtigt som muligt. Så der kan være begrænsninger med hensyn til antallet af processorer, vi gerne vil tillade kørt i denne proces, så vi kan begrænse det med "MED MAXDOP"-erklæringen.
I dette tilfælde beder jeg SQL om kun at bruge én processor til vores CHECKDB-kørsel. Og når vi gør det, er det færre processorer dedikeret til dette, men det vil normalt tage længere tid at køre din DBCC CHECKDB. Lad os nu se nærmere på reparationsmulighederne. Der er forskellige reparationsmuligheder. Den mest drastiske kaldes "REPAIR_ALLOW_DATA_LOSS". Du kan bogstaveligt talt miste data, når vi bruger denne mulighed til at forsøge at reparere en database, der kommer tilbage med fejl. Vi kan også bruge "REPAIR_REBUILD".
REPAIR_REBUILD betragtes som en blød reparationsmulighed, og hvad vi mener med det er, at det garanterer, at vi ikke mister tilgængelige data i databasen, når vi kører dette. Så som denne kommando er lagt ud, bruger vi konteksten for "Master" -databasen. Når vi gør noget som dette, skal vi sætte databasen i "SINGLE_USER" -tilstand for at tillade en reparationsoperation. I dette tilfælde kører vi den.
Nu har vi her muligheden for "ESTIMATEONLY", og endnu en gang vil "ESTIMATEONLY" fortælle os, hvor meget plads vi vil opgive i "TEMPDB" for at gøre dette. Vores snapshot-fil kommer til at optage omkring 230 megabyte, baseret på vores tilbagevenden her. Og efter at have udført en reparation med dette, vil vi gerne sætte det tilbage i "MULTI_USER" -tilstand. Nu, med "ESTIMATEONLY", kørte vi faktisk ikke reparationen, vi foretog kun estimatet. Så lad os se på at køre kommandoen med "REPAIR_REBUILD".
Lad os igen gå og "Udfør" det, vi sætter det tilbage i "MULTI_USER". Så endnu en gang, i forbindelse med "Master" -databasen, vil vi sætte den i "SINGLE_USER" -tilstand. Og i dette tilfælde udfører vi en reparationshandling. Dette er den bløde reparationshandling. Og det, du kommer til at se, er meget af det, vi ville se i en almindelig DB-kontrol, og selvfølgelig vil vi endnu en gang kontrollere for rapporterede fejl. I dette tilfælde er der heller ikke nogen.
Jeg har en god database her. Og den sidste del af denne operation sætter den tilbage i "MULTI_USER" -tilstand. Dvs. reparationskommandoen "REPAIR_ALLOW_DATA_LOSS", det er præcis som "REPAIR_REBUILD", bortset fra at vi bruger "REPAIR_ALLOW_DATA_LOSS". Normalt kører vi dette, når vi har forsøgt at køre "REPAIR_REBUILD", og "REPAIR_REBUILD" kommer tilbage og fortæller os, at det ikke kunne fuldføre reparationen af databasen.
Så vores sidste udvej uden en god backup, og ja, vi bør bruge en god backup, før vi er tvunget til at lave en "REPAIR_ALLOW_DATA_LOSS". Hvis der ikke findes en sikkerhedskopi, er dette vores eneste mulighed for at få databasen online igen og tilgængelig. Så det afslutter vores demo med at diskutere DBCC CHECKDB, overveje, hvornår man skal bruge CHECKDB og nogle af de mest almindelige kommandoindstillinger, der er tilgængelige. Jeg håber, at denne video hjalp dig med at forstå værdien af at bruge DBCC CHECKDB, når du forsøger at opretholde en ensartet, stabil SQL Server-databaseinstallation.
Tak, fordi du så med.
