Um zu prüfen, welche Datenbanken sich auf dem jeweiligen Server befinden, muss man zum Dashboard-Bildschirm wechseln. Aus der Liste PHYSICAL SERVERS ist ein Server zu wählen, anschließend werden alle im gewählten Server vorhandene Datenbanken unten aufgelistet..

Nach dem Umschalten der Anzeige in den Television Mode bietet das Dashboard die Möglichkeit, die Belastung einzelner Datenbanken zu prüfen. Auf dieser Ebene sind: Server-CPU-Belastung, Dauer der Sperren und Wartezeiten in Echtzeit zu sehen..

Die Auswahl der Datenbank aus der Liste ORACLE INSTANCES ermöglicht, die Leistungsstatistiken der letzten 15 Minuten anzuzeigen. Die Datenaktualisierung erfolgt in 30-Sekunden-Takt für CPU, Waits, Waits Details, Sessions. Sonstige Funktionalitäten werden alle 15 Minuten aktualisiert.

Der Dashboard-Bildschirm informiert durch eine graue Kennzeichnung, dass die jeweilige Instanz nicht verfügbar ist.

Um benutzerdefinierte Warnmeldungen einzustellen, muss man den Tab Configuration > Alert settings > Alerts definition öffnen. Die Warnmeldungen können auf 2 Ebenen definiert werden:

• allgemein
• für einzelne Datenbanken.

Um eine benutzerdefinierte Warnmeldung einzustellen, ist das Feld Add new alert anzuklicken.

In dem neu geöffneten Fenster kann, je nach Bedarf, eine benutzerdefinierte Warnmeldung eingestellt werden.

Um einen Bericht über die Datenbankbelastung zu generieren, muss man zum Tab Reports > Performance report wechseln. Anschließend ist ein Datumsbereich zu bestimmen und die Schaltfläche Run Report zu betätigen. Der erstellte Bericht enthält die TOP11 der Befehle:

• die am längsten dauern,
• die die CPU am längsten nutzen,
• die die meisten Daten von der Festplatte lesen,
• die die meisten Daten vom Datenpuffer lesen,
• die die am häufigsten verwendet werden.

sowie:

• Dauer der Sperren pro Stunde,
• Top 10 der am längsten dauernden Waits und Latches in der Datenbank.

Um zu prüfen, wie viele CPUs durch die Datenbank und wie viele durch den Server genutzt werden, muss man zum Bildschirm Performance > Database load wechseln. Wenn man mit dem Mauszeiger über das Diagramm fährt, sind die Werte für den Zeitraum von 15 Minuten zu sehen. Das sind u.a.: CPU Time (Auslastung der CPU durch die Datenbank) und Server CPU (Auslastung der CPU durch alle Prozesse auf dem Server).

Um zu prüfen, wie viele CPUs durch den Server genutzt werden und wie viele ihm zur Verfügung stehen, muss man den Tab Performance > OS Stat öffnen. In der Tabelle unten sind die Spalten CPU Number und Busy Time zu markieren. Das Diagramm zeigt die durch den Server genutzten CPUs im Vergleich zu allen CPUs, die im gewählten Zeitraum zugeordnet wurden.

Um zu prüfen, wie viel RAM-Speicher der Datenbank zugewiesen ist, muss man den Tab Parameters > Parameters Overview öffnen. Im Feld Param name ist SGA einzugeben und in der Liste SGA_MAX_SIZE zu finden. Der Wert dieses Parameters bestimmt den der Datenbank zugeordneten Speicher.

Anschließend sollte man zur Lesemarke Memory > SGA wechseln. Auf dem Bildschirm wird angezeigt, wie viel RAM-Speicher genutzt wird und wie viel frei ist (SGA TOTAL). Es sind auch die Größen einzelner SGA-Speicherkomponenten zu sehen.

Um zu prüfen, wie viel RAM-Speicher dem Server zugeordnet ist, muss man den Tab Performance > OS Stat öffnen. Aus der Tabelle unten ist die Spalte Physical Memory zu wählen. Das Diagramm zeigt die Größe des RAM-Speichers auf dem Server.

Um die Größe und den Zuwachs der Datenbank zu prüfen, muss man den Tab Space Monitor > Database size öffnen. Auf dem Bildschirm wird dann der gesamte, freie und belegte Platz in der Datenbank im jeweiligen Zeitraum angezeigt. Zusätzlich wird in der Sektion DATABASE GROWTH der Zuwachs am vorherigen Tag, in der vorherigen Woche und im vorherigen Monat angezeigt.

Informationen über Datenbankgröße, Tabellenraum und Dateien sind im Tab Space Monitor zu finden. In Last Snap Tablespace Size werden die neuesten Daten über die Größe der einzelnen Tabellenräume in der Datenbank grafisch und in Tabellenform dargestellt.

Die gleichen Informationen können auf der Ebene des Dashboard-Bildschirms abgerufen werden. Zu diesem Zweck ist eine Datenbank und dann Database space zu wählen.

Der Zuwachs des Tabellenraums im Bereich der ausgewählten Daten kann im Tab Space monitor > Tablespace historygeprüft werden. Es besteht die Möglichkeit, den Datumsbereich einzustellen und einen bestimmten Tabellenraum auszuwählen.

