Higiena środowiska

Elementarne błędy w sposobie zrządzania bazą, performance tunningu (strojeniu) oraz bieżącym utrzymaniu są najczęstszą przyczyną stopniowego zmniejszania się wydajności zarówno SAP, jak i MS SQL Servera. Tutaj pojawia się pierwszy element, który należy traktować globalnie: higiena środowiska. Zależności pomiędzy Windows Server a Microsoft SQL Server stanowią zasadniczą i niepodzielną całość. Obydwa te elementy są nierozerwalne i wzajemnie na siebie wpływające. Niedopuszczalne jest traktowanie systemu operacyjnego jako nietykalnego, bowiem prowadzi to do (błędnego) przekonania, że stabilnego systemu ruszać nie należy. To samo dotyczy bazy Microsoft SQL Server, która nieaktualizowana w trakcie swej pracy, nie będzie wydajna, będzie obarczona błędami, a z czasem zacznie sprawiać problemy. Reasumując, pierwszym warunkiem wydajnego działania jest aktualizacja.

Warto w tym miejscu zwrócić uwagę na klika czynników, które bezpośrednio wpływają na decyzje administratorów o dokonaniu stosownych aktualizacji bazy Microsoft SQL Server. W szczególności są to:

  • zgodność wersji Microsoft SQL Server z PAM (Product Availability Matrix),
  • częstotliwość aktualizacji,
  • wiarygodność źródeł poprawek,
  • stosowne noty SAP do każdej z nich oraz upgrade guide wydawane do konkretnych release bazy i systemu SAP,
  • plan wdrożenia poprawek,
  • plan awaryjny na wypadek niepowodzenia,
  • regularne, potwierdzone testy odtworzeniowe,
  • wsparcie konsultantów Basis na wypadek problemów.

Aktualizacje mają kluczowe znaczenie dla prawidłowej pracy bazy Microsoft SQL Server, bo składają się na nie zarówno małe poprawki, czyli SP (Support Package), jak i duże update’y, czyli CU (Cummulative Update). Szczegółowe noty opisują zarówno ich dopasowanie do systemu operacyjnego, jak i zależności pomiędzy systemem SAP a bazą. Jakkolwiek aktualizacje te dotyczą wyłącznie warstwy bazy danych i systemu operacyjnego, to również system SAP wymaga aktualizacji pod kątem bazy. W szczególności jest to część jądra systemu (kernela), odpowiadająca właśnie za komunikację z bazą, czyli DBSL (Database Shared Library).

Podnoszenie wydajności

Poprawność wdrożenia systemu SAP w oparciu o bazę Microsoft SQL Server stanowi o jakości środowiska. Zazwyczaj skalowanie (sizing) oraz parametry systemu są optymalizowane pod strat produkcyjny systemu, zaś docelowa wydajność spada wraz z upływem czasu. Ta ogólna zasada ma zastosowanie do wszystkich rodzajów baz oraz platform systemowych. Nie oznacza to jednak, że w środowisku MS Windows oraz Microsoft SQL Server tak musi być zawsze, a reakcja administratora wynika wyłącznie ze zgłaszanych przez użytkowników problemach wydajnościowych systemu.

Administrator, który dba o higienę środowiska, korzysta z raportów EWA (Early Watch Alert) i na ich podstawie podejmuje odpowiednie działania. Co można wyczytać z raportów EWA o bazie danych? To kopalnia wiedzy, bez zagłębiania się w niuanse Microsoft SQL Server. Zasadniczo warto skupić się na kilku parametrach Microsoft SQL Server, aby podnieść jego wydajność o kilkanaście procent. Zarządzanie plikami danych SAPDATA powinno się odbywać w taki sposób, aby rozszerzanie środowiska było wygodne z punktu widzenia administratora oraz optymalne ze względu na wydajność. Mam tutaj na myśli rozmieszczenie trzech kluczowych elementów na systemie plikowym, tj. plików SAPDATA, plików logów transakcyjnych SAPLOG oraz bazy TEMPDB.

Baza TEMBD jest bardzo często pomijana w procesie tunnigowania Microsoft SQL Server i wydajności systemu SAP. Nie zapominajmy o tym, że zgodnie z architekturą bazy Microsoft większość transakcji na danych „przechodzi” właśnie przez nią. Jej alokacja na niewłaściwej przestrzeni dyskowej może z początku być całkowicie nieodczuwalna, jednak po pewnym czasie, kiedy system obrośnie danymi do przetwarzania, jej wydajność będzie wprost proporcjonalna do całkowitej wydajności systemu! Jej niewłaściwe zbudowanie będzie rzutowało na jakość wdrożenia w ten sposób, że kiedy spadnie całkowita wydajność, administratorzy będą pomijać jej znaczenie w myśl stwierdzenia – „do tej pory było dobrze, więc to na pewno nie to”. Błąd!

