SAP na Oracle bardziej wydajny

Eksploatując system SAP, w miarę upływu czasu firmy wdrażają kolejne moduły, rozbudowują już działające funkcjonalności. Użytkownicy chcą, aby ich aplikacje działały bardzo szybko. Menedżment również życzy sobie, aby interesujące ich dane były dostępne jak najprędzej. Ciągła pogoń za coraz szybszym, bardziej złożonym przetwarzaniem coraz większych wolumenów informacji z czasem powoduje pojawienie się problemów z wydajnością systemu.

Jednym ze sposobów rozwiązania tego problemu jest inwestycja w najnowocześniejszy sprzęt, wyposażony w dużą ilość pamięci RAM, najszybsze procesory, zakup jeszcze szybszych macierzy dyskowych. Jednakże najlepszy sprzęt jest też sprzętem najdroższym i nie daje 100% gwarancji, że problemy z wydajnością systemu ustąpią. W dodatku w wielu organizacjach procesy zakupowe mogą trwać nawet kilka miesięcy. Na ten okres administratorzy systemu SAP muszą znaleźć inny sposób na poprawę wydajności.

A zatem zanim wydamy pieniądze na nowy sprzęt, warto przyjrzeć się innym możliwościom poprawy wydajności: poprawie konfiguracji bazy danych oraz optymalizacji aplikacji/wdrożonej funkcjonalności. Użytkownicy baz danych muszą rozumieć, że główną przyczyną problemów wydajnościowych nie jest sama baza danych, lecz aplikacje ją wykorzystujące. Źle napisane bądź zapętlone w kodzie zapytania SQL zwykle są przyczyną pojawiających się problemów. Pierwszym krokiem administratora systemu powinien być kontakt z twórcą aplikacji i rozpoznanie, czy kod powodujący błąd nie może być przepisany na nowo, tak by zoptymalizować wykorzystanie zasobów bazy danych.

Przesłanki nieefektywnego działania bazy danych

Jednak jeśli wszelkie sposoby optymalizacji od strony aplikacyjnej nie przynoszą efektu, należy zająć się optymalizacją bazy danych. Rekonfigurując bazę danych, należy mieć na uwadze, że satysfakcjonujące rozwiązanie problemu w jednym obszarze może sprowokować pojawienie się problemów wydajnościowych w innym. Każda zmiana parametrów bazy danych powinna być dobrze przemyślana. Przykładowo w przypadku zmiany konfiguracji odpowiedzialnej za zarządzanie pamięcią bazy danych Oracle bez dokupienia i zainstalowania dodatkowej pamięci RAM możemy doprowadzić do stanu, że baza danych zajmie więcej istniejącej pamięci, która wcześniej była dostępna dla innych aplikacji, np. systemu SAP.

Jest wiele przesłanek, które wskazują, że baza danych działa nieefektywnie i wymaga optymalizacji. Są to m.in.:

• długi czas oczekiwania na odpowiedź bazy danych,
• bardzo duża liczba operacji dyskowych wejścia/wyjścia,
• duża fragmentacja tabel i indeksów,
• problem z alokacją pamięci.

Optymalizacja bazy danych powinna być podzielona na kilka etapów. W całym procesie należy uwzględnić uwarunkowania pracy użytkowników biznesowych, aby nie doprowadzić do niedostępności systemu SAP. Każde środowisko SAP jest inne i nie ma jednego idealnego planu na poprawę wydajności. Przed przystąpieniem do optymalizacji należy dokładnie zaudytować system, znaleźć potencjalne „wąskie gardła”. Na ich podstawie będzie można określić, jakie zmiany można wykonać na systemie, przeanalizować ich potencjalny wpływ na działanie systemu, ocenić, ile czasu jest potrzebne na dokonanie zmian, przygotowanie planu i wspólnie z biznesem określenie harmonogramu wprowadzenia zmian.

Optymalizować, ale co?

Optymalizacja jest procesem złożonym, nieodpowiednie zmiany mogą doprowadzić do pogorszenia wydajności lub nawet do awarii systemu. Metodologię optymalizacji można podzielić na cztery obszary:

• optymalizacja zapytań,
• optymalizacja struktur pamięciowych,
• optymalizacja operacji wejścia/wyjścia,
• wykrycie i wyeliminowanie prób dostępu do tych samych zasobów.

