Baza danych zwalnia — gdzie szukać przyczyny

Jak wygląda problem od strony użytkownika

Typowe zgłoszenie brzmi: „program działa wolno". Za tym zdaniem kryją się jednak bardzo różne sytuacje, a rozróżnienie ich jest pierwszym krokiem diagnozy.

Wolno wszystko czy tylko konkretna operacja? Cały czas czy o określonych porach? Na wszystkich stanowiskach czy na jednym? Od zawsze, czy od konkretnej daty? Cztery pytania, które zawężają obszar poszukiwań z całego systemu do jednego elementu.

Najczęściej odpowiedzi układają się w schemat: konkretna operacja, na wszystkich stanowiskach, narastająco od kilku miesięcy. To wskazuje na bazę danych, a nie na sieć ani na komputery użytkowników.

Jak zgłaszać spowolnienia, żeby diagnoza była krótsza

Zgłoszenie „znowu wolno działa” wysłane dzień później niewiele mówi osobie, która ma szukać przyczyny. Większość problemów z wydajnością jest chwilowa, więc liczy się dokładny moment i okoliczności. Dobrze opisane zgłoszenia potrafią skrócić diagnozę z kilku dni do kilku godzin.

Najprościej przygotować wspólny arkusz albo formularz, w którym pracownicy zapisują każdy przypadek. Po tygodniu widać wzorzec: te same godziny, ta sama operacja, ci sami użytkownicy.

• Data i godzina, najlepiej z dokładnością do minut
• Stanowisko i nazwa użytkownika
• Operacja: co dokładnie było robione i w którym oknie programu
• Czas oczekiwania, choćby szacunkowy
• Treść komunikatu, jeśli się pojawił, albo zrzut ekranu
• Czy w tym samym czasie ktoś inny też zgłaszał problem

Taki dziennik przydaje się szczególnie w firmach z kilkoma lokalizacjami. Gdy zgłoszenia z oddziału w Kraśniku pojawiają się o innych porach niż z biura w Lublinie, trop prowadzi raczej do łącza albo do zadań uruchamianych w oddziale niż do samej bazy.

Zmierz, zanim zaczniesz naprawiać

Zdanie „system działa wolniej niż kiedyś” nie wystarczy, żeby ocenić efekt naprawy. Przed jakimikolwiek zmianami warto zmierzyć czas kilku operacji, które przeszkadzają najbardziej.

Takie pomiary powtarza się po każdej zmianie. Dzięki nim wiadomo, co naprawdę pomogło, a co tylko wyglądało na poprawę.

Czy to na pewno baza: sieć, stanowiska i program

Nie każde spowolnienie ma przyczynę w bazie. Jeśli wolno działa tylko jedno stanowisko, problem leży zwykle w komputerze albo w połączeniu z siecią. Jeśli wolno działają wszystkie stanowiska w oddziale, a w centrali szybko — w łączu między lokalizacjami.

Warto też sprawdzić, czy spowolnienie nie zbiegło się z aktualizacją programu, systemu albo oprogramowania antywirusowego. Zmiana ustawień skanowania plików potrafi spowolnić pracę bardziej niż rozrost bazy.

Prosty test: jeśli ta sama operacja wykonana bezpośrednio na serwerze jest szybka, a na stanowiskach wolna, winna jest sieć albo komputery. Jeśli wolna jest wszędzie — baza albo serwer.

Przyczyna pierwsza: brakujące indeksy

To najczęstsza i najłatwiejsza do usunięcia przyczyna. Indeks działa jak spis treści: bez niego baza musi przejrzeć całą tabelę, żeby znaleźć jeden rekord.

Przy tysiącu rekordów różnica jest niezauważalna. Przy milionie — to różnica między dziesiątą częścią sekundy a kilkunastoma sekundami. Dlatego problem pojawia się dopiero po latach, gdy dane urosną.

Indeksy znikają albo nie powstają najczęściej po imporcie danych, po migracji na nowy serwer i po przywróceniu bazy z kopii wykonanej nieodpowiednim narzędziem. Warto sprawdzić to w pierwszej kolejności, bo naprawa bywa kwestią godziny.

Przyczyna druga: baza rosnąca bez konserwacji

Bazy systemów handlowych i sklepów rosną nie tylko o dane, na których zależy firmie. Rosną też o logi operacji, historię zmian, sesje użytkowników, porzucone koszyki i dane tymczasowe, których nikt nigdy nie usuwa.

