Przyczyn nieoptymalnego działania systemu może być wiele. Najczęściej jest to jedna lub kilka z poniższych.

Błędy na etapie projektowania.
Podczas projektowania systemu projektant tworzy strukturę bazy danych. Decyduje, jakie będą tabele, indeksy, widoki. Jakie będą pola w tabelach i jakie będą typy tych pół (tekstowy, tekstowy zmiennej długości, liczbowy itp.). Błędy popełnione na tym etapie mogą mieć wpływ na pracę całej aplikacji i mogą powodować jej niewydajność.

Przebudowy systemu
Większość aplikacji zmienia się, dostosowując się do potrzeb klientów, zmian warunków biznesowych, zmian przepisów itp. Czasem oznacza to bardzo radykalną zmianę systemu, np. system zaprojektowany jako ERP zostaje przekształcony na system CRM. Zmiany funkcjonalności wymuszają zmiany struktury, ale zazwyczaj jest to tylko lekka przebudowa istniejącej struktury bazy danych. Ten sam system był projektowany od zera, miałby zupełnie inną strukturę, lepiej dopasowaną do potrzeb. To samo dotyczy procesów i zapytań SQL – gdyby były tworzone od zera, raczej na pewno byłyby bardziej optymalne.

Błędy programistyczne
Dużo problemów wydajnościowych powstaje podczas developmentu.
Podczas prac programistycznych największy nacisk kładziony jest zazwyczaj na funkcjonalność i stabilność kodu. Programiści najczęściej mają do dyspozycji bazę developerską z bardzo ograniczonym zbiorem danych (rzędu kilku promili danych produkcyjnych), zdarza się, że są to dane generowane losowo.
Na tak małym zbiorze danych nawet nieoptymalne zapytania działają bardzo szybko.
Programiści mają małe szanse wychwycić na tym etapie faktyczne problemy wydajnościowe, mogą co najwyżej stosować tzw. dobre praktyki programistyczne, nie w każdym wypadku skuteczne.
Jak w każdej grupie zawodowej, wśród programistów są artyści, dobrzy rzemieślnicy i partacze.
I nawet bardzo dobry programista nie zawsze potrafi stworzyć wydajny kod SQL.

Na to wszystko nakłada się także stosowanie narzędzi typu Hibernate, które to na podstawie logiki w nich zapisanej same generują zapytania SQL do bazy, niekoniecznie optymalne.

Przyrost i rozkład danych
Wraz z rozwojem firmy rośnie ilość zleceń, faktur, klientów. Ilość zleceń dzisiaj może być nawet kilka razy większa, niż powiedzmy 5 lat temu. Rośnie ilość danych w tabelach (dane bieżące i te z przeszłości), zwiększa się ilość osób pracujących w systemie, zwiększa się ilość transakcji w ciągu dnia.
Wraz z rozwojem firmy może zmienić się rozkład danych. Np. wcześniej firma nastawiona była na sprzedaż hurtową (mało klientów, mało faktur, duża ilość pozycji na fakturze), teraz przeważa sprzedaż detaliczna (dużo klientów, duża ilość faktur, mało pozycji na fakturze).
W przypadku skomplikowanych zapytań SQL nawet niewielka zmiana rozkładu danych może spowodować jego niewydajne działanie.
To wszystko może sprawić, że nasz system może przestać działać wydajnie.

Uniwersalność systemu
Większość systemów IT (poza tymi pisanymi na zamówienie dla konkretnego klienta) tworzona jest jako systemy uniwersalne. Mogą działać zarówno u małego, jak i u dużego klienta. Mogą zarządzać zarówno produkcją mebli, żywności, jak i części samochodowych. Będą działać zarówno u klientów, którzy wystawiają 100 faktur miesięcznie, jak i u tych, którzy wystawiają ich 100 tysięcy dziennie.
I u każdego z tych klientów system musi działać w sposób akceptowalny pod względem wydajności.
Niestety co innego będzie najbardziej wydajne dla małej ilości danych, a co innego dla bardzo dużej.
Producenci oprogramowania muszą znaleźć kompromis – coś, co będzie dość wydajne w każdym przypadku.
Niestety oznacza to, że w naszym konkretnym przypadku nie jest to rozwiązanie najbardziej wydajne.

Customizacje
Większość systemów IT to gotowe systemy, które dostosowuje się dla danego klienta, zmieniając istniejące lub tworząc nowe moduły.
Ten sam system (z modyfikacjami pod danego klienta) działa już u kilkudziesięciu lub kilkuset klientów.
Jest duża szansa, że problemy wydajnościowe w części wspólnej systemu pojawiły się już u innego klienta i w taki czy inny sposób zostały rozwiązane przez dostawcę.

Każde firma ma inną specyfikę, więc jest bardzo nikła szansa, że taka sama customizacja została wdrożona u innego klienta i że problemy wydajnościowe zostały już zgłoszone i poprawione.

W związku z tym nawet w najlepszym, najwydajniej zaprojektowanym systemie mogą pojawić się niewydajne procesy.

Wdrożenie
Każdy, kto wdrażał nowy system IT, wie, że nie jest to łatwe. Nowy system trzeba dostosować do naszych procesów biznesowych. Trzeba dorobić specyficzne dla nas elementy – raporty, formatki itp. Często okazuje się, że właśnie w tych modyfikacjach pojawiają się błędy, trzeb je poprawić. Okazało się, że próbna migracja nie przebiegła poprawnie, część danych zmigrowała się błędnie. Do tego wszystkiego gonią nas terminy.
Wreszcie, po wielu perypetiach docieramy do momentu, kiedy wszystkie (lub prawie wszystkie) funkcjonalności działają poprawnie i uroczyście kończymy wdrożenie.

Nikt nie myśli o sprzątaniu środowiska po wdrożeniu.
Dostawca jest szczęśliwy, że wreszcie udało się zakończyć wdrożenie. Czasem wyrobił się w zakładanym budżecie, czasem go przekroczył. Nie jest zainteresowany wydawaniem pieniędzy na dodatkowe prace: porządkowanie środowiska po wdrożeniu oraz wyszukiwaniem i optymalizacją problematycznych zapytań.

Utrzymanie
Problemy wydajnościowe mogą pojawiać się także w przypadku braku odpowiednich kompetencji u administratorów baz danych.
Nasza baza zmienia się, zmienia się ilość i rozkład danych. Pojawiają się modyfikacje lub nowe komponenty systemu, a co za tym idzie inne, nowe zapytania SQL.
Bazę danych należy cyklicznie „sprzątać” – defragmentować tabele i indeksy, dbać o aktualność statystyk, dostosowywać przydział pamięci i inne parametry inicjalizacyjne do aktualnego obciążenia.
Na administratorze ciąży bardzo duża odpowiedzialność – to on może wykryć i usunąć większość problemów z wydajnością.
Niestety, nie każdy administrator dysponuję odpowiednimi umiejętnościami.

W kolejnym artykule opiszę, jakie mogą być efekty optymalizacji. Artykuł dostępny jest tutaj
Jeżeli kogoś zainteresował temat optymalizacji i chciałby się dowiedzieć czegoś więcej, zachęcam do kontaktu: optymalizacja@commit-it.pl

Zachęcam do samodzielnego sprawdzenia możliwości optymalizacji Waszych baz danych – przygotowaliśmy program do badania wydajności baz danych (na chwilę obecną gotowa jest wersja dla Oracle, pracujemy nad wersją dla MSSQL i PostgreSQL). Program jest bezpłatny, warunkiem jego używania jest rejestracja na stronie www.commit-it.pl/perfcheck