Application Partitions

Motivation

Große Mengen an Bewegungsdaten sollen nach der Archivierung dauerhaft aus der Datenbank gelöscht werden. Auf Grund der Datenmenge ist das mit klassischen SQL Statements wegen hoher Laufzeiten schlecht zu bewältigen. Es ist günstiger, in solchen Fällen entsprechende Tabellen direkt zu droppen, dabei muss natürlich sichergestellt werden, dass nur bereits archivierte Daten gelöscht werden und problematische Daten erneut vom Benutzer bearbeitet werden können. Außerdem sollte dieser Prozess automatisiert in bestimmten Zeiträumen stattfinden (Scheduling) und entsprechend konfigurierbar sein.

Annahmen:

Es wird in diesem Beispiel von einer Oracle Datenbank ausgegegangen. Zudem wird festgelegt, dass Daten, die älter sind als 2 Monate, gelöscht werden sollen.

Funktionsweise

Hier ist eine Klartextbeschreibung mit den oben genannten Rahmenbedingungen (Löschzeitpunkt: Älter als 2 Monate):

Es sind 2 Monate vergangen. Alles was älter ist als zwei Monate wird bereinigt (Clearing) und anschliessend gelöscht, wenn keine nicht archivierten Daten vorhanden sind. Alles was zwischen 2 Monaten und dem Ausführungsdatum liegt, wird in den Offline- Bereich verschoben. Alles was nach dem Ausführungszeitpunkt liegt, ist der neue Active Bereich.

Es gibt also drei Bereiche, die auf entsprechende Tabellen (und Indices) abgebildet werden können:

Offline:

Beinhaltet alle Daten, die bei der Nächsten Ausführung des SwitchPartitionJob- Service gedroppt werden sollen

Clearing:

Beinhaltet alle Daten, die bei der Nächsten Ausführung des SwitchPartitionJob- Service von Offline nach Clearing verschoben worden sind, weil Sie entweder nicht archiviert wurden oder anderweitig nicht ein definiertes Löschschema passen.

Active:

Das ist die aktuelle Tabelle mit dem aktuellem Datenbestand.

Folgendes Schaubild verdeuticht den Prozess:

Interne Funktionsweise

Der eigentliche Vorgang der Partitionierung geschieht über den SwitchPartitionJob.

Die Abfolge der internen Abläufe ist wie folgt:

1. Partition-Lock: Ein anwendungsweiter Partition-Switch-Lock wird gesetzt. Falls der Lock nicht erlangt werden kann, bricht der Job ab.
2. Ausführbarkeit prüfen: Der Job prüft, ob B3P_PARTITION_DATABASE = true ist und ob seit dem letzten Switch (B3P_LAST_SWITCH_DATE) der über B3P_SWITCH_SPAN definierte Zeitraum vergangen ist.
3. Recovery-Check: Fehlende Active-, Offline- und Clearing-Tabellen werden automatisch nacherstellt (Recovery), um einen konsistenten Ausgangszustand sicherzustellen.
4. Clearing: Nicht archivierte Nachrichten werden aus den Offline-Tabellen in die Clearing-Tabellen verschoben. Die Selektion erfolgt standardmäßig über state = 'ERR', kann aber per B3P_CLEARING_WHERE_CLAUSE angepasst werden.
5. Nachrichtenverarbeitung stoppen: Alle dynamischen Locks, der Crawler-Lock, die Queue und die Archivierung werden gesperrt. Dabei wartet der Job pro Lock bis zu 10 Versuche (je 5 s).
6. Bis zu 50 Sekunden abwarten, dass die Queue leer ist.
7. Warten auf laufende Verarbeitung: Der Job wartet in einer Schleife (Polling alle 5 s), bis keine aktiven Workflow-Threads mehr in der Queue laufen.
8. Pre-Switch-Checks: Optional wird eine über B3P_PRESWITCH_CHECK_CLASS konfigurierte Prüfklasse ausgeführt. Zusätzlich wird bei gesetzter B3P_MESSAGE_ID_IN_ARCHIVE geprüft, ob diese Message-ID im Archiv existiert.
9. Offline-Tabellen droppen: Die bisherigen Offline-Tabellen und deren Indizes werden entfernt.
10. Active nach Offline umbenennen: Die aktiven Tabellen und Indizes werden nach Offline umbenannt. Direkt nach dem Rename wird B3P_LAST_SWITCH_DATE aktualisiert.
11. Neue Active-Tabellen erstellen: Leere Tabellen und Indizes für den neuen Active-Bereich werden erstellt.
12. Application Lock freigeben: Alle Locks (dynamische Locks, Crawler, Queue, Archiv) werden wieder freigegeben.
13. Global Properties aktualisieren: B3P_LAST_SWITCH_DATE wird mit dem Ausführungszeitpunkt beschrieben und DELETE_FULL_TEXT_INDEX_TO wird anhand des Switch-Span berechnet und gespeichert.