Jak wiemy, każda baza charakteryzuje się takimi cechami jak wielkość czy struktura. Nie możemy ingerować w strukturę bazy TEMPDB, jednak możemy kreować jej wydajność za pomocą jej wielkości. Właściwy dobór wielkości bazy jest bardzo ściśle określony i doskonale udokumentowany zarówno w notach SAP (OSS), jak i Microsoft (MSDN). Praktyka konsultancka jednak zaleca zachowanie umiaru i pewnego wyczucia w stosowaniu zaleceń.

Czysto matematyczne określanie pewnych cech baz w rzeczywistości wcale nie musi prowadzić do pełnej optymalizacji, a jedynie do jej rozrostu bez poprawy wydajności, co w konsekwencji będzie odczuwalne jako strata czasu na szukanie problemu, bez wyraźnej poprawy. Rodzi się więc pytanie, czy jest szansa na poprawę nieoptymalnie zdefiniowanej bazy TEMPDB? Tak, jest to możliwe i mogą tego dokonać doświadczeni w bazach Microsoft SQL Server konsultanci Basis lub certyfikowani inżynierowie Microsoft SQL Server. Oczywiście, z racji specyficznej procedury zmiany rzeczonej bazy, zawsze wiąże się to z przeprowadzeniem mniej lub bardziej złożonego projektu, jednak jest to operacja na tyle bezpieczna, że nie ma powodów do jakichkolwiek obaw.

Bardziej znaną metodą poprawy wydajności bazy jest optymalizacja logów transakcyjnych. Ogólne zasady postępowania z logami transakcyjnymi bazy są dobrze udokumentowane zarówno w OSS, jak i MSDN, warto jednak wspomnieć o tym, że wielkość, przyrost i położenie na filesystemie to najważniejsze ich cechy. Optymalizację logów transakcyjnych należy rozpocząć od określenia liczby transakcji w systemie na podstawie raportów EWA. Dobrą praktyką jest przyjęcie kilkunastoprocentowego marginesu nadmiarowości ich wielkości, jednak stałe utrzymywanie jej wielkości powyżej progu wartości rozszerzenia nie ma sensu, a jedynie przysparza kłopotów administracyjnych. W przeciwieństwie do plików danych, plik lub pliki logów można bezpiecznie shrinkować, choć operacja ta wymaga kliku zabiegów okołotunningowych.

Zasada minimalnej nadmiarowości dotyczy też ustawienia progu rozrostu. Określenie wielkości maksymalnej logu transakcyjnego leży w gestii lokalnego administratora i w głównej mierze zależy od możliwości wykorzystania przestrzeni dyskowych. Okresowy monitoring silnika bazy powinien wykazać, że należy dążyć do minimalizacji lub wyeliminowania logów wirtualnych (VLF) na systemie, które w krytycznych sytuacjach mogą doprowadzać do znacznego przyrostu operacji zapis/odczyt na podsystemie dyskowym i drastycznego okresowego spadku wydajności.

W tym miejscu zapewne pojawi się pytanie o interpretację wartości parametrów bazy przez administratora infrastruktury (czasem również administratora Microsoft SQL Server) – jest to możliwe wyłącznie na drodze analizy suchych danych, z zachowaniem wspomnianego marginesu namiarowości.

Parametryzacja

Wśród elementów parametryzacyjnych, które wyłaniają się po etapie wdrożenia, jest rozkład i wielkość plików danych SAPDATA na podsystemie dyskowym. Umiejętność właściwej oceny sytuacji jest kluczowa przy wdrożeniu, jednak ocena ta powinna być weryfikowana, kiedy środowisko serwerowe zaczyna ewoluować. Ograniczeniem jest zawsze sprzęt, którym dysponuje administrator, nie przeszkadza to jednak w elastycznym operowaniu na plikach danych w trakcie ich normalnego czasu pracy.

