By: Brady Upton | Updated: 2016-07-26 | Komentarze (2) | Powiązane: More > Database Console Commands DBCCs

Problem

Korupcja bazy danychSQL Server może być problemem i może spowodować poważne uszkodzenie bazy danych. Jeśli jesteś doświadczonym DBA, to prawdopodobnie masz zabezpieczenia, aby to wykryć, ale przez lata widziałem setki serwerów SQL bez żadnych metod wykrywania i to jest problem. Istnieje kilka sposobów na wykrycie uszkodzenia bazy danych, ale ta wskazówka skupi się bardziej na DBCC CHECKDB.

Rozwiązanie

Możesz lub nie słyszałeś o poleceniachDBCC (database console commands). Te polecenia są używane do wykonywania różnych operacji w bazie danych i mogą być podzielone na cztery kategorie:Konserwacja, Różne, Informacyjne i Sprawdzanie poprawności. Na co dzień używam niektórych poleceń DBCC, ale żadnego z nich nie używam bardziej niż DBCC CHECKDB.

Czym jest SQL Server DBCC CHECKDB

DBCC CHECKDB, z Microsoft MSDN Library, sprawdza logiczną i fizyczną integralność wszystkich obiektów w określonej bazie danych, wykonując następujące operacje:

  • Uruchamia DBCC CHECKALLOC na bazie danych – Sprawdza spójność struktur alokacji przestrzeni dyskowej dla określonej bazy danych.
  • Uruchamia DBCC CHECKTABLE na każdej tabeli i widoku w bazie danych – sprawdza integralność wszystkich stron i struktur tworzących tabelę lub widok indeksowany.
  • Uruchamia DBCC CHECKCATALOG na bazie danych – sprawdza spójność katalogów w bazie danych.
  • Weryfikuje zawartość każdego widoku indeksowanego w bazie danych.
  • Weryfikuje spójność na poziomie łącza między metadanymi tabel a katalogami i plikami systemu plików podczas przechowywania danych zmiennych(max) w systemie plików przy użyciuFILESTREAM.
  • Weryfikuje dane brokera usług w bazie danych

Jeśli kiedykolwiek uruchomiłeś DBCC CHECKDB, wiesz, że zajmuje to trochę czasu w przypadku dużych baz danych.Teraz, gdy znasz wszystkie kroki, które są uruchamiane, możesz zobaczyć, dlaczego zajmuje to trochę czasu.

Jak SQL Server DBCC CHECKDB może mi pomóc?

Psucie danych jest złe. Może powodować różnego rodzaju problemy w obrębie bazy danych, w tym nieprawidłowe wyniki danych, nieudane polecenia SQL, a w niektórych przypadkach może doprowadzić do awarii całej instancji SQL. DBCC CHECKDB ostrzega o uszkodzeniach, dzięki czemu można je naprawić, zanim (miejmy nadzieję) staną się zbyt poważne.

Jak używać SQL Server DBCC CHECKDB?

DBCC CHECKDB jest całkiem proste. Istnieje kilka opcji, których można użyć z tym poleceniem i przejdziemy do niektórych z nich w następnej sekcji, ale podstawowa składnia wygląda tak:

DBCC CHECKDB ('DatabaseName')

Pretty simple.

Automate SQL Server DBCC CHECKDB

