Oracle Datenkollektor. Status:

Transkript

1 Oracle Datenkollektor Status:

2 Einleitung... 3 Die Leistungsmerkmale des ApplicationManager-Datenkollektors für Oracle... 3 Architektur eines Oracle Datenbank Systems... 4 Der Oracle-Datenkollektor... 5 Database-Monitoring... 6 Monitoring von Applikations- und Benutzer-Sessions... 6 Redo Log/Archive Monitoring... 7 Monitoring der Datenbank-Parameter... 8 Allgemeine Eigenschaften... 9 Tablespace-Monitoring Table- und Index-Monitoring Data File-Monitoring Performance-Management Management des Betriebssystems Vorkonfigurierte Regelwerke für die Überwachung Anhang A: Objektstruktur des Datenkollektors: Copyright REALTECH 2008 Seite 2 von 15

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 Release-Stand 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 Oracle Der Datenkollektor für Oracle DBs ermöglicht das Monitoring und die Analyse von Oracle Datenbanken der Versionen 8.0, 8i und 9i, wobei alle auf dem lokalen Rechner installierten Oracle Datenbanken durch einen Oracle Datenkollektor parallel überwacht werden. Einheiten wie Tablespaces oder Datendateien einer Oracle Datenbank werden im Rahmen des CIM-Modells als Managed Objects (MOs) einzeln erfasst und entsprechend detailliert analysiert. Weitere Funktionalitäten, wie das Monitoring der Control-Dateien, der Archivierung, der Redologs, der Lizenzen und Sessions, der DB- Profilparameter, der Caches und Locks sowie des Oracle-Alert Logs sind in der DC Online -Dokumentation des Produktes beschrieben. Das vorliegende Dokument gibt einen Einblick in die wesentlichen Funktionen des Datenkollektors. Copyright REALTECH 2008 Seite 3 von 15

4 Architektur eines Oracle Datenbank Systems Oracle ist ein relationales Datenbanksystem, dass die neusten ANSI-SQL-Standards weitgehend abdeckt und damit von vielen großen geschäftskritischen Anwendungen verwendet wird. Oracle dient dazu, große Datenmengen im Terabyte-Breich, 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 Oracle Datenbank-System hochverfügbar ist und keine Engpässe aufweist. Daher unterstützt Oracle spezielle Techniken wie Oracle RAC (Real Application Cluster), Schattendatenbank-Technologien und spezielle Verfahren für Backup und Recovery. 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 eines Oracle Datenbank-Systems enthält die Datenbank-Instanz in Form von Prozessen und Speicherelementen, die jeweils spezielle Aufgaben erfüllen. Die Prozesse greifen auf Speichereinheiten zu, die genauso verschiedene Aufgaben erfüllen und unterschiedlich verwaltet werden. Oracle ist eine High-End-Datenbank, deren Verhalten von einer großen Anzahl von Profilparametern bestimmt wird und von der Art, wie eine Applikation auf die Datenbank zugreift. Applikationstuning fängt daher häufig mit dem Tuning der Datenbank an. Architektur einer Oracle DB: Copyright REALTECH 2008 Seite 4 von 15

5 Der Oracle-Datenkollektor Die folgende Abbildung zeigt den Status aller Objekte einer Oracle Datenbank im Managed Monitor des theguard! ApplicationManagers. Eine vollständige Liste aller Objekte ist im Anhang A beschrieben. Die Tablespaces, Datenfiles und das Alert 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 Datenbank-Komponente auf einen Blick ersichtlich. Überwachungsparameter lassen sich individuell für jede Komponente getrennt einstellen. Andere Datenbank-Komponenten, wie Sessions, Segmente oder auch die Redo Log-Gruppen, werden nicht als Managed Objects erfasst, da dies zu einer unübersichtlichen Menge hoch dynamischer Objekte führen würde, bzw. das direkte Monitoring der einzelnen Komponenten wenig sinnvoll wäre. Das Monitoring erfolgt bei diesen Komponenten vielmehr über die Gesamtheit der Objekte, wobei dabei alle einzelnen Objekte einer Komponente nach konfigurierbaren Kriterien überwacht werden. Die entsprechenden Meldungen enthalten dann auch den einzelnen Objektnamen (z.b. den Namen einer Tabelle). Einzelne oder alle Systemprozesse eines Datenbanksystems (SMON, PMON, etc.) lassen sich z.b. als Prozessgruppe im jeweiligen Betriebssystem-Datenkollektor individuell als Managed Object überwachen. Copyright REALTECH 2008 Seite 5 von 15

