In der Prozesshistorie (Tabelle JobHistory) werden die verarbeiteten Prozesse aufgezeichnet. Die Prozesshistorie können Sie im Job Queue Info analysieren. Ausführliche Informationen finden Sie im One Identity Manager Handbuch zur Prozessüberwachung und Fehlersuche.
Um Meldungen in der Prozesshistorie aufzuzeichnen
-
Prüfen Sie im Designer, ob der Konfigurationsparameter Common | ProcessState | JobHistory aktiviert ist. Anderenfalls aktivieren Sie den Konfigurationsparameter. Wählen Sie über die Option des Konfigurationsparameters den Umfang der Aufzeichnungen.
Tabelle 123: Zulässige Werte des Konfigurationsparameters Common | ProcessState | JobHistory
|
NO |
Es werden keine Meldungen in der Prozesshistorie aufgezeichnet. |
|
ALL |
Alle verarbeiteten Prozessschritte werden in Prozesshistorie aufgezeichnet. |
|
ERROR |
Es werden nur fehlerhafte Prozessschritte in Prozesshistorie aufgezeichnet. |
|
ERRORorSELECTED |
Fehlerhafte Prozessschritte und Prozessschritte, die mit der Option Prozesshistorie gekennzeichnet sind, werden in der Prozesshistorie aufgezeichnet. |
|
SELECTED |
Nur Prozessschritte, die mit der Option Prozesshistorie gekennzeichnet sind, werden in der Prozesshistorie aufgezeichnet. |
-
Legen Sie über den Konfigurationsparameter Common | ProcessState | JobHistory | TrimLongParameters fest, wie lang der Wert von Prozessparametern sein darf, die in der Prozesshistorie aufgezeichnet werden.
Die Aufzeichnungen in der Prozesshistorie sollten in regelmäßigen Abständen aus der One Identity Manager-Datenbank entfernt und archiviert werden. Der One Identity Manager bietet dazu verschiedene Verfahren an. Weitere Informationen finden Sie unter Archivieren und Löschen von Aufzeichnungen.
Um Vererbungsberechnungen als Folge einer Änderung am System zu verfolgen, wird die GenProcID in den Operationen des DBQueue Prozessor mitgeführt. Für eventuelle Folgeoperationen muss sichergestellt sein, dass es je Operation und Objekt nur einen Eintrag in der DBQueue gibt. Um derartige Prozesse abzubilden, wird für diese eine neue GenProcID vergeben und in weiteren Prozessen verwendet. Die kollidierten Prozesse und ihre GenProcID’s werden in der Tabelle DialogProcessSubstitute abgebildet.
Bei der Erzeugung neuer GenProcID für kollidierte Prozesse gelten folgende Regeln:
-
Mehrere gleiche Operationen des DBQueue Prozessor auf einem Objekt werden zu einem Prozess (einer GenProcID) zusammengeführt. Dabei werden vorhandene Ersatzprozesse genutzt, wenn die Menge ihrer Vorgänger, bezogen auf Basisprozesse, identisch ist.
-
Sollte es in der Folge zu weiteren Kollisionen kommen, so werden schon ersetzte GenProcID zuerst in ihre Ursprünge aufgelöst und dann ein neuer Ersatz gebildet.
-
Ein Ersatz gilt genau für eine Menge an Ursprungsprozessen.
Der Konfigurationsparameter QBM | DBQueue | GenProcIDReplaceLimit definiert den Grenzwert für Prozessersetzungen. Diese Maximalzahl von kollidierenden Prozessen wird in der Tabelle DialogProcessSubstitute abgebildet. Bei Bedarf können Sie den Konfigurationsparameter im Designer aktivieren und den Wert anpassen.
Verwandte Themen
Es existiert eine hierarchische Rollenstruktur bestehend aus 4 Rollen O1, O2, O3 und O4. Die Identität X ist den Rollen O1, O4 und O3 zugeordnet. Nachfolgend wird die Zuweisung von Software an die Rollen betrachtet.
Abbildung 29: Abbildung der Rollenstruktur laut Beispiel
Zwischen zwei Ausführungen des DBQueue Prozessor laufen drei Prozesse mit jeweils eigener GenProcID an der Oberfläche ab:
-
P1: Zuweisung Software A1 an die Rolle O1
-
P2: Zuweisung Software A2 an die Rolle O1
-
P3: Zuweisung Software A3 an die Rolle O2
Im Ergebnis stehen folgende Operationen in der DBQueue (Tabelle DialogDBQueue) und der Prozessinformation:
|
OrgHasApp |
O1 |
P1 |
|
OrgHasApp |
O1 |
P2 |
|
OrgHasApp |
O2 |
P3 |
Die Operation OrgHasApp bezüglich O1 kann nicht aufgeteilt werden, da für O1 die Vereinigungsmenge der Software errechnet wird. Zu diesem Zeitpunkt ist auch keine Information mehr verfügbar, welche GenProcID durch die Zuordnung welcher Software eingetragen wurde.
Um Eindeutigkeit bezüglich der Kombination Operation und Objekt zu erreichen, wird eine neue GenProcID P4 eingeführt und die beiden Operationen bezüglich O1 auf diese verdichtet. In der Tabelle DialogProcessSubstitute wird vermerkt, dass P4 die möglichen (aber in der Einzelaktion nicht eindeutigen) Vorgänger P1 und P2 hat.
|
OrgHasApp |
O1 |
P4 |
|
OrgHasApp |
O2 |
P3 |
Abhängig, ob OrgHasApp eine Operation ist, die im Einzelschritt- oder im Bulkverfahren abgearbeitet wird, kann es jetzt zu folgenden Konstellationen kommen:
- Fall 1) Die Berechnung für O1 wird ausgeführt, dann die Operation für O2.
- Fall 2) Die Berechnung für O2 wird ausgeführt, dann die Operation für O1.
- Fall 3) Die Berechnungen für O1 und O2 werden in einer Bulkoperation gleichzeitig ausgeführt.
Nach Ausführung dieser Operationen und unter der Annahme, dass sie alle zu Änderungen an den betroffenen totalen Mengen führen, ergeben sich folgende Zustände:
Fall 1) Die Berechnung für O1 wird ausgeführt, dann die Operation für O2.
|
OrgHasApp |
O2 |
P3 |
|
OrgHasApp |
O4 |
P4 |
|
OrgHasApp |
O2 |
P4 |
|
OrgHasApp |
O3 |
P4 |
|
PersonHasApp |
X |
P4 |
Vor dem nächsten Lauf des DBQueue Prozessors muss wieder eine Verdichtung der GenProcID’s vorgenommen werden, da für die Operation OrgHasApp für Objekt O2 keine Eindeutigkeit gegeben ist. P5 wird eingeführt, mit den möglichen Vorgängern P4 und P3.
|
OrgHasApp |
O2 |
P5 |
|
OrgHasApp |
O4 |
P4 |
|
OrgHasApp |
O3 |
P4 |
|
PersonHasApp |
X |
P4 |
Jetzt wird die Berechnung für O2 ausgeführt:
|
OrgHasApp |
O3 |
P5 |
|
PersonHasApp |
X |
P5 |
|
OrgHasApp |
O4 |
P4 |
|
OrgHasApp |
O3 |
P4 |
|
PersonHasApp |
X |
P4 |
Da für O3 keine Eindeutigkeit gegeben ist, wird P6 eingeführt mit den möglichen Vorgängern P4 und P5.
|
OrgHasApp |
O3 |
P6 |
|
PersonHasApp |
X |
P5 |
|
OrgHasApp |
O4 |
P4 |
|
PersonHasApp |
X |
P4 |
Nach den Berechnungen für O3 und O4 liegt folgende Situation vor:
|
PersonHasApp |
X |
P6 |
|
PersonHasApp |
X |
P5 |
|
PersonHasApp |
X |
P4 |
Für das Objekt X ist keine Eindeutigkeit gegeben, so dass P7 mit den möglichen Vorgängern P4, P5 und P6 eingeführt wird.
Fall 2) Die Berechnung für O2 wird ausgeführt, dann die Operation für O1.
|
OrgHasApp |
O1 |
P4 |
|
OrgHasApp |
O2 |
P3 |
Nach der Ausführung stehen folgende Einträge in der DBQueue:
|
OrgHasApp |
O1 |
P4 |
|
OrgHasApp |
O3 |
P3 |
Nach dem nächsten Ausführungsschritt liegt folgende Situation vor:
|
OrgHasApp |
O3 |
P3 |
|
OrgHasApp |
O4 |
P4 |
|
OrgHasApp |
O2 |
P4 |
|
OrgHasApp |
O3 |
P4 |
|
PersonHasApp |
X |
P4 |
Für die Eindeutigkeit von O3 muss ein Prozess P5 mit den möglichen Vorgängern P3 und P4 erzeugt werden:
|
OrgHasApp |
O3 |
P5 |
|
OrgHasApp |
O4 |
P4 |
|
OrgHasApp |
O2 |
P4 |
|
PersonHasApp |
X |
P4 |
Nach den Berechnungen liegt folgende Situation vor:
|
PersonHasApp |
X |
P5 |
|
PersonHasApp |
X |
P4 |
Für das Objekt X ist keine Eindeutigkeit gegeben, so dass P6 mit den möglichen Vorgängern P4 und P5 eingeführt wird.
Fall 3) Die Berechnungen für O1 und O2 werden in einer Bulkoperation gleichzeitig ausgeführt.
|
OrgHasApp |
O1 |
P4 |
|
OrgHasApp |
O2 |
P3 |
Nach dem ersten Berechnungsschritt stehen folgende Informationen in der DBQueue:
|
OrgHasApp |
O4 |
P4 |
|
OrgHasApp |
O2 |
P4 |
|
OrgHasApp |
O3 |
P4 |
|
OrgHasApp |
O3 |
P3 |
|
PersonHasApp |
X |
P4 |
Für O3 wird durch Prozess P5 mit den möglichen Vorgängern P3 und P4 Eindeutigkeit hergestellt:
|
OrgHasApp |
O4 |
P4 |
|
OrgHasApp |
O2 |
P4 |
|
OrgHasApp |
O3 |
P5 |
|
PersonHasApp |
X |
P4 |
Nach dem nächsten Berechnungsschritt ist folgender Inhalt zu finden:
|
OrgHasApp |
O3 |
P4 |
|
PersonHasApp |
X |
P4 |
|
PersonHasApp |
X |
P5 |
Nachdem im nächsten Durchlauf O3 errechnet wurde und dieser keinen neuen PersonHasApp-Eintrag erzeugt hat, da X mit P4 schon existiert, steht zum Schluss nur X mit P4 und P5.
|
PersonHasApp |
X |
P4 |
|
PersonHasApp |
X |
P5 |
Für das Objekt X ist keine Eindeutigkeit gegeben, so dass P6 mit den möglichen Vorgängern P4 und P5 eingeführt wird.
Alle im One Identity Manager protokollierten Aufzeichnungen werden zunächst in der One Identity Manager-Datenbank gespeichert. Der Anteil der historisierten Daten am Gesamtvolumen einer One Identity Manager-Datenbank sollte maximal 25 % betragen. Anderenfalls kann es zu Performance-Problemen kommen. Die Aufzeichnungen sollten in regelmäßigen Abständen aus der One Identity Manager-Datenbank entfernt und archiviert werden.
Um die aufgezeichneten Daten in regelmäßigen Abständen aus der One Identity Manager-Datenbank zu entfernen, werden folgende Verfahren angeboten:
-
Die Daten können direkt aus der One Identity Manager-Datenbank in eine One Identity Manager History Database übernommen werden. Dieses ist das Standardverfahren für die Datenarchivierung. Wählen Sie dieses Verfahren, wenn die Server auf denen die One Identity Manager-Datenbank und die One Identity Manager History Database liegen einander sehen.
-
Die Daten werden ohne Archivierung nach einer festgelegten Zeitspanne aus der One Identity Manager-Datenbank gelöscht.
Ausführliche Informationen zur Einrichtung der Archivierung von Daten in einer History Database finden Sie im One Identity Manager Administrationshandbuch für die Datenarchivierung.
Detaillierte Informationen zum Thema
