S/4 Hana und SAP Adaptive Server Enterprise

Unternehmen, die für ihre SAP-Systeme bislang homogene Datenbanken von Anbietern wie Oracle oder IBM nutzen, drohen bei der Einführung von Hana oder SAP Business Suite 4 Hana (S/4 Hana) doppelte Lizenz- und Wartungskosten für ihre Datenbanken: Einerseits für Hana, andererseits für die der anderen Anbieter.

Dabei ist in der Hana Runtime Edition for Applications and SAP BW (REAB) bereits die Lizenz für ASE enthalten – eine alternative Datenbank für die verbleibenden Altsysteme wird sozusagen frei Haus mitgeliefert. Diese ist aufgrund ihrer Stabilität insbesondere im Finanzumfeld geschätzt und teils seit Jahrzehnten im Einsatz.

Zudem ist die Roadmap von SAP – im Gegensatz etwa für MaxDB – für sie klar und sie verfügt über eine sehr gute Kompression, was zu einem vergleichsweise geringen Platzbedarf führt. Ein Umstieg liegt somit auf der Hand. Doch bei der Migration auf ASE gilt es, einige Stolperfallen zu beachten.

Pro und Contra Migration auf ASE

Wie unsere Erfahrungen aus über 100 Migrationen und dem Betrieb von über 70 Kundensystemen zeigen, amortisieren sich die Kosten für die Migration auf ASE in der Regel aufgrund der dauerhaft nie­drigeren Lizenz- und Wartungskosten recht schnell.

Außerdem legt das Lizenzmodel der SAP dabei keine Hürden für die Virtualisierung der Datenbank in den Weg. Weitere Vorteile sind der Bezug von Anwendung und Datenbank aus einer Hand sowie deutliche Vorteile beim Platzbedarf etwa gegenüber MaxDB, die im Gegensatz zu ASE keine Datenkompression unterstützt.

Zudem sind keine aufwändigen Reorganisationen wie bei Oracle notwendig. Die eingebettete Administration erfolgt über das gängige DBA Cockpit, mit dem die meisten Administratoren vertraut sind.

Dem stehen meist zwingend erforderliche Investitionen in die IT-Infrastruktur entgegen, da ASE hardwareseitig deutlich mehr CPU-Ressourcen benötigt. Wie die Praxis zeigt, ist hier teilweise eine um mehrere hundert Prozent höhere Rechenleistung erforderlich.

Hinzu kommt, dass die Datenbank während der Vollsicherung ihr Log nicht leeren kann, sodass ein besonderes Augenmerk auf die Gestaltung des Backups zu legen ist.

Insgesamt überwiegen bei den meisten Unternehmen jedoch die Vorteile von ASE – insbesondere im Hinblick auf die dauerhaften Gesamtkosten.

Konzeption: Erfahrung ist gefragt

Aufgrund der spezifischen Hardware-Anforderungen gilt es trotz der gut dokumentierten Migrationsanleitungen, bereits in der Frühphase der Planung erfahrene Spezialisten hinzuzuziehen und sich strikt an die von SAP veröffentlichten Empfehlungen – etwa bei der Dimensionierung der Caches – zu halten.

Ein besonderes Augenmerk sollte dabei auch auf die Gestaltung des Backup-Konzepts gelegt werden. Bei Snapshot-basierten Backups hat dies idealerweise auf dem „prepare database mode“ zu basieren.

Er ist dem „quiesce mode“ vorzuziehen, da Letzterer die Datenbank nur in einen Read-only-Modus versetzt. Um Point-in-time Recovery zu ermöglichen, ist in der Konzeption darauf zu achten, dass Logs eigenständig wiederherstellbar sind.

Da die Datenbank während einer Vollsicherung ihre Logs nicht leeren kann, ist die Backup-Laufzeit ein kritischer Faktor: Solange die Sicherung läuft, werden die Änderungen in die Logs geschrieben.

Dauert das Backup zu lange, laufen die Logs über. Es empfiehlt sich daher, Backups in Zeiten geringer Belastung zu machen sowie den Logbereich ausreichend zu dimensionieren. Zusätzlich können füllgradgesteuerte Log­backups eingerichtet werden.

Auch sollten die Monitoring-Parameter strikt auf die SAP-spezifischen Anforderungen angepasst sein. Sind diese Voraussetzungen erfüllt, ermöglicht ASE sehr schnelle und erfahrungsgemäß problemlose Backups.

Knackpunkte bei der Administration

Mit SAP vertraute Administratoren können ASE über das gewohnte DBA Cockpit verwalten und überwachen. Typisch für die Datenbank sind jedoch sehr häufige Änderungen in den SAP-Hinweisen bezüglich der einzelnen Parameter.

Hervorzuheben ist dabei, dass rund 95 Prozent der ASE-Parameter online änderbar sind. Dies gilt selbst für den zu verwendenden Arbeitsspeicher (max_memory) und die CPU-Ressourcen (syb_default_pool). Diese Eigenschaft ermöglicht es – insbesondere im Zusammenspiel mit Virtualisierung –, die Ressourcen dynamisch an den wachsenden Bedarf anzupassen.

Für die Reduktion der Ressourcen ist, wie auch aus der Virtualisierung bekannt, ein Neustart erforderlich – dieser kann jedoch meist in ein geplantes Wartungsfenster gelegt werden.

Auch die Frequenz der Patches ist bei ASE vergleichsweise hoch, was einerseits einen gewissen Aufwand beim Einspielen bedeutet, jedoch auch zur Folge hat, dass Bug Fixes meist recht schnell erfolgen und neue Features rasch zur Verfügung stehen.

Für den Fall, dass die SAP-Systeme beziehungsweise das DBA-Cockpit ausfällt, fehlen auch die gewohnten Administrationstools für ASE. Dann lässt sich die Datenbank nur noch rein über iSQL verwalten.

Dies kann insbesondere kleinere IT-Abteilungen ohne Mitarbeiter mit entsprechenden iSQL-Kompetenzen vor Schwierigkeiten stellen.

Fazit

Insgesamt steht Unternehmen mit ASE eine Datenbank zur Verfügung, die – nicht zuletzt aufgrund der günstigen Lizenzsituation in Kombination mit S/4 Hana – eine sinnvolle Alternative zum Parallelbetrieb von Hana und Datenbanken von Drittanbietern ist.

Werden ein paar Schritte eingehalten (siehe Kasten), steht erfahrungsgemäß einer Migration auf ASE nichts entgegen. Dabei ist es unerheblich, ob der Betrieb im Unternehmen selbst oder von einem Dienstleister übernommen wird.

ASE-Migration: Klassische Vorgehensweise

• Lizenzberatung und ROI-Berechnung
• Architekturberatung: Infrastruktur und Feststellen von Release-Abhängigkeiten
• Bei Bedarf: Release Upgrade auf jeweils mindestens SAP Netwea- ver 7.0 (EHP 2), SAP ECC (EHP 5), SAP CRM (EHP 1) und SAP SRM (EHP 1)
• Technische Migration
• Bei Eigenbetrieb: Schulung der Administratoren – insbesondere, wenn keine iSQL-Kenntnisse vorhanden sind