Pracuję nad wdrożeniem przez Paula Randala metody ręcznego rozkładania DBCC CHECKDB na kilka dni w przypadku bardzo dużych baz danych, które zasadniczo obejmują:
- Dzielenie tabel w bazie danych z grubsza jednakowo pomiędzy 7 segmentów
- Uruchamianie DBCC CHECKALLOC dwa razy w tygodniu
- Uruchamianie DBCC CHECKCATALOG raz w tygodniu
- Uruchamianie tabeli kontrolnej DBCC na jednym wiadrze każdego dnia tygodnia
Czy ktoś użył tej techniki? Jakieś istniejące skrypty?
Obawiam się, że to może nie obejmować wszystkiego, co robi CHECKDB; dokumentacja Books Online dla CHECKDB mówi, że oprócz CHECKALLOC, CHECKCATALOG i CHECKTABLE, to także:
- Sprawdza zawartość każdego indeksowanego widoku w bazie danych.
- Sprawdza spójność na poziomie łącza między metadanymi tabeli a katalogami i plikami systemu plików podczas przechowywania danych varbinary (max) w systemie plików za pomocą FILESTREAM. (Tylko SQL 2008)
- Sprawdza poprawność danych Service Broker w bazie danych.
Oto moje pytania:
Czy te dodatkowe kontrole są konieczne / ważne? (Widoki indeksowane są dla mnie trochę bardziej niepokojące, nie sądzę, że korzystamy z Service Brokera lub FILESTREAM.)
Jeśli tak, czy istnieją sposoby na przeprowadzenie tych dodatkowych kontroli osobno?
CHECKALLOC i CHECKCATALOG wydają się działać bardzo szybko, nawet na dużych dbs. Czy jest jakiś powód, aby nie uruchamiać ich codziennie?
(Uwaga: będzie to standardowa procedura dla tysięcy istniejących baz danych na setkach serwerów lub przynajmniej każdej bazy danych o określonym rozmiarze. Oznacza to, że opcje takie jak restrukturyzacja wszystkich baz danych w celu użycia CHECKFILEGROUP nie są dla nas praktyczne).
źródło
Odpowiedzi:
Możesz uruchomić
DBCC CHECKTABLE WITH EXTENDED_LOGICAL_CHECKSbezpośrednio w indeksowanych widokach . Sprawdzanie indeksowanych widoków może być problematyczne w pewnych okolicznościach , więc przygotuj się na zbadanie wszelkich wyników fałszywie dodatnich. (Paul Randal wspomina również w komentarzach do przywołanego artykułu, że możliwe są również fałszywe negatywy, ale nie mam bezpośredniego doświadczenia).Nie ma obsługi uruchamiania Service Brokera ani
FILESTREAMczeków osobno, nie.Nie, że jestem tego świadomy.
Możesz także rozważyć uruchomienie
DBCC CHECKCONSTRAINTS. Kontrola ta jest nie wliczone wDBCC CHECKDB, niezależnie od opcji można określić. Możesz także pomyśleć o okazjonalnym bieganiuCHECKDB, gdy okoliczności na to pozwalają.źródło
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.
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:
DBCC CHECKTABLEwraz z uruchomieniemDBCC CHECKALLOCiDBCC CHECKCATALOGDBCC CHECKTABLE,DBCC CHECKALLOCaDBCC CHECKCATALOG. Tak, że można poczuć się, jak długo jest ona zwykle biorąc dla kontroli do uruchomienia.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:
źródło