SAP HANA – Aktuelle Migrations- und Implementierungsszenarien

(Last Updated On: 17. Juni 2016)

SAP fährt derzeit eine sehr aggressive Produktpolitik im Bezug auf HANA. Und auch, wenn HANA grundsätzlich kein Wufffffnderkind ist und durchaus nicht ohne Konkurrenz auf dem markt steht – das Konzept ist schlüssig – und die Möglichkeiten für den Endanwender vielversprechend.

Aktuelle SAP HANA Business Cases

die Gründe, warum immer mehr SAP-Kunden auf HANA wechseln, sind vielschichtig. Viele Kunden wollen auf der Höhe der Zeit stehen und nicht den Aufsprung auf die aktuelle SAP-Produktpalette verpassen. Strategien, welche die Produkte SAP BW on HANA, CRM on HANA, Simple Finance 2.0 und letztendlich auch S/4HANA beinhalten, sind ohne HANA gar nicht mehr möglich. Und eine solche Strategie hat auch seine Vorteile. Das neue Datenmodell unter Simple Finance 2.0 verschlankt das Datenvolumen von SAP ERP enorm, und CRM on HANA verspricht einen enormen Performancegewinn, der in Zukunft ein essentieller Treiber für zeitgemäße Analysen im Bereich der Customer Segmentation sein wird.

Aber auch die SAP-Produktpolitik ist in an dieser Stelle sehr fordernd. Das Fiori Gateway für S/4HANA muss schon jetzt erzwungenermaßen auf einer drei SAP Datenbanken MaxDB, SAP ASE oder SAP HANA laufen.

Wer SAP HANA einführt, sollte sich grundsätzlich Gedanken über das gesamte SAP Data Management-Produktportfolio machen. mit dem SAP Event Stream Processor können Sie mit einem kompetenten Entwiclkungsteam permanente Informations-Ströme (beispielsweise von den Sensoren der Windkraftanlagen eines Windparks) filtern und verarbeiten. Die gefilterten Daten können dann in einer SAP HANA Datenbank persistiert und von dort aus auf lokale SQL Anywhere-Datenbanken geladen werden, die es den Entscheidungsträgern ermöglichen, die aktuell für sie relevanten Daten von ihren Mobilgeräten aus einzusehen.

SAP Solution Manager als erstes HANA-Einführungsprojekt

Wer sich noch unsicher über sein Commitment auf eine HANA-Landschaft ist, dem sei an dieser stelle empfohlen, als erstes ein Migrationsprojekt auf den SAP Solution Manager on HANA zu versuchen. Das Projekt hat den Vorteil, dass keine zusätzlichen Lizenzkosten anfallen, denn eine HANA-Datenbank unter dem Solution Manager ist kostenlos. Eine Migration des SAP Solution Managers als initiales Umstellungsprojekt der HANA Landschaft hat diverse Vorteile. Das Datenvolumen der Solution Manager Datenbank ist erfahrungsgemäß kleiner als bei NetWeaver BW- oder Business Suite-Systemen. So kann man mit einem schlank budgetierten Einführungsprojekt erste Erfahrungswerte mit SAP-Applikationssystemen unter SAP HANA sammeln, ohne zunächst einen allzu großen Einflussfaktor in bestehende IT-Geschäftsprozesse befürchten zu müssen.

Typische HANA-Projektherausforderungen

Mit diesen müssen Sie  bei umfangreicheren Umstellungsprojekten – sie es nun im Rahmen der SAP Business Suite, SAP BW oder S/4HANA – immer rechnen. Neben HANA-spezifischer Anpassungen Ihrer Customer Enhancements und Ihres Codings, um von den Vorteilen SAP HANA In-Memory Computing Engine Gebrauch machen und Ihr Customizing auf das neue Release trimmen zu können, müssen Sie sich auch wieder Gedanken über all die Themen machen, die Sie in ihren bisherigen Applikationssystemen eigentlich schon geklärt hatten. Hochverfügbarkeitskonzept, Security-Konfiguration, Schulung der Mitarbeiter und Administratoren, Ausarbeitung eines Backup & Recoverykonzeptes – all diese Themen kommen auch bei einer Umstellung auf SAP HANA wieder hoch.

