Ograniczenia OLTP In-Memory

OLTP In-Memory nie obsługuje wszystkich typów danych i konstrukcji T-SQL — część funkcji tabel dyskowych jest niedostępna.

Zakres technologii In-Memory OLTP w SQL Server

In-Memory OLTP w Microsoft SQL Server jest mechanizmem przeznaczonym do obsługi obciążeń transakcyjnych z wykorzystaniem tabel zoptymalizowanych pod kątem pamięci oraz natywnie kompilowanych procedur składowanych. Tabela memory-optimized nie jest zwykłą tabelą dyskową przeniesioną do pamięci. Ma odmienny model blokowania, wersjonowanie wierszy i zestaw dozwolonych operacji. Z tego powodu istniejący schemat bazy danych nie zawsze może zostać bezpośrednio przekształcony do postaci In-Memory OLTP.

Podstawowym ograniczeniem jest konieczność zmieszczenia aktywnego zbioru danych tabel zoptymalizowanych pod kątem pamięci w dostępnej pamięci operacyjnej. SQL Server zapisuje zmiany tych tabel również w plikach checkpoint file pairs, aby zapewnić trwałość danych, ale pliki te nie zastępują pamięci potrzebnej do pracy. Przepełnienie pamięci może uniemożliwić wykonywanie operacji DML albo powodować problemy podczas odzyskiwania bazy. Przy projektowaniu trzeba więc uwzględnić rozmiar danych, indeksów, wersji wierszy i struktur wewnętrznych.

Typy danych i elementy schematu niedostępne dla tabel memory-optimized

Tabele zoptymalizowane pod kątem pamięci nie obsługują całego katalogu typów danych dostępnych w tabelach dyskowych. Dotyczy to między innymi typów text, ntext i image, a także typów aliasowych zdefiniowanych na ich podstawie. W praktyce dane tekstowe lub binarne trzeba przechowywać przy użyciu obsługiwanych typów, takich jak varchar(max), nvarchar(max) lub varbinary(max), z uwzględnieniem ograniczeń konkretnej wersji SQL Server i rodzaju operacji.

Ograniczenia obejmują także konstrukcję tabeli. Dla tabel memory-optimized wymagany jest co najmniej jeden indeks, a każdy indeks musi być zaprojektowany zgodnie z zasadami tego mechanizmu. Dostępne są indeksy hash oraz indeksy nietrwałe typu nonclustered, lecz indeks hash wymaga właściwego doboru liczby bucketów i najlepiej sprawdza się przy wyszukiwaniu po równości. Nie wszystkie właściwości znane z tabel dyskowych, takie jak dowolna postać indeksu, kolumn obliczanych, ograniczeń lub relacji, mogą być użyte w identyczny sposób. Przed migracją schematu należy sprawdzić zgodność kolumn, kluczy, indeksów, wartości domyślnych i ograniczeń integralności.

Ograniczenia języka T-SQL i procedur składowanych

Natywnie kompilowane procedury składowane wykonują tylko podzbiór języka T-SQL. Nie można zakładać, że procedura działająca dla tabel dyskowych zostanie zaakceptowana przez kompilator natywny bez zmian. Ograniczenia dotyczą między innymi części funkcji, operatorów, konstrukcji sterujących, zapytań dynamicznych oraz sposobów obsługi wyjątków. Zakres obsługi zależy od wersji i edycji SQL Server, dlatego zgodność trzeba weryfikować w dokumentacji właściwej wersji, a nie na podstawie samej nazwy funkcji.

Ważną różnicą jest model transakcyjny. In-Memory OLTP stosuje optymistyczną kontrolę współbieżności i wersjonowanie wierszy, a nie klasyczne blokowanie wierszy i stron w takim zakresie jak tabele dyskowe. Transakcja może zakończyć się konfliktem aktualizacji lub niepowodzeniem walidacji, jeśli w czasie jej trwania zmieniły się dane odczytane wcześniej. Aplikacja musi wtedy prawidłowo obsłużyć ponowienie transakcji. Nie każdą transakcję można także swobodnie łączyć z operacjami wykonywanymi na tabelach dyskowych, ponieważ występują ograniczenia dotyczące dostępu między tymi rodzajami tabel, eskalacji transakcji i użycia określonych funkcji silnika.

Nie wszystkie obiekty powiązane z tabelami dyskowymi mają odpowiednik dla tabel memory-optimized. Ograniczenia mogą dotyczyć wyzwalaczy, kluczy obcych, widoków, kursorów, instrukcji DDL oraz mechanizmów replikacji i wysokiej dostępności. Sam fakt, że narzędzie migracyjne wskazuje możliwość utworzenia tabeli, nie potwierdza zgodności całego przepływu aplikacyjnego. Konieczne są testy kompilacji, testy transakcyjne oraz sprawdzenie planów zapytań dla rzeczywistych operacji odczytu i zapisu.

Weryfikacja zgodności przed użyciem In-Memory OLTP

Analizę należy rozpocząć od inwentaryzacji tabel, kolumn, indeksów, ograniczeń i procedur, które mają korzystać z In-Memory OLTP. Warto oddzielić wymagania funkcjonalne od wymagań wydajnościowych: przyspieszenie pojedynczych operacji nie uzasadnia migracji, jeżeli schemat intensywnie korzysta z nieobsługiwanych typów danych albo konstrukcji T-SQL. Należy również obliczyć zapotrzebowanie na pamięć z uwzględnieniem indeksów i narzutu wersjonowania, a następnie sprawdzić zachowanie bazy podczas restartu oraz odzyskiwania po awarii.

Podczas diagnostyki błędu trzeba ustalić, czy problem powstał przy tworzeniu obiektu, kompilacji procedury, wykonaniu zapytania, walidacji transakcji czy braku pamięci. Komunikat SQL Server powinien być analizowany razem z definicją obiektu i wersją silnika. Pomocne jest porównanie zapytania wykonywanego na tabeli dyskowej z zapytaniem przeznaczonym dla tabeli memory-optimized, ponieważ różnica może wynikać nie z danych, lecz z niedostępnej funkcji albo niezgodnego planu wykonania. W środowisku użytkownika końcowego problemy z bazą mogą objawiać się zawieszaniem programu, błędami zapisu lub utratą połączenia, dlatego diagnostyka powinna obejmować również system operacyjny, pamięć RAM, nośnik danych i konfigurację aplikacji.

Przed wdrożeniem wymagane są testy obciążenia i współbieżności, obejmujące konflikty aktualizacji, długie transakcje, restart usługi SQL Server oraz odtwarzanie kopii zapasowej. Dopiero wynik takich testów pozwala ocenić, czy ograniczenia In-Memory OLTP są akceptowalne dla konkretnego schematu i aplikacji. W przypadku komputera, na którym uruchamiane jest oprogramowanie bazodanowe, warto oddzielić diagnostykę systemu i podzespołów od analizy samego silnika SQL Server.