Wśród najczęściej zgłaszanych problemów związanych z wydajnością systemów SAP należy wymienić:

  • Wydajność bazy danych. Centralnym punktem do identyfikowania problemów wydajnościowych jest transakcja DBACOCKPIT, w której możemy podejrzeć zużycie zasobów bazy danych – np. zużycie cache. Analizując te dane, możemy poprawić wydajność systemu i zredukować zużywane zasoby. W niektórych przypadkach nie ma konieczności poprawy wydajności, jak np. dla zadań w tle, które wykonują się w nocy, a wynik potrzebny jest użytkowników dopiero rankiem.
  • Wykonywanie programów. Interpretując wyniki z wielu transakcji zbierających dane statystyczne bądź szczegółowych logów systemu SAP, możemy przeanalizować czas trwania programów, określić, w którym miejscu program wykonuje się najdłużej i dlaczego, a dzięki temu próbować zoptymalizować jego działanie bądź przepisać kod, by był wydajniejszy.
  • SAP system check. Wydajność systemu operacyjnego, zużycie zasobów – pamięć RAM, zużycie procesorów CPU, statystyki wejścia/wyjścia jak też statystyki wywołań dla tabel lub bufory systemu SAP. Nieefektywnie napisane zapytanie SQL może powodować wysokie zużycie CPU bądź skutkować bardzo dużą liczbą operacji wejścia/wyjścia.

Od czego zależy wydajność SAP?

Jeśli natrafimy na problemy wydajnościowe w naszym środowisku SAP, w pierwszej kolejności należy przeanalizować historyczne informacje o wydajności za pewien czas. Dane, na które powinniśmy zwrócić uwagę, to czas odpowiedzi, obciążenie procesora, obciążenie bazy danych, implementacja/aktualizacja programów klienckich, kosztowne zapytania SQL, jak również komunikacja z zewnętrznymi systemami.

Jeśli w systemie występuje bardzo wysoka utylizacja procesora i nie jest to spowodowane przez żadną aplikację systemu SAP ani bazę danych, to należy sprawdzić, jaki proces na poziome systemu operacyjnego powoduje spowolnienie SAP. Po analizie należy zdecydować, czy będziemy optymalizować/aktualizować system operacyjny, czy może dobrym rozwiązaniem jest dodanie dodatkowych zasób do maszyny. Z kolei jeśli load spowodowany jest przez bazę danych, należy przeanalizować jej parametry i dokonać dostosowania.

Gdy problem wydajnościowy jest spowodowany na poziomie aplikacyjnym SAP, należy przeanalizować zwiększenie parametrów pamięciowych systemu SAP, uwzględniając zasoby systemu operacyjnego oraz sprawdzić zadania w tle w transakcji SM37, jak również działające programy klienckie i kosztowne zapytania SQL – czy nie mogłyby zostać zoptymalizowane przez autorów.

Na poziomie systemu SAP wydajność buforów systemu można zweryfikować w transakcji ST02.

Weryfikacja wydajności buforów systemu SAP w transakcji ST02

Z tego miejsca możemy szczegółowo podejrzeć parametry pamięciowe i dostosować je do możliwości systemu operacyjnego. Gdy na poziomie aplikacyjnym nie występują problemy z wydajnością, wtedy możemy przejść poziom niżej, do bazy danych. Tutaj może pojawić się szereg wąskich gardeł, które należy usunąć. Analizę można rozpocząć od sprawdzenia buforów bazy danych, czy aktualne wartości są wystarczające. Jeśli nie są, to należy sprawdzić, jak je poprawić, aby zmiana przyniosła poprawę, a nie skutek odwrotny. Przed wykonaniem zmiany należy dokładnie przeanalizować środowisko – od systemu operacyjnego, poprzez bazę danych, aż po system SAP. Zanim przystąpimy do zmiany parametrów na własną rękę, należy zwrócić uwagę na rekomendacje firmy SAP umieszczane w notach SAP na portalu service.sap.com.

Z poziomu systemu SAP weryfikujemy programy/transakcje, dla których mamy najdłuższy czas odpowiedzi bazy danych. Czas ten jest znacznie dłuższy niż czas dla procesora CPU. Na tym etapie trudno jest wywnioskować, czy problemem jest nieoptymalnie napisany program, czy zapytanie SQL. Włączając trace na zapytaniach SQL, możemy w łatwy sposób zweryfikować/wyeliminować przyczynę, jaką może być zapytanie.

Weryfikacja czasu odpowiedzi bazy danych z poziomu systemu SAP

SAP system check – sprawdzenie wydajności systemu operacyjnego