Zusätzlich erfolgt mit jeder Einführung eines SAP-Produkts on HANA bestenfalls eine Verschlankung Ihrer Produkt- und Systemlandschaft. Mit der Einführung von S/4HANA bietet es sich beispielsweise an, die Anzahl an ERP-Systemen in der Unternehmenslandschaft zu reduzieren. Mehrere Regionen, die zuvor durch unterschiedliche ERP-Systeme angebunden wurden, werden nun zusammengefasst. Möglicht macht dies das neue Datenmodell und die Auslagerung des operationalen Reportings von in das Fiori Frontend. Dadurch sinkt gleichzeitig die Anzahl der notwendigen OLAP-Systeme. Die Techniken der System Landscape Transformation, der SAP HANA System Replication und des SAP Replication Servers ermöglichen eine solche Zusammenfassung unter geringem Ressourcen- und Zeitaufwand. Zudem wird mit SAP BW on HANA der BW-A (Business Warehouse Accelerator) abgelöst, was ebenfalls zur Einsparung von Systemen in der Unternehmenslandschaft führen kann. Und die S/4HANA Search Engine wird auf vielen Ebenen den Einsatz der TREX Search Engine obsolet machen.

Doch machen wir uns nichts vor: SAP HANA Einführungsprojekte sind nicht einfach, sondern aufwändig – und erfordern viel fachmännisches Know-How. Wenn Sie HANA großflächig in Ihrer Unternehmenslandschaft einführen wollen, brauchen Sie kompetente Partner – und eine effiziente Strategie.

Database Migration Option

An erster Stelle bei einer Migration bestehender SAP-Systeme steht immer die Frage nach der technischen Umsetzung der Migration. Die Database Migration Option (DMO) des Software Update Managers ermöglicht das Upgrade bestehender Applikationssysteme auf einen aktuellen Release inklusive Migration auf die SAP HANA Datenbank innerhalb einer einzigen Downtime. Für den Kunden bedeutet dies eine verringerte Ausfallzeit seiner SAP-Applikationssysteme und somit eine verbesserte Business Continuity. Die beschleunigte Durchführung der Downtime führt außerdem zu einem geringeren Ressourcenaufwnad innerhalb eines Migrationsprojektes. Somit ist ein Umzug der SAP-Landschaft auf HANA so kostengünstig wie noch nie.

Die Database Migration Option alleine hält bereits sehr viele Herausforderungen parat, da mit dieser Option in der Regel große Releasesprünge überwunden werden und gleichzeitig ein Umzug auf eine neue Datenbank erfolgt. Das Durchführende Team benötigt hierzu Wissen im Umgang mit der Quelldatenbank und der Zieldatenbank (in diesem Fall SAP HANA) sowie über Quell- und Zielrelease des Applikationssystems (beispielsweise ERP, CRM oder BW).

Storage-Integration

Bereits vor der DMO muss die Zieldatenbank, also SAP HANA, ordnungsgemäß installiert sein. Dabei macht es Sinn, das System bereits abgabefertig zu konfigurieren. Dazu gehört unter Anderem die Implementierung einer Backup- und Recoverystrategie. Mit Hilfe der SAP HANA Storage Connector API können Sie SAP HANA an Drittanbieter-Storagelösungen wie NetApp bzw. Backup-Tools wie CommVault anbinden. Achten Sie hierbei darauf, nur zertifizierte Drittanbieterlösungen, welche die backint Certification for SAP HANA bestanden haben, zu nutzen.

Optimierung der DMO Downtime

Und auch wenn die Database Migration Option (DMO) an sich bereits eine verringerte Downtime im Vergleich zur herkömmlichen 2-step-methode (Upgrade und anschließende Systemkopie) verspricht, so gilt es dennoch die Downtime der DMO an die Wünsche des Kunden weiter anzupassen. Mit detaillierter Feinanalyse der zu verwendenden Upgradeparameter und der Zuhilfenahme mehrerer R3*-Server kann die Downtime des Upgrades noch weiter reduziet werden.