Daten-Zustand nach einem Switch:

Die Offline und Clearing Tabellen beinhalten Daten, auf die normal zugegriffen werden kann.

Im Initialdurchlauf der Partitionierung werden alle Daten, die älter sind als der eingestellte Wert, in die Offline Tabellen verschoben ( durch Umbenennen). Erst beim zweiten Start des SwitchPartitionJobs werden diese Daten tatsächlich gedroppt.

Es werden ständig die Daten aus dem Offline Bereich vorgehalten (z.B. >= 2 Monate) sowie die aktuellen Daten bis zum nächsten Switch (2 Monate). Insgesamt sind also mindestens die Daten aus dem einfachen, maximal aus dem doppelten Zeitraum verfügbar, der angegegeben worden ist, plus die Daten, die nebenläufig im Clearing Bereich liegen.

Gesondertes Clearing

Da auch der Clearing-Prozess bei entsprechenden Datenmengen aufwendig sein kann, kann über den SwitchPartitionCopyClearingJob auch zwischenzeitlich die Verschiebung der Daten von Offline nach Clearing erfolgen.

Konfiguration

Die Konfiguration besteht aus mehreren Einstellungen und Services. Die Services sind hier verlinkt und gesondert unter Services in der B2B Dokumentation zu finden.

Um die „Application Partitions“ einzurichten, müssen folgende Einstellung in B2B by Practice geändert werden. Aktuell ist die Einrichtung für folgende Datenbanken möglich:

• MS SQL Server ab 2008
• Oracle ab 11g
• Derby ab 10.11
• Sap DB / MaxDB

Berechtigungen Datenbank Benutzer

Für die Ausführung der verschiedenen Befehle benötigt der Benutzer für die B2B Datenbank erweiterte Berechtigungen: DROP, CREATE, RENAME. Zusätzlich für einzelne Datenbanken:

• MS SQL Server 2008: sp_rename()

Tabellenprüfung

Da bei den Application Partitions häufiger komplette Bereiche von Tabellen für die Bewegungsdaten neu Angelegt werden müssen, muss die Ausgangssituation ebenfalls diesem Umfang an Tabellen entsprechen.

Folgende Tabellen müssen existieren, bevor die Application Partitions genutzt werden können.

• B2BBP_DATA_MESSAGE
• B2BBP_DATA_ACTION
• B2BBP_DATA_ATTRIBUTE
• B2BBP_DATA_ATTRIBUTE_ARCHIVE
• B2BBP_DATA_ERROR
• B2BBP_DATA_CLEARING
• B2BBP_DATA_CLEARING2
• B3P_DATA_STATES_HISTORY

Bei Oracle müssen folgende Indices vorhanden sein:

• IDX_MESSAGE_STARTED_ID
• IDX_MESSAGE_REFERENCE_ID
• IDX_CORR_ALTERID_DIRECT_SENDER
• IDX_ATTRIBUTE_ACTIONID_TYPE
• IDX_ATTRIBUTE_MESSAGEID_TYPE
• IDX_ATTRIBUTE_MESSAGEID
• IDX_ATTRIBUTE_ARC_ACTION_TYP
• IDX_ATTRIBUTE_ARC_MESSAGE_TYP
• IDX_ATTRIBUTE_ARC_MESSAGEID
• IDX_ERROR_ACTION_ID
• IDX_ACTION_MESSAGE_ID
• IDX_ACTION_STARTED_MESSAGE_ID
• IDX_B3P_STATES_HIST_1

