Hei, nimeni on Kirk. Olen GSE-tiimin Senior Principal Engineer. Tässä videossa tutustutaan Microsoft SQL -palvelimen TSQL-tietokantatyökaluun DBCC CHECKDB. Keskustelemme siitä, miksi ja milloin DBCC CHECKDB on suoritettava, sekä komentovaihtoehdoista, jotka määrittävät tietokannan tarkistuksen tason ja suoritusajan.
Käydään läpi pari seikkaa ennen itse esittelyä. DBCC CHECKDB on TSQL-työkalu, joka tarkastelee tietyn tietyn SQL server tietokannan kaikkien objektien loogista ja fyysistä eheyttä. Meillä on myös joitain korjausvaihtoehtoja, jotka ovat myös käytettävissä, ja meillä on myös vaihtoehto "TABLOCK", johon liittyy tietokannan tilannekuvan käyttö tai käyttämättä jättäminen. Aiomme tarkastella "ESTIMATEONLY" -vaihtoehtoa, miksi haluamme käyttää sitä, ja se liittyy "TEMPDB" -käyttöön CHECKDB-prosessin aikana.
Tarkastelemme myös kohtaa PHYSICAL_ONLY, miksi sitä halutaan käyttää ja milloin. Tarkastelemme myös, miten voimme hallita CHECKDB-prosessiin osallistuvien prosessorien määrää MAXDOP-nimisellä tavalla. Tässä osassa katsotaan muutamia esimerkkejä siitä, mitä näkisi, kun DBCC CHECKDB suoritetaan. Joten ensimmäinen komento itse tarkistaa kirjaimellisesti kaiken, mitä DBCC CHECKDB voi tarkastella tietyssä tietokannassa.
Tulokset ovat tässä. Kun suoritamme tämän, meitä kiinnostaa eniten tietokannasta löytyneiden kohdistus- ja yhtenäisyysvirheiden määrä. Joten minulla on terve "AdventureWorks2019" -tietokanta, joten kaikki palaa ilman virheitä. Lisäksi tietokanta on pieni, joten suorittaminen on nopeaa. Jos meillä on paljon suurempi tietokanta, esimerkiksi 100 kertaa tämän kokoinen tietokanta, tämän suorittaminen kestää paljon kauemmin.
Ja monet ihmiset ihmettelevät, kuinka usein meidän pitäisi yrittää suorittaa DBCC CHECKDB, ja yleensä SQL-mestarit kertovat sinulle, että haluat yrittää suorittaa sen mahdollisimman pian. Jos tietokannassa on epäjohdonmukaisuuksia tai minkäänlaisia ohjelmistovaurioita, haluat selvittää sen mahdollisimman nopeasti ja käsitellä sen. Joten seuraava vaihtoehto, jota aiomme tarkastella, on nimeltään "WITH PHYSICAL_ONLY".
Se on sama komento, paitsi tässä tapauksessa se kirjaimellisesti vain tarkistaa fyysisen kokonaisuuden tai itse tietokannan rakenteen. Se suoritetaan yleensä paljon nopeammin kuin täysi tarkistus, ja siksi haluamme suorittaa sen tuotantoympäristöissä, joissa ylläpitoaikoja on rajoitettu. Meillä on myös toinen vaihtoehto nimeltä "TABLOCKin kanssa", joten yksi asia, joka meidän on ymmärrettävä DBCC CHECKDB: stä, yksi ensimmäisistä asioista, joita se tekee, on se, että se luo tilannekuvatiedoston, joka sisältyy "TEMPDB" -tietokantaan, ja on aikoja, jolloin emme ehkä voi käyttää "TEMPDB: tä" jotain sellaista CHECKDB-prosessilla.
Joten riippumatta siitä, mitä nimeämme "TABLOCKilla", sanomme DBCC CHECKDB: lle, ettei se luo tilannevedostiedostoa, joten se ei vie tätä tilaa "TEMPDB": ssä ja se yleensä toimii nopeammin sen seurauksena. Yksi vaihtoehtoisista toiminnoista on ESTIMATEONLY. Tämä nimenomainen komento kertoo, kuinka paljon tilaa odotamme käyttäneemme TEMPDB-tietokannassamme, kun suoritat CHECKDB:n.
Ja tässä on esimerkki siitä, että se tulee takaisin kilotavuina, joten tämä on noin 230 megatavua. Eräs toinen vaihtoehto on WITH MAXDOP. Riippumatta siitä, mitä DBCC CHECKDB suorittaa, se yrittää käyttää niin monta prosessoria kuin se tarvitsee toimiakseen rinnakkain. Se haluaa suorittaa useita säikeitä yrittääkseen suorittaa mahdollisimman nopeasti. Tässä prosessissa käytettävien prosessorien määrää voi siis olla rajoitettu, joten sitä voi rajoittaa MAXDOP-komennolla.
Tässä tapauksessa käsken SQL: ää käyttämään vain yhtä prosessoria CHECKDB-ajoon. Ja kun teemme niin, siihen on omistettu vähemmän prosessoreita, mutta DBCC CHECKDB: n suorittaminen kestää yleensä kauemmin. Tarkastellaan seuraavaksi korjausvaihtoehtoja. Korjausvaihtoehtoja on useita. Niistä radikaalein on REPAIR_ALLOW_DATA_LOSS. Saatat kirjaimellisesti menettää tietoja aina, kun yritämme korjata virheitä sisältävän tietokannan tämän vaihtoehdon avulla. Toinen vaihtoehto on REPAIR_REBUILD.
REPAIR_REBUILD pidetään pehmeänä korjausvaihtoehtona, ja tarkoitamme tällä sitä, että se takaa, että emme menetä tietokannassa olevia tietoja, kun suoritamme tämän. Komennon asettelussa käytetään Master-tietokannan kontekstia. Aina kun teemme jotain tällaista, meidän on asetettava tietokanta "SINGLE_USER" -tilaan korjaustoiminnon mahdollistamiseksi. Suoritetaan tämä.
Nyt meillä on vaihtoehto "ESTIMATEONLY", ja jälleen kerran "ESTIMATEONLY" kertoo meille, kuinka paljon tilaa aiomme luopua "TEMPDB": ssä tehdäksemme tämän. Tilannekuvatiedostomme vie noin 230 megatavua tänne paluumme perusteella. Ja kun olet tehnyt korjauksen tällä, haluamme laittaa sen takaisin "MULTI_USER" -tilaan. Nyt "ESTIMATEONLY" -toiminnolla emme itse asiassa suorittaneet korjausta, teimme vain arvion. Katsotaanpa komennon suorittamista komennolla REPAIR_REBUILD.
Suoritetaan se vielä kerran, laitetaan se takaisin MULTI_USER. Asetamme Master-tietokannan jälleen kerran SINGLE_USER-tilaan. Suoritetaan tällä kertaa korjaustoiminto. Tämä on varovaisempi korjausvaihtoehto. Ja mitä tulet näkemään, on paljon siitä, mitä näkisimme tavallisessa DB-tarkistuksessa, ja tietysti haluamme jälleen kerran tarkistaa ilmoitetut virheet. Niitä ei taaskaan ole.
Tietokanta on kunnossa. Ja tämän toiminnon viimeinen osa asettaa sen takaisin "MULTI_USER" -tilaan. REPAIR_ALLOW_DATA_LOSS-korjauskomento muistuttaa siis täysin REPAIR_REBUILD-korjausta, paitsi että siinä käytetään REPAIR_ALLOW_DATA_LOSS-komentoa. Yleensä suoritamme tämän, kun REPAIR_REBUILD yritetään suorittaa ja REPAIR_REBUILD tulee takaisin ja ilmoittaa, että tietokannan korjausta ei voitu suorittaa loppuun.
Joten viimeinen keino ilman hyvää varmuuskopiointia, ja kyllä, meidän pitäisi käyttää hyvää varmuuskopiointia ennen kuin meidän on pakko tehdä "REPAIR_ALLOW_DATA_LOSS". Jos varmuuskopiota ei ole, tämä on ainoa tapa saada tietokanta takaisin online-tilaan ja käyttöön. Tähän päättyy DBCC CHECKDB:n esittely, jossa pohdittiin, milloin CHECKDB:tä kannattaa käyttää, sekä joitakin yleisimpiä käytettävissä olevia komentovaihtoehtoja. Toivon, että tämä video auttoi sinua ymmärtämään DBCC CHECKDB: n käytön arvon yritettäessä ylläpitää johdonmukaista ja vakaata SQL server tietokanta-asennusta.
Kiitos, että katsoit.
