AWR: Wie „exadatiert“ die Datenbankarbeit?

Mit diesem kurzen Beitrag möchte ich ein Missverständnis über die Analyse von AWR-Datenbanken, die auf Oracle Exadata laufen, ausräumen. Fast 10 Jahre lang bin ich ständig mit der Frage konfrontiert worden: Welchen Beitrag leistet die Exadata-Software zur Leistung? Oder, um neu geprägte Wörter zu verwenden: Wie sehr wird die Leistung einer bestimmten Datenbank durch Exadata beeinflusst?

Auf diese richtige Frage, meiner Meinung nach, wird oft eine falsche Antwort gegeben, die sich auf AWR-Statistiken stützt. Diese präsentiert eine Methode der systematischen Wartezeiten, die die Antwortzeiten als Summe der Prozessorauslastung (DB CPU) und der Wartezeiten verschiedener Klassen interpretiert.

Mit dem Erscheinen von Exadata sind in der AWR-Statistik spezifische systematische Wartezeiten hinzugekommen, die mit der Funktionsweise der Exadata-Software verbunden sind. In der Regel beginnen die Bezeichnungen dieser Wartezeiten mit dem Wort „cell“ (eine Zelle bezeichnet den Exadata Storage-Server). Häufig sind Wartezeiten mit den aussagekräftigen Bezeichnungen „cell smart table scan“, „cell multiblock physical read“ und „cell single block physical read“ zu finden.

In den meisten Fällen ist der Anteil solcher Exadata-Wartezeiten an der Gesamtreaktionszeit gering, sodass sie nicht einmal im Abschnitt der Top 10 Foreground Events by Total Wait Time auftauchen (in diesem Fall müssen sie im Abschnitt Foreground Wait Events gesucht werden). Nur mit großem Aufwand fanden wir bei unseren Kunden ein Beispiel eines täglichen AWR-Berichts, in dem die Exadata-Wartezeiten in die Top 10 aufstiegen und insgesamt etwa 5 % ausmachten:

Ereignis

Wartezeiten

Gesamtwartezeit (Sek.)

Durchschnittliche Wartezeit

% DB-Zeit

Warteklasse

DB CPU

115,2K

70.4

SQL*Net weitere Daten von dblink

670,196

5471.5

8,16 ms

3.3

Netzwerk

Cell einfacher Block physikalisch lesen

5,661,452

3827.6

676,07 µs

2.3

Benutzer I/O

Sync ASM-Ausgleich

4,350,012

3481.3

800,30 µs

2.1

Andere

Cell Multiblock physikalisch lesen

759,885

2252

2,96 ms

1.4

Benutzer I/O

direkt Pfad lesen

374,368

1811.3

4,84 ms

1.1

Benutzer I/O

SQL*Net Nachricht von dblink

7,983

1725

216,08 ms

1.1

Netzwerk

Cell intelligenter Tabellen-Scan

1,007,520

1260.7

1,25 ms

0.8

Benutzer I/O

direkt Pfadlesen temporär

520,211

808.4

1,55 ms

0.5

Benutzer I/O

enq: TM — Konkurrenz

652

795.8

1220,55 ms

0.5

Application

Aus solchen AWR-Statistiken werden oft folgende Schlussfolgerungen gezogen:

1. Der Beitrag der Exadata-Magie zur Datenbankleistung ist nicht hoch — er überschreitet nicht 5 %, und die Datenbank 'exadatisiert' schlecht.

2. Wenn eine solche Datenbank von Exadata auf die klassische Architektur „Server + Array“ übertragen wird, ändert sich die Leistung nicht wesentlich. Denn selbst wenn dieses Array dreimal langsamer ist als das Speichersystem von Exadata (was für moderne All-Flash-Arrays kaum möglich ist), ergibt sich durch die Multiplikation von 5 % mit drei eine Erhöhung des Anteils an Eingabe-/Ausgabewarteschlangen auf 15 % — eine solche Datenbank wird das mit Sicherheit überstehen!

Beide Schlussfolgerungen sind ungenau, mehr noch, sie verzerren das Verständnis der Idee, die in Exadata Software steckt. Exadata sorgt nicht nur für schnellen Input/Output, sondern funktioniert grundsätzlich anders als die klassische Architektur „Server + Array“. Wenn die Datenbank tatsächlich „exadatiert“ ist, wird die SQL-Logik auf das Speichersystem übertragen. Server Dank einer Reihe spezieller Mechanismen (vor allem Exadata Storage Indexes, aber nicht nur) finden die Systeme selbst die benötigten Daten und senden sie an die DB-Server. Sie tun dies ausreichend effizient, weshalb der Anteil der typischen Exadata-Wartezeiten an der Gesamtreaktionszeit gering ist. 

Wie wird sich dieser Anteil außerhalb von Exadata verändern? Welche Auswirkungen hat das auf die Gesamtleistung der Datenbank? Die besten Antworten auf diese Fragen liefert das Testen. Zum Beispiel kann das Warten auf den »Cell Smart Table Scan« außerhalb von Exadata zu einem so intensiven Table Full Scan werden, dass die E/A alle Reaktionszeiten in Anspruch nimmt und die Leistung dramatisch sinkt. Aus diesem Grund ist es falsch, bei der Analyse von AWR den Gesamtprozentsatz der Exadata-Wartezeiten als Beitrag ihrer Magie zur Leistung zu betrachten und erst recht, diesen Prozentsatz zur Leistungsprognose außerhalb von Exadata zu verwenden. Um zu verstehen, wie sehr die Arbeit der Datenbank „exadatisiert“ wird, müssen die Statistiken im AWR-Bereich „Instance Activity Stats“ untersucht werden (dort finden sich viele Statistiken mit aussagekräftigen Bezeichnungen) und miteinander verglichen werden.

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

Autor: Alexey Struchenko, Leiter der Datenbankabteilung bei »Infosystemy Jet«

Quelle: habr.com