Mit diesem kurzen Beitrag möchte ich ein Missverständnis im Zusammenhang mit der Analyse von AWR-Datenbanken, die auf Oracle Exadata laufen, ausräumen. Seit fast 10 Jahren stehe ich ständig vor der Frage: Welchen Beitrag leistet Exadata Software zur Produktivität? Oder mit neu geprägten Worten: Wie „expertise“ ist die Arbeit einer bestimmten Datenbank?
Oftmals wird diese richtige Frage meiner Meinung nach mit Bezug auf die AWR-Statistik falsch beantwortet. Es stellt die Systemwartemethode vor, die die Antwortzeit als Summe der Betriebszeit von Prozessoren (DB-CPUs) und der Wartezeit verschiedener Klassen behandelt.
Mit der Einführung von Exadata tauchten in den AWR-Statistiken spezifische Systemerwartungen im Zusammenhang mit dem Betrieb der Exadata-Software auf. In der Regel beginnen die Namen solcher Wartevorgänge mit dem Wort „Zelle“ (der Exadata Storage-Server wird als Zelle bezeichnet), am häufigsten sind Wartevorgänge mit den selbsterklärenden Namen „Cell Smart Table Scan“ und „Cell Multiblock“. „Physical Read“ und „Cell Single Block Physical Read“.
In den meisten Fällen ist der Anteil solcher Exadata-Wartezeiten an der Gesamtantwortzeit gering und daher fallen sie nicht einmal in den Abschnitt „Top 10 Vordergrundereignisse nach Gesamtwartezeit“ (in diesem Fall müssen Sie im Abschnitt „Vordergrundwartezeit“ danach suchen). Abschnitt „Veranstaltungen“. Mit großer Mühe haben wir ein Beispiel für den täglichen AWR unserer Kunden gefunden, bei dem die Exadata-Erwartungen in der Top10-Sektion enthalten waren und insgesamt etwa 5 % ausmachten:
Event
Wartet
Gesamtwartezeit (Sek.)
Durchschnittlich warten
%DB-Zeit
Warteklasse
DB-CPU
115.2k
70.4
SQL*Net mehr Daten von dblink
670,196
5471.5
8.16ms
3.3
Netzwerk
Physisches Lesen einzelner Zellenblöcke
5,661,452
3827.6
676.07us
2.3
Benutzer-E/A
ASM-Neuausrichtung synchronisieren
4,350,012
3481.3
800.30us
2.1
Andere
Physischer Multiblock-Lesevorgang für Zellen
759,885
2252
2.96ms
1.4
Benutzer-E/A
direkter Pfad lesen
374,368
1811.3
4.84ms
1.1
Benutzer-E/A
SQL*Net-Nachricht von dblink
7,983
1725
216.08ms
1.1
Netzwerk
Zell-Smart-Table-Scan
1,007,520
1260.7
1.25ms
0.8
Benutzer-E/A
direkter Pfad Lesetemp
520,211
808.4
1.55ms
0.5
Benutzer-E/A
enq: TM - Streit
652
795.8
1220.55ms
0.5
Anwendung
Aus solchen AWR-Statistiken werden häufig 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 „Server + Array“-Architektur übertragen wird, ändert sich an der Leistung nicht viel. Denn selbst wenn sich herausstellt, dass dieses Array dreimal langsamer ist als das Exadata-Speichersystem (was für moderne All-Flash-Arrays kaum möglich ist), dann erhalten wir bei Multiplikation von 5 % mit drei eine Erhöhung des Anteils der I/O-Wartezeiten auf 15 %. - die Datenbank wird das sicher überstehen!
Beide Schlussfolgerungen sind unzutreffend und verzerren darüber hinaus das Verständnis der Idee hinter Exadata Software. Exadata bietet nicht nur schnellen I/O, es funktioniert auch grundlegend anders als die klassische Server- und Array-Architektur. Wenn der Datenbankbetrieb wirklich „exadaptiert“ ist, wird die SQL-Logik auf das Speichersystem übertragen. Speicherserver finden dank einer Reihe spezieller Mechanismen (hauptsächlich Exadata-Speicherindizes, aber nicht nur) selbst die erforderlichen Daten und senden die Datenbank an die Server. Dies geschieht recht effizient, sodass der Anteil der typischen Exadata-Wartezeiten an der Gesamtantwortzeit gering ist.
Wie wird sich dieser Anteil außerhalb von Exadata ändern? Wie wirkt sich dies auf die Leistung der Datenbank insgesamt aus? Tests werden diese Fragen am besten beantworten. Beispielsweise kann das Warten auf einen „Cell Smart Table Scan“ außerhalb von Exadata zu einem so umfangreichen Table Full Scan führen, dass I/O die gesamte Antwortzeit in Anspruch nimmt und die Leistung dramatisch abnimmt. Aus diesem Grund ist es falsch, bei der Analyse des AWR den Gesamtprozentsatz der Exadata-Erwartungen als Beitrag seiner Magie zur Leistung zu betrachten und noch mehr, diesen Prozentsatz zur Vorhersage der Leistung außerhalb von Exadata zu verwenden. Um zu verstehen, wie „genau“ die Arbeit der Datenbank ist, müssen Sie die AWR-Statistiken des Abschnitts „Instance Activity Stats“ studieren (es gibt viele Statistiken mit selbsterklärenden Namen) und sie miteinander vergleichen.
Und um zu verstehen, wie sich eine Datenbank außerhalb von Exadata anfühlt, erstellen Sie am besten einen Datenbankklon aus einem Backup auf der Zielarchitektur und analysieren die Leistung dieses Klons unter Last. Exadata-Besitzer haben in der Regel diese Möglichkeit.
Autor: Alexey Struchenko, Leiter der Datenbankabteilung von Jet Infosystems
Source: habr.com