Der Weg zu SAP BW auf HANA: Teil 2 Applikation€¦ · o Nur open SQL Kein Coding mit DB-spezifischer Syntax ... HANA werden BW Transformationen mehr und mehr als HANA-Prozeduren

Der Weg zu SAP BW auf HANA:

Teil 2 – ApplikationFrank Riesner, Solution Architect, SAP (Schweiz) AG

© 2015 SAP SE. All rights reserved. 30Public

Migrationsvoraussetzungen seitens BW-Applikation

• SAP HANA

o Nur open SQL

Kein Coding mit DB-spezifischer Syntax (z.B. Oracle Hints etc.)

• SAP NetWeaver 7.4

o Neues Konzept der Analyseberechtigungen (Tr. RSECADMIN)

o BEx-Frontendtools und BEx-Berichte nur noch in Version 7.x

Sind diese Voraussetzungen erfüllt, läuft SAP BW nach der Migration auf SAP HANA störungsfrei weiter.

(„non-disruptive approach“)


Empfohlene Anpassungen nach der Migration

• Prio 1

o Prüfung Delta-Merge Einstellungen

o Prüfung Konzept nicht-aktiver Daten

• Prio 2

o Konvertierung von InfoCubes

o Anpassungen an Prozessketten

o Löschen von Sekundärindices

• Prio 3

o Abbau nicht benötigter InfoCubes

o Optimierung von Transformationen

o Analyse BEx Query-Ausführungsmodus

• Anschließend

o Einsatz neuer Funktionen


Prio 1: Verstehen Sie den „Delta Merge“!

• Delta Merge wird automatisch von SAP HANA DB verwaltet für:

PSA-Tabellen, standard DataStore-Objekte und InfoObjekte

• Delta Merge muss von BW Applikation gesteuert werden für:

InfoCubes

Schreiboptimierte DataStore-Objekte

Spaltenbasierte Tabelle

Main-

StorageDelta-Storage

Schreiben

Lesen

Delta Merge

Main-Storage:

Spaltenbasiert (sortiert), dadurch leseoptimiert

Delta-Storage:

Spaltenbasiert (unsortiert) oder zeilenbasiert, dadurch schreiboptimiert

SAP HANA

Hauptspeicher

Im Datentransfer-Prozess In Prozesskette


Prio 1: Prüfen Sie das Konzept nicht-aktiver Daten!

Dieses neue Konzept optimiert die Nutzung der Memory-Ressourcen des BW-Systems und

teilt BW InfoProvider hierzu in zwei Gruppen ein:

o Gruppe 1: Aktive InfoProviderWerden immer im Memory gehalten, denn sind relevant für tägliches Laden und Reporting

InfoCubes, standard DataStore-Objekte und alle Stammdaten

o Gruppe 2: Nicht-aktive InfoProviderWerden auch im Memory gehalten, aber bei Ressourcenknappheit mit höchster Priorität daraus entfernt

PSA-tables, schreiboptimierte DataStore-Objekte

Nach der Migration auf SAP HANA sind zunächst alle PSA-Tabellen und

schreiboptimierte DataStore-Objekte als nicht-aktiv definiert.

Kunden nutzen allerdings häufig schreiboptimierte DataStore-Objekte für Aufgaben der Gruppe 1.

In solchen Fällen sollten diese DataStore-Objekte in aktive InfoProvider umgewandelt werden,

um Performancenachteile zu vermeiden.

• Umsetzung: Tr. RSHDBMON oder DWH Workbench / Administration

Entfernen des “Early-Unload”-Kennzeichens


Prio 2: Konvertieren Sie InfoCubes!

Klassischer InfoCube SAP HANA-optimierter InfoCube

• Klassischer InfoCube: erweitertes Sternschema optimiert für relationale DBs

2 Fakttabellen

4-16 Dimensiontabellen (3 Standard- und bis zu 13 Kundendimensionen) 6 - 18 Tabellen

• SAP HANA-optimierter InfoCube: vereinfachtes Schema optimiert für SAP HANA

1 Fakttabelle

1 Standard Dimensiontabelle für das Datenpaket nur 2 Tabellen


Prio 2: Konvertieren Sie InfoCubes!

• Warum alle InfoCubes konvertieren?

Deutlich einfachere Modellierung: Keine schlecht definierten InfoCubes mehr!

Flexible Remodellierung jederzeit: Nur Änderung von Metadaten, aber physiches Datenmodell bleibt unverändert!

Spürbar schnelleres Laden in InfoCubes: Faktor 3-5 durch fehlende Dimensionstabellen!

Konvertierung ist sehr effizient und läuft auch bei großen InfoCubes nur wenige Minuten!

Durch Konvertierung spürbar weniger Speicherbedarf!

Keine Auswirkung auf Reportingobjekte oder Datenflüsse!

(Queryperformance quasi unverändert und daher kein Grund)

• Umsetzung

