MAX_STORAGE_SIZE_MB

MAX_STORAGE_SIZE_MB to limit przestrzeni przydzielonej Query Store — po jego wyczerpaniu zbieranie danych zostaje wstrzymane.

MAX_STORAGE_SIZE_MB jako granica pojemności Query Store

Parametr MAX_STORAGE_SIZE_MB określa maksymalny rozmiar obszaru, w którym mechanizm Query Store przechowuje informacje o wykonywanych zapytaniach. Gromadzone mogą być między innymi teksty zapytań, plany wykonania, statystyki czasowe, dane o liczbie uruchomień oraz informacje potrzebne do obserwowania zmian wydajności. Wartość parametru odnosi się do przestrzeni przeznaczonej na te dane, a nie do całego pliku bazy danych ani do wolnego miejsca na fizycznym dysku.

Znaczenie tego ustawienia jest praktyczne: Query Store nie może bez ograniczeń zwiększać zajmowanego obszaru, ponieważ mogłoby to wpływać na dostępne zasoby bazy. Po osiągnięciu ustalonego limitu system przechodzi w stan, w którym nowe informacje nie są dopisywane w zwykłym trybie. W rezultacie historia zapytań przestaje się rozszerzać, mimo że sama baza danych nadal może działać i przyjmować operacje użytkowników. Nie oznacza to automatycznego usunięcia całej bazy ani awarii serwera, lecz ograniczenie dalszego zbierania danych diagnostycznych.

Warto pamiętać, że MAX_STORAGE_SIZE_MB nie jest ustawieniem określającym rozmiar tabel użytkowych, indeksów, kopii zapasowych ani dziennika transakcji. Dotyczy wyłącznie magazynu Query Store powiązanego z konkretną bazą. Z tego powodu analiza parametru powinna obejmować także stan pozostałych obszarów bazy, lecz nie należy utożsamiać ich z limitem Query Store.

MAX_STORAGE_SIZE_MB na tle innych ustawień monitorowania

Limit MAX_STORAGE_SIZE_MB działa razem z regułami retencji i sposobem agregowania statystyk. Sam rozmiar magazynu nie przesądza o tym, jak długo pozostaną dostępne informacje. Na zajętość wpływają również liczba różnych zapytań, zmienność ich tekstu, liczba obserwowanych planów oraz częstotliwość zapisu statystyk. Dwie bazy o podobnym ruchu mogą więc wykorzystywać przestrzeń w różnym tempie.

Ważne jest odróżnienie limitu pojemności od interwału gromadzenia danych. Interwał określa, jak często statystyki są odświeżane lub zapisywane, natomiast MAX_STORAGE_SIZE_MB wyznacza granicę łącznego miejsca zajmowanego przez Query Store. Skrócenie interwału może dostarczać bardziej szczegółowego obrazu zmian, ale jednocześnie może zwiększyć tempo przyrostu danych. Z kolei rzadsze zapisywanie może ograniczyć narzut, lecz zmniejsza szczegółowość obserwacji.

Inaczej działa także okres przechowywania danych. Retencja może powodować usuwanie starszych informacji, gdy przestają być potrzebne zgodnie z przyjętą polityką. Limit pojemności jest natomiast zabezpieczeniem przed przekroczeniem ustalonego rozmiaru. W dobrze przygotowanej konfiguracji oba mechanizmy współpracują: starsze dane są usuwane w przewidywalny sposób, a magazyn pozostaje dostępny na nowe obserwacje.

Nie należy również porównywać MAX_STORAGE_SIZE_MB bezpośrednio z limitem pamięci RAM. Query Store wykorzystuje trwały magazyn związany z bazą, choć operacje odczytu i zapisu mogą korzystać z pamięci systemowej. Wydajność zależy więc od kilku elementów: obciążenia procesora, szybkości podsystemu dyskowego, liczby zapytań oraz ustawień samego mechanizmu.

MAX_STORAGE_SIZE_MB a typowe problemy z Query Store

Jednym z częstych problemów jest stopniowe zapełnianie magazynu przez bardzo dużą liczbę unikatowych zapytań. Może do tego dochodzić w aplikacjach, które budują tekst SQL dynamicznie i umieszczają zmienne wartości bez właściwego parametryzowania. Dla Query Store kolejne warianty tekstu mogą wyglądać jak osobne zapytania, przez co historia rośnie szybciej, niż wynikałoby to z samej liczby operacji wykonywanych przez użytkowników.

Innym źródłem wzrostu zajętości jest występowanie wielu planów dla tego samego zapytania. Zmiana planu może być korzystna, gdy wynika z dopasowania do aktualnych danych, ale duża liczba planów utrudnia analizę i zajmuje dodatkową przestrzeń. Warto sprawdzać, czy zmienność planów jest uzasadniona, czy może wskazuje na niestabilne statystyki, niewłaściwe indeksowanie albo różnice w parametrach wejściowych.

