Knowledge Base > Automation Engine und Zielsysteme > Datenbanken > ILM – Partition-Key Turnaround

ILM - Partition-Key Turnaround

Wird die Partionierung der Datenbank mittels ILM genutzt, so kommt es beim Erreichen der maximalen RunID (Aufgaben, Statistiksätze) zu einer speziellen Situation. Wie schnell dieses Maximum erreicht ist, hängt von der Anzahl der regelmäßig gestarteten Aufgaben ab. Um dieses Problem zu lösen, wird in diesem Fall eine spezielle Prozedur - der Partition-Key Turnaround - durchgeführt.

Allgemeine Informationen

Statistikeinträge (für durchgeführte Aufgaben) werden in der Tabelle AH gespeichert, wobei sich deren RunIDs in der Spalte AH_Idnr befinden. Die Werte dieser Spalte sind technisch 32-Bit-Zahlen, wodurch sich ein maximaler Wert von 2.147.483.647 ergibt. Der Nummernbereich unter 1.000.000 ist für spezielle Verarbeitungen reserviert.
Der erlaubte bzw. mögliche Wertebereich für die RunIDs von Statistiksätzen ist daher: 1.000.000 bis 2.147.483.647.

Bei Automation Engine Systemen mit einer geringen Anzahl von regelmäßig durchgeführten Aufgaben wird diese Grenze praktisch nie erreicht. Bei einer großen Anzahl (~1.000.000) von täglich laufenden Aktivitäten kann man mitunter schon nach einigen Jahren auf dieses Limit stoßen.

Partitionswechsel

Allgemeine Informationen zu ILM und dem Partitionswechsel finden Sie hier.

Es wird immer eine bestimmte Anzahl von Partitionen in der Datenbank online gehalten. Diesen Wert können Sie mit der Einstellung ONLINE_PARTITIONS in der Variable UC_ILM_SETTINGS festlegen.

Bei der Nutzung von ILM mit AE hat jede Partition einen maximalen Key-Wert. Die aktuelle Partition jedoch ist nach oben hin offen und besitzt keinen fixen Grenzwert. Dies wird über einen speziellen virtuellen Wert der Partition realisiert: NULL bei MS SQL Server und MAXVALUE bei Oracle Datenbanken.

Beim Partitionswechsel wird im oberen Bereich eine neue Partition eingefügt und die älteste Partition gelöscht. Bei Oracle ist das Löschen direkt möglich, bei MS SQL Server ist eine Staging-Tabelle notwendig.

Partition-Key Turnaround Modus

Es wird laufend automatisch der maximale RunID-Verbrauch der bisherigen Partitionen berechnet und in der Variable UC_ILM_SETTINGS unter dem Key MAX_ENTRIES abgelegt. Soll ein Partitionswechsel durchgeführt werden, so wird geprüft, ob ab der aktuell höchsten RunID weniger als 3x MAX_ENTRIES notwendig ist, um den Maximalwert zu erreichen. Ist dies der Fall, so wird der Partition-Key Turnaround-Modus aktiviert.

Ist dieser spezielle Modus aktiv, werden die nächsten Partitionen wieder im unteren Bereich (ab 1.000.000) eingefügt und die Nummerierung beginnt wieder von vorne. Dieser spezielle Modus ist solange aktiv, bis alle Partitionen im oberen Nummernbereich entfernt worden sind und wieder ein durchgehender Wertebereich bis 2.147.483.647 verfügbar ist.

Da die Partionierung von Oracle gegenüber MS SQL Server Datenbanken sehr unterschiedlich ist, läuft auch der Partition-Key Turnaround anders ab. Der Ablauf wird somit pro Datenbank-Typ beschrieben.

Oracle

Folgendes Ausgangsszenario:

Max. Verbrauch (MAX_ENTRIES): 1.000.000
Aktuell höchste vergebene RunID: 2.145.000.000
Online Partitionen: 4

Partition	Obergrenze
P11	2.142.483.647
P12	2.143.483.647
P13	2.144.483.647
P14	MAXVALUE

P11 reicht technisch gesehen von 1.000.000 bis 2.142.483.647, logisch gesehen jedoch nur von 2.141.483.647 bis 2.142.483.647, da nur Datensätze in diesem Bereich von AE geschrieben werden.

Nun soll ein Partitionswechsel gemacht werden. Zwischen der aktuell höchsten RunID (2.145.000.000) und dem Maximalwert (2.147.483.647) ist weniger als 3x MAX_ENTRIES (1.000.000) Platz, wodurch in den Partition-Key Turnaround Modus gewechselt wird.

Nun wird die älteste Partition (P11) gesplittet, um im unteren Nummernbereich (beginnend ab 1.000.000) eine neue Partition (P15) einzufügen. Als Obergrenze der neuen Partition wird der 3-fache Maximalverbrauch festgelegt. In unserem Fall ergibt sich für die neue Partition P15 die Obergrenze 4.000.000.