Um Einstellungen der einzelnen Datenbankparameter zu prüfen, muss man den Tab Parameters öffnen. Auf dem Bildschirm werden alle Parameter der Datenbank einschließlich des eingestellten Wertes angezeigt. Nach der Auswahl eines unten stehenden Parameters ist der Änderungsverlauf zu sehen.

Auf dem Bildschirm Parameters > Parameters History wird eine Liste aller Parameteränderungen im jeweiligen Zeitraum angezeigt. Es ist möglich, einen bestimmten Parameter durch Eingabe seiner Bezeichnung oder seines Wertes zu wählen.

Um I/O-Befehle zu finden, die das System am stärksten belasten, muss man den Tab Performance > SQL 3D öffnen.

Falls man nach Lesevorgängen sucht, ist Draw bar auf Disk Reads einzustellen, um die Abfragen zu sehen, die beim Lesen von Festplattengeräten die größten Belastungen erzeugen.

Falls man nach Schreibvorgängen sucht, ist Show additional filters zu öffnen und Log generating statements zu wählen, um die Abfragen zu sehen, die beim Schreiben die größten Belastungen erzeugen.

Um zu prüfen, welche Sitzung das Problem UNDO GLOBAL verursacht, muss man Sessions > Undo usage sessions öffnen. Die Spalte Used records ist in absteigender Reihenfolge zu sortieren. Die Sitzung mit der höchsten Anzahl von im Prozess verarbeiteten Datensätzen gilt als Problemursache.

Um das Problem im jeweiligen Zeitraum zu analysieren, muss man den Tab Session / Undo History öffnen und den Datumsbereich einstellen. Nachdem ein Zeitpunkt gewählt wurde, ist der untere Tab Undo zu wählen und die Spalte Used records absteigend zu sortieren. Die Sitzung mit der höchsten Anzahl von im Prozess verarbeiteten Datensätzen gilt als Problemursache.

Um zu prüfen, welche Sitzung die meisten Änderungen in der Datenbank verursacht, muss man den Tab Sessions > Undo usage sessions öffnen. Die Spalte Used records ist dann in absteigend zu sortieren. Die Sitzung mit der höchsten Anzahl von im Prozess verarbeiteten Datensätzen verursacht die meisten Änderungen in der Datenbank.

Um zu prüfen, was shared_pool Latches verursacht, muss man den Tab Performance > Latches > Latch library cacheöffnen. In der Sektion SHARED POOL STATEMENTS ist eine Liste von Abfragen mit Literalen, einschließlich der Anzahl der belegten Shared Pool-Speicher zu sehen. Es wird auch die Anzahl der Versionen der Abfrage berücksichtigt. Literale, die den Speicher im größten Umfang nutzen, gelten als Ursache der shared_pool Latches.

Um die Datenbankbelastung in den letzten 2 Jahren zu analysieren, muss man den Tab Performance > Load trendsöffnen. Dann sind der Datumsbereich für die letzten 24 Monate und die Gruppierung nach Monaten einzustellen. Standardmäßig sieht man das Diagramm Elapsed time, das die Dauer aller Befehle in der Datenbank im ausgewählten Zeitraum in der ausgewählten Zeitgruppierung (15 Minuten, Tag, Monat) anzeigt.

Um zu prüfen, wer eine Abfrage ausführt, muss man den Tab Sessions > Session / Undo history öffnen. Nach der Eingabe einer Abfragekennung im Feld Using Query Hash erscheint unten eine Liste aller Sitzungen, in denen die Abfrage im ausgewählten Zeitraum ausgeführt wurde.

Um die Leistungsstatistik der jeweiligen Abfrage zu prüfen, muss man den Tab Performance > SQL Details öffnen. Nach Eingabe der Abfragekennung oder nach Auswahl der Abfragekennung aus einer Liste, erscheinen in der Sektion SQL STATISTICS Leistungsstatistiken für den ausgewählten Zeitraum.

Es besteht die Möglichkeit, die Ergebnisse nach Monaten, Tagen, Stunden oder Snaps (15 Minuten) zu gruppieren.

Um den Ausführungsplan zu prüfen, muss man den Tab Performance > SQL Details öffnen. Nachdem die Abfragekennung eingegeben oder aus einer Liste ganz unten im Tab Explain plan gewählt wurde, erscheint ein Ausführungsplan.

Es kommt vor, dass eine Abfrage mehr als einen Ausführungsplan nutzt. Nachdem das Feld Compare Plans markiert wurde, erscheint ein zweiter Ausführungsplan. So können Unterschiede hervorgehoben und auch der Grund für das langsame Funktionieren mit dem gegebenen Ausführungsplan gefunden werden.

Es kann auch der Ausführungsplan für eine aktive Sitzung geprüft werden. Zu diesem Zweck muss man den Tab Sessions öffnen. Nachdem eine Sitzung markiert wurde, erscheinen unten der Text der ausgeführten Abfrage und der Ausführungsplan.

Um zu überprüfen, wie viele Abfragen den jeweiligen Ausführungsplan nutzen, muss man den Befehl im Tab SQL Detailswählen und auf Add to SQL plan klicken.

Anschließend ist der Tab SQL-Plan zu öffnen und der zuvor hinzugefügte Ausführungsplan aus der Liste auf der linken Seite zu wählen. Es erscheint eine allgemeine Leistungsstatistik für den jeweiligen Ausführungsplan. Nachdem der Tab Statements using plan gewählt wurde, sind alle Abfragen zu sehen, welche den jeweiligen Ausführungsplan nutzen.

