Tempdb a In-Memory

tempdb w kontekście In-Memory OLTP obsługuje dodatkowe struktury pomocnicze przy operacjach na tabelach pamięciowych.

Rola tempdb przy tabelach In-Memory OLTP

W SQL Server technologia In-Memory OLTP przechowuje dane tabel oznaczonych jako memory-optimized w specjalnym obszarze pamięci i korzysta z odrębnego mechanizmu indeksowania. Oznacza to, że tempdb nie jest miejscem, w którym standardowo znajdują się rekordy takiej tabeli, jej indeksy ani wersje wierszy używane przez kontrolę współbieżności. Samo określenie „In-Memory” odnosi się do sposobu przetwarzania i przechowywania danych przez silnik Hekaton, a nie do całkowitego wyeliminowania tempdb z każdego planu zapytania.

tempdb może nadal obsługiwać struktury pomocnicze powstające podczas wykonywania zapytań dotyczących tabel pamięciowych. Dotyczy to między innymi tabel tymczasowych, klasycznych zmiennych tabelowych, obszarów roboczych dla operatorów sortowania i agregacji oraz danych zapisywanych na dysk w wyniku przepełnienia pamięci, czyli tak zwanego spill. O tym, czy tempdb zostanie użyte, decyduje plan wykonania, rodzaj operatorów oraz dostępna pamięć, a nie samo występowanie tabeli memory-optimized w zapytaniu.

Co pozostaje w pamięci, a co może trafić do tempdb

Tabela utworzona z opcją MEMORY_OPTIMIZED = ON ma własne zasady przechowywania rekordów i indeksów. Indeks HASH opiera się na tablicach mieszających, natomiast indeksy typu NONCLUSTERED są zoptymalizowane pod kątem struktury danych In-Memory OLTP. Dla tabel trwałych dane są zabezpieczane również za pomocą plików checkpoint file pair w specjalnej grupie plików MEMORY_OPTIMIZED_DATA. Są to mechanizmy silnika In-Memory OLTP, niezależne od przeznaczenia tempdb.

Inaczej wygląda sytuacja na poziomie wykonania zapytania. Zapytanie może pobierać dane z tabeli memory-optimized, a następnie wykonywać sortowanie, grupowanie, łączenie lub obliczenia wymagające dodatkowej przestrzeni roboczej. Jeżeli operator planu nie mieści całego zbioru w przydzielonej pamięci, SQL Server może wykorzystać tempdb. W dzienniku lub planie wykonania będzie to wyglądało jak problem związany z tempdb, mimo że podstawowa tabela przechowuje dane w mechanizmie In-Memory OLTP.

Ważne jest także rozróżnienie między pamięciozoptymalizowaną zmienną tabelową a tradycyjną zmienną tabelową. Zmienna oparta na typie utworzonym z MEMORY_OPTIMIZED = ON korzysta z mechanizmu In-Memory OLTP i nie jest zwykłą strukturą tempdb. Klasyczna zmienna tabelowa oraz tabela tymczasowa utworzona za pomocą składni #nazwa są natomiast elementami tradycyjnego przetwarzania tempdb. Pomieszanie tych dwóch rodzajów obiektów może prowadzić do błędnych wniosków podczas analizy obciążenia.

Współbieżność, wersjonowanie i ograniczenia diagnostyczne

In-Memory OLTP wykorzystuje wielowersyjny model kontroli współbieżności. Wersje wierszy są obsługiwane przez struktury pamięciowe właściwe dla tego silnika, a nie przez klasyczny magazyn wersji w tempdb używany przez niektóre mechanizmy izolacji w tabelach dyskowych. Z tego powodu wzrost użycia tempdb nie powinien być automatycznie interpretowany jako dowód, że wersjonowanie rekordów tabeli memory-optimized odbywa się właśnie tam.

Jednocześnie jedno zapytanie może łączyć tabele memory-optimized z tabelami dyskowymi, tabelami tymczasowymi albo klasycznymi zmiennymi tabelowymi. W takim planie występują różne modele przetwarzania: część operacji wykonuje silnik In-Memory OLTP, a część korzysta z tradycyjnych operatorów SQL Server. Szczególnej uwagi wymagają zapytania wykonywane w trybie interop, czyli z użyciem interpretowanego silnika zapytań, oraz procedury natywnie kompilowane, które mają bardziej ograniczony zestaw obsługiwanych konstrukcji.

Diagnoza powinna dlatego rozdzielać kilka źródeł zużycia zasobów. Należy sprawdzić pamięć przydzieloną dla obiektów In-Memory OLTP, wykorzystanie plików checkpoint, operatorzy planu wykonania, występowanie spill do tempdb, czas oczekiwania oraz rzeczywiste typy użytych tabel i zmiennych. Sam licznik zajętości tempdb nie wskazuje jeszcze, że uszkodzona jest tabela pamięciowa. Może oznaczać nieoptymalne sortowanie, duże grupowanie, błędne oszacowanie liczby wierszy albo nieoczekiwane użycie obiektu tymczasowego.

Znaczenie rozdzielenia magazynu danych od przestrzeni roboczej

Rozróżnienie między tempdb a pamięcią In-Memory OLTP ma znaczenie przy planowaniu pojemności i analizie awarii. Zapełnienie tempdb może zatrzymać zapytania wykorzystujące tabele tymczasowe lub operatory wymagające obszaru roboczego, ale nie oznacza automatycznie utraty danych z tabel trwałych memory-optimized. Z kolei wyczerpanie pamięci przeznaczonej dla obiektów In-Memory OLTP może powodować inny zestaw objawów, nawet gdy tempdb ma jeszcze wolne miejsce.

Przy tabelach z DURABILITY = SCHEMA_AND_DATA dane muszą zostać odtworzone po ponownym uruchomieniu z plików checkpoint grupy MEMORY_OPTIMIZED_DATA. Przy DURABILITY = SCHEMA_ONLY zachowywany jest schemat, lecz rekordy są tracone po restarcie instancji. Żaden z tych wariantów nie zmienia tempdb w trwały magazyn tabeli memory-optimized. W praktyce należy więc osobno kontrolować stan pamięci, plików In-Memory OLTP, dziennika transakcyjnego i tempdb.

W środowisku, w którym występują problemy z zapytaniami używającymi tabel In-Memory OLTP, diagnostyka powinna rozpocząć się od planu wykonania i definicji obiektów. Trzeba ustalić, czy obiekt jest rzeczywiście oznaczony jako memory-optimized, czy zapytanie korzysta z natywnej kompilacji, które operatory tworzą dane pośrednie oraz czy występuje przepełnienie do tempdb. Dopiero takie rozdzielenie pozwala wskazać właściwy obszar naprawy: projekt tabeli, indeksy, plan zapytania, konfigurację pamięci albo konfigurację tempdb.