W idealnym środowisku pliki danych będą tej samej lub prawie tej samej wielkości, rozłożone równomiernie pomiędzy podsystemami dyskowymi i porozdzielane, jak to ma miejsce podczas instalacji systemu. Rolą administratora będzie takie nimi manipulowanie, by zapewnić optymalne wyniki wydajności. W zależności od wielkości środowiska liczba plików danych jest różna, a ich wielkość zmienia się dynamicznie, niekoniecznie równomiernie i nie zawsze w zbliżonym czasie. Nie jest to powód do podejmowania radykalnych działań, jednak obserwacja wskazana jest zawsze.

W razie wątpliwości można poradzić się konsultanta Basis oraz administratora infrastruktury, z naciskiem na Basis. Wynika to bezpośrednio z faktu specyficznej konstrukcji bazy SAP i wymaga, jak wspomniano wcześniej, pewnego wyczucia i doświadczenia. Obserwacje prowadźmy zawsze dwutorowo: na podstawie codziennych przeglądów bazy, jak i zbiorczych raportów EWA. Ważną rolę odgrywa tutaj sam podsystem dyskowy i konfiguracja RAID, inna dla plików danych i logu transakcyjnego.

Pamiętać należy o zachowaniu dwóch czynników: wydajnościowego oraz bezpieczeństwa. Mówimy tutaj o właściwym doborze macierzy dyskowych oraz stosowaniu technologii RAID, szczególnie RAID 10, 5, 50, 60. W razie wątpliwości co do właściwego doboru zalecamy kontakt z konsultantem Basis, który zapewne optymalnie dobierze podsystem dyskowy w zależności od możliwości i potrzeb. Ponownie zwrócę uwagę na kwestię skali – przewymiarowanie na pewno nie poprawi sytuacji, a jedynie wygeneruje wysokie koszty utrzymania lub zakupu.

Jak każda baza danych, również Microsoft SQL Server ma rozbudowane możliwości konfiguracyjne. Mówimy tutaj o silniku bazy, czyli jak zachowują się jej binarna i procesy robocze bazy. Szereg parametrów ma odczuwalne przełożenie na jakość pracy całego systemu. Część z nich jest dość oczywista, jak na przykład zarządzanie pamięcią instancji bazy danych, część jest niezrozumiała i traktowana na zasadzie „nie ruszam czegoś, o czym mało wiem”. Jako że część parametrów ustawia się automatycznie, można je tak traktować, jednak do czasu, kiedy nasze środowisko nie rozrośnie się lub automatyczne ustawienia przestaną być optymalne dla systemu produkcyjnego. Wkraczamy wówczas w świat zaawansowanej konfiguracji bazy Microsoft SQL Server i dopiero wtedy rozwija ona skrzydła. Nie należy się bać zaawansowanej konfiguracji, która z pozoru wydaje się skomplikowana (a w której bazie nie jest?), a jedynie być dobrze do niej przygotowanym, z zapleczem konsultingowym włącznie.

Manipulacja przydziałem pamięci, procesorów, kontami użytkowników czy rolami wymaga wprawdzie pewnej wprawy i wiedzy, jednakże może przynieść duże zmiany w jakości pracy całego systemu. Dobrze udokumentowane zarządzanie przydziałem pamięci znajdziemy wprost na SAP Marketplace (OSS) w postaci not właściwych do danej wersji bazy, to samo dotyczy pozostałych parametrów czy nawet kompresji (tę część można i zaleca się wykonać z poziomu systemu SAP).

Warto również wspomnieć o takich istotnych dla wydajności zagadnieniach, jak sterowanie statystykami dla bazy oraz jej fragmentacja. Generalnie KB SAP (Knowledge Base) mówi, jak postępować z automatycznymi statystykami na tabelach w bazie oraz które tabele nie powinny być nimi objęte. Dobrym źródłem takich analiz jest również raport EWA, który podaje z dokładnością do nazwy tabeli procedurę postępowania. Zastosowanie się do zaleceń raportu jest wysoce wskazane.

Baza Microsoft SQL Server ma to do siebie, że jej pliki danych SAPDATA fragmentują się. Warto o to spytać konsultanta, który zaleci odpowiednie czynności, o ile będą one potrzebne. Złą praktyką jest natomiast eksperymentowanie ze znalezionymi gdzieś na forach ustawieniami i procedurami, ponieważ zazwyczaj odnoszą się one do środowisk, w których nie pracuje SAP.

Narzędzia

