Oracle-Administration mit Toad
Datenbankadministration, Diagnose und Optimierung. Basiert auf Toad für Oracle v10.0
49,80€
(Preis inkl. Mwst. )
| Autor(en): | Patrick Schwanke |
| Verlag: | Addison-Wesley Verlag |
| Version: | 1. Auflage, 2009 |
| Umfang: | 370 Seiten |
| Format: | PDF: 18,9MB |
| Gewicht: | 744 g |
| ISBN: | 3827328942 |
| Bestell-Nr.: | 82732894P |
| Artikeltyp: | E-Book |
Datenbankadministratoren erfahren in diesem Buch wie Sie die verschiedenen Aufgaben ihrer täglichen Arbeit mit Hilfe von Toad (R) for Oracle effizient bewältigen können. Zu Themen wie Verwaltung, Diagnose, Monitoring, Health-Checks oder Optimierung erhalten sie zahlreiche Hinweise sowie Tipps und Tricks aus der Praxis. Ausgehend von den einzelnen Themen wird jeweils der Weg zu den einschlägigen Fenstern und Funktionen im Toad abgeleitet.
Leseprobe:
17 Diagnose-Funktionen (S. 227-228)
Zu den häufigen Aufgaben eines DBAs gehören sicherlich Troubleshooting und Problemdiagnose. Sei es, dass die Anwendung nicht mehr verfügbar ist, hängt oder allgemeine Performance-Probleme zeigt oder auch nur ein einzelner Benutzer entsprechend beeinträchtigt ist. Aus vielerlei Gründen gerät in solchen Situationen oft die Datenbank in den Verdacht, ursächlich für die aufgetretenen Probleme zu sein.
Nicht selten stellt sich im Nachhinein heraus, dass das Problem auf einer anderen Ebene des Technologie- Stacks liegt, z. B. beim Storage oder in einer Virtualisierungsschicht. Vielleicht befindet sich auf demselben Server auch noch eine andere Datenbank, die mit einer Lastspitze alle anderen in Mitleidenschaft zieht. In jedem Falle ist es für den DBA wichtig, passende Diagnosewerkzeuge bei der Hand zu haben, sei es, um die Problemursache aufzudecken, oder um belegen zu können, dass es sich nicht um ein Datenbank-Problem handelt und sich damit selbst aus der Schusslinie nehmen zu können. Natürlich kann Toad kein vollständiger Ersatz für tiefgehende Analyse-Werkzeuge sein.
Dennoch bietet er eine ganze Reihe von Funktionen, um auf Datenbank-, Instanz- oder Session-Ebene Diagnosedaten bis herunter auf einzelne SQL-Kommandos und deren Ausführungspläne, Laufzeiten und Ressourcenverbrauch zu liefern. An dieser Stelle sollte man immer im Hinterkopf behalten, dass auch eine noch so gute, proaktive Überwachung der Datenbank durch professionelle Monitoring- Lösungen den Diagnose- und Troubleshooting-Prozess nicht ersetzen kann. Ein typisches Beispiel dafür sind große Ladejobs oder sonstige Batchläufe, die unangekündigt über Nacht oder über dasWochenende laufen.
Schnell ist ein Tablespace vollgelaufen, obwohl eine entsprechende Überwachung in Betrieb war. In solchen und vielen ähnlichen Situationen hat man als DBA mit einem altbekannten Phänomen zu kämpfen: Fragt man bei den Beteiligten in die Runde, ob irgendwelche außergewöhnlichen Aktivitäten getätigt wurden, erhält man regelmäßig eine negative Antwort („Wir haben nichts Besonderes gemacht."). Solche Aktivitäten dennoch rekonstruieren zu können, ist ein weiterer wichtiger Aspekt, der insbesondere in Abschnitt 17.4.2 beschrieben wird. Die folgenden Abschnitte stellen nun die wichtigsten Diagnose-Werkzeuge von Toad vor. Neben vielen eigenständigen Funktionen gibt es darunter auch solche, die auf vorhandenen Oracle-Werkzeuge aufbauen, z. B. auf Statspack, AWR oder TKProf.
17.1 Session-Aktivität
Eine Übersicht über die Datenbank-Sessions und deren aktuelle Aktivitäten ist häu- fig der erste Schritt in Richtung einer Diagnose. Zum einen hilft es, bei datenbankweiten Problemen zu klären, ob gerade eine oder mehrere ressourcen-intensive Sessions laufen, die alle anderen in Mitleidenschaft ziehen. Gerade bei Anwendungen, die es Endanwendern gestatten, eigene Abfragen und Reports zu definieren, kommt es immer wieder vor, dass eine solche ad hoc definierte Abfrage unerwartet viele Millionen Zeilen zurückliefert und so die komplette Datenbank belastet.
In solchen Fällen gilt es, schnell die betreffende Session zu finden und ggf. abzubrechen oder abzuschätzen, wie lange sie noch läuft. Zum anderen ist es bei Performance-Problemen eines einzelnen Anwenders wichtig, dessen Session in der Datenbank zu identifizieren. Dies kann anhand von Merkmalen wie Benutzername, Client, Anwendungsname oder auch Login-Zeitpunkt geschehen. Welche Merkmale hierfür ausreichen, hängt stark von der Struktur und Connection-Verwaltung der Anwendung ab. In manchen Fällen, insbesondere bei zustandslosen Anwendungen mit einem Connection-Pool, ist dies kaum oder gar nicht möglich. In den meisten Fällen funktioniert es aber recht gut.
Leseprobe:
17 Diagnose-Funktionen (S. 227-228)
Zu den häufigen Aufgaben eines DBAs gehören sicherlich Troubleshooting und Problemdiagnose. Sei es, dass die Anwendung nicht mehr verfügbar ist, hängt oder allgemeine Performance-Probleme zeigt oder auch nur ein einzelner Benutzer entsprechend beeinträchtigt ist. Aus vielerlei Gründen gerät in solchen Situationen oft die Datenbank in den Verdacht, ursächlich für die aufgetretenen Probleme zu sein.
Nicht selten stellt sich im Nachhinein heraus, dass das Problem auf einer anderen Ebene des Technologie- Stacks liegt, z. B. beim Storage oder in einer Virtualisierungsschicht. Vielleicht befindet sich auf demselben Server auch noch eine andere Datenbank, die mit einer Lastspitze alle anderen in Mitleidenschaft zieht. In jedem Falle ist es für den DBA wichtig, passende Diagnosewerkzeuge bei der Hand zu haben, sei es, um die Problemursache aufzudecken, oder um belegen zu können, dass es sich nicht um ein Datenbank-Problem handelt und sich damit selbst aus der Schusslinie nehmen zu können. Natürlich kann Toad kein vollständiger Ersatz für tiefgehende Analyse-Werkzeuge sein.
Dennoch bietet er eine ganze Reihe von Funktionen, um auf Datenbank-, Instanz- oder Session-Ebene Diagnosedaten bis herunter auf einzelne SQL-Kommandos und deren Ausführungspläne, Laufzeiten und Ressourcenverbrauch zu liefern. An dieser Stelle sollte man immer im Hinterkopf behalten, dass auch eine noch so gute, proaktive Überwachung der Datenbank durch professionelle Monitoring- Lösungen den Diagnose- und Troubleshooting-Prozess nicht ersetzen kann. Ein typisches Beispiel dafür sind große Ladejobs oder sonstige Batchläufe, die unangekündigt über Nacht oder über dasWochenende laufen.
Schnell ist ein Tablespace vollgelaufen, obwohl eine entsprechende Überwachung in Betrieb war. In solchen und vielen ähnlichen Situationen hat man als DBA mit einem altbekannten Phänomen zu kämpfen: Fragt man bei den Beteiligten in die Runde, ob irgendwelche außergewöhnlichen Aktivitäten getätigt wurden, erhält man regelmäßig eine negative Antwort („Wir haben nichts Besonderes gemacht."). Solche Aktivitäten dennoch rekonstruieren zu können, ist ein weiterer wichtiger Aspekt, der insbesondere in Abschnitt 17.4.2 beschrieben wird. Die folgenden Abschnitte stellen nun die wichtigsten Diagnose-Werkzeuge von Toad vor. Neben vielen eigenständigen Funktionen gibt es darunter auch solche, die auf vorhandenen Oracle-Werkzeuge aufbauen, z. B. auf Statspack, AWR oder TKProf.
17.1 Session-Aktivität
Eine Übersicht über die Datenbank-Sessions und deren aktuelle Aktivitäten ist häu- fig der erste Schritt in Richtung einer Diagnose. Zum einen hilft es, bei datenbankweiten Problemen zu klären, ob gerade eine oder mehrere ressourcen-intensive Sessions laufen, die alle anderen in Mitleidenschaft ziehen. Gerade bei Anwendungen, die es Endanwendern gestatten, eigene Abfragen und Reports zu definieren, kommt es immer wieder vor, dass eine solche ad hoc definierte Abfrage unerwartet viele Millionen Zeilen zurückliefert und so die komplette Datenbank belastet.
In solchen Fällen gilt es, schnell die betreffende Session zu finden und ggf. abzubrechen oder abzuschätzen, wie lange sie noch läuft. Zum anderen ist es bei Performance-Problemen eines einzelnen Anwenders wichtig, dessen Session in der Datenbank zu identifizieren. Dies kann anhand von Merkmalen wie Benutzername, Client, Anwendungsname oder auch Login-Zeitpunkt geschehen. Welche Merkmale hierfür ausreichen, hängt stark von der Struktur und Connection-Verwaltung der Anwendung ab. In manchen Fällen, insbesondere bei zustandslosen Anwendungen mit einem Connection-Pool, ist dies kaum oder gar nicht möglich. In den meisten Fällen funktioniert es aber recht gut.