Einrichtung der Application Partition Services

Links (siehe auch oben):

• Link zum SwitchPartitionJob
• Link zum SwitchPartitionCopyClearingJob

Extensions für zusätzliche Indexe

Mit den Extensions:

1. SWITCH_PARTITION_RENAME_ACTIVE_INDEXES
2. SWITCH_PARTITION_CREATE_ACTIVE_INDEXES
3. SWITCH_PARTITION_CREATE_OFFLINE_INDEXES
4. SWITCH_PARTITION_CREATE_CLEARING_INDEXES

Können zusätzliche (vom B2B Standard abweichende) Index angegeben werden welche bei der Application-Partition berücksichtigt werden sollen. Bei 1.) muss ein Rename Statement angegeben werden z.B. alter index “IDX_TEST_ACTION_NAME” rename to “IDX_TEST_ACTION_NAMEO”.

Bei 4.) ein create Statment z.B. CREATE INDEX IDX_TEST_ACTION_NAMEC ON B2BBP_DATA_ACTIONC (NAME)

Aktivierung der Application Partitions

Damit die Application Partitions auch aktiv werden, muss noch folgende Global Property gesetzt werden.

B3P_PARTITION_DATABASE = true

Ist diese Eigenschaft auf false gesetzt, oder gar nicht vorhanden, dann sind die Application Partitions in B2B by Practice nicht aktiv.

Relevante Global Properties

Zeitpunktberechnung

Der SwitchPartitionJob schreibt nach der erfolgreichen Ausführung einen Zeitstempel in B3P_LAST_SWITCH_DATE. Bei jedem Lauf vergleicht der Job die aktuelle Zeit mit diesem Zeitstempel unter Berücksichtigung des B3P_SWITCH_SPAN-Werts. Die Formel lautet:

<Aktuelles Datum> - <B3P_SWITCH_SPAN> > <B3P_LAST_SWITCH_DATE>

Die GP B3P_LAST_SWITCH_DATE ist optional und bei Inbetriebnahme nicht verpflichtend.

Anbindung B2B-Message-Service

Falls Sie den B2B-Message-Service einsetzen, muss dieser ebenfalls für Switch Partition konfiguriert werden. Weitere Details entnehmen Sie der Doku des B2B-Message-Service.

SWITCH_PARTITION_DO_POST_SECURITY_LEVEL

Diese Global Property steuert, wie eingehende DoPost-Anfragen während der Laufzeit des SwitchPartitionJob behandelt werden:

Relevante Jobs einrichten:

Die Archivierung, SwitchPartition und SwitchPartitionCopyClearing müssen abgestimmt ablaufen, damit der Switch sauber abläuft. Vor dem Switch sollte der CopyClearing-Job optimalerweise die Offline-Partition vollständig abgearbeitet und nicht archivierte Nachrichten in die Clearing-Partition verschoben haben. Dann wird der Switch besonders schnell durchgeführt. Der CopyClearing-Job seinerseits sollte nur den Zeitraum betrachten, der durch den ArchivJob archiviert wurde.

Deshalb bietet sich folgende Konfiguration der Jobs, as Beispiel für den Switch-Intervall von 60 Tagen:

• Zwei ArchiveJobs archivieren Nachrichten älter als 55 Tage in der Aktiven und Offline-Partitionen. Sie laufen zu unterschiedlichen Tageszeiten.
• SwitchPartitionCopyClearingJob verschiebt nicht archivierte Nachrichten älter als 59 Tage in die Clearing-Partition. Das gibt den Archivjobs im Fehlerfall bis zu vier Tage Zeit, um die Nachrichten zu archivieren.
• SwitchPartitionJob macht einen Switch jede 60 Tage, dabei sollte die Offline-Partition keine relevanten Nachrichten mehr haben, weil sie zuvor archiviert bzw. in die Clearing-Partition verschoben wurden.

B2BBP_DATA_LOCKTAB_PARTITION