Tr. RSMIGRHANADB

Nicht transportierbar, in jedem System durchzuführen.


Prio 2: Passen Sie Prozessketten an!

SAP BW auf anyDB

SAP BW auf HANA

Obsolete Verarbeitungsschritte

• Index löschen

• Index neu aufbauen

• Datenbankstatistiken auffrischen

• Hochrollen gefüllter Aggregate

• Neuaufbau definierter Aggregate

• Anpassen existierender Aggregate durch ChangeRun

• BW Accelerator Index aktualisieren

Ergebnis

• Deutlich übersichtlichere Prozessketten

• Weniger Entwicklungs- und Verwaltungsaufwand

• Bessere Laufzeiten


Prio 2: Entfernen Sie Sekundärindices!

• Sekundärindices sind in SAP HANA grundsätzlich nicht mehr notwendig, da sich SAP HANA auch

so durch sehr gute Suchperformance auszeichnet.

• Somit sind alle kundeneigenen Indices im BW-System genau zu prüfen. SAP empfiehlt diese wo immer

möglich zu entfernen, denn sie belegen unnötigerweise Speicherressourcen und haben einen

negativen Einfluss auf die Schreibperformance der Datenbank.

• In DataStore-Objekten wurden Sekundärindices ursprünglich während der Migration auf SAP HANA

gelöscht. Ab BW 7.30 SP09 bzw. BW 7.4 jedoch bleiben sie erhalten.

Warum? -In Ausnahmefällen können Sekundärindices dennoch die Suche beschleunigen, vor allem bei

sehr komplexen Abfragen auf mehrere Nicht-Schlüsselfelder…

• Empfohlenes Vorgehen:

Indexdefinition zunächst belassen, aber physisch von DB löschen (ABAP Datenbank Utility, Tr. SE14).

Wenn die Systemperformance Ihre Erwartungen erfüllt, sollten dann auch die Metadaten gelöscht werden.


Hauptvorteile von BW auf SAP HANA

BW Applikationsserver (ABAP)

Massiver

Datentransfer

Gesamte Verarbeitungslogik

Klassische Datenbank

BW Applikationsserver (ABAP)

Reduzierter

Datentransfer

(nur Ergebnisse)

Verbliebene Verarbeitungslogik

Datenintensive

Verarbeitungen

SAP

HANA

»Code-Push-Down«

HANA-optimierte Datenverarbeitungsabläufe in SAP BW


Prio 3: Löschen Sie überflüssige InfoCubes!

• Mit BW auf HANA können Sie ohne Bedenken direkt auf DataStore-Objekte reporten.

InfoCubes als Reportingstruktur und als „Accelerator“ für flexibles schnelles Reporting sind obsolet!

• Sollten InfoCubes nur existieren, um vor-aggregierte Daten für schnelles Reporting vorzuhalten, dann sollten

diese gelöscht werden. Dies ist der Fall, wenn die Transformation zwischen DataStore-Objekte(n) und

InfoCube(s) keine zusätzliche Businesslogik abbildet und Felder nur 1:1 überträgt.

• Solche Transformationen können Sie mit dem “Transformation Finder” (SAPnote 1908367) lokalisieren.

• Prüfen Sie auch, ob die Logik nicht in die Querydefinition oder in die

Transformation in die DataStore-Objekte verlagert werden können.

• Ist dies möglich, dann lassen sich unnötige so Persistenzen vermeiden,

Ladezeiten verringern und der Speicherverbrauch reduzieren.


Prio 3: Optimieren Sie Transformationen!

• Analysieren Sie, ob ihre ABAP-Routinen verbessert werden können

SAP BW Routine Analyzer (SAPnote 1847431)

Ausführung pro Prozesskette, Transformation, APD, IP-Planungsszenario etc.

Datentransfer-Prozess

• Analysieren Sie, ob ihre Transformationen HANA-optimiert verarbeitet werden können. Seit BW 7.4 auf

HANA werden BW Transformationen mehr und mehr als HANA-Prozeduren abgebildet (anstelle von ABAP-

Programmen). Evtl. lohnt sich eine Überarbeitung, um die HANA-Optimierung nutzen zu können.

Voraussetzungen:

Unterstütze Transformationen: 1:1 Mapping, Zeitkonvertierung,

Einheitenkonvertierung, Formeln, Nachlesen von InfoObjekten,

Nachlesen von DataStore-Objekten, Expertenroutine HANA SQL Skript.

Unterstütze Datenquellen: PSA, DataSore-Objekte, InfoCubes,

MultiProvider, CompositeProvider, InfoSources

Unterstütze Datenziele: DataStore-Objekte,

InfoSources, OpenHub-Destinationen

• Umsetzung: In Transformationsregel und DTP


Prio 3: Evaluieren Sie Query-Ausführungsmodi!

• In BW auf HANA existieren verschiedene Ausführungmodi für BEx-Queries

o Mode “0” – Nicht optimierte Verarbeitung in HANA

