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. Lock der Arbeitsumgebung (Keine Ausführung laufender Services)
  2. Offline und Clearing Tabellen prüfen, Clearing Tabellen ggf. erstellen
  3. Der Clearing Prozess wird auf Offline Tabellen ausgeführt
  4. Offline Tabellen werden gedroppt
  5. Die aktuellen Tabellen werden nach Offline umbenannt
  6. Die Indizes werden bereinigt
  7. Neue Tabellen für den Active Bereich werden erstellt
  8. Das Switch Datum in den Global Properties wird mit dem Ausführungszeitpunkt aktualisiert

Wichtig ist hierbei, sich den Zustand der Daten zu veranschaulichen:

Die Offline und Clearing Tabellen beinhalten Daten, auf die normal zugegriffen werden kann. Dafür stehen in der B2B Oberfläche im MessageMonitor zusätzliche Filteroptionen bereit:

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):

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.

B3P_LAST_SWITCH_DATE = 2011.03.02 17:46:01

Der SwitchPartitionJob schreibt nach der erfolgreichen Ausführung einen Zeitstempel in diese Global Properties. Bei jedem Lauf vergleicht der SwitchPartitionJob die aktuelle Zeit mit diesem Zeitstempel unter Berücksichtigung des CRON-Ausdrucks von B3P_SWITCH_SPAN. Hierdurch wird sichergestellt, dass nur zu definierten Zeitpunkten ein Partition Switch stattfindet.

Diese GP ist optional und bei Inbetriebnahme nicht verpflichtend. Diese GP kann aber verwendet werden, um den ersten Switch nicht direkt mit dem Start der B2B by Practice auszuführen, sondern erst, wenn folgende Formel greift:

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

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.

Datenbank Schema festlegen

Bei der GP B3P_REPORTING_DB_SCHEMA muss das Datenbank Schema angegeben werden. In diesem Schema wird dann die Existenz von Tabellen geprüft. Sollte es nur ein Schema geben kann man diese GP weglassen. Es kann auch noch der Datenbank Catalog angegeben werden mit B3P_REPORTING_DB_CATALOG. Diese Properties können wegelassen werden falls schon der Tabellen Name in der Datenbank eindeutig ist.

SWITCH_PARTITION_DO_POST_SECURITY_LEVEL

Wenn diese GP nicht angelegt ist werden do Post anfragen während der SwitchPartitionJob läuft mit einer Exception beantwortet. Wenn man diese GP auf normal setzt werden die do Post anfragen gepuffert bis der SwitchPartitionJob durchgelaufen ist. Wenn man diese GP auf high setzt werden die do Post anfragen auch gepuffert bis der SwitchPartitionJob durchgelaufen ist. Hier wird ein sicheres Verfahren verwendet welches nicht ganz so Performant ist wie beim setzten auf normal. Wenn diese GP auf high ist wird die zusätzliche Tabelle B2BBP_DATA_LOCKTAB_PARTITION benötigt.

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

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.

View Me   Edit Me