ALTER DATABASE ADD FILE (memory optimized)

Polecenie ALTER DATABASE ADD FILE z opcją memory optimized dodaje do bazy danych plik przeznaczony dla tabel przechowywanych w pamięci.

ALTER DATABASE ADD FILE (memory optimized) – czym jest ta opcja

ALTER DATABASE ADD FILE z opcją memory optimized jest instrukcją języka Transact-SQL używaną w SQL Server do przygotowania pliku przeznaczonego dla danych tabel zoptymalizowanych pod kątem pracy w pamięci. Takie tabele nie są obsługiwane dokładnie tak samo jak zwykłe tabele dyskowe. Ich rekordy są utrzymywane w pamięci operacyjnej, natomiast specjalny obszar na dysku przechowuje trwałą reprezentację danych oraz informacje potrzebne do odtworzenia stanu po ponownym uruchomieniu usługi.

W praktyce polecenie nie tworzy tabeli i nie przenosi automatycznie istniejących danych. Dodaje do wskazanej bazy danych plik należący do kontenera MEMORY_OPTIMIZED_DATA. Kontener ten jest częścią grupy plików typu FILESTREAM, ale jego przeznaczenie jest bardziej wyspecjalizowane. To właśnie w nim SQL Server zapisuje checkpoint files, czyli pliki punktów kontrolnych wykorzystywane do utrwalania zmian pochodzących z tabel memory-optimized.

Przykładowa forma instrukcji może wyglądać następująco:

ALTER DATABASE [BazaTestowa]
ADD FILEGROUP [BazaTestowa_mod_fg] CONTAINS MEMORY_OPTIMIZED_DATA;

ALTER DATABASE [BazaTestowa]
ADD FILE (NAME = N'BazaTestowa_mod', FILENAME = N'D:\SQLData\BazaTestowa_mod')
TO FILEGROUP [BazaTestowa_mod_fg];

W typowym wdrożeniu potrzebne są więc dwa powiązane elementy: grupa plików oznaczona CONTAINS MEMORY_OPTIMIZED_DATA oraz plik dodany do tej grupy. Sama ścieżka wskazana w FILENAME musi odnosić się do istniejącej lokalizacji, do której usługa SQL Server ma odpowiednie uprawnienia. Nazwa logiczna po NAME służy do identyfikacji pliku w metadanych bazy, natomiast FILENAME określa jego fizyczne położenie.

memory optimized w ALTER DATABASE – kontekst techniczny i porównania

Najważniejsza różnica między klasyczną tabelą a tabelą memory-optimized dotyczy sposobu wykonywania operacji. Zwykła tabela opiera się na stronach danych i mechanizmach bufora, który wczytuje potrzebne fragmenty z dysku do pamięci. Tabela zoptymalizowana pod kątem pamięci korzysta z innego modelu przechowywania, z konstrukcjami zaprojektowanymi dla dostępu bez blokad typowych dla tradycyjnych struktur. Nie oznacza to jednak, że dysk przestaje mieć znaczenie. Trwałość danych nadal wymaga zapisywania informacji w plikach kontenera.

Kontener MEMORY_OPTIMIZED_DATA należy odróżnić od zwykłego pliku danych MDF oraz od pliku dziennika LDF. MDF przechowuje standardowe obiekty bazy, takie jak klasyczne tabele i indeksy. LDF rejestruje operacje w dzienniku transakcji. Plik memory optimized pełni natomiast funkcję magazynu trwałości dla obiektów pamięciowych i jest obsługiwany według reguł właściwych dla tego mechanizmu. Nie powinno się traktować go jako zamiennika dziennika ani jako prostego dodatkowego miejsca na dowolne tabele.

Warto również rozróżnić trwałość schematu tabeli. Tabela memory-optimized może być utworzona jako SCHEMA_AND_DATA albo SCHEMA_ONLY. Pierwszy wariant zachowuje dane po restarcie, dlatego wymaga prawidłowo skonfigurowanego kontenera i odpowiedniego planu ochrony. Drugi wariant zachowuje definicję tabeli, lecz po ponownym uruchomieniu instancji nie odtwarza jej zawartości. Dodanie pliku jest szczególnie istotne wtedy, gdy planowane są obiekty typu SCHEMA_AND_DATA.

Można to porównać do rozdzielenia warstwy roboczej od warstwy trwałego zapisu. Pamięć operacyjna zapewnia szybki dostęp podczas działania procesu, a pliki checkpoint zabezpieczają możliwość odtworzenia danych. Z tego powodu dobór lokalizacji, uprawnień oraz systemu kopii zapasowych pozostaje częścią konfiguracji, a nie dodatkiem wykonywanym po zakończeniu instalacji.

ALTER DATABASE ADD FILE memory optimized – typowe problemy

Jednym z częstszych problemów jest próba dodania pliku bez wcześniejszego utworzenia właściwej grupy plików. SQL Server może wtedy zwrócić błąd związany z nieprawidłowym typem filegroup albo z brakiem grupy oznaczonej CONTAINS MEMORY_OPTIMIZED_DATA. Kolejną przyczyną niepowodzenia bywa wskazanie ścieżki, która nie istnieje na komputerze, na którym działa usługa. Ścieżka widoczna w Eksploratorze użytkownika nie musi być dostępna dla konta usługi.