6 Database-Monitoring Jede Oracle Instanz (Datenbank) kann hinsichtlich verschiedener Kriterien überwacht werden: Status der Oracle DB Änderung von DB Konfigurationsparametern Status der Tablespaces und Datenfiles Segment (Tabellen, Indizes, etc.) - Attribute Existenz und Spiegelung der Control- und Datenfiles Status der Archivierung ( Database Log Mode, Automatical Archival ) und der Redo Logs Anzahl der Client-Verbindungen prozentual zur Anzahl lizenzierter Clients Erfassung von Benutzer-Anmeldungen mit sicherheitskritischem Login (z.b. sytem, sys, scott) Qualität der Caches Status der Rollbacksegmente I/O Performance Statistische Auswertung der Transactions, Calls, Sorts und Enqueues Schwerwiegende Datenbank-Fehler, die im Alert 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 Konfigurationsparameter auf die individuellen Anforderungen, getrennt für jede Oracle-Instanz, angepasst werden. Die Konfiguration kann leicht auf andere Oracle-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. Diese sind im Folgenden beschrieben. Monitoring von Applikations- und Benutzer-Sessions Applikationsprozesse bzw. Benutzer erhalten eine Session, sobald sie sich an der Datenbank anmelden. Aktive Sessions, aktive Benutzer und registrierte Benutzer können separat überwacht werden. Neben der Anzahl der aktiven/freien Sessions wird auch die Anzahl der blockierten Sessions (Sessions die auf die Freigabe eines Locks warten), die Wartezeit der am längsten blockierten Session sowie die summierte Wartezeit aller Sessions erfasst. Copyright REALTECH 2008 Seite 6 von 15

7 Liste aller Sessions einer DB Instanz: Wartesituationen können so zeitnah erkannt und beim Überschreiten konfigurierbarer Schwellwerte frühzeitig alarmiert werden. Wird eine DB-Instanz von verschiedenen Applikationen (oder verschiedenen Applikationsprozessen) genutzt, lassen sich so leicht die Prozesse per PID identifizieren, die durch die Datenbank aufgehalten werden. Redo Log/Archive Monitoring Änderungen von Applikationsdaten durch Insert, Update, Delete werden von der Datenbank permanent in sogenannten Redo Logs protokolliert. Die Redo Log-Gruppen als Ringspeicher sind daher für die Stabilität, Konsistenz und Performance von wesentlicher Bedeutung für die Applikation. Ein Monitoring erfolgt sinnvoller weise über die Gesamtheit der Log Gruppen. So wird neben der Qualität des entsprechenden Redo Log-Puffers im Hauptspeicher auch die Anzahl der freien Log Gruppen (im ARCHIVELOG-Modus die Anzahl der freien und archivierten Log Gruppen) überwacht. Liste der Redo Log-Informationen: Performance-Engpässe im Bereich der LGWR- und ARCH- Prozesse können so frühzeitig erkannt und Fehlerzustände (Archiver Stuck) vermieden werden. Dies garantiert die Verfügbarkeit und Performance auch bei speziellen Lastspitzen durch die Applikation. Copyright REALTECH 2008 Seite 7 von 15

8 Monitoring der Datenbank-Parameter Die Werte sämtlicher Datenbank-Parameter können mit Soll-Werten bzw. Soll-Wertebereichen verglichen werden. 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. Liste der Oracle-Parameter und deren Werte: Irrtümliche Änderungen kritischer Parameter oder unterschiedliche Werte auf verschiedenen Datenbanken können so einfach und schnell ermittelt werden. Applikationsfehler durch falsche DB-Profilparameter werden vermieden. Copyright REALTECH 2008 Seite 8 von 15

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

10 Tablespace-Monitoring Die Tablespaces sind die logischen Speicherbereiche einer Oracle Datenbank. Die Größe eines Tablespaces wird durch die Größe und Anzahl der dem Tablespace zugeordneten physischen Speicherbereiche (den Datendateien) bestimmt. Kann eine der zugeordneten Datendateien automatisch vergrößert werden (autoextent-funktion), ist auch der entsprechende Tablespace automatisch erweiterbar. Datenbankobjekte bzw. Segmente (Tabellen, Indexe etc) sind genau einem Tablespace zugeordnet. Sind in einem Tablespace keine freien Speicherbereiche mehr vorhanden, können die zugeordneten Datenbankobjekte keine weiteren Daten mehr speichern, was einen partiellen Ausfall der Datenbank und der Applikation darstellt. Applikationen teilen daher beim Installieren die Segmente sinnvoll in Tablespaces auf, was das spätere Tuning deutlich erleichtert. Tablespace-Monitoring bedeutet daher in erster Linie die Überwachung des verfügbaren Speichers. Neben der absoluten Größe des freien Speichers ist dabei auch die Fragmentierung des Speichers von Belang, d.h. auf wie viele Bereiche sich der freie Speicher verteilt, wie groß die einzelnen freien Speicherbereiche sind und ob freie Speicherbereiche u.u. benachbart und damit zusammengefasst werden können (koaleszierbar sind). Liste aller 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 2008 Seite 10 von 15

