Als Maximo- Experten gehen wir oft von einer einfachen Annahme aus: Der Datensatz mit der höchsten ID muss der zuletzt erstellte sein. In einer herkömmlichen Einzelserver-Umgebung scheint diese Annahme meist zuzutreffen.  
‍

In der IBM Maximo Application Suite (MAS) Manage kann diese Logik jedoch, insbesondere beim Betrieb mehrerer Pods, zu falschen Schlussfolgerungen führen.
‍

Für Architekten, Entwickler, Berichtersteller und Integrationsteams ist es unerlässlich zu verstehen, wie Maximo Datenbanksequenzen verwaltet, Werte zwischenspeichert und IDs über mehrere Pods hinweg zuweist.

Verständnis der Maximo-Sequenzverwaltung

Maximo nutzt Datenbanksequenzen, um eindeutige Identifikatoren für Datensätze zu generieren, wie zum Beispiel:

• Arbeitsaufträge

• Serviceanfragen

• Bestandstransaktionen

• Einkaufstransaktionen

• Benutzerdefinierte Geschäftsobjekte
  ‍

Die Implementierung variiert je nach Datenbankplattform leicht.

Oracle und Db2

Oracle und Db2 verwenden native Datenbank-Sequenzobjekte. Die Datenbank selbst verwaltet die Sequenz und garantiert die Eindeutigkeit über alle Anwendungsinstanzen hinweg.
‍

Wenn Maximo einen neuen Bezeichner benötigt, fordert es den nächsten Wert direkt von der Datenbanksequenz an.

SQL Server

Früher nutzte Maximo auf SQL Server die Tabelle MAXSEQUENCE anstelle von nativen SQL Server-Sequenzobjekten.
‍

In neueren MAS Manage-Releases kann SQL Server bei entsprechender Konfiguration native SQL Server-Sequenzen über den Mechanismus NEXT VALUE FOR nutzen.
‍

Unabhängig von der Datenbankplattform bleibt das Hauptziel dasselbe:

Effiziente und sichere Generierung eindeutiger Werte in einer Umgebung mit hoher Nebenläufigkeit.

Nutzen mehrere MAS Manage-Pods dieselbe Sequenz?

Die kurze Antwort lautet ja.
‍

In MAS Manage verbinden sich alle Pods mit derselben gemeinsam genutzten Datenbank. Folglich teilen sie sich auch dieselben zugrunde liegenden Sequenzobjekte.
‍

Eine Sequenz existiert nicht unabhängig innerhalb einzelner Pods. Stattdessen gilt:

• Die Sequenz befindet sich in der Datenbank.

• Jeder Pod fordert Werte von derselben Sequenz an.

• Die Datenbank garantiert die Eindeutigkeit.

• Mehrere Pods können gleichzeitig Datensätze erstellen, ohne dass es zu Kollisionen kommt.
  ‍

Das bedeutet, dass UI-Pods, Integrations-Pods, Cron-Pods und Reporting-Pods alle Werte aus derselben zugrunde liegenden Sequenzquelle beziehen.

Was hat es mit dem Cache auf sich? (Verstehen Sie?)

Um die Leistung zu verbessern, fordert Maximo normalerweise nicht bei jeder Erstellung eines Datensatzes einen neuen Sequenzwert aus der Datenbank an.
‍

Stattdessen reserviert es Wertblöcke und speichert diese im Arbeitsspeicher.
‍

Zum Beispiel:

• UI-Pod 1 reserviert die Sequenzen 1 – 5

• UI-Pod 2 reserviert die Sequenzen 6 – 10
  ‍

Beide Bereiche sind einzigartig, da sie aus derselben Datenbanksequenz zugewiesen wurden.
‍

Jeder Pod verfügt nun über einen eigenen lokalen Cache, wodurch Datensätze erstellt werden können, ohne dass ständige Datenbankabfragen erforderlich sind.
‍

Dies verbessert die Skalierbarkeit und Leistung des Systems erheblich. Hier beginnen jedoch viele Probleme bei der Berichterstattung und Integration….

Warum Sequenznummern nicht chronologisch sind

Stellen Sie sich folgendes Szenario vor:

Schritt 1: UI-Pod 1 reserviert die Werte: 1, 2, 3, 4, 5

Schritt 2: UI-Pod 2 reserviert die Werte: 6, 7, 8, 9, 10