o Mode “2” – Individuelle Verarbeitung pro InfoProvider

o Mode “3” – Optimierte Verarbeitung (Standard bis BW 7.4 SP07)

o Mode “6” – Ausnahmeaggregation (Standard ab BW 7.4 SP08)

• Für die große Mehrzahl der BEx-Queries ist die Standardeinstellung die beste und schnellste Ausführungsart.

Es existieren aber Ausnahmen, in denen eine Abweichung vom Standardmodus bessere Laufzeiten ergeben

kann.

• Der BW Query Monitor (Tr. RSRT) ermöglicht diese Evaluation

durch Simulieren einer BEx-Query in verschiedenen

Ausführungsmodi.

• SAPnote 2063449 beschreibt, welche BEx-Funktionen bereits HANA-optimiert sind bzw. noch werden.


Prio 3: Evaluieren Sie Query-Ausführungsmodi!

• Umsetzung:

Ausführungsmodus pro InfoProvider: InfoProvider-Eigenschaften oder Tr. RSDIPROP

Ausführungsmodus pro BEx-Query: Query Monitor, Tr. RSRT


Empfohlene Anpassungen nach der Migration

• Prio 1

o Prüfung Delta-Merge Einstellungen

o Prüfung Konzept nicht-aktiver Daten

• Prio 2

o Konvertierung von InfoCubes

o Anpassungen an Prozessketten

o Löschen von Sekundärindices

• Prio 3

o Abbau nicht benötigter InfoCubes

o Optimierung von Transformationen

o Analyse BEx Query-Ausführungsmodus

• Anschließend

o Einsatz neuer Funktionen


© 2015 SAP SE oder ein SAP-Konzernunternehmen.

Alle Rechte vorbehalten.

Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrückliche schriftliche

Genehmigung durch SAP SE oder ein SAP-Konzernunternehmen nicht gestattet.

SAP und andere in diesem Dokument erwähnte Produkte und Dienstleistungen von SAP sowie die dazugehörigen Logos sind Marken oder eingetragene Marken der

SAP SE (oder von einem SAP-Konzernunternehmen) in Deutschland und verschiedenen anderen Ländern weltweit.

Weitere Hinweise und Informationen zum Markenrecht finden Sie unter http://global.sap.com/corporate-de/legal/copyright/index.epx.

Die von SAP SE oder deren Vertriebsfirmen angebotenen Softwareprodukte können Softwarekomponenten auch anderer Softwarehersteller enthalten.

Produkte können länderspezifische Unterschiede aufweisen.

Die vorliegenden Unterlagen werden von der SAP SE oder einem SAP-Konzernunternehmen bereitgestellt und dienen ausschließlich zu Informationszwecken.

Die SAP SE oder ihre Konzernunternehmen übernehmen keinerlei Haftung oder Gewährleistung für Fehler oder Unvollständigkeiten in dieser Publikation.

Die SAP SE oder ein SAP-Konzernunternehmen steht lediglich für Produkte und Dienstleistungen nach der Maßgabe ein, die in der Vereinbarung über die jeweiligen

Produkte und Dienstleistungen ausdrücklich geregelt ist. Keine der hierin enthaltenen Informationen ist als zusätzliche Garantie zu interpretieren.

Insbesondere sind die SAP SE oder ihre Konzernunternehmen in keiner Weise verpflichtet, in dieser Publikation oder einer zugehörigen Präsentation dargestellte

Geschäftsabläufe zu verfolgen oder hierin wiedergegebene Funktionen zu entwickeln oder zu veröffentlichen. Diese Publikation oder eine zugehörige Präsentation,

die Strategie und etwaige künftige Entwicklungen, Produkte und/oder Plattformen der SAP SE oder ihrer Konzernunternehmen können von der SAP SE oder ihren

Konzernunternehmen jederzeit und ohne Angabe von Gründen unangekündigt geändert werden.

Die in dieser Publikation enthaltenen Informationen stellen keine Zusage, kein Versprechen und keine rechtliche Verpflichtung zur Lieferung von Material, Code oder

Funktionen dar. Sämtliche vorausschauenden Aussagen unterliegen unterschiedlichen Risiken und Unsicherheiten, durch die die tatsächlichen Ergebnisse von den

Erwartungen abweichen können. Die vorausschauenden Aussagen geben die Sicht zu dem Zeitpunkt wieder, zu dem sie getätigt wurden. Dem Leser wird empfohlen,

diesen Aussagen kein übertriebenes Vertrauen zu schenken und sich bei Kaufentscheidungen nicht auf sie zu stützen.

http://global.sap.com/corporate-de/legal/copyright/index.epx

Documents

Der Weg zu SAP BW auf HANA: Teil 2 Applikation€¦ · o Nur open SQL Kein Coding mit DB-spezifischer Syntax ... HANA werden BW Transformationen mehr und mehr als HANA-Prozeduren