Microsoft SQL Server ma wiele wbudowanych narzędzi administracyjnych, z których należy korzystać. Tak, najczęstszym grzechem zaniedbania jest właśnie niewykorzystywanie w codziennej administracji wbudowanych narzędzi! Pierwszym z brzegu jest chociażby zarządzanie Maintenance Planami. Brak dobrze przygotowanych planów serwisowych to potencjalne problemy w krótkim czasie. Zaczyna się banalnie – konfiguracja backupu, potem oczyszczanie przestrzeni po nim, a na sprawdzaniu spójności bazy skończywszy. W dalszej kolejności mamy Server Agenta, którego mrówcza praca pozwala nam precyzyjnie określać kondycję systemu i rokować zarówno o wydajności, jak i cyklu serwisowym bazy.

Na koniec warto jeszcze wspomnieć o różnicowaniu środowisk i ich wydajności. Trudno zadawać sobie trud, aby tunningować środowisko rozwojowe, ponieważ deweloperzy pracujący nad jakimś raportem lub innym rozwiązaniem mają świadomość nieoptymalnego środowiska. Oczywiście nie należy dopuszczać do skrajnej niewydolności, ale zaleca się zachować umiar we wkładanym w to wysiłku.

Częściej zachodzi potrzeba przetestowania jakiegoś rozwiązania w środowisku testowym i tutaj stajemy przed problemem wydajności – w zależności od rodzaju rozwiązania może być ona potrzebna (chcemy przetestować wydajność raportu w systemie) lub marginalna (chcemy przetestować samo działanie rozwiązania i czas nie jest krytyczny). Tutaj decyzja zawsze leży po stronie administratora, jednak rekomenduje się stosowanie konfiguracji zbliżonej do systemu produkcyjnego, o ile zasoby na to pozwolą.

System produktywny to już powinna być klasa sama w sobie – tutaj wszystko powinno być jak najlepiej zoptymalizowane, by zachować maksymalną wydajność.

Wirtualizacja, klastry i skala

W czasach wszechpanującej wirtualizacji śmiało można stwierdzić, że środowisko Microsoft idzie z duchem czasu. Przystosowanie go do pracy w środowiskach wirtualnych jest jednym z mocniejszych stron strategii rozwoju programowania Microsoft, w tym bazy Microsoft SQL Server. Oczywiście środowisko wirtualne rządzi się swoimi prawami i wymogami, które jednakże nie odbiegają znacząco od fizycznych, choć samo środowisko jest nieco przez wirtualizację ograniczane. Z drugiej jednak strony wirtualizacja jeszcze bardziej uelastycznia możliwości konfiguracyjne oraz rozbudowy skali systemu.

Śmiem twierdzić, że Microsoft SQL Server jest w stanie rosnąć wraz z systemem SAP, dotrzymując mu kroku w zachowaniu wydajności. W każdej kolejnej wersji bazy Microsoft SQL Server rokowania na wydajną pracę w dużych środowiskach są coraz lepsze, a to za sprawą zmieniającej się architektury wewnętrznej bazy, mechanizmów zarządzania pamięcią, plikami danych i wreszcie strukturami danych.

Zarówno środowisko zwirtualizowane, jak i fizyczne SAP oparte na Microsoft SQL Server może pracować w klastrach, które są natywnie wspierane zarówno przez Microsoft, jak i przez SAP.

Łatwość konfiguracji oraz graficzny interfejs konfiguracyjny sprawiają, że nawet mniej doświadczony administrator jest w stanie administrować klastrem bazodanowym. Stopień skomplikowania instalacji systemu SAP w pełnym modelu High Availability jest średni, zaś utrzymanie tegoż już tylko dość proste, pod warunkiem znajomości technologii oczywiście. Jeśli model HA i klaster nie są tym, czego oczekuje się od systemu, a zależy nam na wdrożeniu i łatwym utrzymaniu bezpiecznego systemu, pozostaje jeszcze możliwość uruchomienia „bazy zapasowej” w trybie Stand-by, czyli klasycznego Log Shippingu, jednak jest to już materiał na oddzielny artykuł.

Bazując na powyższych wskazówkach i stosując ogólnie przyjęte dobre praktyki specyficzne dla MS SQL Server, można w znaczący sposób poprawić lub utrzymywać na bieżąco dobrą wydajność środowiska, niezależnie od jego wielkości. Nie bójmy się zmian – każdy system ich wymaga. Należy jedynie korzystać ze sprawdzonych źródeł zarówno w pozyskiwaniu wiedzy z internetu, jak i wsparcia od firm konsultingowych, które służą pomocą w utrzymaniu dobrej kondycji systemów.