1 Kurzbeschreibung
Dieses Dokument erläutert die in Comarch ERP Enterprise zur Verfügung stehenden Funktionalitäten, um Leistungsinformationen zu einem ERP-System zu gewinnen und auszuwerten. Durch die Protokollierung der vom ERP-System-Application-Server (SAS) ausgeführten Operationen mit entsprechenden Kontextinformationen, auch über einen längeren Zeitraum, ist es möglich, gezielt Engpässe in der Leistungsfähigkeit zu analysieren und Trendanalysen über das Systemverhalten in Produktivsystemen zu machen.
2 Zielgruppe
- Administratoren
- Technische Berater
- Entwickler
3 Begriffsbestimmung
Monitoringereignis
Ein Monitoringereignis ist die Ausführung einer Operation in einem Application-Server. Eine Operation wird immer in einem Kontext ausgeführt, der durch Kontextinformationen beschrieben wird. Ein Monitoringereignis umfasst die Kontextinformationen der Ausführung sowie die Ausführungszeit.
Leistungsmonitor
Ein aktiver Leistungsmonitor zeichnet während des Betriebs eines Application-Servers Leistungsinformationen auf. Leistungsinformationen enthalten die Information, wie häufig die aufgezeichneten Monitoring-Ereignisse mit welcher Laufzeit eingetreten sind. Ein Leistungsmonitor hat mehrere Zustände, die nacheinander durchlaufen werden: vorbereitet, geplant, aktiv, abgeschlossen. Nur im Zustand „aktiv“ werden Leistungsinformationen aufgezeichnet. Jeder Leistungsmonitor basiert auf einer Vorlage, die festlegt, welche Monitoring-Ereignisse ab welcher Ausführungszeit durch den Leistungsmonitor aufgezeichnet werden.
Datenbank-Leistungsmonitor
Ein Datenbank-Leistungsmonitor zeichnet die Leistungsinformationen in Business Objects auf der Repository-Datenbank auf. Die Leistungsinformationen werden auf der Datenbank über die Kontextinformationen zusammengefasst. Ein Datenbank-Leistungsmonitor kann besonders effizient Monitoring-Ereignisse aufzeichnen, die häufig mit identischen Kontextinformationen eintreten. Je unterschiedlicher die Kontextinformationen der aufgezeichneten Ereignisse sind, desto umfangreicher ist die aufgezeichnete Datenmenge. Die in der Datenbank gespeicherten Leistungsinformationen können mit Berichten oder durch das System-Cockpit ausgewertet werden.
Leistungsinformationen
Die Leistungsinformationen werden im Betrieb eines Application-Servers durch aktive Leistungsmonitore aufgezeichnet. Die Leistungsinformationen enthalten die Information, wie häufig bestimmte Monitoring-Ereignisse mit welcher Laufzeit eingetreten sind. Datenbank-Leistungsmonitore zeichnen die Leistungsinformationen in Business Objects auf der Datenbank auf.
4 Verwaltung des Monitoring
Die Leistungsinformationen können über ausgeführte technische Operationen aufgezeichnet werden. Auf Basis dieser Daten lassen sich Auswertungen erstellen, die einen Einblick in das Verhalten des Systems, auch
über einen längeren Zeitraum hinweg, ermöglichen. Das Hauptziel ist, Performance-Engpässe aufzuspüren, damit spezifische Optimierungsmaßnahmen vorgenommen werden können.
Ein Datenbank-Leistungsmonitor speichert die Leistungsinformationen in der Repository-Datenbank. Diese Daten können mit den für die Datenbank-Leistungsmonitore verfügbaren Berichten oder mit der Anwendung Systemcockpit ausgewertet werden.
4.1 Monitoring aktivieren
Auf jedem gestarteten Application-Server ist standardmäßig der Default-Datenbankmonitor aktiv. Um mit einem Datenbank-Leistungsmonitor Leistungsinformationen aufzuzeichnen, ist keine weitere Aktivierung notwendig.
4.2 Monitoring deaktivieren
Mit dem Tool „wrkmon“ kann die Aufzeichnung von Leistungsinformationen durch aktive Datenbank-Leistungsmonitore auf einem gestarteten Application-Server bis zum nächsten Neustart deaktiviert werden.
Mithilfe der ERP-Property com.cisag.sys.kernel.MonitoringMode=0 können Sie die Aufzeichnung von Leistungsinformationen für alle Leistungsmonitore deaktivieren.
4.3 Leistungsmonitore
Um Leistungsinformationen aufzuzeichnen, muss ein Leistungsmonitor angelegt werden. Zur Verwaltung der Leistungsmonitore dient die Anwendung „Leistungsmonitore“. Wenn ein Leistungsmonitor aktiv ist, dann protokolliert er Informationen zu den technischen Operationen gemäß seiner Konfiguration. Wurde der Leistungsmonitor nicht auf einem bestimmten Application-Server eingeschränkt, ist dieser auf allen Application-Servern des Systems mit aktiv. Pro Application-Server können maximal 32 Leistungsmonitore aktiv sein.
4.3.1 Konfiguration des Leistungsmonitors
Die Leistungsmonitore werden über die Anwendung „Leistungsmonitore“ verwaltet.
Die Konfiguration eines Leistungsmonitors basiert auf einer vorgegebenen Vorlage. In einer Vorlage ist festgelegt, welche der protokollierbaren Monitoring-Ereignisse, in Abhängigkeit von der Operation und dem angegebenen Schwellwert bezüglich der Ausführungszeitdauer, aufgezeichnet werden.
Zusätzlich kann über die Anwendung die Menge der protokollierenden Monitoring-Ereignisse weiter eingeschränkt werden. So ist es möglich, Monitoring-Ereignisse nur für einen bestimmten Session-Typ, einen Application-Server, eine Anwendung, einen Bericht oder einen Benutzer zu protokollieren.
Zur Konfiguration eines Leistungsmonitors steht eine Auswahl von Vorlagen zur Verfügung, die nachstehend beschrieben werden.
4.3.1.1 Datenbank-Leistungsmonitor für die Analyse der Antwortzeiten
Die zugehörige Vorlage-Datei heißt „DatabaseMonitor-Default.xml“. Mit dieser Vorlage können Sie die Antwortzeiten des Systems bei Dialogzugriffen, Ausgabeaufträgen, ODBC-Zugriffen und Verarbeitungsaufträgen messen. Diese Leistungsinformationen bilden die Grundlage für die erste Analyse der Antwortzeiten.
Der Standard-Datenbank-Leistungsmonitor verwendet diese Vorlage und ist auf jedem System aktiv. Damit können Sie jederzeit das Antwortverhalten aller Application-Server kontrollieren.
Die folgenden Operationen werden aufgezeichnet:
| Operation |
| ROUNDTRIP_CLIENT |
| ROUNDTRIP_GUI |
| ROUNDTRIP_PERFORM_ACTION |
| ROUNDTRIP_ODBC |
| OUTPUT_JOB_EXECUTE |
| ROUNDTRIP_PERFORM_ACTION_WAIT_TIME |
| APPLICATION_ACTION_EXECUTE |
Die Leistungsinformationen werden nach den folgenden Kontextinformationen differenziert aufgezeichnet:
| Kontextinformation |
| Application-Server |
| Datenbank |
| Session-Typ |
| Anwendung |
| Aktion |
| Bericht |
Die Daten werden für die letzten 3 Tage, 3 Wochen und 3 Jahre aufbereitet.
4.3.1.2 Datenbank-Leistungsmonitor zur Analyse des Datenbankzugriffs
Die zugehörige Vorlage-Datei heißt „DatabaseMonitor-DatabaseAnalysis.xml“. Mit dieser Vorlage werden alle Datenbankzugriffe von Anwendungen oder Berichten aufgezeichnet. Damit können Sie herausfinden, welche Anwendungen oder Berichte besonders viele oder aufwendige Datenbankzugriffe verursachen.
Die Verwendung dieser Vorlage kann das Antwortverhalten eines Application-Servers beeinträchtigen. Verwenden Sie diesen Leistungsmonitor nur in Entwicklungs- oder Test-Systemen bzw. auf einen speziell dafür eingerichteten Application-Server. Schränken Sie diesen Leistungsmonitor auf einen Application-Server oder einen Benutzer ein.
Die folgenden Operationen werden aufgezeichnet:
| Operation |
| DB_ACQUIRE_CONNECTION |
| DB_STATEMENT_EXECUTE |
| DB_TRANSACTION_COMMIT |
| DB_TRANSACTION_ROLLBACK |
Die Leistungsinformationen werden nach den folgenden Kontextinformationen differenziert aufgezeichnet:
| Kontextinformation |
| Application-Server |
| Datenbank |
| Session-Typ |
| Anwendung |
| Datenbankabfrage |
| Bericht |
Die Daten werden für die letzten 3 Tage, 2 Wochen und das letzte Jahr aufbereitet.
4.3.1.3 Datenbank-Leistungsmonitor zur vollständigen Analyse
Die zugehörige Vorlage-Datei heißt „DatabaseMonitor-FullAnalysis.xml“. Diese Vorlage zeichnet alle für Datenbank-Leistungsmonitore verfügbaren Operationen auf und erzeugt damit umfangreiche Leistungsinformationen. Damit können Sie eine detaillierte Analyse des Antwortverhaltens und des Datenbankzugriffs einer Anwendung oder eines Berichts durchführen.
Die Verwendung dieser Vorlage kann das Antwortverhalten eines Application-Servers deutlich beeinträchtigen. Verwenden Sie diesen Leistungsmonitor nur in Entwicklungs- oder Test-Systemen bzw. auf einen speziell dafür eingerichteten Application-Server. Schränken Sie diesen Leistungsmonitor auf einen Application-Server oder einen Benutzer ein.
Die folgenden Operationen werden aufgezeichnet:
Die Leistungsinformationen werden nach den folgenden Kontextinformationen differenziert aufgezeichnet:
| Kontextinformation |
| Application-Server |
| Datenbank |
| Session-Typ |
| Anwendung |
| Aktion |
| Suche |
| Datenbankabfrage |
| Bericht |
Die Daten werden für die letzten 3 Tage, 2 Wochen und das letzte Jahr aufbereitet.
4.3.2 Aufzeichnung durch Datenbank-Leistungsmonitore
Die Leistungsinformationen eines aktiven Datenbank-Leistungsmonitors werden in die Repository-Datenbank in das Business Object „com.cisag.sys.kernel.obj.MonitoringData“ geschrieben. Die Daten werden von jedem Application-Server einmal pro Stunde für die kleinste aufgezeichnete Zeiteinheit, dies sind meist Tage, gespeichert. Der Verarbeitungsauftrag „Leistungsinformationen reorganisieren“ fasst die Aufzeichnungen mehrerer Application-Server zusammen und überträgt die Aufzeichnungen auf gröbere Zeiteinheiten, wie beispielsweise Wochen und Jahre. Veraltete Leistungsinformationen werden abhängig von der gewählten Vorlage gelöscht.
Sie sollten daher den Verarbeitungsauftrag „Leistungsinformationen reorganisieren“ am besten täglich einplanen.
5 Protokollierte Leistungsinformationen
Leistungsmonitore zeichnen die Leistungsinformationen zu bestimmten im Application-Server aufgetretenen Monitoring-Ereignissen auf. Die von einem Leistungsmonitor aufzuzeichnenden Monitoring-Ereignisse werden in dessen Konfiguration festgelegt. Die zu dem Monitoring-Ereignis zugehörigen Kontextinformationen und Ausführungszeiten werden bei Datenbank-Leistungsmonitoren in der Datenbank gespeichert.
5.1 Kontextinformationen
Die Kontextinformationen beschreiben den Ausführungskontext eines Monitoring-Ereignisses. Im Folgenden wird beschrieben, welche Kontextinformation ein Monitoring-Ereignis besitzt.
5.1.1 Operationstyp
Der Operationstyp gibt den Typ der durch den Application-Server ausgeführten Operation an. Nachfolgend werden die als Monitoring-Ereignis protokollierbaren Operationen aufgeführt.
5.1.1.1 Datenbankverbindung öffnen (DB_OPEN_CONNECTION)
Der Application-Server hat eine Datenbankverbindung über JDBC zur Datenbank geöffnet. Eine Datenbankverbindung wird benötigt, um Daten in die Datenbank zu schreiben oder Daten von der Datenbank zu lesen. Das Öffnen einer Datenbankverbindung ist eine teure Operation. Standardmäßig wird deshalb eine einmal geöffnete Datenbankverbindung vom SAS offen gehalten und für den nächsten Datenbankzugriff weiter verwendet („Connection-Pooling“). Somit sollte die Anzahl der durch die Operation DB_OPEN_CONNECTION protokollierten Verbindungen gering sein.
Eine übliche Ausführungszeit dieser Operation liegt zwischen 0-500 ms. Wenn Datenbank-Server und SAS nicht auf demselben Rechner laufen, kann die benötigte Zeit für die Netzwerkkommunikation einen großen Anteil an der gemessenen Ausführungszeit haben. Beim Auftreten von permanent höheren Werten sollte das Problem analysiert werden.
5.1.1.2 Datenbankverbindung schließen (DB_CLOSE_CONNECTION)
Der Application-Server hat eine offene Datenbankverbindung über JDBC geschlossen. Diese Operation sollte in normalen Betrieb so gut wie nie aufgezeichnet worden sein, da der SAS eine einmal geöffnete Datenbankverbindung nicht wieder schließt. Anderenfalls liegt eine Fehlkonfiguration das SAS oder des DBMS vor.
Eine übliche Ausführungszeit dieser Operation liegt zwischen 0-500 ms. Wenn Datenbank-Server und SAS nicht auf demselben Rechner laufen, kann die benötigte Zeit für die Netzwerkkommunikation einen großen Anteil an der gemessenen Ausführungszeit haben.
5.1.1.3 Datenbankverbindung anfordern (DB_ACQUIRE_CONNECTION)
Für jeden Lesezugriff sowie beim Commit einer Datenbank-Transaktion wird eine Datenbankverbindung aus dem Pool für Datenbankverbindungen angefordert.
Je häufiger Datenbankverbindungen angefordert werden, desto mehr Datenbankzugriffe werden abgesetzt. Die Anzahl der Anforderungen ist also ein Maß für die Anzahl der Datenbankzugriffe einer Anwendung oder einer Aktion.
5.1.1.4 Datenbankanweisung ausführen (DB_STATEMENT_EXECUTE)
Der Application-Server hat eine SQL-Anweisung auf der Datenbank ausgeführt, um Daten zu lesen oder zu schreiben. Durch Auswertung dieser Operation kann ermittelt werden, welche ausgeführte Datenbankanweisung wie viel Zeit benötigt hat. Die konkrete Datenbankanweisung kann über Identifikation ermittelt werden. Weiterhin sind in der Regel zusätzliche Informationen zum Ausführungskontext verfügbar, z. B. in welcher Anwendung die Datenbankanweisung ausgeführt wurde.
Die Ausführungszeit der Datenbankanweisung kann in Abhängigkeit von deren Komplexität stark schwanken. Einfache Datenbankanweisungen sollten nicht länger als 100 ms dauern, komplexere Datenbankanweisungen nicht länger als 3 s. Wenn Datenbank-Server und SAS nicht auf demselben Rechner laufen, kann die benötigte Zeit für die Netzwerkkommunikation einen großen Anteil an der gemessenen Ausführungszeit haben. Bei permanent längeren Ausführungszeiten sollte eine Analyse der Ursache erfolgen.
5.1.1.5 Datenbank-Transaktion bestätigen (DB_TRANSACTION_COMMIT)
Der Application-Server hat eine Datenbanktransaktion erfolgreich beendet. Alle Datenbankoperationen finden innerhalb einer Datenbank-Transaktion statt. So werden durch ein- oder mehrere Datenbankanweisungen vorgenommene Änderungen an den Daten erst durch den erfolgreichen Abschluss der Transaktion (commit) permanent und für andere sichtbar.
Eine übliche Ausführungszeit dieser Operation liegt zwischen 0-100 ms. Wenn Datenbank-Server und SAS nicht auf demselben Rechner laufen, kann die benötigte Zeit für die Netzwerkkommunikation einen großen Anteil an der gemessenen Ausführungszeit haben. Bei permanent längeren Ausführungszeiten sollte eine Analyse der Ursache erfolgen.
5.1.1.6 Datenbank-Transaktion abbrechen (DB_TRANSACTION_ROLLBACK)
Der Application-Server hat eine Datenbanktransaktion abgebrochen. Alle in der Transaktion durch Datenbankanweisungen vorgenommenen Änderungen an den Daten wurden verworfen. Das System bricht nur im Fehlerfall eine Datenbank-Transaktion ab. Diese Operation sollte also nur sehr selten und im Normalfall gar nicht auftreten.
Eine übliche Ausführungszeit dieser Operation liegt zwischen 0-100 ms. Wenn Datenbank-Server und SAS nicht auf demselben Rechner laufen, kann die benötigte Zeit für die Netzwerkkommunikation einen großen Anteil an der gemessenen Ausführungszeit haben. Bei permanent längeren Ausführungszeiten sollte eine Analyse der Ursache erfolgen.
5.1.1.7 Laden einer Business-Object-Instanz (OM_GET_OBJECT)
Der Application-Server hat eine Business-Object-Instanz über den Object-Manager mit der Methode „getObject()“ geladen. Wenn die Business-Object-Instanz nicht im Cache gefunden wurde, dann wird auf die Datenbank zugegriffen. In diesem Fall wird die zugehörige Datenbankanweisung durch eine DB_STATEMENT_EXECUTE-Operation protokolliert. Das Aufzeichnen dieser
Operation ist nur zum Entwicklungszeitpunkt sinnvoll, wenn das Verhalten einer konkreten Anwendung interessant ist. Protokolliert werden das betroffene Business Object und der für den Zugriff benutzte Schlüsseltyp.
Bei dieser Operation wird keine Zeitmessung vorgenommen.
5.1.1.8 Laden einer Menge von Business-Object-Instanzen (OM_GET_OBJECT_ARRAY)
Der Application-Server hat eine Menge von Business-Object-Instanzen über den Object-Manager mit der Methode „getObjectArray()“ geladen. Wenn Business-Object-Instanzen nicht im Cache gefunden wurden, dann wird auf die Datenbank zugegriffen. In diesem Fall wird die zugehörige Datenbankanweisung durch eine „DB_STATEMENT_EXECUTE“-Operation protokolliert. Das Aufzeichnen dieser Operation ist nur zum Entwicklungszeitpunkt sinnvoll, wenn das Verhalten einer konkreten Anwendung interessant ist. Zusätzlich werden Informationen über die Art des Zugriffes protokolliert. Das sind das betroffene Business Object, die Anzahl der zurück gelieferten Business-Object-Instanzen und der verwendete Schlüsseltyp.
Bei dieser Operation wird keine Zeitmessung vorgenommen.
5.1.1.9 Anfordern eines Business Object-Iterators (OM_GET_OBJECT_ITERATOR)
Der Application-Server hat einen Object-Iterator über den Object-Manager mit der Methode „getObjectIterator()“ angefordert. Dabei wird die angegebene OQL-Anweisung in eine datenbankspezifische SQL-Anweisung übersetzt und das Prepared-Statement für den Datenbankzugriff initialisiert. Die OQL-Anweisung kann über die protokollierte Identifikation ermittelt werden. Die gemessene Zeitdauer beinhaltet die Ausführungszeit der resultierenden SQL-Anweisung. Die Zeit für das Laden der Ergebnisse ist in der gemessenen Zeitdauer nicht enthalten. Das Aufzeichnen dieser Operation ist in der Regel nur zum Entwicklungszeitpunkt sinnvoll, wenn das Verhalten einer konkreten Anwendung interessant ist.
Eine übliche Ausführungszeit dieser Operation liegt zwischen 0-500 ms.
5.1.1.10 Anfordern eines Result-Sets (OM_GET_RESULT_SET)
Der Application-Server hat ein Result-Set über den Object-Manager mit der Methode „getResultSet()“ angefordert. Dabei wird die angegebene OQL-Anweisung in eine datenbankspezifische SQL-Anweisung übersetzt und das Prepared-Statement für den Datenbankzugriff initialisiert. Die OQL-Anweisung kann über die protokollierte Identifikation ermittelt werden. . Die gemessene Zeitdauer beinhaltet die Ausführungszeit der resultierenden SQL-Anweisung. Die Zeit für das Laden der Ergebnisse ist in der gemessenen Zeitdauer nicht enthalten. Das Aufzeichnen dieser Operation ist in der Regel nur zum Entwicklungszeitpunkt sinnvoll, wenn das Verhalten einer konkreten Anwendung interessant ist.
Eine übliche Ausführungszeit dieser Operation liegt zwischen 0-500 ms.
5.1.1.11 Anfordern eines UPDATE-Anweisung (OM_GET_UPDATE_STATEMENT)
Der Application-Server hat eine UPDATE-Anweisung über den Object-Manager mit der Methode „getUpdateStatement()“ angefordert. Dabei wird die angegebene OQL-Anweisung in eine datenbankspezifische SQL-Anweisung übersetzt und das Prepared-Statement für den Datenbankzugriff initialisiert. Die OQL-Anweisung kann über die protokollierte Identifikation ermittelt werden. Die Ausführungszeit der resultierenden SQL-Anweisung selbst ist in der gemessenen Zeitdauer nicht enthalten. Das Aufzeichnen dieser Operation ist in der Regel nur zum Entwicklungszeitpunkt sinnvoll, wenn das Verhalten einer konkreten Anwendung interessant ist.
Eine übliche Ausführungszeit dieser Operation liegt zwischen 0-50 ms.
5.1.1.12 Registrieren einer Business-Object-Instanz zum Speichern (OM_PUT_OBJECT)
Der Application-Server hat eine Business-Object-Instanz über den Object-Manager mit der Methode „putObject()“ zum Speichern registriert. Das Aufzeichnen dieser Operation ist nur zum Entwicklungszeitpunkt sinnvoll, wenn das Verhalten einer konkreten Anwendung interessant ist.
Bei dieser Operation wird keine Zeitmessung vorgenommen.
5.1.1.13 Ausführen einer OQL-Suche (CIS_OQL_SEARCH_STATEMENT_EXECUTE)
Der Application-Server hat eine OQL-Suche ausgeführt. Das sind typischerweise Anwendungs- und Feldwertehilfen. Dabei wird die aus der OQL-Suche resultierende OQL-Anweisung in eine datenbankspezifische SQL-Anweisung übersetzt und das Prepared-Statement für den Datenbankzugriff initialisiert. Die OQL-Anweisung kann über die protokollierte Identifikation ermittelt werden. Die Ausführungszeit der resultierenden SQL-Anweisung selbst ist in der gemessenen Zeitdauer nicht enthalten. Das Aufzeichnen dieser Operation ist in der Regel nur zum Entwicklungszeitpunkt sinnvoll, wenn das Verhalten einer konkreten Anwendung interessant ist.
Eine übliche Ausführungszeit dieser Operation liegt zwischen 0-50 ms.
5.1.1.14 Ausführen eines ODBC-Zugriffs (ROUNDTRIP_ODBC)
Der Application-Server hat einen Zugriff für den SOM oder für eine externe Anwendung (z. B. Crystal Reports) über die ODBC-Schnittstelle ausgeführt. Ein ODBC-Roundtrip entspricht dem Aufruf einer ODBC-Funktion während der Berichtausführung und nicht der Ausführung des Berichtes selbst. Zur Ausführung eines Berichtes können dutzende ODBC-Roundtrips erfolgen. Die für den Bericht ausgeführten SQL-Anweisungen werden jeweils über eine DB_STATEMENT_EXECUTE-Operation protokolliert.
Über die gemessene Ausführungszeit können Rückschlüsse auf die Performance der Berichtsausführung gezogen werden. Deshalb sollten Operationen mit auffällig langen Ausführungszeiten aufgezeichnet werden.
Die Ausführungszeit dieser Operation hängt sehr stark von der Komplexität des Berichts ab und liegt zwischen 0-5000 ms. Wenn Datenbank-Server, SAS sowie der SOM bzw. die externe Anwendung nicht auf demselben Rechner laufen, kann die benötigte Zeit für die Netzwerkkommunikation einen relevanten Anteil an der gemessenen Ausführungszeit haben.
5.1.1.15 Ausführen eines Browser-Zugriffs (ROUNDTRIP_GUI)
Der Application-Server hat einen Zugriff von einem Browser behandelt. Die meisten Interaktionen des Benutzers führen zu einer Kommunikation zwischen Browser und dem Application-Server, der die Benutzerinteraktion verarbeitet, die entsprechende Anwendung aufruft, welche das Ergebnis berechnet und die grafische Oberfläche aktualisiert. Die dafür benötigte Zeit wird gemessen. Diese enthält aber nicht die Zeitdauer für die Kommunikation zwischen Browser und Application-Server. Diese Operation ist interessant, um Aussagen über das Antwortverhalten auf Benutzerinteraktionen zu gewinnen. Deshalb sollten Operationen mit auffällig langen Ausführungszeiten aufgezeichnet werden.
Eine übliche Ausführungszeit dieser Operation liegt zwischen 0-5000 ms.
5.1.1.16 Ausführen eines Browser-Zugriffs mit Zugriffszeit (ROUNDTRIP-CLIENT)
Diese Operation entspricht der Operation „ROUNDTRIP-GUI“. Die gemessene Zeitdauer enthält aber zusätzlich die Zeitdauer für die Kommunikation zwischen Browser und Application-Server. Diese Zeit entspricht der in der Statuszeile des Internet Explorers angezeigten Zeitdauer für den letzten ausgeführten Roundtrip.
Eine übliche Ausführungszeit dieser Operation liegt zwischen 0-5000 ms.
5.1.1.17 Ausführen einer Anwendungsinteraktion (ROUNDTRIP_PERFORM_ACTION)
Der Application-Server hat die Methode „performAction()“ einer Anwendung ausgeführt. Wenn der Benutzer in einer Anwendung eine Interaktion auslöst, erfolgt durch die zuständige Anwendung deren Behandlung. In einer Standardanwendung wird dazu immer die Methode „performAction()“ der Anwendung aufgerufen, welche die entsprechende Anwendungslogik ausgeführt. Die dafür benötigte Zeit wird gemessen. Als Kontextinformation wird die ganzzahlige Action-ID und – falls vorhanden – der vollständige Name des zugehörigen Entwicklungsobjektes vom Typ „Action“ aufgezeichnet, um die Operation der aufgerufenen Interaktion zuordnen zu können. Diese Operation ist interessant, um die Laufzeiten von Funktionalitäten in Anwendungen zu ermitteln.
Übliche Ausführungszeiten dieser Operation liegen zwischen 0-5000 ms.
5.1.1.18 Warten auf die Ausführung einer Anwendungsinteraktion (ROUNDTRIP_PERFORM_ACTION_WAIT_TIME)
Die Anzahl der Threads zum Ausführen von Anwendungsinteraktionen ist pro Application-Server beschränkt. Der Application-Server wartet mit der Ausführung der Anwendungsinteraktion, bis ein freier Thread zur Verfügung steht.
Übliche Ausführungszeiten für diese Operationen liegen zwischen 0-50 ms. Eine erhöhte Wartezeit kann auf eine Überlastung des Application-Servers hinweisen.
5.1.1.19 Ausführen einer Anwendungsaktion (APPLICATION_ACTION_EXECUTE)
Der Application-Server hat die Methode „run()“ einer Anwendung ausgeführt. Eine bei der Anwendung eingetragene Aktion wurde ausgeführt. Diese Aktionen werden beim Ausführen von Verarbeitungsaufträgen und z.B. beim Öffnen von interaktiven Anwendungen verwendet.
Die Ausführungszeit gibt somit an, wie lange die Ausführungszeit eines Verarbeitungsauftrags war. Damit können Sie häufig ausgeführte bzw. lang laufende Verarbeitungsaufträge erkennen. Die gemessene Zeit beinhaltet bei Hintergrund-Anwendungen die Zeit, in der auf den Abschluss aller erzeugten Ausgabeaufträge gewartet wurde.
5.1.1.20 Ausführen eines Ausgabeauftrags (OUTPUT_JOB_EXECUTE)
Ein Ausgabeauftrag wurde ausgeführt. Im Unterschied zu der Operation ROUNDTRIP_ODBC wird bei OUTPUT_JOB_EXECUTE die vollständige Ausführungszeit des Ausgabeauftrags gemessen. Damit können Sie häufig ausgeführte bzw. lang laufende Ausgabeaufträge erkennen.
5.1.1.21 Erzeugen einer Dialog-Session (SESSION_DIALOG_CREATE)
Ein Benutzer hat sich auf dem Application-Server interaktiv angemeldet und dadurch eine neue Dialog-Session (interaktive Session) erzeugt. Dazu gehört das Erzeugen und Initialisieren der neuen Session bezüglich der gewählten Datenbank und den Benutzereinstellungen. Die dafür benötigte Zeit wird gemessen. Durch das Protokollieren dieser Operation können Rückschlüsse über die Anmeldeprozedur gezogen werden.
Übliche Ausführungszeiten dieser Operation liegen zwischen 100-2000 ms.
5.1.1.22 Commit einer ERP-System-Transaktion (TM_COMMIT)
Der Application-Server hat eine ERP-System-Transaktion über den Transaction-Manager erfolgreich beendet. Alle geänderten Business-Object-Instanzen und alle Änderungen durch eventuell ausgeführte UPDATE-Anweisungen wurden durch die zugehörige erfolgreich beendete Datenbanktransaktion (DB_TRANSACTION_COMMIT) persistent gemacht. Die Transaktion wurde vom Transaktions-Stack entfernt, der Shared-Cache des Application-Servers wurde aktualisiert. Die dafür benötigte Zeit wird gemessen. Das Aufzeichnen dieser Operation ist nur zum Entwicklungszeitpunkt sinnvoll, wenn das Verhalten einer konkreten Anwendung interessant ist.
Übliche Ausführungszeiten dieser Operation liegen zwischen 0-100 ms.
5.1.1.23 Rollback einer ERP-System-Transaktion (TM_ROLLBACK)
Der Application-Server hat eine ERP-System-Transaktion über den Transaction-Manager abgebrochen. Alle Änderungen wurden verworfen, es wurde keine zugehörige Datenbanktransaktion ausgeführt. Die Transaktion wurde vom Transaktions-Stack entfernt. Die dafür benötigte Zeit wird gemessen. Das Aufzeichnen dieser Operation ist nur zum Entwicklungszeitpunkt sinnvoll, wenn das Verhalten einer konkreten Anwendung interessant ist.
Bei dieser Operation wird keine Zeitmessung vorgenommen.
5.1.1.24 Sperranforderung mit Konflikt (LOCK_ACQUIRE_WAIT)
Vom Application-Server wurde eine Sperre auf eine Business-Object-Instanz beim Message-Server angefordert, welche zu diesem Zeitpunkt schon gesperrt war. Dies kann beispielsweise sein, wenn eine Business-Object-Instanz zum Ändern in einer Transaktion gesperrt ist und in einer anderen Transaktion gelesen werden soll. Dadurch musste erst auf die Freigabe gewartet werden, bis erfolgreich gesperrt werden konnte. Die dafür benötigte Zeit wird gemessen. Im normalen Betrieb sollten nur wenig Sperren mit hohen Wartezeiten auftreten. Andernfalls sollte die Ursache analysiert werden.
Übliche Ausführungszeiten dieser Operation liegen zwischen 0-10 s. Wenn Message-Server und SAS nicht auf demselben Rechner laufen, kann die benötigte Zeit für die Netzwerkkommunikation einen relevanten Anteil an der gemessenen Ausführungszeit haben.
5.1.1.25 Sperranforderung ohne Konflikt (LOCK_ACQUIRE_DIRECT)
Eine Sperre auf eine Business-Object-Instanz wurde angefordert, die sofort gewährt wurde. Das Aufzeichnen dieser Operation ist höchstens zum Entwicklungszeitpunkt sinnvoll, wenn das Verhalten einer konkreten Anwendung interessant ist.
Übliche Ausführungszeiten dieser Operation liegen zwischen 0-50 ms. Wenn Message-Server und SAS nicht auf demselben Rechner laufen, kann die benötigte Zeit für die Netzwerkkommunikation einen großen Anteil an der gemessenen Ausführungszeit haben.
5.1.2 Zeitstempel
Der Zeitstempel gibt den Endzeitpunkt der Ausführung der Operation an.
5.1.3 Session-Typ
Alle Operationen werden innerhalb einer Session ausgeführt. Eine Session (oder auch Sitzung) dient einem bestimmten Einsatzzweck, den der Session-Typ angibt. Zu einer protokollierten Operation wird der Typ der Session angegeben, in der diese ausgeführt wurde. In der folgenden Tabelle sind die möglichen Session-Typen mit einer kurzen Erläuterung aufgeführt.
| Session-Typ | Bezeichnung | Erläuterung |
| INITIALIZER | Initialisierung | Wenn eine Session neu erzeugt wird, dann befindet sich diese in der Initialisierungsphase.
Ein konkreter Session-Typ ist noch nicht zugeordnet worden. |
| SYSTEM | System | Den Session-Typ SYSTEM besitzen Sessions, die grundlegende Funktionalitäten für den Betrieb des Application-Servers ausführen. |
| BATCH | Hintergrund-verarbeitung | Sessions vom Typ BATCH führen Hintergrundanwendungen aus, die keine Benutzerinteraktion benötigen. |
| TOOL | Toolshell | Die Toolshell-Session ist die Kommandozeile des Application-Servers.
Alle dort ausgeführten Tools laufen in diesem Kontext. |
| REMOTE | Entfernter Zugriff | Eine Session vom Typ REMOTE wird erzeugt, wenn ein entfernter Zugriff auf den Application-Server stattfindet.
Da zu diesem Zeitpunkt noch nichts über den genauen Typ des entfernten Zugriffes bekannt ist, wird erstmal der Typ REMOTE vergeben und dieser dann später genauer spezifiziert. |
| DIALOG | Dialogzugriff | Bei der interaktiven Anmeldung eines Benutzers am Application-Server über den Browser wird eine Session dieses Typs erzeugt.
Alle als Folge von Benutzerinteraktionen ausgeführten Operationen in dieser Session sind diesem Session-Typ zugeordnet. |
| ODBC | ODBC-Zugriff | Eine Session, die ODBC-Abfragen vom interaktiven ODBC-Treiber bedient, hat diesen Session-Typ. Anwendungen wie z. B. Crystal Reports benutzen den interaktiven ODBC-Treiber von Comarch ERP Enterprise. |
| ODBC_SERVER | ODBC-Serverzugriff | Eine Session, die ODBC-Abfragen vom SOM bedient, hat diesen Session-Typ.
In diesem Fall ist bei der protokollierten Operation der Name des ausgeführten Berichtes angegeben. |
| KNOWLEDGESTORE | Knowledge-Store-Zugriff | Für Zugriffe auf den Knowledge Store über WEB-DAV wird eine Session mit diesem Typ verwendet. |
| RESOURCE | Ressourcen-Zugriff | Zum Laden von Bildern, Icons und ähnliches benutzt der Web-Server des Application-Servers eine Session mit diesem Typ. |
| CORBA | CORBA-Zugriff | Entfernte Zugriffe von externen Anwendungen über die CORBA-Schnittstelle des Application-Servers werden in einer Session dieses Typs behandelt. |
| WEB_SERVICES | SOAP-Zugriff | Entfernte Zugriffe von externen Anwendungen über die SOAP-Schnittstelle des Application-Servers werden in einer Session dieses Typs behandelt. |
5.1.4 Session-GUID
Die Session-GUID ist die Identifikation für die Session, in der die Operation ausgeführt wurde.
5.1.5 Application-Server
Der Name des Application-Servers, der die Operation ausgeführt hat.
5.1.6 Benutzer
Die Kennung des Benutzers, in dessen Kontext die Operation ausgeführt wurde.
5.1.7 Anwendung oder Bericht
Der Name der Anwendung wird angegeben, in der die Operation ausgeführt wurde. Alternativ ist der Name des über den SOM ausgeführten Berichtes angegeben.
5.1.8 Ausführungszeit-Kategorie
Bei der Ausführung einer Operation wird die Ausführungszeitdauer (t) gemessen und die Operation in eine Ausführungszeit-Kategorie eingeordnet. Folgende Kategorien existieren:
| Kategorie | Zeitdauer |
| 1 | 0-50 ms (0 ms <= t <= 50 ms) |
| 2 | 50-100 ms (50 ms < t <= 100 ms) |
| 3 | 100-250 ms (100 ms < t <= 250 ms) |
| 4 | 250-500 ms (250 ms < t <= 500 ms) |
| 5 | 500-1000 ms (500 ms < t <= 1000 ms) |
| 6 | 1000-2000 ms (1000 ms < t <= 2000 ms) |
| 7 | 2000-5000 ms (2000 ms < t <= 5000 ms) |
| 8 | 5000-20000 ms (5000 ms < t <= 20000 ms) |
| 9 | >20000 ms (t > 20000 ms) |
5.1.9 Ausführungszeitdauer
Die Ausführungszeitdauer der Operation in ms.
5.1.10 Identifikation der Datenbankanweisung
Eine Datenbankanweisung ist über eine 16-stellige Hexadezimalzahl identifiziert. Jeder durch den Application-Server ausgeführten SQL-, ODBC-SQL oder OQL-Anweisung wird automatisch eine Identifikation zugeordnet, über die die zugehörige Datenbankanweisung in der Anwendung „Datenbankanweisungen abfragen“ ermittelt werden kann.
5.1.11 Datenbank
Der Name der Datenbank, auf die sich die Operation bezog.
5.1.12 Business Object
Der voll qualifizierte Name des Business-Objects, auf die sich die Operation bezog.
5.1.13 OQL-Suche
Der voll qualifizierte Name der OQL-Suche, die von der Operation benutzt wurde.
5.1.14 Action-ID und optional Action-Description-Path
Die „Action-ID“ der durch den Application-Server behandelten Action, in deren Kontext die Operation ausgeführt wurde. Falls er bekannt ist bekannt, ist zusätzlich der Action-Description-Path gesetzt. Dieser wird durch ein Leerzeichen von der Action-ID getrennt.
5.1.15 Key-Number
Die „Key-Number“ gibt den von der Operation benutzten Schlüsseltyp für den Zugriff auf eine Business-Object-Instanz an. Der Wert „0“ steht für den Primärschlüssel, ein anderer Wert für einen Sekundärschlüssel.
5.1.16 Instanzenanzahl eines Business Object
Gibt die Anzahl der von der Operation zugegriffenen Business-Object-Instanzen an.
5.2 Verfügbare Kontextinformationen
Es sind nicht alle Kontextinformationen für jede Operation verfügbar. Die folgende Tabelle zeigt für jede protokollierbare Operation, welche Informationen immer vorhanden (X), möglicherweise vorhanden (O) oder nicht vorhanden (-) sind. Bei der Auswertung der aufgezeichneten Operationen ist diese Tabelle sehr hilfreich, um nachzuschlagen, welche Kontextinformationen für eine Operation von Interesse überhaupt verfügbar sind.
| Operationstyp | Zeitstempel | Session-Typ | Session-GUID | Application-Server | Benutzer | Anwendung o. Report | Ausführungszeit-Kategorie | Ausführungszeitdauer | Datenbankanweisung | Datenbank | Business Object | OQL-Suche | Action-ID | Key-Number | Business-Object-Instanz-Anzahl |
| DB_OPEN_CONNECTION | X | X | X | X | X | O | X | X | – | X | – | – | O | – | – |
| DB_CLOSE_CONNECTION | X | X | X | X | X | O | X | X | – | X | – | – | O | – | – |
| DB_ACQUIRE_CONNECTION | X | X | X | X | X | O | X | X | – | X | – | – | O | – | – |
| DB_STATEMENT_EXECUTE | X | X | X | X | X | O | X | X | X | X | – | – | O | – | – |
| DB_TRANSACTION_COMMIT | X | X | X | X | X | O | X | X | – | X | – | – | O | – | – |
| DB_TRANSACTION_ROLLBACK | X | X | X | X | X | O | X | X | – | X | – | – | O | – | – |
| OM_GET_OBJECT | X | X | X | X | X | O | – | – | – | X | X | – | O | X | X |
| OM_GET_OBJECT_ARRAY | X | X | X | X | X | O | – | – | – | X | X | – | O | X | X |
| OM_GET_OBJECT_ITERATOR | X | X | X | X | X | O | X | X | X | X | – | – | O | – | – |
| OM_GET_RESULT_SET | X | X | X | X | X | O | X | X | X | X | – | – | O | – | – |
| OM_GET_UPDATE_STATEMENT | X | X | X | X | X | O | – | – | X | X | – | – | O | – | – |
| OM_PUT_OBJECT | X | X | X | X | X | O | – | – | – | X | X | – | O | – | – |
| CIS_OQL_SEARCH_STATEMENT_ EXECUTE |
X | X | X | X | X | O | X | X | X | X | – | X | O | – | – |
| ROUNDTRIP_ODBC | X | X | X | X | X | O | X | X | – | – | – | – | O | – | – |
| ROUNDTRIP_GUI | X | X | X | X | X | O | X | X | – | – | – | – | O | – | – |
| ROUNDTRIP_PERFORM_ACTION | X | X | X | X | X | O | X | X | – | – | – | – | X | – | – |
| APPLICATION_ACTION_
EXECUTE |
X | X | X | X | X | O | X | X | – | – | – | – | X | – | – |
| OUTPUT_JOB_EXECUTE | X | X | X | X | X | O | X | X | – | – | – | – | X | – | – |
| SESSION_DIALOG_CREATE | X | X | X | X | X | O | X | X | – | X | – | – | O | – | – |
| TM_COMMIT | X | X | X | X | X | O | X | X | – | X | – | – | O | – | – |
| TM_ROLLBACK | X | X | X | X | X | O | – | – | – | X | – | – | O | – | – |
| LOCK_ACQUIRE_WAIT | X | X | X | X | X | O | X | X | – | – | – | – | O | – | – |
| LOCK_ACQUIRE_DIRECT | X | X | X | X | X | O | X | X | – | – | – | – | O | – | – |
| ROUNDTRIP_CLIENT | X | X | X | X | X | O | X | X | – | – | – | – | O | – | – |
| ROUNDTRIP_PERFORM_ACTION_WAIT_TIME | X | X | X | X | X | O | X | X | – | – | – | – | O | – | – |
Ein Datenbank-Monitor zeichnet für die protokollierten Operationen zusätzliche Informationen auf, die bei der Auswertung zur Berechnung zusätzlicher Informationen verwendet werden. Dies sind:
- Anzahl des Auftretens,
- Summe der Ausführungszeit,
- durchschnittliche Ausführungszeit,
- kürzeste Ausführungszeit,
- längste Ausführungszeit,
- Standardabweichung,
- benötigte CPU-Zeit,
- benötigte Zeit für Datenbankoperationen, die innerhalb der protokollierten Operation ausgeführt wurden,
- Anzahl von Datenbank-Anweisungen, die innerhalb der protokollierten Operation ausgeführt wurden,
- erstmalige Ausführung einer Datenbank-Anweisung im ERP-System
6 Auswertung der Leistungsinformationen
Die Leistungsinformationen eines Datenbank-Leistungsmonitors werden in der Datenbank in Business Objects gespeichert. Die Auswertung Daten kann mit Berichten oder über das System-Cockpit erfolgen.
6.1.1 Berichte
Datenbank-Leistungsmonitore können wie jedes andere Business Object auch über Berichte ausgewertet werden. Für die Auswertung stehen Ihnen die folgenden Berichte zur Verfügung, welche über die Anwendung „Berichtsdokumente ausgeben“ ausgeführt werden können:
- Leistungsinformationen: Zeitaufwändige Aktionen sortiert nach Summe
- Leistungsinformationen: Zeitaufwändige Berichte sortiert nach Summe
- Leistungsinformationen: Zeitaufwändige Datenbankanweisungen sortiert nach Summe
Sie können diese Berichte duplizieren und nach Ihren Bedürfnissen anpassen oder aber neue Berichte erstellen. Weitere Informationen finden Sie in der Hilfe zu dem jeweiligen Bericht.
6.1.2 Systemcockpit
In der Anwendung „Systemcockpit“ können Sie die Leistungsinformationen jedes Datenbank-Leistungsmonitors flexibel auswerten. Die transienten Leistungsinformationen des Standard-Datenbank-Leistungsmonitors können Sie für die maximal letzten 24 Stunden seit dem letzten Start eines Application-Servers auswerten. Alle übrigen Leistungsinformationen können Sie bei dem System abfragen. Weitere Informationen finden Sie in der Dokumentation Systemcockpit.