Die Speicherkonfiguration ist im Tab Memory > SGA im Feld SGA Usage zu finden.

Einzelne Komponenten der Speicherpuffer befinden sich im Tab Memory > SGA in der Sektion CURRENT MEMORY UTILIZATION. Wenn man den Mauszeiger über eine Komponente bewegt, wird im Diagramm ihr Wert angezeigt.

Um den Verlauf der SGA-Parametereinstellungen zu prüfen, muss man den Tab Speicher > SGA History öffnen. Dort ist die Belegung einzelner SGA-Elemente im gewählten Zeitraum zu sehen.

Um zu prüfen, welche Sitzung den Tabellenraum zum Sortieren im größten Umfang nutzt, muss man den Tab Sessions > Sort usage sessions öffnen. Dort sind die Belegung des Tabellenraumes zum Sortieren und die Liste der Sitzungen, die den Tabellenraum nutzen, zu sehen. Um die gesuchten Sitzungen anzuzeigen, ist die Spalte Space Used absteigend zu sortieren.

Um zu überprüfen, ob Literale in der Datenbank vorhanden sind, muss man den Tab Performance > Latches > Latch library cache öffnen. In der Sektion SHARED POOL STATEMENTS ist eine Liste von Abfragen mit Literalen und mit der Größe des belegten Shared Pool-Speichers zu sehen.

Literale bereiten Probleme, wenn in der Datenbank SHARED POOL-Latches erscheinen. Um nach diesen Latches zu suchen, muss man den Tab Waits > Analyze öffnen sowie den Datumsbereich und die Gruppierung einstellen. In der Sektion WAIT STATISTICS muss man nach wait latch:shared pool suchen. Ist die Wartezeit im Verhältnis zur Dauer aller Prozesse sehr gering, dann gibt es kein Problem mit Literalen.

Man unterscheidet mehrere Leistungsprobleme, deren Ursachen nicht mit der Datenbank verbunden sind:

• Netzwerkprobleme
• Anwendungsseitige Verarbeitung
• Langsames Funktionieren der Festplattenmatrix.

Um prüfen, ob in der Datenbank ein Problem mit langen Wartezeiten auf die Antwort des Netzwerkes besteht, muss man den Tab Waits > Overview öffnen und den gewählten Punkt im Diagramm anklicken. Wenn in der Datenbank hohe TCP Socket-Wartezeiten ( KGAS) auftreten, dann ist das Netzwerk die Problemursache. Die häufigsten Wartezeiten sind unterhalb des Diagramms zu sehen.

Das Problem kann auch an der Festplattenmatrix liegen. Um dies zu prüfen, muss man den Tab I/O Stats > I/O Analyzeöffnen und – je nach der geprüften Operation – entsprechend die Spalten Writes/Reads und Write time/Read timewählen. Wenn keine Zunahme der Anzahl von Lese-/Schreibvorgängen festzustellen ist und die Dauer dieser Operationen wesentlich länger wird, liegt das Problem an der Hardware oder die Festplattenmatrix wird durch andere Prozesse auf dem Server belastet, die außerhalb der Datenbank ausgeführt werden.

Um die Abfragen zu finden, die das System am stärksten belasten, muss man den Tab Performance > SQL 3D öffnen. Im Feld Draw bar ist die Kategorie zu wählen, in der die Abfragen die Datenbank belasten. Anschließend muss man das Datum einstellen und das Ergebnis nach Tag, Monat oder Snap (15 Minuten) gruppieren. Unten werden auf einem 3D-Diagramm die Abfragen angezeigt, die das System am stärksten belasten. Um eine von ihnen zu analysieren, ist die jeweilige Abfrage und dann View SQL detail anzuklicken. Infolgedessen wird der Tab SQL details geöffnet.

Im Tab Performance > SQL details sind dann der Text der jeweiligen Abfrage, Ausführungsstatistiken für den jeweiligen Zeitraum und der Abfrageausführungsplan zu sehen. Es besteht die Möglichkeit, die Leistungsstatistiken nach Snap (15 Minuten), Stunde, Tag und Monat zu gruppieren.

Nach der Auswahl einer Abfrage wird im Tab Performance > SQL Details auf dem unteren Bildschirm der Ausführungsplan angezeigt. Man muss show plan objects anklicken.

Auf dem Bildschirm sind alle in der Abfrage verwendeten Objekte zu sehen. Um zu prüfen, welche Indexe sich in der jeweiligen Tabelle befinden, muss man die Tabellenbezeichnung anklicken. Auf der rechten Seite erscheint eine Liste der auf ihr aufgebauten Indexe. Nachdem der Index angeklickt wurde, erscheinen ganz unten die im ihm verwendeten Spalten.

Um Abfragen anhand genutzter Objekte zu finden, muss man den Tab Performance > SQL Details öffnen und die auf der rechten Seite vorhandene Schaltfläche Find SQL anklicken:

Anschließend muss man den Tab Statements using objects öffnen und die Bezeichnung des Objekts eingeben. Unten erscheint eine Liste mit Abfragen, die das jeweilige Objekt nutzen, samt Hauptleistungsstatistiken für den jeweiligen Zeitraum.

Um herauszufinden, welche Abfragen den Ausführungsplan geändert haben, muss man den Tab Performance > SQL Details öffnen und die auf der rechten Seite vorhandene Schaltfläche Find SQL anklicken.

