Zgodność funkcji

Zgodność funkcji między wersjami silnika decyduje, czy zapytanie zadziała tak samo po migracji bazy.

Na czym polega zgodność funkcji

Zgodność funkcji między wersjami silnika bazy danych oznacza, że istniejące zapytania, procedury, widoki, wyzwalacze oraz mechanizmy obsługi transakcji zachowują oczekiwane znaczenie po aktualizacji albo migracji. Nie chodzi wyłącznie o to, czy zapytanie przechodzi analizę składniową. Równie ważne jest, czy zwraca ten sam zestaw wierszy, stosuje takie same reguły porównywania tekstu, zachowuje kolejność wyników tam, gdzie aplikacja jej wymaga, oraz obsługuje wartości puste i typy danych w sposób zgodny z wcześniejszym działaniem.

Funkcja dostępna w jednej wersji może zostać oznaczona jako przestarzała, zmienić zachowanie albo zostać usunięta w kolejnej wersji. Zmiana może dotyczyć zarówno jawnego polecenia, jak i elementu używanego pośrednio, na przykład domyślnej wartości kolumny, sposobu rzutowania typu tekstowego na liczbowy lub reguł interpretowania daty. Dlatego ocena zgodności wymaga porównania dokumentacji obu wersji oraz uruchomienia rzeczywistych zapytań na kopii danych testowych.

Składnia to tylko jeden poziom kompatybilności

Podczas migracji należy sprawdzić elementy języka zapytań używane przez aplikację. Przykładowo, zapytanie może przestać działać po zmianie nazwy funkcji, usunięciu klauzuli albo zaostrzeniu reguł dotyczących niejednoznacznych nazw kolumn. Parser może także zaakceptować dawną konstrukcję, ale zinterpretować ją inaczej. W takim przypadku problem nie zawsze pojawia się jako błąd; czasem aplikacja otrzymuje poprawnie sformatowany, lecz nieprawidłowy wynik.

Osobnej kontroli wymagają funkcje daty i czasu, operacje na tekstach oraz konwersje typów. Wynik dodawania miesiąca do daty zależy od reguł obsługi końca miesiąca, a porównanie tekstów może zależeć od zestawienia znaków i czułości na wielkość liter. Rzutowanie wartości zmiennoprzecinkowej na typ całkowity może obcinać część ułamkową albo zgłaszać błąd, zależnie od silnika i użytej funkcji. Test powinien obejmować wartości typowe, graniczne, puste oraz niepoprawne, ponieważ właśnie one ujawniają różnice między implementacjami.

Wpływ zgodności na wyniki i wydajność

Zmiana wersji silnika może wpłynąć na plan wykonania zapytania bez zmiany jego tekstu. Optymalizator może wybrać inny indeks, kolejność łączenia tabel lub sposób filtrowania danych. Sam wynik logiczny powinien pozostać zgodny, ale czas wykonania, zużycie pamięci i liczba odczytów stron mogą się zmienić. Zapytanie działające poprawnie na małej bazie testowej może po migracji przekroczyć limity czasu dla dużej tabeli, zwłaszcza gdy wcześniej korzystało z zachowania optymalizatora charakterystycznego dla starszej wersji.

Weryfikacja powinna obejmować porównanie liczby zwracanych rekordów, wartości kluczowych pól, liczby rekordów zmienionych przez instrukcje modyfikujące oraz zachowania transakcji przy błędach. Należy również sprawdzić blokady i poziom izolacji, ponieważ zmiana domyślnej konfiguracji może zmienić widoczność niezatwierdzonych danych albo kolejność oczekiwania transakcji. Przydatne są testy regresyjne uruchamiane na identycznym zbiorze danych, zapis planów wykonania oraz pomiar czasu zapytań przed i po migracji. Jeżeli aplikacja korzysta z przygotowanych zapytań, trzeba przetestować także parametry o różnych typach i rozmiarach.

Jak przygotować bezpieczny test migracji

Przed zmianą produkcyjnego silnika warto sporządzić wykaz używanych funkcji, rozszerzeń, typów danych, indeksów i obiektów programowalnych. Źródłem takiego wykazu mogą być pliki migracji schematu, kod aplikacji, definicje procedur oraz logi zapytań. Każdy element należy przypisać do jednej z kategorii: zgodny bez zmian, wymagający modyfikacji, zastąpiony innym mechanizmem albo nieobsługiwany. Szczególną uwagę trzeba zwrócić na funkcje oznaczone w dokumentacji jako deprecated, ponieważ ich obecność w bieżącej wersji nie gwarantuje zachowania w następnej.

Test migracyjny powinien używać kopii schematu i danych reprezentatywnych dla rzeczywistego obciążenia. Po odtworzeniu danych należy uruchomić zapytania odczytujące, operacje INSERT, UPDATE i DELETE, procedury, raporty oraz scenariusze rollbacku. Wyniki trzeba porównać automatycznie, a nie tylko wzrokowo. Warto także sprawdzić kodowanie tekstu, strefy czasowe, wartości NULL, uprawnienia obiektów i zachowanie po ponownym uruchomieniu aplikacji. Dopiero po przejściu tych testów można zaplanować migrację z kopią zapasową, określonym punktem powrotu i monitoringiem błędów po przełączeniu.