Problemy mogą wystąpić także wtedy, gdy w podanej lokalizacji znajduje się już plik o tej samej nazwie albo gdy nazwa logiczna koliduje z istniejącym obiektem. Przed uruchomieniem polecenia powinno się sprawdzić właściwości bazy, listę filegroup, bieżące pliki oraz ich rozmiary. Przydatne są zapytania do widoków katalogowych, między innymi sys.database_files, sys.filegroups oraz sys.database_filestream_options. Pozwalają one ustalić, czy konfiguracja odpowiada zamierzonemu typowi obiektu.

Nie należy zakładać, że zwiększenie ilości pamięci automatycznie rozwiąże każdy problem wydajności. Tabele memory-optimized zajmują pamięć według własnych zasad, a indeksy również mają koszt. Przy zbyt małej ilości dostępnej pamięci może dojść do presji pamięci, spowolnienia innych baz albo problemów z odtwarzaniem danych. Z drugiej strony sam fakt dodania pojemnego pliku nie gwarantuje lepszego działania, jeżeli aplikacja wykonuje zapytania niezgodne z dostępnymi indeksami lub używa konstrukcji niewspieranych przez dany typ tabeli.

Ważne jest też uwzględnienie kopii zapasowych. Kontener memory optimized powinien być objęty procedurą odtwarzania bazy, a test przywracania powinien obejmować także obiekty korzystające z pamięci. Pominięcie tego etapu może ujawnić problemy dopiero po awarii. Przed zmianą konfiguracji warto zapisać aktualny stan bazy, zweryfikować wolne miejsce oraz ustalić, czy operacja będzie wykonywana w oknie dopuszczalnym dla użytkowników.

ALTER DATABASE ADD FILE – praktyczne wskazówki konfiguracji

Najpierw powinno się ustalić, czy rzeczywiście potrzebne są tabele memory-optimized. Technologia ta jest przydatna w określonych scenariuszach, na przykład przy intensywnych operacjach na krótkotrwałych danych roboczych, kolejkach lub tabelach wymagających ograniczenia tradycyjnego blokowania. Nie każda tabela z dużą liczbą rekordów skorzysta na przeniesieniu do pamięci. Przed zmianą warto przeanalizować obciążenie, czas trwania transakcji, rodzaj zapytań oraz dostępne indeksy.

Ścieżka FILENAME powinna być wybrana z uwzględnieniem trwałości nośnika, kopii zapasowych i uprawnień konta usługi. W środowisku testowym można wykorzystać osobny katalog przeznaczony do eksperymentów, natomiast w środowisku używanym przez aplikację należy udokumentować właściciela lokalizacji i sposób jej zabezpieczenia. Nie powinno się ręcznie przenosić plików po utworzeniu konfiguracji. Jeżeli zmiana lokalizacji jest konieczna, należy zastosować procedurę przewidzianą dla przenoszenia plików bazy i sprawdzić ją na kopii.

Po wykonaniu ALTER DATABASE warto zweryfikować rezultat zapytaniem do sys.database_files oraz sprawdzić, czy plik ma oczekiwany typ i należy do poprawnej grupy. Następnie można utworzyć niewielką tabelę testową z MEMORY_OPTIMIZED = ON, wykonać kontrolną transakcję, zamknąć ją zgodnie z procedurą testową i potwierdzić odtworzenie danych. Taki test powinien być oddzielony od danych produkcyjnych i opisany w dokumentacji.

Dobrym zwyczajem jest także monitorowanie zużycia pamięci, rozmiaru plików checkpoint oraz czasu wykonywania operacji. Obserwacja przed i po zmianie pomaga odróżnić rzeczywistą poprawę od chwilowego efektu. W dokumentacji należy zapisać nazwę bazy, nazwę filegroup, nazwę logiczną pliku, ścieżkę, uprawnienia oraz plan wycofania zmian.

ALTER DATABASE ADD FILE (memory optimized) – kiedy zgłosić się do serwisu

Do konsultacji warto zgłosić się wtedy, gdy polecenie kończy się błędem, nie jest jasne, czy grupa plików została utworzona poprawnie, albo gdy konfiguracja ma zostać zmieniona w działającej bazie używanej przez aplikację. Szczególnej ostrożności wymagają sytuacje, w których brakuje aktualnej kopii zapasowej, nie ma pewności co do uprawnień do katalogu lub występują objawy presji pamięci. W takich przypadkach samo ponowne uruchamianie instrukcji może zwiększyć ryzyko niespójnej konfiguracji.

Pomoc techniczna może obejmować odczyt metadanych bazy, sprawdzenie lokalizacji plików, analizę komunikatu błędu, przygotowanie planu testowego oraz weryfikację kopii zapasowej. Przydatne jest przekazanie dokładnej wersji SQL Server, trybu odzyskiwania, fragmentu wykonywanej instrukcji i pełnej treści komunikatu. Nie powinno się usuwać plików ani grup plików ręcznie, ponieważ taka czynność może uniemożliwić poprawne otwarcie bazy.

W Warszawskim Pogotowiu Komputerowym 24/7 można skonsultować interpretację konfiguracji związanej z ALTER DATABASE ADD FILE (memory optimized), zwłaszcza gdy potrzebne jest uporządkowanie informacji przed dalszymi pracami. Przed rozpoczęciem zmian należy przygotować kopię bezpieczeństwa, ustalić zakres testu i potwierdzić, które elementy bazy mają pozostać nienaruszone.