Anschließend muss man den Tab Plan Flip-Flop Statements öffnen. Nach der Aktualisierung ist eine Liste von Befehlen zu sehen, die den Ausführungsplan im jeweiligen Zeitraum geändert haben.

Um die Leistung an mehreren Tagen zu vergleichen, muss man den Tab Performance > Compare > Compare Daysöffnen. Anschließend muss man die zu vergleichenden Tage wählen und zur Liste hinzufügen. Die Grafik enthält Leistungsdaten jedes hinzugefügten Tages, die nach Snaps oder Stunden gruppiert sind. Es kann die Dauer aller Abfragen, CPU, executions, rowsprocessed, fetches, disk reads, buffer gets verglichen werden.

Um die jeweiligen Zeiträume zu vergleichen, muss man den Tab Performance > Compare > Compare > Compare Periods öffnen. Anschließend muss man zwei Zeiträume wählen, die uns interessieren. Die Grafik enthält die Leistungsdaten jedes Zeitraumes. Es kann die Dauer der Prozesse in der Datenbank, CPU, executions, fetches, rowsproccesed, disk reads, buffer gets verglichen werden.

Um die Abfrage zu finden, die ein Latch: cache buffer chains generiert, muss man den Tab Performance > Latches > Buffer Latches öffnen. Nachdem im Diagramm der jeweilige Zeitpunkt markiert wurde, erscheint eine Liste von Abfragen, die die die größte Anzahl von Puffern ablesen. Man muss prüfen, bei welcher Abfrage das Buffer Utilization am größten ist. Sie ist für das Vorhandensein des Latch: cache buffer chains verantwortlich.

Um zu prüfen, wer ein Leistungsproblem um 2 Uhr nachts verursacht hat, muss man den Tab Performance > Database load öffnen. Anschließend ist im Diagramm 2.00 Uhr nachts zu wählen. Kann man eine Zunahme der Datenbankserverauslastung feststellen, dann sollte man auf der Liste unten prüfen, welche Abfrage dafür verantwortlich war.

Um zu prüfen, wer diesen Befehl ausgeführt hat, ist der Tab Sessions > Session / Undo history zu öffnen. Anschließend muss man die Abfragekennung eingeben und finden, wer gegen 2.00 Uhr nachts die Abfrage ausgeführt hat.

Zunächst muss man den Tab Performance > Waits öffnen. Nach dem Anklicken des jeweiligen Zeitpunktes im Diagramm, ist in der Sektion ein Wait mit einer „ enq“-Komponente in der Bezeichnung zu finden. Wenn dieser vorhanden ist, muss man zum Tab Locks > Locks history übergehen.

Zuerst ist zu prüfen, ob Waits beim Speichern auftreten, d.h. logfile Sync, db file parallel write, logfile parallel write, free buffer busy. Zu diesem Zweck muss man den Tab Performance > Waits > Analyze öffnen. Anschließend sollte man alle angezeigten Waits finden und markieren.

An der Sperrsitzung befindet sich ein Pfeil mit der Möglichkeit, die restlichen Sitzungen zuzuklappen. Gesperrte Sitzungen können bis zur Sperrsitzung zugeklappt werden.

Zuerst ist zu prüfen, ob Waits beim Speichern auftreten, d.h. log file sync, db file parallel write, logfile parallel write, free buffer busy. Zu diesem Zweck muss man den Tab Performance > Waits > Analyze öffnen. Anschließend sollte man alle angezeigten Waits finden und markieren.

Anschließend muss man zum Bildschirm I/O Stats > I/O Analyze wechseln. Nachdem der gleiche Datumsbereich wie zuvor für Festplatten-Waits eingestellt wurde, sind die Spalten Writes, Write time zu markieren. Falls im Wait-Wachstumspunkt auch das Write Time zunimmt, die Anzahl der Schreibvorgänge aber nicht größer wird, dann liegt das Problem an der Festplattenmatrix. Nimmt die Anzahl der Schreibvorgänge hingegen zu, ist derjenige Befehl zu finden, der in diesem Zeitraum die meisten Daten in der Matrix gespeichert hat.

Ist die Schreibzeit eines einzelnen 8K-Datenblocks länger als 0,004 Sekunden, deutet dies natürlich auf eine langsame I/O-Funktion hin und das Problem muss außerhalb der Datenbank gesucht werden. Für eine SSD-Matrix beträgt die Lesezeit eines einzelnen 8K-Blocks 0,003 Sekunden.

Um die Abfrage zu finden, die die meisten Daten in der Matrix gespeichert hat, muss man den Tab Performance > SQL 3Döffnen, die Leiste Show additional filters ausklappen und Log generating statements öffnen. Die angezeigten Abfragen gelten als die größte Belastung beim Speichern auf der Festplattenmatrix.

Um zu analysieren, ob es Probleme beim Lesen von Daten gibt, muss man den Tab I/O Stats > I/O Analyze öffnen, dann den Datumsbereich sowie die Auflösung einstellen und in der Tabelle unten die Spalten Reads und Read timemarkieren. Falls im Diagramm die Datenlesezeit zunimmt und die Anzahl der Lesevorgänge nicht steigt, liegt das Problem beim Lesen an der Festplattenmatrix. Wenn die Anzahl der Lesevorgänge auch steigt, muss derjenige Befehl gefunden werden, der im jeweiligen Zeitraum die meisten Daten gelesen und somit Probleme beim Lesen verursacht hat.

