SAP HANA

Der Weg zu SAP BW auf HANA:
Teil 2 – Applikation
Frank Riesner, Solution Architect, SAP (Schweiz) AG
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“)
© 2015 SAP SE. All rights reserved.
Public
30
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. All rights reserved.
Public
31
Prio 1: Verstehen Sie den „Delta Merge“!
Spaltenbasierte Tabelle
Schreiben
SAP HANA
Hauptspeicher
MainStorage
Delta-Storage
Delta Merge
 Main-Storage:
Spaltenbasiert (sortiert), dadurch leseoptimiert
 Delta-Storage:
Spaltenbasiert (unsortiert) oder zeilenbasiert, dadurch schreiboptimiert
Lesen
Im Datentransfer-Prozess
•
In Prozesskette
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
© 2015 SAP SE. All rights reserved.
Public
32
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 InfoProvider
Werden 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 InfoProvider
Werden 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
© 2015 SAP SE. All rights reserved.
Public
33
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
© 2015 SAP SE. All rights reserved.
Public
34
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.
© 2015 SAP SE. All rights reserved.
Public
35
Prio 2: Passen Sie Prozessketten an!
Obsolete Verarbeitungsschritte
SAP BW auf anyDB
•
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
SAP BW auf HANA
© 2015 SAP SE. All rights reserved.
Public
36
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.
© 2015 SAP SE. All rights reserved.
Public
37
Hauptvorteile von BW auf SAP HANA
BW Applikationsserver (ABAP)
Gesamte Verarbeitungslogik
Massiver
Datentransfer
Klassische Datenbank
BW Applikationsserver (ABAP)
Verbliebene Verarbeitungslogik
Reduzierter
Datentransfer
(nur Ergebnisse)
SAP
HANA
Datenintensive
Verarbeitungen
»Code-Push-Down«
HANA-optimierte Datenverarbeitungsabläufe in SAP BW
© 2015 SAP SE. All rights reserved.
Public
38
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.
© 2015 SAP SE. All rights reserved.
Public
39
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.
•
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 ABAPProgrammen). 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
Datentransfer-Prozess
• Umsetzung: In Transformationsregel und DTP
© 2015 SAP SE. All rights reserved.
Public
40
Prio 3: Evaluieren Sie Query-Ausführungsmodi!
•
In BW auf HANA existieren verschiedene Ausführungmodi für BEx-Queries
o
o
o
o
Mode “0”
Mode “2”
Mode “3”
Mode “6”
– Nicht optimierte Verarbeitung in HANA
– Individuelle Verarbeitung pro InfoProvider
– Optimierte Verarbeitung (Standard bis BW 7.4 SP07)
– 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.
© 2015 SAP SE. All rights reserved.
Public
41
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
© 2015 SAP SE. All rights reserved.
Public
42
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. All rights reserved.
Public
43
© 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.
© 2015 SAP SE. All rights reserved.
Public
99