AWR: Wie „exadatet“ sich die Performance einer Datenbank?

Mit diesem kurzen Beitrag möchte ich ein Missverständnis bezüglich der Analyse von AWR-Datenbanken, die auf Oracle Exadata basieren, ausräumen. Seit fast 10 Jahren sehe ich mich ständig mit der Frage konfrontiert: Wie trägt die Exadata-Software zur Leistung bei? Oder um es mit neu geschaffenen Wörtern auszudrücken: Wie sehr „exadatet“ die Arbeit jener oder jener Datenbank?

Auf diese berechtigte Frage wird, meiner Meinung nach, oft eine falsche Antwort gegeben, die sich auf AWR-Statistiken stützt. Diese präsentieren ein Verfahren für systemische Wartezeiten, das die Antwortzeit als Summe der CPU-Zeit der Datenbank (DB CPU) und der Wartezeiten verschiedener Klassen interpretiert.

Mit dem Erscheinen von Exadata sind spezifische systemische Wartezeiten in die AWR-Statistik aufgenommen worden, die mit der Exadata-Software in Zusammenhang stehen. In der Regel beginnen die Bezeichnungen solcher Wartezeiten mit dem Wort „cell“ (ein Exadata-Speicherserver wird als Zelle bezeichnet), wobei die am häufigsten vorkommenden Wartezeiten die sprechenden Bezeichnungen „cell smart table scan“, „cell multiblock physical read“ und „cell single block physical read“ tragen.

In den meisten Fällen ist der Anteil solcher Exadata-Wartezeiten an der Gesamtantwortzeit gering, weshalb sie nicht einmal im Abschnitt der Top 10 der Vordergrundereignisse nach Gesamtwartezeit auftauchen (in diesem Fall müssen sie im Abschnitt der Vordergrundwarteereignisse gesucht werden). Wir haben mit viel Mühe bei unseren Kunden ein tägliches AWR-Beispiel gefunden, in dem die Exadata-Wartezeiten in den Abschnitt der Top 10 aufgenommen wurden und insgesamt etwa 5% ausmachten:

Ereignis

Wartezeiten

Gesamte Wartezeit (Sek.)

Durchschnittliche Wartezeit

% DB-Zeit

Warteklasse

DB CPU

115.2K

70.4

SQL*Net mehr Daten von DB-Link

670,196

5471.5

8.16ms

3.3

Netzwerk

cell single block physical read

5,661,452

3827.6

676.07us

2.3

Benutzer I/O

Synchron ASM-Neuverteilung

4,350,012

3481.3

800.30us

2.1

Sonstige

cell multiblock physical read

759,885

2252

2.96ms

1.4

Benutzer I/O

direkt Pfadlesen

374,368

1811.3

4.84ms

1.1

Benutzer I/O

SQL*Net Nachricht von DB-Link

7,983

1725

216.08ms

1.1

Netzwerk

cell smart table scan

1,007,520

1260.7

1.25ms

0.8

Benutzer I/O

direkt Pfadlesen temporär

520,211

808.4

1.55ms

0.5

Benutzer I/O

enq: TM — Konflikt

652

795.8

1220.55ms

0.5

Anwendung

Aus solchen AWR-Statistiken werden oft folgende Schlussfolgerungen gezogen:

1. Der Beitrag der Magie von Exadata zur Datenbankleistung ist nicht hoch — er übersteigt 5 % nicht, und die Datenbank „exadatet“ schlecht.

2. Wenn eine solche Datenbank von Exadata auf eine klassische Architektur „Server + Array“ migriert wird, wird sich die Leistung nicht stark ändern. Denn selbst wenn sich dieses Array als dreimal langsamer erweist als das Exadata-Speichersystem (was für moderne All-Flash-Arrays kaum möglich ist), erhalten wir durch Multiplikation von 5 % mit drei einen Anstieg des Anteils an E/A-Wartezeiten auf 15 % — so eine Datenbank wird das mit Sicherheit überstehen!

Beide diese Schlussfolgerungen sind ungenau; mehr noch, sie verzerren das Verständnis der Idee, die in Exadata Software steckt. Exadata bietet nicht nur schnellen Input/Output, sie funktioniert grundlegend anders als die klassische Architektur „Server + Array“. Wenn die Datenbank tatsächlich „exadatet“, wird die SQL-Logik auf das Speichersystem übertragen. Storage Server findet dank einer Reihe spezieller Mechanismen (insbesondere den Exadata Storage Indexes, aber nicht nur) selbstständig die benötigten Daten und überträgt sie an die DB-Server. Sie tun dies ziemlich effizient, weshalb der Anteil typischer Exadata-Wartezeiten an der Gesamtreaktionszeit gering ist. 

Wie wird sich dieser Anteil außerhalb von Exadata verändern? Wie wird sich das auf die Gesamtleistung der Datenbank auswirken? Am besten können diese Fragen durch Tests beantwortet werden. Beispielsweise kann das Warten auf „Cell Smart Table Scan“ außerhalb von Exadata in einen so schweren Table Full Scan umschlagen, dass der Input/Output die gesamte Reaktionszeit in Anspruch nimmt und die Leistung dramatisch sinkt. Deshalb ist es falsch, beim Analysieren von AWR den Gesamtprozentsatz der Exadata-Wartezeiten als Beitrag ihrer Magie zur Leistung zu betrachten und insbesondere diesen Prozentsatz zur Prognose der Leistung außerhalb von Exadata zu verwenden. Um zu verstehen, wie stark die Arbeit der Datenbank „exadatet“, muss man die Statistiken der AWR-Sektion „Instance Activity Stats“ (dort gibt es viele Statistiken mit sprechenden Namen) studieren und sie miteinander vergleichen.

Um herauszufinden, wie sich die Datenbank außerhalb von Exadata verhalten wird, ist es am besten, aus einem Backup einen Klon der Datenbank auf der Zielarchitektur zu erstellen und die Leistung dieses Klons unter Belastung zu analysieren. Diese Möglichkeit haben normalerweise die Besitzer von Exadata.

Autor: Alexey Struchenko, Leiter der Datenbankabteilung „Infostat Jet“

Quelle: habr.com