DB2/UDB Datenkollektor. Status:

Transkript

1 DB2/UDB Datenkollektor Status:

2 Einleitung... 3 Die Leistungsmerkmale des ApplicationManager-Datenkollektors für DB2/UDB... 3 Architektur eines DB2/UDB-Datenbank-Systems... 4 Der DB2/UDB-Datenkollektor... 5 Instanz-Monitoring... 6 Monitoring der DBM-Konfigurationsparameter... 6 Datenbank-Monitoring... 8 Überwachung des Log Space... 8 Allgemeine Eigenschaften... 9 Tablespace-Monitoring Bufferpool-Monitoring Performance-Management Management des Betriebssystems Vorkonfigurierte Regelwerke für die Überwachung Anhang A: Objektstruktur des Datenkollektors: Copyright REALTECH 2005 Seite 2 von 14

3 Einleitung Effizientes Applikationsmanagement bedeutet weitaus mehr als die Maximierung der Verfügbarkeit. Durch gezieltes Tuning können Leistungsniveau und Stabilität geschäftskritischer Anwendungen gesteigert werden ohne zusätzlich in Hardware (Prozessoren, RAM, Plattenplatz) zu investieren. Dazu stehen für theguard! ApplicationManager für viele Applikationen Datenkollektoren zur Verfügung, die ein umfassendes Monitoring und eine detaillierte Datenanalyse erlauben. Datenkollektoren erlauben weit mehr als das Sammeln von Events nach vorgegebenen Regeln. Sie liefern in Echtzeit alle Performance-Werte, den aktuellen Zustand aller Applikations-Objekte und erlauben den Einblick in Konfigurationsattribute wie z.b. den Releasestand oder die Parametrisierung der Applikation. Datenkollektoren modellieren eine Applikation in Objekte und Unter-Objekte und erlauben so eine dedizierte Behandlung für Alarmierung, Monitoring oder Statusanzeige. Die Modellierung stellt zudem sicher, dass Informationen klar strukturiert sind und Meldungen einfach der jeweiligen Problemursache zuzuordnen sind. Vorkonfigurierte und wiederverwendbare Regelwerke pro Applikationstyp erlauben die schnelle Einführung der Lösung und die einfache Anpassung der Überwachung an dynamische Landschaften. Das einfache Setzen von Schwellwerten garantiert so das frühzeitige Erkennen möglicher Fehlersituationen. Ein umfassendes Reaktionsmanagement erlaubt die flexible Alarmierung zu mehr als 100 verschiedenen Geräten und Meldungs- Konsolen. Das automatische Discovery neuer Applikationsinstanzen und -objekte, inklusive automatischer Zuordnung von Regelwerken, ermöglicht eine automatische Überwachung selbst in den Fällen, bei denen Administratoren die jeweiligen Applikationen umkonfigurieren (z.b. Hinzufügen neuer Instanzen oder Objekte). Ein zentrales Reporting auf den Applikationsinstanzen und -objekten ermöglicht ein granulares und effektives Kapazitätsmanagement aller Ressourcen. Das integrierte Service Level Management garantiert die Einhaltung von Service Levels für Applikationsverfügbarkeit und Performance, wobei die Operational Level Agreements (OLAs) einfach auf den Applikationsobjekten definiert werden können. Die Leistungsmerkmale des ApplicationManager-Datenkollektors für DB2/UDB Der Datenkollektor für DB2/UDB ermöglicht das Monitoring und die Analyse von DB2-Datenbanken der Versionen 7.2 bis 8.1, wobei alle auf dem lokalen Rechner installierten DB2-Instanzen durch einen Datenkollektor parallel überwacht werden. Neben der DB2-Instanz (Datenbank Manager, DBM) werden auch die Datenbanken, die Tablespaces, die Bufferpools sowie das Diagnostic Log im Rahmen des CIM-Modells als Managed Objects (MOs) einzeln erfasst und entsprechend detailliert analysiert. Die einzelnen Funktionalitäten des Datenkollektors sind in der DC Online -Dokumentation des Produktes beschrieben. Das vorliegende Dokument gibt einen Einblick in die wesentlichen Funktionen des Datenkollektors. Copyright REALTECH 2005 Seite 3 von 14

