Memory Grants

Memory Grants to pamięć przydzielana zapytaniom na operacje sortowania i mieszania — zbyt duże przydziały blokują inne zapytania.

Memory Grants jako przydział pamięci dla zapytań

Memory Grants oznacza obszar pamięci operacyjnej rezerwowany przez silnik bazy danych na wykonanie operacji, które nie mogą być przeprowadzone wyłącznie w prostym odczycie wierszy. Najczęściej chodzi o sortowanie wyników, grupowanie, łączenie zbiorów danych oraz tworzenie struktur pomocniczych potrzebnych do realizacji planu wykonania. Przydział jest ustalany na podstawie informacji dostępnych w chwili kompilowania zapytania, między innymi przewidywanej liczby wierszy, szerokości rekordów, rodzaju operatorów i ustawień środowiska.

Nie należy utożsamiać Memory Grants z pamięcią zajmowaną przez całą bazę danych ani z pojemnością plików danych. Jest to część zasobów wykorzystywana tymczasowo przez konkretne zapytanie lub partię zapytań. Po zakończeniu pracy zasób może zostać zwolniony i użyty ponownie. Znaczenie ma więc nie tylko wielkość pojedynczego przydziału, lecz także liczba jednocześnie wykonywanych operacji, ich czas trwania oraz sposób zarządzania pamięcią przez system bazodanowy.

Jeżeli zapytanie otrzyma zbyt mały przydział, operacja sortowania lub mieszania może zostać przeniesiona częściowo na dysk. Zwiększa to liczbę operacji wejścia i wyjścia, wydłuża czas odpowiedzi i może powodować skoki obciążenia. Zbyt duży przydział prowadzi do innego rodzaju problemu: pamięć zostaje zarezerwowana, choć nie jest w pełni wykorzystywana, a inne zapytania muszą czekać na dostęp do zasobów.

Memory Grants w planie wykonania i w porównaniu z pamięcią podręczną

W analizie planu wykonania warto odróżnić kilka pojęć, które bywają łączone w jedną kategorię. Pamięć podręczna przechowuje strony danych i indeksów, aby kolejne odczyty mogły odbywać się szybciej. Memory Grants służą natomiast przede wszystkim operatorom planu wymagającym roboczej przestrzeni. Sortowanie po kolumnie, agregowanie wielu wierszy, budowanie tablic mieszających przy łączeniu tabel oraz niektóre operacje związane z funkcjami okna mogą potrzebować takiej rezerwy.

W planie wykonania można porównywać przydział oczekiwany, przydział faktycznie wykorzystany oraz zakres pamięci wymagany przez operatorów. Różnica między tymi wartościami jest ważną wskazówką diagnostyczną. Jeżeli użycie pozostaje znacznie poniżej przydziału, przyczyną może być zawyżona estymacja liczby wierszy, nieaktualne statystyki, zbyt szerokie kolumny uwzględnione w zapytaniu albo plan przygotowany dla innego wariantu parametrów. Jeżeli zapotrzebowanie przekracza dostępną rezerwę, widoczne mogą być operacje spill, czyli zapisywanie danych roboczych do obszaru tymczasowego.

Warto również odróżnić oczekiwanie na Memory Grants od zwykłego oczekiwania na blokadę. W pierwszym przypadku zapytanie czeka na odpowiednią porcję pamięci, ponieważ dostępne zasoby zostały przydzielone innym zadaniom. W drugim przypadku problem dotyczy współbieżnego dostępu do obiektów lub wierszy. Oba zjawiska mogą pojawić się w tym samym czasie, lecz wymagają innego sposobu rozpoznania i usuwania.

Memory Grants a typowe problemy wydajnościowe

Najczęściej spotykanym problemem jest niedokładna estymacja kardynalności, czyli błędna ocena liczby wierszy, które przejdą przez dany operator. Jeżeli silnik spodziewa się niewielkiego zbioru, może przydzielić zbyt mało pamięci dla sortowania lub łączenia. Rzeczywisty zbiór okazuje się większy, dlatego część danych zostaje obsłużona poza pamięcią. Objawem może być wysoki czas wykonania, wzrost aktywności dysku tymczasowego oraz różnica między liczbą wierszy przewidywaną a rzeczywistą.

Odwrotna sytuacja występuje wtedy, gdy predykat jest mało selektywny, statystyki nie odzwierciedlają aktualnego rozkładu danych albo zapytanie otrzymuje wartości parametrów nietypowe dla planu, który został zapisany wcześniej. Wówczas przydział pamięci może być nadmierny. Pojedyncze wykonanie nie musi ujawnić problemu, ale przy dużej współbieżności kilka dużych rezerw może doprowadzić do kolejek, presji pamięci i opóźnienia prostszych zapytań.

Niepożądane skutki mogą wynikać także z konstrukcji samego zapytania. Pobieranie większej liczby kolumn niż potrzebna, sortowanie przed ograniczeniem zbioru, łączenie tabel bez odpowiednich warunków oraz funkcje wykonywane na kolumnach używanych do filtrowania utrudniają wybór efektywnego planu. Niekiedy problem nie polega na braku pamięci, lecz na tym, że zapytanie wymusza kosztowną operację, której można uniknąć przez zmianę kolejności działań, zawężenie projekcji lub poprawę indeksowania.

W środowiskach o zmiennym obciążeniu znaczenie ma również czas życia przydziału. Długie zapytanie może utrzymywać zarezerwowaną pamięć przez cały okres działania, nawet gdy chwilowo wykonuje inne etapy planu. Z tego powodu trzeba analizować nie tylko pojedynczy rekord z monitoringu, ale także powtarzalność zjawiska, porę występowania, równoległość i liczbę oczekujących żądań.

Memory Grants i praktyczne wskazówki diagnostyczne

Diagnostykę można rozpocząć od zebrania planu wykonania oraz informacji o rzeczywistym i przewidywanym użyciu pamięci. Należy sprawdzić, który operator otrzymał największy przydział, czy wystąpiło zapisanie danych roboczych na dysk oraz czy szacunki liczby wierszy były zbliżone do rzeczywistości. Pomocne jest zestawienie kilku wykonań tego samego zapytania z różnymi parametrami, ponieważ problem może pojawiać się tylko dla określonego zakresu danych.

Kolejnym krokiem powinno być sprawdzenie aktualności statystyk i rozkładu wartości w kolumnach wykorzystywanych w filtrach oraz warunkach łączenia. Samo odświeżenie statystyk nie zawsze rozwiązuje problem, ale może ujawnić, że wcześniejszy plan opierał się na nieaktualnych informacjach. W razie potrzeby analizuje się indeksy, typy danych, konwersje niejawne, szerokość zwracanych rekordów i sposób przekazywania parametrów.

Warto ograniczać zakres danych możliwie wcześnie. Zamiast pobierać pełne rekordy i filtrować je dopiero na końcu, lepiej przekazać warunki do operatorów, które mogą zmniejszyć zbiór przed sortowaniem lub grupowaniem. Przydatne bywa także rozdzielenie bardzo rozbudowanego zapytania na etapy, jeżeli pozwala to uzyskać lepsze estymacje i kontrolować rozmiar zbiorów pośrednich. Każda taka zmiana powinna być oceniana na podstawie planu i pomiaru czasu, ponieważ pozornie prostsza forma nie zawsze oznacza mniejsze zapotrzebowanie na zasoby.

Nie powinno się zwiększać globalnych limitów pamięci jako pierwszej reakcji na pojedyncze wolne zapytanie. Taka decyzja może ukryć przyczynę i zmniejszyć zasoby dostępne dla systemu operacyjnego lub innych usług. Najpierw należy ustalić, czy problem wynika z planu, danych, statystyk, indeksów, współbieżności czy niewłaściwego wzorca zapytań. Dopiero na tej podstawie można oceniać ustawienia instancji, stopień równoległości i mechanizmy ograniczające wpływ dużych operacji.

Memory Grants oraz moment zgłoszenia problemu do serwisu

W praktyce problemy z Memory Grants często są zauważane jako ogólne spowolnienie komputera, długie oczekiwanie aplikacji, okresowe zawieszanie interfejsu albo nieproporcjonalny wzrost użycia pamięci i dysku. Jeżeli zjawisko występuje tylko podczas pracy z konkretnym programem bazodanowym, przydatne jest zapisanie godziny, rodzaju wykonywanej operacji, liczby użytkowników oraz informacji o tym, czy problem ustępuje po zakończeniu dużego zadania. Takie dane ułatwiają oddzielenie kłopotu z zapytaniem od problemu sprzętowego.

Zgłoszenie do serwisu ma sens, gdy występują powtarzalne opóźnienia, system zaczyna intensywnie korzystać z pliku wymiany, aplikacje przestają odpowiadać albo monitoring wskazuje presję pamięci mimo prawidłowo działających zapytań w spokojniejszych okresach. W ramach przygotowania można zabezpieczyć kopię planu wykonania, podstawowe informacje o konfiguracji, komunikaty systemowe i opis momentu wystąpienia objawów. Nie powinno się usuwać danych ani zmieniać wielu ustawień naraz, ponieważ utrudnia to późniejsze ustalenie przyczyny.

W przypadku problemów ze sprzętem, systemem lub środowiskiem pracy można skorzystać z pomocy serwisu komputerowego w Warszawie pod numerem +48 22 100 48 29. Analiza powinna obejmować zarówno stan komputera, jak i sposób, w jaki aplikacja korzysta z pamięci, procesora, dysku oraz połączenia z bazą danych. Dzięki temu można ustalić, czy Memory Grants są główną przyczyną opóźnień, czy jedynie widocznym skutkiem szerszego problemu z konfiguracją lub planem wykonania.