Compatibility level

Compatibility level to ustawienie bazy danych określające, z którą wersją silnika SQL Server zachowuje ona zgodność funkcjonalną.

Compatibility level jako ustawienie zgodności bazy danych

Compatibility level to parametr przypisany do konkretnej bazy danych w środowisku Microsoft SQL Server. Określa on, w jakim zakresie zapytania, funkcje języka T-SQL oraz wybrane zachowania optymalizatora mają działać zgodnie z wcześniejszym modelem zgodności. Nie jest to jednak proste przełączenie całej bazy na starszą wersję serwera. Silnik SQL Server może działać w nowszym wydaniu, a sama baza może przez pewien czas korzystać z niższego poziomu zgodności, aby ograniczyć ryzyko zmian w działaniu istniejącej aplikacji.

Rozróżnienie między wersją silnika a Compatibility level ma duże znaczenie podczas migracji. Aktualizacja instancji SQL Server nie musi automatycznie oznaczać natychmiastowej zmiany zachowania każdej bazy. Pozwala to przeprowadzić testy, sprawdzić zapytania i stopniowo ocenić wpływ nowych mechanizmów. Ustawienie dotyczy bazy, a nie pojedynczego użytkownika czy jednego polecenia. Zmiana może więc wpłynąć na wiele aplikacji korzystających z tych samych danych.

W praktyce poziom zgodności pełni funkcję warstwy przejściowej. Ułatwia przeniesienie bazy do nowszego środowiska, kiedy kod aplikacji, procedury składowane, raporty lub narzędzia administracyjne nie zostały jeszcze w pełni zweryfikowane. Nie powinno się jednak traktować niskiego poziomu jako docelowego rozwiązania bez analizy. Starsze ustawienie może ograniczać dostęp do ulepszeń silnika, utrudniać wykorzystanie nowych funkcji oraz zaciemniać przyczynę problemów z wydajnością.

Compatibility level w kontekście wersji silnika i migracji

Podczas przenoszenia bazy między serwerami występują co najmniej trzy osobne zagadnienia: zgodność plików bazy, zgodność języka zapytań oraz sposób optymalizacji wykonywania instrukcji. Compatibility level odnosi się przede wszystkim do drugiego i trzeciego obszaru. Nie zastępuje kopii zapasowej, testu odtwarzania ani kontroli uprawnień. Nie naprawia również aplikacji, która korzysta z nieobsługiwanych sterowników lub zakłada określone zachowanie serwera.

W starszych środowiskach poziom zgodności mógł zachowywać wcześniejsze reguły interpretowania niektórych konstrukcji T-SQL. W nowszych wydaniach zmiany mogą dotyczyć między innymi funkcji języka, obsługi słów kluczowych, kolejności przetwarzania wybranych elementów zapytania albo decyzji podejmowanych przez optymalizator. Dwa zapytania o identycznej treści mogą zwrócić ten sam wynik, lecz zostać wykonane według innego planu. Z tego powodu po podniesieniu ustawienia trzeba analizować nie tylko błędy składniowe, ale także czas wykonywania, obciążenie procesora, odczyty z dysku i stabilność planów.

Ważne jest także odróżnienie poziomu zgodności od ustawień kompatybilności bazy użytkownika, ustawień sesji oraz parametrów samej instancji. Na wynik działania zapytania wpływa cały kontekst wykonania. Mogą mieć znaczenie między innymi opcje SET, poziom izolacji transakcji, statystyki, indeksy, parametry procedur, aktualność danych i sposób wywołania zapytania przez aplikację. Samo ustawienie Compatibility level nie daje więc pełnej gwarancji zachowania identycznego jak przed migracją.

Przy porównywaniu poziomów nie należy kierować się wyłącznie numerem. Trzeba sprawdzić, do jakiej wersji SQL Server odnosi się dana wartość, jakie funkcje są przez nią aktywowane oraz jakie zmiany optymalizatora mogą pojawić się po jej podniesieniu. Dokumentacja producenta, dzienniki aplikacji i rzeczywiste testy na kopii danych są ważniejsze niż mechaniczne zastosowanie najwyższego dostępnego ustawienia.

Typowe problemy po zmianie Compatibility level

Jednym z częstszych objawów jest pogorszenie wydajności zapytania po podniesieniu poziomu zgodności. Nie musi to oznaczać błędu w samym ustawieniu. Nowszy optymalizator może wybrać inny plan wykonania, ponieważ inaczej ocenia selektywność warunków, koszt operacji albo kolejność łączenia tabel. Plan korzystny dla niewielkiego zakresu danych może okazać się mniej korzystny po zmianie rozkładu danych. Dlatego diagnoza powinna obejmować rzeczywiste parametry wywołania, statystyki i plan wykonania.