4 Architektur eines DB2/UDB-Datenbank-Systems DB2/UDB ist ein relationales Datenbanksystem, dass die neusten ANSI-SQL-Standards weitgehend abdeckt und damit von vielen großen geschäftskritischen Anwendungen verwendet wird. DB2-Datenbanken dienen dazu, große Datenmengen im Terabyte-Bereich, wie beispielsweise von SAP Systemen, permanent mit hoher Geschwindigkeit zur Verfügung zu stellen, dauerhaft zu speichern und zu verwalten. Eine geschäftskritische Anwendung kann daher nur dann reibungslos betrieben werden, wenn das zugrundeliegende DB2/UDB- Datenbank-System hochverfügbar ist und keine Engpässe aufweist. Im Bereich der Datenbanken wird viel in Software- und Hardwaretechnologien investiert, obwohl die meisten Probleme durch die dynamische Nutzung durch die Applikation bzw. menschliche Eingriffe von außen (Administratoren) verursacht werden. Eine professionelle Management-Software ist daher unabdingbar. Die Architektur des DB2/UDB-Datenbank-Systems erlaubt den Betrieb und die Verwaltung von mehreren DB2 Datenbanken durch eine DB2-Instanz (Datenbank Manager, DBM). So können mit nur einer DB2-Instanz die Daten verschiedener Anwendungen oder Geschäftsbereiche leicht separiert und verwaltet werden. Auf entsprechend großen und schnellen Server-Systemen können zudem mehrere, komplett unabhängige DB2- Instanzen betrieben werden Architektur eines DB2/UDB-Datenbank-Systems: Copyright REALTECH 2005 Seite 4 von 14

5 Der DB2/UDB-Datenkollektor Die folgende Abbildung zeigt alle Objekte einer DB2/UDB-Instanz im Managed Monitor des theguard! ApplicationManagers. Eine vollständige Liste aller Objekte ist im Anhang A beschrieben. Die DB2-Instanzen, deren Datenbanken, Tablespaces, der Bufferpool sowie das Diagnostic Log werden im Managed Monitor als Managed Object erfasst und dargestellt. Die Managed Objects sind ihrer Hierarchie entsprechend klar und übersichtlich angeordnet. Dadurch ist der aktuelle Zustand jeder Komponente auf einen Blick ersichtlich. Überwachungsparameter lassen sich individuell für jede Komponente getrennt einstellen. Einzelne oder alle Systemprozesse eines Datenbanksystems lassen sich z.b. als Prozessgruppe im jeweiligen Betriebssystem-Datenkollektor individuell als Managed Object überwachen. Copyright REALTECH 2005 Seite 5 von 14

6 Instanz-Monitoring Jede DB2/UDB-Instanz (Datenbank Manager, DBM) kann hinsichtlich der folgenden Kriterien überwacht werden: Status der DB2-Instanz Änderung von DBM-Konfigurationsparametern Überwachung der DB2-Agenten und der Anzahl der Datenbankverbindungen (local und remote) Schwerwiegende Datenbank-Fehler, die im Diagnostic Log protokolliert werden Meldungen (Events) sind klar in Kategorien und Klassen unterteilt und können so leicht gefiltert und unterschiedlich behandelt werden. Sämtliche Überwachungen können mittels Konfigurationsparametern auf die individuellen Anforderungen, getrennt für jede DB2-Instanz, angepasst werden. Die Konfiguration kann leicht auf andere DB2-Instanzen verteilt werden. Die umfassende, automatische Überwachung entlastet alle Datenbank-Administratoren von täglichen Durchsichten. Darüber hinaus ist es möglich, zusätzliche Attribute permanent zu überwachen oder deren Werte alternativ in Form von Listen (Properties) in Echtzeit darzustellen. Monitoring der DBM-Konfigurationsparameter Die Werte sämtlicher DBM-Parameter können angezeigt und mit Soll-Werten bzw. Soll-Wertebereichen verglichen werden. Die DBM-Konfigurationsparameter nach Bereichen sortiert: Liste der überwachten Konfigurationsparameter: Copyright REALTECH 2005 Seite 6 von 14

