SQL Server DBCC CHECKDB-databaseverktøy Her er når og hvordan du bruker databaseverktøyet for SQL Server DBCC CHECKDB som dekker alternativene REPAIR_ALLOW_DATA_LOSS, REPAIR_REBUILD, TABLOCK, ESTIMATEONLY, PHYSICAL_ONLY og MAXDOP.
Hei, jeg heter Kirk. Jeg er senior avdelingsingeniør og jobber med GSE-teamet. Denne videoen handler om å se på Microsoft SQL Server TSQL-databaseverktøyet, DBCC CHECKDB. Vi diskuterer hvorfor og når DBCC CHECKDB skal kjøres, sammen med kommandoalternativer som bestemmer nivået på databasekontroll og kjøretid involvert.
Vi skal ta for oss noen punkter før demonstrasjonen. DBCC CHECKDB er et TSQL-verktøy som ser på den logiske og fysiske integriteten til alle objektene i en gitt SQL-serverdatabase. Vi har noen reparasjonsalternativer som også er tilgjengelige, og vi har noe som heter "TABLOCK" i tillegg som innebærer bruk eller ikke-bruk av et øyeblikksbilde av databasen. Vi skal se på alternativet "ESTIMATEONLY", hvorfor vi ønsker å bruke det, og det er i forhold til "TEMPDB" -bruk under en CHECKDB-prosess.
Vi skal også se på "PHYSICAL_ONLY", hvorfor vi ønsker å bruke det alternativet og når. Og vi skal også se på hvordan vi kan kontrollere antall prosessorer som er involvert i CHECKDB-prosessen med noe som kalles "MAXDOP". Nå skal vi se på noen av eksemplene på hva vi ser når vi kjører DBCC CHECKDB. Så den første kommandoen selv vil bokstavelig talt sjekke alt som er mulig for DBCC CHECKDB å se på i en gitt database.
Her er resultatene. Den avkastningslinjen vi er mest interessert i når vi kjører dette, er antallet "tildelingsfeil" og "konsistensfeil" som finnes i databasen. Så jeg har en sunn "AdventureWorks2019" -database, så alt kommer tilbake uten feil. Dette er en liten database, så kjøretiden er rask. Hvis vi har en mye større database, en database for eksempel 100 ganger størrelsen på denne, vil det ta mye lengre tid å kjøre denne.
Og mange lurer på hvor ofte vi skal prøve å kjøre DBCC CHECKDB, og vanligvis vil SQL-mesterne fortelle deg at du vil prøve å kjøre den så snart som mulig. Hvis det er uoverensstemmelser eller noen form for programvareskade i databasen, vil du oppdage det så raskt som mulig og håndtere det. Det neste alternativet vi skal se på, er det som heter "MED PHYSICAL_ONLY".
Det er den samme kommandoen, bortsett fra at den i dette tilfellet bokstavelig talt bare sjekker den fysiske enheten eller strukturen til selve databasen. Det vil vanligvis kjøre mye raskere enn en full sjekk, og det er derfor vi ønsker å kjøre dette i produksjonsmiljøer der vi har begrensninger på vedlikeholdstidene våre. Vi har også et annet alternativ som heter "WITH TABLOCK", så en ting vi trenger å forstå om DBCC CHECKDB, en av de første tingene den gjør er at den lager en øyeblikksbildefil som finnes i "TEMPDB" -databasen, og det er tider når vi kanskje ikke kan bruke "TEMPDB" til noe sånt med en CHECKDB-prosess.
Så uansett hva vi betegner "WITH TABLOCK", forteller vi DBCC CHECKDB om ikke å opprette en øyeblikksbildefil, så den kommer ikke til å oppta den plassen i "TEMPDB", og den vil vanligvis kjøre raskere som et resultat av det. En av de andre tingene vi kan kjøre som et alternativ er "MED ESTIMATEONLY". Denne spesielle kommandoen vil fortelle oss hvor mye plass vi forventer å ha brukt i vår "TEMPDB" -database når vi kjører CHECKDB.
Og her er et eksempel på utgangen av det, det kommer tilbake i kilobyte, så dette er rundt 230 megabyte. Et annet alternativ er «WITH MAXDOP». Uansett hvilken DBCC CHECKDB som kjører, prøver den å bruke så mange prosessorer som den trenger for å kjøre parallelt. Den ønsker å kjøre flere tråder for å prøve å utføre så raskt som mulig. Så det kan være begrensninger med hensyn til antall prosessorer vi ønsker å tillate å kjøre i denne prosessen, slik at vi kan begrense det med "WITH MAXDOP"-setningen.
I dette tilfellet forteller jeg SQL å bare bruke en prosessor for våre CHECKDB kjøre. Og når vi gjør det, er det mindre prosessorer dedikert til dette, men det vil vanligvis ta lengre tid å kjøre DBCC CHECKDB. La oss ta en titt på reparasjonsalternativene. Vi har ulike reparasjonsalternativer. Det mest drastiske alternativet heter «REPAIR_ALLOW_DATA_LOSS». Du kan bokstavelig talt miste data når vi bruker dette alternativet for å prøve å reparere en database som kommer tilbake med feil. Vi kan også bruke «REPAIR_REBUILD».
REPAIR_REBUILD regnes som et mykt reparasjonsalternativ, og det vi mener med det er at det garanterer at vi ikke kommer til å miste tilgjengelige data i databasen når vi kjører dette. Slik denne kommandoen er lagt opp, bruker vi konteksten til "Master"-databasen. Hver gang vi gjør noe slikt, må vi sette databasen i "SINGLE_USER" -modus for å tillate en reparasjonsoperasjon. I dette tilfellet kjører vi det alternativet.
Nå har vi valget "ESTIMATEONLY", og nok en gang vil "ESTIMATEONLY" fortelle oss hvor mye plass vi skal gi opp i "TEMPDB" for å gjøre dette. Vår øyeblikksbildefil kommer til å oppta rundt 230 megabyte, basert på vår retur her. Og etter å ha utført en reparasjon med dette, vil vi sette den tilbake i "MULTI_USER" -modus. Nå, med "ESTIMATEONLY" kjørte vi faktisk ikke reparasjonen, vi gjorde bare estimatet. Så la oss ta en titt på å kjøre kommandoen med "REPAIR_REBUILD".
La oss igjen gå og "utføre" det, vi skal sette det tilbake i "MULTI_USER". Så igjen, i sammenheng med "Master"-databasen, skal vi sette den i "SINGLE_USER"-modus. Og i dette tilfellet kjører vi en reparasjonsoperasjon. Dette er det lettere reparasjonsalternativet. Og det du kommer til å se er mye av det vi vil se i en vanlig DB-sjekk, og selvfølgelig, nok en gang, vil vi se etter rapporterte feil. I dette tilfellet er det ingen feil.
Jeg har en god database her. Den siste delen av denne operasjonen er å sette den tilbake i "MULTI_USER"-modus. Reparasjonskommandoen "REPAIR_ALLOW_DATA_LOSS" er nøyaktig lik "REPAIR_REBUILD", bortsett fra at vi bruker "REPAIR_ALLOW_DATA_LOSS". Vi kjører dette vanligvis når vi har forsøkt å kjøre "REPAIR_REBUILD", og "REPAIR_REBUILD" kommer tilbake og forteller oss at den ikke kunne fullføre reparasjonen av databasen.
Så, vår siste utvei uten en god sikkerhetskopi, og ja, vi bør bruke en god sikkerhetskopi før vi blir tvunget til å gjøre en "REPAIR_ALLOW_DATA_LOSS". Hvis det ikke finnes noen sikkerhetskopi, er dette vårt eneste alternativ for å få databasen tilbake på nett og tilgjengelig. Så det avslutter vår demo av å diskutere DBCC CHECKDB, vurderer når du skal bruke CHECKDB, og noen av de vanligste kommandoalternativene som er tilgjengelige. Jeg håper denne videoen hjalp deg med å forstå verdien av å bruke DBCC CHECKDB når du prøver å opprettholde en konsekvent, stabil SQL-serverdatabaseinstallasjon.
Takk for at du så på.