Oczywiście, nie chcesz logować się każdego ranka i uruchamiać tego polecenia na każdej bazie danych, więc możesz zautomatyzować ten proces, używając kilku różnych metod:

  • Plany konserwacji SQL Server -Plany konserwacji są częścią SQL Server po wyjęciu z pudełka (chyba że używasz ExpressEdition). W większości przypadków nie lubię korzystać z planów konserwacji, ale w przypadku tego typu zadań nie mam nic przeciwko ich użyciu. W oknie narzędziowym Plany konserwacji należy użyć zadania Sprawdź integralność bazy danych. Jedyną konfigurowalną opcją jest włączenie indeksów, więc nie jest to zbyt przyjazne dla użytkownika, ale w niektórych przypadkach jest to wszystko, czego potrzebujesz. Ponownie, porozmawiamy o innych opcjach w następnej sekcji.
  • Skrypty niestandardowe – Skrypty niestandardowe są zazwyczaj tym, czego używam i oferują najlepszą elastyczność w zakresie dodawania opcji, które chcesz. Moje skrypty go-toscripts są już utworzone i wolne do użytku z Ola Hallengren. Wykonał on wspaniałą pracę tworząc je i dzieląc się nimi z całym światem. DziękiOla!
    • Sprawdź skrypty na MSSQLTips.com:
    • Performing Maintenance with SQL Server Databases in Full Recovery mode
    • SQL Server Database Maintenance Plans and Backup File Management
    • Performing SQL Server Maintenance with No Maintenance Window

    SQL Server DBCC CHECKDB Options

    Istnieje kilka opcji do wykorzystania z DBCC CHECKDB i omówię tutaj kilka z nich bardziej popularnych:

    • NOINDEX – Określa, że nie powinny być wykonywane intensywne sprawdzenia nieklastrowych indeksów dla tabel użytkownika. Zmniejsza to czas wykonania overallexecution. NOINDEX nie ma wpływu na tabele systemowe, ponieważ kontrole integralności są zawsze wykonywane na indeksach tabel systemowych.
    • NO_INFOMSGS – Wyłącza wszystkie komunikaty informacyjne.
    • PHYSICAL_ONLY – Ogranicza sprawdzanie do integralności fizycznej struktury nagłówków stron i rekordów oraz spójności alokacyjnej bazy danych. Ta kontrola ma na celu zapewnienie niewielkiego narzutu sprawdzania fizycznej spójności bazy danych, ale może również wykryć rozdarte strony, błędy sum kontrolnych i typowe awarie sprzętu, które mogą zagrozić danym użytkownika.
    • TABLOCK – Powoduje, że DBCC CHECKDB uzyskuje blokady zamiast używać wewnętrznej migawki bazy danych. Obejmuje to krótkotrwałą wyłączną blokadę (X) bazy danych. TABLOCK powoduje, że DBCC CHECKDB działa szybciej na bazie danych pod dużym obciążeniem, ale zmniejsza współbieżność dostępną na bazie danych podczas działania DBCC CHECKDB.
    • DATA_PURITY – Powoduje, że DBCC CHECKDB sprawdza bazę danych pod kątem wartości kolumn, które są nieprawidłowe lub poza zakresem. Na przykład DBCC CHECKDB wykrywa kolumny z wartościami daty i czasu, które są większe lub mniejsze niż dopuszczalny zakres dla typu danych datetime; lub kolumny typu danych dziesiętnych lub przybliżonych liczbowych z wartościami skali lub precyzji, które nie są ważne.

    Przejdziemy do niektórych opcji NAPRAWY w innej sekcji poniżej.

    Jak często powinienem sprawdzać uszkodzenie SQL Server?

    W każdej minucie każdego dnia. Just kidding.

    Jeśli masz codzienne okno konserwacyjne, dobrze byłoby sprawdzać codziennie, czy dane nie są uszkodzone. Im szybciej można je złapać, tym mniej szkód mogą wyrządzić. Zauważyłem, że wiele osób uruchamia to w weekend, szczególnie w przypadku większych baz danych. Nie ma w tym nic dobrego ani złego, upewnij się tylko, że masz to zaplanowane okresowo.

    Czy muszę uruchomić DBCC CHECKDB w moim środowisku produkcyjnym?

    Nie, cóż, tak. W pewnym sensie.

    Aby sprawdzić, czy dane nie są uszkodzone, nie warto uruchamiać DBCC CHECKDB na swoim środowisku testowym…chyba że przywrócisz kopię swojego środowiska produkcyjnego do testów, a następnie ją uruchomisz. BRILLIANT!

    Możesz zastanawiać się, czy niektóre opcje HA są odpowiednie, takie jak AlwaysOn, LogShipping itp. Nie, musisz sprawdzić swoje produkcyjne środowisko *live*.

    Teraz, gdy DBCC CHECKDB jest skonfigurowane i działa, czego szukam?

    Gratulacje! Masz zautomatyzowane i działające DBCC CHECKDB, ale co teraz? Jeśli masz skonfigurowane zadanie agenta serweraSQL, upewnij się, że skonfigurowałeś pocztę bazy danych, operatora i powiadomienie dla tego zadania. Jeśli zadanie się powiedzie, kontynuuj swój piękny dzień. Jeśli zadanie się nie powiedzie, to mamy trochę pracy do wykonania.

    Możesz zobaczyć błąd taki jak ten:

    The In-row data USED page count for object „tablename”, index ID 2, partitionID 608313809829888, alloc unit ID 608313809829888 (type In-row data) is incorrect.Run DBCC UPDATEUSAGE. (Error 2508) The In-row data RSVD pagecount for object „tablename”, index ID 2, par… Krok nie powiódł się.

    lub to:

    Object ID 2088535921, index ID 0, partition ID 72345201021503994, alloc unitID 72345201051571606 (type In-row data): Strona (1:94299) nie mogła zostać przetworzona.Zobacz inne błędy dla szczegółów. Msg 8939, Level 16, State 98, Line 1 Table error:Object ID 2088535921, index ID 0, partition ID 72345201021503994, alloc unitID 72345201051571606 (type In-row data), page (1:94299). Test (IS_OFF (BUF_IOERR,pBUF->bstat)) nie powiódł się. CHECKDB znalazł 0 błędów alokacji i 2 błędy spójności w tabeli 'tablename’ (ID obiektu 2088535921). CHECKDB znalazł 0 błędów alokacji i 2 błędy spójności w bazie danych 'tablename’. repair_allow_data_loss to minimalny poziom naprawy dla błędów znalezionych przez DBCC CHECKDB (Database).

    Po pierwsze, nie panikuj. Po drugie, sprawdź kopie zapasowe. Błędy DBCC CHECKDB zazwyczaj mówią, co należy zrobić.

    W przypadku pierwszego błędu polecenie DBCC UPDATEUSAGE skoryguje niedokładności w liczbie stron i wierszy w widokach katalogowych. Całkiem nieszkodliwe.

    Drugi błąd zgłasza uszkodzenie danych. Błąd wspomina o użyciu repair_allow_data_loss jako minimalnego poziomu naprawy. Oznacza to, że możesz uruchomić oświadczenie z tym argumentem, ale możesz stracić dane. Dlatego zawsze zalecam przywracanie do kopii zapasowej, jeśli jest to możliwe. Musisz się upewnić, że kopia zapasowa nie zawiera uszkodzonych danych i chcesz się upewnić, że nie nastąpi utrata danych.

    Jak naprawić bazę danych SQL Server

    Jeśli nie masz kopii zapasowej, może być konieczne użycie DBCC CHECKDB z opcją naprawy.Oto opcje naprawy, które są dostępne do użycia. Mogą one działać lub nie i należy ich używać w ostateczności:

    • REPAIR_ALLOW_DATA_LOSS – próbuje naprawić wszystkie zgłoszone błędy.Naprawy te mogą spowodować utratę niektórych danych.
    • REPAIR_REBUILD – wykonuje naprawy bez możliwości utraty danych. Może to obejmować szybkie naprawy, takie jak naprawa brakujących wierszy w indeksach nieklastrowych, oraz bardziej czasochłonne naprawy, takie jak odbudowa indeksu.

    Jak powiedziałem powyżej, bardzo ważne jest posiadanie aktualnych kopii zapasowych, aby odzyskać dane po uszkodzeniu. Korupcja nie ma znaczenia, ile danych posiadasz, jaką wersję SQL używasz lub jak fantazyjne jest twoje centrum danych.

    Czuję się z tym całkiem dobrze, ale czego jeszcze mogę użyć, aby chronić moje instancje SQL?

    DBCC CHECKDB powinno być uruchamiane na każdej instancji SQL, ale istnieje kilka innych sposobów, które mogą pomóc w wykrywaniu/przeciwdziałaniu uszkodzeniom danych.

    • Alerty agenta SQL Server – Brian Kelley napisał na ten temat niezłą poradę tutaj.
    • Weryfikacja strony – Upewnij się, że twoje bazy danych używają weryfikacji strony za pomocą CHECKSUM. Jeśli nadal używasz SQL 2005 lub niższego, nie jest to dostępne, ale po aktualizacji upewnij się, że zmieniłeś to ustawienie. Aby zobaczyć ustawienia weryfikacji stron, użyj następującego polecenia:
    select name, page_verify_option_desc from sys.databases
    Następne kroki
    • Zapewnij się, że sprawdzisz BibliotekęMSDN, aby uzyskać więcej szczegółów dotyczących DBCC CHECKDB
    • MSSQLTips.com ma ładną kolekcję wskazówek na temat sprawdzania spójności bazy danych, które mogą być również pomocne.

    Ostatnia aktualizacja: 2016-07-26

    O autorze
    Brady Upton jest administratorem bazy danych i supergwiazdą SharePoint w Nashville, TN.
    Zobacz wszystkie moje porady
    Powiązane zasoby

    • Więcej porad SQL Server DBA…

    .

By: adminPosted on

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.