7 Sollwerte können durch den Benutzer konfiguriert und mit wenigen Maus-Klicks schnell auf andere Datenbanken übertragen werden. Dies gilt auch für alle anderen Konfigurationen. Setzen der Sollwerte für die Überprüfung der DBM-Konfigurationsparameter: Irrtümliche Änderungen kritischer Parameter oder unterschiedliche Werte auf verschiedenen Instanzen können so einfach und schnell ermittelt werden. Applikationsfehler durch falsche DBM-Profilparameter werden vermieden. Copyright REALTECH 2005 Seite 7 von 14

8 Datenbank-Monitoring Jede DB2-Datenbank kann hinsichtlich folgender Kriterien überwacht werden: Status der DB2-Datenbank Änderung von DB-Konfigurationsparametern Auslastung des Log Space Überwachung der Backup-Intervalle Qualität der Caches Anzahl der Client-Verbindungen Statistische Auswertung der Sorts, Locks, Deadlocks, SQL Statements und der Tabellen-Aktivität Meldungen (Events) sind klar in Kategorien und Klassen unterteilt und können so leicht gefiltert und unterschiedlich behandelt werden. Sämtliche Überwachungen können mittels Konfigurationsparametern auf die individuellen Anforderungen, getrennt für jede DB2-Datenbank, angepasst werden. Die Konfiguration kann leicht auf andere DB2- Datenbanken verteilt werden. Die umfassende, automatische Überwachung entlastet alle Datenbank-Administratoren von täglichen Durchsichten. Darüber hinaus ist es möglich, zusätzliche Attribute permanent zu überwachen oder deren Werte alternativ in Form von Listen (Properties) in Echtzeit darzustellen. Überwachung des Log Space Änderungen von Applikationsdaten durch Insert, Update, Delete werden von der Datenbank permanent im Transaction Log protokolliert. Das Transaction Log wird in im Log Space der Datenbank gespeichert. Ist im Log Space kein freier Speicher mehr verfügbar, können keine weiteren Transaktionen ausgeführt werden, was einen partiellen Stillstand der Datenbank bedeutet. Der Log Space ist daher für die Stabilität, Konsistenz und Performance von wesentlicher Bedeutung für die Applikation. Auslastung des Log Space: Durch die Überwachung des Log Space kann der Ausfall der Datenbank aufgrund eines vollgelaufenen Transaction Logs vermieden werden. Dies garantiert die Verfügbarkeit und Performance auch bei speziellen Lastspitzen durch die Applikation. Copyright REALTECH 2005 Seite 8 von 14

9 Allgemeine Eigenschaften Neben der Überwachung können viele wichtige und nützliche Informationen, bezüglich einer DB2-Datenbank, in Form von Listen (Properties) in Echtzeit abgerufen werden. In detaillierten Übersichtstabellen sind z.b. die relevanten Daten über die Tablespaces der Datenbank zusammengefasst; unabhängig davon, ob der Tablespace für ein detailliertes Monitoring als Managed Object erfasst wurde. Liste: Allgemeine Informationen über Tablespaces: Liste: Füllgrad der Tablespaces: Dieser zentrale und schnelle Überblick verkürzt die Ursachenanalyse bei Problemen. Copyright REALTECH 2005 Seite 9 von 14

10 Tablespace-Monitoring Die Tablespaces sind die logischen Speicherbereiche einer DB2-Datenbank. Die Größe eines Tablespaces wird durch die Größe und Anzahl der dem Tablespace zugeordneten physischen Speicherbereiche (den Containern) bestimmt. Tablespace-Monitoring bedeutet daher in erster Linie die Überwachung des verfügbaren Speichers. Liste der Tablespace-Eigenschaften: Durch das Monitoring aller für das Speichermanagement relevanten Größen können sich abzeichnende Kapazitätsengpässe frühzeitig erkannt und behoben werden. Das Reporting aller Daten erlaubt die langfristige Kapazitätsplanung für Applikationsdaten, z.b. auch die Auslagerung einzelner sehr großer Tabellen (oder Tabellenpartitionen) in eigene Tablespaces. Copyright REALTECH 2005 Seite 10 von 14

