Wprowadzenie
Regularna konserwacja bazy danych jest ważną częścią pracy administratora bazy danych, która pomaga zapewnić normalne działanie krytycznych systemów. Jednym z najłatwiejszych sposobów na osiągnięcie tego będzie zautomatyzowanie zadań związanych z DBCC CheckDB. Bez względu na używaną wersję SQL Server, nigdy nie będzie bazy danych niewymagającej konserwacji. Będziesz musiał zaplanować regularne konserwacje, aby móc zakryć plecy, szczególnie w czasie rzeczywistej katastrofy.
DBA jest zawsze winowajcą
Za każdym razem, gdy pojawia się problem z bazą danych, wszystkie oczy zwrócone są na DBA. Niezależnie od tego, czy problem został spowodowany przez deszcz, czy też przez jakiegoś programistę piszącego paskudny kod powodujący spowolnienie bazy danych, oczekuje się, że administrator DBA naprawi bałagan. I możesz sobie wyobrazić, z jaką presją musisz sobie poradzić, jeśli zostaniesz poproszony o szybkie przywrócenie bazy danych przy użyciu ostatniej dostępnej kopii zapasowej, która, jak dowiadujesz się w trakcie procesu, nie jest ważna, a integralność bazy danych została naruszona już kilka miesięcy temu. Tutaj leży różnica między proaktywnym DBA a reaktywnym DBA. W rzeczywistości strategia odzyskiwania jest znacznie bardziej krytyczna w porównaniu ze strategią tworzenia kopii zapasowych. Jakiemu celowi mogą służyć codzienne kopie zapasowe baz danych, jeśli nie są one przydatne w czasie przywracania?
Dlaczego konserwacja jest ważna?
Wraz z bezprecedensowym rozwojem technologii baz danych i nowymi funkcjami pojawiającymi się w każdym wydaniu, jako administrator baz danych koniecznie musisz wyprzedzić resztę i upewnić się, że postępujesz zgodnie z najlepszymi praktykami w branży utrzymanie bazy danych.
DBCC CheckDB i jak możemy go uruchomić
DBCC CheckDB – ta nazwa dość opisuje funkcjonalność. Mówiąc prościej, sprawdza bazy danych. Jest to ważne, aby upewnić się, że baza danych działa zgodnie z oczekiwaniami. Zasadniczo DBCC CheckDB sprawdza logiczną i fizyczną integralność wszystkich obiektów w bazie danych. To właśnie robi DBCC CheckDB pod maską według oficjalnego Dokumentacja Microsoft:
Uruchamia DBCC CHECKALLOC w bazie danych – spójność alokacji miejsca na dysku
Uruchamia DBCC CHECKTABLE w każdej tabeli i widoku w bazie danych – jest to integralność wszystkich stron i struktur, które składają się na tabelę lub widok indeksowany.
Uruchamia DBCC CHECKCATALOG w bazie danych – sprawdza spójność katalogu w określonej bazie danych.
Sprawdza zawartość każdego zindeksowanego widoku w bazie danych.
Sprawdza spójność na poziomie łącza między metadanymi tabeli a katalogami/plikami systemu plików podczas przechowywania danych varbinary (max) w systemie plików za pomocą FILESTREAM.
Weryfikuje dane Service Broker w bazie danych.
Kiedy uruchamiasz polecenie DBCC CheckDB jawnie lub przez zadanie, zasadniczo wykonuje wszystkie powyższe.
Uruchamianie DBCC CheckDB bezpośrednio w bazie danych
Możesz uruchomić polecenie DBCC CheckDB bezpośrednio w bazie danych i sprawdzić wyniki. Sprawdź wyjście polecenia, jak pokazano na zrzucie ekranu poniżej. Dane wyjściowe pokazują szczegóły dotyczące wierszy w tabelach oraz liczbę stron używanych przez te wiersze.
Jeśli przyjrzysz się uważnie, zobaczysz więcej szczegółów dotyczących obiektów bazy danych. Na przykład w bazie danych „VLDB” widzę następujący wynik:
“Object ID 1179151246 (object 'Warehouse.ColdRoomTemperatures'): The operation is not supported with memory optimized tables. This object has been skipped and will not be processed.”
Jak pokazują te dane wyjściowe, DBCC CheckDB nie jest obsługiwane w przypadku tabel zoptymalizowanych pod kątem pamięci. Tabele zoptymalizowane pod kątem pamięci zostały po raz pierwszy wprowadzone w programie SQL Server 2014 jako funkcja tylko dla przedsiębiorstw. Jednak z biegiem lat stały się popularną i szeroko rozpowszechnioną funkcją SQL Server.
Zauważysz również, że DBCC Check sprawdził dane brokera usług w bazie danych, jak pokazano poniżej.
“DBCC results for 'VLDB'. Service Broker Msg 9675, State 1: Message Types analyzed: 14. Service Broker Msg 9676, State 1: Service Contracts analyzed: 6. Service Broker Msg 9667, State 1: Services analyzed: 3. Service Broker Msg 9668, State 1: Service Queues analyzed: 3. Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0. Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0. Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0. Service Broker Msg 9605, State 1: Conversation Priorities analyzed: 0.”
Na koniec, po pomyślnym wykonaniu polecenia DBCC CheckDB, zobaczysz następujące dane wyjściowe:
Co się stanie, jeśli po uruchomieniu DBCC CheckDB zostaną zgłoszone błędy?
W powyższym przykładzie widać, że DBCC CheckDB zostało zakończone bez żadnych błędów. Jeśli jednak nie masz tyle szczęścia, możesz natknąć się na błędy spójności – i to będzie czas, kiedy będziesz musiał podjąć kilka krytycznych decyzji. Jeśli natkniesz się na problemy w produkcyjnej bazie danych, najlepiej poinformuj właścicieli firm lub kierownika operacyjnego, aby położyli karty na stole. Możesz albo dać im opcję przywrócenia bazy danych z ostatniej dostępnej kopii zapasowej, albo poeksperymentować z uruchamianiem poleceń DBCC CheckDB z dodatkowymi opcjami.
Komunikaty o błędach DBCC mogą wyglądać podobnie do poniższego:
Table error: Object ID 36, index ID 1, partition ID, alloc unit ID (type In-row data). Keys out of order on page (1:107), slots 6 and 9. CHECKDB found 0 allocation errors and 1 consistency errors in table 'sys.syk' (object ID 36). CHECKDB found 0 allocation errors and 1 consistency errors in database 'VLDB'. repair_rebuild is the minimum repair level for the errors found by DBCC CHECKDB (VLDB).
W komunikacie o błędzie można zobaczyć starannie sformułowany komunikat o błędzie – „repair_rebuild to minimum poziom naprawy błędów znalezionych przez DBCC CHECKDB ” – sugerując uruchomienie DBCC CheckDB z opcją repair_rebuild. Wystarczy spojrzeć na podświetlone słowo – „minimum”. Oznacza to, że z opcją repair_rebuild nie ma realnej możliwości utraty danych, a SQL Server wykonuje kilka szybkich poprawek pod maską. Zapoznaj się z poniższym poleceniem, aby uruchomić DBCC CheckDB z opcją repair_rebuild. Upewnij się, że baza danych znajduje się w trybie pojedynczego użytkownika.
Zgodnie z dokumentacją firmy Microsoft opcja REPAIR_REBUILD jest najbardziej nieszkodliwą wersją, ponieważ nie może powodować utraty danych. Jeśli jednak REPAIR_REBUILD nadal nie naprawi błędów spójności, jest jeszcze jedna opcja – włączyć REPAIR_ALLOW_DATA_LOSS. Patrząc na nazwę wiemy, że jeśli włączymy tę opcję, istnieje możliwość utraty części danych. Z tego powodu Microsoft ostrzega nas, abyśmy używali tego z najwyższą ostrożnością, ponieważ mogą wystąpić nieoczekiwane konsekwencje uruchomienia DBCC CheckDB z REPAIR_ALLOW_DATA_LOSS. Polecenie DBCC CheckDB w tym przypadku będzie wyglądać następująco:
Wskazówki do rozważenia przed użyciem opcji Napraw w DBCC CheckDB
Jak ważna jest dana baza danych?
Czy baza danych znajduje się w środowisku produkcyjnym czy testowym?
Jak duża jest baza danych?
Czy masz dobrą strategię odzyskiwania na wypadek pojawienia się problemów?
Czy zweryfikowałeś kopie zapasowe bazy danych?
Na podstawie sytuacji i odpowiedzi na powyższe pytania spróbuj podjąć decyzję, mając na uwadze najlepszy interes klienta.
Automatyzacja zadań DBCC CheckDB na serwerze SQL przy użyciu planów konserwacji bazy danych
Cóż, nie musisz ręcznie uruchamiać wszystkich tych poleceń na swoich serwerach. Dlatego mamy plany konserwacji. Pamiętaj, aby zaplanować regularny cykl konserwacji dla wszystkich baz danych, korzystając z planów konserwacji bazy danych. To dość proste i nieskomplikowane zadanie. W sekcji „Zadania planu konserwacji” wybierz „Zadanie sprawdzania integralności bazy danych”.
Spowoduje to dodanie zadania podrzędnego do planu konserwacji w celu zaplanowania sprawdzania integralności baz danych. Upewnij się, że wybrałeś wymagane bazy danych, jak pokazano.
Upewnij się, że wszystkie sprawdzenia bazy danych są przeprowadzane poza godzinami szczytu tygodnia. Zazwyczaj okna serwisowe są w weekendy, kiedy serwer jest mniej zajęty w porównaniu z innymi dniami tygodnia. Jednak będzie się to różnić w zależności od serwera i aplikacji. W krytycznych systemach baz danych alerty są zazwyczaj wyświetlane w przypadku pominięcia kontroli DBCC CheckDB lub integralności. W ten sposób administratorzy baz danych mogą proaktywnie sprawdzać i zapewniać, że przejdą weryfikację integralności, aby uniknąć późniejszych niespodzianek.
Automatyzacja zadań DBCC CheckDB na serwerze SQL przy użyciu niestandardowych skryptów lub innych popularnych skryptów
Plany konserwacji SQL Server nie muszą być używane przez cały czas do wykonywania zadań konserwacyjnych na Twojej instancji SQL Server. Istnieją inne dostępne niestandardowe skrypty, których możesz użyć. Jednym z popularnych bezpłatnych narzędzi serwisowych jest rozwiązanie serwisowe Ola Hallengren. Możesz zainstalować całe rozwiązanie do konserwacji, które obejmuje zadania tworzenia kopii zapasowych, optymalizacji itp., lub możesz pobrać tylko odpowiednie skrypty związane z kontrolą integralności. W tym demo postaramy się zainstalować skrypty przeznaczone do sprawdzania integralności bazy danych.
Kliknij opcję DatabaseIntegrityCheck.sql, jak pokazano, aby pobrać procedury składowane, które sprawdzają integralność bazy danych. Po uruchomieniu tych procedur składowanych w głównej bazie danych natknąłem się na następujące komunikaty ostrzegawcze:
“The module 'DatabaseIntegrityCheck' depends on the missing object 'dbo.CommandExecute'. The module will still be created; however, it cannot run successfully until the object exists.”
Jeśli uruchomisz procedurę składowaną do przeprowadzania kontroli integralności, pojawi się następujący błąd:
Jak wskazuje błąd, brakujący kod możesz pobrać tutaj. Gdy to zrobisz, możesz rozpocząć testowanie integralności bazy danych.
Można dostosować różne opcje za pomocą dodatkowych parametrów polecenia DBCC. Więcej szczegółów i przykładów można znaleźć tutaj.
Jednak w tym demo sprawdzimy kilka przykładów, aby zobaczyć, jak łatwe i przyjazne dla użytkownika są te skrypty.
Do uruchamiania DBCC CheckDB na wszystkich bazach danych użytkowników , musisz wykonać następujące czynności:
EXECUTE dbo.DatabaseIntegrityCheck @Databases = 'USER_DATABASES', @CheckCommands = 'CHECKDB'
Możesz zobaczyć polecenie, które zostało uruchomione i status wyniku, który potwierdza, że DBCC CheckDB zakończyło się pomyślnie.
Aby uruchomić DBCC Check tylko dla systemowych baz danych, wykonaj to polecenie:
EXECUTE dbo.DatabaseIntegrityCheck @Databases = 'SYSTEM_DATABASES', @CheckCommands = 'CHECKDB'
Na zrzucie ekranu widać, że DBCC CheckDB zostało pomyślnie zakończone dla systemowych baz danych.
Do uruchamiania DBCC CheckDB tylko dla określonej bazy danych, wykonaj następujące czynności:
EXECUTE dbo.DatabaseIntegrityCheck @Databases = 'VLDB', -- your specific DB Name @CheckCommands = 'CHECKDB'
W powyższym przykładzie widziałeś kilka sposobów wykorzystania parametrów. Istnieje jednak wiele innych filtrów, które możesz wybrać na podstawie swoich preferencji. Ponadto, jak już wspomniano, możesz odwołać się do tego linku dla lepszego zrozumienia scenariuszy Oli Hallengren. Powtórzę, używam skryptów Ola Hallengren na serwerach, którymi zarządzam i jest to wysoce zalecane i rozpoznawalne w społeczności SQL Server. Procedury składowane można zaplanować na podstawie preferowanych parametrów i uruchamiać je jako zadanie SQL poza godzinami szczytu. W ten sposób nie musisz uruchamiać żadnego z tych skryptów ręcznie, dzięki czemu możesz skupić się na innych ważnych zadaniach.
Wniosek
- Z tego artykułu dowiedziałeś się o DBCC CheckDB i o tym, jak można z niego korzystać
- Zrozumiałeś również, jak ważne jest regularne uruchamianie DBCC CheckDB we wszystkich ważnych bazach danych
- Poznałeś również, jak ważne jest posiadanie przetestowanej strategii tworzenia kopii zapasowych – zaleca się przywracanie baz danych przy użyciu dobrej kopii zapasowej zamiast rozwiązywania wszelkich błędów spójności za pomocą opcji naprawy DBCC
- Widziałeś również, jak łatwo jest skonfigurować i zautomatyzować skrypty za pomocą planów konserwacji SQL Server lub niestandardowych skryptów, np. tego od Ola Hallengren
- Poznałeś również ryzyko niezaplanowania DBCC CheckDB w obsługiwanej infrastrukturze
- Nauczyłeś się również, że bez względu na to, na jakim serwerze się znajdujesz i jakiej infrastruktury używasz, nie może istnieć baza danych niewymagająca konserwacji
- Na koniec upewnij się, że Twoje bazy danych są zdrowe i, w każdym razie, bądź gotowy na te dni OFF, które mogą nie być pod Twoją kontrolą