SAP HANA Table Placement

Desweiteren ist es bereits vor dem Upgrade notwendig, das SAP HANA Table Placement und die Partitionierung der Data Volumes zu planen. Betreiben Sie eine HANA Scale-Out Landschaft, bei denen sich mehrere SAP HANA Knoten in einem Aktiv/Aktiv-Cluster die Last teilen, müssen Sie entscheiden, welche Hosts für welche Datenbankobjekte zuständig sind – und auf welchen Datenträgern diese Datenbankobjekte liegen müssen. Nur mit einem durchdachten Konzept erhält ihre HANA-Landschaft nach dem Umzug die gewünschte Performnace. dies stellt hohe Anforderungen an die SAP Basis, da hierbei ein hohes architektonisches Hintergrundwissen im Bezug auf die planung von Storage-Systemen vorausgesetzt wird. Neben dem passenden Tiering (verteilen von Daten auf Datenträger verschiedener Leistungsfähigkeit abhängig von der häufigkeit ihrer Selektion), Striping (Bündelüng von I/O-Performance mehrerer Datenträger für bestimmte Speicherbereiche) und der Konfiguration und planung der ausfallsicherheit des Speichers müssen hierbei auch immer die Kosten im Auge behalten werden.

SAP HANA Scale-Up vs. Scale-Out

Desweiteren steht die Frage im Raum, ob Sie für Ihren Applikationsserver nur einen aktiven SAP HANA Server betrieben sollen (Scale-Up) oder mehrere Server in einem Aktiv/Aktiv-Clusterverbund (Scale-Out). Grundsätzlich ist es eine gute Idee, so lange wie möglich auf Scale-Up zu setzen. Denn dadurch sparen Sie sich nicht nur unnötige Verwaltungs- und Administrationskosten, sondern auch eine Performanceeinbuße durch den Overhead an I/O-Kommunikation zwischen den Scale-Out-Knoten. Für jede HANA Appliance oder jeden HANA Host im Allgemeinen gibt es eine bestimmte Empfehlung über das Verhältnis zwischen installiertem Hauptspeicher und Anzahl an CPU-Kernen. Dieses Verhältnis, die sogenannte RAM/CPU-Ratio, liegt beispielsweise bei Business suite Produkten bei einem WErt von 96 GB pro CPU-Kern. Wenn Sie sich den Markt an verfügbaren SAP HANA Appliances bzw. SAP HANA Mainframes ansehen, kommen Sie zum Schluss, dass die größten SAP HANA Appliances in diesem Verhältnis eine Hauptspeicherkapazität von entweder 2 TB oder 6 TB leisten können. Größere Scale-Up-Modelle sind regelrechte Mainframes und in Größenordnungen von 24 und 32 TB zu haben.Die Bereiche dazwischen (3-5 TB, 6-23 TB, 25-31 TB)  sind diejenigen, in denen Scale-Out empfehlenswert ist. Da das Scale-Up-Szenario meistens das zu bevorzugende Szenario ist, sollten Unternehmen versuchen, Ihr Datenvolumen auf SAP HANA zu verringern, um im Scale-Up Szenario bleiben zu können. Mögliche Maßnahmen hierzu sind

  • das Upgrade auf SAP Simple Finance 2.0, da sich hierbei das Datenmodell ändert. SAP Simple Finance 2.0 setzt auf die I/O-Power der in-Memory Datenbank SAP HANA und liefert immer mehr Systeminformationen als aggregierte SQL-Views aus anstelle von ausdefinierten Tabellen, in denen ansonsten Daten persistiert werdne. Mehr und mehr Daten werden also on-the-fly aggregiert anstatt fest auf dem Sekundärspeicher hinterlegt, was Speicherkapazität spart.
  • Das Auslagern auf andere Datenbanken. Sofern Sie noch Produkte im Einsatz haben, deren Release das Suffix „on HANA“ nicht zwingend voraussetzt, sollten Sie diese Daten bevorzugt je nach Datenmodell in eine zeilenorientierte Datenbank (OLTP-Applikation) oder in eine spaltenorineiterte Datenbank (OLAP-Applikation) persistieren. Die Daten können dann immer noch zur Analyse über SAP HANA Smart Data Access von diesen Systemen zu fest definierten Zeitpunkten (bspw. monatlich) abgerufen werden, um sie in die Analyse einzubeziehen. Wenn Sie Ihre IT bisher noch nicht stark auf ein Datenbankmanagementsystem ausgerichtet haben, ist es auch hier naheliegend bei SAP-Datenbanken zu bleiben. So könnten Sie beispielsweise für eine zeilenorientierte Datenablage in OLTP-Systemen SAP ASE verwenden und für eine spaltenorientierte Ablage in OLAP-Anwendungen Sybase iQ. Wenn Ihr Unternehmen jedoch aufgrund der bisherigen IT-STrategie außerhalb Ihrer SAP-Applikationen bevorzugt andere Datenbankmanagementsysteme einsetzt, beispielsweise Oracle 12c oder MS SQL 2012, so spricht auch gegen diese Lösungen nichts.
  • Einsatz von SAP HANA Dynamic Tiering und iQ Near Line Storage. Hierbei lagern Sie weniger häufig selektierte Datenbankobjekte von SAP HANA auf einen Warm Storage (Dynamic Tiering) bzw. Cold Storage (iQ NLS) aus. Dieser Warm bzw. Cold Storage wird unter gar keinen Umständen im Hauptspeicher der SAP-HANA Datenbank nachgeladen und hat somit zur Folge, dass Sie für diese Daten keinen weiteren Hauptspeicher benötigen. Daher zählt der Speicher, den Sie über SAP HANA Dynamic Tiering ausgelagert haben, nicht in das Datenvolumen hinein, welches Sie im Form von Hauptspeicher vorhalten können müssen. Daher können Sie länger im Scale-Up Szenario bleiben.
  • Setzen Sie eine HANA Revision neuer als SPS 90 ein. Diese unterstützt bereits inverted Indizes und kann daher noch einmal das Datenvolumen Ihrer HANA-Lösung in vielen Szenarien erheblich reduzieren.

