Sprawdzanie zgodności zapytań

Sprawdzanie zgodności zapytań po migracji pozwala wykryć regresje wydajności wynikające ze zmiany optymalizatora.

Na czym polega sprawdzanie zgodności zapytań po migracji

Sprawdzanie zgodności zapytań po migracji bazy danych polega na porównaniu działania tych samych instrukcji SQL przed zmianą środowiska i po jej wykonaniu. Migracja może oznaczać przeniesienie danych do innego serwera, zmianę wersji silnika, zmianę konfiguracji, odtworzenie kopii zapasowej albo przejście na inną platformę sprzętową. Sam fakt, że zapytanie nadal się wykonuje, nie potwierdza jego pełnej zgodności. Należy sprawdzić zarówno poprawność składni, jak i zwracane dane, typy kolumn, kolejność wyników oraz zachowanie w przypadku wartości pustych i granicznych.

Weryfikacja obejmuje zapytania wykonywane bezpośrednio przez aplikację, procedury zapisane w bazie, widoki, wyzwalacze oraz zadania cykliczne. Szczególną uwagę zwraca się na elementy zależne od konkretnego silnika, takie jak funkcje daty i czasu, konkatenacja tekstów, konwersje typów, obsługa identyfikatorów, składnia paginacji oraz sposób porównywania wartości tekstowych. Jeżeli po migracji używany jest inny silnik bazy danych, instrukcja może wymagać dostosowania, nawet gdy nazwa SQL pozostaje podobna.

Porównanie wyników, typów danych i efektów ubocznych

Podstawowym testem jest uruchomienie tego samego zapytania na porównywalnym zbiorze danych w starym i nowym środowisku. Wyniki powinny być zestawione w sposób niezależny od przypadkowej kolejności rekordów, chyba że zapytanie zawiera jednoznaczne sortowanie za pomocą klauzuli ORDER BY. Porównuje się liczbę zwróconych wierszy, wartości poszczególnych kolumn, wartości NULL, precyzję liczb dziesiętnych oraz reprezentację dat i znaczników czasu. Brak sortowania nie jest sam w sobie błędem, ale aplikacja nie powinna zakładać kolejności wyników, której zapytanie nie określa.

Niektóre zapytania nie tylko odczytują dane, lecz także je zmieniają. Dla instrukcji INSERT, UPDATE i DELETE trzeba sprawdzić liczbę zmodyfikowanych rekordów, działanie warunków filtrujących oraz wpływ ograniczeń integralności. Test powinien uwzględniać transakcję, wycofanie zmian i ponowne wykonanie operacji. W przypadku procedur lub wyzwalaczy należy zweryfikować, czy po migracji nadal powstają te same wpisy zależne, aktualizują się odpowiednie kolumny i nie pojawiają się dodatkowe błędy wynikające z kluczy obcych, unikalności albo zmienionej wartości domyślnej.

Regresje planów wykonania i zmiana optymalizatora

Zgodność funkcjonalna nie gwarantuje zachowania wydajności. Po zmianie wersji silnika lub konfiguracji może zostać wybrany inny plan wykonania, ponieważ optymalizator ocenia dostępne indeksy, statystyki, selektywność predykatów i przewidywaną liczbę wierszy. Zapytanie może nadal zwracać prawidłowe dane, lecz wykonywać pełne skanowanie tabeli zamiast używać indeksu albo wybierać kosztowne złączenie dla dużych zbiorów. Dlatego dla zapytań krytycznych porównuje się plan wykonania, czas realizacji, liczbę odczytanych stron lub rekordów oraz zużycie pamięci i procesora, o ile dany silnik udostępnia takie informacje.

Przed pomiarem należy zapewnić możliwie porównywalne warunki: podobny rozmiar danych, aktualne statystyki, te same parametry zapytania i porównywalne obciążenie systemu. Trzeba odróżnić czas pierwszego wykonania od czasu kolejnych uruchomień, ponieważ wynik może zależeć od pamięci podręcznej planów i danych. Warto testować zarówno typowe wartości parametrów, jak i wartości skrajne. Predykat zwracający prawie wszystkie rekordy może wymagać innej strategii niż ten sam predykat użyty dla rzadkiej wartości. Takie różnice mogą ujawnić regresję, której nie widać podczas testu na małej próbce.

Praktyczny zakres testów po przeniesieniu bazy

Kontrolę najlepiej rozpocząć od spisu zapytań używanych przez najważniejsze funkcje aplikacji i od instrukcji, które wcześniej powodowały największe obciążenie. Każde zapytanie powinno mieć określone dane wejściowe, oczekiwany rezultat oraz warunki uznania testu za poprawny. Należy uwzględnić wyszukiwanie bez wyników, pojedynczy wynik, dużą liczbę wyników, brak opcjonalnego parametru, wartości NULL oraz znaki spoza podstawowego alfabetu. W testach zapisu trzeba dodatkowo sprawdzić powtórzenie tej samej operacji, konflikt unikalności i zachowanie po przerwaniu transakcji.

Jeżeli wykryto różnicę, należy ustalić jej rodzaj: błąd składni, zmianę semantyki, odmienny typ danych, rozbieżny wynik, zmianę planu wykonania albo problem z konfiguracją połączenia. Samo wydłużenie czasu wykonania nie dowodzi jeszcze błędu danych, ale może wskazywać na regresję wymagającą analizy indeksów, statystyk lub parametrów optymalizatora. Wyniki porównania powinny obejmować treść zapytania, parametry, czas wykonania, plan lub jego istotne elementy oraz wersję środowiska. Taki zapis pozwala odtworzyć problem i odróżnić rzeczywistą niezgodność od różnicy wynikającej z niekontrolowanych warunków testowych.