page_split

page_split to zdarzenie podziału strony indeksu, którego duża częstotliwość świadczy o fragmentacji i kosztownych zapisach.

Na czym polega page_split w indeksie

page_split oznacza operację podziału strony indeksu w silniku Microsoft SQL Server. Strona jest podstawową jednostką przechowywania danych w SQL Server i ma rozmiar 8 KB. Gdy podczas zapisu nowy rekord albo zmieniona wartość klucza indeksu nie mieści się na stronie docelowej, silnik może utworzyć drugą stronę, przenieść do niej część wpisów oraz rozdzielić pomiędzy obie strony zawartość indeksu. Następnie aktualizowane są informacje potrzebne do zachowania prawidłowej struktury drzewa indeksowego.

Podział strony nie jest sam w sobie błędem. Jest normalnym mechanizmem obsługi zapisów do indeksu, szczególnie gdy dane są wstawiane w kolejności, która nie odpowiada kolejności klucza indeksu. Problem pojawia się wtedy, gdy operacja występuje często. Podział wymaga dodatkowych odczytów i zapisów, może generować blokowanie innych transakcji, zwiększa ilość pracy dziennika transakcji oraz może prowadzić do powstawania wolnego miejsca na stronach. Częste zdarzenia page_split są więc sygnałem do sprawdzenia sposobu wstawiania danych, definicji indeksów i ich parametrów przechowywania.

Dlaczego kolejność klucza wpływa na liczbę podziałów

Najłatwiejszym przypadkiem dla indeksu jest dopisywanie nowych kluczy na końcu struktury. Jeżeli kolumna klucza rośnie monotonicznie, nowe wpisy zwykle trafiają do ostatniej strony indeksu. W takiej sytuacji podział strony może być rzadszy, ponieważ silnik nie musi wstawiać wartości pomiędzy już istniejące wpisy. Inaczej działa indeks, do którego trafiają klucze o rozproszonych wartościach. Wstawienie rekordu do środka uporządkowanej strony może wymagać przesunięcia wpisów i utworzenia nowej strony.

Znaczenie ma także rozmiar wpisu indeksowego. Indeks zawierający szerokie kolumny, kolumny o zmiennej długości albo dużą liczbę kolumn uwzględnianych w strukturze zajmuje więcej miejsca na każdej stronie. Mniejsza liczba wpisów mieszczących się na stronie zwiększa prawdopodobieństwo, że kolejny zapis nie znajdzie wystarczającej ilości wolnego miejsca. Dodatkową przyczyną może być aktualizacja wartości klucza indeksu. Jeżeli zmiana powoduje przeniesienie rekordu w inne miejsce uporządkowanej struktury, SQL Server może wykonać operacje podobne do wstawienia i usunięcia, a ich skutkiem również może być podział strony.

Jak interpretować page_split podczas analizy SQL Server

Sam licznik lub pojedyncze zdarzenie page_split nie pozwala ocenić, czy występuje realny problem wydajnościowy. Analiza powinna uwzględniać częstotliwość zapisów, czas obserwacji, typ indeksu oraz relację między liczbą podziałów a całkowitą liczbą operacji zapisu. Warto ustalić, której tabeli i którego indeksu dotyczą zdarzenia, czy podziały występują podczas obciążenia aplikacji oraz czy towarzyszą im wzrost czasu odpowiedzi, blokowanie, większa aktywność dziennika transakcji albo dodatkowe operacje wejścia-wyjścia.

W SQL Server do oceny stanu indeksów można wykorzystać między innymi widoki dynamicznego zarządzania, takie jak sys.dm_db_index_physical_stats, które dostarczają informacji o fragmentacji i wykorzystaniu stron. Nie należy jednak utożsamiać każdego podziału strony z wartością avg_fragmentation_in_percent. Fragmentacja logiczna opisuje nieciągłość kolejności stron indeksu, natomiast page_split jest zdarzeniem związanym z konkretną operacją modyfikacji. Oba zjawiska mogą mieć wspólną przyczynę, ale mierzą różne właściwości. Przed zmianą indeksu trzeba sprawdzić plan zapytań, predykaty wyszukiwania, obciążenie zapisami oraz wpływ indeksu na operacje odczytu.

Ograniczanie kosztownych podziałów stron

Ograniczanie liczby podziałów stron w SQL Server zaczyna się od identyfikacji indeksów, dla których zjawisko jest częste i kosztowne. Jednym z mechanizmów dostępnych przy tworzeniu lub przebudowie indeksu jest parametr FILLFACTOR. Określa on docelowe wypełnienie stron liści indeksu podczas operacji budowania. Pozostawienie wolnego miejsca może zmniejszyć liczbę podziałów wywoływanych późniejszymi wstawkami w środku struktury, ale równocześnie zwiększa rozmiar indeksu i może wymagać większej liczby odczytów. Zbyt niska wartość nie jest uniwersalnym rozwiązaniem, ponieważ wolne miejsce może szybko zostać wykorzystane, a większy indeks zwiększa koszt pamięciowy i wejścia-wyjścia.

Dobór klucza indeksu powinien uwzględniać rzeczywisty wzorzec zapisów, a nie tylko unikalność kolumny. W niektórych tabelach korzystne może być użycie klucza o przewidywalnej kolejności, natomiast w innych konieczne jest zachowanie klucza wynikającego z wymagań zapytań. Przebudowa indeksu może uporządkować strukturę i odzyskać wolne miejsce, lecz nie usuwa przyczyny przyszłych podziałów, jeżeli aplikacja nadal wykonuje rozproszone wstawienia lub aktualizacje klucza. W przypadku problemów z wydajnością potrzebna jest diagnostyka konkretnej bazy, tabeli, indeksu i obciążenia, a następnie test zmiany na danych oraz zapytaniach odpowiadających rzeczywistemu użyciu.