Dual Stack Split

Wenn Sie desweiteren vor haben, auf SAP Solution Manager on HANA oder SAP CRM on HANA zu wechseln, kann es womöglich sein, dass Sie Ihr bestehendes Dual Stack-System splitten müssen, da im neuen Release nur noch zwie Standalone NetWeaver Stacks (ABAP und Java) unterstützt werden. Bei CRM kann der Stack Split vor der Database Migraton Option durchgeführt werden, beim SAP Solution Manager hingegen muss der klassische Weg gegangen werden – bestehend aus Upgrade -> Dual Stack Split -> Heterogene Systemkopie.

Sandbox-Lauf

Bevor Sie zum ersten mal eine Database Migration Option an einem Entiwcklungssystem vornehmen, sollten Sie vorher einen Sandbox-Lauf durchgeführt haben. dieser stellt sich, dass möglichst viele Fehler, die während der DMO auftauchen können, identifiziert und im Vorfeld gelöst werden, so dass das Upgrade in der Produktivlandschaft reibungsloser von statten geht. Ohne einen Sandboxlauf können äußere Umstände wie etwa die Notwendigkeit der Einschaltung des SAP-Supports, nicht im Vorfeld erkannte Softwarekonflikte oder fehlendes internes know-How zum Showstopper werden und den Projekterfolg gefährden. Desweiteren dient der Sandboxlauf bereits zur Einschätzung und Optimierung der System-Downtime.

Notfall-Entwicklungssystem

In diesem Zug sollten Sie sich auch Gedanken machen, ob Sie nicht für die Zeit des Upgrades Ihrer Drei-System-Landschaft ein zweites Notfall-Entwicklungssystem aufbauen wollen. Dieses dient als Entwicklungssystem für Notfallentwicklungen, wenn sich Ihr ursprüngliches Entwicklungsssystem bereits auf dem neuen Release befindet, die anderen Systeme jedoch unter Umständen noch im Quellrelease stecken.

