Kiedy wdrażamy system SAP, trudno precyzyjnie przewidzieć, jak jego baza danych będzie się rozrastać w przyszłości. Oczywiście na podstawie dostępnych informacji na etapie projektowania technicznego systemu szacowane są przyrosty bazy danych w kolejnych latach, a co za tym idzie, odpowiednia przestrzeń dyskowa. Jednak określenie wpływu przyrostu danych na działanie systemu w różnych aspektach jego funkcjonowania jest już zdecydowanie trudniejsze. Jest to wszak związane z rozwojem firmy, liczbą operacji, jakie będą wykonywane, przyrostem zamówień, liczbą produktów i wystawianych faktur.

Obecnie dostępne technologie wykorzystywane w dyskach twardych udostępniają duże przestrzenie za stosunkowo niską cenę. Jednak budowa systemu dyskowego, który z jednej strony zapewni odpowiednio dużą przestrzeń, a z drugiej będzie wydajny i zdolny do obsłużenia dużej liczby operacji zapisu i odczytu, jest już zdecydowanie trudniejsza i bardziej kosztowna.

Przestrzeń dyskowa to tylko jeden z negatywnych aspektów, z jakim mamy do czynienia w kontekście przyrostu wielkości każdego systemu IT, w tym SAP. Inne problemy to:

  • spadek wydajności systemu wynikający z wydłużenia czasu potrzebnego na odczyt i zapis danych (szczególnie dla dużych tabel),
  • konieczność zapewnienia wydajnego mechanizmu tworzenia kopii zapasowych i możliwości ich odtworzenia w przypadku awarii w akceptowalnym dla biznesu czasie,
  • większe zapotrzebowanie na zasoby sprzętowe, takie jak procesory czy pamięć RAM,
  • długi czas potrzebny na odświeżenie środowiska testowego danymi z systemu produkcyjnego (tzw. kopia mandanta),
  • długi czas przestoju systemu podczas podniesienia do nowej wersji (upgrade).

Dodatkowo w dużych bazach danych można zaobserwować również inne niedogodności, takie jak długie czasy odświeżania statystyk bazy danych czy problemy z efektywną reorganizacją danych.

Wszystko to w rezultacie powoduje znaczne zwiększenie kosztów potrzebnych do utrzymania systemu. Dodatkowe koszty dotyczą zarówno sprzętu, jak i zasobów ludzkich.

Uporządkuj swoje biurko

W działalności biznesowej dane o zakupach, płatnościach, fakturach sprzed 10 lat to już prehistoria. Z rzadka są wykorzystywane do długookresowych zestawień czy analiz. Często zatrzymuje się je jedynie ze względu na wymogi prawne, które obligują do przechowywania i udostępniania ich odpowiednim instytucjom (np. Urzędowi Skarbowemu, ZUS). Także statystyki wskazują, że dane, które zostały wprowadzone do systemu kilka lat wcześniej, są odczytywane niezmiernie rzadko.

W środowisku SAP najbardziej efektywnym rozwiązaniem problemów z wielkością baz danych jest archiwizacja. Mechanizm archiwizacji danych w systemie SAP pozwalana na zmniejszenie wielkości bazy danych poprzez przeniesienie ich do zewnętrznego archiwum.

Odpowiedni mechanizm archiwizacji pozwala wykonywać tę czynność cyklicznie, by nie dopuścić do ponownego nadmiernego rozrostu bazy. A jednocześnie przez cały czas dostęp do zarchiwizowanych danych jest zapewniony.

Jako że z danych archiwalnych korzysta się sporadycznie, dobrym rozwiązaniem jest przechowywanie ich na nośnikach, których koszt jest znacznie niższy niż baz danych. Ponadto dane archiwalne są kompresowane (nawet do 10 razy), co dodatkowo wpływa na efektywność całego rozwiązania.

Systemy SAP współpracują z całą gamą rozwiązań służących do przechowywania danych archiwalnych, począwszy od standardowej przestrzeni dyskowej, poprzez urządzenia HSM (Hierarchical Storage Management), a skończywszy na zaawansowanych rozwiązaniach dedykowanych do przechowywania danych archiwalnych (OpenText, FileNet, itp.).

