Organizacja bazy danych to trzecie, obok odbudowy i reorganizacji indeksów, zadanie cykliczne usługi SSJob dbające o wydajność bazy StudioSystem. Aktualizuje ono statystyki, na podstawie których optymalizator zapytań SQL Server podejmuje decyzje o sposobie wykonania poszczególnych zapytań.
Czym jest organizacja bazy danych
Organizacja bazy danych to trzecie zadanie z serii poświęconej utrzymaniu wydajności bazy StudioSystem, obok opisanej wcześniej odbudowy oraz reorganizacji indeksów. O ile tamte dwa zadania porządkują fizyczną strukturę indeksów, o tyle organizacja bazy danych zajmuje się czymś innym - aktualizacją statystyk, na podstawie których silnik bazy danych podejmuje decyzje o sposobie wykonania zapytań.
Tak jak pozostałe zadania SSJob opisane przy okazji kopii bazy MSSQL i kopii aplikacji, organizacja bazy danych korzysta z tego samego mechanizmu - wiersza w tabeli _jobs z ustawianym harmonogramem oraz powiadomieniami e-mail. Różni się jedynie rodzajem wykonywanej operacji wewnątrz bazy danych.
Czym są statystyki bazy danych
Statystyki bazy danych to wewnętrzna struktura SQL Server opisująca przybliżony rozkład wartości w kolumnach tabeli, zapisana w formie histogramu. Na podstawie statystyk optymalizator zapytań szacuje, ile wierszy zwróci dana operacja filtrowania, złączenia czy sortowania, zanim jeszcze faktycznie wykona zapytanie - a od trafności tego szacunku zależy, jaki plan wykonania zostanie wybrany.
Błędny szacunek liczby wierszy - na przykład wynikający z nieaktualnych statystyk - może skłonić optymalizator do wybrania planu zoptymalizowanego pod niewielki zbiór danych tam, gdzie w rzeczywistości trzeba przetworzyć miliony wierszy, albo odwrotnie. Skutkiem bywa zapytanie wykonujące się zauważalnie wolniej, mimo że odpowiednie indeksy - opisane przy okazji odbudowy i reorganizacji - są obecne i wcale nie są nadmiernie sfragmentowane.
Statystyki można aktualizować na dwa sposoby - poprzez pełne skanowanie wszystkich wierszy tabeli, dające najdokładniejszy obraz rozkładu danych, albo poprzez skanowanie próbkowe, obejmujące jedynie część wierszy wybranych losowo. Pełne skanowanie jest dokładniejsze, ale bardziej obciąża serwer i trwa dłużej, dlatego przy bardzo dużych tabelach transakcyjnych StudioSystem częściej stosuje się rozsądnie dobraną próbkę, wystarczającą do zachowania trafności szacunków optymalizatora bez nadmiernego wydłużania czasu wykonania samego zadania.
Dlaczego statystyki się dezaktualizują
Każda operacja wstawienia, aktualizacji lub usunięcia danych zmienia rzeczywisty rozkład wartości w tabeli, podczas gdy statystyki pozostają niezmienione aż do ich kolejnej aktualizacji. SQL Server potrafi wprawdzie aktualizować statystyki automatycznie, jednak dzieje się to dopiero po przekroczeniu określonego progu zmian w tabeli, co przy dużych, intensywnie obsługiwanych tabelach transakcyjnych StudioSystem - dokumentach magazynowych, kartotekach czy tabelach YMS i TCS - bywa zbyt rzadkie, by statystyki na bieżąco odzwierciedlały aktualny stan danych.
Cykliczne, wymuszone odświeżenie statystyk poza wbudowanym mechanizmem automatycznym pozwala uniknąć sytuacji, w której optymalizator zapytań przez dłuższy czas opiera się na danych nieaktualnych, mimo że sam mechanizm automatyczny formalnie działa poprawnie. Historycznie próg uruchamiający automatyczną aktualizację statystyk w SQL Server wynosił około dwudziestu procent zmienionych wierszy tabeli, co przy naprawdę dużych tabelach oznaczało, że statystyki potrafiły pozostawać nieaktualne bardzo długo, zanim zmiana osiągnęła wymagany procentowo próg.
Konfiguracja w tabeli _jobs
Zadanie organizacji bazy danych korzysta z tego samego, węższego zestawu pól co odbudowa i reorganizacja indeksów - 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 aktualizowane są statystyki |
Podobnie jak przy pozostałych zadaniach tej serii, pole CONECTIONSTRINGNAME decyduje o tym, w której konkretnie bazie danych usługa SSJob ma wykonać aktualizację statystyk - istotne przy wdrożeniach obsługujących z jednego serwera więcej niż jedną instalację StudioSystem.
Aktualne statystyki bez ingerencji DBA
Cykliczna aktualizacja statystyk utrzymuje trafność planów wykonania zapytań bez ręcznego monitorowania przez administratora.
Związek z odbudową i reorganizacją indeksów
Zadanie organizacji bazy danych nie działa w oderwaniu od pozostałych dwóch zadań tej serii - jego znaczenie wynika bezpośrednio z tego, jak dokładnie działają odbudowa i reorganizacja indeksów:
| Operacja | Wpływ na statystyki |
|---|---|
| Odbudowa indeksu | Aktualizuje powiązane statystyki jako efekt uboczny, z pełnym skanowaniem danych |
| Reorganizacja indeksu | Nie aktualizuje statystyk w żadnym zakresie |
| Organizacja bazy danych | Aktualizuje statystyki niezależnie od tego, co dzieje się z indeksami |
Pełna odbudowa indeksu aktualizuje powiązane z nim statystyki automatycznie, ponieważ w trakcie tworzenia indeksu od nowa SQL Server i tak przegląda wszystkie dane. Reorganizacja indeksu nie ma tej właściwości - jest operacją znacznie lżejszą, ale nie dotyka statystyk w żadnym zakresie. W wdrożeniach, które ze względu na obciążenie serwera opierają się głównie na częstej, lekkiej reorganizacji zamiast rzadszej pełnej odbudowy, osobne zadanie organizacji bazy danych staje się właściwie niezbędne, by statystyki nie pozostawały nieaktualne przez długi czas.
Harmonogram i obciążenie serwera
Aktualizacja statystyk dla dużych tabel wymaga przejrzenia znaczącej części, a przy pełnym skanowaniu - całości danych, co czyni ją operacją zauważalnie obciążającą serwer, choć zwykle nie aż tak intensywnie jak pełna odbudowa dużych indeksów. Z tego powodu harmonogram tego zadania planuje się, podobnie jak pozostałe zadania utrzymaniowe, na godziny najmniejszego obciążenia platformy.
Warto rozdzielić w czasie organizację bazy danych od kopii bazy MSSQL oraz od odbudowy i reorganizacji indeksów - uruchomienie kilku intensywnych zadań równolegle w tym samym oknie nocnym może niepotrzebnie wydłużyć czas trwania każdego z nich i zawęzić margines bezpieczeństwa przed rozpoczęciem pracy przez użytkowników rano.
Dobre praktyki
Kilka zasad pomaga utrzymać zadanie organizacji bazy danych efektywnym niezależnie od skali wdrożenia:
- Traktowanie jako uzupełnienia indeksów, nie ich zamiennika - aktualne statystyki nie zastępują dobrze utrzymanych, mało sfragmentowanych indeksów, tylko pozwalają optymalizatorowi w pełni z nich korzystać.
- Szczególna uwaga przy częstej reorganizacji - skoro reorganizacja nie aktualizuje statystyk, wdrożenia opierające się głównie na niej powinny traktować to zadanie priorytetowo.
- 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ń - pole
MAILPOWIADOMIENIEpozwala na bieżąco kontrolować wykonanie zadania, a poleOSTATNIOWYKONANOw tabeli_jobspotwierdza datę ostatniego poprawnego uruchomienia. - Obserwacja czasu wykonania w czasie - wydłużające się z tygodnia na tydzień wykonanie zadania organizacji bazy danych jest naturalnym sygnałem wzrostu bazy, podobnie jak przy odbudowie czy reorganizacji indeksów.
Warto też pamiętać, że statystyki dotyczą nie tylko tabel powiązanych z indeksami, ale wszystkich kolumn wykorzystywanych w warunkach zapytań, złączeniach czy grupowaniach - również tych, na których nie założono żadnego indeksu. Dlatego zadanie organizacji bazy danych ma znaczenie szersze niż tylko uzupełnienie odbudowy i reorganizacji, obejmując swoim działaniem cały obraz statystyczny bazy danych StudioSystem, z którego korzysta optymalizator zapytań przy planowaniu każdego pojedynczego zapytania wykonywanego przez aplikację.
Podobnie jak przy pozostałych zadaniach tej serii, skutki zaniedbania organizacji bazy danych rzadko są nagłe - nieaktualne statystyki objawiają się stopniowym, trudnym do jednoznacznego zdiagnozowania spowolnieniem wybranych zapytań, które łatwo błędnie przypisać innej przyczynie, zamiast rozpoznać w nich efekt przestarzałych danych używanych przez optymalizator.
Podsumowanie
Organizacja bazy danych to zadanie SSJob domykające triadę utrzymania wydajności bazy StudioSystem, obok odbudowy i reorganizacji indeksów. Konfiguruje się je jednym, pojedynczym wierszem w tabeli _jobs, wskazując bazę danych oraz harmonogram uruchomień, najlepiej ustawiony w godzinach najmniejszego obciążenia serwera.
Razem, wszystkie trzy zadania - odbudowa indeksów, reorganizacja indeksów i organizacja bazy danych - tworzą kompletny zestaw automatycznych czynności utrzymaniowych, uzupełniający zadania kopii zapasowej opisane w materiale o instalacji usługi SSJob. Skonfigurowanie ich wszystkich jako osobnych, dobrze rozłożonych w czasie wierszy tabeli _jobs pozwala utrzymać wydajność bazy StudioSystem na stabilnym poziomie przez długi czas, bez konieczności ręcznej interwencji administratora.