Recovery Sandbox

Während der Database Migration Option müssen Sie den aktuellen Stand des Upgrades an mehreren Stellen sichern. Dabei macht es Sinn, die Upgrade-Prozedur nur dann fortzusetzen, wenn man vorher sichergestellt hat, dass man von diesem Backup sauber restoren kann. Grundsätzlich sind zwar Konsistenzchecks auf das Backup, z. B. über das Binary-Tool hdbbackupdiag für die Sicherung der HANA-Zieldatenbank ein guter Indikator. Sicherheit hat man aber erst dann, wenn es einem gelingt, die Datenbanken wiederherzustellen. Da es unnötige Risiken mit sich bringt, das eventuell inkonsistente Backup auf der selben Datenbank zurückzuspielen, auf dem Sie gerade das Upgrade laufen haben, sollten Sie auf einem ausgelagerten System eine Dummy-Quelldatenbank (z. B. Oracle) und eine Dummy-Zieldatenbank (HANA) erstellen, auf welcher sie die Backups testen können.

Stellen Sie außerdem bei jedem Backup sicher, dass die SCN der Datenbank identisch ist mit der SCN des Backups zu diesem Zeitpunkt.

UTC Zeitumstellung

Eine HANA Migration bietet außerdem die Möglichkeit, zeitgleich viele andere sinnvollen Maßnahmen auf diesen Zeitraum zu legen. Wenn Sie beispielsweise darüber nachdenken sollten, Ihre SAP-Systeme auf UTC umzustellen, damit in Ihren SAP-Systemen die inneren Uhren und damit eingeplante Jobs ungestört von Zeitumstellungen ticken, dann liese sich eine solche Umstellung wunderbar mit der Migration vereinen. Die Auswirkungen der Umstellung können dann in den Tests mit ausgewertet und im Zuge der Qualitätssicherung angegangen werden.

Netzwerkarchitektur

Desweiteren empfiehlt es sich, spätestens mit der Migration auf SAP HANA eine mehrstufige Netzwerkarchitektur aufzusetzen. Wenn bisher Ihre Applikationsserver sich über das gleiche Netzwerksegment unterhalten haben wie die User, macht es vielleicht Sinn, im Zuge der Migration über eine Trennung in Frontend- und Backend-Netz in Erwägung zu ziehen. Dadurch können Sie nicht nur die Performance der Netze besser im Griff behalten, Sie fügen auch noch einen zusätzlichen Sicherheits-Layer in Ihre Landschaft hinzu.

SAP HANA Security Configuration

Da wir gerade von Sicherheits sprachen: Wenn Sie eine vorinstallierte HANA Appliance beziehen, sollten Sie unbedingt die mit dem System ausgelieferten Schlüsselpaare neu generieren. Denn diese Schlüsselpaare sind auf allen Standardauslieferungen der HANA Appliance gleich, was Sie angreifbar macht. Dabei macht es Sinn, sich grundsätzlich gleich vor der Migration Gedanken überdie Sicherheitskonfiguration und das Hardening der SAP HANA Zieldatenbank Gedanken zu machen.

(POWER) – Linux

Einge Migration auf SAP HANA bringt mitunter einiges an Veränderungen in Ihre IT-Abteilung. Hatten Sie es beispielsweise bisher ausschließlich mit einer Windows-Server- oder Unix-Umgebung zu tun, müssen Sie sich spätestens jetzt mit einem Enterprise-Linux wie SLES oder RHEL auseinandersetzen. Damit Ihre Fachkräfte nicht das Gefühl haben, wieder von vorne anfangen zu müssen, sollten Sie das Projekt nutzen, um das nötige Basis-Wissen aufzubauen. Grundsätzlich ist dies keine schlechte Strategie, da sich Linux mittlerweile auf jedem Sektor breit gemacht hat. Eine investition in Linux-Know How wird Ihre IT nur noch stärker machen. Und dank PowerLinux müssen Sie sich auch in einer IBM Power-Landschaft keine Sorgen darum machen. Das einzige was Sie brauchen ist das notwendige Know How, um ein PowerLinux als LPAR zu betreiben.

