Datenbereinigung
Grundlagen
Zu jeder abgeschlossenen Prozess-Instanz und Instanz-Aktion werden in der Datenbank durch die Prozess-Engine große Datenmengen historisiert. Diese Daten werden für Prozess-Auswertungen benötigt. Doch gibt es technische Prozesse, deren historisierte Daten nicht benötigt werden. Zudem sind Daten, die mehrere Jahre zurückliegen, nicht mehr interessant. Um die historisierten Daten zu bereinigen, kann nun jeder Prozess einem Datenbereinigungs-Job zugewiesen werden. Die Datenbereinigung ist an den Customizing-Transport angebunden.
Definition
Im Standard werden drei Bereinigungsdefinitionen ausgeliefert. Neue Prozesse werden der Datenbereinigung SHORT zugewiesen. Ein Löschlauf besteht immer aus 2 Stufen.
Skript-Prozesse ohne Auswertung (SHORT)
Löschen von historischen Instanzinformationen - Standard 1 Tag
Löschen von alten Prozessdefinitionen - Standard 2 Jahre
Interaktionsprozesse mit kurzem Auswertungszeitraum (MEDIUM)
Löschen von historischen Instanzinformationen - Standard 1 Monat
Löschen von alten Prozessdefinitionen - Standard 2 Jahre
Interaktionsprozesse mit langem Auswertungszeitraum (DEFAULT)
Löschen von historischen Instanzinformationen - Standard 1 Jahr
Löschen von alten Prozessdefinitionen - Standard 2 Jahre
Zu jedem Job gibt es 2 Datumseinstellungen getrennt nach jeweils Jahr (max 99.), Monat (max. 11) und Tag (max 30). Die Einstellungen berechnen einen Wert in Tagen, wie alt die Einträge sein müssen, bevor sie gelöscht werden.
Beispiel: 1 Jahr, 6 Monate, 7 Tage => 1*365 + 6*30 + 7 = 742 Tage
Die Zeitangabe der Prozessdefinition ist dabei immer größer als die der Instanzinformationen.
Jeder Datenbereinigung können nun Prozesse zugewiesen werden. Die bisherige Zuordnung wird entfernt. Die Zuordnung kann nur für Prozesse aus der der aktuellen Customizing-Schicht erfolgen. Bei übersteuerten Prozessen gilt die Zuordnung auch für die zu Grunde liegenden Standard- oder Partnermodul-Prozesse.
Ausführung
Die Datenbereinigung startet über den Timer Systemtabellen bereinigen. Dieser startet im Standard einmal pro Tag.
Je nach Bereinigungs-Stufe werden unterschiedliche Daten der Prozesshistorie gelöscht.
Die Löschung kann nicht rückgängig gemacht werden.
Bereinigung der Instanzinformationen
Die erste Stufe löscht die Hauptdatenmenge der Prozess-Historie. Hierzu zählen die Prozessvariablen und Aktionsinformationen auch für Benutzeraktionen.
Tabellen
ACT_HI_VARINST -> ACT_GE_BYTEARRAY
ACT_HI_ACTINST -> ACT_HI_TASKINST, ACT_HI_IDENTITYLINK
ACT_HI_PROCINST
ACT_RE_PROCDEF, ACT_RE_DEPLOYMENT
ProcessInstance
ProcessWaitState
ProcessErrorLog
Beeinträchtigung in BPM
Auswertungen sind nur noch bis zum letzten Bereinigungszeitraum möglich. Der Startcount und die Abschluss-Übersicht werden verfälscht.
Bereinigung von Prozessdefinitionen
Die zweite Stufe löscht alte Versionen von Prozess-Definitionen, die in CURSOR-BPM erstellt wurden, zu denen es aber keine Instanzinformationen gibt.
Tabellen
ProcessContainer, ProcessModel
ProcessMask, ProcessSearch
Translation
Beeinträchtigung in BPM
Es ist kein alter Stand "potentiell" wiederherstellbar.
Ausführung bei noch laufenden kritischen Prozessen verhindern
Es kann sein, dass langlaufende Prozesse mit großen Transaktionen zu derselben Zeit wie die Datenbereinigung laufen und es dabei zu Datenbanksperren kommen kann. Um Probleme bei solchen kritischen Prozessen mit der Datenbank zu vermeiden, können diese Prozesse als Anwendungsvariable hinterlegt werden. Die über ein Systemtimer gestartete Aktion zur Bereinigung der Daten innerhalb der Activiti-Tabellen prüft beim Start, ob aktuell noch kritische Prozesse am Laufen sind. Ist dies der Fall, läuft die Datenbereinigung nicht los sondern es erfolgt
ein entsprechender Log-Eintrag
eine Mail-Benachrichtigung an den System-Zuständigen (zentraler Empfänger für Service-Anforderungen im System)
Der Vermerk "kritischer Prozess" erfolgt über eine Anwendungsvariable, in der die Prozessnamen der wichtigen Prozesse festgehalten werden können. Der Absender der Mail-Benachrichtigung wird in den Systemeinstellungen hinterlegt.
Konfigurationsvorschlag
Die Datenbereinigung sollte in Testsystemen und Produktivsystemen unterschiedlich eingesetzt werden. Bei Verwendung des Customizingtransports, sollte man erst die Datenbereinigung auf Entwicklung-/Testsystem mit besonderen Einstellungen durchführen, danach die Einstellungen wechseln und diese auf das Produktivsystem übertragen.
Datenbereinigung im Testsystem
In einem Testsystem werden die Prozesse entwickelt. Damit entstehen von einem Prozess eine Vielzahl von Prozessversionen, deren Prozessdefinition mit der Zeit die Datenbank und die Servercaches belastet. Daher ist es notwendig, dort die alten Prozess-Versionen aufzuräumen. Prinzipiell sollte man immer zwischendurch einen Prozessstand extern durch einen Export sichern.
Die folgenden Einstellungen, sind hierfür sinnvoll:
DEFAULT
Instanzinformationen: 1 Monat
Prozessdefinitionen: 1 Monat
MEDIUM/SHORT
Prozessdefinitionen: 1 Monat
Natürlich werden die Prozessdefinitionen von noch aktiv laufenden Prozessen nicht gelöscht. Die letzte Version eines Prozesses bleibt immer erhalten.
Datenbereinigung im Produktivsystem
Nachdem die Datenbereinigung im Testsystem durchgeführt wurde, sollte die DEFAULT Konfiguration wieder auf den Standard zurückgestellt werden. Im Produktivsystem gibt es meist nur 3 Kategorien von Prozessen:
Prozesse, die zeitgesteuert gestartet werden und/oder reine serverseitige Logiken ausführen
Prozess mit Benutzerinteraktion, deren Laufzeit aber immer unter einem Tag liegt
Prozess mit Benutzerinteraktion mit einer Laufzeit über mehrere Tage oder sogar Wochen
Lange laufende Prozessinstanzen, sind eine gute Grundlage für die Auswertung von Liegezeiten und Bearbeitungszeiten. Reine serverseitige Ausführungen dagegen, haben eine viel zu kurze Laufzeit, um dies sinnvoll auswerten zu können. Diese werden aber meist sehr häufig ausgeführt, was zu einer hohen Datenlast führen kann. Um herauszufinden wie oft welcher Prozess ausgeführt wurde, kann folgendes SQL-Statement verwendet werden.
SELECT ACT_RE_PROCDEF.NAME_, COUNT(ACT_HI_PROCINST.ID_) AS count
FROM ACT_RE_PROCDEF,ACT_HI_PROCINST
WHERE ACT_HI_PROCINST.PROC_DEF_ID_ = ACT_RE_PROCDEF.ID_
GROUP BY ACT_RE_PROCDEF.NAME_
ORDER BY count DESCFür die oben genannten Prozesskategorien, solle man auch drei verschiedene Datenbereinigungs-Einstellungen verwenden und die Prozesse dem entsprechend zuweisen.
Ungültige Variablen löschen
In älteren Version kann es dazu kommen, das Variablen vom Typ IScriptWorkSpace für laufende aber wartende Instanzen in der Datenbank verblieben sind. Durch ein Update werden die Variablen ungültig und müssen gelöscht werden.
/* Selection der Prozess-Instanzen */
SELECT ACT_HI_PROCINST.*
FROM ACT_RU_EXECUTION, ACT_RU_VARIABLE, ACT_HI_PROCINST
WHERE ACT_HI_PROCINST.ID_ = ACT_RU_EXECUTION.PROC_INST_ID_
AND ACT_RU_EXECUTION.ID_ = ACT_RU_VARIABLE.EXECUTION_ID_
AND ACT_RU_VARIABLE.NAME_ = 'workSpace'
/* Selection der Prozess-Ids */
SELECT DISTINCT NAME_
FROM ACT_RE_PROCDEF
WHERE ID_ IN
(SELECT ACT_RU_EXECUTION.PROC_DEF_ID_
FROM ACT_RU_EXECUTION, ACT_RU_VARIABLE
WHERE ACT_RU_EXECUTION.ID_ = ACT_RU_VARIABLE.EXECUTION_ID_ AND ACT_RU_VARIABLE.NAME_ = 'workSpace')Diese Variablen können aus den Instanzen problemlos gelöscht werden, da sie nach Ablauf einer Client-Session ungültig sind.
/* BLOB-History-Daten löschen */
DELETE FROM ACT_GE_BYTEARRAY WHERE ID_ IN
(SELECT BYTEARRAY_ID_ FROM ACT_HI_VARINST WHERE NAME_ = 'workSpace')
/* ORACLE */
CREATE TABLE TMPACT_GE_BYTEARRAY AS
(SELECT BYTEARRAY_ID_ FROM ACT_RU_VARIABLE WHERE NAME_ = 'workSpace')
/* MSSQL /*
SELECT BYTEARRAY_ID_ INTO TMPACT_GE_BYTEARRAY FROM ACT_RU_VARIABLE WHERE NAME_ = 'workSpace'
/* Variablen löschen */
DELETE FROM ACT_HI_VARINST WHERE NAME_ = 'workSpace'
DELETE FROM ACT_RU_VARIABLE WHERE NAME_ = 'workSpace'
/* BLOB-Runtime-Daten löschen */
DELETE FROM ACT_GE_BYTEARRAY WHERE ID_ IN
(SELECT BYTEARRAY_ID_ FROM TMPACT_GE_BYTEARRAY)
DROP TABLE TMPACT_GE_BYTEARRAY