Folgende Tabelle muss erstellt werden wenn das SWITCH_PARTITION_DO_POST_SECURITY_LEVEL auf high ist.

CREATE TABLE
 B2BBP_DATA_LOCKTAB_PARTITION
 (
   LOCKID VARCHAR2(40) NOT NULL,
   NODENR INTEGER
 );

Nacharbeiten

Nach der Einrichtung der Partitionierung sind folgende Punkte zu beachten:

• Die Archivierung muss den Offline Bereich berücksichtigen, bei Wunsch auch die Active- und Clearing-Bereiche
• Vorhandene Delete Jobs sind unter Umständen überflüssig
• Nach dem ersten Lauf des SwitchPartitionJobs müssen die Views in der Datenbank geändert werden, damit die Nachrichen im Nachrichtenmonitor angezeig werden können. Diese Views sollen gelöscht und mit neuen Definitionen angelegt werden:
  • b2bbp_data_message_view
  • b2bbp_data_action_view
  • b2bbp_data_attribute_view
  • b2bbp_data_error_view

Die neuen Definitionen der Views sind in der Datei create_tables_b2b_special_oracle.sql zu finden.

Monitoring

Der SwitchPartitionJob protokolliert seinen Fortschritt im MessageMonitor als einzelne Nachricht mit mehreren Actions. Folgende Informationen werden als Action-Einträge geschrieben:

Zusätzlich werden die Actions „Aktuelle Aktion” und „Abgeschlossene Aktion” laufend aktualisiert, so dass der aktuelle Fortschritt im MessageMonitor sichtbar ist.

Erstmalige Inbetriebnahme (Erster Switch)

Der erste Switch unterscheidet sich vom regulären Betrieb, da noch keine Offline- und Clearing-Tabellen existieren und alle Bewegungsdaten in den aktiven Tabellen liegen. Dieser Abschnitt beschreibt die Vorbereitung und die Nachkontrolle.

Vorbereitung (Checkliste)

Folgende Punkte müssen vor dem Setzen von B3P_PARTITION_DATABASE = true erfüllt sein:

1. Datenbank-Berechtigungen prüfen

Der DB-Benutzer der B2B-Anwendung benötigt die Rechte CREATE TABLE, DROP TABLE und RENAME (bzw. sp_rename() bei MS SQL Server). Ohne diese Rechte schlägt der Switch mit einer SQL-Exception fehl.

2. Basistabellen prüfen

Alle 8 Bewegungsdaten-Tabellen müssen in der Datenbank vorhanden sein (siehe Tabellenprüfung). Die Spalten-Typen sollen ebenfalls mit den Standard-Skripten abgeglichen werden.

3. Indizes prüfen (Oracle / SAP DB)

Bei Oracle müssen alle Standard-Indizes existieren (siehe Tabellenprüfung). Zusätzliche kundenspezifische Indizes müssen über die entsprechenden Extensions registriert sein (siehe Extensions für zusätzliche Indexe).

4. SwitchPartitionJob als Service einrichten aber noch nicht aktivieren

Der Service muss konfiguriert und geplant sein, bevor die Partitionierung aktiviert wird. Mindestens die Service Property B3P_SWITCH_SPAN muss gesetzt sein (z.B. 0 2 0 0 0 0 für 2 Monate).

Die Property B3P_PRESWITCH_CHECK_CLASS und die Extension B3P_PRESWITCH_CHECK_SQL sollen unbedingt zumindest wie in der SwitchPartitionJob-Doku beschrieben konfiguriert werden!

Wir empfehlen den ersten und zweiten Switch manuell anzustoßen und den Ablauf zu kontrollieren. Ein Switch dauert normalerweise wenige Sekunden bis Minuten.

5. SWITCH_PARTITION_DO_POST_SECURITY_LEVEL festlegen

Entscheiden Sie, wie eingehende Nachrichten während des Switches behandelt werden sollen ( siehe SWITCH_PARTITION_DO_POST_SECURITY_LEVEL). Bei high muss die Tabelle B2BBP_DATA_LOCKTAB_PARTITION vorab erstellt werden.