Ist die Lesezeit eines einzelnen 8K-Datenblocks länger als 0,003 Sekunden, deutet dies natürlich auf eine langsame I/O-Funktion hin und das Problem muss außerhalb der Datenbank gesucht werden. Für eine SSD-Matrix beträgt die Lesezeit eines einzelnen 8K-Blocks 0,0002 Sekunden.

Um die Abfrage zu finden, die die meisten Daten in der Matrix gelesen hat, muss man den Tab Performance > SQL 3Döffnen und Draw bar auf Disk Reads einstellen. Die angezeigten Abfragen gelten als die größte Belastung beim Lesen der Festplattenmatrix.

Um den Prozentsatz der Datenbankbelastung durch die jeweilige Abfrage zu prüfen, muss man den Tab Performance > SQL Details öffnen. Nachdem die Abfragekennung eingegeben wurde, erscheinen der Inhalt, die Leistungsstatistik im jeweiligen Zeitraum und der Ausführungsplan. Im unteren Tab muss man Graph wählen und dann Database load for Elapsed Time markieren. Auf dem Diagramm sind die Dauer des Befehls und sein prozentualer Anteil im Vergleich zu allen Abfragen in der Datenbank zu sehen.

Um zu prüfen, inwieweit mehrere ausgewählte Abfragen die Datenbank belasten, muss man den Tab Performance > SQL Analyze öffnen. Auf dem Diagramm ist die Dauer aller unten markierter Befehle im Vergleich mit allen Abfragen in der Datenbank zu sehen.

Um Variable mit Literalen zu ersetzen, muss man zuerst den Tab Performance > SQL Details öffnen. Nachdem eine Abfrage gewählt wurde, ist das Feld Online value zu markieren. Dann erscheinen ganz unten im Ausführungsplan Werte mit ihrem Datentyp, die die Variablen ersetzen. Anschließend sollten die Werte an die Variablen im Abfrageinhalt angepasst werden.

Um zu prüfen, welche Instanzen sich auf dem jeweiligen Server befinden, muss man den Dashboard-Bildschirm starten und aus der Liste PHYSICAL SERVERS einen Server wählen – es werden alle auf dem gewählten Server vorhandenen Instanzen aufgelistet.

Nach dem Umschalten der Anzeige in Television mode bietet das Dashboard die Möglichkeit, die Belastung einzelner Instanzen zu prüfen. Auf dieser Ebene sind: Server-CPU-Belastung, Dauer der Sperren und Waits in Echtzeit zu sehen..

Die Auswahl der Datenbank aus der Liste SQL INSTANCES ermöglicht, die Leistungsstatistiken der letzten 15 Minuten anzuzeigen.

Der Dashboard-Bildschirm informiert durch eine graue Kennzeichnung, dass die jeweilige Instanz nicht verfügbar ist.

Um benutzerdefinierte Warnmeldungen einzustellen, muss man den Tab Configuration > Alert settings > Alerts definition öffnen. Die Warnmeldungen können auf 2 Ebenen definiert werden:

• allgemein
• für einzelne Datenbanken.

Um eine benutzerdefinierte Warnmeldung einzustellen, ist das Feld Add new alert anzuklicken..

Im neu geöffneten Fenster kann man, je nach Bedarf, eine benutzerdefinierte Warnmeldung einstellen.

Um einen Bericht zu generieren, muss man zum Tab Reports > Performance report wechseln. Anschließend ist ein Datumsbereich zu bestimmen und die Schaltfläche Run Report zu betätigen. Der erstellte Bericht enthält die TOP11 der Befehle:

• die am längsten dauern,
• die die CPU am längsten benutzen,
• die die meisten Daten von der Festplatte lesen,
• die die meisten Daten vom Datenpuffer lesen,
• die die am häufigsten verwendet werden.

sowie:

• Dauer der Sperren pro Stunde,
• Top 10 der am längsten dauernden Waits und Latches in der Datenbank.

Um zu prüfen, wie viele CPUs durch die Instanz und wie viele durch den Server nutzt werden, muss man zum Bildschirm Performance > Database load wechseln. Wenn man mit dem Mauszeiger über das Diagramm fährt, sind die Werte für den Zeitraum von 15 Minuten zu sehen. Dies sind u.a.: CPU Time (CPU-Auslastung durch Instanzen) und Server CPU (CPU-Auslastung durch alle Prozesse auf dem Server).

Um Informationen über den zugewiesenen RAM-Speicher zu erhalten, muss man den Tab Memory>Memory usageöffnen. Dort sieht man wie viel RAM-Speicher durch Instanzen genutzt wird, über wie viel freien Speicher der Server verfügt (TOTAL SERVER MEMORY) und wie der Speicher aufgeteilt wurde (Memory Utilization).

Um die Größe einer Instanz zu prüfen, muss man den Tab Space monitor > Current space öffnen. Auf dem Bildschirm ist der gesamte, freie und belegte Speicher der Instanz zu sehen.

Um die Speichergrößen einzelner Datenbanken zu prüfen, ist das Ergebnis nach Datenbanken zu gruppieren:

Um den historischen Speicherzuwachs einer Instanz zu prüfen, muss man den Tab Space monitor > History öffnen. Auf dem Bildschirm ist der gesamte, freie und belegte Speicher der Instanz im gewählten Zeitraum zu sehen. Um den Speicherzuwachs für einzelne Datenbanken zu prüfen, ist das Ergebnis nach Datenbanken zu gruppieren.

