Duża baza danych, długo generowany raport i niewielkie wykorzystanie zasobów serwera mogą sugerować, że wystarczy udostępnić programowi więcej mocy. Gdy proces zajmuje jeden rdzeń, a pamięć i dysk pozostają słabo obciążone, naturalnym pytaniem jest możliwość przyspieszenia pracy przez zmianę ustawień.
W Analizach BI współpracujących z Comarch ERP Optima samo obserwowanie wolnych zasobów nie wystarcza jednak do wyboru rozwiązania. Najpierw rozdzielamy dwa obszary: operację wykonywaną w BI oraz zapytania obsługiwane przez SQL Server.
Najpierw ustalamy, co ogranicza generowanie raportu
Nie ma ogólnego sposobu na wymuszenie wielordzeniowej pracy Analiz BI. Możliwość wykorzystania zasobów zależy od tego, gdzie występuje ograniczenie. Nie należy więc traktować ustawienia w Windows Server 2022 jako uniwersalnego rozwiązania dla każdego długo wykonywanego raportu.
Pierwszym celem diagnostyki jest ustalenie, czy czas zajmuje sama operacja w BI, czy zapytania wykonywane na bazie. Bez tego łatwo skupić się na ustawieniach serwera, mimo że sprawdzenia wymaga przede wszystkim konstrukcja raportu. Sam fakt, że Optima została już dostrojona, nie rozstrzyga jeszcze tej kwestii.
Przy długo generowanym raporcie najbardziej prawdopodobnym obszarem do weryfikacji jest ilość przetwarzanych danych. Warto porównać zakres potrzebny odbiorcy z zakresem faktycznie pobieranym przez raport. Szczególnie istotne jest to, czy obejmuje on konkretny okres, czy przetwarza całą dostępną historię.
Drugim punktem jest zawartość raportu. Sprawdzamy, czy ładowane elementy są rzeczywiście potrzebne do uzyskania oczekiwanego wyniku. Nie chodzi o usuwanie informacji na próbę, lecz o oddzielenie danych wymaganych do analizy od tych, które nie służą jej celowi. To mocna wskazówka diagnostyczna, ale bez sprawdzenia konkretnego raportu nie przesądza jeszcze o przyczynie opóźnienia.
Jak sprawdzić raport, pamięć SQL i utrzymanie bazy?
Zaczynamy od określenia oczekiwanego wyniku: jaki okres ma obejmować analiza i jakie informacje muszą się w niej znaleźć. Dopiero z takim punktem odniesienia można ocenić, czy raport wykonuje potrzebną pracę, czy przetwarza dane wykraczające poza rzeczywiste zapotrzebowanie.
- Porównujemy okres analizy z zakresem danych raportu. Jeżeli potrzebny jest wybrany miesiąc, sprawdzamy, czy raport nie przetwarza również pozostałej historii.
- Weryfikujemy potrzebne elementy. Ustalamy, które z nich są wykorzystywane w wyniku i czy raport nie ładuje dodatkowych, zbędnych informacji.
- Sprawdzamy limit pamięci SQL Server. To osobny obszar względem samej operacji wykonywanej w BI.
- Weryfikujemy utrzymanie bazy. Sprawdzamy, czy cyklicznie wykonywane są prace optymalizujące, takie jak reindeksacja.
W SQL Server można określić maksymalną ilość pamięci RAM. Warto zweryfikować ten limit, ale nie utożsamiać go z poleceniem wykorzystania całej dostępnej pamięci. Samo podniesienie wartości nie jest potwierdzeniem, że raport zacznie działać szybciej. Nie podajemy też jednej właściwej wartości bez sprawdzenia konkretnego środowiska.
<screen>
Przykładowo osoba przygotowująca miesięczne zestawienie może korzystać z raportu, który przetwarza dane ze wszystkich lat. Najpierw porównujemy jego zakres z potrzebnym miesiącem, następnie oceniamy przydatność ładowanych elementów. Dopiero wynik takiego sprawdzenia daje podstawę do dalszych decyzji, zamiast zakładania z góry, że brakuje rdzeni lub pamięci.
Osobno sprawdzamy cykliczne prace optymalizujące bazę. Reindeksacja jest wskazanym obszarem weryfikacji, a nie gwarancją usunięcia opóźnienia. Potwierdzenie, że takie prace są wykonywane, pozwala uwzględnić stan utrzymania bazy w dalszej ocenie problemu.
Perspektywa ELTE-S
Przed ograniczeniem zakresu raportu warto uzgodnić z jego odbiorcą, jakie dane rzeczywiście są potrzebne. Szybszy wynik nie będzie użyteczny, jeśli po zmianie zabraknie informacji wymaganych do analizy. Najpierw ustalamy więc kryteria poprawności, a potem oceniamy czas wykonania.
Rekomendujemy również rozdzielenie prób dotyczących raportu od zmian po stronie SQL Server. Wprowadzanie kilku zmian jednocześnie utrudni ustalenie, która z nich wpłynęła na czas generowania. Przy porównaniu zachowujemy ten sam oczekiwany wynik, aby nie pomylić poprawy wydajności ze zmianą zakresu analizy.
Jeśli chcesz ustalić, od czego zacząć sprawdzanie konkretnego raportu BI i jego zaplecza SQL, możemy pomóc uporządkować diagnostykę. Porozmawiajmy o usprawnieniach.