Dawno dawno temu, za górami, za lasami był sobie system, który miał pewne problemy wydajnościowe. W ramach diagnozy uruchomiliśmy SQL Trace celem namierzenia zapytania, które sprawia nam kłopoty. Wyniki trace'a były mniej więcej zgodne z naszymi wcześniejszymi podejrzeniami, co do możliwych "zamulaczy".
Jednak jedna rzecz spowodowała u nas opad szczęki.
Niespodziewanie w naszym TOP 5 najczęściej wykonywanych zapytań... Co ja mówię, nawet nie TOP 5 a zdecydowany, niedościgniony lider tego rankingu to było zapytanie...
select sysdate
from dual;
I to nie z nie byle jakim wynikiem! Podczas jednego procesu wykonań tego SQL'a było miliony! O ile nie miliardy!
Kompletnie nie spodziewaliśmy się takich wyników.
Można by zapytać, czy takie leciutkie zapytanie faktycznie może być problemem?
Kilkaset czy kilka tysięcy zapytań zapewne nie zrobi żadnej różnicy. Ale kilka milionów nawet szybkich zapytań w sumie daje już jakiś realny dodatkowy czas.
Trzeba też pamiętać, że wykonywanie zapytań SQL (DUAL TO TABELA!) w procedurach składowanych skutkuje przełączaniem kontekstu. A przełączanie kontekstu to kolejne "wydane" niepotrzebnie ułamki sekund.
No tak, ale SYSDATE jest często bardzo istotne z punktu widzenia funkcjonalności biznesowych. Procesy oparte są o bieżącą datę i od niej zależą. Faktury wystawiane są zawsze 3 dnia miesiąca, kapitalizacja odsetek wykonuje się ostatniego dnia miesiąca, opłata roczna nalicza się raz do roku konkretnego dnia (dni wykonywania tych czynności kompletnie przypadkowe ! :D ). Bez SYSDATE się nie da!
Poświęcamy więc wydajność na rzecz spełnienia wymagań biznesowych. Co zrobisz jak nic nie zrobisz...Co zrobisz? Nic nie zrobisz....
Ale czy faktycznie nie ma możliwości pozbycia się kłopotliwego zapytania?
Okazuje się, że wystarczy tylko niewielka zmiana w kodzie PL/SQL!
Zamiast zapytania
select sysdate
from dual;
wystarczy przypisać wartość SYSDATE bezpośrednio do zmiennej
dCurrentDate := SYSDATE;
Wprawdzie oczekiwać, że po takiej zmianie nasz system wystrzeli jak rakieta byłoby trochę zbyt hurraoptymistyczne. Niemniej jednak przynajmniej dajemy naszej bazie szansę, by zajęła się czymś pożytecznym a nie w kółko pobierała datę z DUAL :D
Zdaję sobie sprawę, że zamiana w systemie WSZYSTKICH zapytań o SYSDATE może być więcej niż kłopotliwa, niemniej jednak poddawać się nie można i w miarę możliwości należy zmieniać, poprawiać., reenginerować. A jak mamy szczęście i piszemy system od tak zwanego ZERA to od razu zapomnieć o czymś takim jak DUAL.
Jakość i wydajność systemu to nie zawsze skomplikowana optymalizacja wielopiętrowych zapytań SQL, strojenie parametrami czy dorzucanie dysków i pamięci.
Jakość i wydajność to także te wszystkie drobne szczególiki na poziomie naszych zapytań SQL czy kodu PL/SQL.
Sami sprawdźcie, ile macie zapytań do DUAL. Ja jutro sprawdzę!
Nie zapomnijcie o triggerach! Tam najczęściej czai się SYSDATE i DUAL!
Komentarze
Prześlij komentarz