11 Bufferpool-Monitoring Das Lesen und Schreiben von der bzw. auf die Festplatte gehört zu den langsamsten Operationen einer Datenbank und beeinflusst damit entscheidend die Gesamtperformance. Durch das Monitoring des Bufferpools können die Qualität des Bufferpools (Hit Ratio, Trefferquote) und die I/O- Operationen der Datenbank erfasst und mittels der Reporting-Funktion detailliert untersucht werden. Die Hit Ratios eines Buffers: Statistik über die physikalischen Leseoperationen eines Buffers: Das Monitoring der Bufferpools liefert so wertvolle Hinweise für die Optimierung der I/O-Performance und damit der schreibenden und lesenden Applikation. Copyright REALTECH 2005 Seite 11 von 14

12 Performance-Management Die Managed Objects, wie z.b. die DB2-Instance oder die DB2-Database, liefern zahlreiche statistische Werte bezüglich ihres Echtzeitzustandes. So z.b. Auslastungs- und Performancewerte wie Anzahl der aktuellen Client- Verbindungen, Speicherbedarf, Qualität des Caches, u.v.a.. Für sämtliche statistischen Werte können Schwellwerte gesetzt werden, welche bei Über- bzw. Unterschreitung zu Alarmen führen. Dies dient gleichzeitig der Funktions- und der Performance-Überwachung. Ebenso können die statistischen Werte in der ApplikationManager-Datenbank gesammelt und via Reporting ausgewertet werden. So können z.b. Trendanalysen für den Verbrauch von Plattenplatz, etc. durchgeführt werden, welche als Grundlage für eine Kosten- und Kapazitätsplanung dienen. Weiterhin lassen sich sämtliche statistische Werte im Echtzeit-Performance-Monitor beobachten und miteinander vergleichen. Dies bietet eine wertvolle Unterstützung für Performance- und Speicher- Optimierungen. Die Abbildung unten zeigt die Nutzung des Log Spaces und die Anzahl der allokierten, sekundären Log Files im Performance-Monitor. Copyright REALTECH 2005 Seite 12 von 14

13 Management des Betriebssystems Um ein DB2-Datenbank-System komplett abzusichern, sollte man wesentliche Kenngrößen des Betriebssystems wie z.b. physische Platten, Prozessor-Auslastung, Paging-File, etc. überwachen. Diese Kenngrößen und mehr können mit den entsprechenden Datenkollektoren für die Betriebssysteme erfasst und ausgewertet werden. Vorkonfigurierte Regelwerke für die Überwachung Der DB2/UDB-Datenkollektor enthält viele umfassende, vorkonfigurierte Regelwerke für Objekttypen wie Instance, Database, Tablespace oder Bufferpool. Weitere Informationen über REALTECH s Softwareprodukte unter: REALTECH AG Industriestr. 39c Walldorf Germany Tel Fax mailto:customer-services@realtech.com Copyright REALTECH 2005 Seite 13 von 14

14 Anhang A: Objektstruktur des Datenkollektors: Der Datenkollektor hat folgende Objektstruktur in Objekttypen, die u.a. maßgebend für die Konfiguration, die Zuordnung der Events und für alle sonstigen Funktionen sind: Objekttyp Unterobjekttypen Metrik Thema DB Client Ein Client pro Managed Node Instanz-Monitoring Eigenschaften des vom Datenkollektor genutzten Client- Environment Instance Database Tablespace Bufferpool Diagnostic Log Database Diagnostic Log Tablespace Bufferpool Ein bis n Instanzen (Datenbank Manager, DBM) pro Managed Node Ein bis n Datenbanken pro Instanz Ein bis n Tablespaces pro Datenbank Ein bis n Bufferpools pro Datenbank Ein Diagnostic Log pro Instanz Instanz-Monitoring Zustand, Aktivität und Performance auf Datenbank Manager-Ebene Datenbank-Monitoring Aktivität und Performance auf Datenbank-Ebene Tablespace-Monitoring Kontrolle von Speicherverbrauch und Segmentwachstum Buffer-Monitoring Auslastung und Performance der Puffer Alarmierung bei DB2- Fehlermeldungen Copyright REALTECH 2005 Seite 14 von 14