Darstellung von Zeitmarken in WebSphere Business Monitor

Da WebSphere Business Monitor in seinen Datenbankservicekomponenten mehrere Datenbanken verwendet, müssen Sie unbedingt wissen, wie Zeitmarken bei der Datenbankreplizierung durch das System zwischen diesen Datenbanken umgewandelt werden.

Für die Topologien von WebSphere Business Monitor sind viele Konfigurationen möglich. Sie müssen wissen, wie diese Topologien konfiguriert werden, um für Zeitmarken die gewünschten Ergebnisse zu erzielen. Zu den einbezogenen Servern gehören der Server mit der Laufzeitdatenbank, der Server mit der Protokolldatenbank und der Server, auf dem WebSphere Portal installiert ist, der also die Position von DB2 Alphablox darstellt. Wenn im Ergebnis alle Zeiten in GMT (Greenwich Mean Time) gemeldet werden sollen, müssen die Systemuhren der Maschinen mit der Laufzeitdatenbank, mit der Protokolldatenbank und mit WebSphere Portal alle auf GMT gesetzt sein. Alle Zeitmarken und Dimensionsberichterstellungen werden dann in GMT angegeben.

Sollen alle Zeiten in EST (Eastern Standard Time) gemeldet werden, müssen alle Server auf EST gesetzt sein. Wenn Sie Clients in unterschiedlichen Zeitzonen einsetzen wollen, empfiehlt es sich, alle Server auf GMT zu setzen. Falls die über WebSphere Portal festgelegten Clienteinstellungen nicht GMT angeben, gibt es Abweichungen zwischen Berichten, die Zeitmarken verwenden (diese Zeitmarken sind relativ zu den Einstellungen unter WebSphere Portal), und den Berichten, die Dimensionsanalysen durchführen. Diese basieren auf GMT. Die technischen Details werden im Folgenden erläutert.

Die Zeitmarkenspalten in der Statusdatenbank werden als lange Java-Datentypen (serialisierte Java-Zeitmarken auf GMT-Basis) gespeichert. Beim Versetzen dieser Zeitmarken zwischen den drei Datenbanken werden sie während der ETL-Schritte zwischen der Status- und der Laufzeitdatenbank aus diesen langen Java-Datentypen in reale DB2-Zeitmarken konvertiert. Diese Änderung wird unter Verwendung einer Java-basierten benutzerdefinierten Funktion vorgenommen, die den langen Datentyp in eine Zeitmarke konvertiert und den Zeitmarkendatentyp an DB2 zurückgibt. An diesem Punkt werden die Zeitmarken basierend auf den Zeiteinstellungen des Servers konvertiert, auf dem sich die Laufzeitdatenbank befindet. Falls diese Systemuhr auf GMT gesetzt ist, werden die Zeitmarken in GMT konvertiert. Andernfalls werden sie basierend auf dem Zeitzonenabstand und dem Sommerzeitabstand der Systemuhr konvertiert. In DB2 werden sie relativ zu dieser Zeitzone und nicht in GMT gespeichert. DB2 stellt spezielle Register bereit, um den Zeitzonenabstand abzurufen und auf die Zeitmarken anzuwenden.

Zeitmarken, die in die Protokolldatenbank versetzt werden, werden nicht konvertiert. Die Protokolldatenbank speichert somit die Zeitmarken in derselben Zeitzone wie das System mit der Laufzeitdatenbank. Dies bedeutet, dass die Zeitzoneneinstellung der Server mit der Laufzeitdatenbank und der Protokolldatenbank identisch sein muss. Während der ETL-Schritte werden diese Zeitmarken mit der Tabelle DIM_TIME verglichen. Für die Tabelle DIM_TIME selbst ist keine Zeitzone definiert. Wird die Tabelle jedoch mit einem Datenbankserver gekoppelt, verwendet sie die Zeitzoneneinstellungen des Servers. Daher werden alle Zuordnungen zur Tabelle DIM_TIME in der Annahme durchgeführt, dass die Tabelle DIM_TIME und die gesuchte Zeitmarke relativ zur Zeitzone des Servers mit der Protokolldatenbank sind, die möglicherweise nicht auf GMT gesetzt ist.

Der Server, der als Host für WebSphere Portal dient, muss sich ebenfalls in derselben Zeitzone wie die Server mit der Laufzeitdatenbank und der Protokolldatenbank befinden. Wenn Dashboards die Zeitmarkenspalten direkt (also nicht unter Verwendung der Zeitdimension) abfragen, geht die aktuelle Architektur gegenwärtig davon aus, dass die Zeitzonen der Server mit der Laufzeitdatenbank und der Protokolldatenbank mit der Zeitzone des Dashboard-Servers identisch sind. Die Zeitmarken werden wieder in Java-Zeitmarken konvertiert, und WebSphere Portal geht davon aus, dass die Zeitzone für die Zeitmarken der Datenbankserver mit der eigenen Zeitzone identisch ist. Basierend auf diesen Einstellungen werden die Zeitmarken dann zurück in GMT konvertiert. Eine Clientmaschine kann andere Zeitzoneneinstellungen haben. Solange WebSphere Portal die Zeitmarken korrekt in GMT konvertiert, treten keine Probleme auf. Die Konvertierung findet jedoch nur dann korrekt statt, wenn die Zeitzoneneinstellungen von WebSphere Portal und den Servern mit der Laufzeitdatenbank und der Protokolldatenbank identisch sind.

Dieser letzte Aspekt ist aufgrund des Entwurfs der Zeitdimension in WebSphere Business Monitor nicht direkt erkennbar. Während der ETL-Phase gibt es zum Zwecke der Dimensionsanalyse mehrere Verbindungen zur Zeitdimension. Die Person, die die Analyse durchführt, muss sich der Tatsache bewusst sein, dass diese Berichte - ungeachtet der Zeitzoneneinstellungen auf dem Client - auf der Zeitzone der Server mit der Laufzeitdatenbank und der Protokolldatenbank basieren, auf denen die Konvertierung aus GMT in die lokale Zeit der Server stattfindet. Auch wenn die kleinste Einheit der Zeitdimension in einem Tag besteht, könnte ein Zeitzonenunterschied den Tag ändern, an dem ein bestimmter Datensatz auftrat.


Copyright IBM Corporation 2005, 2006. Alle Rechte vorbehalten.