Datenbanken sind das Herz vieler Business-Applikationen oder Websites. Der Erfolg steht und fällt mit der Geschwindigkeit, in die Datenbank Anfragen bearbeitet. Kommt die Antwort auf eine Web-Anfrage zu spät, könnte der Besucher schon wieder verschwunden sein und anderswo bestellen.
Im ersten Teil unserer Serie gehen wir auf grundlegende Fakten ein, die die Performance einer Datenbank beeinflussen, und auf die zur Verfügung stehenden Statistik-Tools, die bei der Fehlersuche behilflich sind.
Unsere neue Serie zu Oracle 10g basiert auf Kapitel 18 des Standardwerks „Oracle 10g“ von Fröhlich, Czarski und Maier aus dem Verlag Markt + Technik. Sie können dieses über 870 Seiten starke Buch auch in unserem Buchshop bestellen oder als eBook herunterladen.
|
Teil 2: Shared Pool konfigurieren |
|
Teil 3: Buffer Cache optimieren |
|
Teil 4: Der Redo-Logbuffer |
|
Teil 5: I/O optimieren |
|
Teil 6: Tuning automatisieren |
Datenbank Tuning
Oracle plant seit längerem, das Umfeld für eine sich selbst verwaltende Datenbank zu schaffen. Während man in Oracle9i mit der Einführung von dynamischen Parametern für die Shared Memory-Verwaltung nur von ersten Ansätzen sprechen konnte, finden sich in Oracle 10g die ersten Features, die ein automatisches Tuning in Abhängigkeit vom aktuellen Workload, ohne Eingriff durch den DBA, durchführen.
Es ist zu erwarten, dass Oracle diesen Weg konsequent weitergeht. Automatisches Tuning oder eine sich selbst verwaltende Datenbank bietet Vorzüge in mehreren Bereichen:
-
Die Datenbankparameter können dynamisch, abhängig vom aktuellen Workload der Datenbank, angepasst werden. Dagegen ist eine statische Konfiguration immer ein Kompromiss, der alle Situationen über die Zeitachse gleichermaßen bedienen muss.
-
Mit dem Einstieg in die Welt des Grid Computing ist ein Service Provisioning auf allen Ebenen erforderlich.
-
Für kleine und mittlere Datenbanken nimmt der Anteil der Einflussnahme durch den Datenbankadministrator ab. Das macht die Oracle-Datenbank konkurrenzfähiger gegenüber Datenbanken wie Sybase oder Informix.
Bei genauer Betrachtung lässt sich jedoch sagen, dass generell der Administrationsaufwand einer Oracle 10g-Datenbank gegenüber früheren Versionen nicht kleiner geworden ist. Die Einsparungen an Administration durch automatische Features und Vereinfachungen werden durch die große Anzahl neuer Produkte und Features kompensiert. Es erfolgt also eine Verlagerung der Charakteristik der administrativen Aufgaben.
Wenn wir über Oracle 10g-Datenbank-Tuning sprechen, dann lassen sich die Aktivitäten in folgende Kategorien einteilen:
-
Performance-Planung
-
Optimierung von Instanz und Datenbank
-
Einrichtung automatischer Tuning-Features
Performance-Planung
Performance-Planung bekommt einen immer größeren Einfluss auf die Leistungsfähigkeit des Endsystems. Vor wenigen Jahren war die Standardvorgehensweise noch, eine Datenbank aufzusetzen und danach schrittweise zu optimieren. Dieses Vorgehen ist heute nicht mehr ausreichend. Bereits bei Festlegung der Architektur kann durch falsche Entscheidungen die Leistungsfähigkeit des Systems stark eingeschränkt werden. Das lässt sich auch später durch Tuning-Maßnahmen oder durch Einsatz leistungsstärkerer Hardware nicht in vollem Umfang korrigieren.
So bringt der Einsatz einer Real Application Clusters-Architektur nicht nur eine Erhöhung der Verfügbarkeit, sondern auch eine nicht unerhebliche Verbesserung an Performance.
So hat in einem Projekt die Verfügbarkeit bei der Auswahl einer RACArchitektur eine untergeordnete Rolle gespielt. Es sollte ein Advanced Queuing-System zum Einsatz kommen, bei dem eine Durchsatzrate von zweitausend Nachrichten pro Sekunde erforderlich war. Oracle Advanced Queuing speichert alle Nachrichten in der Datenbank. Die Flaschenhälse bilden dabei die Online Redo Log-Dateien sowie die Undo-Tablespaces. Da in einer RAC-Architektur jede Instanz über eigene Redo Log-Dateien und Undo-Tablespaces verfügt, konnte ein Skalierungsfaktor von 0,8 erreicht werden. Das heißt, mit zwei Instanzen konnte der Durchsatz auf 180%, bei vier Instanzen auf ca. 320% erhöht werden.
Skalierbarkeit
Skalierbarkeit spielt häufig im Internetbereich die erste Geige. Es ist fast unmöglich einzuschätzen, wie sich die Zugriffszahlen entwickeln werden. Auch hier kann einfach durch Hinzunahme weiterer Knoten eine Erhöhung der Performance erfolgen. Dabei ist keine Änderung in der Applikation erforderlich. Bekanntlich machen die Applikationskosten den Löwenanteil von Internetprojekten aus. RAC bietet in diesem Fall die perfekte Kombination aus einem hohen Maß an Skalierbarkeit und Hochverfügbarkeit.
Es gibt weitere Optionen, um Performance bereits bei der Architekturerstellung zu planen. So können Sie sich für eine logische Standby-Datenbank entscheiden, die mit Oracle Streams aktuell gehalten wird. Alle Benutzerabfragen und Reports können dann auf die Standby-Datenbank umgeleitet werden. Zusätzlich können Sie die Primär-Datenbank für DML-Befehle und die Standby-Datenbank für SQL-Abfragen optimieren. Das Maß an Entlastung, das Sie auf der Primär-Datenbank damit erreichen, erhalten Sie selten durch den Einsatz leistungsfähigerer Hardware. Zudem ist die letztere Methode wesentlich teurer.
Führen Sie vor der endgültigen Architektur-Entscheidung einen Proof-of-Concept-Test durch. Damit können Sie u.a. beweisen, dass die vorgeschlagene Architektur die erforderlichen Performance-Werte liefert. Dabei ist immer noch Raum für spätere Tuning-Aktivitäten.
Auswahl der Hardware-Komponenten
Zur Performance-Planung gehört auch die richtige Auswahl und die Dimensionierung der Hardware-Komponenten. Wenn Sie ein ausfallsicheres System benötigen, dann werden Sie von vornherein Festplatten oder Subsysteme spiegeln oder evtl. ein RAID-System einsetzen wollen.
Für eine Data Warehouse-Datenbank stehen andere Aspekte im Vordergrund. Hier kommt es fast in erster Linie auf Performance an, alle anderen Aspekte treten in den Hintergrund. Auch Verfügbarkeit spielt eher eine untergeordnete Rolle. Es werden riesige Datenmengen verarbeitet, die nur schwer in den Buffer Cache passen. Besonderer Wert sollte deshalb auf hohe Durchsatzraten für E/A-Vorgänge gelegt werden. Hier macht es also wenig Sinn, Festplatten zu spiegeln oder RAID-5-Systeme einzusetzen.
Das Datenbank-Modell hat ebenfalls einen wichtigen Einfluss auf die Performance des produktiven Systems. In der Praxis zeigt sich, dass logisch perfekte Modelle nicht immer die beste Performance liefern. Verwenden Sie z.B. hierarchische Tabellen, die sehr groß sind, dann laufen die Abfragen sehr lang und haben einen großen Ressourcen-Verbrauch. Ein Modell ohne Redundanzen ist zwar erstrebenswert, jedoch kann ein gewisses Maß von Datenredundanz eine deutliche Erhöhung der Performance zur Folge haben. Nicht umsonst ist ein Data Warehouse mit einem Star-Schema ein hochredundantes System.
Formulieren Sie, bevor Sie mit der Performance-Planung beginnen, eindeutige Zielsetzungen. Systeme können sehr unterschiedliche Prioritäten aufweisen. So kann einerseits die Laufzeit der Applikation, anderseits eine optimale Strukturierung der Daten im Vordergrund stehen. Erfüllen Sie nur die Mindestanforderungen an die Performance und versuchen Sie nicht, die optimale Performance auf Kosten von Nachteilen in anderen Bereichen herauszuholen. In der Zielsetzung sollten auch Anforderungen an die Skalierbarkeit enthalten sein. Hochskalierbare Systeme sind in der Regel teurer und erfordern eine komplexere Architektur.
Optimierung von Instanz und Datenbank
Oracle hat mit der Version 10g begonnen, automatische Tuning-Features auszuliefern. Damit ist es möglich, über die Zeitachse Datenbankparameter abhängig vom aktuellen Workload dynamisch zu verändern. Ausführliche Informationen dazu finden Sie im Artikel Oracle Datenbank-Tuning Teil 3 im Abschnitt „Einrichtung automatischer Tuning-Features“.
Der vorliegende Abschnitt beschäftigt sich mit der Optimierung eines statischen Systems, bei dem sich die Parameter und Rahmenbedingungen über die Zeitachse nicht verändern. Der Datenbankadministrator sammelt Statistiken, um die Performance-Probleme zu lokalisieren und zu analysieren. Danach unternimmt er Schritte, um die Performance zu verbessern. Dabei werden Parameter angepasst und bleiben wieder konstant bis zum nächsten Tuning.
Sammeln Sie Ihre ersten Tuning-Erfahrungen mit statischen Systemen. Die Kenntnis der Auswirkungen von Initialisierungsparametern sowie Erfahrungen zum effektiven Vorgehen bei der Lösung von Performanceproblemen sind Grundvoraussetzung für einen erfolgreichen Tuning-Prozess. Automatische Tuning-Features lösen bei weitem nicht alle Performance-Probleme. Hier sind manuelle Eingriffe ebenso erforderlich, mit dem zusätzlichen Faktor von dynamischen Zuständen des Datenbanksystems.
Eine performante Datenbank erstellen
Datenbank-Tuning beginnt mit der Ersterstellung einer Datenbank und ihrer Objekte. Bereits hier können Sie durch Abweichung von der Standardkonfiguration erste Performance-Verbesserungen erreichen.
Physische Objekte
In Oracle 10g haben Sie die Möglichkeit, mehrere Temporary Tablespaces zu einer Gruppe zusammenzufassen. Damit kann eine SQL-Anweisung mehrere Tablespaces gleichzeitig benutzen. Wenn in Ihrem System viele Sortierprozesse laufen, können Sie mit Hilfe von Gruppen für Temporary Tablespaces eine Performance-Verbesserung erreichen.
Die Größe der Online Redo Log-Dateien hat Einfluss auf die Performance der Datenbank. Das Verhalten des Log-Writer-Prozesses (DBWn) hängt von deren Größe ab.
In der Regel garantieren große Redo Log-Dateien eine bessere Performance. Kleine Dateien vergrößern die Checkpoint-Häufigkeit. Es gibt keine Regel, wie groß die Redo Log-Dateien sein sollen, aber Größen von mehreren hundert Megabyte bis in den Gigabyte-Bereich hinein sind durchaus keine Seltenheit mehr. Ein Wechsel der Log-Datei alle zwanzig Minuten ist ein guter Anhaltspunkt.
Segmente
Beim Erstellen einer Tabelle reserviert Oracle Speicherplatz in Form eines Extents. Wächst die Tabelle durch Einfügen von Daten, werden weitere Extents hinzugenommen.
Besteht ein Segment aus vielen kleinen Extents, die unter Umständen noch wahllos über die Festplatte verteilt sind, dann nennt man diese Situation Fragmentierung. Ein stark fragmentiertes Segment führt zu einer signifikanten Verschlechterung der Performance. Handelt es sich dabei um eine häufig frequentierte Tabelle, kann es zu Wartezeiten von mehreren Minuten kommen.
Tablespaces, in denen der Administrator die Verwaltung der Segmente bestimmt, werden »Vom Datenbankkatalog verwaltete Tablespaces« genannt, da die Informationen über Größe und Anzahl von Extents im Datenbankkatalog hinterlegt werden.
Lokal verwaltete Tablespaces gibt es seit Oracle8i. Dabei übernimmt Oracle die Verwaltung der Extents in Form von Bitmaps und Sie haben nur wenig Einflussnahme.
Verwenden Sie in Oracle 10g für kleine bis große Segmente lokal verwaltete Tablespaces. Das vermindert den Verwaltungsaufwand und bringt keine Nachteile für die Performance mit sich. Für sehr große Segmente kann es Sinn machen, vom Datenbankkatalog verwaltete Tablespaces zu verwenden. Wenn Sie große lokal verwaltete Tablespaces erstellen, dann sollten Sie eine gleichförmige Extent-Zuweisung verwenden.
Der effizienteste Weg, Indexe zu erstellen, ist, zuerst die Daten in die Tabelle zu laden, ohne dass ein Index angelegt ist, und hinterher die Indexe zu erstellen.
Auch beim Erstellen der Indexe lässt sich viel Zeit sparen. Entscheidend für die Geschwindigkeit beim Indexaufbau ist die Sort Area. Eine Erhöhung des Parameters SORT_AREA_SIZE vergrößert die Sort Area und Oracle führt bei der Erstellung des Index weniger Zugriffe auf die Festplatte durch.
Ein Index kann mit der Option UNRECOVERABLE erstellt werden. In diesem Fall werden wesentlich weniger Redo-Informationen erzeugt.
Hauptspeicher-Verwaltung
Oracle speichert Informationen im Hauptspeicher, um Plattenzugriffe zu reduzieren. Das Ziel ist deshalb, die Anzahl der Festplattenzugriffe so gering wie möglich zu halten und die Informationen im Hauptspeicher verfügbar zu machen.
Seit Oracle9i ist es möglich, die Größen für den Shared Pool, den Large Pool und den Buffer Cache dynamisch, d.h. ohne Neustart der Instanz, zu verändern.
Achten Sie darauf, dass die System Global Area (SGA) komplett im realen Hauptspeicher läuft. Eine Benutzung der Swap-Datei führt zu großen Performanceverlusten und verfälscht die Bilder, die Sie von den Statistiken erhalten. Problemlösungen sind eine Verkleinerung der SGA oder eine Erhöhung der realen Hauptspeichergröße.
Der Parameter LOCK_SGA kann auf einigen Plattformen benutzt werden, um die SGA im realen Hauptspeicher festzubinden. Damit wird ein Schreiben in die Auslagerungsdatei vermieden.
Wie groß die einzelnen Pools zu wählen sind, hängt von Last und Größe der Datenbank sowie von der Art der Anwendung und SQL-Anweisungen ab. Generell gilt die Aussage: Je größer, desto besser. Da aber der reale Speicher begrenzt ist, macht es keinen Sinn, Speicher einerseits zu verschenken, wenn er an anderer Stelle benötigt wird.
Festplatten-Aktivitäten
Die Architektur einer Oracle-Datenbank garantiert, dass Performance nicht durch Wartezeiten auf Ein- und Ausgabeaktivitäten der Festplatte eingeschränkt wird. Allerdings wird in der Praxis ein intelligentes E/A-Layout vorausgesetzt.
Bei einem schlechten E/A-Layout kann es zu großen Verlusten an Performance kommen. Eine gute E/A-Performance beginnt deshalb bereits bei der Auswahl der Hardware. Der Durchsatz in Megabyte pro Sekunde ist eine wichtige Größe.
Ein intelligentes Verteilen von Dateien auf verschiedene Festplatten (Striping) trägt entscheidend zur Erhöhung des E/A-Durchsatzes bei. Es gibt verschiedene Formen des Stripings. Weit verbreitet ist die Methode, große und häufig benutzte Tablespaces auf mehrere Dateien aufzuteilen und diese auf verschiedene Festplatten zu verteilen. Dann sind mehrere Festplatten parallel mit dem Lesen beschäftigt.
Die Art der Verteilung von Dateien hängt stark vom Einsatzgebiet ab. Während in einer OLTP-Datenbank die Online Redo Log-Dateien stark beschäftigt sind und deshalb unbedingt separiert werden müssen, werden sie im Data Warehouse von SQL-Abfragen nicht benutzt.
Auch bei einem sehr guten Anfangslayout werden Sie im laufenden Betrieb feststellen, dass die Verteilung noch nicht optimal ist. Eine Überwachung der E/A-Aktivitäten ist deshalb wichtig. Hot Spots können identifiziert und beseitigt werden.
Verwaltung von Festplatten-Subsystemen
Es werden immer häufiger Festplatten-Subsysteme eingesetzt, die über SAN oder NAS angeschlossen werden. Die Verwaltung und die Zuweisung erfolgt dann über Logical Volume Manager. Auch hier gibt es eine Möglichkeit zur Einflussnahme auf die Verteilung von Dateien. So können Dateien über verschiedene Disk-Gruppen verteilt werden und liegen dann auch physisch getrennt.
Auch die richtige Wahl der Blockgröße trägt zur Verbesserung der Performance bei. Während in einem Data Warehouse höhere Blockgrößen Verbesserungen erzielen, kann im OLTP-System ein Gegeneffekt eintreten. Im Folgenden finden Sie einige Regeln, die Ihnen helfen, die richtige Blockgröße für Ihr System zu bestimmen.
Für Lesezugriffe gilt:
-
Für kurze Sätze und überwiegend zufällige Lesezugriffe sind kleinere Blockgrößen besser.
-
Sind die Sätze kurz und wird überwiegend sequenziell zugegriffen, dann sind größere Blöcke besser.
-
Wenn die Sätze sehr lang sind und LOBs in großer Anzahl enthalten, dann sind größere Blöcke zu bevorzugen.
Für Schreibzugriffe gilt:
-
Für OLTP-Datenbanken mit vielen Transaktionen sollte die Blockgröße nicht zu groß gewählt werden. Im Falle eines Kompromisses ist der kleinere Wert zu bevorzugen.
-
Für ein Data Warehouse sollten eher große Blöcke verwendet werden, auch wenn das zu einer Verlangsamung im Ladeprozess führt.
-
Wenn Sie sich nicht sicher sind, welche Blockgröße Sie wählen sollen, dann ist 8 Kbyte ein guter Kompromiss, der eventuell nicht optimal ist, aber andererseits auch keine Probleme verursacht.
Crash Recovery
Oracle führt ein Crash Recovery durch, wenn sich die Datenbank in einem inkonsistenten Zustand befindet. Das ist z.B. der Fall bei einem Neustart nach einem shutdown abort.
Die Zeit für ein Crash Recovery kann sehr lang sein, wenn der letzte Checkpoint lange zurückliegt. Zu häufige Checkpoints andererseits führen zu einer Verschlechterung der Performance. An dieser Stelle ist also ein Kompromiss zu finden.
Mit dem Parameter fast_start_mttr_target ist es möglich, die Recovery-Zeit zu steuern.
Statistiken sammeln
Das Sammeln von Statistiken ist die Basis für ein erfolgreiches Performance-Tuning. Nur mit Hilfe der Statistiken können Sie sich ein komplettes Bild über die Aktivitäten in der Datenbank machen. Sie können kritische Ereignisse und Engpässe erkennen und gezielt Statistiken abfragen.
Sammeln Sie Statistiken über längere Zeiträume. Archivieren Sie ältere Statistiken, aber löschen Sie diese nicht. Nur mit einer kompletten Historie sind Sie in der Lage, die richtigen Schlüsse über das System zu ziehen.
Oracle stellt die folgenden Mittel zum Sammeln von Statistiken zur Verfügung:
-
das Automatic Workload Repository (AWR)
-
die
V$-Views im Datenbankkatalog
Sie können die gesammelten Informationen des AWR für die Datenbank-Optimierung verwenden. Das Einführen des AWR dient jedoch in erster Linie der Verwendung durch die automatischen Tuning Features. Das Automatic Workload Repository wurde auf der Basis von STATSPACK weiterentwickelt und löst STATSPACK ab.
Beachten Sie, dass beim Herunterfahren einer Instanz die Statistiken in den V$-Views gelöscht werden. Wenn Sie also Statistiken über einen längeren Zeitraum sammeln wollen, reichen die V$-Views alleine nicht aus.
Enterprise Manager
Der Enterprise Manager bietet Momentaufnahmen für Performance-Werte. Klicken Sie zur Anzeige auf das Register PERFORMANCE der Datenbank-Seite.
Die V$-Views sind die Basis für alle Werkzeuge zum Sammeln und Anzeigen von Statistiken. Sie können darauf aufbauend Ihre eigenen Performance-Werkzeuge erstellen. Allerdings decken die vorhandenen Tools die Statistiken ab, die Sie in der Praxis benötigen.
Als Administrator sollten Sie die wichtigsten Views kennen. Nicht immer stehen bei Kunden ad hoc die entsprechenden Werkzeuge zur Verfügung. Dann können Sie notwendige Informationen über SQL*Plus abfragen.
Die V$-Views lassen sich in drei Kategorien einteilen:
-
Current State Views
-
Counter/Accumulator Views
-
Information Views
Current State Views
Current State Views spiegeln den aktuellen Zustand in der Datenbank wider. In folgender Tabelle finden Sie eine Übersicht.
|
View |
Beschreibung |
|
|
Locks, die momentan gehalten oder angefordert werden |
|
|
Sitzungen und Prozesse, die ein Latch aufweisen |
|
|
Alle in der Instanz offenen Cursor |
|
|
Alle offenen Sitzungen |
|
|
Ressourcen, auf die momentan gewartet wird |
Counter/Accumulater Views
Counter/Accumulater Views speichern, wie oft bestimmte Aktivitäten seit dem Start der Instanz stattgefunden haben.
|
View |
Beschreibung |
|
|
Statistik des Shared Pools auf Objekt-Niveau |
|
|
E/A-Aktivitäten auf Datei-Niveau |
|
|
Zusammenfassung von Latch-Aktivitäten |
|
|
Aktivitäten von Child Latches |
|
|
Statistik für den Shared Pool auf Namespace-Niveau |
|
|
Zusammenfassung über die Benutzung des Library Cache |
|
|
Zusammenfassung über die Benutzung von Ressourcen der eigenen Sitzung |
|
|
Zusammenfassung der Aktivität von Rollbacksegmenten |
|
|
Zusammenfassung der Aktivitäten des Dictionary Cache |
|
|
Überwachung der Segment-Statistik |
|
|
Realzeit-Überwachung von Segmenten |
|
|
Zusammenfassung der Warte-Ereignisse in der aktuellen Sitzung |
|
|
Ressourcen-Benutzung, seit die Sitzung existiert |
|
|
Simulation des LRU-Mechanismus im Shared Pool |
|
|
Detailinformationen für Cursor von |
|
|
SQL-Befehle im Shared Pool |
|
|
Zusammenfassung der Benutzung von Ressourcen |
|
|
Zusammenfassung von Ressourcen, auf die gewartet wurde |
|
|
Historie der Benutzung von UNDO im Zehn-Minuten-Takt |
|
|
Buffer Waits pro Block |
Information Views
Information Views sind weniger dynamisch als Current State Views.
|
View |
Beschreibung |
|
|
Empfehlungen des MTTR Advisors, wenn der Parameter |
|
|
Parameter der aktuellen Sitzung und Instanz-Parameter |
|
|
Server-Prozesse |
|
|
Segment-Statistik |
|
|
Ausführungsplan des letzten Cursors |
|
|
Details für den Ausführungsplan |
|
|
Text der SQL-Anweisungen im Shared Pool |
Sonstige Views
Oracle 10g stellt Performance-Views zur Verfügung, die sich auf das Automatic Storage Management beziehen.
|
View |
Beschreibung |
|
|
Beschreibung der Diskgroups einer ASM-Instanz (Nummer, Name, Größe, Status, Redundanz-Typ). In einer DB-Instanz eine Zeile für jede Diskgroup, die verwendet wird. |
|
|
Anzeige der Datenbanken, die diese Diskgroups benutzen. In einer DB-Instanz eine Zeile für die ASM-Instanz, die verwendet wird |
|
|
Verfügbare Platten. In einer DB-Instanz eine Zeile für jede Platte, die von dieser Instanz verwendet wird. |
|
|
In der ASM-Instanz die Dateien, die zu einer Diskgroup gehören. In einer DB-Instanz keine Zeilen. |
|
|
In der ASM-Instanz das Template für eine gemountete Diskgroup. In einer DB-Instanz keine Zeilen. |
|
|
In der ASM-Instanz die Alias-Namen der Diskgroups. In einer DB-Instanz keine Zeilen. |
|
|
In der ASM-Instanz die Anzeige von laufenden Operationen. In einer DB-Instanz keine Zeilen. |
Neu in Oracle 10g sind eine Reihe von Views für das verbesserte Wait-Event-Modell.
|
View |
Beschreibung |
|
|
Liefert Zeiten für Warte-Ereignisse sowie die in jeder Klasse verbrauchte Zeit für die gesamte Instanz |
|
|
Speichert die Anzahl von Warte-Ereignissen auf Sitzungsbasis |
|
|
Zeigt die letzten zehn Warte-Ereignisse für alle aktiven Sitzungen an |
|
|
Für die Darstellung eines Histogramms der Anzahl der Ereignisse sowie der maximalen und Gesamt-Wartezeit |
|
|
Stellt ein Histogramm aller einzelnen Block-Lesevorgänge dar. Die Darstellung erfolgt pro Datei. |
|
|
Liefert ein Histogramm aller Block-Lesevorgänge pro temporärer Datei |
In einer Real-Application-Clusters-Datenbank existieren Views mit dem Präfix GV$. Diese enthalten eine Spalte mit der Instanznummer und führen eine datenbankübergreifende Statistik.
(mha)