SYS.DM_OS_MEMORY_OBJECTS

sys.dm_os_memory_objects zwraca szczegółowe dane o obiektach pamięciowych alokowanych przez silnik.

Widok pamięci wewnętrznej SQL Server

SYS.DM_OS_MEMORY_OBJECTS jest dynamicznym widokiem zarządzania SQL Server, który służy do badania sposobu wykorzystania pamięci przez poszczególne elementy silnika bazy danych. Nie opisuje on wyłącznie pamięci przydzielonej całej instancji ani ilości wolnego RAM-u w komputerze. Pokazuje niższy poziom szczegółowości: obiekty pamięci tworzone przez komponenty odpowiedzialne między innymi za kompilację zapytań, wykonywanie planów, obsługę struktur wewnętrznych oraz przechowywanie danych roboczych.

Wyniki tego widoku należy interpretować jako obraz aktualnego stanu instancji w chwili wykonania zapytania. SQL Server dynamicznie przydziela i zwalnia pamięć, dlatego pojedynczy odczyt nie jest pełnym pomiarem historycznym. Do analizy zmian potrzebne jest cykliczne zbieranie wyników, najlepiej razem z informacjami o obciążeniu procesora, operacjach wejścia i wyjścia, aktywnych zapytaniach oraz presji pamięci zgłaszanej przez system.

Każdy rekord reprezentuje określony obiekt lub grupę obiektów zarządzanych przez mechanizmy alokacji pamięci. Wśród dostępnych informacji mogą znajdować się identyfikatory obiektu i obiektu nadrzędnego, typ, nazwa, liczba przydzielonych stron, dane dotyczące rezerwacji pamięci wirtualnej oraz węzeł pamięci, z którym obiekt jest powiązany. Znaczenie poszczególnych kolumn zależy od wersji SQL Server, dlatego dokumentacja używanej wersji pozostaje ważniejsza niż przykłady przygotowane dla innej instalacji.

Jak czytać wyniki bez błędnych wniosków

Największa wartość diagnostyczna tego widoku pojawia się po grupowaniu danych według typu obiektu, nazwy albo relacji nadrzędnej. Sam fakt, że jeden obiekt zajmuje więcej pamięci niż inny, nie oznacza jeszcze błędu. Niektóre struktury są tworzone na potrzeby aktualnego obciążenia i ich rozmiar może naturalnie zmieniać się wraz z liczbą zapytań, wielkością planów wykonania lub liczbą równoczesnych sesji.

W praktyce warto rozróżniać pamięć przydzieloną, zarezerwowaną i rzeczywiście używaną. Rezerwacja przestrzeni adresowej nie musi oznaczać, że taka sama ilość pamięci fizycznej została zajęta. Podobnie liczba stron przypisana do obiektu nie daje samodzielnie odpowiedzi na pytanie, czy komputerowi zabrakło RAM-u. Do takiej oceny trzeba zestawić wyniki z całkowitym zużyciem pamięci przez proces SQL Server, ustawieniami limitu pamięci, stanem systemu operacyjnego oraz zachowaniem innych aplikacji.

SYS.DM_OS_MEMORY_OBJECTS różni się zakresem od widoków opisujących pamięć bufora danych, pamięć planów zapytań czy ogólny stan alokatorów. Nie powinno się zastępować nim analizy buforów, procedur składowanych ani aktywnych zapytań. Ten widok odpowiada przede wszystkim na pytanie, jakie wewnętrzne obiekty otrzymały pamięć i jak zmienia się ich udział, natomiast nie wskazuje automatycznie, które zapytanie jest winne problemom z wydajnością.

Odczyt zwykle wymaga uprawnień diagnostycznych odpowiednich dla danej wersji SQL Server i sposobu połączenia. Brak uprawnień może skutkować odmową wykonania zapytania albo ograniczeniem widocznych informacji. Przed nadaniem dodatkowych uprawnień należy sprawdzić, czy analiza może zostać wykonana przez konto przeznaczone do monitoringu. W środowisku produkcyjnym rozsądniej jest ograniczyć zakres dostępu i zapisywać wyniki do tabeli diagnostycznej niż pozwalać przypadkowym użytkownikom na szeroki wgląd w stan instancji.

Objawy, które warto powiązać z tym widokiem

