Wer killt gerade meine Automation Engine?!?

Und da passiert es plötzlich wieder. Der Administrator beobachtet entsetzt, wie zwei, drei DWPs (Dialog Work Processes) der Reihe nach nicht mehr reagieren. Zehn Minuten darauf wird der erste davon sogar ausgegraut, das System meldet, dass es die Verbindung zum Prozess verloren hat.

Was ist passiert?

Ein Anwender hat Suchanfragen auf die Automation Engine gestellt. Dadurch kann es zu starken Performance-Problemen kommen. Verantwortlich sind meistens die folgenden zwei Arten von Suchen:

• Komplexe Objektsuchen sorgen insbesondere auf Systemen mit vielen Objekten für Probleme. Das passiert nur bei der Objektsuche aus dem Java User Interface, das AWI verwendet einen Suchindex und verhindert es dadurch.
• Selektive Statistik, also die Suche nach Statistiksätzen, kann ebenfalls zu langen Suchvorgängen führen. Diese Funktion steht aber nur Nutzern zur Verfügung, die auch das entsprechend Privileg besitzen.

Bei diesen Suchvorgängen müssen die Daten in der Automation Engine Datenbank gesucht werden, das kann schon mal ein paar Sekunden oder sogar Minuten dauern. Und weil weder Automic noch der Administrator vorhersagen kann, was die Benutzer alles abfragen, können sie auch keine DB Indizes dafür erstellen – der Overhead durch diese Indizes wäre zu hoch.

Deshalb kommt es gelegentlich zu den eingangs erwähnten Schwierigkeiten. Der DWP, der die Suchanfrage verarbeitet, reagiert nicht mehr, während er auf die Antwort der Datenbank wartet. Er schreibt also keine neuen Logfileeinträge. Es sieht aus, als wäre er eingefroren. Und nach einem festgelegten Timeout Intervall (default 10 Minuten) wird der DWP in der Systemübersicht ausgegraut, d.h. das System meldet, es habe die Verbindung zum Prozess verloren.

Nicht gut! Ein DWP hat die Verbindung zur AE verloren!

Noch schlimmer wird es, wenn der suchende Benutzer ungeduldig ist. Im User Interface kann er nicht sehen, dass die Suche noch läuft. Also startet er die Suchanfrage einfach nochmal… und nochmal… und nochmal.

Jedes Mal wird die Suchanfrage an einen anderen DWP gestellt und alles wird noch schlimmer.

Was kann man dagegen tun?

Viele Administratoren kennen das Problem, wissen aber nicht, was sie dagegen tun sollen.

Wie schon gesagt, löst sich mit dem AWI ein Teil davon zum Glück von selbst. Objektanfragen werden jetzt einfach über einen Suchindex gelöst.

Und die selektive Statistik steht ja sowieso nur Anwendern zur Verfügung, die das erforderliche Privileg haben.

Also alles kein Problem?

Doch, denn nicht jeder benutzt das AWI und manchmal kann oder will man das Privileg nicht allen Usern entziehen.

In diesen Fällen gibt es keine echte Lösung. Aber ich will Ihnen zeigen, wie Sie herausfinden können, wer das Problem verursacht. Dann können Sie in einem Notfall einschreiten und die Problematik aufklären.

Dafür brauchen Sie die Tabelle MQDWP.

MQDWP

Die Tabelle MQDWP (ab V11.2 aufwärts MQ1DWP und MQ2DWP) ist die sogenannte Message Queue der Dialog Work Prozesse. Jede Benutzeranfrage wird von den Communication Processes in dieser Tabelle zur Abarbeitung durch die DWPs eingetragen.

Hinweis: Ab V11.2 müssen Sie zunächst herausfinden, ob MQ1DWP oder MQ2DWP aktiv ist. Die Informationen finden Sie in der Spalte MQ-Set der Systemübersicht oder in der Tabelle MQSRV, Spalte MQSRV_MQSet.

Drei Spalten der Tabelle sind besonders Interessant:

MQDWP-BADDR

Das ist die „Back Address“, also die Adresse, an die das Ergebnis der DWP-Aufgabe geschickt werden soll. Es handelt sich um die User-Session im Format *CPxxx#00000000.

Diese Session ID finden Sie in der Tabelle AH in der Spalte AH_Infotext, beziehungsweise ab V11.2 in der Tabelle AUSR in der Spalte AUSR_CADR.

MQDWP_SchedTime

In der Spalte MQDWP_SchedTime finden Sie den Zeitpunkt der Abfrage – in der Regel ein Zeitpunkt in der Vergangenheit. Das ist normalerweise der entscheidende Hinweis darüber, wie lange der Request schon läuft.

Wie die meisten Zeitstempel in der AE Datenbank ist auch MQDWP_SchedTime in UTC.

MQDWP_Msg

Diese Spalte enthält den eigentlichen Request im XML-Format. In Oracle ist diese Spalte ein BLOB, in MS SQL ist der Datentyp VARBINARY. In beiden Fällen muss man den Datentyp konvertieren, um den XML-Inhalt lesen zu können.

Abfrage der DWP-Einträge

Mit der folgenden Abfrage erhalten Sie eine nach Datum sortierte Liste aller DWP-Einträge – inklusive einer Spalte mit der User-Session.

In meinem Beispiel ist das MQ-Set 1 aktiv, daher geht die Abfrage auf MQ1DWP.

select MQDWP_SchedTime, MQDWP_BADDR, AH_IDNR, AH_OH_IDNR, AH_Client, AH_Name, USR_FirstName, USR_LastName, USR_Email1
, UTL_RAW.CAST_TO_VARCHAR2(DBMS_LOB.SUBSTR(MQDWP_MSG, 2000, 1))  -- Oracle
--CONVERT(VARCHAR(MAX),MQDWP_Msg)   -- T-SQL
from MQ1DWP 
inner join AH on AH_Infotext = MQDWP_BADDR and AH_Timestamp4 is null
inner join USR on AH_OH_IDNR = USR_OH_IDNR
order by MQDWP_SCHEDTIME

Die Ausgabe sieht so aus:

Weiterführende Infos zur MQDWP_Msg

Im XML in MQDWP_Msg bekommen Sie weitere Hinweise zu Abfragen der Benutzer:

• Im XML Attribut “useridnr” steht die OH_Idnr des Users.
• Im XML Attribut “session” steht die AH_Idnr (d.h. die RunID) der Usersession.
• Im XML-element “request” finden Sie beim Attribut “name”, um welche Aktion es sich handelt, z.B. “setsearch” für eine Objektsuche, “getactivities” für ein Aktivitätenfenster-Refresh oder “getstatistics” für ein Statistikfenster oder eine Statistiksuche.

Problem gelöst, dank SQL

Das Beispiel zeigt mal wieder, wie nützlich SQL-Kenntnisse beim Umgang mit der Automation Engine sind. In wenigen Sekunden finden Sie heraus, wer für die Abfrage verantwortlich ist.

Wollen Sie die AE DB Struktur besser verstehen? Wollen Sie wissen, wo in welchen Tabellen und Spalten Sie welche Informationen finden? Wollen Sie Abfragetechniken lernen?

Und wollen Sie das ganze vielleicht auch noch in einer der schönsten Metropolen der Welt zur Adventzeit machen?

Dann kommen Sie zum DB Workshop nach Wien!