Schritt 3: Ein Benutzer mit einer Sitzung in UI-Pod 2 erstellt einen Arbeitsauftrag

Schritt 4: Kurze Zeit später erstellt ein Benutzer mit einer Sitzung in UI-Pod 1 einen weiteren Arbeitsauftrag

Das Ergebnis:

Wenn Sie nach ID sortieren, erscheint Arbeitsauftrag UI2 neuer, obwohl er in Wirklichkeit vor Arbeitsauftrag UI1 erstellt wurde.
‍

Die Sequenzwerte bleiben zwar eindeutig, spiegeln jedoch nicht mehr die tatsächliche Erstellungsreihenfolgewider.

Warum das wichtig ist

Viele Anwender nutzen Datensatz-IDs unbewusst als Abkürzung, um Fragen zu beantworten wie:

• Was war der letzte Arbeitsauftrag?

• Welche Serviceanfrage wurde zuletzt erstellt?

• Was ist die neueste Bestandstransaktion?

• Welches Asset wurde zuletzt hinzugefügt?
  ‍

In einer Multi-Pod-MAS-Umgebung lassen sich diese Fragen nicht zuverlässig über den höchsten Sequenzwert beantworten. Dies kann zu ungenauen Berichten, Dashboards, Integrationen, Datenmigrationen und Business-Intelligence-Ergebnissen führen.
‍

Ich bin sicher, dass ich nicht der Einzige bin, der in der Vergangenheit eine Form der folgenden Abfrage verwendet hat, um den neuesten Wert zu erhalten:

select * from <table>  
where <column> = ‘<value>’ and   
<table unique id> = (select max(<table unique id>) from <table> where <column> = ‘<value>’) 

Warum ROWSTAMP keine Lösung ist

Einige, mich eingeschlossen, haben versucht, ROWSTAMP als Alternative zu verwenden.
‍

Dies führt zu einem anderen Problem, da sich dieses Feld ebenfalls ändert, sobald ein Datensatz aktualisiert.
‍

Zum Beispiel:  

Bei einer Sortierung nach dem Aktualisierungsdatum (ROWSTAMP) WO10001 erscheint neuer, obwohl WO10002 später erstellt wurde.
‍

Dadurch sind aktualisierungsbasierte Felder unzuverlässig, um die ursprüngliche Erstellungsreihenfolge zu bestimmen.

Was sollten Sie stattdessen verwenden?

Der richtige Ansatz ist die Verwendung eines unveränderlichen Erstellungszeitstempels.  
‍

Beispiele hierfür sind:

• Erstellungsdatum

• Erstellungsdatum und -uhrzeit

• Vom System erstellte Audit-Felder

• Weitere reine Einfüge-Zeitstempelspalten
  ‍

Eine nützliche Faustregel lautet:

Verwenden Sie die ID zur Identifizierung: der sequenzgenerierte Bezeichner identifiziert einen Datensatz eindeutig.

Verwenden Sie den Zeitstempel für die Chronologie: Erstellungszeitstempel zeigen, wann ein Datensatz tatsächlich eingefügt wurde.

Verwenden Sie beides für eine stabile Sortierung: wenn mehrere Datensätze denselben Zeitstempel aufweisen, kann die Kombination aus Zeitstempel und ID eine deterministische Sortierung gewährleisten.

Zusammenfassung

Da MAS Manage-Bereitstellungen für die Skalierbarkeit zunehmend auf Kubernetes und mehrere Pods setzen, werden Annahmen, die in herkömmlichen Maximo-Umgebungen mit einem einzelnen Server funktionierten, weniger zuverlässig.
‍

Sequenznummern wurden entwickelt, um ein einziges Problem zu lösen: Eindeutigkeit.
‍

Sie waren nie dazu gedacht, als Nachweis für die Erstellungsreihenfolge zu dienen.
‍

Wenn Sie für Ihre geschäftlichen Anforderungen ermitteln müssen, was zuletzt geschehen ist, verlassen Sie sich immer auf einen echten Erstellungszeitstempel und nicht auf einen sequenzgenerierten Bezeichner. So stellen Sie sicher, dass Ihre Berichte, Integrationen und operativen Entscheidungen auf der Realität basieren und nicht auf der zufälligen Reihenfolge zwischengespeicherter Sequenzwerte.

‍