Entschuldigung! Nie wieder …
Meine Frau begrüßt mich amüsiert an der Haustür:
„Hast du die Welt aus den Angeln gehoben? Auf deinem privaten Smartphone wollen dich ziemlich viele Leute erreichen.“
Ich erkläre ihr kurz die Umstände meiner missglückten Berichterstattung und überlege mir gleichzeitig einen Plan zur Wiedergutmachung: intern meine Basisleute zum Mittagessen in die Kantine einladen und mit Chefredakteur Färbinger und seinen Freunden eine Telko organisieren.
Hier sind die Ergebnisse:
Seit Hana 2 SPS3 unterstützt die Datenbank Intels Optane-DC-Persistent-Memory. Intel und SAP entwickelten das Konzept gemeinsam. Man argumentiert, dass bei einem Benchmark mit gemischter Speicherbestückung – Dram (Dynamic Random Access Memory) und Persistent Memory (Optane oder Pmem) – der Hana-Start um das 12,5-Fache beschleunigt wird.
Es ist eine Größenordnung, die auch den Ergebnissen der Kollegen von Evonik und Siemens entspricht, die von Accenture präsentiert wurden. So weit, so gut.
Aber sind diese Ergebnisse relevant und hilfreich? Oder, wie mir Chefredakteur Färbinger ausrichten ließ: Lösung sucht Problem! Grau ist alle Theorie und offensichtlich auch diese von Accenture, denn wie es ein Ex-SAP-Kollege formulierte: By default werden Tabellen beim ersten Mal „angreifen“ von der Festplatte oder SSD ins Memory geladen.
Der Start-up einer 1-TB-Hana sollte, wenn kein Anwender arbeitet, schnell gehen. Gültig nur für Column Tables, nicht Row Tables. Da aber 99 Prozent der Tabellen Column Stores sind, gilt die Aussage für die ganze DB.
Jede Tabelle hat den Parameter IS_PRELOAD, der ist „by default“ auf „false“ gesetzt. Somit werden die Tabellen beim Hana-Start nicht ins Memory geladen, dies geschieht erst beim Zugriff auf diese Tabellen.
Bis vor Kurzem konnte man pro Partition und Column steuern, was ins Hana-Memory geladen wird. Seit SP4 und der Native Storage Extension geht das auch auf Page-Ebene. (Vielen Dank an den Ex-SAP-Mitarbeiter, der alles an einem realen Hana-Server überprüft hat – hier schlägt die praktische Erfahrung die Theorie von Accenture! Von diesem ausgewiesenen Experten werden wir in Zukunft noch viel im E-3 Magazin lesen, wie mir Chefredakteur Färbinger telefonisch mitteilte.)
SAP hat diese Erkenntnisse weitgehend bestätigt:
„NVRam bedeutet non-volatiler Ram oder auch persistenter Speicher […] Bei NVRam ist die Performance für einen Neustart geringer, weil auf die Daten erst zugegriffen wird, wenn sie verwendet werden.“
Wo es nach internen und externen Aussagen nochmals spannend werden könnte, ist die zukünftige Speichergröße eines Hana-Servers. Weil Optane, oder wie Intel auch sagt:
Pmem/NVRam, eine höhere Packungsdichte hat, kann mit jedem Abtausch eines Dram-Speicherriegels gegen Pmem das Memory eines Hana-Servers erhöht werden.
Bei Intel fanden wir Quellen, die von einem Verhältnis eins zu vier berichteten, was bei einem 4-Sockel-Server dann 4,5 TB pro Sockel bringen könnte.
Liest man einige SAP-Notes sehr sorgfältig, relativiert sich diese frohe Botschaft sehr schnell. Offensichtlich bleibt es aufgrund der Hana-Architektur aber bei einem Verhältnis von eins zu eins, wie auch Färbingers Quellen bestätigen.
Noch einen zweiten „Schlagabtausch“ zwischen SAP und unserer virtuellen Expertenrunde gab es: Allgemein wurden die zahlreichen Bug Fixes und Service Packages kritisiert.
„Solange SAP also alle sechs Wochen einen neuen Patch herausbringt und die Empfehlungen für die Paramater-Settings noch öfter wechseln …“
Die Antwort von SAP:
„Sowohl Updates als auch Durchbooten sind Entscheidungen des Kunden – die Update-Frequenz obliegt allein seiner Entscheidung. Die meisten Hana-Parameter lassen sich online – ohne Neustart – ändern.“
Sehr amüsant – alle unsere internen und externen Experten waren sich einig: Warum bringt SAP in schöner Regelmäßigkeit einen Patch heraus, wenn nicht dafür, dass Kunden ihn einspielen, um erkannte Bugs zu beheben, die teilweise das Resultat von Berechnungen verfälschen (Wer kann dann seinem System noch trauen?).
Wenn der Bestandskunde das Problem an den Support eskaliert, sagt dieser als Erstes: „Patchen Sie doch auf den aktuellen Stand, bevor wir uns die Sache überhaupt ansehen.“
Der Early Watch Report zeigt hier sowieso schon lange „hellrote“ Ampeln – das soll ich SAP über meine Kolumne ausrichten.
1 Kommentar
Werner Dähn
Ein paar interessante Tests, Erkenntnisse und Kommentare bei Microsoft zu dem Thema:
https://techcommunity.microsoft.com/t5/running-sap-applications-on-the/sap-hana-fast-restart/bc-p/1091766
Werner Dähn
Bezüglich Statup-Zeiten, wird die Wahrheit irgendwo dazwischen liegen.
Klar, wenn zum Start gleich mal gar keine Tabellen geladen werden, ist der Start sehr schnell und PMEM hilft an der Stelle nichts.
In Realität stürzen sich aber sofort 1000te Anwender auf das frisch gebootete Hana und warten ungeduldig bis all die benötigten Tabellen endlich geladen sind. Also sollte man den Begriff Boot-Zeit sowieso etwas weiter fassen, hin zu “bis die Anwender vernünftig arbeiten können”.
Umgekehrt, werden die benötigten Tabellen/Partitionen anfänglich nur 10%(?) der Gesamtmenge ausmachen.
Irgendwo zwischen den beiden Extremen liegt die Wahrheit. Entsprechend ist PMEM keine Wunderlösung für Alles und Jeden, aber trotzdem eine tolle Sache. Und dann hat PMEM ja noch weitere genannte Vorteile…
Einverstanden?