Um die Einstellungen einzelner Instanzparameter zu überprüfen, muss man den Tab Parameters > Instance Parameters > Server Configuration Parameters Overview öffnen. Auf dem Bildschirm werden alle Parameter in der Datenbank samt eingestelltem Wert angezeigt. Nachdem der unten stehendende Parameter gewählt wurde, erscheint ein Änderungsverlauf.

Der Bildschirm Parameters > Parameters History zeigt eine Liste aller Parameteränderungen im festgelegten Zeitraum an. Es ist möglich, einen bestimmten Parameter durch die Eingabe seiner Bezeichnung oder seines Wertes zu wählen.

Um die Einstellungen der einzelnen Datenbankparameter zu prüfen, muss man den Tab Parameters > Database Parameters > Database Parameters Overview öffnen. Auf dem Bildschirm werden alle Parameter in der Datenbank samt eingestelltem Wert angezeigt. Nachdem der unten stehendende Parameter gewählt wird, erscheint der Änderungsverlauf.

Der Bildschirm Parameters > Database Parameters > Database Parameters History zeigt eine Liste aller Parameteränderungen im festgelegten Zeitraum an. Es ist möglich, einen bestimmten Parameter durch Eingabe seiner Bezeichnung oder seines Wertes zu finden.

Um I/O-Befehle zu finden, die das System am stärksten belasten, muss man den Tab Performance > SQL 3D öffnen. Um die Abfragen zu sehen, die das System beim Ablesen der Festplattenmatrix am stärksten belasten ist Draw bar auf Disk Reads einzustellen.

Um zu prüfen, welche Sitzung die meisten Änderungen in der Instanz vornimmt, muss man den Tab Sessions > Log usage sessions öffnen und die Spalte Log record count absteigend sortieren. Die Sitzung mit der höchsten Zahl ist für die meisten Änderungen verantwortlich.

Um die Befehle zu finden, die für den Latch Shared_pool verantwortlich sind, muss man den Tab Performance > SQL 3Döffnen und anschließend Draw bar auf Buffer Writes einstellen, um die Abfragen zu sehen, die die meisten Daten speichern.

Um die Instanzbelastung in den letzten 2 Jahren zu analysieren, muss man den Tab Performance > Load trends öffnen. Dann sind der Datumsbereich für die letzten 24 Monate und die Gruppierung nach Monaten einzustellen. Standardmäßig ist das Diagramm Elapsed time zu sehen, das die Dauer aller Befehle in einer Instanz anzeigt.

Um zu prüfen, welche Abfragen an welche Datenbank die höchste Belastung verursachen, muss man den Tab Performance > SQL Analyze öffnen. Nachdem der Tab Database Load angeklickt und die Tabellen nach der Spalte Elapsed Time absteigend sortiert wurden, wird eine Liste der am stärksten belasteten Datenbanken angezeigt.

Die zweite Möglichkeit zu prüfen, welche Abfragen an welche Datenbank die höchste Belastung verursachen, ist das Öffnen des Tabs Performance > Instance load. Anschließend muss man oben rechts in der Ecke All databasesanklicken. Es erscheint eine Zusammenstellung, die den jeweiligen Anteil an der Belastung jeder Datenbank im gewählten Zeitraum darstellt.

Um zu prüfen, wer die jeweilige Abfrage ausgeführt hat, muss man den Tab Sessions > Active Sessions / Log usage sessions history öffnen. Nach Eingabe der Abfragekennung im Feld Using Query Hash erscheint unten eine Liste aller Sitzungen, die die Abfrage im jeweiligen Zeitraum ausgeführt haben.

Um die Leistungsstatistiken für die jeweilige Abfrage zu prüfen, muss man den Tab Performance > SQL Details öffnen. Nachdem die Abfragekennung eingegeben oder aus einer Liste in der Sektion SQL STATISTICS ausgewählt wurde, erscheinen Leistungsstatistiken für den jeweiligen Zeitraum. Es ist möglich, die Ergebnisse nach Monat, Woche Stunde oder Snap (15 Minuten) zu gruppieren.

Um den Ausführungsplan zu prüfen, muss man den Tab Performance > SQL Detail öffnen. Nachdem die Abfragekennung eingegeben oder aus einer Liste ganz unten im Tab Explain plan gewählt wurde, erscheint der Ausführungsplan.

Manchmal nutzt eine Abfrage mehrere Ausführungspläne. Nachdem das Feld Compare Plans markiert wurde, erscheint ein zweiter Ausführungsplan. Auf diese Weise kann man die Unterschiede hervorheben und den Grund für das langsame Funktionieren mit dem jeweiligen Ausführungsplan finden..

Es kann auch der Ausführungsplan für eine aktive Sitzung geprüft werden. Zu diesem Zweck muss man den Tab Sessions öffnen. Nachdem eine Sitzung markiert wurde, erscheinen unten der Text der ausgeführten Abfrage und der Ausführungsplan.

Um zu prüfen, inwieweit der Speicher auf dem Server von Instanzen genutzt wird, muss man den Tab Memory > Memory usage öffnen. Auf der rechten Seite des Bildschirms erscheint ein Diagrammm auf dem Folgendes zu sehen ist:
• Verfügbarer RAM-Speicher und seine Nutzung durch alle auf dem Server laufenden Prozesse (Diagrammbalken im blauen Rahmen),
• Durch SQL-Instanzen genutzter Speicher (Diagrammbalken im grünen Rahmen).