Po kilku latach potrafi to stanowić większość objętości bazy. Same w sobie nie przeszkadzają, ale spowalniają kopie zapasowe, wydłużają operacje konserwacyjne i zajmują pamięć, która przydałaby się gdzie indziej.

Uporządkowanie polega na ustaleniu, co można usunąć albo zarchiwizować, i wprowadzeniu regularnego czyszczenia. To jednorazowa praca plus zadanie cykliczne — a efekt bywa zaskakująco duży.

Archiwizacja zamiast usuwania

Gdy baza rośnie o dane sprzed lat, pierwszą myślą jest ich usunięcie. W systemach handlowych i księgowych to zwykle zły pomysł: dokumenty mogą być potrzebne przy kontroli, reklamacji albo analizie sprzedaży.

Lepszym rozwiązaniem jest archiwizacja. Starsze dane przenosi się do osobnej bazy dostępnej do odczytu, a baza robocza zawiera tylko ostatnie lata. Program działa szybciej, a historia pozostaje dostępna, gdy jest potrzebna.

Archiwizacja wymaga zaplanowania: co przenieść, jak zachować powiązania między danymi i jak sięgać do archiwum. Takie prace wykonujemy w ramach optymalizacji baz danych.

Przyczyna trzecia: brak regularnej konserwacji

Bazy danych wymagają okresowej konserwacji: przebudowy indeksów, aktualizacji statystyk, sprawdzenia spójności. W wielu instalacjach nikt tego nie robi, bo nikt nie wie, że trzeba.

Skutek narasta powoli. Indeksy tracą efektywność, plany wykonania zapytań stają się nieoptymalne, a baza wykonuje coraz więcej pracy przy tych samych operacjach.

Wprowadzenie zadań konserwacyjnych to zwykle kilka godzin pracy i konfiguracja harmonogramu. Efekt bywa natychmiastowy i utrzymuje się, o ile zadania faktycznie się wykonują — co też warto monitorować.

Ustawienia z dnia instalacji, które szkodzą po latach

Wiele baz działa na ustawieniach wybranych przy instalacji, gdy dane zajmowały ułamek obecnej objętości. Nikt do nich nie wraca, bo przez pierwsze lata nie sprawiały kłopotów. Z czasem zaczynają spowalniać zapisy i wydłużać każdą większą operację.

Zmiana tych ustawień zwykle nie wymaga przerwy w pracy albo wystarcza jej krótkie okno serwisowe. Trzeba ją jednak poprzedzić pełną kopią i sprawdzeniem, czy na dysku jest miejsce na docelowy rozmiar plików. Szerzej o konfiguracji serwera bazy piszemy w artykule Microsoft SQL Server w małej firmie.

Aktualizacje programu i serwera bazy

Aktualizacje programów handlowych często zmieniają strukturę bazy: dodają tabele, kolumny i nowe mechanizmy. Zwykle przebiegają bez problemów, ale czasem zostawiają bazę bez odświeżonych statystyk albo z nowymi zapytaniami, które działają wolniej.

Dlatego po każdej większej aktualizacji warto powtórzyć pomiary kluczowych operacji i uruchomić zadania konserwacyjne. Jeśli coś zwolniło, lepiej wykryć to w pierwszym tygodniu niż po kwartale.

Warto też pilnować aktualizacji samego serwera bazy i systemu operacyjnego. Brak poprawek to nie tylko ryzyko bezpieczeństwa, ale też czasem znane problemy wydajności, które producent już dawno naprawił.

Przyczyna czwarta: pojedyncze ciężkie zapytania

Czasem cała reszta działa poprawnie, a problem tworzy jedna operacja: raport przeliczający wszystko od początku, zestawienie generowane w godzinach szczytu albo synchronizacja odpytująca bazę tysiąc razy zamiast raz.

Objaw charakterystyczny: system zwalnia o konkretnych porach — rano, gdy ktoś generuje raport, albo co godzinę, gdy uruchamia się synchronizacja ze sklepem.

Diagnoza wymaga podejrzenia, co baza faktycznie wykonuje w tych momentach. Naprawa bywa prosta: przeniesienie ciężkiej operacji na noc, ograniczenie zakresu danych albo poprawienie sposobu, w jaki integracja pobiera dane.

Nawyki użytkowników, które obciążają bazę

