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:

MQDWP_SCHEDTIME MQDWP_BADDR AH_IDNR AH_OH_IDNR AH_CLIENT AH_NAME USR_FIRSTNAME USR_LASTNAME USR_EMAIL1 MQDWP_Msg
07/03/2017 06:03:43 *CP002#00000029 1163134 1004002 1000 ADMIN/1000  Philipp  Elmer philipp@philippelmer.com [XML]
07/03/2017 06:13:33 *CP002#00000029 1163134 1004002 1000 ADMIN/1000 Philipp  Elmer philipp@philippelmer.com [XML]

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!

Von |2017-07-22T10:05:11+02:0014. Juli 2017|Kategorien: AutomicBlog|Kommentare deaktiviert für Wer killt gerade meine Automation Engine?!?

Share This Story!

And then it happens again. Horrified, the administrator observes how two or three DWPs (Dialog Work Processes) one after the other stop responding. Ten minutes later, the first one is even grayed out, the system reports that it has lost the connection to the process.

So, what happened?

A user has made search queries to the Automation Engine. This can lead to strong performance problems. Usually, one of the following two types of searches is responsible:

  • Complex Object Searches mainly cause problems on systems with many objects. This only happens with the object search from the Java User Interface, the AWI uses a search index and thereby prevents it.
  • Selective Statistics, i.e. querying for statistics, can cause long-lasting searches. This function is only available to users who also have the appropriate privilege.

With searches like these, the data in the Automation Engine Database must be searched, which can take a few seconds or even minutes. And because neither Automic nor the administrator can predict what the users are asking, they can not create DB indices for it – the overhead for these indices would be too high.

This is why the difficulties mentioned in the beginning of the article occur. The DWP processing query stops responding while waiting for the database response. It does not write new log entries. It looks like it’s frozen. And after a fixed timeout interval (default 10 minutes), the DWP is grayed out in the system overview, the system reports that the connection to the process has been lost.

That’s not good! A DWP has lost connection to the AE!

It gets even worse, when the searching user is impatient. In the user interface, he can not see the search is still running. So he just starts the search again… and again… and again.

Each time the search gets submitted to another DWP and everything gets worse.

What can you do about it?

Many administrators know the problem, but do not know what to do about it.

As I said before, the AWI already solves the first part of the problem. Object searches are now solved simply by a search index.

And selective statistics is available only to users, who have the necessary privilege.

Does this mean, there’s no problem at all?

No, the problem is still there, as not everyone uses the AWI and sometimes the privilege may or should not be withdrawn from all users.

In these cases, there is no real solution. But I want to show you how to find out which users caused the problem. This gives you the opportunity to intervene and to explain the issue to the user.

For this, you need the table MQDWP.

MQDWP

The table MQDWP (from V11.2 upwards it’s MQ1DWP and MQ2DWP) is the so-called Message Queue of Dialog Work Processes. Here, every user query is entered here by the Communication Processes to be handled by the DWPs.

One note: As of V11.2, you must first determine whether MQ1DWP or MQ2DWP is active. You can find the information in the column MQ Set of the system overview or in the table MQSRV, column MQSRV_MQSet.

Three columns of the table are particularly interesting:

MQDWP-BADDR

This is the “back address”, the address to which the result of the DWP task should be sent. It contains the user session in the format * CPxxx # 00000000.

This session ID can be found in the table AH in the column AH_Infotext, or as of V11.2 in the table AUSR in the column AUSR_CADR.

MQDWP_SchedTime

In the column MQDWP_SchedTime, you find the time of the query – usually a time in the past. This is the crucial indicator of how long the request is already running.

Like most time stamps in the AE database MQDWP_SchedTime is given in UTC.

MQDWP_Msg

This column contains the actual request in XML format. In Oracle, this column is a BLOB; in MS SQL, the data type is VARBINARY. In either case, you must convert the data type to read the XML content.

Query of the DWP entries

The following query will give you a list of all DWP entries sorted by date – including a column with the user session.

In my example, the MQ Set 1 is active, so the query goes to 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

The output looks like this:

MQDWP_SCHEDTIME MQDWP_BADDR AH_IDNR AH_OH_IDNR AH_CLIENT AH_NAME USR_FIRSTNAME USR_LASTNAME USR_EMAIL1 MQDWP_Msg
07/03/2017 06:03:43 *CP002#00000029 1163134 1004002 1000 ADMIN/1000  Philipp Elmer  philipp@philippelmer.com [XML]
07/03/2017 06:13:33 *CP002#00000029 1163134 1004002 1000 ADMIN/1000  Philipp  Elmer philipp@philippelmer.com [XML]

Further Info about MQDWP_Msg

In the XML in MQDWP_Msg you get more information about user queries:

    • The XML attribute “useridnr” contains the OH_Idnr of the User.
    • The XML Attribute “session” contains the AH_Idnr (i.e. the RunID) of the user session.
    • The XML item “request” contains the attribute “name”, which tells you, the type of the activity, e.g. “setsearch” (n object search), “getactivities” (a refresh of the activity window), or “getstatistics” (a statistics window or a statistics search).

Problem solved, thanks to SQL

The example shows how useful it is, to have solid knowledge about SQL when working with the Automation Engine. You only need seconds to find out who is responsible for the query.

Do you want to better understand the AE DB structure? Do you want to know where in which tables and columns you can find what information? Do you want to learn querying techniques?

And do you want to do it all in one of the most beautiful cities in the world at the Advent season?

The come to the DB Workshop in Vienna!

Von |2022-06-30T13:07:39+02:0014. Juli 2017|Kategorien: AutomicBlog|Kommentare deaktiviert für Who killed my AE?!?

Share This Story!

Titel

Nach oben