SAP Hana – das Patchmonster
Schaut man sich die Patchzyklen der marktrelevanten Datenbanken und demzufolge den Hana-Wettbewerb an, so ergibt sich auf Monatsbasis ein interessantes Bild. Auch den Herstellern anderer Datenbanken passieren Fehler („zurückgezogene Releases“), sodass die geplanten Release-Zyklen nicht wie geplant eingehalten werden können.
Bei SAP kann man zwar nicht von geplant ausgehen, aber die Vergangenheit bestätigt die Zahl der zurückgezogenen Releases. Eine derartig hohe Taktung hat keine andere dieser DBs.
Optimistisch kann man sagen: „Die Hana-Entwicklung schreitet rasant voran.“ Die meisten Beobachter und Anwender kommen aber zu dem Schluss, dass es in der Vergangenheit zu viele Fehler gab, die nicht auf neue Funktionen zurückzuführen sind.
Laut SAP werden in den sogenannten Maintenance-Revisionen nur Fehler behoben und keine neuen Features aktiviert. Erhöht sich hier die Schlagzahl derartiger Maintenance-Versionen, macht dies die mangelnde Qualität der Software sichtbar. 
Dies ist insbesondere bei SPS12 deutlich zu erkennen. Dies haben auch einige Kunden bestätigt und die Vertreter der SAP haben diesen Kritikpunkt verstanden und angenommen. Seit den letzten Revisionen (deutlich ab 122.09) sind die Fehler enorm zurückgegangen.
In der Grafik, die aus mehr als 400 der offiziellen SAP-Hinweise entstanden ist, erkennt man deutlich, wie viele Fehler in einer Hana-Revision enthalten sind und, wesentlich dramatischer, dass für rund 35 Prozent davon kein Workaround vorhanden ist oder angeboten wird!
Je nach Gewichtung des Bugs muss dann auf die nächsthöhere Revision ausgewichen werden. Viele Kunden bemängeln genau dieses Verhalten, da sie von einem Fehler in den nächsten laufen. Dies bedeutet einen enormen internen Administrations- und Testaufwand.
Der zeitliche Aspekt ist gerade für die größeren Unternehmen, die im Normalfall nur ein bis zwei Releases im Jahr produktiv setzen, ein riesiges Problem. Hier muss man allerdings zwischen geplanten (neue Features, Performanceverbesserungen, Supportende oder Abhängigkeiten zum SAP-Release) und ungeplanten Wartungen (Stabilitätsprobleme, falsche Ergebnisse, Konsistenzprobleme, fehlerhafte Funktionalitäten) differenzieren.
Im Durchschnitt benötigt man zwischen mindestens drei und i. d. R. sechs Wochen, um für eine neue Datenbankversion alle Regressions-, Backup-, Recovery- und Clustertests zu durchlaufen, ohne Vorbereitungs- und Abstimmungsaufwand.
Wenn allerdings bereits nach vier bis fünf Wochen die nächste Hana-Revision veröffentlicht wird, kommt man gar nicht mehr aus dieser Testspirale heraus. Hier stellt die SAP nun via „Capture and Replay“ (ab SPS12) eine neue notwendige Funktion bereit, die den Testaufwand minimiert und optimiert.
Man benötigt nicht mehr explizite Test-/Keyuser, die das neue Release funktional und mit nur geringer Last testen, sondern man kann 1:1 den Workload aus dem produktiven System auf einem Testsystem abbilden.
30 Minuten für den Release-Wechsel?
Oft wird im Hana-Umfeld von der SAP über einen Wartungsaufwand von nur 30 Minuten für einen Release-Wechsel geworben. Hierbei wird aber unterschlagen, dass es sich dabei lediglich um die reine technische Prozedur handelt.
Hierfür notwendige und hinreichende Vorbereitungsarbeiten, Tests, Konsistenzprüfungen oder gar die Prüfung von Abhängigkeiten sind dabei nicht enthalten, denn diese beanspruchen mit Abstand die meiste Zeit.
Um Letzteres zu prüfen, stellt die SAP den Kunden leider kein vernünftiges Toolset zur Seite. Das bedeutet, man muss für jeden Release- Wechsel einige hundert Hinweise prüfen, ob die Funktion im Einsatz ist und dies auf die zukünftig verwendete Datenbankversion zutrifft.
Es gibt zum jetzigen Stand keine Such-, Filter- oder Kategorisierung der Hana-SAP-Hinweise. Am Ende erschwert es dem Administrator die Arbeit und verlängert somit den Testaufwand für mögliche Workarounds und Bugs, die möglicherweise doch noch in der neuen angestrebten Version enthalten sind.
Eine Antwort, ob ein derartiges Tool in Zukunft von der SAP ausgeliefert wird, konnten die anwesenden SAP-Mitarbeiter nicht geben. Auch dieser Kritikpunkt wurde aufgenommen, konnte aber bis zum jetzigen Zeitpunkt nicht vollständig geklärt werden.
Eine mögliche Lösung hat QPCM mit dem iHAL (intelligent Hana Assurance List) unabhängig von der SAP entwickelt, damit die tagelange Suche, Prüfung und Gewichtung der Hana-Hinweise nicht so viel Aufwand bedeutet.
Durch Eingabe des Quell- und Ziel-Releases kann der Administrator mittels iHAL ermitteln und dann abwägen, wie viele Fehler mit welchem Feature in Verbindung stehen, und anhand der Gewichtung bewerten, ob es Sinn macht, einen Workaround einzusetzen oder besser auf eine der kommenden Revisionen zu warten.
Dieses Hana-Prüf-Tool wird es in Zukunft auf www.qpcm.de geben. (Bei Interesse oder Detailauswertung setzen Sie sich via Mail mit jens.gleichmann@qpcm.de in Verbindung.)
Nicht jeder Bug führt zum Update
Ein Großteil der von SAP veröffentlichten Hana-Fehler sind schwerwiegender Natur, die sehr wohl die Stabilität der Hana-Datenbank als auch die Konsistenz der Daten betreffen. Damit sollte jedes Update wohlüberlegt sein und geprüft werden, bevor man das Update technisch einspielt.
Die Grafik gibt eine Übersicht der Verteilung der Kategorien und die verbundene Anzahl an Hana-Bugs. Wichtig ist die Kernaussage des Impulsbeitrags der SAP: „Nicht jeder Bug muss zwangsweise zu einem Update führen!“
Man sollte also abwägen, ob das betroffene Feature sowie dessen Impact den Betrieb, die Stabilität und Integrität des Gesamtsystems gefährden. Nur mit diesem Wissen kann man die Frage „Wann ist der richtige Zeitpunkt für ein Update/Upgrade“ mit ruhigem Gewissen beantworten.
Doch Stand heute fehlt genau diese Transparenz für die Kunden und Anwender. Unter diesen Umständen stellt sich zwangsläufig die Frage, über die fast alle IT-Manager und Administratoren diskutieren: Ist Hana bereits „Mission critical ready“?
Aufgrund dieser sehr kurzen Release-Zyklen sowie des damit verbundenen hohen Aufwands und der Menge an trotzdem noch offenen Bugs im Vergleich zu anderen Datenbanken verdient sich die Hana-Datenbank zum Standpunkt heute die bereits unter vielen Kunden bekannte Betitelung „Das Patchmonster“.
Die Veranstaltung war sowohl für Hersteller als auch Kunden sehr konstruktiv und die SAP hat sich der Kritik offen gestellt. Der Software-Gigant aus Walldorf hat in den letzten Wochen bereits darauf reagiert und die Hana-Revisionen deutlich stabilisiert.
Mit dieser Veranstaltung wurde das Fundament für die von vielen Kunden geforderte DSAG-Arbeitsgruppe „Hana im Betrieb“ Ende Juni geschaffen.