SuSE Linux und Red Hat Enterprise Linux for SAP Applications

Wo wir schon beim Betriebssystem sind: Für die meisten SAP-Anwendungsszenarien brauchen Sie meist eine spezielle Version einer Enterprise-Linux-Distribution. Sie sollten beispielsweise nicht die Standardauslieferung von SuSE Linux Enterprise Server nehmen, sondern die Auslieferung SuSE Linux Enterprise Server for SAP Applications. Dieses Produkt liefert ein Mehr an Softwarepaketen mit, darunter das sapconf-Paket und den SAP HANA Resource Agent, mit dem vollautomatische Takeover-Prozesse in HA-Szenarien möglich werden. Genau so verhält es sich mit Red Hat Enterprise Linux for SAP.

SAP HANA Appliance vs Tailored Data Center Integration (TDI)

Auf welcher Hardwareplattform sollen Sie denn jetzt letztendlich Ihre HANA-Systeme betreiben? Für Kunden, die Ihre HANA-Systeme in einer abgeschotteten Umgebung haben wollen empfiehlt sich hierzu die Anschaffung einer SAP HANA Appliance. Diese sind häufig intel-basiert. Grundsätzlich gibt es allerdings auch die Möglichkeit der sogenannten SAP HANA Tailored DataCenter Integration.  Dieses Szenario richtet sich an Kunden mit exzellentem Know How im Betrieb eigenere Rechenzentren. Der Kunde profitiert in diesem Fall von den Synergieeffekten, die sich für ihn ergeben, wenn die SAP HANA Systeme auf seiner eigenen Hardware betreiben kann. So sind beispielsweise viele IBM POWER 8 Systeme für SAP HANA zertifiziert. Dies bedeutet, dass der Kunde auf seiner IBM Power-Hardware neben anderen IT-Services und Applikationsservern auch seine SAP HANA Installationen betrieben kann. Somit spart er sich die Anschaffung und Wartung einer gesonderten Appliance und profitiert von allen Vorteilen seiner bestehenden Landschaft, wie etwa die Virtualisierung unter IBM PowerVM. SAP HANA TDI bietet sich also an, wenn Sie selbst eigene Rechenzentren betreiben und Ihre Server-Hardware derzeit auf IBM POWER 8 oder intel E5/E7 basiert.

Bei SAP HANA TDI sind Sie für die Systemarchitektur selbst verantwortlich. Damit Sie hier nichts falsch machen, empfiehlt es sich, einen zertifizierten Beratungspartner mit Erfahrung in der Implementierung von SAP HANA in einem TDI-Szenario hinzuzuholen. Dieser sorgt dafür, dass alle ausgewählten Lösungen, also Serverhardware, Storage-Systeme, Virtualisierungslösungen, Backup-Tools zertifiziert sind und die minimalen Performance-Schwellenwerte bei der Implementierung erfüllt werden.

Virtualisierung

Haben Sie sich einmal für eine passende Hardwareplattform entschieden, bestimmt dies auch häufig die einzusetzende Virtualisierungslösung mit. Kunden auf Intel neigen meistens dazu VMWare vSphere zu nutzen, während IBM POWER-Umgebungen IBM PowerVM einsetzen. Einen Partner zu finden, der über Know-How-Ressourcen in diesem Umfeld verfügt, ist häufig schwer zu finden.

SAP HANA System Replication