Um zu prüfen, ob die SQL-Instanz den zugewiesenen Speicher hundertprozentig nutzt, muss man den Tab Memory > Memory usage öffnen. Anschließend sollte man den Wert von Max Server memory mit dem Wert des von Instanzen genutzten Speichers vergleichen. Außerdem ist zu prüfen, ob sich einzelne Speicherbereiche (Sektion Memory Utilization for last snapshot) zur vollen Speichergröße addieren – dann wissen wir, dass SQL den zugewiesenen Speicher hundertprozentig nutzt.

Einzelne Komponenten der Speicherpuffer befinden sich im Tab Memory > Memory usage in der Sektion MEMORY UTILIZATION. Wenn man den Mauszeiger über eine Komponente bewegt, wird im Diagramm ihr Wert angezeigt.

Um den Verlauf der Speicherparametereinstellungen zu prüfen, muss man den Tab Memory > Memory usage history öffnen. Dort ist die Belegung einzelner Speicherelemente im gewählten Zeitraum zu sehen.

Um zu prüfen, welche Sitzung den tempdb-Speicherbereich im größten Umfang nutzt, muss man den Tab Sessions > Temp usage sessions öffnen. Dort ist die Belegung des temporären Speicherbereiches (tempdb) und eine Liste der Sitzungen zu sehen, die den Speicher nutzen. Um gesuchte Sitzungen anzuzeigen, ist die Spalte Total Space Used absteigend zu sortieren.

Es werden einige Leistungsprobleme unterschieden, deren Ursache nicht mit der Instanz verbunden ist, d.h.:

• Anwendungsseitige Verarbeitung
• Langsames Funktionieren der Festplattenmatrix.

Oft sind lange Wartezeiten in Anwendungen die Problemursache. Die Folge davon sind Sperren. Die Sperrsitzung der Instanz ist inaktiv und führt nichts aus, während sie auf ein commit / eine Antwort vonseiten der Anwendung wartet. Um ein solches Problem zu analysieren, muss man den Tab Locks > Locks history öffnen. Falls auf dem Diagramm langfristige Sperren zu sehen sind und die Sperrsitzung permanent den Status SLEEPING hat, ist die lange Wartezeit auf eine Antwort vonseiten der Anwendung für das Problem verantwortlich.

Das Problem kann auch an der Festplattenmatrix liegen. Um dies zu prüfen, muss man den Tab I/O Stats > I/O Analyzeöffnen und – je nach der geprüften Operation – entsprechend die Spalten Writes/Reads und Write time/Read timewählen. Wenn keine Zunahme der Anzahl von Lese-/Schreibvorgängen festzustellen ist und die Dauer dieser Operationen wesentlich länger wird, liegt das Problem an der Hardware oder die Festplattenmatrix wird durch andere Prozesse auf dem Server belastet, die außerhalb der Datenbank ausgeführt werden.

Um die Abfragen zu finden, die das System am stärksten belasten, muss man den Tab Performance > SQL 3D öffnen. Im Feld Draw bar ist die Kategorie zu wählen, in der die Abfragen die Datenbank belasten. Anschließend muss man das Datum einstellen und das Ergebnis nach Tag, Monat oder Snap (15 Minuten) gruppieren. Unten werden auf einem 3D-Diagramm die Abfragen angezeigt, die das System am stärksten belasten. Um eine von ihnen zu analysieren, ist die jeweilige Abfrage und dann View SQL detail anzuklicken. Infolgedessen wird der Tab SQL details geöffnet.

Im Tab Performance > SQL-Details sind der Text, die Ausführungsstatistiken für den jeweiligen Zeitraum und der Abfrageausführungsplan zu sehen. Es besteht die Möglichkeit, die Leistungsstatistiken nach Snap (15 Minuten), Stunde, Tag und Monat zu gruppieren.

Nach der Auswahl einer Abfrage wird im Tab Performance > SQL Details auf dem unteren Bildschirm der Ausführungsplan angezeigt. Man muss show plan objects anklicken:

Auf dem Bildschirm sind alle in der Abfrage verwendeten Objekte zu sehen. Um zu prüfen, welche Indexe sich in der jeweiligen Tabelle befinden, muss man die Tabellenbezeichnung anklicken. Auf der rechten Seite erscheint eine Liste der auf ihr aufgebauten Indexe. In der Spalte Index columns sind Spalten vorhanden, in denen ein Index eingerichtet wurde. Nachdem der Index angeklickt wurde, erscheinen unten ausführliche Informationen zu den Spalten.

Um Abfragen zu finden, die auf genutzten Objekten basieren, muss man den Tab Performance > SQL Details öffnen und dann ist die Schaltfläche Find SQL anklicken:

Anschließend ist der Tab Statement by text zu öffnen und die Tabellenbezeichnung einzugeben. Unten erscheint eine Liste von Abfragen, die die genannte Tabelle nutzen, einschließlich grundlegender Leistungsstatistiken für den jeweiligen Zeitraum.

Um herauszufinden, welche Abfragen den Ausführungsplan geändert haben, muss man den Tab Performance > SQL Details öffnen und die auf der rechten Seite vorhandene Schaltfläche Find SQL anklicken.

