Click here to load reader

SAP BW auf HANA - · PDF fileVORBEREITUNG DER UMSTELLUNG AUF HANA 36 Blog: Wie man ein BW-System nicht sized

  • View
    228

  • Download
    2

Embed Size (px)

Text of SAP BW auf HANA - · PDF fileVORBEREITUNG DER UMSTELLUNG AUF HANA 36 Blog: Wie man ein...

  • SAP BW auf HANA

    Frank Riesner Klaus-Peter Sauer

  • INHALTSVERZEICHNIS

    3

    Inhaltsverzeichnis

    Vorwort 7

    Danksagung 11

    1 Evolution und berblick 15

    1.1 Evolution von SAP HANA 15

    1.2 Evolution von BW 21

    1.3 BW auf HANA versus BWA 31

    2 Vorbereitung der Umstellung auf HANA 35

    2.1 Sizing 35

    2.2 Migrationsoptionen und untersttzende Werkzeuge 44

    2.3 Housekeeping 58

    2.4 Betrieb im Rechenzentrum 63

    2.5 Data Lifecycle Management 98

    3 nderungen bei der Datenbewirtschaftung 113

    3.1 Generisches BW-Delta 113

    3.2 DB Connect 115

    3.3 Operational Data Provisioning 116

    3.4 In-memory Data Fabric 129

    4 Modellierung in SAP BW auf HANA 135

    4.1 nderungen an bestehenden InfoProvidern 136

    4.2 SAP-HANA-Modellierung 163

    4.3 Neue InfoProvider 174

    4.4 Anwendungsszenarien 199

    4.5 SAP-BW-Optimierung durch HANA 223

  • INHALTSVERZEICHNIS

    4

    4.6 Berechtigungen 238

    4.7 Prozessketten 243

    4.8 Obsolete Modellierungsfunktionen 246

    5 SAP-BW-Referenzarchitektur 249

    5.1 Layered Scalable Architecture klassisch 250

    5.2 Layered Scalable Architecture auf HANA 254

    5.3 Umwandlung einer LSA in LSA++ 259

    6 SAP HANA Live 265

    6.1 Motivation und Ziele 265

    6.2 Virtuelles Datenmodell 268

    6.3 Werkzeuge 273

    6.4 SAP BW versus SAP Hana Live 279

    7 Zusammenfassung und Ausblick 283

    7.1 Wie Sie von BW auf HANA profitieren 283

    7.2 BW auf HANA im Vergleich zu anderen Datenbanken mit In-Memory-Funktionen 291

    7.3 BW Roadmap der Blick in die Zukunft 295

  • INHALTSVERZEICHNIS

    5

    Quellenverzeichnis 301

    Neue BW-Transaktionen 302

    A Die Autoren 306

    B Index 309

    C Disclaimer 314

    Weitere Bcher von Espresso Tutorials 315

  • 35

    2 Vorbereitung der Umstellung auf HANA

    Sptestens mit der Entscheidung, HANA als Datenbank fr Ihr

    Business Warehouse einzusetzen, sollten Sie Themen wie Sizing,

    Migration, Housekeeping, Rechenzentrumsbetrieb und Data Life-

    cycle Management von HANA als Datenbank fr Ihr BW-System in

    Angriff nehmen.

    Idealerweise haben Sie im Vorfeld der Entscheidung fr HANA schon

    ber diese Themen gesprochen. So ist etwa das Sizing nicht nur fr

    die Gre und Anzahl der bentigten Server magebend. Je nach

    Lizenzierungsmodell hat die Datenbankgre auch Einfluss auf die

    Lizenzkosten.

    Unabhngig vom Lizenzmodell sollten Sie die Themen wie House-

    keeping und Data Lifecycle Management als permanente Prozesse

    im Unternehmen etablieren. Dadurch knnen Systemtabellen schlank

    gehalten werden. Aktuelle und hufig verwendete Daten sollten im

    Hauptspeicher von HANA liegen, um schnellstmglich analysiert zu

    werden. Historische Daten, auf die nur noch selten zugegriffen wird,

    knnen Sie hingegen im Near-Line-Storage-Archiv kostengnstig

    ablegen.

    2.1 Sizing

    Das richtige Sizing des Datenbankservers fr HANA ist sehr wichtig,

    denn bereits hier knnen viele Fehler gemacht werden. Um das zu

    vermeiden, hat Marc Bernard einen sehr guten Blog mit den hufigs-

    ten Fehlern beim Sizing eines BWs auf HANA geschrieben.

  • VORBEREITUNG DER UMSTELLUNG AUF HANA

    36

    Blog: Wie man ein BW-System nicht sized

    http://scn.sap.com/community/netweaver-bw-hana/

    blog/2013/08/28/how-not-to-size-a-sap-netweaver-

    bw-system-for-sap-hana

    2.1.1 Sizing eines neuen BWs auf HANA

    Beim Sizing eines brandneuen Systems fr BW auf HANA sollte der

    Quicksizer eingesetzt werden (http://service.sap.com/quicksizer).

    Auch wenn es darum geht, die Applikationsserver richtig zu dimensi-

    onieren, finden Sie entsprechende Hilfestellung in diesem Tool.

    2.1.2 Sizing eines nicht-BW Data Warehouses fr BW auf HANA

    Angenommen, Sie haben ein bestehendes Data Warehouse, das

    nicht auf BW-Technologie basiert. Dieses System mchten Sie in ein

    BW auf HANA berfhren. Fr das Sizing gibt es zwei Mglichkeiten:

    1. Quicksizer (siehe voriger Abschnitt),

    2. manuelles Sizing.

    Fr die Berechnung des manuellen Sizings bentigen Sie den Quell-

    datenbestand sowie gegebenenfalls den Kompressionsfaktor (c)

    der Quelldatenbank. Falls die Datenbank keine Komprimierung nutzt,

    setzen Sie diesen Faktor c = 1. Die Berechnung erfolgt nach den

    Formeln in Abbildung 2.1.

    http://scn.sap.com/community/netweaver-bw-hana/blog/2013/08/28/how-not-to-size-a-sap-netweaver-%0bbw-system-for-sap-hanahttp://scn.sap.com/community/netweaver-bw-hana/blog/2013/08/28/how-not-to-size-a-sap-netweaver-%0bbw-system-for-sap-hanahttp://scn.sap.com/community/netweaver-bw-hana/blog/2013/08/28/how-not-to-size-a-sap-netweaver-%0bbw-system-for-sap-hanahttp://service.sap.com/quicksizer

  • VORBEREITUNG DER UMSTELLUNG AUF HANA

    37

    Abbildung 2.1: Formeln des manuellen Sizings

    HANA hlt die Daten primr im Hauptspeicher. Die Speicherung auf

    Festplatten wird lediglich zur Ausfallsicherheit bentigt. Bei Neustart

    des Systems knnen Sie so die Daten von der Persistenz gesichert

    wiederherstellen.

    Der Plattenplatz der Persistenz (DISKPersistenz) ist das bentigte Mini-

    mum, muss mindestens der Gre des Hauptspeichers (in etwa

    zweimal der Gre des Datenbestands) entsprechen und dient zur

    Sicherung der Savepoints. Bitte reservieren Sie nach Bedarf noch

    Platz fr Backups, Exports und andere Zwecke. Eine Daumenregel

    empfiehlt hier den vierfachen Platz des Random Access Memorys

    (RAM). Letztlich hngt es von Ihren Bedrfnissen ab.

    Fr den Log-Bereich (DISKLog) empfiehlt es sich ebenfalls, einen Plat-

    tenbereich entsprechend der Hauptspeichergre (einmal die Haupt-

    speichergre auf Platte) zu reservieren. Hier werden alle Informati-

    onen bzgl. Datenvernderungen mitprotokolliert und synchron auf

    Disk geschrieben, um bei einem Systemausfall Datenverluste zu

    vermeiden.

    Die vorangestellte Formel geht davon aus, dass sich in einem typi-

    schen BW-System etwa 60 GB der Daten im sogenannten Row Store

    befinden, also in dem Teil der Datenbank, der zeilenbasiert abgelegt

    wird. Diese werden vom Gesamtdatenbestand abgezogen, und der

    Rest wird spaltenbasiert in der Datenbank abgelegt.

  • VORBEREITUNG DER UMSTELLUNG AUF HANA

    38

    Der Komprimierungsgrad von Daten hngt sehr speziell davon ab,

    wie hufig sich Werte wiederholen und welchen Datentyp einzelne

    Spalten haben. Die Erfahrung hat gezeigt, dass im Durchschnitt etwa

    ein Komprimierungsfaktor von 4:1 zu erwarten ist. Dieser Wert wird

    mit dem Faktor zwei multipliziert, da Sie neben der reinen Ablage der

    Daten noch Platz im Hauptspeicher (RAM) bentigen, der fr dyna-

    mische Objekte im laufenden Betrieb gebraucht wird. Beispiele sind

    hier temporre Objekte, die zur Laufzeit von Berichten oder auch von

    Datenladungen erzeugt werden. Bercksichtigen Sie dies nicht, wird

    es im Betrieb zu erheblichen Problemen kommen.

    Sofern die Daten in der bestehenden Datenbank komprimiert sind,

    knnen Sie einen Komprimierungsfaktor c einbeziehen.

    Im letzten Teil der Formel werden noch 90 GB bercksichtigt, die

    typischerweise nicht spaltenweise in der Datenbank abgelegt werden.

    Dazu zhlen

    40 GB an Systemdaten (Data Dictionary, Housekeeping

    Tabellen etc.),

    40 GB an Caches,

    und ca. 10 GB an zustzlichen HANA-Komponenten, wie

    z. B. der Name-Server oder der Statistik-Server.

    In Summe ergibt das 90 GB.

    Soweit zur Erklrung der Formel; doch wie kommen Sie jetzt zum Quelldatenbestand?

    Das wird detailliert im zuvor genannten Blog von Marc Bernard be-

    schrieben. Sie gehen von Ihrer bestehenden Datenbankgre aus

    und ziehen den freien Platz, das Log und die Datenbankindizes ab.

    Auf Aggregate knnen Sie ebenfalls verzichten.

    Haben Sie die Daten komprimiert abgelegt, so knnen Sie den

    durchschnittlichen Komprimierungsfaktor ber den Parameter c in

    der Formel bercksichtigen.

  • VORBEREITUNG DER UMSTELLUNG AUF HANA

    39

    Manuelles Sizing

    Sie planen, ein MS-SQL-basiertes Data Warehouse

    mit einer Datenbankgre von 600 GB (ohne Indizes,

    Log und Aggregate) in ein BW auf HANA zu ber-

    fhren. Derzeit setzen sie keine Komprimierung ein.

    RAM = (600 GB 60 GB) * 2 / 4 * 1 + 90 GB = 360 GB

    Was Sie wissen sollten

    Eine wichtige Voraussetzung fr diese Formel sind

    vergleichbare Datenmodelle. Wenn Sie zum Beispiel

    im BW planen, die Daten mehrfach persistent abzu-

    legen, dies aber in ihrem heutigen System nicht tun,

    dann sollten Sie das in Ihre berlegungen miteinbe-

    ziehen, denn sonst besteht die Gefahr, dass Sie das System zu

    klein dimensionieren.

    Das Gleiche gilt auch im umgekehrten Fall, d. h., wenn Sie das

    Datenmodell und die vorhandenen Redundanzen auflsen, dann

    bentigen Sie weniger Platz im knftigen BW-System. Im Verlauf

    des Buches zeigen wir Ihnen, wie Sie Datenschichten virtualisie-

    ren knnen, denn hierzu gibt es speziell mit BW auf HANA neue

    Mglichkeiten.

    Einige Datentabellen mssen Sie nicht permanent im Hauptspeicher

    vorhalten. Hierzu gehren beispielsweise die Persistent Staging Area

    (PSA) oder schreiboptimierte DataStore-Objekte (write-optimized

    DSO). Diese knnen Sie mit einem niedrigeren Wert gewichten, denn

    hier greift bei BW auf HANA die Logik der nicht aktiven Daten (sie

Search related