Po przekroczeniu dostępnego miejsca diagnostyka może stać się niepełna. W raportach zabraknie najnowszych obserwacji, przez co trudniej będzie ustalić, kiedy rozpoczęło się spowolnienie i jakie zapytania miały w nim udział. Problem może być szczególnie widoczny przy analizie okresowej: starsze dane będą dostępne, ale nie pojawią się kolejne próbki, które pozwoliłyby porównać bieżący stan z wcześniejszym.

Nie powinno się jednak reagować wyłącznie przez mechaniczne zwiększanie limitu. Jeżeli Query Store rośnie z powodu niekontrolowanej liczby wariantów zapytań, większy magazyn jedynie odsunie moment wystąpienia problemu. Najpierw należy ustalić przyczynę przyrostu, ocenić wartość przechowywanych danych i sprawdzić, czy polityka retencji odpowiada rzeczywistym potrzebom.

MAX_STORAGE_SIZE_MB w praktycznej kontroli pojemności

Kontrola powinna zaczynać się od sprawdzenia aktualnego wykorzystania przestrzeni oraz odczytania stanu Query Store. Przydatne jest porównanie zajętości w kilku punktach czasu, ponieważ pojedynczy odczyt nie pokazuje tempa wzrostu. Jeżeli magazyn przyrasta równomiernie, można zaplanować dalsze działania. Gwałtowny skok powinien skłonić do poszukania zmian w aplikacji, wdrożenia nowych modułów albo nietypowego obciążenia.

W analizie warto uwzględnić zapytania zajmujące najwięcej miejsca oraz te, które występują w wielu odmianach. Pomocne bywa zestawienie liczby zapytań, liczby planów, częstotliwości wykonań i kosztu przechowywania. Sama liczba uruchomień nie wystarcza do oceny sytuacji: zapytanie wykonywane rzadko może generować wiele wariantów, a zapytanie częste może mieć niewielki ślad w magazynie, jeśli pozostaje stabilne.

Zmiany limitu powinny być wykonywane po uwzględnieniu dostępnej przestrzeni i przyjętej polityki utrzymania. Warto dokumentować wartość przed zmianą, powód modyfikacji oraz oczekiwany efekt. Po zastosowaniu ustawienia należy ponownie zweryfikować stan magazynu i obserwować, czy dane są rejestrowane. Jeżeli problem wynika z błędnej konfiguracji, może być potrzebne uporządkowanie historii Query Store zgodnie z procedurą właściwą dla danego środowiska.

Dobrym zwyczajem jest ustalenie progu ostrzegawczego przed osiągnięciem maksymalnej wartości. Pozwala to zareagować z wyprzedzeniem, zanim zbieranie nowych informacji zostanie zatrzymane. Monitoring powinien obejmować także błędy mechanizmu, przerwy w rejestrowaniu oraz zmiany konfiguracji wykonywane podczas wdrożeń. Dzięki temu MAX_STORAGE_SIZE_MB staje się elementem planowej kontroli, a nie ustawieniem sprawdzanym dopiero po pojawieniu się braków w historii.

Kiedy zgłosić MAX_STORAGE_SIZE_MB do serwisu komputerowego

Wsparcie techniczne jest zasadne, gdy Query Store przestaje przyjmować nowe dane, limit szybko się wyczerpuje albo po zmianie konfiguracji nie pojawiają się oczekiwane statystyki. Zgłoszenie powinno zawierać nazwę bazy, aktualny stan Query Store, obserwowane tempo wzrostu, informacje o ostatnich zmianach aplikacji oraz opis momentu, od którego diagnostyka stała się niepełna. Takie dane ułatwiają odróżnienie problemu z limitem od kłopotów z miejscem na dysku, uprawnieniami lub stanem samej bazy.

Pomoc można uzyskać w Warszawskim Pogotowiu Komputerowym 24/7, kontaktując się telefonicznie pod numerem +48 22 100 48 29. W ramach zgłoszenia można uporządkować interpretację ustawienia, sprawdzić zależności między pojemnością a retencją oraz przygotować bezpieczny plan dalszej obserwacji. Przed przekazaniem dostępu warto zabezpieczyć kopię konfiguracji i zanotować dotychczasowe wartości, aby możliwe było porównanie stanu przed i po wykonanych czynnościach.

Nie należy czekać do chwili całkowitego zatrzymania gromadzenia danych, jeżeli Query Store jest istotnym źródłem informacji o wydajności. Wczesne wykrycie szybkiego przyrostu pozwala ustalić, czy przyczyną jest konstrukcja zapytań, liczba planów, zbyt długa retencja, nietrafiony interwał zapisu czy po prostu zbyt mała przestrzeń przewidziana dla danej bazy. Dzięki temu MAX_STORAGE_SIZE_MB może zostać dopasowany do realnego sposobu pracy systemu, a historia potrzebna do diagnozowania spowolnień pozostanie użyteczna.