Anschließend muss man den Tab Plan Flip-Flop Statements öffnen. Nach der Aktualisierung ist eine Liste von Befehlen zu sehen, die den Ausführungsplan im jeweiligen Zeitraum geändert haben.

Um die Leistung an mehreren Tagen zu vergleichen, muss man den Tab Performance > Compare Trends > Compare Days öffnen. Anschließend muss man die zu vergleichenden Tage wählen und zur Liste hinzufügen. Die Grafik enthält Leistungsdaten jedes hinzugefügten Tages, die nach Snaps oder Stunden gruppiert sind.

Um bestimmte Zeiträume zu vergleichen, muss man den Tab Performance > Compare trends > Compare Periodsöffnen. Anschließend muss man zwei für uns interessante Zeiträume wählen. Die Grafik enthält Leistungsdaten jedes Zeitraumes.

Um zu prüfen, wer das Leistungsproblem um 2 Uhr nachts verursacht hat, muss man den Tab Performance > Instance load öffnen. Anschließend ist im Diagramm 2.00 Uhr nachts zu wählen. Kann man eine Zunahme der Datenbankserverauslastung feststellen, dann sollte man auf einer Liste unten prüfen, welche Abfrage dafür verantwortlich war.

Um zu prüfen, wer diesen Befehl ausgeführt hat, ist der Tab Sessions > Active sessions / Log usage sessions history zu öffnen. Anschließend muss man die Abfragekennung eingeben und finden, wer gegen 2.00 Uhr nachts die Abfrage ausgeführt hat.

Zunächst muss man den Tab Performance > Waits öffnen. Nach dem Anklicken des jeweiligen Zeitpunktes im Diagramm, ist in der Sektion ein Wait mit einer „LCK“-Komponente in der Bezeichnung zu finden. Ist dieser vorhanden, dann muss man entsprechend den nachfolgenden Anweisungen verfahren.

Anschließend muss man den Tab Locks > Locks history öffnen. Das Diagramm zeigt die Wartezeit der Sitzung und die Anzahl der Sitzungen in der Sperre im jeweiligen Zeitraum an. Nach dem Anklicken des Punktes erscheint eine Liste der sperrenden und gesperrten Sitzungen.

Bei einer Sperrsitzung befindet sich einen Pfeil mit der Möglichkeit, die restlichen Sitzungen zuzuklappen. Gesperrte Sitzungen können bis zur Sperrsitzung zugeklappt werden. Das Problem liegt an der Instanz, wenn eine Sperrsitzung aktiv ist und sie Befehle in der Datenbank ausführt. Ist die Sperrsitzung ruhend (status sleeping), ist die Anwendung für das Problem verantwortlich.

Zuerst ist zu prüfen, ob Waits beim Speichern, d.h. writelogs auftreten. Zu diesem Zweck muss man den Tab Performance > Waits > Analyze öffnen. Anschließend sollte man alle angezeigten Waits finden und markieren.

Anschließend muss man zum Bildschirm I/O Stats > I/O Analyze wechseln. Nachdem der gleiche Datumsbereich, wie zuvor für Festplatten-Waits, eingestellt wurde, sind die Spalten Writes, Write time zu markieren. Falls im Wait-Wachstumspunkt auch die Write time zunimmt, die Anzahl der Schreibvorgänge aber nicht größer wird, dann liegt das Problem an der Festplattenmatrix. Nimmt die Anzahl der Schreibvorgänge hingegen zu, ist derjenige Befehl zu finden, der in diesem Zeitraum die meisten Daten in der Matrix gespeichert hat.

Um herauszufinden, welche Abfrage die meisten Daten in der Matrix gespeichert hat, muss man den Tab Performance > SQL 3D öffnen und Draw bar auf Buffer Writes einstellen. Die angezeigten Abfragen gelten als die größte Belastung beim Speichern auf der Festplattenmatrix.

Zuerst ist zu prüfen, ob auf der Festplatte Waits beim Lesen auftreten, d.h. pageiolatch_sh. Zu diesem Zweck muss man den Tab Performance > Waits > Analyze öffnen und den Wait pageiolatch_sh finden.

Anschließend muss man zum Bildschirm I/O Stats > I/O Analyze wechseln und den gleichen Datumsbereich wie zuvor für den Wait pageiolatch_sh einstellen. Falls im Wait-Wachstumspunkt auch die Read time wächst und die Anzahl der Lesevorgänge dabei nicht zunimmt, dann liegt das Problem an der Festplattenmatrix.

Um zu prüfen zu welchem Prozentsatz eine Abfrage die Instanzen belastet, muss man den Tab Performance > SQL Details öffnen. Nachdem die Abfragekennung eingegeben wurde, erscheinen auf dem Bildschirm: der Inhalt, die Leistungsstatistik für den jeweiligen Zeitraum und der Ausführungsplan. Im unteren Tab muss man Graph wählen und dann Database load for Elapsed Time markieren. Auf dem Diagramm sind die Dauer des Befehls und sein prozentualer Anteil im Vergleich zu allen Abfragen in der Datenbank zu sehen.

Um zu prüfen, inwieweit mehrere ausgewählte Abfragen die Instanz belasten, muss man den Tab Performance > SQL Analyze öffnen. Auf dem Diagramm ist die Dauer aller unten markierter Befehle im Vergleich mit allen Abfragen in der Instanz zu sehen.