Das initiale HANA Sizing für ein S/4HANA System wird erstellt, bevor jemand weiß, wie die tatsächliche Workload aussehen wird. Das während eines Migrationsprojekts erstellte Sizing-Dokument ist eine fundierte Schätzung: Datenvolumen des Quellsystems wird in erwartete Anforderungen für den HANA Column Store umgerechnet, Benutzerprognosen werden mit Speicherfaktoren pro Benutzer multipliziert, Batch-Workloads werden auf Basis von ECC Job-Laufzeiten geschätzt. Die Methodik ist solide. Die Eingabedaten sind unvollständig, weil sich Produktionsverhalten nicht präzise modellieren lässt, bevor es überhaupt eine Produktion gibt.
Manche Sizing-Annahmen erweisen sich als konservativ und das System läuft mit komfortabler Reserve. Andere erweisen sich als zu optimistisch und die Speicherentwicklung nach dem Go-live nähert sich der Allokationsgrenze schneller als erwartet. In beiden Fällen wird das Sizing-Dokument in dem Moment irrelevant, in dem die Produktion startet, weil das System nun reale Daten erzeugt, die jede Schätzung in diesem Dokument durch eine Messung ersetzen.
Dieser Artikel erklärt, was nach dem Go-live gemessen werden sollte, um zu prüfen, ob das Sizing unter realer Last standhält, wie zukünftige Speicher- und Storage-Anforderungen aus Post-Go-live-Daten statt aus Vorab-Schätzungen abgeleitet werden, wann Sizing-Anpassungen notwendig werden und wie aus den kontinuierlich erzeugten Monitoring-Daten eine laufende Kapazitätsplanung aufgebaut wird.
Warum die Sizing-Validierung nach dem Go-live anders ist als das Pre-Migration-Sizing
Was das initiale Sizing richtig eingeschätzt hat, und was es nicht wissen konnte
HANA Sizing-Schätzungen vor der Migration basieren auf drei Eingaben: dem ECC Quelldatenvolumen, der erwarteten Transaktionslast sowie einer Reihe von Multiplikatoren und Wachstumsannahmen aus der SAP Sizing-Methodik. Das Quelldatenvolumen ist meist genau. Die Transaktionslast ist in der Regel eine plausible Annäherung. Die Wachstumsannahmen sind Schätzungen, die an Branchendurchschnitten ausgerichtet sind.
Was die Sizing-Methodik nicht berücksichtigen kann, ist das spezifische Verhalten kundeneigener ABAP Programme, die nicht Teil der Sizing-Analyse waren, das Speicherkonsumprofil kundenspezifischer Calculation Views, die während des Projekts erstellt wurden, die tatsächliche Delta-Merge-Frequenz unter produktiven Schreibvolumina und der Row-Store-Verbrauch von Tabellen, die das Projektteam nicht als speicherrelevant identifiziert hatte. Das ist keine Nachlässigkeit. Diese Faktoren sind vor Produktionsstart tatsächlich nicht verlässlich bekannt.
Es gibt außerdem eine Kategorie von Speicherwachstum nach dem Go-live, die nichts mit den ursprünglichen Sizing-Annahmen zu tun hat: Datenwachstum durch Geschäftsprozesse. Ein S/4HANA System, das mit 1,2 TB migrierten Daten live geht, erzeugt neue Daten mit einer Rate, die vom Transaktionsvolumen bestimmt wird. Nach 18 Monaten Produktion ist die Datenbank gewachsen. Wenn diese Wachstumsrate im Sizing unterschätzt wurde, überschreitet die Speicherentwicklung früher als erwartet das, wofür die Hardware dimensioniert wurde.
Die ersten 90 Tage: Wenn das echte Speicherprofil sichtbar wird
Das Speicherverhalten eines HANA Systems ist in den ersten 90 Produktionstagen nicht stabil. Es entwickelt sich, während der Arbeitsdatenbestand in den Speicher geladen wird, neue Daten hinzukommen und die internen Strukturen des Column Store durch Delta-Merge-Zyklen optimiert werden.
Am ersten Tag nach dem Go-live befindet sich das System in einem kalten Zustand. Column-Store-Partitionen, die auf der Festplatte vorhanden sind, sind noch nicht vollständig in den Speicher geladen. Sobald Benutzer und Batch-Jobs auf Daten zugreifen, lädt HANA die benötigten Partitionen. Der Speicherverbrauch steigt in den ersten Tagen, während sich der Arbeitsdatenbestand erwärmt. Dieser Anstieg ist erwartbar und weist nicht auf ein Sizing-Problem hin. Ein mögliches Sizing-Problem zeigt sich dann, wenn der Speicherverbrauch über den erwarteten stabilen Zustand hinaus weiter ansteigt.
Der stabile Zustand eines gut dimensionierten Systems liegt bei einer Speichernutzung, die sich unter normaler täglicher Last zwischen 50 % und 70 % der Allokationsgrenze einpendelt, mit höheren Spitzen während der Monatsabschluss-Batch-Verarbeitung. Wenn das System bereits in der ersten Woche 75 % erreicht, bevor überhaupt ein Monatsabschluss gelaufen ist, sollte das Sizing wahrscheinlich überprüft werden. Wenn es sich im ersten Monat inklusive Monatsabschluss bei 60 % stabilisiert, verfügt das Sizing über Reserve für das Wachstumsmodell.
Deshalb ist ein Post-Go-live-Monitoring, das die Speicherentwicklung in den ersten 90 Tagen täglich erfasst, wertvoller als ein einmaliger Snapshot an Tag 30. Die Entwicklung zeigt, ob sich das System stabilisiert oder weiter wächst. Das entscheidet darüber, ob das aktuelle Sizing für die nächsten 12 bis 24 Monate ausreicht oder früher Aufmerksamkeit benötigt.
Validierung des Memory Sizings: Die wichtigsten Metriken
Peak Used Memory im Verhältnis zur Allokationsgrenze
Die Allokationsgrenze ist die Obergrenze, die HANA nicht überschreiten wird. Sie wird in der Datei global.ini über den Parameter global_allocation_limit konfiguriert und liegt typischerweise bei 90 % bis 95 % des physischen RAM, damit dem Betriebssystem genügend Reserve bleibt. Dieser Wert bestimmt, ob Ihr Sizing ausreichend ist.
Für die Sizing-Validierung nach dem Go-live muss der maximale Speicherverbrauch als Prozentsatz der Allokationsgrenze verfolgt werden, und zwar auf Ebene produktiver Lastspitzen: Peak während der Geschäftszeiten, Peak während des Monatsabschluss-Batchs und, falls relevant, Peak während der Jahresabschlussverarbeitung. Nicht Tagesdurchschnitte. Spitzenwerte.
Die Schwellenwerte für die Sizing-Bewertung sind: Eine Peak-Nutzung dauerhaft unter 70 % der Allokationsgrenze bedeutet, dass das System gut dimensioniert ist und Wachstumsspielraum hat. Eine Peak-Nutzung, die regelmäßig 80 % bis 85 % erreicht, bedeutet, dass das Sizing heute ausreichend ist, die Kapazitätsplanung aber die nächsten 12 Monate explizit modellieren muss. Eine Peak-Nutzung von 90 % bedeutet, dass eine Sizing-Überprüfung bereits überfällig ist. Der Weg von einem 85 % Peak zu einem Out-of-Memory-Stopp ist kürzer, als viele Teams glauben, wenn er während eines Hochlast-Events wie dem Monatsabschluss auftritt.
M_MEMORY_OVERVIEW richtig lesen
Die View M_MEMORY_OVERVIEW in HANA liefert das konsolidierte Speicherbild. Die für die Sizing-Validierung relevanten Felder sind USED_PHYSICAL_MEMORY, ALLOCATED_PHYSICAL_MEMORY und FREE_PHYSICAL_MEMORY auf Service-Ebene, kombiniert mit der Allokationsgrenze auf Instanzebene aus M_CONFIGURATION.
Der am häufigsten falsch interpretierte Wert ist USED_PHYSICAL_MEMORY. Er beschreibt den aktuell aktiven Speicherverbrauch. Er enthält nicht den Speicher, den HANA bereits alloziert hat, der aber im Moment der Messung nicht aktiv von Daten belegt ist: Speicherfragmentierung, vorallozierte Buffer und reservierter Speicherplatz. Der nützlichere Wert für die Sizing-Bewertung ist ALLOCATED_PHYSICAL_MEMORY, weil er zeigt, wie viel Speicher HANA vom Betriebssystem beansprucht hat. Die Differenz zwischen ALLOCATED und USED ist Overhead, der nicht verschwindet, selbst wenn Daten entladen werden.
Ein System, bei dem ALLOCATED bei 85 % der Allokationsgrenze liegt, USED aber bei 65 %, wirkt anhand der Used-Metrik komfortabel. Die operative Grenze ist jedoch ALLOCATED, nicht USED. Wenn ALLOCATED weiter wächst und sich der Grenze nähert, beginnt HANA mit aggressiven Column-Store-Unloads, um Speicher freizugeben. Das verschlechtert die Performance. Überwachen Sie daher ALLOCATED, nicht nur USED.
Geladene Column-Store-Daten: Was den Speicher tatsächlich verbraucht
Der größte Treiber des HANA Speicherverbrauchs in einer S/4HANA Umgebung sind Column-Store-Tabellendaten. Die View M_CS_TABLES zeigt den Speicherverbrauch pro Column-Store-Tabelle, einschließlich der Aufteilung zwischen Main Store, komprimiert und leseoptimiert, und Delta Store, schreiboptimiert und unkomprimiert.
Die Sizing-Validierung nach dem Go-live sollte eine Analyse der 20 größten Tabellen nach Speicherverbrauch an Tag 30 und an Tag 90 enthalten. Zwei Dinge sind dabei wichtig. Erstens Tabellen, die zwischen Tag 30 und Tag 90 stark gewachsen sind, weil sie die am schnellsten wachsenden Datenbereiche identifizieren und genauere Wachstumsprognosen ermöglichen. Zweitens Tabellen, bei denen der Delta Store im Verhältnis zum Main Store groß ist, weil das darauf hinweist, dass Delta Merges mit dem Schreibvolumen dieser Tabellen nicht Schritt halten und der effektive Speicherverbrauch höher ist als nötig.
Ein Delta Store, der mehr als 20 % des gesamten Speicherverbrauchs einer Tabelle ausmacht, sollte untersucht werden. Das Anpassen des Merge-Schwellenwerts oder das Auslösen eines manuellen Merges für die größten Tabellen kann den Speicherverbrauch senken, ohne Infrastruktur zu ändern. Diese Art systeminterner Optimierung ist oft verfügbar, bevor eine Resizing-Entscheidung notwendig wird. Sie wird aber nur sichtbar, wenn der Column-Store-Speicher auf Tabellenebene überwacht wird, nicht nur aggregiert.
Hinweis: M_CS_TABLES kann in einem großen S/4HANA System Tausende von Zeilen zurückgeben. Fragen Sie die View mit einem Filter auf MEMORY_SIZE_IN_TOTAL > 1000000000, also 1 GB, ab, um sich auf Tabellen zu konzentrieren, die das Speicherbild tatsächlich beeinflussen. Die Top 50 Tabellen nach Speichergröße machen typischerweise 60 % bis 70 % des gesamten Column-Store-Speicherverbrauchs aus.
Zukünftige Speicheranforderungen aus Post-Go-live-Daten prognostizieren
Die Berechnung der Wachstumsrate und warum mehr als 30 Tage Daten nötig sind
Eine aus 30 Tagen Post-Go-live-Daten berechnete Speicherwachstumsrate ist als Planungsgrundlage unzuverlässig. Die ersten 30 Tage enthalten die Cold-Start-Ladephase, die die Wachstumsrate im Vergleich zum stabilen Zustand künstlich erhöht. Sie enthalten möglicherweise einen Monatsabschluss, möglicherweise aber auch nicht. Genau dieser Monatsabschluss ist jedoch das Ereignis mit der höchsten Last und dem größten Einfluss auf den Peak-Speicherverbrauch. Außerdem reichen 30 Tage nicht aus, um einen linearen Wachstumstrend von einem logarithmischen Trend zu unterscheiden, was völlig andere Folgen für den Zeitpunkt eines notwendigen Resizings hat.
Neunzig Tage liefern eine nutzbare Wachstumsrate für eine lineare Projektion. Sechs Monate liefern eine Wachstumsrate, mit der sich lineare von beschleunigten Trends unterscheiden lassen. Der praktische Ansatz besteht darin, ab den 90-Tage-Daten konservativ zu projizieren und die Projektion zu verfeinern, sobald mehr Daten vorliegen.
Die Berechnung ist einfach: Ziehen Sie den Speicherverbrauch an Tag 30 vom Speicherverbrauch an Tag 90 ab, wobei die Cold-Start-Phase ausgeschlossen wird, und teilen Sie das Ergebnis durch 60 Tage, um eine tägliche Wachstumsrate zu erhalten. Projizieren Sie diese Rate nach vorne. Wenden Sie sie auf die aktuelle Reserve zwischen Peak ALLOCATED Memory und Allokationsgrenze an. Das Ergebnis zeigt, wie viele Tage bei aktueller Wachstumsrate verbleiben, bevor der Peak den Warnschwellenwert von 85 % erreicht.
Liegt dieser Wert unter 6 Monaten, ist sofort eine Sizing-Überprüfung erforderlich. Liegt er bei 12 bis 18 Monaten, ist eine Sizing-Überprüfung im nächsten quartalsweisen Planungszyklus angemessen. Liegt er bei 24 Monaten oder mehr, ist das aktuelle Sizing komfortabel und ein monatliches Wachstumsmonitoring reicht aus.
Wann ein Resizing notwendig wird: Entscheidungskriterien, die vorab definiert werden sollten
Das Resizing eines HANA Systems, ob on-premise oder in einer Cloud-Umgebung, hat Vorlaufzeit. Bei einem Hyperscaler erfordert die Änderung des Instanztyps für ein produktives HANA System ein geplantes Wartungsfenster und umfasst in der Regel einen kurzen Neustart. Der Prozess ist schneller als ein Hardware-Upgrade on-premise, aber nicht unmittelbar. Die Entscheidung muss 4 bis 6 Wochen getroffen werden, bevor die Grenze kritisch wird, nicht erst dann, wenn das System unter produktiver Last bereits bei 88 % Speichernutzung liegt.
Entscheidungskriterien im Voraus festzulegen, statt auf Speicherdruck zu reagieren, erfüllt zwei Zwecke. Es nimmt die Dringlichkeit aus der Entscheidung, was die Qualität der Analyse verbessert. Und es schafft einen klaren Trigger, den das operative Monitoring sichtbar machen kann: Wenn Monitoring-Daten zeigen, dass die Peak-Speichernutzung in drei aufeinanderfolgenden Monatsabschlusszyklen X % erreicht hat, wird der Sizing-Review-Prozess gestartet.
Ein pragmatischer Kriterienkatalog lautet: Starten Sie eine Sizing-Überprüfung, wenn die Peak-Nutzung während eines Monatsabschlusszyklus 82 % der Allokationsgrenze überschreitet. Beginnen Sie den Resizing-Prozess, wenn die 6-Monats-Wachstumsprognose zeigt, dass das System im nächsten Quartal 85 % Peak erreichen wird. Diese Indikatoren werden operativ als Frühwarnsignale genutzt, nicht nur als rückblickende Kennzahlen. Dadurch bleibt Zeit zum Handeln, bevor die Grenze operativ kritisch wird.
In der Praxis: In RISE with SAP Umgebungen laufen Memory-Resizing-Anfragen über SAP und nicht direkt über den Hyperscaler. Der Prozess umfasst eine formale Sizing-Überprüfung mit SAP und einen Change Request. Planen Sie 6 bis 8 Wochen Vorlaufzeit ein, statt der 2 bis 3 Wochen, die bei einer direkten Änderung des Instanztyps beim Hyperscaler typisch sind. Bauen Sie diese Vorlaufzeit entsprechend in die Entscheidungstrigger ein.
CPU und Storage: Sizing-Dimensionen, die oft weniger Aufmerksamkeit erhalten
CPU-Thread-Auslastung unter Spitzenlast
Das CPU Sizing von HANA wird oft als zweitrangig gegenüber dem Speicher betrachtet, weil HANA für die meisten Workloads speichergebunden ist. Das stimmt weitgehend. CPU wird dort zur Grenze, wo stark parallelisierte Operationen auftreten: große analytische Abfragen, die Dutzende Ausführungsthreads erzeugen, Delta-Merge-Operationen, die parallel zu den geschäftlichen Spitzenzeiten laufen, und Jahresabschluss-Batch-Läufe, die mehrere Reporting-Jobs gleichzeitig ausführen.
CPU Sizing-Validierung nach dem Go-live bedeutet, die CPU-Thread-Auslastung während Peak-Events zu beobachten, nicht Tagesdurchschnitte. M_SERVICE_THREADS zeigt die Anzahl aktiver Threads und deren Zustände während einer Abfrage oder Batch-Operation. Ein System, bei dem während des Monatsabschlusses alle verfügbaren CPU-Threads gleichzeitig aktiv sind, hat keine Reserve für parallele Last. Die Benutzererfahrung in diesem Zeitfenster verschlechtert sich, weil jede zusätzliche Abfrage um Threads konkurriert, die bereits vollständig belegt sind.
Das konkrete Szenario, auf das geachtet werden sollte, ist ein System, das in täglichen CPU-Metriken unauffällig aussieht, aber genau während des 3- bis 4-stündigen Monatsabschluss-Batch-Fensters eine CPU-Thread-Sättigung zeigt. Dieses Muster erscheint nicht in Tagesdurchschnittswerten. Es wird nur in Peak-Auslastungsdaten während genau dieser Ereignisse sichtbar. Deshalb ist CPU-Monitoring bei Peak-Events, nicht nur im Tagesdurchschnitt, für die Sizing-Validierung entscheidend.
Wachstumsrate des Datenvolumens und Konfiguration des Log-Volumes
Das Wachstum des Datenvolumens nach dem Go-live wird durch die Rate neuer Datenerzeugung bestimmt: neue gebuchte Belege, neue Bewegungen, neue analytische Aggregate. Die Wachstumsrate der ersten 90 Tage ist die genaueste verfügbare Grundlage für die Storage-Kapazitätsplanung, weil sie das tatsächliche Transaktionsvolumen dieser spezifischen Produktionsumgebung widerspiegelt.
Berechnen Sie das Wachstum des Datenvolumens, indem Sie M_DISK_USAGE in den ersten 12 Wochen nach dem Go-live wöchentlich abfragen und jedes Mal die Größe der DATA-Komponente erfassen. Das wöchentliche Delta ergibt die Wachstumsrate. Projizieren Sie sie über 24 Monate. Wenn das projizierte Datenvolumen im Monat 24 mehr als 80 % des zugewiesenen Storage überschreitet, muss entweder eine Storage-Erweiterung oder Data Lifecycle Management innerhalb des ersten Jahres geplant werden.
Das Sizing des Log-Volumes ist ein anderes Problem. Das Log-Volume wächst nicht in derselben Weise wie das Datenvolumen. Es sammelt Redo Logs, bis Log-Backups ausgeführt werden. Danach können gesicherte Segmente überschrieben werden. Das Risiko ist nicht ein allmähliches Wachstum bis zur Grenze, sondern eine plötzliche Erschöpfung, wenn Log-Backups nicht mehr laufen. Der Post-Go-live-Check für das Log-Volume ist daher keine Wachstumsratenberechnung, sondern die Bestätigung, dass das Backup-Intervall auf den produktiven Schreibdurchsatz abgestimmt ist und das Log-Volume genug Puffer hat, um mindestens 2 Stunden Ausfall eines Backup-Fensters zu überstehen, ohne 100 % Auslastung zu erreichen.
Data Lifecycle und seine Auswirkung auf die Sizing-Entwicklung
Wie Archivierung das Speicherbild verändert
HANA Column-Store-Daten verbrauchen Speicher proportional zum geladenen Datenvolumen. Der direkteste Weg, das Wachstum des Speicherverbrauchs zu reduzieren, abgesehen von Hardware-Resizing, besteht darin, Daten aus der Datenbank zu entfernen, die das Unternehmen für produktive Abläufe nicht mehr benötigt. Das ist Datenarchivierung, und ihre Wirkung auf den Speicher ist direkt: Archivierte Daten, die nicht mehr in HANA liegen, verbrauchen keinen Speicher.
Die meisten S/4HANA Projekte planen Archivierung als zukünftige Aktivität. Sie findet selten im ersten Produktionsjahr statt. Die praktische Folge für das Sizing ist, dass die Speicherwachstumsentwicklung im ersten Jahr den ausgleichenden Effekt der Archivierung nicht enthält, der in der initialen Sizing-Schätzung angenommen wurde. Das Sizing wurde möglicherweise mit einem angenommenen 3-Jahres-Archivierungszyklus berechnet. Die tatsächlichen ersten drei Jahre können jedoch ohne jegliche Archivierung verlaufen, wodurch die Wachstumsentwicklung steiler wird als im Sizing-Dokument prognostiziert.
Post-Go-live-Monitoring, das Datenwachstum nach Funktionsbereich verfolgt, etwa Finanzbelege, Materialbewegungen oder Bestellungen, liefert den fachlichen Kontext für eine fundierte Diskussion darüber, welche Datenbereiche am schnellsten wachsen und welche Archivierungsprogramme den größten Sizing-Effekt hätten. Ohne diese Daten werden Archivierungsentscheidungen auf Basis von Compliance-Anforderungen oder Projektbequemlichkeit getroffen, statt nach Speicherauswirkung.
Kalte Daten in HANA, die dort nicht sein sollten
Nach 12 bis 18 Monaten Produktion enthalten die meisten S/4HANA Systeme ein erhebliches Datenvolumen, das im ersten Jahr aktiv war, jetzt aber selten oder gar nicht mehr abgerufen wird. Historische Finanzbelege aus abgeschlossenen Perioden, abgeschlossene Fertigungsaufträge, versendete Kundenaufträge von vor zwei Jahren. Diese Daten liegen im Column Store, belegen Speicher und werden bei Table Scans geladen, selbst wenn die Abfrage nur aktuelle Daten benötigt.
Die native Tabellenpartitionierung von HANA ermöglicht es, historische Daten in Partitionen zu trennen, die als unloaded markiert sind. Das bedeutet, sie verbrauchen keinen Speicher, solange sie nicht explizit abgerufen werden. Die Implementierung von Range Partitioning auf Datumsfeldern für große Transaktionstabellen hält aktuelle Daten warm im Speicher, während historische Daten auf der Festplatte verbleiben, bis sie benötigt werden.
Das Monitoring-Signal dafür, dass kalte Daten erheblichen Speicher belegen, ist ein hohes Verhältnis zwischen der gesamten Column-Store-Datengröße und dem Datenvolumen, das in den letzten 30 Tagen durch produktive Abfragen tatsächlich genutzt wurde. Wenn eine Tabelle 200 GB Daten enthält und das Monitoring zeigt, dass im letzten Monat nur 15 GB davon abgerufen wurden, entsprechen 185 GB des Speicher-Footprints dieser Tabelle kalten Daten, die durch Partitionierung aus dem aktiven Arbeitsspeicher entfernt werden könnten. M_CS_UNLOADS zeigt, welche Tabellenteile aufgrund von Speicherdruck entladen und später erneut geladen wurden. Das dient als Proxy, um wenig genutzte Datenstrukturen zu identifizieren.
Von der Sizing-Validierung zur laufenden Kapazitätsplanung
Der monatliche Rhythmus der Kapazitätsprüfung
Sizing-Validierung ist ein Projektlieferobjekt. Kapazitätsplanung ist eine operative Disziplin. Der Übergang vom einen zum anderen findet ungefähr an Tag 90 statt, wenn sich das Speicherprofil nach dem Go-live ausreichend stabilisiert hat, um belastbare Prognosen zu ermöglichen.
Eine monatliche Kapazitätsprüfung erfordert weder ein langes Meeting noch einen komplexen Bericht. Sie benötigt vier Zahlen, die monatlich aktualisiert werden: aktuelle Peak-Speichernutzung als Prozentsatz der Allokationsgrenze, aktuelle Wachstumsrate des Datenvolumens in GB pro Monat, prognostiziertes Datum, an dem die Peak-Speichernutzung basierend auf der aktuellen Wachstumsrate 82 % erreicht, und prognostiziertes Datum, an dem das Datenvolumen eine Storage-Erweiterung erfordert. Mit diesen vier monatlich aktualisierten Zahlen hat das Team 60 bis 90 Tage Vorwarnzeit für jede Kapazitätsgrenze, bevor sie den Produktionsbetrieb beeinträchtigt.
Die Prüfung wird relevant, wenn sich eine dieser Zahlen deutlich verändert. Eine Wachstumsrate, die über drei aufeinanderfolgende Monate von 15 GB pro Monat auf 35 GB pro Monat gestiegen ist, ist kein Rauschen. Sie ist ein Signal, dass sich etwas im Datenerzeugungsmuster verändert hat, sei es Geschäftswachstum, eine neue Integration, die mehr Datensätze erzeugt, oder ein Housekeeping-Job, der nicht mehr läuft. Die monatliche Prüfung ist der Mechanismus, der diese Veränderung erkennt, solange der Handlungsspielraum noch in Monaten und nicht in Wochen gemessen wird.
Was berichtet werden sollte, und an wen
Das Operations-Team benötigt die Rohmetriken: HANA Speichernutzungstrend, Datenvolumenwachstum, Delta-Merge-Zustand, Log-Volume-Status. Diese fließen in Monitoring-Dashboards ein, die das Basis-Team kontinuierlich einsehen kann.
IT-Management und Business-Verantwortliche benötigen etwas anderes: ein einfaches Signal, ob das aktuelle Sizing die nächsten 12 Monate abdeckt und wie der Planungshorizont für die nächste Sizing-Entscheidung aussieht. Nicht die rohen HANA Speicherzahlen, sondern die Schlussfolgerung, die diese Zahlen ermöglichen. Eine monatliche Kapazitätszusammenfassung mit drei Zeilen, aktueller Headroom, prognostiziertes Datum des nächsten Entscheidungspunkts und empfohlene Maßnahme, falls erforderlich, ist für Entscheider nützlicher als ein Diagramm mit M_MEMORY_OVERVIEW-Werten.
Diese Unterscheidung ist wichtig, weil Sizing-Entscheidungen Budget, Beschaffung und Planungszeit betreffen. Die Personen, die diese Entscheidungen genehmigen, müssen verstehen, wann eine Entscheidung nötig ist, nicht wie HANA Speichermanagement funktioniert. Monitoring-Daten in geschäftsrelevante Kapazitätssignale zu übersetzen, ist Teil der Kapazitätsplanung und keine separate Kommunikationsaufgabe.
Das Sizing-Dokument ist ein Ausgangspunkt, kein Ziel
Jedes Sizing-Dokument, das für eine S/4HANA Migration erstellt wird, hat ein Ablaufdatum: Es ist gültig, bis die Produktion startet. Danach ersetzt die tatsächliche Messung die Schätzung als Grundlage jeder Kapazitätsentscheidung.
Teams, die das Post-Go-live-Sizing richtig angehen, behandeln den Übergang von Schätzung zu Messung als bewussten Prozess. Sie beginnen am ersten Tag mit dem Monitoring der Speicherentwicklung, legen Baseline-Metriken an Tag 30 und Tag 90 fest, definieren Entscheidungskriterien für den Start einer Sizing-Überprüfung und berichten den Kapazitätsstatus monatlich, bevor das Thema dringend wird.
Teams, die es falsch machen, behandeln das Sizing-Dokument als korrekt, bis etwas ausfällt. Diese Teams entdecken beim ersten Monatsabschluss, dass das Sizing zu optimistisch war, wenn die Speichernutzung während des Closing-Batchs auf 91 % steigt und keine Vorlaufzeit bleibt, um zusätzliche Kapazität vor dem nächsten Monatsabschluss vier Wochen später zu beschaffen.
Post-Go-live-Monitoring ändert die Hardware nicht. Es ändert die verfügbare Zeit, um fundierte Entscheidungen über die Hardware zu treffen. Diese Zeit wird entweder proaktiv genutzt oder in reaktivem Krisenmanagement verbraucht. Der Unterschied zwischen beidem ist kontinuierliche Messung.
