![\"AWR:](\"\/wp-content\/uploads\/2020\/09\/b0ca997a4bd415723ae56c183e2dd42f.jpeg\")
<\/p>\nMit diesem kurzen Beitrag m\u00f6chte ich ein Missverst\u00e4ndnis \u00fcber die Analyse von AWR-Datenbanken, die auf Oracle Exadata laufen, ausr\u00e4umen. Fast 10 Jahre lang bin ich st\u00e4ndig mit der Frage konfrontiert worden: Welchen Beitrag leistet die Exadata-Software zur Leistung? Oder, um neu gepr\u00e4gte W\u00f6rter zu verwenden: Wie sehr wird die Leistung einer bestimmten Datenbank durch Exadata beeinflusst?<\/p>\n
<\/p>\n
Auf diese richtige Frage, meiner Meinung nach, wird oft eine falsche Antwort gegeben, die sich auf AWR-Statistiken st\u00fctzt. Diese pr\u00e4sentiert eine Methode der systematischen Wartezeiten, die die Antwortzeiten als Summe der Prozessorauslastung (DB CPU) und der Wartezeiten verschiedener Klassen interpretiert.<\/p>\n
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 \u201ecell\u201c (eine Zelle bezeichnet den Exadata Storage-Server). H\u00e4ufig sind Wartezeiten mit den aussagekr\u00e4ftigen Bezeichnungen \u201ecell smart table scan\u201c, \u201ecell multiblock physical read\u201c und \u201ecell single block physical read\u201c zu finden.<\/p>\n
In den meisten F\u00e4llen 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\u00fcssen sie im Abschnitt Foreground Wait Events gesucht werden). Nur mit gro\u00dfem Aufwand fanden wir bei unseren Kunden ein Beispiel eines t\u00e4glichen AWR-Berichts, in dem die Exadata-Wartezeiten in die Top 10 aufstiegen und insgesamt etwa 5 % ausmachten:<\/p>\n
Ereignis<\/strong><\/p>\n Wartezeiten<\/strong><\/p>\n Gesamtwartezeit (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 weitere Daten von dblink<\/p>\n 670,196<\/p>\n 5471.5<\/p>\n 8,16 ms<\/p>\n 3.3<\/p>\n Netzwerk<\/p>\n Cell einfacher Block physikalisch lesen<\/p>\n 5,661,452<\/p>\n 3827.6<\/p>\n 676,07 \u00b5s<\/p>\n 2.3<\/p>\n Benutzer I\/O<\/p>\n Sync ASM-Ausgleich<\/p>\n 4,350,012<\/p>\n 3481.3<\/p>\n 800,30 \u00b5s<\/p>\n 2.1<\/p>\n Andere<\/p>\n Cell Multiblock physikalisch lesen<\/p>\n 759,885<\/p>\n 2252<\/p>\n 2,96 ms<\/p>\n 1.4<\/p>\n Benutzer I\/O<\/p>\n direkt Pfad lesen<\/p>\n 374,368<\/p>\n 1811.3<\/p>\n 4,84 ms<\/p>\n 1.1<\/p>\n Benutzer I\/O<\/p>\n SQL*Net Nachricht von dblink<\/p>\n 7,983<\/p>\n 1725<\/p>\n 216,08 ms<\/p>\n 1.1<\/p>\n Netzwerk<\/p>\n Cell intelligenter Tabellen-Scan<\/p>\n 1,007,520<\/p>\n 1260.7<\/p>\n 1,25 ms<\/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,55 ms<\/p>\n 0.5<\/p>\n Benutzer I\/O<\/p>\n enq: TM — contention<\/p>\n 652<\/p>\n 795.8<\/p>\n 1220,55 ms<\/p>\n 0.5<\/p>\n Application<\/p>\n Aus solchen AWR-Statistiken werden oft folgende Schlussfolgerungen gezogen:<\/p>\n 1. \u0412\u043a\u043b\u0430\u0434 \u043c\u0430\u0433\u0438\u0438 Exadata \u0432 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 \u043d\u0435 \u0432\u044b\u0441\u043e\u043a \u2014 \u043d\u0435 \u043f\u0440\u0435\u0432\u044b\u0448\u0430\u0435\u0442 5 %, \u0430 \u0431\u0430\u0437\u0430 \u0434\u0430\u043d\u043d\u044b\u0445 \u00ab\u044d\u043a\u0437\u0430\u0434\u0430\u0442\u0438\u0442\u0441\u044f\u00bb \u043f\u043b\u043e\u0445\u043e.<\/p>\n 2. \u0415\u0441\u043b\u0438 \u0442\u0430\u043a\u0443\u044e \u0431\u0430\u0437\u0443 \u043f\u0435\u0440\u0435\u043d\u0435\u0441\u0442\u0438 \u0441 Exadata \u043d\u0430 \u043a\u043b\u0430\u0441\u0441\u0438\u0447\u0435\u0441\u043a\u0443\u044e \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0443 \u00ab\u0441\u0435\u0440\u0432\u0435\u0440 + \u043c\u0430\u0441\u0441\u0438\u0432\u00bb, \u0442\u043e \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0438\u0437\u043c\u0435\u043d\u0438\u0442\u0441\u044f \u043d\u0435 \u0441\u0438\u043b\u044c\u043d\u043e. \u041f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u0434\u0430\u0436\u0435 \u0435\u0441\u043b\u0438 \u044d\u0442\u043e\u0442 \u043c\u0430\u0441\u0441\u0438\u0432 \u043e\u043a\u0430\u0436\u0435\u0442\u0441\u044f \u0432\u0442\u0440\u043e\u0435 \u043c\u0435\u0434\u043b\u0435\u043d\u043d\u0435\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f Exadata (\u0447\u0442\u043e \u0435\u0434\u0432\u0430 \u043b\u0438 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e \u0434\u043b\u044f \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445 All Flash \u043c\u0430\u0441\u0441\u0438\u0432\u043e\u0432), \u0442\u043e \u0443\u043c\u043d\u043e\u0436\u0438\u0432 5% \u043d\u0430 \u0442\u0440\u0438 \u043c\u044b \u043f\u043e\u043b\u0443\u0447\u0438\u043c \u0443\u0432\u0435\u043b\u0438\u0447\u0435\u043d\u0438\u0435 \u0434\u043e\u043b\u0438 \u043e\u0436\u0438\u0434\u0430\u043d\u0438\u0439 \u0432\u0432\u043e\u0434\u0430-\u0432\u044b\u0432\u043e\u0434\u0430 \u0434\u043e 15% \u00ad\u2014 \u0442\u0430\u043a\u043e\u0435 \u0431\u0430\u0437\u0430 \u0434\u0430\u043d\u043d\u044b\u0445 \u043d\u0430\u0432\u0435\u0440\u043d\u044f\u043a\u0430 \u043f\u0435\u0440\u0435\u0436\u0438\u0432\u0435\u0442!<\/p>\n Beide Schlussfolgerungen sind ungenau, mehr noch, sie verzerren das Verst\u00e4ndnis der Idee, die in Exadata Software steckt. Exadata sorgt nicht nur f\u00fcr schnellen Input\/Output, sondern funktioniert grunds\u00e4tzlich anders als die klassische Architektur \u201eServer + Array\u201c. Wenn die Datenbank tats\u00e4chlich \u201eexadatiert\u201c ist, wird die SQL-Logik auf das Speichersystem \u00fcbertragen. Server<\/a> Dank einer Reihe spezieller Mechanismen (vor allem Exadata Storage Indexes, aber nicht nur) finden die Systeme selbst die ben\u00f6tigten 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. <\/p>\n Wie wird sich dieser Anteil au\u00dferhalb von Exadata ver\u00e4ndern? 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 \u00bbCell Smart Table Scan\u00ab au\u00dferhalb 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\u00dferhalb von Exadata zu verwenden. Um zu verstehen, wie sehr die Arbeit der Datenbank \u201eexadatisiert\u201c wird, m\u00fcssen die Statistiken im AWR-Bereich \u201eInstance Activity Stats\u201c untersucht werden (dort finden sich viele Statistiken mit aussagekr\u00e4ftigen Bezeichnungen) und miteinander verglichen werden.<\/p>\n Um zu verstehen, wie sich die Datenbank au\u00dferhalb 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\u00f6glichkeit haben in der Regel die Besitzer von Exadata.<\/p>\n