sys.dm_db_xtp_memory_consumers pokazuje komponenty zużywające pamięć przydzieloną tabelom memory-optimized.
Rola widoku sys.dm_db_xtp_memory_consumers w SQL Server
sys.dm_db_xtp_memory_consumers jest widokiem dynamicznym SQL Server przeznaczonym do analizy pamięci używanej przez silnik In-Memory OLTP w bieżącej bazie danych. Zwraca wiersze opisujące poszczególnych konsumentów pamięci, czyli wewnętrzne obiekty, pule i struktury indeksów, którym silnik przypisał rezerwacje pamięci. Widok nie przedstawia wyłącznie prostego zużycia pamięci przez pojedynczą tabelę. Pokazuje rozdział pamięci pomiędzy różne elementy obsługujące tabele memory-optimized, indeksy oraz operacje kontrolne silnika.
Zakres wyników zależy od wersji SQL Server, dlatego zapytania administracyjne nie powinny zakładać, że każda instalacja zwróci identyczny zestaw wierszy. Jednym z podstawowych pól jest memory_consumer_type_desc. Wartość VARHEAP oznacza zmienny stertowy obszar pamięci, HASH odnosi się do pamięci zajmowanej przez indeks, a PGPOOL oznacza pulę stron używaną przez bazę podczas operacji wykonywania. Wartość typu agregującego nie powinna być traktowana jako osobny obiekt do sumowania, ponieważ może obejmować pamięć kilku innych konsumentów.
Powiązanie konsumenta z tabelą i indeksem
Do ustalenia, którego obiektu dotyczy dany wiersz, służą między innymi kolumny object_id, xtp_object_id oraz index_id. object_id jest identyfikatorem obiektu bazy danych, któremu przypisano pamięć; dla obiektów systemowych może mieć wartość ujemną. xtp_object_id identyfikuje obiekt In-Memory OLTP odpowiadający tabeli memory-optimized. Jeżeli pamięć dotyczy indeksu, index_id wskazuje jego identyfikator. Dla pamięci przypisanej do tabeli bazowej indeks może mieć wartość NULL.
Przykładowe zapytanie diagnostyczne uruchamiane w konkretnej bazie może wyglądać następująco:
SELECT memory_consumer_type_desc, memory_consumer_desc, object_id, xtp_object_id, index_id, allocated_bytes, used_bytes, allocation_count FROM sys.dm_db_xtp_memory_consumers; Wynik warto łączyć z metadanymi tabel i indeksów, zamiast interpretować sam opis tekstowy. memory_consumer_desc może wskazywać na takie elementy jak pamięć danych użytkownika, sterta wewnętrzna bazy, indeks haszujący albo pule stron związane z aktywnością punktów kontrolnych. W przypadku tabel memory-optimized z indeksem columnstore część pamięci może należeć do wewnętrznych struktur używanych do śledzenia danych tego indeksu.
Interpretacja allocated_bytes, used_bytes i allocation_count
allocated_bytes określa liczbę bajtów zarezerwowanych dla danego konsumenta. Nie jest to zawsze liczba bajtów aktualnie zajętych przez użyteczne dane. Rezerwacja może obejmować obszar przygotowany przez alokator na przyszłe przydziały albo strukturę indeksu. used_bytes pokazuje liczbę używanych bajtów, ale dokumentacja SQL Server wiąże tę kolumnę przede wszystkim z konsumentami typu VARHEAP. Dlatego nie należy automatycznie obliczać różnicy między tymi kolumnami dla każdego rodzaju pamięci.
allocation_count informuje o liczbie alokacji wykonanych dla danego konsumenta. Duża liczba alokacji nie dowodzi sama w sobie wycieku pamięci ani błędu konfiguracji. Może wynikać z charakteru obciążenia, częstego tworzenia struktur pomocniczych lub pracy indeksu. Przy analizie problemu braku pamięci należy porównywać wartości w czasie i zestawiać je z liczbą wierszy, rozmiarem indeksów, aktywnością punktów kontrolnych oraz komunikatami SQL Server. Pola partition_count, sizeclass_count, min_sizeclass, max_sizeclass i memory_consumer_address mają charakter wewnętrzny i nie powinny być podstawą aplikacyjnych reguł biznesowych.
Uprawnienia i bezpieczna procedura odczytu
Widok odczytuje dane dla bieżącej bazy, więc zapytanie należy wykonać po przełączeniu kontekstu na właściwą bazę za pomocą USE nazwa_bazy; albo przez połączenie wskazujące tę bazę. W SQL Server 2019 i wcześniejszych wersjach pełny dostęp do wierszy wymaga uprawnienia VIEW DATABASE STATE. W SQL Server 2022 i nowszych do odczytu danych wydajnościowych bazy używa się uprawnienia VIEW DATABASE PERFORMANCE STATE. Bez odpowiednich uprawnień wynik może być pusty albo ograniczony do obiektów, do których użytkownik ma dostęp.
W praktyce ten DMV jest narzędziem dla administratora SQL Server analizującego pamięć In-Memory OLTP, a nie testem pamięci RAM laptopa lub komputera. Pusty wynik może oznaczać brak skonfigurowanych obiektów memory-optimized, niewłaściwy kontekst bazy albo brak wymaganych uprawnień. Z kolei wysoka wartość allocated_bytes wymaga sprawdzenia, czy dotyczy danych, indeksu, puli stron czy obiektu wewnętrznego. Dopiero takie rozróżnienie pozwala poprawnie ocenić, czy obserwowany wzrost wynika z normalnej pracy tabel memory-optimized, rozmiaru indeksu, aktywności punktów kontrolnych, czy z rzeczywistego problemu z zarządzaniem pamięcią w SQL Server.
