Kompatybilność T-SQL

Kompatybilność T-SQL określa, które konstrukcje tego dialektu są obsługiwane przy danym poziomie zgodności bazy.

Czym jest poziom zgodności T-SQL w SQL Server

Kompatybilność T-SQL w Microsoft SQL Server opisuje zestaw reguł, według których silnik interpretuje składnię oraz wykonuje wybrane zapytania zapisane w języku Transact-SQL. Najważniejszym ustawieniem jest poziom zgodności bazy danych, określany jako compatibility level. Jest on przypisany do konkretnej bazy, a nie do całej instancji SQL Server. Dzięki temu bazy działające na tej samej instancji mogą korzystać z różnych poziomów zgodności.

Poziom zgodności nie jest prostym przełącznikiem określającym, czy baza „jest” daną wersją SQL Server. Baza może działać na nowszej instancji, a jednocześnie zachowywać część starszych reguł przetwarzania zapytań. Takie rozwiązanie ułatwia migrację, ponieważ aktualizacja silnika nie musi od razu oznaczać zmiany wszystkich zachowań optymalizatora i wszystkich zapytań aplikacyjnych.

Wpływ zgodności na składnię i wykonywanie zapytań

Zmiana poziomu zgodności może oddziaływać na interpretację niektórych konstrukcji T-SQL, funkcji językowych oraz zachowanie zapytań. Dotyczy to między innymi zmian w optymalizatorze zapytań, sposobie szacowania liczby wierszy, wyborze operatorów planu wykonania oraz regułach transformacji zapytania. W efekcie to samo zapytanie może otrzymać inny plan wykonania po zmianie poziomu zgodności, nawet jeśli jego tekst i dane pozostaną takie same.

Nie każda funkcja wprowadzona w nowszej wersji SQL Server staje się dostępna wyłącznie przez podniesienie poziomu zgodności. Część możliwości zależy od wersji uruchomionego silnika, a poziom zgodności steruje tylko określonymi zachowaniami kompatybilności. Z tego powodu podczas migracji trzeba rozdzielić trzy kwestie: obsługę danej składni przez silnik, ustawienie poziomu zgodności bazy oraz wpływ zmiany na plany zapytań i wyniki działania aplikacji.

Kompatybilność może również ujawnić niejednoznaczności w istniejącym kodzie. Konstrukcja, która wcześniej była akceptowana albo interpretowana według starszych reguł, po zmianie ustawienia może powodować błąd kompilacji, ostrzeżenie lub zmianę wyniku. Szczególnej uwagi wymagają zapytania używające funkcji systemowych, niejawnych konwersji typów, zapytań złożonych, tabel czasowych oraz procedur składowanych zależnych od planu wykonania.

Sprawdzanie ustawienia i bezpieczna zmiana

Aktualny poziom zgodności można odczytać z widoku katalogowego sys.databases, sprawdzając kolumnę compatibility_level dla wybranej bazy. Weryfikacja powinna obejmować również wersję instancji, stan bazy, ustawienia optymalizatora oraz zależności aplikacji. Sama obecność wartości poziomu zgodności nie informuje jeszcze, czy wszystkie zapytania będą wykonywane prawidłowo po jej zmianie.

Ustawienie zmienia się poleceniem ALTER DATABASE z opcją SET COMPATIBILITY_LEVEL. Dozwolone wartości zależą od wersji SQL Server i nie powinny być dobierane na podstawie przypadkowego przykładu z innej instancji. Przed zmianą należy potwierdzić, jaki poziom jest obsługiwany przez konkretny silnik, a następnie przetestować procedury składowane, widoki, funkcje, wyzwalacze i najważniejsze zapytania raportowe.

Praktyczna migracja powinna mieć etap porównawczy. Najpierw zapisuje się plany wykonania i czasy działania istotnych zapytań przy obecnym ustawieniu. Następnie zmienia się poziom zgodności w środowisku testowym i ponownie analizuje plany, liczbę odczytów logicznych, blokowanie, zużycie procesora oraz czas odpowiedzi. Jeżeli pojawi się regresja, trzeba ustalić, czy wynika ona ze zmiany planu, błędu w zapytaniu, nieaktualnych statystyk, innego rozkładu danych czy rzeczywistej różnicy semantycznej.

Kompatybilność T-SQL a diagnostyka problemów z bazą

Błąd zgłaszany przez aplikację może wynikać z niezgodności składni, lecz równie często jego przyczyną jest plan wykonania zmieniony po migracji. Dlatego komunikat o wolnym zapytaniu, przekroczeniu limitu czasu lub dużym obciążeniu procesora nie powinien być automatycznie przypisywany samej wersji T-SQL. Należy powiązać tekst błędu z konkretnym zapytaniem, bazą, poziomem zgodności i planem wykonania użytym w chwili wystąpienia problemu.

W analizie przydatne są między innymi definicje obiektów zapisane w katalogu systemowym, historia zmian konfiguracji, statystyki zapytań oraz rzeczywiste plany wykonania. Trzeba sprawdzić, czy procedura nie korzysta z nazw lub składni zarezerwowanych dla innego poziomu zgodności, czy typy danych nie są konwertowane niejawnie oraz czy warunki łączenia tabel pozwalają optymalizatorowi wykorzystać indeksy. W przypadku różnicy wyników należy porównać nie tylko plan, ale również sortowanie, ustawienia sesji i sposób interpretacji wyrażeń.

Przywrócenie wcześniejszego poziomu zgodności może być środkiem tymczasowym ograniczającym skutki migracji, ale nie zastępuje analizy przyczyny. Docelowo warto poprawić zapytania, odświeżyć statystyki, zweryfikować indeksy i ponownie przetestować obciążenie. Każdą zmianę należy dokumentować dla konkretnej bazy, ponieważ identyczny poziom zgodności nie gwarantuje identycznego działania zapytań na bazach o innym schemacie, danych i konfiguracji.