Reorganizacja indeksów to zadanie cykliczne usługi SSJob, porządkujące fizyczny układ stron istniejącego indeksu bez tworzenia go od nowa. W przeciwieństwie do pełnej odbudowy indeksów jest operacją lżejszą, działającą online i możliwą do uruchamiania częściej.
Czym jest reorganizacja indeksów
Reorganizacja indeksów to druga - obok opisanej osobno odbudowy indeksów - metoda przeciwdziałania fragmentacji struktur przyspieszających wyszukiwanie danych w bazie StudioSystem. Zamiast tworzyć indeks od podstaw, reorganizacja porządkuje strony już istniejącego indeksu, dopasowując ich fizyczny układ na dysku do logicznej kolejności kluczy.
Zadanie to, podobnie jak pozostałe zadania cykliczne opisane przy okazji kopii bazy MSSQL i kopii aplikacji, korzysta z tego samego mechanizmu usługi SSJob - wiersza w tabeli _jobs z ustawianym harmonogramem oraz powiadomieniami e-mail. Różnica leży wyłącznie w rodzaju wykonywanej operacji, nie w sposobie jej skonfigurowania.
W praktyce reorganizacja pełni rolę lekkiej, częstej konserwacji, uzupełniającej rzadziej uruchamianą pełną odbudowę - dwa zadania, które razem utrzymują wydajność zapytań na akceptowalnym poziomie przy rozsądnym zużyciu zasobów serwera.
Jak działa reorganizacja
Mechanizm reorganizacji przegląda istniejące strony liścia indeksu i fizycznie przestawia je tak, by ich kolejność na dysku odpowiadała logicznej kolejności kluczy indeksu. Dodatkowo operacja ta porządkuje wypełnienie stron zgodnie z ustawionym parametrem fill factor, zagęszczając dane tam, gdzie to możliwe, i zwalniając miejsce zajmowane wcześniej przez częściowo puste strony powstałe w wyniku podziałów.
Kluczową cechą odróżniającą reorganizację od odbudowy jest to, że jest ona operacją online - wykonuje się na małych, przyrostowych porcjach danych i nie wymaga blokady uniemożliwiającej innym procesom odczyt czy zapis w tym samym czasie. Dzięki temu reorganizację można częściej uruchamiać także w godzinach, w których na serwerze pojawia się pewien ruch, bez ryzyka zauważalnego zablokowania użytkowników korzystających w tym czasie z systemu.
Reorganizacja nie usuwa jednak fragmentacji równie skutecznie jak odbudowa - przy bardzo wysokim jej poziomie porządkowanie kolejnych stron trwa proporcjonalnie długo i nie zawsze prowadzi do tak dobrego rezultatu, jaki dawałoby utworzenie indeksu od nowa. Istotna jest też różnica w zużyciu przestrzeni tymczasowej serwera - odbudowa indeksu, zwłaszcza dużego, wymaga w trakcie działania dodatkowego miejsca w bazie tempdb na potrzeby utworzenia nowej struktury obok starej, podczas gdy reorganizacja przestawia strony w miejscu, praktycznie bez dodatkowego zapotrzebowania na przestrzeń tymczasową. Ta różnica bywa istotna przy wdrożeniach z ograniczoną przestrzenią dyskową zarezerwowaną dla bazy danych.
Konfiguracja w tabeli _jobs
Zadanie reorganizacji indeksów korzysta z tego samego, węższego zestawu pól co odbudowa - bez rozróżniania rodzaju operacji czy 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 reorganizowane są indeksy |
Podobnie jak przy odbudowie, pole CONECTIONSTRINGNAME decyduje o tym, w której konkretnie bazie danych usługa SSJob ma wykonać reorganizację - istotne przy wdrożeniach obsługujących z jednego serwera więcej niż jedną instalację StudioSystem.
Lekka konserwacja bez przestojów
Cykliczna reorganizacja indeksów działa w tle, nie blokując pracy użytkowników korzystających w tym czasie z systemu.
Reorganizacja a odbudowa
Wybór między reorganizacją a pełną odbudową indeksów zależy przede wszystkim od zmierzonego poziomu fragmentacji konkretnego indeksu oraz od dostępnego okna czasowego na wykonanie zadania:
| Cecha | Reorganizacja | Odbudowa |
|---|---|---|
| Sposób działania | Porządkuje istniejące strony indeksu | Tworzy indeks od nowa |
| Obciążenie serwera | Niższe | Wysokie |
| Blokowanie dostępu do danych | Brak - operacja online | Możliwe przy dużych indeksach |
| Skuteczność przy dużej fragmentacji | Ograniczona | Wysoka, niezależna od poziomu |
| Typowa częstotliwość uruchamiania | Częsta - nawet codziennie | Rzadsza - np. raz w tygodniu |
W wielu wdrożeniach oba zadania stosuje się równolegle jako komplementarną parę - częstsza reorganizacja ogranicza narastanie fragmentacji na co dzień, a rzadsza pełna odbudowa porządkuje te indeksy, w których fragmentacja mimo to zdążyła osiągnąć wysoki poziom.
Kiedy stosować reorganizację
Decyzję o wyborze reorganizacji zamiast pełnej odbudowy w profesjonalnych wdrożeniach SQL Server opiera się zwykle na zmierzonym procentowym poziomie fragmentacji konkretnego indeksu. Niski poziom fragmentacji, rzędu kilkunastu procent, zwykle nie uzasadnia jeszcze żadnej interwencji. Poziom umiarkowany, orientacyjnie od kilkunastu do kilkudziesięciu procent, jest klasycznym wskazaniem do reorganizacji - operacja ta wystarcza, by przywrócić rozsądną wydajność zapytań bez nadmiernego obciążania serwera. Warto przy tym pamiętać, że fragmentacja poszczególnych indeksów w tej samej bazie danych rzadko narasta w jednakowym tempie - indeksy na często modyfikowanych tabelach dokumentów magazynowych wymagają zwykle częstszej reorganizacji niż indeksy na rzadziej zmienianych kartotekach słownikowych.
Gdy fragmentacja przekracza próg kilkudziesięciu procent, reorganizacja porządkuje strony zbyt wolno w stosunku do skali problemu i lepszym rozwiązaniem staje się pełna odbudowa, opisana szerzej w materiale o odbudowie indeksów. StudioSystem, uruchamiając zadania cyklicznie dla całej bazy, upraszcza tę decyzję kosztem pewnej nadmiarowości, w zamian oferując prostotę konfiguracji bez konieczności ręcznej analizy każdego indeksu z osobna.
Harmonogram i obciążenie serwera
Ponieważ reorganizacja jest operacją online i znacznie lżejszą niż pełna odbudowa, jej harmonogram można ustawić bardziej elastycznie niż w przypadku zadań intensywnie obciążających serwer. Wielu administratorów uruchamia reorganizację codziennie lub co kilka dni, nawet w godzinach, w których na serwerze pojawia się umiarkowany ruch użytkowników.
Mimo to, przy naprawdę dużych tabelach - takich jak dokumenty magazynowe zapisywane przez cały dzień roboczy z wielu równoległych stanowisk - warto rozważyć uruchamianie reorganizacji w godzinach nieco mniejszego obciążenia, by ograniczyć jej wpływ na czas odpowiedzi pozostałych zapytań wykonywanych równolegle.
Podobnie jak przy odbudowie, warto unikać nakładania się harmonogramu reorganizacji na inne intensywne zadania SSJob, w tym na kopię bazy MSSQL - nawet lekka operacja bazodanowa uruchomiona równolegle z kopią zapasową może niepotrzebnie wydłużyć czas trwania obu zadań.
Dobre praktyki
Kilka zasad pomaga utrzymać zadanie reorganizacji efektywnym niezależnie od skali wdrożenia:
- Traktowanie jako uzupełnienia, nie zamiennika - reorganizacja nie zastępuje w pełni odbudowy indeksów przy wysokim poziomie fragmentacji, tylko ogranicza tempo jej narastania.
- Częstsze uruchamianie niż odbudowy - dzięki niższemu obciążeniu serwera reorganizację można bezpiecznie zaplanować częściej, nawet codziennie.
- Rozdzielenie w czasie od innych zadań SSJob - unikanie nakładania się harmonogramu na kopię bazy danych czy odbudowę indeksów ogranicza łączne obciążenie serwera.
- Weryfikacja powiadomień - brak spodziewanego e-maila z potwierdzeniem wykonania jest sygnałem ostrzegawczym samym w sobie.
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 reorganizacji. Dodatkowej diagnostyki, przydatnej zwłaszcza przy diagnozowaniu nieudanych uruchomień, dostarcza Dziennik zdarzeń Windows, do którego usługa zapisuje informacje o swoim działaniu - mechanizm ten opisano szerzej przy okazji instalacji usługi SSJob.
Podobnie jak przy odbudowie, skutki zaniedbania reorganizacji rzadko są nagłe - fragmentacja narasta stopniowo, a jej wpływ na wydajność ujawnia się dopiero po dłuższym czasie, gdy kolejne raporty i zestawienia wykonują się zauważalnie wolniej niż jeszcze kilka tygodni wcześniej. Regularna, cykliczna reorganizacja, uzupełniona rzadszą pełną odbudową, zapobiega temu powolnemu pogarszaniu się komfortu pracy z systemem.
Podsumowanie
Reorganizacja indeksów to lżejsze, częściej uruchamiane zadanie SSJob, uzupełniające pełną odbudowę w walce z naturalną fragmentacją struktur przyspieszających wyszukiwanie danych w bazie StudioSystem. Konfiguruje się je jednym, pojedynczym wierszem w tabeli _jobs, wskazując bazę danych oraz harmonogram uruchomień, bez konieczności rozróżniania rodzaju operacji.
Tam, gdzie sama reorganizacja przestaje wystarczać, naturalnym uzupełnieniem jest pełna odbudowa indeksów, opisana szerzej w poprzednim materiale tej samej serii poświęconej utrzymaniu bazy danych StudioSystem. Kolejnym krokiem w tej samej serii jest zadanie organizacji bazy danych, porządkujące kolejny aspekt techniczny wpływający na stabilną pracę platformy.