Niepokój może uzasadniać stopniowy wzrost pamięci przypisanej do określonego rodzaju obiektów, jeśli towarzyszy mu coraz większe zużycie RAM-u, spadek responsywności aplikacji albo częste oczekiwanie na pamięć. Sam wzrost nie dowodzi wycieku. Może wynikać ze zmiany profilu pracy, większej liczby użytkowników, nowych zapytań, rozbudowanych planów lub dłuższego utrzymywania struktur potrzebnych do wykonania zadań.

Innym sygnałem jest duża zmienność wyników między kolejnymi pomiarami. Krótkotrwałe skoki mogą być normalną reakcją na kompilację zapytań, równoległe operacje albo chwilowe zadania administracyjne. Jeśli jednak skoki powtarzają się przy podobnym obciążeniu i nie następuje odzyskanie zasobów, trzeba sprawdzić dzienniki SQL Server, konfigurację pamięci, wersję silnika, aktywne zapytania oraz błędy systemowe. Dopiero korelacja tych danych pozwala odróżnić oczekiwane zachowanie od problemu wymagającego interwencji.

Często zadawane pytanie brzmi, czy ten widok pokaże uszkodzenie modułu RAM albo wadliwą płytę główną. Nie. SYS.DM_OS_MEMORY_OBJECTS opisuje logiczne przydziały pamięci widziane przez SQL Server, a nie stan elektryczny podzespołów. Błędy sprzętowe mogą jednak wywoływać niestabilność procesu, restarty, błędy odczytu lub zapisu oraz uszkodzenia danych. W takim przypadku analizę widoku trzeba uzupełnić o dzienniki systemu Windows, test pamięci, kontrolę temperatur, zasilania i nośnika.

Warto też uważać na porównywanie wyników po zmianie wersji SQL Server, aktualizacji systemu albo przeniesieniu bazy na inny komputer. Wewnętrzne nazwy, sposób grupowania oraz rozkład pamięci mogą się różnić, mimo że aplikacja wykonuje te same operacje. Raport diagnostyczny powinien zawierać datę pomiaru, wersję produktu, ustawienia instancji, obciążenie w czasie odczytu i pełne zapytanie użyte do zebrania danych.

Gdzie kończy się analiza programowa, a zaczyna diagnostyka sprzętu

Jeżeli odczyty z SYS.DM_OS_MEMORY_OBJECTS wskazują na nietypowe zużycie pamięci, pierwszym krokiem powinno być zabezpieczenie danych i zebranie powtarzalnych pomiarów. Pochopne zatrzymanie usługi, usuwanie baz, czyszczenie plików albo zmiana limitów pamięci może ukryć objaw i utrudnić ustalenie przyczyny. Gdy problem występuje tylko na jednym komputerze, a konfiguracja SQL Server nie zmieniła się, warto rozszerzyć sprawdzenie o pamięć RAM, dysk, układ chłodzenia i zasilacz.

Do serwisu sprzętowego warto zgłosić komputer, gdy pojawiają się samoczynne restarty, zawieszanie systemu, niebieskie ekrany, błędy kopiowania danych, zaniki obrazu, nietypowe odgłosy nośnika albo problemy z uruchamianiem. Takie symptomy mogą wpływać na pracę SQL Server, lecz nie zostaną naprawione samą zmianą zapytania diagnostycznego. Technik może sprawdzić podzespoły, wykonać testy pamięci i nośnika, ocenić stan zasilania oraz ustalić, czy dalsza praca grozi utratą danych.

W przypadku uszkodzonego dysku ważna jest kolejność działań. Intensywne testy zapisu, wielokrotne restartowanie komputera i próby naprawy systemu plików mogą pogorszyć stan nośnika. Najpierw należy ograniczyć pracę urządzenia, wykonać bezpieczną kopię lub podstawowy odzysk dostępnych danych, a dopiero później prowadzić testy obciążeniowe. Dotyczy to szczególnie sytuacji, w której błędy SQL Server zbiegają się z komunikatami o problemach sprzętowych w systemie operacyjnym.

Warszawskie Pogotowie Komputerowe zajmuje się kompleksową naprawą sprzętu komputerowego — laptopów i komputerów stacjonarnych. Przy zgłoszeniu związanym z SYS.DM_OS_MEMORY_OBJECTS warto dostarczyć opis objawów, kopię ważnych danych oraz informacje o tym, czy komputer był ostatnio rozbudowywany, przegrzewał się lub samoczynnie wyłączał.