BCC proponuje podejście do archiwizacji danych historycznych w SAP od strony przyczyn, a nie skutków. Warto przeprowadzić projekt archiwizacji, czyli przeniesienia części danych, które nie są już w systemie zmieniane, na zewnętrzne nośniki, i tym samym zwolnić przestrzeń w systemach.

Archiwizację danych możemy porównać do porządkowania własnego biurka. Nie możemy przechowywać na nim wszystkich dokumentów, które posiadamy. Do części z nich zaglądamy sporadycznie, dlatego odkładamy je na wyższą półkę, a te, nad którymi właśnie pracujemy, pozostawiamy blisko siebie.

Ograniczyć wielkość bazy

Przykładem firmy, która zdecydowała się przeprowadzić archiwizację danych z SAP jest DHL Express (Poland). Prowadzony przez BCC (aktualnie All for One Poland) projekt zakończył się na przełomie 2009/2010. Zakres archiwizacji obejmował dane z obszarów FI, CO oraz SD.

Od 1999 r. liczba danych w systemie przyrastała wręcz skokowo, co wiązało się z rozwojem firmy i zdobywaniem rynku przesyłek kurierskich w Polsce. W połowie 2009 r. wielkość bazy danych systemu SAP w DHL Express (Poland) osiągnęła około 2,4 TB. Dodatkowo prognozy na najbliższe lata wskazują na dalszy jej przyrost.

Aby wielkość bazy nie wpływała na wydajność systemu, należało zarchiwizować jak najwięcej danych. Drugim, równie istotnym celem projektu archiwizacji było ograniczenie przyrostów bazy w kolejnych latach. Dzięki udziałowi w projekcie centrum kompetencyjnego SAP z DHL Express w Polsce konsultanci DHL uzyskali wiedzę pozwalającą na dokonywanie archiwizacji bazy danych SAP w kolejnych latach.

W pierwszym etapie przeprowadzono analizę stanu obecnego oraz opracowano koncepcję archiwizacji. Następnie, w drugim etapie konfigurowano rozwiązanie i przeprowadzono testy. Odbyły się także warsztaty zapoznające użytkowników kluczowych z działaniem zaimplementowanego rozwiązania. Wreszcie w trzecim etapie uruchomiono rozwiązanie produkcyjne.

Analiza i koncepcja archiwizacji

W DHL Express w trakcie analizy technicznej bazy danych wytypowano największe tabele oraz tabele, które rosną najszybciej. Największa była tabela z pozycji pojedynczych COEP, kolejne dwie zawierały dane z obszaru sprzedaży i dystrybucji. W wyniku analizy następnie określono odpowiednie obiekty archiwizacji, które należy zastosować. Archiwizacja objęła dane z lat 1999-2005. Analiza systemu, a następnie opracowanie koncepcji to najbardziej krytyczny etap projektu. Błędy na tym etapie mogą prowadzić do problemów z dostępem do danych lub spowodować, że rozwiązanie nie będzie tak efektywne, jak się spodziewamy (np. ze względu na niewielką liczbę danych, jaką uda się zarchiwizować).

Wybór obiektów archiwizacji nie jest zadaniem prostym. Wymaga szerokiej wiedzy z określonych modułów systemu SAP, ponadto konieczna jest wiedza na temat zależności pomiędzy archiwizowanymi danymi, co ma konsekwencje dla wyboru kolejności archiwizacji poszczególnych tabel. Należy więc np. uwzględnić, że pozycje pojedyncze z CO (tabela COEP) archiwizują się także przy okazji archiwizacji zleceń sprzedaży. A więc scenariusz archiwizacji powinien przewidywać, by w pierwszej kolejności nastąpiła archiwizacja tabel SD, a dopiero później CO.

Właściwie dobrane obiekty archiwizacji wraz z zależnościami pozwalają na stworzenie mapy archiwizacji obrazującej, które dane i w jakiej kolejności zostaną zarchiwizowane.

Na etapie koncepcji istotne jest również uzgodnienie, z jakiego okresu dane będą archiwizowane, a więc które dane powinny pozostać w bazie ze względu na łatwość i szybkość dostępu. Konieczne jest znalezienie kompromisu między oczekiwaniem użytkowników, że wszystkie dane będą dostępne „tak jak zwykle”, a koniecznością przeniesienie części danych do zewnętrznego archiwum, aby poprawić działanie bazy danych.

Kolejnym istotnym aspektem koncepcji jest określenie dostępu do danych zarchiwizowanych. Dostęp do nich nie różni się specjalnie od dostępu do danych obecnych w bazie. Jednak w wypadku części danych jest on możliwy jedynie za pomocą dedykowanych transakcji, a czasem sposób prezentacji może się różnić od prezentacji danych ulokowanych w bazie.

Struktury informacyjne

W celu umożliwienia poprawnego dostępu do danych konieczne było również aktywowanie odpowiednich struktur informacyjnych archiwizacji. Są to tabele przechowujące wybrane dane spośród archiwizowanych informacji, które następnie ułatwiają i przyspieszają dostęp do informacji zarchiwizowanych. Optymalnie dobrane struktury informacyjne przechowują tylko te dane, które są niezbędne do efektywnego odczytu informacji zarchiwizowanych.

Zbyt rozbudowane struktury informacyjne to większa przestrzeń w bazie danych konieczna do ich utrzymania. Z drugiej strony zbyt ograniczone struktury nie pozwalają na efektywne wyszukiwanie zarchiwizowanych danych po wszystkich kryteriach (polach), które nas interesują.

Warto pamiętać, że jeśli oprócz SAP ERP wykorzystujemy również inne rozwiązania (np. hurtownię danych SAP BW), które są zasilane z systemu SAP, to powinniśmy uwzględnić to na etapie tworzenia koncepcji i zaplanować zasilenie tych systemów przed archiwizacją. Pamiętajmy, że archiwizacja to działania cykliczne, za kilka lat dziś świeże i niezbędne dane staną się obiektami archiwalnymi. Dlatego tak istotny jest precyzyjny opis działań koniecznych do prawidłowego przeprowadzenia całego procesu w kolejnych latach.

W DHL Express całość ustaleń została zawarta w dokumencie opisującym koncepcję archiwizacji, a dla każdego obiektu archiwizacji stworzony został osobny dokument/instrukcja, opisujący, w jaki sposób należy z niego korzystać.

Konfiguracja i testy

Podczas kolejnego etapu projektu na podstawie koncepcji przygotowaliśmy konfigurację, która następnie została wykorzystana na systemie produkcyjnym DHL.

Wyniki testów potwierdziły, że przyjęte założenia są zgodne z oczekiwaniami pod kątem wolumenu zarchiwizowanych danych z jednej strony, a z drugiej zarchiwizowane dane są dostępne dla użytkowników i możliwe jest ich efektywne wykorzystanie.

Dzięki testom udało się też rozwiązać kilka problemów, które wpływały na ilość danych, jaką mogliśmy zarchiwizować. Jednym z częściej występujących problemów były nieprawidłowe statusy archiwizowanych dokumentów czy obiektów (niezamknięte, nierozliczone, w trakcie przetwarzania itp.).

Podobnie jak to miało miejsce na etapie analizy i koncepcji, warunkiem powodzenia tej fazy jest dobra współpraca z użytkownikami kluczowymi systemu SAP.

W projekcie archiwizacji konfiguracja obejmuje zarówno część techniczną, taką jak przygotowanie miejsca składowania danych i powiązania go z systemem SAP (w zależności od przyjętego rozwiązania: dyski, repozytoria przechowujące zarchiwizowane dane, dedykowane oprogramowanie itp.), jak również część biznesową – określenie czasu retencji dla dokumentów, kont, obiektów czy ustawienie odpowiednich znaczników dla określonych typów dokumentów i obiektów.

Testy kończące tę fazę muszą potwierdzić, że oczekiwany efekt jest możliwy do osiągnięcia zarówno ze względu na ilość danych, które możemy usunąć z bazy, jak również ze względu na sposób dostępu do archiwum.

630 GB danych do archiwum

Po potwierdzeniu na etapie testów założeń koncepcji przystąpiliśmy do archiwizacji produkcyjnej. W odróżnieniu od archiwizacji przeprowadzonej testowo, konieczne było uwzględnienie faktu, że uruchomienie zadań archiwizacyjnych na systemie produkcyjnym może mieć wpływ na jego działanie.

Zadania archiwizacyjne znacznie obciążały system, a więc konieczne było planowanie ich w okresach, kiedy na systemie nie były prowadzone operacje istotne dla działalności firmy, takie jak rozliczenia okresowe, zamykanie miesiąca itp. Ze względu na duży wolumen danych pojedyncze zadania archiwizacji trwały nawet kilka dni.

W trakcie trzech miesięcy, bo tyle trwał proces archiwizacji początkowej w DHL, na systemie produkcyjnym uruchomiono ponad 800 pojedynczych zadań związanych z archiwizacją (przetwarzanie wstępne, archiwizacja, usuwanie, przetwarzanie końcowe). Łącznie zarchiwizowano ponad 630 GB danych. Ze względu na efektywną kompresję danych archiwum zajęło jedynie 73 GB. Uzyskano wysoki współczynnik kompresji na poziomie 8,6.

O efektach projektu najdobitniej mówią liczby. Według szacunków, baza danych SAP w DHL w 2013 r. będzie miała wielkość ok. 2,7 TB. Bez archiwizacji danych historycznych osiągnęłaby ok. 4,2 TB, czyli byłaby blisko dwukrotnie większa.

Obok zmniejszenia rozmiaru bazy danych efektem projektu jest także wzrost wydajności pracy systemu. Reakcja systemu w zakresie dotyczącym zapytań do  „odchudzonych” tabel jest obecnie szybsza. Ponadto inne korzyści z archiwizacji to skrócenie czasu wykonywania kopii bezpieczeństwa oraz odtwarzania w przypadku awarii. Niższe są także koszty rozwoju platformy sprzętowej koniecznej do utrzymania systemu.

Projekt archiwizacji w DHL trwał ponad pół roku, co wynikało z wielkości systemu i wolumenu danych. Poszczególne zadania analizujące dane, jak i same zadania archiwizacji przetwarzały się bardzo długo (pojedyncze zadania archiwizacyjne trwały nawet kilka dni).

Konsultanci BCC odpowiadali za archiwizację danych do 2005 r. Obecnie – już we własnym zakresie – administratorzy SAP w DHL Express przygotowują się do zarchiwizowania danych za kolejne lata. Docelowo w systemie mają być przechowywane dane z trzech ostatnich lat.

Jak podkreśla Paweł Rutkowski, Konsultant SAP w DHL Express: „Ten okres to wynik kompromisu pomiędzy wymaganiami biznesu, któremu zależy na dostępności do dużego wolumenu danych, a rozsądną wielkością bazy, która nie wpływa na czas odpowiedzi systemu. Co roku starsze dane będą przenoszone do archiwum, gdzie oczywiście dalej będą dostępne dla uprawnionych użytkowników”.   

O archiwizacji warto pomyśleć zawczasu, kiedy jeszcze bazie danych daleko do rozmiarów rzędu terabajta. W trakcie projektu zostanie uruchomionych od kilkudziesięciu do nawet tysiąca operacji. O wiele łatwiej i szybciej operacje te przebiegną przy stosunkowo niewielkiej wielkości bazy.

Raz opracowana mapa i procedury archiwizacji będą wykorzystywane cyklicznie, by ograniczyć przyrosty bazy danych i utrzymać jej wielkość na rozsądnym poziomie. To największa wartość, jaką daje archiwizacja w systemie SAP.