![\"AWR:](\"\/wp-content\/uploads\/2020\/09\/b0ca997a4bd415723ae56c183e2dd42f.jpeg\")
<\/p>\nMit diesem kurzen Beitrag m\u00f6chte ich ein Missverst\u00e4ndnis bez\u00fcglich der Analyse von AWR-Datenbanken, die auf Oracle Exadata basieren, ausr\u00e4umen. Seit fast 10 Jahren sehe ich mich st\u00e4ndig mit der Frage konfrontiert: Wie tr\u00e4gt die Exadata-Software zur Leistung bei? Oder um es mit neu geschaffenen W\u00f6rtern auszudr\u00fccken: Wie sehr \u201eexadatet\u201c die Arbeit jener oder jener Datenbank?<\/p>\n
<\/p>\n
Auf diese berechtigte Frage wird, meiner Meinung nach, oft eine falsche Antwort gegeben, die sich auf AWR-Statistiken st\u00fctzt. Diese pr\u00e4sentieren ein Verfahren f\u00fcr systemische Wartezeiten, das die Antwortzeit als Summe der CPU-Zeit der Datenbank (DB CPU) und der Wartezeiten verschiedener Klassen interpretiert.<\/p>\n
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 \u201ecell\u201c (ein Exadata-Speicherserver wird als Zelle bezeichnet), wobei die am h\u00e4ufigsten vorkommenden Wartezeiten die sprechenden Bezeichnungen \u201ecell smart table scan\u201c, \u201ecell multiblock physical read\u201c und \u201ecell single block physical read\u201c tragen.<\/p>\n
In den meisten F\u00e4llen 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\u00fcssen sie im Abschnitt der Vordergrundwarteereignisse gesucht werden). Wir haben mit viel M\u00fche bei unseren Kunden ein t\u00e4gliches AWR-Beispiel gefunden, in dem die Exadata-Wartezeiten in den Abschnitt der Top 10 aufgenommen wurden und insgesamt etwa 5% ausmachten:<\/p>\n
Ereignis<\/strong><\/p>\n Wartezeiten<\/strong><\/p>\n Gesamte Wartezeit (Sek.)<\/strong><\/p>\n Durchschnittliche Wartezeit<\/strong><\/p>\n % DB-Zeit<\/strong><\/p>\n Warteklasse<\/strong><\/p>\n DB CPU<\/p>\n <\/p>\n 115.2K<\/p>\n <\/p>\n 70.4<\/p>\n <\/p>\n SQL*Net mehr Daten von DB-Link<\/p>\n 670,196<\/p>\n 5471.5<\/p>\n 8.16ms<\/p>\n 3.3<\/p>\n Netzwerk<\/p>\n cell single block physical read<\/p>\n 5,661,452<\/p>\n 3827.6<\/p>\n 676.07us<\/p>\n 2.3<\/p>\n Benutzer I\/O<\/p>\n Synchron ASM-Neuverteilung<\/p>\n 4,350,012<\/p>\n 3481.3<\/p>\n 800.30us<\/p>\n 2.1<\/p>\n Sonstige<\/p>\n cell multiblock physical read<\/p>\n 759,885<\/p>\n 2252<\/p>\n 2.96ms<\/p>\n 1.4<\/p>\n Benutzer I\/O<\/p>\n direkt Pfadlesen<\/p>\n 374,368<\/p>\n 1811.3<\/p>\n 4.84ms<\/p>\n 1.1<\/p>\n Benutzer I\/O<\/p>\n SQL*Net Nachricht von DB-Link<\/p>\n 7,983<\/p>\n 1725<\/p>\n 216.08ms<\/p>\n 1.1<\/p>\n Netzwerk<\/p>\n cell smart table scan<\/p>\n 1,007,520<\/p>\n 1260.7<\/p>\n 1.25ms<\/p>\n 0.8<\/p>\n Benutzer I\/O<\/p>\n direkt Pfadlesen tempor\u00e4r<\/p>\n 520,211<\/p>\n 808.4<\/p>\n 1.55ms<\/p>\n 0.5<\/p>\n Benutzer I\/O<\/p>\n enq: TM \u2014 contention<\/p>\n 652<\/p>\n 795.8<\/p>\n 1220.55ms<\/p>\n 0.5<\/p>\n Anwendung<\/p>\n Aus solchen AWR-Statistiken werden oft folgende Schlussfolgerungen gezogen:<\/p>\n 1. Der Beitrag der Exadata-Magie zur Datenbankleistung ist gering \u2013 er \u00fcberschreitet nicht 5 %, und die Datenbank leidet bei der Nutzung von Exadata.<\/p>\n 2. Wenn eine solche Datenbank von Exadata auf eine klassische Architektur \u201eServer + Array\u201c migriert wird, \u00e4ndert sich die Leistung nicht stark. Denn selbst wenn dieses Array dreimal langsamer als das Exadata-Speichersystem ist (was f\u00fcr moderne All-Flash-Arrays kaum m\u00f6glich ist), erhalten wir durch die Multiplikation von 5 % mit drei eine Steigerung des IO-Warteanteils auf 15 % \u2013 eine solche Datenbank wird das sicher \u00fcberstehen!<\/p>\n Beide diese Schlussfolgerungen sind ungenau; mehr noch, sie verzerren das Verst\u00e4ndnis der Idee, die in Exadata Software steckt. Exadata bietet nicht nur schnellen Input\/Output, sie funktioniert grundlegend anders als die klassische Architektur \u201eServer + Array\u201c. Wenn die Datenbank tats\u00e4chlich \u201eexadatet\u201c, wird die SQL-Logik auf das Speichersystem \u00fcbertragen. Storage Server<\/a> findet dank einer Reihe spezieller Mechanismen (insbesondere den Exadata Storage Indexes, aber nicht nur) selbstst\u00e4ndig die ben\u00f6tigten Daten und \u00fcbertr\u00e4gt sie an die DB-Server. Sie tun dies ziemlich effizient, weshalb der Anteil typischer Exadata-Wartezeiten an der Gesamtreaktionszeit gering ist. <\/p>\n Wie wird sich dieser Anteil au\u00dferhalb von Exadata ver\u00e4ndern? Wie wird sich das auf die Gesamtleistung der Datenbank auswirken? Am besten k\u00f6nnen diese Fragen durch Tests beantwortet werden. Beispielsweise kann das Warten auf \u201eCell Smart Table Scan\u201c au\u00dferhalb 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\u00dferhalb von Exadata zu verwenden. Um zu verstehen, wie stark die Arbeit der Datenbank \u201eexadatet\u201c, muss man die Statistiken der AWR-Sektion \u201eInstance Activity Stats\u201c (dort gibt es viele Statistiken mit sprechenden Namen) studieren und sie miteinander vergleichen.<\/p>\n Um herauszufinden, wie sich die Datenbank au\u00dferhalb 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\u00f6glichkeit haben normalerweise die Besitzer von Exadata.<\/p>\n