Transakcje pamięciowe

Transakcje pamięciowe działają na tabelach memory-optimized bez klasycznych blokad, korzystając z wersjonowania wierszy.

Transakcje pamięciowe w SQL Server

Transakcje pamięciowe to mechanizm silnika Microsoft SQL Server związany z technologią In-Memory OLTP. Operują na tabelach oznaczonych jako MEMORY_OPTIMIZED = ON, których rekordy są przechowywane w strukturach zoptymalizowanych pod kątem dostępu z pamięci operacyjnej. W odróżnieniu od klasycznych tabel przechowywanych w stronach danych, takie tabele korzystają z wielowersyjnego modelu współbieżności. Aktualizacja wiersza nie polega na nadpisaniu jednej wersji blokowanej dla innych transakcji, lecz na utworzeniu nowej wersji rekordu z odpowiednimi znacznikami początku i końca jego ważności.

Określenie „bez klasycznych blokad” wymaga doprecyzowania. Operacje na danych w tabelach memory-optimized nie wykorzystują tradycyjnych blokad wierszy i stron ani typowych zatrzymań wynikających z oczekiwania na blokadę danych. SQL Server nadal może jednak stosować blokady związane ze schematem, metadanymi lub innymi elementami infrastruktury. Współbieżność jest przede wszystkim kontrolowana optymistycznie: transakcja odczytuje dostępne wersje, a przy zatwierdzaniu silnik sprawdza, czy w czasie jej trwania nie wystąpił konflikt z inną transakcją.

Wersjonowanie rekordów i walidacja zatwierdzenia

W modelu wielowersyjnym jeden logiczny rekord może mieć kilka wersji odpowiadających kolejnym zmianom. Transakcja odczytuje wersję zgodną z własnym punktem widzenia, ustalonym przez reguły izolacji i moment rozpoczęcia operacji. Jeżeli inna transakcja zmieniła ten sam rekord, SQL Server nie musi zatrzymywać pierwszej transakcji na blokadzie. Zamiast tego podczas walidacji może wykryć konflikt zapisu, konflikt odczytu albo naruszenie reguł izolacji i odrzucić zatwierdzenie.

Konsekwencją jest inny profil błędów niż w przypadku klasycznych blokad. Zamiast długiego oczekiwania na zwolnienie blokady może pojawić się nieudane zatwierdzenie transakcji, które aplikacja musi obsłużyć przez ponowienie operacji albo zmianę sposobu wykonywania zapisu. Przy dużej liczbie równoczesnych modyfikacji znaczenie ma więc nie tylko czas pojedynczego zapytania, lecz także prawdopodobieństwo konfliktów. Niewłaściwie zaprojektowana transakcja może być szybka w warstwie odczytu, ale często kończyć się błędem walidacji.

Indeksy, trwałość i ograniczenia mechanizmu

Tabela memory-optimized wymaga co najmniej jednego indeksu. SQL Server obsługuje dla niej między innymi indeksy hash oraz indeksy zakresowe typu Bw-tree. Indeks hash jest przeznaczony głównie do wyszukiwania po równości i wymaga odpowiedniego doboru liczby kubełków. Nie jest dobrym zamiennikiem indeksu zakresowego dla zapytań wykorzystujących sortowanie, operatory nierówności albo przedziały wartości. Indeksy zakresowe lepiej pasują do wyszukiwania po zakresie i porządkowania danych.

Przy deklarowaniu tabeli wybiera się również sposób trwałości. Opcja DURABILITY = SCHEMA_AND_DATA zapisuje dane i schemat w sposób pozwalający odtworzyć zawartość po ponownym uruchomieniu instancji. Opcja SCHEMA_ONLY zachowuje definicję tabeli, ale dane są tracone po restarcie. Tabele memory-optimized nie są automatycznym przyspieszeniem dla każdego obciążenia. Wymagają analizy wzorców zapytań, indeksów, konfliktów transakcyjnych, rozmiaru danych oraz zgodności używanego kodu T-SQL z ograniczeniami In-Memory OLTP. Część funkcji i konstrukcji dostępnych dla tabel klasycznych może wymagać innego zapisu lub nie być dostępna w identycznej postaci.

Rozpoznawanie problemów z transakcją pamięciową

Diagnostyka problemów powinna obejmować definicję tabeli, użyte indeksy, poziom izolacji, sposób rozpoczęcia i zakończenia transakcji oraz komunikaty zwracane przez SQL Server. Należy rozróżnić konflikt wynikający z równoczesnej modyfikacji od błędu konstrukcji zapytania, niezgodności funkcji albo problemu z trwałością danych. Sama obserwacja, że zapytanie nie czeka na klasyczną blokadę, nie dowodzi jeszcze poprawności przepływu. Istotne jest sprawdzenie, czy transakcja została zatwierdzona, czy została wycofana oraz czy aplikacja reaguje na konflikt ponowieniem lub kontrolowanym komunikatem.

W praktyce analizuje się także czas życia wersji rekordów i obciążenie związane z ich usuwaniem po ustaniu potrzeby odczytu. Nieusuwane przez dłuższy czas wersje mogą zwiększać zużycie pamięci, zwłaszcza gdy występują długo trwające transakcje. Przy ocenie działania trzeba więc łączyć informacje z logów aplikacji, statystyk SQL Server i definicji obiektów bazy. Naprawa problemu może polegać na korekcie zakresu transakcji, zmianie indeksu, właściwym ustawieniu poziomu izolacji albo obsłudze konfliktów w kodzie, a nie na mechanicznym wyłączaniu wersjonowania.