Możliwy jest również problem funkcjonalny. Aplikacja może używać składni, która w nowym modelu jest interpretowana inaczej, albo opierać się na zachowaniu wcześniej uznawanym za niezalecane. Kłopot może pojawić się w procedurze składowanej, widoku, wyzwalaczu, zadaniu automatycznym lub generatorze raportów. Czasem nie występuje komunikat o błędzie, lecz zmienia się kolejność wyników, sposób konwersji typów danych albo reakcja na wartości puste. Brak błędu nie oznacza zatem, że migracja nie wymaga testów.

Problemy mogą wynikać także z niepełnego obrazu środowiska. Przykładowo aplikacja może łączyć się z inną bazą niż ta, dla której zmieniono ustawienie, a użytkownik może sprawdzać plan zapytania w odmiennych warunkach niż proces produkcyjny. Zdarza się też, że przyczyną są nieaktualne statystyki, brak indeksu, zmiana parametrów połączenia lub różnica w ustawieniach sesji. Weryfikacja powinna rozpoczynać się od potwierdzenia właściwej bazy, instancji i momentu wystąpienia zmiany.

Nie zaleca się pochopnego obniżania poziomu zgodności po każdym spadku wydajności. Takie działanie może chwilowo zmienić plan, lecz nie wyjaśnia przyczyny i może utrudnić późniejsze przejście na docelową konfigurację. Rozsądniejszym podejściem jest porównanie planów, zebranie danych z monitoringu, odtworzenie problemu na kopii oraz sprawdzenie, czy możliwe jest użycie mechanizmu wymuszania właściwego planu lub korekta zapytania.

Praktyczne wskazówki dotyczące Compatibility level

Przed zmianą należy wykonać sprawdzoną kopię zapasową oraz upewnić się, że można odtworzyć bazę w środowisku testowym. Warto przygotować listę najważniejszych procesów: logowanie, wyszukiwanie, zapis danych, generowanie raportów, importy, eksporty i zadania wykonywane automatycznie. Każdy z tych obszarów może korzystać z innych zapytań, procedur i sterowników. Test powinien obejmować zarówno poprawność wyniku, jak i zachowanie pod obciążeniem zbliżonym do rzeczywistego.

Dobrym zwyczajem jest zapisanie stanu wyjściowego. Należy zanotować aktualny poziom zgodności, wersję silnika, czas wykonywania kluczowych zapytań, najczęściej używane plany oraz istotne komunikaty w dziennikach. Dzięki temu po zmianie można odróżnić nowe zjawisko od problemu, który istniał wcześniej. Przydatne jest także monitorowanie zapytań o wysokim czasie trwania, dużej liczbie odczytów i częstych kompilacjach.

Zmianę najlepiej przeprowadzać w kontrolowanym oknie administracyjnym, z określonym kryterium powodzenia i planem wycofania. Poziom zgodności powinien być podnoszony dopiero po sprawdzeniu zależności aplikacji. Jeżeli środowisko korzysta z wielu baz, należy oceniać je osobno, ponieważ każda baza może mieć inny cykl migracji i inny zestaw obciążeń. Warto również sprawdzić zgodność sterowników, bibliotek dostępowych i narzędzi raportowych używanych przez aplikacje.

W przypadku niejasności należy unikać zmian wykonywanych bez rejestracji. Zapis polecenia, daty, osoby wykonującej operację i obserwowanych skutków ułatwia późniejszą analizę. Przydatne jest także rozdzielenie testu składni od testu wydajności. Zapytanie może działać poprawnie pod względem wyniku, a jednocześnie zużywać znacznie więcej zasobów. Odwrotna sytuacja również jest możliwa, dlatego oba kryteria trzeba sprawdzać niezależnie.

Kiedy zgłosić Compatibility level do serwisu

Wsparcie techniczne jest wskazane, gdy po migracji pojawiają się błędy aplikacji, zmienne czasy odpowiedzi, nieoczekiwane plany wykonania, problemy z raportami albo różnice między środowiskiem testowym i produkcyjnym. Zgłoszenie powinno zawierać wersję SQL Server, aktualny poziom zgodności, opis momentu wystąpienia problemu, przykładowe zapytanie oraz informacje o tym, czy zmieniano statystyki, indeksy lub ustawienia sesji. Bez tych danych ocena przyczyny może być niepełna.

W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić analizę konfiguracji bazy, porównanie zachowania przed i po zmianie oraz uporządkowanie procesu migracji. W ramach przygotowania warto udostępnić kopię bez danych wrażliwych, dzienniki błędów i opis aplikacji korzystających z bazy. Pozwala to sprawdzić, czy problem wynika z Compatibility level, planu wykonania, zapytania, sterownika czy szerszej konfiguracji środowiska.

Do serwisu warto zgłosić się również wtedy, gdy baza działa poprawnie, ale planowane jest przejście na nowszy silnik i potrzebna jest ocena ryzyka. Wczesna weryfikacja pozwala ustalić kolejność testów, wytypować krytyczne procedury i przygotować sposób obserwacji po wdrożeniu. Takie podejście ogranicza przypadkowe zmiany i ułatwia utrzymanie przewidywalnego działania aplikacji po migracji.