Ein wichtiger strategischer Punkt ist die Konzeption eines Hochverfügbarkeitsszenarios. Denn aufgrund des in-Memory Charaketers von SAP HANA reicht es für Ihne Business Continuity nicht immer, wenn Sie klassische Hochverfügbarkeitslösungen auf Virtualisierungsebene wie beispielsweise PowerVM oder VMWare HA einsetzen oder beispielsweise einfach nur den Storage der Datenbank über zwei Storage-Systeme hinweg spiegeln. Sie hätten zwar auch die Möglichkeit, über das sogenannte SAP HANA Host-AutoFailover einfach einen Passiv-Knoten bereitzuhalten, der jederzeit für einen ausgefallenen SAP HANA-Knoten einspringen könnte, doch auch diese Lösung hat das selbe Problem: Nach einem TakeOver müssen die zuvor geladenen Daten, die im Hauptspeicher des gerade ausgefallenen Systems vorrätig waren, erneut aus dem Sekundärspeicher nachgeladen werden. Dies führt in der Praxis dazu, dass Ihre SAP HANA Datenbank nach einem Takeover durch einen Sekundärknoten für eine längere Zeit nicht mit der vollen Leistungsfähigkeit arbeiten kann. Nur mit der SAP HANA System Replication haben Sie einen Takeover-Mechanismus, bei welchem der Sekundärknoten in regelmäßigen Abständen die aktuellen Daten des Primärknotens ebenfalls in seinem Hauptspeicher nachlädt. So kann Ihr System bei einem Failover ohne nennenswerte Performanceeinbußen weiterarbeiten.

Wenn Sie sich für die SAP HANA System Replication entscheiden, haben Sie die Wahl zwischen verschiedenen Replikationsmodi. Um ein Urteil darüber fällen zu können, welcher Replikationsmodus für Sie am besten ist, gilt es drei entscheidende Größen zu betrachten.

  • Recovery Time Objective. Die Zeit, die vergehen darf, bis nach dem Ausfall des Primärknotens der Sekundärknoten die Systemanfragen ohne Performanceeinbußen übernehmen kann.
  • Recovery Period Objective. Der maximale Datenverlust gemessen an geleisteter operativer Arbeitszeit am System, die beim Ausfall des Primärknotens eintreten darf
  • Transaction Time. Sie bestimmt, wie lange es dauert, bis eine 4 KB große Änderung an der Datenbank persistiert und als Transaktion abgeschlossen werden kann. Dies bestimmt dadurch die Performance der Datenbank bei sämtlichen Schreibvorgängen.

Housekeeping

Zu jeder guten SAP HANA Migration gehört auch ein passendes Housekeeping. Konsistenzchecks auf Datenbank,  Backups und Binaries gehören hier genau so dazu wie die Konfiguration von Monitoring, Alerting, regelmäßigen Performancemessungen und einem Tuning gemäß der aktuellen Release-Notes.

Zur Performancemessung bieten sich neben applikationsspezifischen Tests desweiteren der SAP HANA Stress Test an.

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren …

2 Antworten

  1. 19. Juni 2017

    […] die SAP HANA System Replication nutzen Sie, wenn Sie transaktionsorientierte Datenreplikation brauchen, Quell- und Zielsystem jedoch beiderseits eine SAP HANA-Instanz ist. Das heißt während beim SAP Replication Server das Quellsystem in der Regel eine AnyDB ist, binden sie in der SAP HANA System Replication als Quellsystem ebenfalls eine SAP HANA Datenbank an. Die SAP HANA System Replication hat im Gegensatz zum SAP Replication Server den Vorteil, dass Sie auf die HANA-to-HANA Übertragung optimiert ist und neben den bloßen Daten auch noch beispielsweise die Systemkonfiguration, HANA-Datenbankbenutzer und andere HANA-Objekte wie Calculation Views etc. replizieren kann. Wenn Sie mehr über die SAP HANA System Replication erfahren wollen, lesen Sie meinen Beitrag zu SAP HANA Tailored Data Center Integration (SDI). […]

  2. 3. Juli 2017

    […] Nicht nur das: in Zukunft können Sie den Secondary entsprechend auch für die Abfrage von Daten für Analysen benutzen, um den Primary zu schonen. Somit ist in gewissem Maße ein gewisser Lastausgleich beim Bearbeiten von Schreib- und Lesezugriffen möglich. Für mehr Infos über die SAP HANA System Replication lesen Sie meinen Blog-Beitrag. […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.