EA SAP HANA: Zarządzanie pamięcią i wydajnością

 SAP HANA, jako platforma in-memory, oferuje wyjątkową wydajność i elastyczność w przetwarzaniu danych. Jednak by w pełni wykorzystać jej potencjał, niezbędne jest aktywne monitorowanie i zarządzanie zużyciem pamięci, CPU oraz optymalizacja zapytań SQL. W tym artykule omawiamy najważniejsze aspekty związane z zarządzaniem wydajnością i pamięcią w SAP HANA oraz przedstawiamy sprawdzone narzędzia i dobre praktyki.

Architektura pamięci SAP HANA

Główne typy pamięci:

• Virtual Memory – suma wszystkich zarezerwowanych przestrzeni przez procesy HANA

• Resident Memory – pamięć realnie załadowana do RAM

• Used Memory – całkowita pamięć aktualnie w użyciu przez HANA

• Code + Stack Memory – kod binarny + kontekst wątków systemowych

• Table Memory – dane z kolumnowych i wierszowych tabel w RAM

• Working Memory – pamięć dla przetwarzania zapytań i operacji tymczasowych

🔍 Monitoruj M_MEMORY dla szczegółowej analizy struktury pamięci.

Zarządzanie pamięcią – komponenty i limity

Parametry konfiguracyjne:

• global_allocation_limit – maksymalna ilość pamięci RAM dla całego systemu HANA

• allocation_limit – limit dla konkretnego serwisu (np. indexserver)

• statement_memory_limit – ograniczenie zużycia pamięci przez jedno zapytanie SQL

sql
SELECT * FROM M_HOST_RESOURCE_UTILIZATION;
SELECT * FROM M_SERVICE_MEMORY WHERE MEMORY_USAGE > 10000000000;

Rekomendacje:

• Ustaw global_allocation_limit na poziomie licencji (np. 384 GB → 393216 MB)

• Monitoruj M_SERVICE_MEMORY – szukaj serwisów zużywających ponadprzeciętną ilość RAM

• W systemach produkcyjnych ustaw statement_memory_limit dla ochrony przed zapytaniami „zjadającymi” zasoby

Monitorowanie wykorzystania CPU

SAP HANA może intensywnie wykorzystywać CPU, szczególnie przy złożonych zapytaniach.

Narzędzia:

• Performance Monitor (HANA Cockpit / Studio)

• Widok M_SERVICE_STATISTICS i M_THREADS

• Kafelki w HANA Cockpit: CPU Usage, Load History

Wskaźniki:

• Użycie CPU > 85% przez dłuższy czas może wskazywać na problemy

• Długo działające wątki – identyfikuj w M_ACTIVE_STATEMENTS

Diagnostyka:

sql
SELECT * FROM M_THREADS WHERE THREAD_STATE = 'Running' AND TOTAL_CPU_TIME > 100000000;

Analiza drogich zapytań (Expensive Statements)

Czym są „expensive statements”?

To zapytania SQL, które zużywają dużo zasobów – czasu CPU, I/O, pamięci.

Widoki diagnostyczne:

• M_EXPENSIVE_STATEMENTS

• M_SQL_PLAN_CACHE

• M_SQL_EXECUTION_PLAN

sql
SELECT * FROM M_EXPENSIVE_STATEMENTS WHERE START_TIME > ADD_SECONDS(CURRENT_TIMESTAMP, -600);

Narzędzia:

• SQL Analyzer – analiza planów zapytań

• Plan Visualizer (PlanViz) – graficzna analiza wykonania zapytania

💡 Włącz śledzenie drogich zapytań, ustawiając progowy czas wykonania (np. 1s)

Optymalizacja wydajności – dobre praktyki

Rekomendacje:

• Unikaj SELECT * – pobieraj tylko niezbędne kolumny

• Używaj LIMIT i paginacji dla dużych wyników

• Zmieniaj strukturę zapytań – np. zamiana IN na JOIN

• Monitoruj widoki – zapytania na widokach obliczeniowych mogą być kosztowne

Narzędzia automatyczne:

• SAP HANA Mini Checks – zestaw gotowych zapytań diagnostycznych (SAP Note 1969700)

• Alerting Framework – wbudowany system alertów z poziomami (Info, Low, Medium, High)

Zarządzanie procesem Delta Merge

W przypadku tabel kolumnowych dane zapisywane są najpierw do delta store, a później łączone z głównym segmentem podczas delta merge.

Kiedy następuje merge?

• Automatycznie po przekroczeniu progu

• Ręcznie (np. po dużym INSERT)

Śledzenie:

sql
SELECT * FROM M_DELTA_MERGE_STATISTICS ORDER BY LAST_MERGE_TIME DESC;

Typy merge:

• Auto

• Smart (bazujący na heurystykach)

• Hard (ręczny, wymuszony)

• Critical (przekroczony limit)

💡 Regularne merge zmniejszają zużycie pamięci i poprawiają wydajność zapytań SELECT.

Zarządzanie wydajnością w HANA Cockpit

W HANA Cockpit znajdziesz dedykowane sekcje:

• Memory Overview – statystyki alokacji

• CPU Usage – wykresy i historia obciążenia

• Expensive Statements Monitor – lista problematycznych zapytań

• Alert Inbox – monitoring i konfiguracja alertów

Podsumowanie

Efektywne zarządzanie pamięcią i wydajnością to kluczowy element pracy administratora SAP HANA. Wysoka wydajność systemu to nie tylko wynik technologii in-memory, ale też konsekwentnego monitorowania i optymalizacji zasobów.

Monitoruj zużycie pamięci i CPU
Identyfikuj i optymalizuj kosztowne zapytania
Zarządzaj delta merge dla stabilności systemu
Korzystaj z Cockpita i Mini Checks do analizy systemowej

EA SAP HANA: Podstawowe narzędzie do zarządzania bazą

 SAP HANA to potężna platforma bazodanowa, której efektywne zarządzanie wymaga odpowiednich narzędzi administracyjnych. Najważniejszymi z nich są SAP HANA Cockpit oraz SAP HANA Studio – oba oferują dostęp do kluczowych funkcji monitorowania, konfiguracji, tworzenia kopii zapasowych i analizy wydajności. W tym artykule przyjrzymy się bliżej ich możliwościom, różnicom oraz praktycznym scenariuszom użycia.

SAP HANA Cockpit – nowoczesne zarządzanie przez przeglądarkę

Co to jest SAP HANA Cockpit?

SAP HANA Cockpit to webowe, oparte na HTML5 narzędzie administracyjne działające w architekturze XS Advanced. Służy do zarządzania wieloma systemami SAP HANA z jednego miejsca. Umożliwia pracę w przeglądarce i nie wymaga instalacji lokalnej.

Najważniejsze funkcje Cockpita:

• Monitoring zużycia CPU, pamięci, dysku

• Zarządzanie bazami tenantowymi (tworzenie, start/stop, backup)

• Przegląd alertów i konfiguracja reguł powiadomień

• Zarządzanie użytkownikami i rolami

• Wgląd w konfigurację systemu (parametry, warstwy .ini)

• Tworzenie kopii zapasowych i odtwarzanie danych

Interfejs użytkownika:

• Tiles Dashboard: intuicyjne kafelki pokazujące stan systemu

• Resource Groups: organizacja środowiska według grup (np. produkcja/test)

• Drill-down do szczegółowych metryk

Wymagania:

• Zainstalowany komponent SAP HANA Cockpit 2.0

• Użytkownik techniczny z rolą: CATALOG READ, MONITOR ADMIN, INIFILE ADMIN

SAP HANA Studio – klasyczne narzędzie desktopowe

Co to jest SAP HANA Studio?

To starsze, ale wciąż bardzo użyteczne środowisko typu IDE oparte na Eclipse. Pozwala na zarządzanie bazą danych SAP HANA oraz tworzenie i modelowanie danych.

Główne funkcje SAP HANA Studio:

• Podgląd i zarządzanie strukturą danych

• SQL Console – wykonywanie zapytań SQL

• Przegląd i modyfikacja konfiguracji .ini

• Zarządzanie użytkownikami i rolami

• Monitoring zasobów i wykorzystania systemu

• Zarządzanie kopiami zapasowymi

Dostępne „perspektywy”:

• Administration Console – do administracji systemem

• Modeler – do tworzenia modeli danych

• Lifecycle Management – do instalacji aktualizacji i transportów

SAP HANA Cockpit vs Studio – porównanie

Funkcja	SAP HANA Cockpit	SAP HANA Studio
Dostęp	Przeglądarka internetowa	Aplikacja desktopowa
Obsługa wielu systemów	✅ Tak	🔶 Ograniczona
SQL Console	✅ Tak	✅ Tak
Zarządzanie użytkownikami	✅ Tak	✅ Tak
Monitoring systemu	✅ Nowoczesny, responsywny	✅ Klasyczny
Obsługa XS Advanced	✅ Tak	❌ Nie
Instalacja aplikacji/modeli danych	🔶 Ograniczona	✅ Tak (Modeler)
Zalecane użycie	Nowe instalacje, krajobrazy	Utrzymanie istniejących systemów, development

Typowe scenariusze administracyjne

Tworzenie kopii zapasowej (Cockpit)

1. Otwórz Cockpit → Wybierz bazę danych

2. Przejdź do kafelka „Backup”

3. Kliknij „Create Backup” → wybierz typ: full, differential, incremental

4. Uruchom → potwierdź sukces operacji

Restart instancji (Studio)

1. Zaloguj się do systemu jako SYSTEM lub admin

2. W zakładce „System” kliknij prawym → „Stop System”

3. Po chwili → „Start System”

4. Zweryfikuj status usług w zakładce „Landscape”

Dodanie użytkownika (SQL)

sql
CREATE USER admin IDENTIFIED BY "SecurePassword123";
GRANT MONITORING, BACKUP ADMIN TO admin;

Zarządzanie bazami tenantowymi (Cockpit)

Możliwości:

• Tworzenie nowego tenanta:

  sql
  CREATE DATABASE TENANT1 SYSTEM USER PASSWORD "TenantPass";
  

• Start/Stop konkretnego tenanta:

  sql
  ALTER SYSTEM START DATABASE TENANT1;
  ALTER SYSTEM STOP DATABASE TENANT1;
  

• Zarządzanie zasobami: pamięć, CPU (w zakładce "Resource Allocation")

Praktyczne wskazówki i dobre praktyki

• Używaj dedykowanych użytkowników technicznych z ograniczonymi uprawnieniami (np. tylko BACKUP OPERATOR)

• Testuj zmiany konfiguracyjne najpierw w systemach nieprodukcyjnych

• Zaplanuj regularne backupy i sprawdzaj logi ich wykonania

• Monitoruj alerty i analizuj historyczne dane wydajnościowe

• Nie edytuj plików .ini ręcznie – zawsze używaj Cockpita lub Studio

Podsumowanie

SAP HANA Cockpit i SAP HANA Studio to dwa komplementarne narzędzia do zarządzania bazą danych HANA. Cockpit zapewnia nowoczesne, centralne zarządzanie i monitoring, natomiast Studio pozostaje przydatne przy pracy lokalnej i modelowaniu danych.

✅ Cockpit – dla administratorów i DevOps
✅ Studio – dla developerów i klasycznej administracji

EA 12 factor app - fundament dla nowoczesnych aplikacji chmurowych czy przestarzały hype?

 W poprzednim wpisie „EA: 12 Factor Agents — Nowe podejście, które może zmienić Twoje myślenie o AI” zaproponowałem przeniesienie idei 12 Factor App na grunt architektury agentowej. Czas wrócić do źródeł i przyjrzeć się oryginalnemu manifestowi 12factor.net, który — mimo że powstał ponad dekadę temu — wciąż stanowi solidny fundament dla budowania nowoczesnych aplikacji chmurowych, mikrousług i systemów agentowych.

Dlaczego warto znać 12 Factor App?

Zasady 12 Factor App to nie przepis na framework czy technologię, ale zestaw praktyk projektowych, które pomagają budować aplikacje:

• przenośne (cloud-native),

• skalowalne poziomo,

• łatwe do wdrażania, monitorowania i rozwijania.

W świecie, w którym infrastruktura staje się zautomatyzowana, a aplikacje coraz bardziej rozproszone, te zasady okazują się nie tyle dobrowolnymi rekomendacjami, co warunkiem „przeżycia” w produkcji.

12 czynników — w skrócie i z komentarzem architekta

Przyjrzyjmy się krótko każdemu z 12 czynników, z perspektywy osoby projektującej systemy rozproszone, często hybrydowe, integrujące się z agentami, API, systemami kolejkowymi i narzędziami DevOps.

1. Codebase — jedna baza kodu na aplikację

Każdy serwis powinien mieć jedno źródło prawdy (repozytorium Git). W przypadku systemów agentowych może to oznaczać, że agent to również jednostka wdrożeniowa (np. kontener), a nie biblioteka współdzielona przez inne serwisy.

2. Dependencies — jawne zarządzanie zależnościami

Brak polegania na globalnym środowisku (jak systemowe paczki). W świecie micro-agents oznacza to np. unikanie ukrytych zależności między agentami a platformą hostującą.

3. Config — konfiguracja przez zmienne środowiskowe

Oddzielenie kodu od konfiguracji to baza dla portowalności i automatyzacji — zarówno w CI/CD, jak i w orkiestracji (Kubernetes, Nomad).

4. Backing services — traktuj zewnętrzne zasoby jak attachable

Usługi takie jak bazy danych, kolejki, pamięci cache są zależnościami, nie integralną częścią aplikacji. Ułatwia to testowanie, replikację, skalowanie.

5. Build, release, run — rozdzielenie etapów cyklu życia aplikacji

Oddzielenie builda (np. Docker image), release'u (konfiguracja + build) i uruchomienia (run-time). Kluczowe przy wersjonowaniu agentów i rollbackach.

6. Processes — bezstanowe procesy

Statelessness to kręgosłup skalowalności i niezawodności. Dane sesyjne powinny trafić do Redis, a nie do pamięci agenta.

7. Port binding — self-contained aplikacje nasłuchujące na porcie

Każda aplikacja (lub agent) powinna być samodzielna i gotowa do uruchomienia w dowolnym środowisku przez proste docker run.

8. Concurrency — skalowanie przez procesy

Nie chodzi tylko o wielowątkowość, ale o świadome projektowanie poziomów równoległości (np. web, worker, cron). W systemach agentowych: osobne procesy dla agentów odpowiedzialnych za inne zadania.

9. Disposability — szybki start i czyste wyłączanie

Aplikacja (agent) powinna uruchamiać się i zamykać szybko i bezpiecznie. Przydatne w autoskalowaniu i orchestracji (K8s, ECS).

10. Dev/prod parity — minimalizacja różnic środowiskowych

Im mniejsza różnica między lokalnym docker-compose up a produkcją w chmurze, tym mniej „niespodzianek”. Infrastructure as Code to tu podstawa.

11. Logs — traktuj logi jako strumień zdarzeń

Nie zapisuj logów do pliku — logi mają iść na stdout/stderr, by mogły być przechwycone przez ELK, Loki, czy inny system monitorujący.

12. Admin processes — pomocnicze zadania jako jednorazowe procesy

Migracje bazy, inspekcja danych czy czyszczenie cache — wszystko jako osobne, uruchamialne procesy. Idealne do CRON-jobów lub zadań DevOps.

12 Factor App vs. 12 Factor Agents

W podejściu agentowym mówimy o architekturze zorientowanej na samodzielne, autonomiczne komponenty komunikujące się ze sobą. W tym świetle:

• Agent może być procesem zgodnym z 12FA.

• Platforma dla agentów powinna wspierać lifecycle wg 12FA (deployment, logi, konfiguracja).

• Rozproszenie i niezależność agentów staje się naturalnym rozszerzeniem idei „self-contained apps”.

W praktyce — 12 Factor App to doskonały fundament, na którym możemy budować 12 Factor Agents.

Kiedy 12 Factor App się nie sprawdzi?

Oczywiście, jak każde podejście, 12FA ma swoje ograniczenia:

• Trudno je zastosować do monolitów z dużym stanem wewnętrznym (ERP, legacy).

• Nie nadaje się do aplikacji wymagających silnego stateful compute (np. stream processing bez zewnętrznego stanu).

• Wymaga kultury DevOps i automatyzacji — bez tego wiele założeń się nie obroni.

Podsumowanie

Zasady 12 Factor App pozostają aktualne, zwłaszcza jako podstawa dla nowoczesnych, autonomicznych komponentów — w tym agentów. W połączeniu z architekturą agentową stanowią przepis na systemy:

• elastyczne i odporne na zmiany,

• łatwe do wdrażania i skalowania,

• zgodne z filozofią „as a Service”.

Jeśli jeszcze nie stosujesz 12FA — warto zacząć chociażby od rozdzielenia konfiguracji, logów i budowania obrazów aplikacyjnych. Małe kroki, wielki zysk.

Czy Twój system jest zgodny z 12 Factor App? A może agenci w Twojej organizacji mogliby na tym podejściu skorzystać? Daj znać w komentarzach lub na LinkedInie — chętnie podyskutuję.

EA CNCF – ekosystem, który napędza współczesny cloud-native

 W ciągu ostatnich kilku lat pojęcie cloud-native przestało być modnym hasłem, a stało się standardem w budowie nowoczesnych systemów. Ale za sukcesem wielu technologii, które dzisiaj uważamy za podstawowe — jak Kubernetes, Prometheus czy Envoy — stoi jedna organizacja: Cloud Native Computing Foundation (CNCF). W tym artykule przyjrzymy się, czym jest CNCF, jaka jest jej historia, kto za nią stoi i jak wygląda proces adopcji projektów do tego ekosystemu.

Czym jest CNCF?

Cloud Native Computing Foundation (CNCF) to fundacja typu non-profit, która powstała w 2015 roku jako część Linux Foundation. Jej celem jest rozwój, standaryzacja i promocja technologii cloud-native — takich, które są zbudowane z myślą o chmurze, konteneryzacji, skalowalności i niezawodności.

CNCF definiuje „cloud-native” jako podejście do budowania systemów odpornych, skalowalnych i zarządzalnych, wykorzystując kontenery, architektury mikroserwisowe, deklaratywne API oraz automatyzację.

Krótka historia CNCF

Fundacja została założona w lipcu 2015 roku — dokładnie wtedy, gdy Google przekazał projekt Kubernetes do open source i oddał go pod skrzydła CNCF. To był kamień milowy. Kubernetes stał się pierwszym i sztandarowym projektem fundacji.

Od tego czasu CNCF stała się jednym z największych i najbardziej wpływowych organizatorów open source w sektorze infrastruktury IT:

• 2015 – Google przekazuje Kubernetes

• 2016 – dołącza Prometheus jako drugi projekt

• 2017-2019 – boom popularności i adopcji narzędzi typu Envoy, Fluentd, Helm, gRPC

• 2020+ – CNCF zarządza setkami projektów i organizuje globalne wydarzenia (np. KubeCon)

Kto uczestniczy w CNCF?

CNCF to nie tylko fundacja – to przede wszystkim społeczność: firmy, kontrybutorzy open source, dostawcy chmury, integratorzy i niezależni deweloperzy. Fundacja ma obecnie:

• Ponad 1700 członków organizacyjnych – w tym Amazon, Google, Microsoft, Red Hat, VMware, Huawei, Alibaba

• Ponad 130 projektów open source

• Tysiące kontrybutorów z całego świata

• Ogromną społeczność skupioną wokół wydarzeń takich jak KubeCon + CloudNativeCon

Również polskie firmy i inżynierowie uczestniczą w rozwoju projektów CNCF, co czyni ten ekosystem prawdziwie globalnym.

Cykl życia projektów w CNCF

CNCF nie przyjmuje dowolnych projektów ani nie traktuje ich wszystkich jednakowo. Każdy projekt przechodzi przez trzy etapy w swoim „życiu” w fundacji:

1. Sandbox

To etap inkubacji – projekty trafiają tu, gdy:

• Są we wczesnej fazie rozwoju

• Chcą zbudować społeczność

• Chcą pokazać potencjał w zakresie cloud-native

Przykład: Dapr, Crossplane, Keptn zaczynały w Sandbox.

2. Incubating

Projekt trafia tu, gdy:

• Udowodnił swoje zastosowanie w praktyce

• Ma aktywną społeczność

• Ma formalne procedury rozwoju i zarządzania

CNCF pomaga wówczas w stabilizacji, dokumentacji, bezpieczeństwie i adopcji przez firmy.

3. Graduated

To status „pełnoprawnego obywatela CNCF”. Wymagania:

• Dowiedzione wdrożenia produkcyjne w wielu organizacjach

• Zrównoważony rozwój i governance

• Spełnienie rygorystycznych wymagań co do bezpieczeństwa i dokumentacji

Przykłady: Kubernetes, Prometheus, Envoy, etcd, containerd

Co daje projektowi dołączenie do CNCF?

• Wiarygodność i zaufanie – dla klientów i deweloperów

• Wsparcie społeczności i fundacji – w obszarach takich jak bezpieczeństwo, testy, CI/CD

• Ekspozycję – m.in. na wydarzeniach CNCF, w raportach i na mapie landscape

• Integrację z innymi projektami – naturalna kompatybilność z Kubernetes i innymi toolami z ekosystemu

CNCF Landscape – mapa (nie)do ogarnięcia

CNCF prowadzi Cloud Native Landscape – interaktywną mapę ekosystemu cloud-native. Znajdziemy tam setki narzędzi pogrupowanych m.in. według kategorii:

• Orkiestracja i zarządzanie

• Obserwowalność i analiza

• Networking

• Storage

• Continuous Delivery

To świetne źródło inspiracji, ale też przestroga – ekosystem CNCF jest ogromny i ciągle rośnie.

🔗 https://landscape.cncf.io

Podsumowanie

CNCF to dziś serce open source'owego świata cloud-native. Jeśli budujesz rozwiązania oparte na Kubernetes, Prometheus, Linkerd, gRPC lub setkach innych technologii – korzystasz z efektów pracy tej fundacji i jej społeczności.

Ale CNCF to nie tylko narzędzia – to także kultura otwartości, transparentności i inżynierskiej doskonałości.

Warto śledzić jej rozwój, bo to, co dzisiaj jest w sandbox, jutro może być fundamentem Twojej infrastruktury.