Tabela bezklastrowa

Tabela bezklastrowa (heap) nie ma zdefiniowanego indeksu klastrowego, przez co dane nie są fizycznie uporządkowane.

Jak działa tabela bezklastrowa

Tabela bezklastrowa, określana także angielskim terminem heap, to tabela, dla której nie zdefiniowano indeksu klastrowego. Brak takiego indeksu oznacza, że wiersze nie są organizowane według klucza określającego ich logiczną kolejność. Dane są przechowywane w stronach i obszarach przydzielonych przez silnik bazy danych, ale sama tabela nie ma nadrzędnej struktury porządkującej rekordy zgodnie z wartością konkretnej kolumny.

Heap nie oznacza pustej tabeli ani tabeli pozbawionej wszystkich indeksów. Na tabeli bezklastrowej można utworzyć indeksy nieklastrowe, które przechowują klucze wyszukiwania oraz informacje pozwalające odnaleźć odpowiadające im wiersze. Nadal jednak podstawowe dane tabeli pozostają zorganizowane jako heap, ponieważ żaden indeks klastrowy nie definiuje ich głównego układu. Z tego powodu kolejność rekordów zwracanych bez jawnego sortowania nie jest gwarantowana i nie należy traktować jej jako stałej właściwości tabeli.

Odczyt rekordów i rola indeksów nieklastrowych

Zapytanie filtrujące tabelę bezklastrową może zostać wykonane przez skanowanie całej tabeli albo przez użycie indeksu nieklastrowego. Skan tabeli polega na odczytaniu kolejnych stron danych i sprawdzeniu warunku dla znajdujących się na nich rekordów. Jest to naturalny sposób wykonania zapytania, gdy trzeba zwrócić znaczną część wierszy albo gdy nie istnieje użyteczny indeks. Przy małej tabeli taki odczyt może być wystarczający, ponieważ koszt przejrzenia niewielkiej liczby stron pozostaje niski.

Jeżeli filtr wykorzystuje kolumnę objętą indeksem nieklastrowym, silnik może najpierw wyszukać odpowiednie klucze, a następnie pobrać pełne dane z heap. Ten drugi etap jest często nazywany wyszukiwaniem po identyfikatorze wiersza. Gdy zapytanie zwraca wiele rekordów, wielokrotne przechodzenie z indeksu do stron danych może być kosztowniejsze niż skan. Dlatego sama obecność indeksu nieklastrowego nie przesądza jeszcze o szybszym wykonaniu zapytania; znaczenie mają między innymi selektywność warunku, liczba zwracanych wierszy, rozmiar rekordu i aktualne statystyki.

Wstawianie, aktualizacje i fragmentacja danych

Wstawienie rekordu do heap nie musi zachować kolejności wynikającej z wartości klucza biznesowego ani z czasu dodania. Jeżeli w istniejących stronach pozostaje wolne miejsce, silnik może wykorzystać tę przestrzeń. W przeciwnym razie przydzielana jest kolejna strona lub kolejny obszar. Aktualizacja rekordu, która zwiększa jego rozmiar, może doprowadzić do przeniesienia wiersza na inną stronę. W takim przypadku w pierwotnym miejscu pozostaje informacja kierująca do nowej lokalizacji danych.

Takie przenoszenie rekordów może zwiększać liczbę odczytywanych stron i pogarszać lokalność danych. Dodatkowym problemem może być fragmentacja indeksów nieklastrowych wskazujących na wiersze heap. Ocena sytuacji powinna obejmować rzeczywisty plan wykonania zapytań, statystyki, rozmiar tabeli, intensywność operacji zapisu oraz liczbę odczytów logicznych. Nie każda tabela bezklastrowa wymaga zmiany struktury. Dla małych tabel, tabel tymczasowych lub obiektów używanych głównie do ładowania danych heap może być uzasadnionym rozwiązaniem.

Diagnoza problemów związanych z heap

Diagnostyka powinna rozpocząć się od ustalenia, czy spowolnienie wynika z samego braku indeksu klastrowego, czy z niewłaściwego indeksu nieklastrowego, nieaktualnych statystyk, nadmiernej liczby odczytów albo częstych zmian rozmiaru wierszy. Warto porównać plan wykonania dla zapytań najczęściej korzystających z tabeli oraz sprawdzić, czy występuje pełny skan, wyszukiwanie po indeksie z licznymi pobraniami danych lub ostrzeżenia dotyczące przeniesionych rekordów. Analiza powinna uwzględniać również rzeczywiste wartości parametrów i rozkład danych, ponieważ plan korzystny dla jednego zakresu może być nieefektywny dla innego.

Możliwym kierunkiem poprawy jest utworzenie odpowiedniego indeksu klastrowego, ale taka zmiana wpływa na sposób przechowywania całej tabeli oraz na istniejące indeksy nieklastrowe. Przed jej wykonaniem trzeba sprawdzić unikalność i stabilność proponowanego klucza, zależności między obiektami, rozmiar tabeli oraz dostępne okno serwisowe. W innych przypadkach wystarczy przebudowa lub korekta indeksów nieklastrowych, aktualizacja statystyk albo zmiana zapytania. Przy diagnostyce komputera, na którym działa lokalne środowisko bazodanowe, należy zebrać plan wykonania, komunikaty błędów i informacje o obciążeniu, aby odróżnić problem logiczny struktury danych od problemu zasobów sprzętowych.