DBCC CHECKDB jest niezbędny, aby bazy danych SQL Server były w 100% pewne, że nie ma uszkodzeń. Jednak ze względu na ogromne rozmiary baz danych bardzo trudno jest znaleźć okno konserwacji, gdy twierdzisz, że masz 24x7. Przez lata zespół SQL Server wdrożył różne mechanizmy wykrywające najczęstsze formy zepsucia, szczególnie związane z fizycznym uszkodzeniem spowodowanym przez sprzęt.
SQL Server 2005 i nowsze wersje mają parametr PAGE_VERIFY = CHECKSUM, który może pomóc proaktywnie wykryć fizyczne uszkodzenie stron bazy danych, dodając w ten sposób sumę kontrolną do każdej strony zapisywanej w systemie we / wy i sprawdzając sumę kontrolną podczas odczytu z dysku.
Ponadto tworzenie kopii zapasowych (pełne lub różnicowe) za pomocą CHECKSUM gwarantuje wykrycie wszelkich uszkodzeń we / wy spowodowanych przez sprzęt.
Dlatego od strony sprzętowej uszkodzenia SQL Server dobrze wykrywa go i zgłasza. (Pamiętaj również o ustawieniu ważnych alertów związanych z korupcją ).
To powiedziawszy, nadal logiczne uszkodzenie , błędy wywoływane przez skrybera - w których strony w pamięci są uszkodzone albo przez kod innej firmy działający w procesie SQL Server, albo przez sterowniki lub inne oprogramowanie z wystarczającymi uprawnieniami do wykonywania w trybie jądra systemu Windows i / lub SQL Server Błędy itp. Są niewykrywalne przy użyciu powyższych metod i dlatego pojawia się CHECKDB .
DBCC CHECKDB wykonuje dokładniejsze kontrole, które obejmują sprawdzanie nagłówków stron pod kątem ewentualnych uszkodzeń, których nie można wykryć w żaden inny sposób.
Jakieś istniejące skrypty?
Zamiast na nowo wymyślić koło, zdecydowanie polecam przyjrzeć się rozwiązaniu Ola SQL Server Integrity Check
Sprawnie działające DBCC CHECKDB:
Musisz być kreatywny, gdy jesteś blisko okna konserwacji, mając ogromne bazy danych lub dużą liczbę baz danych, na których można uruchomić CHECKDB.
Po przejściu szkolenia SQLSkills zaimplementowałem w moim środowisku:
- ustal, jakie tabele mają krytyczne znaczenie do sprawdzenia.
- podziel tabele na grupy o różnych priorytetach, a następnie uruchom je
DBCC CHECKTABLEwraz z uruchomieniem DBCC CHECKALLOCiDBCC CHECKCATALOG
- Utwórz tabelę roboczą, która będzie przechowywać nazwy tabel z priorytetami. Upewnij się tylko, że wszystkie tabele o wysokim priorytecie (które są ogromne) nie znajdują się w jednej grupie, w przeciwnym razie Twój CHECKDB w ogóle się nie ukończy.
- Możesz nawet mieć kolumnę limitu czasu w tabeli roboczej, która będzie koordynować, kiedy Twój CHECKDB zostanie zabity po przejściu przez okno konserwacji
- Dodaj jak długo zajęło na stole do biegu
DBCC CHECKTABLE, DBCC CHECKALLOCa DBCC CHECKCATALOG. Tak, że można poczuć się, jak długo jest ona zwykle biorąc dla kontroli do uruchomienia.
- Możesz nawet uruchomić z
NOINDEXopcją, ponieważ przyspieszy to operację, ponieważ nie sprawdza indeksów nieklastrowanych w tabelach użytkowników. Ma to pewną zaletę, ponieważ nie jest tak krytyczne jak uszkodzenie danych, ponieważ żadne dane nie są tracone, w razie potrzeby można upuścić i ponownie utworzyć indeks.
Oczywiście wersja Enterprise może korzystać z równoległego wykonywania instrukcji DBCC, ale uważaj na ustawienie MAXDOP, ponieważ może to zająć cały procesor. Może to być mocno ograniczone przez Resource Governor.
Uwaga: jeśli masz kolumnę SPARSE, wtedy Twój CHECKDB będzie bardzo powolny, jak opisano tutaj .
Wreszcie, jak zapobiegać uszkodzeniu bazy danych, wykorzystując cały dostępny zestaw narzędzi + swoją wiarę w system sprzętowy serwera bazy danych i, co najważniejsze, wartość twoich danych.
Kilka doskonałych referencji: