Optimize
Transform
Visualize
Interdobs
Interdobs de toonaangevende SAP dienstverlener op het gebied van Business Intelligence. Wij bieden advies, beheer en projectondersteuning op de SAP on-premise en de Cloud producten voor data modellering, data analyse, rapportages, dashboards, predictive analytics en HANA.
Optimize
Interdobs is als geen ander op de hoogte van de laatste stand van de mogelijkheden van de SAP Analytics software en Analytics roadmaps. In onze demo omgevingen experimenteren wij met de nieuwste versies en daardoor kunnen wij uit eerste hand vertellen waar integratie en content aanwezig is en waar nog verder doorontwikkeling benodigd is. Na het samen definiëren van de gewenste stip op de horizon stellen we een pragmatische roadmap op, waardoor de route voorwaarts en eventuele keuzemogelijkheden tussen optimaliseren of vervangen zich zullen openbaren. Interdobs staat voor u klaar!
Transform
Interdobs heeft zich als doel gesteld om u te helpen bij het maken van de juiste beslissing voor uw hele organisatie. Van BI Architectuur tot Analytics, van ruwe data uit uw systemen naar getransformeerde, geharmoniseerde en gevalideerde informatie in het Data Warehouse. SAP Data Warehousing is overigens allang niet meer het klassieke SAP BW van vroeger. Met alle nieuwe mogelijkheden om een agile data warehouse op te zetten, met ruimte voor continue (DevOps) ontwikkelingen, en een keuze voor techniek (BW/4HANA of het HANA SQL Data Warehouse), zijn de mogelijkheden voor uw transformatie eindeloos. Wij bepalen graag samen met u de juiste route!
Visualize
Interdobs realiseert op een methodische wijze de data visualisaties die het juiste verhaal vertellen om de vervolgacties in gang te kunnen zetten. We kijken naar ‘de vraag die achter de vraag’ en maken bij de realisatie gebruik van markt standaarden als HICHERT®SUCCESS en Stephen Few.
OPTIMIZE
TRANSFORM
VISUALIZE

Honey, I ate the HANA memory!

Maakt u zich geen zorgen. Deze blog gaat niet over de nieuwste Disney film, maar over een “side effect”  waar wij onlangs tegenaan liepen in 1 van onze PMO scans. Nog even ter opfrissing: onze PMO scan helpt om uw HANA systeem in optimale conditie te krijgen en te houden. Meer details kunt u hier vinden.

Wat was het geval?

Onze klant gaf aan dat het HANA systeem op onverklaarbare wijze het volledig beschikbare geheugen alloceerde. Nu is HANA vaak hongerig op het gebied van geheugen, het verwerken van alle gegevens in geheugen is tenslotte 1 van de krachten van de database, maar dit was wel erg gortig.

1 van de zaken die ons opviel was dat een zogeheten “row store reorganisation” nodig was. U kunt deze actie vergelijken met de schijf defragmentatie die u vroeger weleens op uw laptop deed om alle data weer in de juiste volgorde te krijgen.

De HANA reorganisatie is een actie die voor optimaal resultaat, plaats moet vinden tijdens down time. Het is dus vaak zo dat dit niet frequent gebeurd, het down brengen van een systeem is tenslotte niet iets was altijd uitkomt.

 

  1. Restart time row store reorganization
    Row store reorganization can be performed at restart time. Since there are no active update transactions during the restart time, this reorganization achieves the maximum compression ratio.
  2. Online row store reorganization
    Row store reorganization can be performed at runtime. To minimize the interference of other transactions, the relevant tables are locked exclusively and update transactions cannot be carried out on those tables. The list of affected tables is determined on the fly depending on the memory usage. As it is executed at runtime, some uncompressed row store memory may remain.

 

Mijn tip aan u is om frequent de Early Watch te raadplegen om te kijken of optimalisatie nodig is. Ga ook vooral voor de 1e optie voor maximaal resultaat.

Terugkomend op het probleem wat onze klant schetste, dit was nog niet het missende puzzelstukje.

Wij vonden deze door een SQL statement te draaien waarin een grote geheugen allocatie aan het licht kwam:

Het geheugen in cache (database management in onderstaande illustratie) was net zo groot als alle data welke opgeslagen was in de DSOs en InfoObjecten (column tables)!

OSS Note 2301382 gaf ons een verklaring:

Starting with SAP HANA Rev. 110 some specific types of persistence pages (virtual file pages) are more likely to be added to the SAP HANA page cache to improve performance. As a result, once used, they will remain in memory, be counted as “Used memory”, and HANA will evict them only if the memory is needed for other objects, such as table data or query intermediate results.

On top of this behaviour a significant amount of pages can be cached unintentionally with SAP HANA Rev. 110 to 122.05 due to a problem in the SAP HANA software.

 

We zien hier een duidelijke bug (alinea 2), maar ook alinea 1 geeft wat vraagtekens. “evict only” geeft aan dat de cache voor lange tijd het geheugen bezet kan houden.

Indien we dit niet hadden gevonden tijdens onze PMO scan, had dit natuurlijk eenvoudig tot een onjuiste beslissing kunnen leiden. Het is voor systeembeheerders vaak lastig om aan te geven waarom het HANA systeem vol zit. Het wordt pas echt vervelend als alleen op basis van een algemene analyse van het geheugengebruik, besloten wordt om nieuwe hardware aan te schaffen, zonder diep het systeem in te duiken.

Onze klanten zien daar vaak de kracht van onze PMO scan, wij gaan door tot het laatste puzzelstukje gevonden is!

SAP heeft overigens actie ondernomen om de honger van het HANA systeem te stillen. In Note 2403124 wordt beschreven hoe door het zetten van een parameter men weer terug kan naar de situatie voor SPS11.

 

Eind goed al goed!

 

Ook geïnteresseerd hoe wij uw HANA systeem kunnen tunen? Neem contact met ons op!