Część spowolnień nie wynika z bazy ani z programu, tylko ze sposobu, w jaki ludzie z niego korzystają. Program pozwala otworzyć listę wszystkich dokumentów od początku działalności, więc ktoś robi to codziennie rano, zamiast ustawić filtr na bieżący miesiąc.

Takie nawyki są niewidoczne dla osoby, która je ma, bo dla niej to po prostu normalna praca. Wychodzą przy obserwacji systemu w godzinach pracy albo w rozmowie z użytkownikami.

• Listy dokumentów i towarów otwierane bez filtra daty lub grupy
• Wyszukiwanie po fragmencie nazwy w całej kartotece, gdy wystarczyłby kod
• Kilka okien z tymi samymi raportami otwartych przez cały dzień
• Eksport pełnych zestawień do arkusza kilka razy dziennie
• Program zostawiony na noc z otwartą edycją dokumentu

Rozwiązanie to zwykle kilka ustawień domyślnych w programie i krótka rozmowa z zespołem. Warto ustawić filtry otwierane domyślnie, przygotować zestawienia generowane w nocy i wyjaśnić, dlaczego towar szukany po kodzie znajduje się szybciej niż po fragmencie nazwy.

Blokady: gdy jedna operacja zatrzymuje wszystkich

Czasem system nie jest wolny cały czas, tylko co jakiś czas „staje” na kilkadziesiąt sekund dla wszystkich użytkowników. Najczęstszą przyczyną są blokady: jedna długa operacja trzyma dane, na które czekają pozostałe.

Typowy przykład to raport uruchomiony w godzinach pracy, który przez minutę blokuje tabelę dokumentów, albo synchronizacja, która aktualizuje tysiące pozycji jedną transakcją.

Diagnoza polega na podejrzeniu, która sesja blokuje inne w chwili zawieszenia. Naprawa to zwykle zmiana harmonogramu, podział dużej operacji na mniejsze części albo poprawa samego zapytania.

Integracje ze sklepem i Allegro jako źródło obciążenia

Wiele firm zauważa spowolnienie po uruchomieniu integracji ze sklepem internetowym albo serwisem sprzedażowym. To nie przypadek: integracja co kilka minut odpytuje bazę o stany, ceny i nowe zamówienia.

Dobrze napisana integracja pobiera tylko to, co się zmieniło. Źle napisana za każdym razem odczytuje cały katalog, co przy kilkudziesięciu tysiącach pozycji obciąża serwer tak samo jak kilku dodatkowych użytkowników pracujących bez przerwy.

Warto sprawdzić, jak często integracja się uruchamia i ile danych pobiera. Opisujemy to szerzej w artykule o integracji sklepu z systemem magazynowym.

Przyczyna piąta: sprzęt, który przestał wystarczać

Serwer dobrany do firmy sprzed pięciu lat obsługuje dziś dwa razy więcej danych i dwa razy więcej stanowisk. W pewnym momencie przestaje wystarczać — i to jest normalne, a nie czyjaś wina.

Najczęściej wąskim gardłem jest pamięć operacyjna, a dopiero potem dysk i procesor. Baza, która nie mieści się w pamięci, musi sięgać do dysku znacznie częściej — i wtedy rodzaj nośnika zaczyna decydować o wszystkim.

Zanim jednak kupicie nowy serwer, warto sprawdzić poprzednie cztery punkty. Nierzadko okazuje się, że po uporządkowaniu bazy obecny sprzęt wystarcza na kolejne trzy lata — a to oszczędność rzędu kilkunastu tysięcy złotych.

Serwer wirtualny, dyski i kopie w godzinach pracy

Coraz więcej baz działa na serwerach wirtualnych, dzielących fizyczny sprzęt z innymi maszynami. To wygodne, ale wprowadza nowe przyczyny spowolnień: inna maszyna na tym samym sprzęcie może zabierać zasoby dokładnie wtedy, gdy baza ich potrzebuje.

Warto sprawdzić, ile pamięci i procesora faktycznie dostaje maszyna z bazą i czy dyski nie są współdzielone z intensywnie pracującymi usługami, na przykład z serwerem plików albo systemem kopii.

Częstym i łatwym do usunięcia problemem są też kopie zapasowe uruchamiane w godzinach pracy. Kopia całej maszyny w środku dnia potrafi spowolnić system dla wszystkich użytkowników.

Kolejność diagnozy