6. Foreign-Key-Constraints auf nicht-partitionierten Tabellen entfernen

Die Tabellen B2BBP_OUTBOX und B2BBP_DATA_ADDITIONAL_COLUMNS besitzen standardmäßig einen FK-Constraint auf B2BBP_DATA_MESSAGE. Da diese Tabellen beim Switch nicht partitioniert werden, müssen die Constraints vor dem ersten Switch entfernt werden. FK-Constraints sind nicht mit der Partitionierung kompatibel.

Oracle SQL zum Löschen der Constraints:

ALTER TABLE B2BBP_OUTBOX DROP CONSTRAINT <constraint_name>;
ALTER TABLE B2BBP_DATA_ADDITIONAL_COLUMNS DROP CONSTRAINT <constraint_name>;

Zum Bereinigen der Tabelle B2BBP_DATA_ADDITIONAL_COLUMNS kann DeleteJobUseTemplate benutzt werden.

7. Archivierung und CopyClearingJob einplanen

Die Archivierungs- und CopyClearingJobs sollten bereits konfiguriert sein, auch wenn sie beim ersten Switch noch keine Rolle spielen. Für den zweiten Switch ist es entscheidend, dass diese Jobs im konfigurierten Intervall laufen ( siehe Relevante Jobs einrichten).

8. B3P_PARTITION_DATABASE = true setzen

Prüfungen nach dem ersten Switch

Zweiter Switch (erstmaliges Löschen von Daten)

Beim zweiten Switch werden zum ersten Mal tatsächlich Bewegungsdaten aus der Datenbank gelöscht. Die Offline-Tabellen aus dem ersten Switch — die alle ursprünglichen Nachrichten enthalten — werden gedroppt.

Voraussetzungen

Damit der zweite und folgende Switches erfolgreich ablaufen und korrekte Nachrichten gelöscht werden, soll das passende Clearing-Verhalten konfiguriert werden. Das bedeutet: Beim Switch soll die Offline-Partition möglichst nur noch Nachrichten enthalten, die gelöscht werden können. Das sind in der Regel archivierte Nachrichten, Job-Entries und eventuell Split-Nachricthen oder andere Nachrichten, die bewusst ohne Archivierung bleiben, aber auch gelöscht werden können. Andere Nachrichten sollten idealerweise bereits vor dem Switch in die Clearing-Partition verschoben werden.

Während des Switches verschiebt der SwitchPartitionJob maximal 1000 Nachrichten von Offline nach Clearing, dabei werden sie über die B3P_CLEARING_WHERE_CLAUSE selektiert.

Wenn danach noch relevante Nachrichten in der Offline-Partition liegen, bricht der Switch mit einer Exception ab. Die Prüfung erfolgt über das SQL-Statement, das in der Extension B3P_PRESWITCH_CHECK_SQL hinterlegt ist.

Wenn eine größere Anzahl von Clearing-Fällen zu erwarten ist, sollte der SwitchPartitionCopyClearingJob so konfiguriert werden, dass er jeden Tag läuft und die Offline-Partition bereinigt. Damit wird sichergestellt, dass die Offline-Partition vor dem nächsten Switch möglichst wenig relevante Nachrichten enthält und der Switch schnell durchläuft.

Die SQL-Statements in der Extension B3P_PRESWITCH_CHECK_SQL und den Service Properties B3P_CLEARING_WHERE_CLAUSE am SwitchPartitionJob und SwitchPartitionCopyClearingJob sollen in ihrem Kern gleich sein und so formuliert sein, dass sie die relevanten Nachrichten selektieren, die nicht gelöscht werden sollen.

Wenden Sie die SQL-Statements manuell in der Datenbank an und passen Sie sie gegebenenfalls an, damit sie die gewünschten Nachrichten selektieren.

Beispiel für Bewegungsdaten-Tabellen

Die folgenden Tabellen werden üblicherweise im Rahmen der Partitionierung erstellt und umbenannt. Je nach verwendeter Datenbank gibt es hier Tabellen mit den Suffixen “O” (Oracle) oder “OFFLINE” (andere), bzw. “C” oder “CLEARING” für entsprechende Clearing Tabellen.