Witam, nazywam się Kirk. Jestem starszym inżynierem głównym w zespole GSE. Ten film jest poświęcony narzędziu bazy danych Microsoft SQL Server TSQL, DBCC CHECKDB. Omówimy, dlaczego i kiedy należy uruchomić DBCC CHECKDB, wraz z opcjami poleceń, które określają poziom sprawdzania bazy danych i związane z tym środowisko uruchomieniowe.
Przed przejściem do demonstracji chcielibyśmy omówić kilka kwestii. DBCC CHECKDB to narzędzie TSQL sprawdzające logiczną i fizyczną integralność wszystkich obiektów w danej bazie danych serwera SQL. Mamy kilka opcji naprawy, które również są dostępne, a także coś, co nazywa się "TABLOCK" jako opcja, która obejmuje użycie lub nieużycie migawki bazy danych. Przyjrzymy się opcji "ESTIMATEONLY", dlaczego chcielibyśmy jej użyć, i jest to związane z użyciem "TEMPDB" podczas procesu CHECKDB.
Przyjrzymy się również "PHYSICAL_ONLY", dlaczego i kiedy chcemy korzystać z tej opcji. Przyjrzymy się również, w jaki sposób możemy kontrolować liczbę procesorów zaangażowanych w proces CHECKDB za pomocą czegoś, co nazywa się "MAXDOP". W tym miejscu przyjrzymy się kilku przykładom tego, co możemy zobaczyć po uruchomieniu DBCC CHECKDB. Tak więc samo pierwsze polecenie dosłownie sprawdzi wszystko, co jest możliwe do przejrzenia przez DBCC CHECKDB w danej bazie danych.
Oto wyniki. Wiersz zwrotu, który najbardziej nas interesuje, gdy go uruchamiamy, to liczba "błędów alokacji" i "błędów spójności" znalezionych w bazie danych. Mam więc sprawną bazę danych "AdventureWorks2019", więc wszystko wraca bez błędów. Jest to mała baza danych, więc proces jest bardzo szybki. Jeśli mamy znacznie większą bazę danych, na przykład 100 razy większą od tej, uruchomienie jej zajmie znacznie więcej czasu.
Wiele osób zastanawia się, jak często powinniśmy próbować uruchamiać DBCC CHECKDB, a zazwyczaj mistrzowie SQL powiedzą ci, że chcesz spróbować uruchomić go tak szybko, jak to możliwe. Jeśli w bazie danych występują jakiekolwiek niespójności lub uszkodzenia oprogramowania, chcesz to jak najszybciej odkryć i sobie z tym poradzić. Następną opcją, której się przyjrzymy, jest opcja o nazwie "Z PHYSICAL_ONLY".
Jest to to samo polecenie, z tą różnicą, że w tym przypadku dosłownie sprawdza tylko fizyczną jednostkę lub strukturę samej bazy danych. Zwykle będzie działać znacznie szybciej niż pełne sprawdzenie, dlatego chcielibyśmy uruchomić go w środowiskach produkcyjnych, w których mamy ograniczenia dotyczące czasu konserwacji. Mamy również inną opcję o nazwie "WITH TABLOCK", więc jedną rzeczą, którą musimy zrozumieć na temat DBCC CHECKDB, jedną z pierwszych rzeczy, które robi, jest tworzenie pliku migawki, który jest zawarty w bazie danych "TEMPDB", i są chwile, kiedy możemy nie być w stanie użyć "TEMPDB" do czegoś takiego z procesem CHECKDB.
Tak więc, niezależnie od tego, co oznaczymy jako "WITH TABLOCK", mówimy DBCC CHECKDB, aby nie tworzył pliku migawki, więc nie zajmie on tego miejsca w "TEMPDB" i zwykle będzie działał szybciej w wyniku tego. Jedną z innych rzeczy, które możemy uruchomić jako opcję, jest "With ESTIMATEONLY". To konkretne polecenie powie nam, ile miejsca powinniśmy wykorzystać w naszej bazie danych "TEMPDB" podczas uruchamiania CHECKDB.
A oto przykład wyniku w kilobajtach, czyli około 230 megabajtów. Kolejną opcją jest „WITH MAXDOP”. Teraz, niezależnie od tego, co DBCC CHECKDB uruchomi, stara się używać tylu procesorów, ile potrzebuje do równoległego działania. Chce uruchomić wiele wątków, aby spróbować wykonać je tak szybko, jak to możliwe. W związku z tym mogą istnieć ograniczenia co do liczby procesorów, które chcielibyśmy dopuścić do uruchomienia w tym procesie, więc możemy to ograniczyć za pomocą instrukcji "WITH MAXDOP".
W tym przypadku mówię SQL, aby używał tylko jednego procesora do uruchamiania CHECKDB. A kiedy to robimy, mniej procesorów jest do tego dedykowanych, ale zwykle uruchomienie DBCC CHECKDB trwa dłużej. Przejdźmy dalej i przyjrzyjmy się opcjom naprawy. Istnieją różne opcje naprawy. Najbardziej drastyczną nazywamy „REPAIR_ALLOW_DATA_LOSS”. Dosłownie możesz utracić dane za każdym razem, gdy użyjemy tej opcji, aby spróbować naprawić bazę danych, która wraca z błędami. Można też użyć opcji „REPAIR_REBUILD”.
REPAIR_REBUILD jest uważana za opcję miękkiej naprawy i rozumiemy przez to, że gwarantuje, że nie utracimy dostępnych danych w bazie danych, gdy ją uruchomimy. Układ tego polecenia będzie zatem taki, że będziemy używać kontekstu bazy danych "Master". Za każdym razem, gdy robimy coś takiego, musimy przełączyć bazę danych w tryb "SINGLE_USER", aby umożliwić operację naprawy. W tym przypadku uruchomimy to.
Teraz mamy tutaj opcję "ESTIMATEONLY" i po raz kolejny "ESTIMATEONLY" powie nam, ile miejsca zamierzamy poświęcić w "TEMPDB", aby to zrobić. Nasz plik migawki zajmie około 230 megabajtów. Po wykonaniu naprawy za pomocą tego urządzenia chcielibyśmy przełączyć go z powrotem w tryb "MULTI_USER". W przypadku polecenia "ESTIMATEONLY" nie przeprowadziliśmy naprawy, a jedynie kosztorys. Przyjrzyjmy się więc uruchamianiu polecenia za pomocą polecenia "REPAIR_REBUILD".
Jeszcze raz, przejdźmy i "Execute" to umieścimy z powrotem w "MULTI_USER". Tak więc po raz kolejny, w kontekście bazy danych "Master", umieścimy ją w trybie "SINGLE_USER". W tym przypadku wykonamy operację naprawy. Jest to operacja miękkiej naprawy. To, co zobaczycie, to wiele z tego, co możemy zobaczyć podczas zwykłego sprawdzania bazy danych. Oczywiście, po raz kolejny, chcemy sprawdzić zgłoszone błędy. Znów nie ma żadnego.
Mam tu dobrą bazę danych. Ostatnią częścią tej operacji jest przełączenie go z powrotem w tryb "MULTI_USER". Polecenie naprawy "REPAIR_ALLOW_DATA_LOSS" działa dokładnie tak samo jak polecenie "REPAIR_REBUILD", z tą różnicą, że używamy "REPAIR_ALLOW_DATA_LOSS". Zazwyczaj uruchamiamy go, gdy próbujemy uruchomić "REPAIR_REBUILD", a "REPAIR_REBUILD" wraca i informuje nas, że nie można ukończyć naprawy bazy danych.
Tak więc nasza ostatnia deska ratunku bez dobrej kopii zapasowej i tak, powinniśmy użyć dobrej kopii zapasowej, zanim będziemy zmuszeni do zrobienia "REPAIR_ALLOW_DATA_LOSS". Jeśli kopia zapasowa nie istnieje, jest to nasza jedyna opcja, aby przywrócić bazę danych do trybu online i udostępnić. Na tym kończy się prezentacja omawiania DBCC CHECKDB, rozważań, kiedy używać CHECKDB oraz niektórych z najczęściej spotykanych dostępnych opcji poleceń. Mam nadzieję, że ten film pomógł Ci zrozumieć wartość korzystania z DBCC CHECKDB podczas próby utrzymania spójnej, stabilnej instalacji bazy danych serwera SQL.
Dziękuję za uwagę.