Der Datenbankschedule für den zentralen Dispatcher wird durch den Datenbankschedule QBM_PWatchDog on <database> gestartet. Der zentrale Dispatcher übernimmt die Steuerung der Verarbeitung und verteilt die Aufträge der DBQueue an die einzelnen Slots.
Bei jedem Lauf des zentralen Dispatchers wird zunächst die Anzahl der aktuell verfügbaren Slots ermittelt, die für den aktuellen Lauf verwendet werden können. Je mehr Last auf dem Datenbankserver vorhanden ist, desto weniger Slots können aktuell verwendet werden, mindestens werden jedoch zwei Slots verwendet.
Die Anzahl der aktuell verfügbaren Slots ergibt sich aus :
Anzahl aktuell verfügbarer Slots = Anzahl der maximal verfügbaren Slots - Betrag für alle Prozesse der eigenen Datenbank - Betrag für Prozesse auf anderen Datenbanken des Servers
Der zentrale Dispatcher startet die Datenbankschedules der aktuell verfügbaren Slots einmalig. Jeder Datenbankschedule ist mit einem Prozess eingerichtet, der die Aufträge für genau diesen Slot ausführt.
Sobald Aufträge in die DBQueue eingetragen werden, wird der zentrale Dispatcher benachrichtigt. Der zentrale Dispatcher verteilt die Aufträge in die einzelnen Slots und benachrichtigt die Prozesse der Slots, dass Aufträge zur Verarbeitung anstehen. Jeder Prozess verarbeitet die Aufträge, die für seinen Slot eingestellt werden. Nach Beendigung seines Auftrags sendet jeder Prozess eine Benachrichtigung an den zentralen Dispatcher und wartet auf neue Aufträge.
Der zentrale Dispatcher prüft in definierten Abständen, ob die Slots noch aktiv sind und verteilt neue Aufträge an die Slots. Sind keine Aufträge in der DBQueue vorhanden, geht der zentrale Dispatcher in den Wartezustand und wartet auf die Benachrichtigung über neue Aufträge.
Nach Ablauf der Laufzeit werden die Aufträge aktuell verwendeter Slots noch abgearbeitet. Anschließend werden die Datenbankschedules der Slots gestoppt und der zentrale Dispatcher beendet. Weitere Informationen finden Sie unter Kommunikation des zentralen Dispatchers mit den einzelnen Slots.
Abbildung 66: Steuerung der Verarbeitung
Der zentrale Dispatcher ermittelt die Einträge der DBQueue (Tabelle DialogDBQueue) und verschiebt die Aufträge in die Tabelle QBMDBQueueCurrent mit der Zuordnung Auftrag pro Slot.
Name des Auftrags | Objekt |
---|---|
OrgRoot | A |
OrgRoot | B |
ADSAccountInADSGroup | X |
ADSAccountInADSGroup | Y |
ADSAccountInADSGroup | Z |
Slotnummer | Name des Auftrags | Objekt |
---|---|---|
001 | OrgRoot | A |
001 | OrgRoot | B |
002 | ADSAccountInADSGroup | X |
002 | ADSAccountInADSGroup | Y |
002 | ADSAccountInADSGroup | Z |
Jeder Prozess verarbeitet die Aufträge, die für seinen Slot in die Tabelle QBMDBQueueCurrent eingestellt werden. Folgeaufträge, die aus der Verarbeitung resultieren, werden in die Tabelle DialogDBQueue eingestellt.
Wenn ein Prozess seine Aufträge abgearbeitet hat und keine weiteren Aufträge anstehen, wird die Slotnummer in der Tabelle QBMDBQueueCurrent durch den Prozess selbst auf "0" gesetzt. Der Eintrag verbleibt zunächst in der Tabelle QBMDBQueueCurrent, wird jedoch nicht mehr beachtet (da Slot 0 kein aktiver Slot ist).
Der Datenbankschedule QBM_PDBQueueProcess_Del on <database>löscht in regelmäßigen Abständen alle Einträge mit Slotnummer "0" aus der Tabelle QBMDBQueueCurrent.
Slotnummer | Bedeutung |
---|---|
001 - n | Nummer des Slots, in dem ein Auftrag zu verarbeiten ist. |
0 | Zustand nach ordnungsgemäßer Erledigung des Auftrags. |
-1 |
Bei der Verarbeitung des Auftrags ist ein Fehler aufgetreten oder Verarbeitung wird zurückgestellt, zum Beispiel wegen laufender Synchronisation. Der zentrale Dispatcher reaktiviert diesen Auftrag. |
-2 |
Bei der Verarbeitung des Auftrags ist ein Fehler aufgetreten oder Verarbeitung wird zurückgestellt, zum Beispiel wegen Blockierungen. Der zentrale Dispatcher reaktiviert diesen Auftrag. |
-3 |
Bei der Verarbeitung des Auftrags ist ein Fehler aufgetreten oder Verarbeitung wird zurückgestellt, zum Beispiel wegen noch vorhandener Einträge in der Jobqueue. Der zentrale Dispatcher reaktiviert diesen Auftrag. |
Wenn ein Auftrag zurückgestellt werden muss, beispielsweise bei einem Verarbeitungsfehler oder bei laufender Synchronisation, dann wird die Slotnummer in der Tabelle QBMDBQueueCurrent durch den Prozess selbst auf "-1" gesetzt. Sind keine Aufträge in der DBQueue vorhanden, werden diese Aufträge reaktiviert. Spätestens beim nächsten Lauf des zentralen Dispatchers werden die zurückgestellten Aufträge wieder in die DBQueue eingestellt. Damit werden zurückgestellte Aufträge spätestens nach Ablauf der maximalen Laufzeit reaktiviert.
|
HINWEIS: Das Zurückstellen von DBQueue Aufträgen wird im Systemprotokoll aufgezeichnet. |
Konfigurationsparameter | Bedeutung |
---|---|
QBM\DBQueue\DefaultRuntime |
Der Konfigurationsparameter legt fest, wie groß das Laufintervall des DBQueue Prozessors sein soll. Der Standardwert ist 90 Sekunden. |
QBM\DBQueue\ChangeLimitMin |
Der Konfigurationsparameter definiert den unteren Grenzwert für Änderungen (Einfügen, Ändern oder Löschen) innerhalb einer einzelnen Operation. Der Standardwert ist 3000. |
QBM\DBQueue\ChangeLimitMax |
Der Konfigurationsparameter definiert den oberen Grenzwert für Änderungen (Einfügen, Ändern oder Löschen) innerhalb einer einzelnen Operation. Der Standardwert ist 50000. |
Um die Gesamtzeit der Verarbeitung der DBQueue Aufträge zu reduzieren, sind einige der Prozeduren des DBQueue Prozessors für die Mengenverarbeitung gekennzeichnet. Sind mehrere Einträge für einen derart gekennzeichneten Auftrag in der DBQueue vorhanden, dann schaltet der DBQueue Prozessor von Einzelverarbeitung auf Mengenverarbeitung.
Es ist ein Mechanismus implementiert, anhand dessen entschieden wird, ob die Umstellung auf Mengenverarbeitung gegenüber der Einzelverarbeitung zu einer Zeitersparnis führen würde. Dazu werden zunächst 25 Einzelverarbeitungen eines Auftrages ausgeführt und die Verarbeitungszeiten ermittelt. Alle weiteren Einträge eines Auftrages, werden über Mengenverarbeitung abgearbeitet und die minimale und maximale Ladezeit für eine rentable Mengenverarbeitung bestimmt. Die Aktualisierung der Ladezeiten erfolgt durch ein selbstoptimierendes Berechnungsverfahren. Das eingesetzte Verfahren hat zur Folge, dass sich der DBQueue Prozessor erst "einschwingen" muss, insbesondere nach einer initialen Schemainstallation oder nach Systemänderungen wie beispielsweise Speicherzuwachs des Datenbankservers. Über den Konfigurationsparameter "Common\DBQueue\DefaultRuntime" können Sie festlegen, wie groß das Laufintervall des DBQueue Prozessors sein soll. Der Standardwert ist 90 Sekunden. Dies entspricht dem Zeitraum, für den über das Berechnungsverfahren eine gute Auslastung erzielt wird.
Als Schutz vor Überladung bei zu großen Datenmengen können Grenzwerte für die zu bearbeitende Ergebnismenge definiert werden. Die Steuerung erfolgt über die Konfigurationsparameter "QBM\DBQueue\ChangeLimitMin" und QBM\DBQueue\ChangeLimitMax.
© 2021 One Identity LLC. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy