Aplikacje biznesowe stają się coraz bardziej skomplikowane, a ilość danych składowanych w bazach radykalnie wzrasta. Wiąże się z tym bardzo duże obciążenie serwerów przy operacjach związanych z przetwarzaniem danych i pracą aplikacji. Z drugiej strony, oczekiwania po stronie użytkowników aplikacji wymagają zachowania zaplanowanych czasów odpowiedzi, gdyż od tego zależy jakość obsługi klienta, sprzedaż lub świadczenie różnych usług. Standardową bazą biznesową jest Oracle. W przypadku aplikacji biznesowych korzystających z tej bazy umiejętności związane z optymalizacją są wysoce cenione.

Gdy aplikacja jest rozwijana, pojawiają się problemy wydajnościowe, które objawiają się wzrostem czasu odpowiedzi aplikacji, problemami z zakończeniem przetwarzania wsadowego w wymaganym czasie, a nawet blokadą pracy aplikacji spowodowaną radykalnym spadkiem wydajności bazy. Standardowa odpowiedź producentów aplikacji oraz dostawców sprzętu i oprogramowania brzmi wtedy: kupić mocniejszą maszynę. Oczywiście, mocniejszy sprzęt podwyższy wydajność aplikacji, ale nie będzie to radykalna zmiana, gdyż wdrożenie nowej maszyny powoduje co najwyżej liniowy wzrost mocy obliczeniowej, a przy niektórych zadaniach firmy oczekują poprawy o rząd lub dwa rzędy wielkości. Modernizacja sprzętu nie zawsze może zapewnić taki skok wydajności.

Skąd ten problem?

Przyczyną opóźnień w przetwarzaniu danych mogą być zapytania, które powodują bardzo duże obciążenie CPU, odczytują wiele danych z podsystemu składowania, a także powodują inne problemy. Rozwiązanie polegające na wymianie sprzętu na mocniejszy, na przykład wyposażony w większą liczbę rdzeni, nie zawsze przynosi oczekiwane efekty, gdyż nie wszystkie problemy da się rozwiązać w ten sposób.

Przykładem aplikacji, które są trudne w klasycznej optymalizacji, jest oprogramowanie billingowe u operatorów telekomunikacyjnych oraz narzędzia związane z obsługą bardzo rozległych magazynów, posiadających kilkaset tysięcy parametrów przy milionach sztuk obiektów i rozległych raportach. Podstawowe działania związane z optymalizacją wydajnościową zazwyczaj już dawno zostały w tych miejscach zrealizowane i dalsze proste zmiany rzadko przynoszą oczekiwaną poprawę pracy aplikacji.

Są firmy, w których liczba indeksów w magazynie przekracza nawet 1 milion. Czas przetwarzania danych w takiej sytuacji intensywnie rośnie, powodując kolejkę przy kasie, opóźnienie księgowania, problemy przy dziennym przetwarzaniu danych. Problemy narastają w miarę rozwoju firmy, stawiając menedżera IT przed trudną decyzją związaną z dalszym utrzymaniem IT w firmie. Musi on albo zakupić nowy sprzęt i nowe licencje (koszty bywają liczone w milionach złotych), albo zamówić usługę optymalizacji bazy w firmie Oracle, bez gwarancji rozwiązania problemu. Dzięki dobrej optymalizacji można dokonać poprawy wydajności o dwa rzędy wielkości (sto razy). Można to uzyskać z gwarancją efektu, także w sposób gwarantowany metodologią i oprogramowaniem. Należy jednak zmienić podejście - zamiast szukać problemów ad hoc, należy analizować pracę bazy, by móc wyciągnąć wnioski.

Jak zmierzyć kłopotliwe zapytania

Aby móc dokonać optymalizacji, niezbędne są pomiary rzeczywistego wykonywania zapytania. Oczywiście, każdy administrator bazy Oracle potrafi posłużyć się poleceniami analizy zapytań (na przykład EXPLAIN PLAN), ale uzyskiwane efekty nie są wystarczające. Typowe narzędzia administracyjne nie dostarczą szczegółowych statystyk na temat obciążenia poszczególnych elementów bazy i systemu operacyjnego. Aby dokonać sensownej optymalizacji, należy analizować pracę bazy przez dłuższy czas, by wychwycić nie tylko same zapytania bezpośrednio wywołujące problemy, ale także te, które mogą mieć wpływ na obniżenie wydajności bazy w dłuższym horyzoncie czasowym. Tego proste narzędzia administracyjne nie potrafią.