Debugowanie procedury

Debugowanie procedury to proces krokowej analizy wykonania kodu w celu zlokalizowania błędu w procedurze składowanej.

Cel i zakres debugowania procedury

Debugowanie procedury składowanej polega na prześledzeniu jej wykonania w celu ustalenia, gdzie rzeczywiste zachowanie kodu różni się od oczekiwanego. Procedura składowana jest zapisanym po stronie systemu zarządzania bazą danych zestawem instrukcji, który może przyjmować parametry, wykonywać zapytania, modyfikować dane i zwracać wynik albo kod statusu. Błąd może dotyczyć składni, typów danych, warunków logicznych, kolejności operacji, obsługi wartości pustych lub wpływu instrukcji na kolejne fragmenty procedury.

Analiza powinna rozpocząć się od dokładnego określenia objawu. Należy ustalić, jakie parametry zostały przekazane, jaki wynik był oczekiwany, jaki wynik faktycznie zwrócono oraz czy wykonanie zakończyło się błędem. Sam komunikat o nieprawidłowym wyniku nie wskazuje jeszcze miejsca usterki, ponieważ przyczyna może znajdować się wcześniej, na przykład w zapytaniu pobierającym niepełny zestaw rekordów albo w instrukcji przypisującej wartość do zmiennej. Istotne jest również rozróżnienie błędu danych od błędu przepływu sterowania.

Śledzenie parametrów, zmiennych i warunków

Podczas krokowego wykonywania procedury sprawdza się wartości parametrów wejściowych oraz zmiennych lokalnych po każdej instrukcji, która może je zmienić. Szczególną uwagę należy zwrócić na konwersje typów, wartości NULL, obcinanie tekstu oraz różnice między liczbą całkowitą, dziesiętną i zmiennoprzecinkową. Wartość NULL nie jest równa zeru ani pustemu tekstowi, dlatego warunek porównujący kolumnę lub zmienną z NULL za pomocą operatora równości może nie zwrócić oczekiwanego rezultatu. W zależności od używanego silnika właściwe sprawdzenie wymaga operatora lub predykatu przeznaczonego do obsługi wartości NULL.

W procedurach zawierających rozgałęzienia należy analizować każdy warunek oraz ustalić, która gałąź została wykonana. Błąd może wynikać z warunku zbyt szerokiego, zbyt wąskiego albo z nieprawidłowego połączenia operatorów AND i OR. Przydatne jest zapisanie wartości pośrednich w komunikacie diagnostycznym, tabeli pomocniczej lub narzędziu śledzącym, o ile nie zmienia to semantyki badanego kodu. Należy jednak odróżnić obserwację od modyfikacji: dodanie instrukcji diagnostycznej może wpływać na czas wykonania, blokady, kolejność odczytów lub zachowanie transakcji.

Transakcje, błędy i wpływ kolejności operacji

Debugowanie obejmuje także sprawdzenie granic transakcji. Jeżeli procedura wykonuje kilka operacji zapisu, trzeba ustalić, kiedy rozpoczyna się transakcja, w którym miejscu następuje zatwierdzenie oraz czy w przypadku błędu wykonywane jest wycofanie zmian. Częściowo wykonana procedura może pozostawić dane w stanie pośrednim, jeśli obsługa błędu obejmuje tylko komunikat, ale nie przywraca spójności operacji. Analizuje się również, czy procedura jest wywoływana wewnątrz transakcji rozpoczętej przez kod aplikacji, ponieważ wtedy jej decyzje dotyczące zatwierdzania lub wycofywania mogą mieć szerszy skutek.

Nieprawidłowa kolejność instrukcji również może powodować pozornie losowe wyniki. Odczyt wykonany przed uzupełnieniem tabeli tymczasowej, aktualizacja przeprowadzona przed sprawdzeniem warunku albo usunięcie rekordu przed pobraniem zależnych informacji zmienia dalszy przebieg procedury. Warto sprawdzić, czy zapytania używają tych samych kryteriów filtrowania, typów złączeń i zasad sortowania. Należy także obserwować blokady, konflikty współbieżności i czas oczekiwania, ponieważ procedura może działać poprawnie dla jednego wywołania, lecz zwracać nieoczekiwane dane przy równoległym wykonaniu przez kilka sesji.

Weryfikacja poprawki i diagnostyka środowiska

Po zlokalizowaniu miejsca błędu poprawkę należy sprawdzić na powtarzalnym zestawie danych. Test powinien obejmować typowy przypadek, wartości graniczne, brak pasujących rekordów, wartości NULL, nieprawidłowe parametry oraz sytuację, w której procedura zostaje przerwana w trakcie działania. Jeżeli procedura modyfikuje dane, testy powinny być wykonywane na kopii danych albo w kontrolowanej transakcji, którą można bezpiecznie wycofać. Sam fakt, że jeden przypadek zwrócił poprawny wynik, nie potwierdza jeszcze poprawności wszystkich gałęzi kodu.

W praktycznej diagnostyce laptopa lub komputera PC analiza procedury może wymagać sprawdzenia aplikacji wywołującej bazę, konfiguracji połączenia, logów błędów i uprawnień użytkownika. Należy porównać wersję procedury używaną w środowisku testowym z wersją uruchamianą przez aplikację, ponieważ różnica w schemacie, parametrach lub wdrożonym kodzie może sprawiać wrażenie błędu samej procedury. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, a w przypadku problemów z działaniem oprogramowania można rozpocząć od ustalenia, czy źródłem objawu jest kod, konfiguracja systemu, połączenie z bazą czy stan danych.