Odbudowa indeksów to kolejne zadanie cykliczne usługi SSJob, tworzące od nowa indeksy bazy danych, które z czasem tracą wydajność na skutek fragmentacji. Konfiguruje się je jako wiersz w tabeli _jobs, wskazując bazę danych oraz harmonogram uruchomień.
Czym jest odbudowa indeksów
Baza danych StudioSystem, tak jak każda baza SQL Server obsługująca intensywny ruch transakcyjny, korzysta z indeksów przyspieszających wyszukiwanie danych w dużych tabelach - dokumentach magazynowych, kartotekach, historii zmian opisanej przy okazji mechanizmu rewizji danych. Indeksy te nie pozostają jednak wiecznie w optymalnym stanie - z czasem ich struktura ulega degradacji, którą nazywa się fragmentacją.
Samo zadanie odbudowy indeksów, podobnie zresztą jak kopia bazy MSSQL czy kopia aplikacji, korzysta z tego samego mechanizmu usługi SSJob - wiersza w tabeli _jobs z ustawianym harmonogramem oraz powiadomieniami wysyłanymi na wskazane adresy e-mail.
W odróżnieniu jednak od zadań kopii zapasowej, odbudowa indeksów nie tworzy żadnego pliku ani nie zabezpiecza danych przed utratą - jej jedynym celem jest utrzymanie wydajności zapytań na akceptowalnym poziomie. To zadanie działające niejako w tle całej infrastruktury, o którym administrator przypomina sobie zwykle dopiero wtedy, gdy zapytania zaczynają wykonywać się zauważalnie wolniej niż jeszcze kilka miesięcy wcześniej.
Dlaczego indeksy się fragmentują
Indeks bazy danych fizycznie zorganizowany jest jako struktura drzewiasta, złożona z powiązanych ze sobą stron danych. Gdy do tabeli trafia nowy rekord, a odpowiadająca mu strona indeksu jest już pełna, SQL Server dzieli ją na dwie - zjawisko to nazywa się podziałem strony. Każdy taki podział pozostawia obie nowo powstałe strony częściowo puste i rozprasza logicznie sąsiadujące dane fizycznie po różnych miejscach na dysku.
Im więcej operacji wstawiania, aktualizacji i usuwania wykonuje się na tabeli, tym więcej podziałów stron się kumuluje, a odczyt danych wymaga coraz więcej operacji dyskowych, by przejść przez rozproszoną strukturę. W systemie takim jak StudioSystem, gdzie dokumenty magazynowe czy transakcyjne tabele YMS i TCS zapisywane są przez cały dzień roboczy, fragmentacja narasta w sposób ciągły i bez interwencji administratora prowadzi do stopniowego spowolnienia zapytań.
Problem ten dotyka przede wszystkim indeksy na tabelach o dużej liczbie operacji zapisu i niesekwencyjnych wartościach kluczy - na przykład tabele dokumentów magazynowych, do których nowe rekordy trafiają przez cały dzień z wielu równoległych stanowisk. Indeksy na tabelach rzadko modyfikowanych, takich jak część kartotek słownikowych, fragmentują się znacznie wolniej i mogą wymagać odbudowy dużo rzadziej niż tabele transakcyjne.
Konfiguracja w tabeli _jobs
Zadanie odbudowy indeksów wykorzystuje węższy zestaw pól niż zadania kopii zapasowej, ponieważ nie ma tu potrzeby rozróżniania rodzaju operacji ani wskazywania folderu docelowego:
| Pole | Znaczenie |
|---|---|
| OSTATNIOWYKONANO | Data ostatniego poprawnego wykonania zadania |
| CYKLICZNOSC | Liczbowy interwał, co jaki zadanie jest uruchamiane |
| CYKLICZNOSCTYPE | Jednostka interwału - np. godziny, dni |
| MAILPOWIADOMIENIE | Adresy e-mail, na które trafią powiadomienia o wykonaniu |
| CONECTIONSTRINGNAME | Łańcuch połączeniowy wskazujący bazę, w której odbudowywane są indeksy |
Pole CONECTIONSTRINGNAME pełni tutaj kluczową, decydującą rolę - to właśnie na jego podstawie usługa SSJob rozpoznaje, w której konkretnie bazie danych ma faktycznie wykonać odbudowę, co ma znaczenie przy wdrożeniach obsługujących więcej niż jedną bazę na tym samym serwerze.
Utrzymanie wydajności bez ingerencji DBA
Cykliczna odbudowa indeksów odciąża administratora bazy danych od ręcznego monitorowania fragmentacji na co dzień.
Odbudowa a reorganizacja
Odbudowa indeksu, opisana w tym materiale, to nie jedyny sposób walki z fragmentacją. Alternatywą, opisaną osobno w materiale o reorganizacji indeksów, jest operacja lżejsza, porządkująca istniejący indeks bez tworzenia go od nowa:
| Cecha | Odbudowa | Reorganizacja |
|---|---|---|
| Sposób działania | Tworzy indeks od nowa | Porządkuje istniejące strony indeksu |
| Obciążenie serwera | Wysokie | Niższe |
| Skuteczność przy dużej fragmentacji | Wysoka, niezależna od poziomu | Ograniczona |
| Typowe zastosowanie | Wysoki poziom fragmentacji | Niski lub umiarkowany poziom fragmentacji |
W praktyce wiele wdrożeń łączy oba podejścia - reorganizację uruchamia się częściej, jako lekką konserwację, a pełną odbudowę rzadziej, jako gruntowniejsze rozwiązanie problemu, gdy fragmentacja mimo reorganizacji utrzymuje się na wysokim poziomie.
Decyzja, które podejście zastosować, w profesjonalnych wdrożeniach SQL Server opiera się zwykle na zmierzonym poziomie fragmentacji konkretnego indeksu, a nie na sztywnej regule stosowanej identycznie dla całej bazy. Niski poziom fragmentacji, rzędu kilkunastu procent, zwykle nie uzasadnia jeszcze żadnej interwencji. Poziom umiarkowany sugeruje reorganizację, a wysoki, przekraczający kilkadziesiąt procent, uzasadnia już pełną odbudowę. StudioSystem, uruchamiając to zadanie cyklicznie dla całej bazy, upraszcza tę decyzję kosztem pewnej nadmiarowości - część indeksów bywa odbudowywana, mimo że sama reorganizacja by wystarczyła, w zamian za prostotę konfiguracji i brak konieczności ręcznej analizy każdego indeksu z osobna. Warto przy tym pamiętać, że próg procentowy fragmentacji, od którego opłaca się przejść z reorganizacji na pełną odbudowę, w bardziej zaawansowanych wdrożeniach ustala się indywidualnie dla najbardziej obciążonych tabel, zamiast stosować jedną wspólną regułę identyczną dla całej bazy danych.
Harmonogram i obciążenie serwera
Odbudowa indeksu, zwłaszcza dla naprawdę dużych tabel, jest operacją bardzo intensywnie korzystającą z zasobów całego serwera - procesora, pamięci i dysku - i potrafi przy okazji chwilowo blokować dostęp do przebudowywanych aktualnie danych. Z tego powodu harmonogram tego zadania planuje się zwykle na godziny najmniejszego obciążenia platformy, najczęściej w nocy, kiedy liczba aktywnych użytkowników i transakcji jest minimalna.
W miarę wzrostu bazy danych i przybywania kolejnych dokumentów czas trwania odbudowy również rośnie. Warto od czasu do czasu sprawdzić, czy okno czasowe zarezerwowane na to zadanie w harmonogramie wciąż wystarcza, zanim zadanie zacznie nachodzić na godziny pracy użytkowników.
Dla firm działających w wielu strefach czasowych albo obsługujących klientów całodobowo - na przykład magazyny wysyłkowe pracujące na dwie lub trzy zmiany - znalezienie okna bez ruchu bywa trudniejsze niż w typowej firmie pracującej wyłącznie w godzinach dziennych. W takich przypadkach warto rozważyć skrócenie okna odbudowy przez podzielenie zadania na mniejsze porcje, obejmujące tylko wybrane, najbardziej newralgiczne tabele, zamiast całą bazę danych naraz w jednym przebiegu.
Powiadomienia i diagnostyka
Tak jak przy pozostałych zadaniach SSJob, pole MAILPOWIADOMIENIE pozwala otrzymywać potwierdzenie wykonania zadania e-mailem, a pole OSTATNIOWYKONANO w tabeli _jobs pokazuje datę ostatniego poprawnego uruchomienia. Dodatkowej diagnostyki dostarcza Dziennik zdarzeń Windows, do którego usługa zapisuje informacje o swoim działaniu, opisany szerzej przy okazji instalacji usługi SSJob.
Dobre praktyki
Kilka zasad pomaga utrzymać to zadanie efektywnym niezależnie od skali wdrożenia:
- Rozdzielenie w czasie od kopii bazy danych - odbudowa indeksów nie powinna nakładać się w harmonogramie na zadanie kopii bazy MSSQL, bo oba intensywnie obciążają serwer.
- Monitorowanie czasu trwania - wydłużający się czas wykonania zadania jest naturalnym sygnałem, że baza danych rośnie i harmonogram może wymagać korekty.
- Rozważenie reorganizacji jako uzupełnienia - częstsza, lżejsza reorganizacja pomiędzy rzadszymi pełnymi odbudowami ogranicza czas, przez jaki fragmentacja realnie wpływa na wydajność.
- Weryfikacja powiadomień - brak spodziewanego e-maila z potwierdzeniem jest sygnałem ostrzegawczym samym w sobie.
Warto też pamiętać, że skutki zaniedbania tego zadania rzadko są nagłe. W przeciwieństwie do braku kopii zapasowej, którego konsekwencje ujawniają się dopiero w chwili awarii, rosnąca fragmentacja indeksów objawia się stopniowo - kolejne raporty i zestawienia wykonują się z tygodnia na tydzień odrobinę wolniej, aż w pewnym momencie różnica staje się zauważalna dla użytkowników zgłaszających, że system „ostatnio jakoś zwolnił”. Regularna, cykliczna odbudowa indeksów zapobiega temu powolnemu, ale realnemu pogarszaniu się komfortu pracy z systemem.
Podsumowanie
Odbudowa indeksów to zadanie SSJob przeciwdziałające naturalnej fragmentacji struktur przyspieszających wyszukiwanie danych w bazie StudioSystem. Konfiguruje się je jednym, pojedynczym wierszem w tabeli _jobs, wskazując bazę danych oraz harmonogram uruchomień, najlepiej ustawiony w godzinach najmniejszego obciążenia serwera.
Tam, gdzie pełna odbudowa okazuje się zbyt kosztowna dla bieżącego harmonogramu, naturalnym uzupełnieniem jest lżejsza reorganizacja indeksów, opisana szerzej w kolejnym materiale tej samej serii poświęconej utrzymaniu bazy danych.