Diagnoza kosztuje mniej niż zgadywanie. Poniższa kolejność sprawdza się w większości przypadków i pozwala odrzucić najtańsze przyczyny, zanim zacznie się rozważać zakupy.

• Ustalenie, co dokładnie jest wolne i od kiedy
• Sprawdzenie indeksów na najczęściej używanych tabelach
• Pomiar wielkości bazy i udziału danych tymczasowych
• Sprawdzenie, czy zadania konserwacyjne w ogóle się wykonują
• Podejrzenie najcięższych zapytań i ich częstotliwości
• Dopiero na końcu: obciążenie serwera i zasoby

Rozmowa z producentem programu i firmą wdrożeniową

Część przyczyn spowolnienia leży po stronie samego programu: sposobu, w jaki buduje zapytania, albo błędów poprawionych w nowszej wersji. Tego nie naprawi się w bazie, ale da się to zgłosić producentowi lub firmie, która program wdrażała.

Takie zgłoszenie jest skuteczne, gdy zawiera konkrety. Opis „program jest wolny” trafia na koniec kolejki. Opis konkretnej operacji z czasem wykonania, wersją programu i informacją, że problem powtarza się na wszystkich stanowiskach, daje szansę na rzeczową odpowiedź.

• Wersja programu i data ostatniej aktualizacji
• Lista operacji, które zwolniły, wraz z pomiarami
• Informacja, czy spowolnienie pojawiło się po aktualizacji
• Wielkość bazy i liczba pracujących stanowisk
• Wyniki sprawdzenia indeksów i zadań konserwacyjnych

W firmach z Łęcznej, Lubartowa czy Świdnika spotykamy sytuację, w której firma wdrażająca program po latach nie świadczy już wsparcia albo nie zajmuje się bazą. Wtedy warto rozdzielić odpowiedzialność: program zostaje po stronie producenta lub partnera, a stan bazy i serwera przejmuje ktoś, kto zajmuje się tym na co dzień — na przykład w ramach optymalizacji baz danych w Świdniku.

Przykład: hurtownia, w której faktura trwała kilkanaście sekund

Typowy przypadek z firm z regionu: hurtownia z kilkunastoma stanowiskami, system handlowy na kilkuletnim serwerze i coraz dłuższe wystawianie faktur. Właściciel rozważa zakup nowego serwera i zmianę programu.

Diagnoza pokazuje trzy rzeczy: brak zadań konserwacyjnych od czasu przeniesienia bazy, tabelę dziennika zdarzeń zajmującą większą część bazy i integrację ze sklepem pobierającą cały katalog co kilka minut.

Po przebudowie indeksów, archiwizacji dziennika i zmianie integracji na pobieranie tylko zmian faktury wystawiają się wyraźnie szybciej, a obecny serwer wystarcza na kolejne lata. Cały zakres prac zajmuje kilka dni, bez zmiany systemu.

Czego nie robić

Nie kupować nowego serwera jako pierwszego kroku. To najdroższa możliwa reakcja i w połowie przypadków nie rozwiązuje problemu, bo przyczyna leży w bazie, nie w sprzęcie.

Nie usuwać danych bez kopii i bez zrozumienia, co się usuwa. Historia operacji bywa potrzebna przy kontroli albo reklamacji, a jej brak kosztuje więcej niż wolniejszy system.

Nie wprowadzać kilku zmian naraz. Wtedy nie wiadomo, która pomogła, a przy następnym problemie zaczyna się od zera. Jedna zmiana, pomiar, kolejna zmiana.

• Zakup nowego serwera przed diagnozą
• Usuwanie danych bez kopii zapasowej
• Kilka zmian naraz, bez pomiaru między nimi
• Kopie wykonywane w godzinach pracy
• Zadania konserwacyjne skonfigurowane, ale niedziałające

Jak nie dopuścić do powtórki

Trzy rzeczy wystarczają, żeby problem nie wrócił: regularna konserwacja bazy, monitoring czasu wykonania kluczowych operacji i okresowe czyszczenie danych tymczasowych.

Monitoring jest tu najważniejszy, bo pozwala zauważyć narastanie problemu, zanim stanie się odczuwalny. Pomiar czasu wystawienia dokumentu raz w tygodniu wystarcza, żeby zobaczyć trend.