11 Table- und Index-Monitoring Als Segment wird die physische Repräsentation eines logischen Datenbankobjekts (z.b. einer Tabelle oder eines Indexes) bezeichnet. In den Segmenten werden die Daten physisch gespeichert, wozu die Segmente in den ihnen zugewiesenen Tablespaces sogenannte Extents allokieren, die die kleinsten allokierbaren Speicherbereiche einer Oracle Datenbank darstellen. In Abhängigkeit vom Typ des Tablespaces kann die Größe eines Extents variabel sein, d.h. die Extents verschiedener Segmente aber auch die Extents eines Segments können unterschiedlich groß sein. Ist in einem Segment kein freier Speicherbereich mehr vorhanden, wird für dieses Segment ein neues Extent allokiert. Dies wird nur dann erfolgreich sein, wenn die für das entsprechende Segment definierte maximale Anzahl von Extents noch nicht erreicht ist und der für das neue Extent benötigte Speicherbereich im Tablespace zur Verfügung steht, bzw. durch eine automatische Tablespace-Erweiterung (autoextent) zur Verfügung gestellt werden kann. Durch den Segment Check werden alle Segmente des Tablespaces bezüglich dieser beiden Kriterien überwacht. Die Anzahl der von jedem Segment bereits allokierten (noch zu allokierenden) Extents kann sowohl bezüglich der maximalen Extent-Anzahl als auch bezüglich des im Tablespaces noch verfügbaren Speichers überprüft werden. Die Prüfung des verfügbaren Speichers kann wahlweise gegen den größten bereits allokierten Speicherbereich oder gegen den unter Berücksichtigung der Autoextent-Funktionalität dann zur Verfügungen stehenden Speicherbereich erfolgen. Konfiguration des Segment Check: Segmentspezifische Fehlzustände, wie das Volllaufen einer Tabelle, können so leicht verhindert werden. Zu viele Extents einer Tabelle können je nach Art des SQL-Statements den Zugriff verlangsamen. Auch hier kann die Funktion helfen, dies frühzeitig zu vermeiden. Copyright REALTECH 2008 Seite 11 von 15

12 Data File-Monitoring In den Datendateien (Data Files) werden die Daten physikalisch gespeichert. 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 Datafile-Monitoring können die I/O-Operationen der Datenbank erfasst und mittels der Reporting- Funktion detailliert untersucht werden. Liste der Informationen für eine Datendatei: Das Monitoring der Datendateien liefert so wertvolle Hinweise für die Optimierung der I/O-Performance für das Load-balancing oder das Lokalisieren von Hot Spots. Copyright REALTECH 2008 Seite 12 von 15

13 Performance-Management Die Managed Objects, wie z.b. die Oracle DB oder die Tablespaces, 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 Performance Monitor beobachten und miteinander vergleichen. Dies bietet eine wertvolle Unterstützung für Performance- und Speicher-Optimierungen. Die Abbildung unten zeigt die Auslastung des Buffer Cache im Performance Monitor. Copyright REALTECH 2008 Seite 13 von 15

14 Management des Betriebssystems Um ein Oracle Datenbank System komplett abzusichern, sollte man wesentliche Kenngrößen des Betriebssystems wie z.b. physische Platten, Prozessor-Auslastung, Page-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 Oracle-Datenkollektor enthält viele umfassende, vorkonfigurierte Regelwerke für Objekttypen wie Database oder Alert Log. Weitere Informationen über REALTECH s Softwareprodukte unter: REALTECH AG Industriestr. 39c Walldorf Germany Tel Fax mailto:customer-services@realtech.com Copyright REALTECH 2008 Seite 14 von 15

15 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 Database Alert Log Tablespace Ein bis n Oracle Instanzen pro Managed Node Instanz-Monitoring Zustand, Aktivität und Performance auf Datenbank-Ebene AlertLog Ein Alert Log pro Oracle- Instanz Alarmierung bei Oracle- Fehlermeldungen Tablespace Datafile Ein bis n Tablespaces pro Oracle-Instanz Datafile Ein bis n Datenfiles pro Tablespace Tablespace-Monitoring Kontrolle von Speicherverbrauch und Segmentwachstum I/O-Performance-Analyse Copyright REALTECH 2008 Seite 15 von 15