Taka duża liczba obszarów, w których można dokonać optymalizacji, przy nieumiejętnej analizie może doprowadzić do pogorszenia i tak już kiepskiej wydajności. W początkowej analizie należy skupić się na obszarach, w których widoczna jest pogorszona wydajność środowiska, wpływająca na działanie przedsiębiorstwa, mogąca skutkować uniemożliwieniem prowadzenia działalności biznesowej.

Sposób optymalizacji systemu zależy od jego specyfiki. Jeśli jest to system typu ERP (OLTP – On-line Transaction Processing) – to wymogi konfiguracyjne dla bazy danych są inne niż w przypadku systemów Business Warehouse (OLAP – On-line Analytical Processing).

Czas przetwarzania zapytań SQL może być różny. Proste zapytania wykonują się bardzo szybko, kilka milisekund, bardziej skomplikowane (np. zamknięcie okresu rozrachunkowego) mogą się wykonywać bardzo długo. W celu identyfikacji zapytań SQL, które są napisane w sposób nieoptymalny i powodują degradację wydajności systemu, można wykorzystać po stronie SAP raporty EarlyWatch lub z poziomu bazy danych raporty AWR (Automatic Workload Repository). Dane zebrane w raportach AWR powinny uwzględniać odpowiedni przedział czasowy, w którym występują problemy na poziomie bazy danych i zapytań SQL.

Po wyodrębnieniu przyczyn problemów wydajnościowych należy utworzyć harmonogram zmian w kontakcie z użytkownikami biznesowymi. Część zmian, jak np. zmiana parametrów statycznych bazy danych, wymaga restartu.

Krok po kroku

Z gotowym harmonogramem przystępujemy do wykonania zmian. Przed rozpoczęciem zmian należy zachować aktualny stan systemu – wykonać backup. W każdej chwili mamy możliwość powrotu do stanu wyjściowego, jeśli nasze modyfikacje niekorzystnie wpłynęły na system lub doprowadziły do jego nieodwracalnej awarii.

Etapu procesu optymalizacji:

• analiza kodu SQL – nieoptymalne zapytanie SQL ma najczęściej wpływ na wydajność bazy danych. W tym momencie konieczna jest współpraca administratora i twórcy zapytania/programu;
• optymalizacja pracy CBO (Cost Based Optimizer) – optymalizator kosztowy generuje plan wykonania zapytania SQL. Jeśli statystyki dla obiektów bazy danych nie są aktualne, to optymalizator może wybrać niewłaściwy plan wykonania zapytania, przez co zapytanie wykona się dłużej;
• zmiana struktur pamięciowych – odpowiednie ustawienie wielkości SGA (System Global Area), PGA (Program Global Area). Zmiana ich wielkości ma duży wpływ na pracę bazy danych (np. na liczbę operacji wejścia/wyjścia);
• zmiana parametrów bazodanowych – odpowiednie ustawienie parametrów inicjujących wpływa na pracę pozostałych komponentów bazy danych;
• analiza i redukcja występowania oczekiwań – zazwyczaj wynikające ze strony aplikacyjnej;
• zmiana konfiguracji systemu operacyjnego – zła konfiguracja systemu operacyjnego często wpływa na wydajność bazy danych.

Przydatne narzędzia

Do analizowania kryzysowej sytuacji administrator wykorzystuje informacje zawarte w dynamicznych perspektywach V$, jak również ma możliwość wykorzystania pakietu diagnostycznego statspack bądź raportów AWR. W wersji 11 bazy Oracle producent dostarczył zintegrowany z jądrem systemu pakiet funkcjonalności, który zawiera narzędzia analityczne i diagnostyczne.

Rozpoczynając rekonfigurację parametrów bazy danych dla środowiska SAP, należy zacząć od zapoznania się z rekomendacjami SAP odnośnie do parametrów dla bazy danych. SAP regularnie publikuje skrypty, za pomocą których sprawdzana jest poprawność parametrów dla bazy danych typu OLTP lub OLAP. Automatyczne zarządzanie pamięcią Oracle jest wyłączone, gdy korzystamy z SAP i bazy danych Oracle. Oracle dostarcza szereg dynamicznych widoków, za pomocą których możemy przeanalizować wielkość buforów, m.in. V$DB_CACHE_ADVICE odnośnie do buffer cache, który zawiera dane odczytane z dysku.