Do tego warto raz na rok sprawdzić, czy sprzęt nadal odpowiada skali firmy. Planowa wymiana jest znacznie tańsza niż awaryjna — i da się ją zaplanować poza sezonem.

Sprawdź wydajność przed zmianą, a nie po niej

Wiele spowolnień da się przewidzieć, bo pojawiają się po konkretnej zmianie w firmie: uruchomieniu nowej integracji, dołączeniu oddziału, zatrudnieniu kilku osób albo imporcie dużego katalogu. Zamiast czekać na zgłoszenia, lepiej sprawdzić wpływ takiej zmiany z wyprzedzeniem.

Przed większymi zmianami warto też mieć sprawdzoną kopię bazy, z której da się wrócić do stanu sprzed operacji. Jak ją zorganizować i przetestować, opisujemy w artykule o kopiach zapasowych w firmie.

Monitoring: kilka liczb raz w tygodniu

Nie trzeba rozbudowanego systemu monitoringu, żeby wcześnie zauważyć problem. Wystarczy kilka liczb sprawdzanych regularnie i zapisywanych w jednym miejscu.

• Wielkość bazy i tempo jej wzrostu
• Wolne miejsce na dysku z danymi i na kopie
• Czy zadania konserwacyjne i kopie wykonały się bez błędów
• Czas kilku kluczowych operacji w programie
• Najdłużej trwające zapytania z ostatniego tygodnia

Taki przegląd zajmuje kwadrans, a pozwala zauważyć trend na długo, zanim użytkownicy zaczną zgłaszać problemy. Przy firmach bez działu IT prowadzimy go w ramach outsourcingu IT.

Firmy z regionu: najczęstsze sytuacje

W firmach handlowych i produkcyjnych z Lublina, Puław czy Chełma bazy danych systemów handlowych rzadko mają opiekuna. Program wdrożyła firma zewnętrzna, serwer ustawił informatyk, który już nie pracuje, a baza od lat działa „sama”.

Najczęściej znajdujemy brak konserwacji, kopie na tym samym dysku co baza i wersję bezpłatną serwera bazy zbliżającą się do swojego limitu. Każda z tych rzeczy da się uporządkować bez przerw w pracy firmy.

Diagnozy i porządkowanie baz prowadzimy dla firm z całego regionu — zobacz bazy danych MSSQL w Lublinie i optymalizację baz danych w Puławach.

Sklepy internetowe: ta sama diagnoza, inne objawy

W sklepach problem objawia się wolnym listingiem produktów i wolną wyszukiwarką wewnętrzną. Przyczyny są te same: brak indeksów po imporcie, filtry przeliczane przy każdym wejściu, rozrost tabel z danymi sesji.

Dochodzi jeden dodatkowy czynnik: liczba równoczesnych użytkowników. Sklep, który działa dobrze przy dziesięciu osobach naraz, potrafi stanąć przy stu — a to dokładnie ta chwila, w której trwa kampania.

Dlatego przy sklepach warto sprawdzać wydajność przed sezonem, a nie w jego trakcie. Więcej przy optymalizacji baz danych.

Kiedy problem leży w samym systemie

Czasem po uporządkowaniu bazy i serwera system nadal nie nadąża za firmą. Dzieje się tak, gdy program nie był projektowany na tę skalę: liczbę dokumentów, magazynów, użytkowników albo integracji.

Sygnałami są: powtarzające się problemy mimo konserwacji, brak możliwości pracy wielu osób jednocześnie, ograniczenia w integracjach i konieczność obchodzenia systemu arkuszami.

Wtedy warto rozważyć zmianę systemu — ale na podstawie diagnozy, a nie przeczucia. O wyborze systemu piszemy w artykule jaki ERP dla małej firmy.

Podsumowanie: kolejność, która oszczędza najwięcej

Najdroższą reakcją na wolno działający system jest zakup nowego serwera jako pierwszy krok. W połowie przypadków nie rozwiązuje problemu, bo przyczyna leży w bazie, nie w sprzęcie.

Sensowna kolejność jest odwrotna: najpierw indeksy, potem wielkość bazy i konserwacja, potem najcięższe zapytania, a dopiero na końcu zasoby serwera. Trzy pierwsze kroki to zwykle dzień pracy i często wystarczają.

Jeśli okaże się, że sprzęt faktycznie nie wystarcza, będziecie to wiedzieć z pewnością — i kupicie serwer dobrany do realnych potrzeb, a nie na wyczucie.