Fehlerbehebung und Optimieren der Datenbankleistung

Diese Berechnung gibt einen Anhaltspunkt über die durchschnittliche Zahl
von Zeilen, die aus Datenbanktabellen gelesen werden, um die Zeilen zu finden,
die den Auswahlbedingungen entsprechen. Niedrige Werte sind ein Hinweis
auf die Effizienz der Datensuche und geben im Allgemeinen an, dass
Indizes effektiv genutzt werden. Dieser Wert kann zum Beispiel sehr hoch
sein, wenn das System zahlreiche Tabellensuchen ausführt und Millionen von
Zeilen geprüft werden müssen, um festzustellen, ob sie den Bedingungen für
die Ergebnismenge entsprechen. Andererseits kann dieser Statistikwert sehr
niedrig sein, wenn auf eine Tabelle über einen vollständig qualifizierten eindeutigen
Index zugegriffen wird. Zugriffspläne mit reinem Indexzugriff (bei
denen keine Zeilen aus der Tabelle gelesen werden müssen) erhöhen den Wert
für ROWS_READ nicht.
In einer OLTP-Umgebung ist dieser Messwert im Allgemeinen nicht höher als
2 oder 3, was darauf hinweist, dass der Zugriff überwiegend über Indizes und
nicht durch Tabellensuchen erfolgt. Dieser Messwert bietet eine einfache Methode,
die Planstabilität über einen Zeitraum hinweg zu überwachen: Eine unerwartete
Erhöhung ist häufig ein Hinweis darauf, dass ein Index nicht mehr
verwendet wird. Dies sollte untersucht werden.
5. Der Zeitaufwand für das Sortieren pro Transaktion:
TOTAL_SORT_TIME / TOTAL_COMMITS
Dies ist eine effiziente Methode zur Behandlung von Sortierstatistiken, weil
zusätzlicher Zeitaufwand für Sortierüberläufe automatisch in diesem Wert berücksichtigt
wird. Trotzdem kann es auch sinnvoll sein, die Werte TOTAL-
_SORTS und SORT_OVERFLOWS zur bequemen Analyse zu erfassen, insbesondere
wenn Ihr System bereits in der Vergangenheit Sortierprobleme hatte.
6. Aufgelaufene Wartezeit pro Tausend Transaktionen:
1000 * LOCK_WAIT_TIME / TOTAL_COMMITS
Übermäßige Wartezeiten auf Sperren schlagen sich häufig in einer schlechten
Antwortzeit nieder, sodass es wichtig ist, die Wartezeit zu überwachen. Der
Wert wird auf ein Tausend Transaktionen normalisiert, weil die Wartezeit auf
Sperren für eine einzelne Transaktion in der Regel recht gering ist. Die Skalierung
auf ein Tausend Transaktionen stellt Messwerte zur Verfügung, die leichter
zu handhaben sind.
7. Die Anzahl von Deadlocks und Überschreitungen von Sperrzeitlimits pro Tausend
Transaktionen:
1000 * (DEADLOCKS + LOCK_TIMEOUTS) / TOTAL_COMMITS
Während Deadlocks in den meisten Produktionssystemen vergleichsweise selten
auftreten, können Überschreitungen von Sperrzeitlimits häufiger vorkommen.
Die Anwendung muss sie gewöhnlich auf ähnliche Weise behandeln: Die
Ausführung der Transaktion muss von Anfang an wiederholt werden. Die
Überwachung der Rate, mit der solche Fälle auftreten, hilft bei der Vermeidung
einer Situation, in der viele Deadlocks oder Überschreitungen von Sperrzeitlimits
eine erhebliche Zusatzbelastung im System verursachen, ohne dass
sich der Datenbankadministrator dessen bewusst ist.
8. Die Anzahl von Triggern zum Stehlen (Neuzuordnung) genutzter Seiten pro
Tausend Transaktionen:
1000 * POOL_DRTY_PG_STEAL_CLNS / TOTAL_COMMITS
Das „Stehlen (Neuzuordnen) genutzter Seiten” ist die am wenigsten wünschenswerte
Methode zur Auslösung einer Pufferpoolbereinigung. Im Wesentlichen
wird die Verarbeitung einer SQL-Anwendung, die eine neue Puffer-
Kapitel 2. Tools und Vorgehensweise bei der Leistungsüberwachung 17