Malentendus dans le contexte Hana

Die Startzeit bis zur Verfügbarkeit des SAP-Systems kann länger als 30 bis 60 min sein, um alle Daten in den Hauptspeicher zu laden: Ja, um alle Daten in den Hauptspeicher zu laden, dauert es einige Zeit, aber dies ist bei einer AnyDB nicht anders.

Diese benötigt auch einige Zeit, um den Puffer zu füllen. Dies passiert üblicherweise nach dem ersten Zugriff auf die Daten und diese verweilen dort, bis der LRU-Algorithmus (Least Recently Used) in Aktion tritt und sie verdrängt.

Hana lädt den kompletten Zeilenspeicher (Row Store) bei jedem Start in den RAM. Danach ist das System sofort verfügbar. Kurze Beschreibung des Startprozesses:

1. Öffnen der Datendateien;
2. Auslesen der Informationen des letzten erfolgreichen Savepoints (Zuordnung von logischen Seiten zu physischen Seiten in den Datendateien und Laden der Liste für offene Transaktionen);
3. Laden des Row Stores (abhängig vom I/O-Subsystem – ca. fünf Minuten für 100 GB);
4. Zurückspielen der Redologs;
5. Zurückrollen der nicht erfolgreich (Commit) gespeicherten Transaktionen;
6. Schreiben eines Savepoints;
7. Laden des Column Stores, der als Preload gekennzeichnet ist
8. „lazy load“ der restlichen Tabellen (asynchrones Laden der Spaltentabellen, die vor dem Neustart bereits geladen waren).

Das Testsystem ist ein BW on Hana on IBM Power. Die DB-Größe ist 40 GB, Row Store hat 6 GB und der Startvorgang dauert etwa 60 Sekunden, der Stopvorgang etwa 75 Sekunden.

Im zweiten Lauf kommt eine 5-GB-Column-Tabelle (REPORSRC) hinzu sowie SQL für den Preload: alter table REPOSRC preload all. Wieder dauerte der Startvorgang etwa 60 und der Stopvorgang etwa 75 Sekunden.

Warum wurde der Startvorgang nicht deutlich länger, obwohl mehr Daten zu laden sind?
Seit SPS7 findet der Preloading-Vorgang, zusammen mit dem Reloading der Tabellen, asynchron statt, direkt nachdem der Startvorgang der Hana-DB abgeschlossen ist.

Auf diesem Weg ist das System sofort wieder verfügbar, ohne auf den Ladevorgang der spaltenorientierten Tabellen zu warten. Wenn man testen will, wie lange es dauert, damit alle Tabellen in den RAM geladen werden, kann man dies mit dem Skript loadAllTables.py (Speicherort: /usr/sap/HDB/SYS/exe/hdb/python_support/) testen (als sidadm): python ./loadAllTables.py –user=System –password= –address=<hostname> –port=3xx15 –namespace=<schema_name>

Statistiken werden mit Hana nicht mehr benötigt; es müssen keine Statistiksammelläufe mehr eingeplant werden: teilweise korrekt. Für die spaltenorientierten Tabellen ist die Aussage richtig. Es werden keine speziellen Sammelläufe benötigt, da der Optimizer sehr schnell durch das Dictionary über die Verteilung Bescheid weiß.

Für den Zeilenspeicher werden Statistiken automatisch generiert, sobald diese benötigt werden (on-the-fly). Diese müssen also ebenso nicht durch Sammelläufe eingeplant werden. Aktuell ist es nicht offiziell dokumentiert, wie man diese Statistiken beeinflussen kann (z. B. Samplesize, manueller Statistiklauf etc.).

Sauvegarde

Ein Restore benötigt immer Logs für ein konsistentes Recovery! Falsch, die Hana-Backups basieren auf einer Snapshot-Technologie. Es ist also ein komplett eingefrorener Stand der Datenbank, der von der Logposition bestimmt ist zur Zeit der Ausführung des Backups.

Das Backup ist somit ohne jegliches Log in einem konsistenten Zustand. Sicherlich werden die Logs für ein Vorwärtsrollen benötigt, z. B. Point in Time Recovery oder zum letztmöglichen Stand vor einem Ausfall.

Backup Catalog: Kataloginformationen werden wie bei Oracle (*.anf-Datei) gespeichert, welche unbedingt zum Recovery benötigt werden. Der Backup-Katalog wird mit jedem Daten- und Logbackup gesichert!

Es ist keine normal lesbare Datei. Auch ohne diese originale Datei aus dem Backup kann ein Recovery stattfinden (siehe SAP Note 1812057, Rekonstruktion des Backup-Katalogs mit hdbbackupdiag).

Zu finden ist diese in der Backup-Lokation (bei Backup-to-Disk) oder im Backup-Set eines Dritt­anbieters sowie erkennbar am Namen log_backup_0_0_0_0.<backupid>.

Der Katalog enthält alle nötigen Informationen, welche für ein Recovery benötigt werden, wie zum Beispiel welche Logs zu welchem Zeitpunkt benötigt werden oder welche Dateien zu welchem Backupset gehören.

Wenn die Backups physisch auf Festplatte-, VTL- oder Band-Ebene gelöscht werden, hält der Backup-Katalog dennoch diese ungültigen Informationen. Aktuell gibt es keinen ausgelieferten Automatismus, der dies bereinigt.

Wie groß ist diese Katalogdatei im System? Das kann man selbst testen! Einblick erhält man mit dem Hana-Studio im Back­up-Editor, wenn man alle Backups inklusive Logs anzeigen lässt.

Wenn diese Datei größer als 20 MB ist, sollte man auf das Housekeeping achten, denn wie bereits erwähnt wird sie bei jedem Backup mitgesichert. Dies bedeutet mehr als 200-mal am Tag! 200-mal 20 MB mal 3 (weil 3-System-Landschaft) sind schon 12.000 MB.

Das Ergebnis des Sizing-Reports muss verdoppelt werden: Die neuen Sizing-Ergebnisse der SAP-Reports sind final und müssen nicht mehr erneut verdoppelt werden, wie vielleicht noch aus alten Dokumentationen hervorgeht.

Als Beispiel kann man eine BW-Scale-up-Lösung nehmen. Dies bedeutet, dass sich Master- und Slave-Knoten auf einem Server befinden. Ein Scale-out-Ansatz im BW-Umfeld besteht nach SAP-Empfehlungen aus einem Master-Knoten, der die transaktionale Last trägt, und mindestens zwei Slave-Knoten, die für das Reporting zuständig sind.

Das SAP-Hauptspeicher-Sizing besteht aus einem statischen und dynamischen Teil. Der statische Anteil sind Indizes sowie Spalten- und Zeilendaten, was der Summe der Nutzdaten entspricht.

Der dynamische Anteil sind temporäre Dateien für das Reporting (OLAP BW Queries), Delta-Merge sowie das Sortieren und Gruppieren, was in Summe dem temporären Speicher entspricht, der nach Abschluss der Aktion wieder freigegeben wird.

Ein Beispiel: Der Row Store mit 53 GB mal 2 entspricht 106 GB; Master-Column hat 11 GB mal 2 entspricht 21 GB (gerundet) plus 67 GB mal 2 entspricht 135 GB (gerundet). Ergibt in Summe 156 GB. 50 GB Caches und Services werden für jeden Server benötigt. Was letztendlich 312 GB in Summe ergibt.