Anschließend wird nach dem Einfügen von P15 die älteste Partition P11 entfernt, wodurch wieder nur 4 Partition verfügbar sind.

Beim nächsten Partitionswechsel wird diese Prozedur wiederholt:

Als Obergrenze der neuen Partition wird wieder der dreifache Maximalverbrauch verwendet, gerechnet ab der Obergrenze von P15. Die aktuell älteste Partition P12 wird daher bei 7.000.000 gesplittet, wodurch die neue Partition P16 entsteht. Anschließend wird P12 entfernt.

Dieser Vorgang wird nun solange wiederholt, bis keine Partitionen mehr im oberen Nummernbereich verfügbar sind. Dies ist in unserem Fall nach einen weiteren Partitionswechsel (P17) soweit.

Wird danach die nach oben offene Partition (P14) gelöscht, so wird kein Partition-Split durchgeführt, sondern eine neue, nach oben offene Partition (P18) eingefügt.

Anschließend ist der Partition-Key Turnaround vorbei und es wird wieder der normale Modus aktiviert. Die RunIDs werden nun wieder ab dem unteren Bereich vergeben.

Dabei gilt:

Wenn der Partition-Key Turnaround Modus aktiv ist, muss weiterhin ein Partitionswechsel erfolgen
Die alten Partitionen sind weiterhin zu löschen, damit jene im oberen Nummernbereich entfernt werden und man so wieder in den Normalbetrieb schalten kann
Ebenfalls sollte der RunID-Verbrauch überwacht werden, damit die 3-fache Maximalverbrauchs-Grenze nicht überschritten wird. Falls diese Grenze nicht ausreicht, ist rechtzeitig ein vorzeitiger Partitionswechsel durchzuführen.

SQL-Server

Folgendes Ausgangsszenario:

Max. Verbrauch (MAX_ENTRIES): 1.000.000
Aktuell höchste vergebene RunID: 2.145.000.000
Online Partitionen: 4

Partition	Obergrenze
P1	2.142.483.647
P12	2.143.483.647
P13	2.144.483.647
P14	NULL

Durch Definition der unteren Grenze bei MS SQL Server ergibt sich, dass die unterste Partition P1 leer ist. Sie kann zwar technisch verwendet werden, ist jedoch logisch leer, da sie von AE nicht verwendet wird. Sie wird auch in der Systemübersicht nicht angezeigt.

Die unterste logische Partition ist somit P12.

Die letzte Partition P14 ist nach oben hin offen.

Nun soll ein Partitionswechsel durchgeführt werden. Da nun ab der höchsten vergebenen RunID bis zur Maximal-Grenze weniger als 3x MAX_ENTRIES vorhanden sind, wird der Partition-Key Turnaround Modus aktiviert.

Da bei MS SQL Server eine Untergrenze definiert wird, wird die unterste Partiton P1 bei 1.000.000 gesplittet, um im unteren Bereich eine Partition einzufügen. Der Bereich unter 1.000.000 bleibt die Partition P1 und weiterhin unbenutzt. Die durch den Split neu entstandene Partition (P15) erbt die Obergrenze der bisher kleinsten Partition.
P15 reicht nun technisch von 1.000.000 bis 2.142.483.647. Dieser Grenzwert wird sich jedoch durch die folgenden Partitionswechsel laufend ändern.

Anschließend wird die älteste Partition P12 gelöscht, wodurch P15 automatisch deren Obergrenze bekommt. P15 reicht nun technisch von 1.000.000 bis 2.143.483.647.

Beim nächsten Partitionswechsel wird die Partition 15 gespalten: P15 erhält nun als Obergrenze den tatsächlichen Maximalverbrauch (1.000.000), gerechnet ab der Obergenze von P1. Die Obergrenze von P15 ist somit 2.000.000. Anschließend wird die älteste Partition P13 gelöscht.
Die neue Partition P16 reicht somit technisch von 2.000.000 bis 2.144.483.647, da sie die Obergrenze von P13 erbt.

Die aktuelle Situation sieht nun so aus:

Nach dem letzten Partitionswechsel erhält P16 den tatsächlichen Maximalverbrauch und wird bei 3.000.000 gesplittet. Die Partition P14 wird gelöscht, wodurch nun die neue Partition P17 nach oben hin offen ist. Der Partition-Key Turnaround ist beendet und wir befinden uns nun wieder im Normalzustand.

Dabei gilt:

Es ist darauf zu achten, dass regelmäßige Partitionswechsel durchgeführt werden, wenn man den RunID-Maximalwert (2.147.483.647) annähernd erreicht.

Automic Documentation - Tutorials - Automic Blog - Resources - Training & Services - Automic YouTube Channel - Download Center - Support