NATIVE_COMPILATION

NATIVE_COMPILATION to opcja procedury składowanej powodująca jej skompilowanie do kodu maszynowego przy tworzeniu.

NATIVE_COMPILATION w procedurach składowanych SQL Server

NATIVE_COMPILATION jest opcją języka Transact-SQL w Microsoft SQL Server, należącą do mechanizmu In-Memory OLTP. Oznaczenie procedury tą opcją powoduje, że jej instrukcje są kompilowane do kodu natywnego, czyli kodu maszynowego wykonywanego przez procesor, zamiast być obsługiwane wyłącznie przez tradycyjny mechanizm interpretacji i wykonywania instrukcji T-SQL. Mechanizm jest przeznaczony dla procedur składowanych związanych z tabelami zoptymalizowanymi pod kątem pamięci, czyli tabelami memory-optimized. Nie jest to uniwersalny przełącznik przyspieszający dowolną procedurę działającą na zwykłych tabelach dyskowych.

W praktyce SQL Server tworzy dla takiej procedury bibliotekę DLL zawierającą skompilowany kod. Informacje potrzebne do ponownego utworzenia tej biblioteki pozostają w metadanych bazy danych, natomiast sama wygenerowana DLL nie jest częścią kopii zapasowej bazy. Po ponownym uruchomieniu bazy lub serwera kod może zostać odtworzony z metadanych. Dla procedur składowanych kompilacja może być odroczona do pierwszego wykonania, dlatego brak procedury w widoku załadowanych modułów bezpośrednio po restarcie nie musi oznaczać błędu.

Wymagana konstrukcja procedury i powiązanie ze schematem

Sama opcja NATIVE_COMPILATION nie wystarcza do utworzenia poprawnej procedury natywnie kompilowanej. Definicja zwykle zawiera również SCHEMABINDING, a ciało procedury musi składać się dokładnie z jednego bloku BEGIN ATOMIC. Przykładowy szkielet dla SQL Server może wyglądać następująco:

CREATE PROCEDURE dbo.DodajElement
WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER
AS
BEGIN ATOMIC
WITH (TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = N'us_english')
INSERT dbo.Elementy (Id, Nazwa) VALUES (1, N'Przykład');
END;

SCHEMABINDING wymusza jawne związanie procedury ze schematem obiektów, z których korzysta. Nazwy tabel muszą zawierać schemat, na przykład dbo.Elementy, a odwołania typu SELECT * nie są dozwolone. Takie ograniczenie pozwala silnikowi dokładniej znać strukturę zależności, ale oznacza, że zmiana definicji używanej tabeli może wymagać wcześniejszej zmiany albo usunięcia procedury. Blok atomowy określa granice transakcji. Jeżeli procedura jest wywołana poza aktywną transakcją, SQL Server może rozpocząć transakcję dla tego bloku i zatwierdzić ją po prawidłowym zakończeniu. W definicji trzeba podać poziom izolacji transakcji oraz język używany przez procedurę.

Wydajność, ograniczenia i zachowanie planu wykonania

Native compilation może ograniczyć koszt obsługi często wykonywanej logiki transakcyjnej, zwłaszcza gdy procedura przetwarza wiele wierszy, wykonuje agregacje, złożone wyrażenia, instrukcje warunkowe, pętle albo serię operacji SELECT, INSERT, UPDATE i DELETE. Korzyść nie wynika jednak z samej nazwy opcji. Dla procedury obsługującej pojedynczy wiersz narzut przekazywania parametrów, konwersji typów lub dostępu do danych może sprawić, że różnica będzie niewielka. Konieczne jest zmierzenie rzeczywistego czasu wykonania oraz liczby operacji wykonywanych przez procedurę.

Natywnie kompilowane moduły nie obsługują całej powierzchni języka T-SQL dostępnej dla zwykłych procedur. Przed użyciem trzeba sprawdzić, czy stosowane zapytania, funkcje, operatory, typy danych i instrukcje sterujące są wspierane w danej wersji SQL Server. Ograniczenia dotyczą między innymi części konstrukcji dynamicznego SQL, niektórych sposobów sortowania, kursorów i wybranych funkcji systemowych. Procedura nie jest automatycznie rekompilowana tylko dlatego, że zmieniły się dane w tabeli. Podczas analizy należy więc odróżnić problem wynikający z nieaktualnych statystyk, problem z planem zapytania i ograniczenie wynikające z native compilation.

Warto również zweryfikować sposób przekazywania parametrów. Zgodność typów parametrów po stronie aplikacji i definicji procedury ogranicza niepotrzebne konwersje. Do pomiaru można wykorzystać statystyki wykonywania procedur natywnie kompilowanych oraz zdarzenia Extended Events. Opcje STATISTICS mogą zbierać dane dla całej procedury, a nie w takim samym układzie dla każdej instrukcji jak w zwykłym module T-SQL. Do ustalenia metadanych pierwszego zestawu wyników stosuje się sp_describe_first_result_set, ponieważ starsze mechanizmy rozpoznawania schematu nie są odpowiednie dla każdego przypadku procedur natywnie kompilowanych.

Sprawdzanie błędów kompilacji i diagnostyka procedury

Błąd przy tworzeniu lub pierwszym uruchomieniu procedury z NATIVE_COMPILATION może wynikać z niepoprawnej składni, odwołania do nieobsługiwanego elementu T-SQL, braku wymaganej tabeli zoptymalizowanej pod kątem pamięci albo niezgodności definicji z wymaganiami SCHEMABINDING i BEGIN ATOMIC. Diagnostykę należy rozpocząć od pełnego komunikatu SQL Server oraz definicji procedury, a następnie sprawdzić zależności w katalogu systemowym, uprawnienia i konfigurację In-Memory OLTP. Sam fakt, że zwykła procedura wykonuje się poprawnie, nie potwierdza, że jej wersja natywnie kompilowana będzie zgodna funkcjonalnie.

Podczas przeglądu warto porównać wynik procedury natywnej z odpowiednikiem wykonywanym jako standardowy moduł T-SQL. Należy sprawdzić wartości parametrów, liczbę zmienionych wierszy, zachowanie w przypadku błędu oraz granice transakcji. Przydatne jest monitorowanie modułów załadowanych do pamięci, statystyk wykonania i zdarzeń Extended Events, a także kontrola, czy procedura rzeczywiście odwołuje się do oczekiwanych tabel memory-optimized. Pliki DLL i pliki pośrednie generowane przez SQL Server nie powinny być ręcznie modyfikowane ani usuwane; ich tworzeniem, ładowaniem i sprzątaniem zarządza silnik bazy danych. W środowisku laptopa lub komputera PC analiza takiego problemu wymaga dostępu do właściwej instancji SQL Server, dzienników oraz skryptu definicji, ponieważ objaw widoczny w aplikacji może być tylko skutkiem błędu kompilacji albo nieobsługiwanej konstrukcji procedury.