Uszkodzenie indeksu klastrowanego

Uszkodzenie indeksu klastrowanego wpływa na fizyczny układ całej tabeli, ponieważ dane są w nim przechowywane.

Na czym polega uszkodzenie indeksu klastrowanego

Indeks klastrowany jest strukturą organizującą sposób przechowywania rekordów tabeli. W wielu relacyjnych silnikach baz danych ma postać drzewa B lub jego odmiany, a poziom liści zawiera same wiersze tabeli albo ich fizyczną reprezentację. Oznacza to, że uszkodzenie tego indeksu może dotyczyć nie tylko pomocniczej struktury używanej do wyszukiwania, lecz także dostępu do całego układu danych. Rekordy mogą stać się niedostępne, błędnie powiązane z kluczami indeksu albo możliwe do odczytania wyłącznie częściowo.

Uszkodzenie indeksu klastrowanego nie jest tym samym co zwykła fragmentacja. Fragmentacja oznacza niekorzystne rozłożenie stron danych, na przykład po licznych aktualizacjach i usuwaniu rekordów, ale sama w sobie nie musi oznaczać utraty spójności. Korupcja indeksu oznacza naruszenie struktury lub zawartości stron, niezgodne odwołania między poziomami drzewa, nieprawidłowe klucze albo rozbieżność między metadanymi a faktycznymi rekordami. Przyczyną mogą być błędy nośnika, nagłe przerwanie zapisu, wadliwa pamięć, problemy sterownika magazynu lub błąd oprogramowania.

Objawy widoczne podczas odczytu i zapisu danych

Objawy zależą od zakresu uszkodzenia. Zapytania korzystające z określonego zakresu kluczy mogą zgłaszać błędy odczytu, zwracać mniej rekordów niż oczekiwano albo kończyć się wyjątkiem. Czasami problem ujawnia się dopiero przy skanowaniu całej tabeli, sortowaniu, przebudowie indeksu lub wykonywaniu kontroli spójności. Jeżeli uszkodzona strona znajduje się w części drzewa odpowiedzialnej za konkretny przedział kluczy, pozostałe operacje mogą przez pewien czas działać poprawnie, co utrudnia rozpoznanie problemu.

Nieprawidłowości mogą pojawić się także przy modyfikacji danych. Wstawienie nowego wiersza, aktualizacja klucza lub usunięcie rekordu może wymagać odczytu uszkodzonej strony i wtedy operacja zostanie przerwana. W innych przypadkach silnik wykryje niespójność dopiero podczas tworzenia planu zapytania albo przy użyciu indeksu. Sama nieoczekiwana powolność nie potwierdza jeszcze korupcji, ponieważ podobny efekt powodują blokady, przeciążenie wejścia-wyjścia, brak pamięci, fragmentacja lub nieaktualne statystyki.

Rozróżnienie korupcji od fragmentacji i błędów planu

Diagnostykę należy rozpocząć od ustalenia, czy problem dotyczy danych, struktury indeksu, czy jedynie wydajności. Kontrola spójności powinna objąć tabelę oraz wszystkie powiązane struktury indeksowe, a jej wynik trzeba zachować wraz z identyfikatorem bazy, nazwą obiektu i czasem wykonania. Warto porównać błędy z dziennikami systemu operacyjnego, komunikatami magazynu danych oraz informacjami o ostatnich awariach zasilania lub nieudanych operacjach wejścia-wyjścia. Pojedynczy komunikat aplikacji bez kontekstu nie wystarcza do wskazania uszkodzonej strony.

Jeżeli kontrola nie wykazuje naruszenia spójności, należy sprawdzić plan zapytania, selektywność predykatów, statystyki, blokady i czas odpowiedzi podsystemu dyskowego. Przebudowa indeksu może zmniejszyć fragmentację, lecz nie powinna być traktowana jako uniwersalne leczenie korupcji. Przy potwierdzonym uszkodzeniu pierwszeństwo ma zachowanie danych i ustalenie dostępnej kopii zapasowej. Naprawa struktury może wiązać się z usunięciem części informacji, dlatego działania naprawcze wykonuje się dopiero po zabezpieczeniu kopii oraz ocenie, czy możliwe jest odtworzenie całej bazy lub konkretnej tabeli.

Bezpieczne postępowanie po potwierdzeniu uszkodzenia

Po potwierdzeniu korupcji należy ograniczyć operacje, które mogą zwiększać liczbę zapisów, i ustalić zakres obiektów dotkniętych problemem. Przydatne jest wykonanie dodatkowego odczytu kontrolnego, porównanie liczby rekordów z niezależnym źródłem oraz sprawdzenie, czy uszkodzenie powtarza się po ponownym odczycie tej samej tabeli. Jeżeli dostępna jest sprawdzona kopia zapasowa, odtworzenie do odseparowanego środowiska pozwala ocenić jej kompletność bez nadpisywania bieżących danych. Należy również zweryfikować stan dysków i kontrolera, ponieważ odtworzenie bazy bez usunięcia przyczyny może doprowadzić do ponownego uszkodzenia.

W zależności od silnika i rodzaju awarii możliwe są różne działania: odtworzenie kopii, odtworzenie do określonego momentu, ponowne utworzenie indeksu z zachowaniem tabeli albo eksport poprawnie odczytanych rekordów do nowej struktury. Konkretna procedura nie jest uniwersalna, ponieważ różne systemy baz danych mają odmienne formaty stron, mechanizmy dziennika transakcyjnego i narzędzia kontroli. W środowisku roboczym nie należy uruchamiać poleceń naprawczych bez znajomości ich skutków, szczególnie gdy dokumentacja ostrzega o możliwości utraty niespójnych danych.

Uszkodzenie indeksu klastrowanego wymaga więc połączenia analizy komunikatów, kontroli spójności, weryfikacji kopii zapasowych i oceny warstwy sprzętowej. Dopiero taki zestaw dowodów pozwala odróżnić rzeczywistą korupcję od problemu wydajnościowego oraz dobrać sposób odzyskania danych adekwatny do zakresu uszkodzeń.