Dla instancji bazy danych na bieżąco zbierane są statystyki dotyczące samego systemu, a także sesji, zapytań SQL, usług. Przechowywane są one w pamięci SGA i w równych przedziałach czasu składowane na dysku. Dane te są ustrukturyzowane i noszą nazwę Automatic Workload Repository (AWR).

Repozytorium AWR jest obsługiwane przez dwa procesy bazy danych:

• Manageability Monitor Process MMON,
• Manageability Monitor Lite Process MMNL.

MMON jest głównym procesem obsługującym AWR, odpowiada za wykonywanie migawek zawierających wartości statystyk i zapisywanie ich na dysku. Zapis odbywa się do tabel, ulokowanych w przestrzeni tabel SYSAUX.

AWR stanowi podstawę działania szeregu mechanizmów automatycznego strojenia bazy danych, samodzielnej diagnostyki bazy oraz dostarcza danych do analizy prowadzonej przez administratora.

ASH – Active Session History – informacje cykliczne na temat sesji są zbierane i umieszczane w buforze danych pamięci SGA. Dostęp do bufora jest możliwy poprzez perspektywę V$ACTIVE_SESSION_HISTORY. Perspektywa zawiera jeden wiersz dla każdej aktywnej sesji. Od wielkości bufora zależy dostępność historii aktywności sesji. Jednak gdy dane są nadpisywane nowymi danymi, to proces MMNL zapisuje dane historyczne na dysk. Dane historyczne dostępne są przez perspektywę DBA_HIST_ACTIVE_SESS_HISTORY, jednak dane w niej zawarte nie są już tak dokładne.

Obie perspektywy zawierają wiele przydatnych informacji na potrzeby analizy wydajności systemu:

• dane o wykonywanym kodzie,
• dane o blokadach i oczekiwaniach na dostęp, m.in. identyfikator sesji blokującej,
• dane o obiektach,
• dane indentyfikacyjne, m.in. nazwa programu, użytkownika.

Jeśli użytkownik zgłasza problem wydajnościowy, wtedy z perspektywy V$ACTIVE_SESSION_HISTORY filtrujemy wiersze dotyczące użytkownika w terminie, gdy występował ten problem, a następnie analizujemy zapytanie SQL, plan wykonania, sprawdzamy, czy nie występowały blokady.

By móc korzystać z powyższych perspektyw, parametr bazy danych STATISTICS_LEVEL musi być ustawiony na wartość ALL lub TYPICAL. W przypadku systemu SAP parametr ma wartość TYPICAL.

Raport ASH wywołuje się poprzez funckje z pakietu DBMS_WORKLOAD_REPOSITORY. Raport ten może być w postaci HTML lub tekstowej. Aby utworzyć raporty, należy wywołać funkcje:

• DBMS_WORKLOAD_REPOSITORY.ASH_REPORT_TEXT,
• DBMS_WORKLOAD_REPOSITORY.AWR_DIFF_REPORT_HTML.

Jednakże Oracle dostarcza skrypty, które znajdują się w lokalizacji $ORACLE_HOME/rdbms/admin, ułatwiające użytkownikowi utworzenie raportów. Skrypty to:

• ashrpt.sql – skrypt uruchamiający raport,
• ashrpti.sql – skrypt uruchamiający raport dla wskazanej instancji.

W wygenerowanym raporcie znajdują się poniższe infromacje:

• Top Events – najdłużej trwające oczekiwania (umożliwia identyfikację niewydajnego systemu dyskowego),
• Load Profile – raportuje sesje najbardziej obciążające system,
• Top SQL – zawiera najbardziej obciążające polecenie SQL,
• Top PL/SQL – zawiera najbardziej obciążające system procedury PL/SQL,
• Top Java – zawiera zestawienie najbardziej obciążających system programów w języku Java,
• Top Sessions – zawiera m.in. informacje o blokujących się sesjach,
• Top Objects/Files/Latches – sprawdza pliki przestrzeni tabel, które były używane,
• Activity Over Time – służy do przeglądu zdarzeń w dłuższym okresie.

Wydajność – chleb powszedni administratora SAP

Dla administratora SAP problemy wydajnościowe bazy danych nie powinny być nadzwyczajnym problemem. Wyposażony w raporty AWR, ASH jak i SAP EarlyWatch administrator dysponuje pełnym wglądem w swoje środowisko bazodanowe. Odpowiednia interpretacja danych skutkuje rozwiązaniem najbardziej doskwierających problemów wydajnościowych.