Problemy z zapytaniami SQL skutkują zwiększoną utylizacją procesora na serwerze bazy danych, z kolei problemy z kodem ABAP powodują zwiększoną utylizacją procesora na serwerze aplikacyjnym. Umieszczenie serwera bazy danych i podstawowego serwera aplikacyjnego na tym samym hoście może powodować znaczną degradacją wydajności. SAP dostarcza transakcje, za pomocą których administrator może podejrzeć statystyki dla systemu operacyjnego – aktualne jak i historyczne dla utylizacji procesora.

Z poziomu systemu SAP statystyki są dostępne jako średnie godzinowe i nie wykazują dokładnie tego, co się wydarzyło w ciągu 5-10 minut. Dlatego system operacyjny powinniśmy monitorować narzędziami na poziomie OS, które dzięki swojej konfigurowalności umożliwiają zbieranie statystyk w zadanych interwałach czasowych, np. 5-10 minut. Mając do dyspozycji szczegółowe statystyki, możemy dokładnie określić momenty szczególnego obciążenia procesorów i  szybciej wyeliminować przyczynę.

Weryfikacja systemu operacyjnego w transakcji ST06

Transakcja ST06 może być używana przez administratorów Basis do uzyskania informacji o zużyciu procesorów i operacjach wyjścia/wejścia. Jednak w przypadku konieczności monitorowania OS w dłuższej perspektywie administratorzy powinni korzystać z narzędzi systemu operacyjnego.

Jeśli zużycie procesora na serwerze bazy danych jest wysokie, w pierwszej kolejności należy zwrócić uwagę na nieoptymalne zapytanie SQL. Jeśli na serwerze bazy danych znajduje się serwer aplikacyjny SAP, to należy zweryfikować, czy części zadań w tle nie można przenieść na godziny poza największą aktywnością użytkowników. Ostatecznym rozwiązaniem zostaje dodanie większej ilości CPU do serwera bazy danych, jeśli oczywiście dysponujemy taką możliwością.

Jeśli zużycie procesora na serwerze aplikacyjnym SAP jest wysokie, to nasze pierwsze kroki powinny być skierowane ku zidentyfikowaniu programów ABAP, które należy zoptymalizować. Należy odpowiednio zmodyfikować grupy logowania, aby równomiernie rozłożyć obciążenie działaniami użytkowników pomiędzy serwerami aplikacyjnymi SAP. Tak jak w przypadku nieoptymalnych zapytań SQL na serwerze bazodanowym, i w tym wypadku konieczne może być dodanie dodatkowej ilości CPU.

Liczba operacji wejścia/wyjścia może być monitorowana z poziomu systemu SAP, jak również za pomocą innych narzędzi, jak np. raporty AWR z poziomu bazy danych Oracle. Przewagą raportów AWR jest możliwość ich skonfigurowania celem automatycznego zbierania statystyk wydajnościowych i możliwość okresowego porównywania z danymi historycznymi. Z poziomu systemu SAP możemy podejrzeć czasy odczytu i zapisów, liczby odczytów i zapisów, podobnie jak z poziomu bazy danych Oracle (DBACOCKPIT -> Wait Event Analysis -> Filesystem Requests).

Weryfikacja czasu odczytu w transakcji DBACOCKPIT. Dobry czas odczytu, czasy odczytu z plików nie przekraczają 5 ms

Problemy z ewentualnym dostępem do plików systemu można zaobserwować w widoku v$system_event z poziomu systemu SAP. W pokazanym przykładzie odczyt danych z pliku trwa 99,98 ms, co jest bardzo długim czasem, wskazującym na problemy z operacjami wejścia/wyjścia. Dobra wydajność operacji wejścia/wyjścia powinna wynosić poniżej 10 ms.

Wyświetlając dane z DBACOCKPIT -> Wait Event Analysis -> Filesystem Requests, możemy zidentyfikować, czy problem z operacjami wejścia/wyjścia dotyczy wszystkich plików bazy danych, czy tylko niektórych.

Narzędzia i doświadczenie

Zarówno firma SAP, jak i producent systemu operacyjnego dostarcza administratorowi SAP szeregu narzędzi, które pozwalają na wgląd w poprawność działania systemu. Umiejętne wykorzystanie powyższych narzędzi prowadzi do skutecznego usunięcia problemów wydajnościowych środowiska SAP. Szczegółowa i rzetelna analiza pozwala rozwiązać wiele trapiących środowisko SAP problemów, jednak próba pójścia na skróty może przynieść skutek odwrotny.

Problemy wydajnościowe mają złożoną naturę i na pierwszy rzut oka mogą przyprawiać o zawrót głowy. Konsultanci BCC (aktualnie All for One Poland) posiadają wiedzę oraz doświadczenie zdobyte w trakcie wielu projektów technicznych dla klientów, jak również podczas prac związanych z usługą administracji SAP (zarówno dla systemów utrzymywanych w lokalizacji klienta, jaki i w hostingu w All for One Data Centers). Ich wiedza i umiejętności są wykorzystywane w analizie i poprawianiu wydajności systemów SAP.