Über unsMediaKontaktImpressum
Randolf Geist 11. Februar 2015

Exadata & In Memory: Real World Performance (Teil 1)

Die Exadata Plattform liefert extreme Performance. © depositphotos.com / PirenX
Die Exadata Plattform liefert extreme Performance. © depositphotos.com / PirenX

Sowohl die Exadata-Plattform mittels der sogenannten „Smart Scan“- Technologie als auch die mit Datenbank Version 12.1.0.2 eingeführte „In Memory Column Store“- Technologie können Full Table Scans extrem beschleunigen.

Mit diesen neuen Technologien geht einher, dass Oracle diese auch mit dem Argument anpreist, weniger Zeit mit SQL Tuning und Design verbringen zu müssen, da diese neuen Features so schnelle Ausführungszeiten ermöglichen.

Wie ein realer Fall bei einem meiner Kunden aber zeigte, ist es auch mit diesen neuen Technologien möglich, in Situationen zu geraten, bei denen trotz anscheinend optimaler Voraussetzungen – im konkreten Fall für die Exadata „Smart Scans“ – die Ausführungszeiten nicht den möglichen Erwartungen entspricht und schließlich nur mittels entsprechender Änderungen, entweder bei der Modellierung oder beim physischen Design die Erwartungen erfüllt werden können.

Ein kurzer Überblick der Exadata-Technologie

Die Exadata Plattform liefert extreme Performance, wenn die Exadata-spezifischen Features entsprechend eingesetzt werden können. Insbesondere die sogenannten Exadata „Smart Scans“ können Full Segment Scans extrem beschleunigen und optimieren.

Der Clou der Plattform liegt darin, dass Teile der Datenverarbeitung in die sogenannten „Storage Cells“ im „Storage Layer“ verlagert werden können (grüne Elemente in der Grafik). Wir haben es hier also mit „intelligentem“ Storage zu tun, der versteht, was in den abgelegten Daten abgespeichert ist und bestimmte Operationen bereits im „Storage Layer“ durchführen kann.

Auf den „Storage Cells“ läuft eine spezielle „Cell Software“, die diese Intelligenz des „Storage Layers“ implementiert und die Daten bereits vorverarbeiten kann. Auf den sogenannten „Compute Nodes“ (blaue Elemente in der Grafik) läuft die normale Oracle Database Software, wie man sie von herkömmlichen Systemen kennt und kommuniziert mit dem „Storage Layer“ mittels eines speziellen Protokolls sowie einer speziellen ASM (Automatic Storage Management)-Implementierung.

Abb. 1: Exadata X3-8 Architektur. © Randolf Geist
Abb. 1: Exadata X3-8 Architektur. © Randolf Geist

Dies hat mehrere Vorteile: Zum einen können diese Operationen bereits auf Storage Layer-Ebene parallelisiert und optimiert werden, zum anderen kann durch die Aufteilung der Operationen zwischen Storage Layer und Compute Node Layer die Menge der Daten, die zwischen den beiden Layern ausgetauscht werden muss, reduziert werden – der Storage Layer kann die Daten also schon vorfiltern und eine reduzierte Datenmenge an die Compute Nodes liefern, die dann weitere Schritte einer SQL-Verarbeitung durchführen, wie Joins oder Aggregate.

Ein spezielles Feature bei den sogenannten „Smart Scans“ sind die „Storage Indizes“, die auf Storage-Layer-Ebene automatisch erzeugt und gepflegt werden, und die es ermöglichen, bei entsprechenden Daten und Filtern I/O zu vermeiden, da die „Storage Indizes“ anzeigen, dass in einem Teilbereich des zu durchsuchenden Segments die gesuchten Daten nicht vorkommen können, da zum Beispiel der anzuwendende Filter außerhalb der Minimal-/Maximalwerte der Spalte in diesem Teilbereich liegt.

Die Verbindung zwischen den Compute Nodes und den Storage Cells verwendet Infiniband (rote Elemente in der Grafik) und ein dafür optimiertes Protokoll. Auch die Compute Nodes sind über Infiniband verbunden. Allerdings findet keine Kommunikation zwischen den Storage Cells statt – auf Storage Cell Ebene ist Exadata also eine „Shared Nothing“-Konfiguration, was einige interessante Implikationen hat.

Wie man den offiziellen Datenblättern entnehmen kann, können Smart Scans in einem Exadata Full Rack (oder den Xn-8 (X3-8 / X4-8) Modellen) bei den aktuellen Modellen in Verbindung mit Flash Cache eine Scan-Geschwindigkeit von bis zu 100GB pro Sekunde – wohlgemerkt unkomprimiert – erreichen. Oracle spricht hier offiziell von „SQL Processing Speed“ oder auch „Maximum SQL bandwidth“.

Abb. 2: Offizielle Exadata X3-8 Performance Metrics. © Randolf Geist
Abb. 2: Offizielle Exadata X3-8 Performance Metrics. © Randolf Geist

Der reale Fall

Ausgangspunkt der gesamten Analyse war eine bestimmte, extrem zeitkritische Abfrage eines Kunden, die es zu optimieren galt. Es handelte sich dabei um eine SQL-Abfrage, die 20 Tabellen mittels Outer Join verknüpfen musste.

Wie viel Sinn es macht, als Teil eines extrem zeitkritischen Vorgangs eine solche Abfrage im Design vorzusehen, ist eine ganz andere Frage. Hier zeigt sich die oben in der Einleitung erwähnte und von Oracle durchaus auch als Verkaufsargument vorgebrachte Idee, dass solche Plattformen es erlauben, Zeit bei der Modellierung und dem Design einsparen zu können, da sie ja so schnell sind.

Die zu verarbeitende Gesamtdatenmenge der 20 Tabellen war ca. 210GB, wobei durch die Struktur der Abfrage und Daten nur Full Table Scans der Tabellen in Frage kam. Dabei kam den Exadata spezifischen Features entgegen, dass nur ca. 1/12 der Daten (ca. 18GB) tatsächlich für die Weiterverarbeitung der Abfrage in den Compute Nodes benötigt wurde (ungefähr 1/4 durch Selektion (WHERE-Klauseln in SQL) und davon 1/3 durch Projektion (verwendete Spalten) ausgewählt), und außerdem eine gewisse physische Ordnung der Daten vorlag, was wiederum den Einsatz von „Storage Indizes“ zur Vermeidung von physischem I/O ermöglichen kann.

Allerdings erlaubt das hier beschriebene Szenario nicht den Einsatz von sogenannten „Bloom Filtern“, eine weitere Technologie, die es ermöglicht, Joins, die Daten filtern, beim Einsatz von Smart Scans zu optimieren, da der Bloom Filter das Filtern des Joins bereits in den Storage Cells verarbeitet und somit die an die Compute Nodes zu sendende und in den Joins zu verarbeitende Datenmenge minimiert werden kann. Da Outer Joins per Definition nicht filtern, kann dieses Feature hier also nicht zum Einsatz kommen.

Angesichts der zu verarbeitenden Datenmenge von 210GB, der eben beschriebenen Exadata-freundlichen Eigenschaften der Abfrage und der oben genannten Smart Scan-Geschwindigkeit von bis zu 100GB pro Sekunde ergaben sich Erwartungen an die Laufzeit der kritischen Abfrage im Bereich von wenigen Sekunden, schließlich musste ja nur weniger als ein Zehntel der Daten in den Compute Nodes verarbeitet werden und der Großteil der Daten konnte bereits in den „Storage Cells“ ausgefiltert werden, auf dem Papier also ein ziemlich optimaler Einsatz der Exadata-Technologie.

Tatsächlich ergaben sich dann aber Laufzeiten von 40 Sekunden oder mehr, und es galt die Frage zu beantworten, warum denn die tatsächliche Laufzeit so weit von den Erwartungen abwich.

Laufzeit-Betrachtungen verschiedener Variationen der SQL-Abfrage

Abb. 3: Laufzeiten unterschiedlicher Variationen der kritischen SQL-Abfrage. © Randolf Geist
Abb. 3: Laufzeiten unterschiedlicher Variationen der kritischen SQL-Abfrage. © Randolf Geist

Die Grafik zeigt die gemessenen Laufzeiten in Sekunden unterschiedlicher Variationen der kritischen SQL-Abfrage auf der Exadata-Plattform des Kunden (Exadata X2-8). Die ursprüngliche Abfrage kann auch in dieser Übersicht gefunden werden mit einer Laufzeit von 40 Sekunden.

Das Interessante und möglicherweise Überraschende an dieser Übersicht ist, dass alle Abfragen genau auf der gleichen zu durchsuchenden Datenmenge beruhen, nämlich die oben genannten 20 Tabellen mit insgesamt 210GB Datenvolumen.

Das bedeutet: Die 20 Tabellen (insgesamt 210GB) können auf der Plattform des Kunden in weniger als drei Sekunden (2,5 Sekunden) verarbeitet werden – sie können aber auch mehr als zwei Minuten brauchen (123 Sekunden), um ein Ergebnis zurückzuliefern.

Es handelt sich hierbei keinesfalls um künstlich erzeugte Extremfälle, sondern allesamt um sehr simple und an reale Gegebenheiten angelehnte Abfragen. Eine so große Bandbreite von möglichen Laufzeiten für die gleiche Grunddatenmenge macht hoffentlich neugierig, genauer hinzuschauen, wie denn diese Laufzeiten im Detail zustande kommen, wie man sich diese erklären kann und welche Schlüsse daraus gezogen werden können.

Testumgebungen

Zur besseren Einordnung der Ergebnisse hier eine kurze Beschreibung der im Test zum Einsatz gekommenen Umgebungen:

Exadata X2-8 Single Compute Node
64 Cores, 128 CPUs, 1TB RAM, 8 Infiniband-Adapter a 40Gbit/sec (theoretische Bandbreite 40GB pro Sekunde zwischen Compute Node und Storage Cells)
14 Storage Cells, 12 CPU Cores pro Storage Cell, insgesamt 168 CPU Cores, 5,3TB Flash Cache, High Capacity Disks.

Laut offiziellem Datenblatt maximal 50GB pro Sekunde „uncompressed Flash data bandwidth“ bei Einsatz von Flash Cache.

Abb. 4: Offizielle Exadata X2-8 Performance Metrics. © Randolf Geist
Abb. 4: Offizielle Exadata X2-8 Performance Metrics. © Randolf Geist

Exadata X3-8 Two Node RAC
80 Cores, 160 CPUs, 2 TB RAM, 8 Infiniband-Adapter a 40Gbit/sec pro Node (theoretische Bandbreite 40GB pro Sekunde zwischen Compute Node und Storage Cells) pro Compute Node
14 Storage Cells, 12 CPU Cores pro Storage Cell, insgesamt 168 CPU Cores, 44TB Flash Cache, High Capacity Disks

Laut offiziellem Datenblatt maximal 100GB pro Sekunde „Maximum SQL flash bandwidth“ bei Einsatz von Flash Cache.

Abb. 5: Offizielle Exadata X3-8 Performance Metrics. © Randolf Geist
Abb. 5: Offizielle Exadata X3-8 Performance Metrics. © Randolf Geist

Analyse Exadata Features

Über entsprechende Statistiken kann ausgewertet werden, welche Exadata-spezifischen Features zu welchem Grad eingesetzt werden. Dies ist wichtig für ein genaueres Verständnis, wie eine bestimmte Performance im Exadata-Umfeld zustande kommt.

Unter anderem folgende Features können darüber analysiert werden:

  • Smart Scans: Einsatz von Smart Scans und zu welchem Grad Smart Scans verwendet wurden, da je nach Szenario (zum Beispiel Read Consistency, Chained Rows oder hohe CPU-Auslastung der „Storage Cells“) auch bei Smart Scans die Menge der bereits in den Zellen verarbeiteten Daten stark variieren kann
  • Offloading Percentage: Wie viele Daten wurden in den „Storage Cells“ verarbeitet im Verhältnis zu der Menge an Daten, die zwischen den Zellen und den „Compute Nodes“ ausgetauscht wurden. Hier sind auch durchaus negative Prozente möglich, da bei Einsatz von Kompression oder Spiegelung von Schreibvorgängen (ASM Mirroring) mehr Daten zwischen „Storage Cells“ und „Compute Nodes“ ausgetauscht werden können als aus „Compute Node“-Sicht verarbeitet werden
  • Flash Cache: Einsatz von Flash Cache und Menge an I/O Requests / Daten verarbeitet mittels Flash Cache
  • Storage Indexes: Vermeidung von I/O mittels Storage Indexes

Zur Auswertung der entsprechend relevanten Statistiken bietet sich Tanel Poder’s „ExaSnapper“ Tool an, dass ein Delta der entsprechenden Statistiken automatisch erzeugen und graphisch darstellen kann.

Einfache SELECT COUNT(*)-Abfrage

Fangen wir also mit den ersten Ergebnissen der obigen Übersicht an. Um zu sehen, ob die Exadata Smart Scans tatsächlich die auf den Datenblättern beschriebene Performance im konkreten Fall des Kunden liefern können, wurden die den Original-Filter-Kriterien entsprechenden Zeilen in den 20 Tabellen mittels einer einfachen UNION ALL-Abfrage gezählt.  Dabei galt es ca. 400 Millionen Zeilen aus ca. 1,6 Milliarden Zeilen zu finden und mittels COUNT(*) zu zählen (eben die oben beschriebenen ca. 25% Prozent der Gesamtdaten).

Folgendes Bild ergab sich für die SELECT COUNT(*)-Abfrage bei einem Parallel DOP von 64 auf der X2-8 und einem DOP von 128 auf der X3-8 und Verwendung von Flash Cache für die Full Table Scans (auf X3-8 mit aktueller Firmware automatisch gecacht, auf X2-8 mittels CELL_FLASH_CACHE KEEP Storage-Klausel explizit eingeschaltet):

X2-8: 2,54 Sekunden, im Durchschnitt ca. 85GB pro Sekunde gelesen, Peak 90GB pro Sekunde
X3-8: 2 Sekunden, im Durchschnitt ca. 105GB pro Sekunde gelesen, Peak 105GB pro Sekunde

Erstaunlicherweise werden bei der einfachsten Form der Abfrage also sogar (deutlich) höhere Durchsätze erzielt als gemäß Datenblatt spezifiziert (zum Beispiel tatsächlich 85GB vs. 50GB pro Sekunde gemäß Datenblatt bei X2-8). Wie ist das möglich? Handelt es sich um Messfehler oder veraltete Angaben in den Datenblättern? Hier ist der Blick in die oben genannten Statistiken sehr hilfreich für das Verständnis:

Abb. 6: Blick in die Statistiken. © Randolf Geist
Abb. 6: Blick in die Statistiken. © Randolf Geist

Die Statistiken bedeuten im Einzelnen folgendes:

  • DB_PHYSICAL_IO: Aus Datenbank-Sicht die Gesamtmenge an I/O (lesend und schreibend), hier also ca. 212GB (217361MB)
  • PHYSICAL_READ_FLASH_CACHE: Datenmenge die über den Flash Cache in den „Storage Cells“ gelesen werden konnte, in diesem Fall ca. 54GB (55756MB)
  • STORAGE_INDEX_SAVED: I/O-Datenmenge, die aufgrund von Storage Indizes in den „Storage Cells“ vermieden werden konnte, da die gesuchten Daten in diesen Teilbereichen nicht vorkommen können, in diesem Fall ca. 158GB (161606MB)
  • SPINNING_DISK_READ: I/O-Datenmenge, die von den Festplatten in den „Storage Cells“ gelesen wurden, in diesem Fall 0MB
  • TOTAL_INTERCONNECT: Die I/O-Datenmenge, die zwischen „Storage Cells“ und „Compute Nodes“ für diese Abfrage ausgetauscht wurden. In diesem Fall nur etwa 4,5GB (4574MB), da der „Smart Scan“ nur die ROWIDs an die „Compute Nodes“ für das Zählen der 400 Millionen Zeilen liefern musste.
  • SMART_SCAN_RETURNED: Die I/O-Datenmenge, die der „Smart Scan“ an die „Compute Nodes“ geliefert hat – die gleichen 4,5GB in diesem Fall. Wie wir später sehen werden, stimmen diese beiden Größen nicht immer überein.

Der Grund für die über dem jeweils angegebenen Maximum liegende Lesegeschwindigkeit ist also offensichtlich die Tatsache, dass nur ca. ein Viertel der Daten tatsächlich gelesen wurde und drei Viertel der Daten per Storage Indexes überhaupt nicht verarbeitet werden mussten.

Abb. 7: Relative Aktivitätsverteilung bei dieser Abfrage. © Randolf Geist
Abb. 7: Relative Aktivitätsverteilung bei dieser Abfrage. © Randolf Geist

Desweiteren wird offensichtlich, dass durch den „Smart Scan“ nur ein Bruchteil der tatsächlich in den „Storage Cells“ verarbeiteten Daten an die „Compute Nodes“ zurückgeliefert wurde, hier also ca. 4,5GB der 54 bzw. 212GB, also auch deutlich weniger als die oben genannten 18GB für die eigentliche Abfrage.

Aus „Compute Node“-Sicht ergibt sich die in Abb. 7 zu sehende relative Aktivitätsverteilung bei dieser Abfrage.

Abb. 8: Absolute Datenbankzeit. © Randolf Geist
Abb. 8: Absolute Datenbankzeit. © Randolf Geist

Und folgendes Bild (s. Abb. 8) für die absolute Datenbankzeit, also die Aufteilung der Zeit, die die dazugehörigen Prozesse in den „Compute Nodes“ verbracht haben. Da es sich um „Parallel Execution“ handelt, können hier auch innerhalb weniger Sekunden mehrere Minuten an Datenbankzeit verbracht werden, da viele Prozesse gleichzeitig an der Abfrage arbeiten.

Die beteiligten Prozesse in den „Compute Nodes“ verbringen also mehr als die Hälfte Ihrer Zeit mit Warten auf Ergebnisse aus den „Storage Cells“ (ca. 87 Sekunden der insgesamt 154 Sekunden Datenbankzeit).

Wird der Einsatz von Storage Indizes verhindert, ergibt sich folgende Performance für die gleiche Art der Abfrage:

X2-8: 5,1 Sekunden, im Durchschnitt ca. 43GB pro Sekunde gelesen, Peak 45GB pro Sekunde
X3-8: 3,1 Sekunden, im Durchschnitt ca. 70GB pro Sekunde gelesen, Peak 75GB pro Sekunde

Hier werden also die laut Datenblatt erreichbaren Scan-Geschwindigkeiten nicht mehr ganz erreicht.

Die Unwirksamkeit der Storage Indizes in diesem Fall kann bestätigt werden, wenn wir wiederum auf die Session Statistiken schauen:

Abb. 9: Session Statistiken. © Randolf Geist
Abb. 9: Session Statistiken. © Randolf Geist
Abb. 10: Verändertes Aktivitätsprofil. © Randolf Geist
Abb. 10: Verändertes Aktivitätsprofil. © Randolf Geist

Im Gegensatz zum vorherigen Beispiel müssen jetzt also tatsächlich alle 212GB in den Zellen verarbeitet werden, der größte Teil wird aus dem Flash Cache gelesen, ein kleiner Teil (ca. 3,5GB) sogar von den Festplatten, da der Flash Cache wohl teilweise an seine Kapazitätsgrenze gebracht wird. Auch das Aktivitätsprofil verändert sich entsprechend (s. Abb. 10).

Abb. 11: Verschiebung / Erhöhung der Datenbankzeit. © Randolf Geist
Abb. 11: Verschiebung / Erhöhung der Datenbankzeit. © Randolf Geist

Und eine entsprechende Verschiebung / Erhöhung der Datenbankzeit kann ebenso gesehen werden (s. Abb. 11).

Es wird jetzt also deutlich mehr auf I/O gewartet (83% der Gesamtzeit) als bei der Verwendung von Storage Indizes. Die Gesamtdatenbankzeit aller in den „Compute Nodes“ beteiligten Prozesse erhöht sich entsprechend auf über 5 Minuten.

Einfache SELECT MAX()-Abfrage

Als nächste Komplexitätsstufe wird die COUNT(*)-Abfrage in eine SELECT MAX()-Abfrage verändert. Dabei werden alle Spalten mit MAX(COLUMN) verwendet, die auch bei der Original-Abfrage in der Projektion zur Verwendung kommen. Dabei ergaben sich folgende Laufzeiten bei Verwendung von Storage Indizes, also zu vergleichen mit dem ersten SELECT COUNT(*)-Beispiel:

X2-8: 7,0 Sekunden, im Durchschnitt ca. 31GB pro Sekunde gelesen, Peak 31GB pro Sekunde
X3-8: 3,7 Sekunden, im Durchschnitt ca. 58GB pro Sekunde gelesen, Peak 60GB pro Sekunde

Im Vergleich zu der einfachen SELECT COUNT(*)-Abfrage unter Verwendung von Storage Indizes ist hier eine deutliche Verlängerung der Laufzeit zu beobachten, als auch eine verringerte Lesegeschwindigkeit auf I/O-Seite.
Die Analyse der Session Statistiken zeigt folgendes Bild:

Abb. 12: Analyse der Session Statistiken. © Randolf Geist
Abb. 12: Analyse der Session Statistiken. © Randolf Geist

Wir können also sehen, dass die Storage Indizes tatsächlich wieder erfolgreich verwendet wurden. Im Unterschied zur SELECT COUNT(*)-Abfrage wurden aber anstatt 4,5GB jetzt über 18GB vom Smart Scan an die Compute Nodes geliefert (SMART_SCAN_RETURNED = TOTAL_INTERCONNECT = 18692MB), da für die Auswertung der MAX()-Funktionen die tatsächlichen Spaltenwerte benötigt werden, im Gegensatz zur Auswertung einer COUNT(*)-Funktion, die nur auf die ROWID für das Zählen zurückgreifen muss. Die erhöhte Komplexität der Aktivität in den Compute Nodes kann auch im Aktivitätsprofil gesehen werden (s. Abb. 13).

Es wird jetzt also prozentual deutlich mehr Zeit auf CPU verbracht als beim SELECT COUNT(*). Die entsprechende Verlängerung und Verschiebung der Datenbankzeit sieht man auf Abb. 14.

Interessanterweise erhöht sich nicht nur die CPU-Zeit (von ca. 67 Sekunden auf fast 5 Minuten), sondern auch die I/O-Wartezeit, allerdings nicht so signifikant (von 87 Sekunden auf 144 Sekunden).

Abb. 13: Aktivitätsprofil. © Randolf Geist
Abb. 13: Aktivitätsprofil. © Randolf Geist
Abb. 14: Verlängerung und Verschiebung der Datenbankzeit. © Randolf Geist
Abb. 14: Verlängerung und Verschiebung der Datenbankzeit. © Randolf Geist

Die eigentliche Abfrage

Als letzte Stufe der Komplexitätserhöhung wird jetzt anstelle eines UNION ALL ein (Outer) Join der 20 Tabellen durchgeführt, und auf das Ergebnis des Joins eine SELECT MAX()-Abfrage der Projektion durchgeführt. Im Gegensatz zu der UNION ALL-Abfrage liefert der Join nicht mehr 400 Millionen Zeilen als Ergebnis, sondern nur noch 20 Millionen. Allerdings muss immer noch die gleiche Datenmenge (20-mal 20 Millionen, ca. 18GB netto) verarbeitet werden. Es sind jetzt in der Projektion 20-mal so viele Spalten wie bei der UNION ALL-Abfrage.

Dabei ergeben sich folgende Laufzeiten:
X2-8: 39,3 Sekunden, im Durchschnitt ca. 5,5GB (7GB) pro Sekunde gelesen, Peak 28GB pro Sekunde
X3-8: 23,7 Sekunden, im Durchschnitt ca. 9GB (12GB) pro Sekunde gelesen, Peak 27GB pro Sekunde

Das ist erst mal ein extremer Unterschied zu den vorherigen Zahlen – insbesondere sind auch die Lesegeschwindigkeiten weit von dem entfernt, was die Plattform grundsätzlich in der Lage ist zu liefern. Tatsächlich befinden sich die Lesegeschwindigkeiten in Bereichen, die von den Festplatten geliefert werden können, wir also möglicherweise hier nicht mehr wirklich vom Einsatz des Flash Caches profitieren.

Die Zahlen in Klammern bezüglich der Lesegeschwindigkeit beziehen sich auf die Gesamtmenge an I/O, während die Zahlen vor den Klammern sich auf die Grundmenge von ca. 210GB beziehen. Der Zusammenhang wird klarer, wenn wir auf die entsprechenden Session-Statistiken schauen:

Abb. 15: Session-Statistiken. © Randolf Geist
Abb. 15: Session-Statistiken. © Randolf Geist

Hier wird also deutlich, dass deutlich mehr I/O erzeugt wurde als in den vorherigen Beispielen.

Insgesamt wurde aus Datenbanksicht jetzt über 270GB an I/O erzeugt (DB_PHYSICAL_IO = 277512MB), und offensichtlich mussten im Vergleich zu vorher zusätzlich 30GB geschrieben (DB_PHYSICAL_WRITE = 30075MB) und gelesen (DB_PHYSICAL_READ = 247437MB) werden, was durch die ASM-Spiegelung zu 60GB verdoppelt wird (SPINNING_DISK_WRITE = 60150MB, ASM Normal Redundancy).

Das bedeutet auch, dass in diesem Fall insgesamt ca. 90GB zusätzlich von den Festplatten bewältigt werden müssen (SPINNING_DISK_IO = 90226MB) und auch jetzt ca. 90GB mehr zwischen den Compute Nodes und den Storage Cells ausgetauscht werden müssen (TOTAL_INTERCONNECT = 108875MB) – ein Anstieg von 18GB auf 106GB.

Ganz wichtig zu beachten ist, dass wir trotzdem im Grunde das gleiche Profil wie vorher haben – wir sparen weiterhin 158GB an I/O über Storage Indizes (STORAGE_INDEX_SAVED = 162033MB) und lesen 54GB mittels Flash Cache per Smart Scan (PHYSICAL_READ_FLASH_CACHE = 55329MB), der 18GB an die Compute Nodes zurückliefert (SMART_SCAN_RETURNED = 18692MB). Diese Optimierung wird aber durch die zusätzliche Schreib- und Leseaktivität deutlich beeinflusst/ verschlechtert.

Diese Statistiken lassen erst mal vermuten, dass das zusätzliche I/O durch TEMP-Aktivität erzeugt wird. Die entsprechenden Aktivitätsprofile bestätigen dies, sie sind in Abb. 16 zu sehen.

Die massive Erhöhung der in den „Compute Nodes“ getätigten Arbeit zeigt sich auch in den Auswertungen der Datenbankzeit (s. Abb. 17).

Abb. 16: Aktivitätsprofile. © Randolf Geist
Abb. 16: Aktivitätsprofile. © Randolf Geist
Abb. 17: Auswertungen der Datenbankzeit. © Randolf Geist
Abb. 17: Auswertungen der Datenbankzeit. © Randolf Geist

Wir reden hier also von einer Erhöhung von 7 auf über 50 Minuten Datenbankzeit, wenn wir den vorherigen SELECT MAX() UNION ALL mit dieser Abfrage hier vergleichen, obwohl genau die gleiche Grunddatenmenge zu verarbeiten ist und auch die gleichen Exadata-Optimierungen greifen! Ebenso erhöht sich die CPU-Zeit in den „Compute Nodes“ von ca. 5 auf 35 Minuten, was auch ziemlich genau dem Siebenfachen entspricht.

Im undefinedzweiten Teil dieses Artikels vertiefen wir die Analyse, indem wir auf Ausführungsplan-Ebene die Aktivitäten untersuchen, und schauen uns Optimierungsmöglichkeiten für den vorliegenden Fall an.

Autor

Randolf Geist

Randolf Geist ist als freiberuflicher Oracle Datenbank-Experte tätig und auf Performance-Themen spezialisiert. Im Bereich der Oracle Optimizer-Technologie und SQL Performance Analyse gehört er zu den Top-Experten.
>> Weiterlesen
Buch des Autors:

YTo2OntzOjY6ImZldXNlciI7aTowO3M6MzoicGlkIjtpOjE1NDA7czozOiJjaWQiO3M6NDoiNzEzOCI7czo0OiJjb25mIjthOjg6e3M6MTA6InN0b3JhZ2VQaWQiO2k6ODIyO3M6MTM6IlVzZXJJbWFnZVNpemUiO2k6MTg7czo5OiJhZHZhbmNlZC4iO2E6Mjp7czoxMDoiZGF0ZUZvcm1hdCI7czo5OiJkLW0teSBIOmkiO3M6MjE6InNob3dDb3VudENvbW1lbnRWaWV3cyI7aTowO31zOjg6InNoYXJpbmcuIjthOjE6e3M6MTI6InVzZVNoYXJlSWNvbiI7Tjt9czo4OiJyYXRpbmdzLiI7YToyOntzOjE2OiJyYXRpbmdJbWFnZVdpZHRoIjtpOjExO3M6MTY6InJldmlld0ltYWdlV2lkdGgiO2k6MTY7fXM6NjoidGhlbWUuIjthOjEyOntzOjI2OiJib3htb2RlbFRleHRhcmVhTGluZUhlaWdodCI7aToyMDtzOjI0OiJib3htb2RlbFRleHRhcmVhTmJyTGluZXMiO2k6MTtzOjE1OiJib3htb2RlbFNwYWNpbmciO2k6NDtzOjE4OiJib3htb2RlbExpbmVIZWlnaHQiO2k6MjU7czoxODoiYm94bW9kZWxMYWJlbFdpZHRoIjtpOjEzNDtzOjI2OiJib3htb2RlbExhYmVsSW5wdXRQcmVzZXJ2ZSI7aTowO3M6MjI6ImJveG1vZGVsSW5wdXRGaWVsZFNpemUiO2k6MzU7czoxNzoic2hhcmVib3JkZXJDb2xvcjIiO3M6NjoiY2RkZWVjIjtzOjE3OiJzaGFyZWJvcmRlckNvbG9yMSI7czo2OiJhZGFlYWYiO3M6MTE6ImJvcmRlckNvbG9yIjtzOjY6ImQ4ZDhkOCI7czoyMToic2hhcmVDb3VudGJvcmRlckNvbG9yIjtzOjY6ImUzZTNlMyI7czoyMDoic2hhcmVCYWNrZ3JvdW5kQ29sb3IiO3M6NjoiZmZmZmZmIjt9czoxNDoiZGF0ZUZvcm1hdE1vZGUiO3M6NDoiZGF0ZSI7czoxMjoiUmVxdWlyZWRNYXJrIjtzOjE6IioiO31zOjQ6ImxhbmciO3M6MjoiZGUiO3M6MzoicmVmIjtzOjE1OiJ0dF9jb250ZW50XzcxMzgiO30%3DYTo0OntzOjQ6ImNvbmYiO2E6MzM6e3M6MTc6InVzZVdlYnBhZ2VQcmV2aWV3IjtzOjE6IjAiO3M6MjI6InVzZVdlYnBhZ2VWaWRlb1ByZXZpZXciO3M6MToiMCI7czoyMDoid2VicGFnZVByZXZpZXdIZWlnaHQiO3M6MjoiNzAiO3M6MjA6Im1heENoYXJzUHJldmlld1RpdGxlIjtzOjI6IjcwIjtzOjMxOiJ3ZWJwYWdlUHJldmlld0Rlc2NyaXB0aW9uTGVuZ3RoIjtzOjM6IjE2MCI7czozODoid2VicGFnZVByZXZpZXdEZXNjcmlwdGlvbk1pbmltYWxMZW5ndGgiO3M6MjoiNjAiO3M6Mjc6IndlYnBhZ2VQcmV2aWV3Q2FjaGVUaW1lUGFnZSI7czozOiIxODAiO3M6MzM6IndlYnBhZ2VQcmV2aWV3Q2FjaGVUaW1lVGVtcEltYWdlcyI7czoyOiI2MCI7czozMDoid2VicGFnZVByZXZpZXdDYWNoZUNsZWFyTWFudWFsIjtzOjE6IjAiO3M6Mjg6IndlYnBhZ2VQcmV2aWV3TnVtYmVyT2ZJbWFnZXMiO3M6MjoiMTAiO3M6Mzg6IndlYnBhZ2VQcmV2aWV3U2Nhbk1pbmltYWxJbWFnZUZpbGVTaXplIjtzOjQ6IjE1MDAiO3M6MzA6IndlYnBhZ2VQcmV2aWV3U2Nhbk1pbkltYWdlU2l6ZSI7czoyOiI0MCI7czozMDoid2VicGFnZVByZXZpZXdTY2FuTWF4SW1hZ2VTaXplIjtzOjM6IjQ1MCI7czoyOToid2VicGFnZVByZXZpZXdTY2FuTWluTG9nb1NpemUiO3M6MjoiMzAiO3M6MzE6IndlYnBhZ2VQcmV2aWV3U2Nhbk1heEltYWdlU2NhbnMiO3M6MjoiNDAiO3M6Mzg6IndlYnBhZ2VQcmV2aWV3U2Nhbk1heEltYWdlU2NhbnNGb3JMb2dvIjtzOjI6IjU1IjtzOjQwOiJ3ZWJwYWdlUHJldmlld1NjYW5NYXhIb3J6aXpvbnRhbFJlbGF0aW9uIjtzOjE6IjUiO3M6Mzc6IndlYnBhZ2VQcmV2aWV3U2Nhbm1heHZlcnRpY2FscmVsYXRpb24iO3M6MToiMyI7czozMDoid2VicGFnZVByZXZpZXdTY2FuTG9nb1BhdHRlcm5zIjtzOjEwOiJsb2dvLGNyZ2h0IjtzOjM4OiJ3ZWJwYWdlUHJldmlld1NjYW5FeGNsdWRlSW1hZ2VQYXR0ZXJucyI7czo1NzoicGl4ZWx0cmFucyxzcGFjZXIseW91dHViZSxyY2xvZ29zLHdoaXRlLHRyYW5zcGEsYmdfdGVhc2VyIjtzOjM4OiJ3ZWJwYWdlUHJldmlld0Rlc2NyaXB0aW9uUG9ydGlvbkxlbmd0aCI7czoyOiI0MCI7czoyNToid2VicGFnZVByZXZpZXdDdXJsVGltZW91dCI7czo0OiI3MDAwIjtzOjEyOiJ1c2VQaWNVcGxvYWQiO3M6MToiMCI7czoxMjoidXNlUGRmVXBsb2FkIjtzOjE6IjAiO3M6MTM6InBpY1VwbG9hZERpbXMiO3M6MzoiMTAwIjtzOjE2OiJwaWNVcGxvYWRNYXhEaW1YIjtzOjM6IjgwMCI7czoxNjoicGljVXBsb2FkTWF4RGltWSI7czozOiI5MDAiO3M6MjI6InBpY1VwbG9hZE1heERpbVdlYnBhZ2UiO3M6MzoiNDcwIjtzOjIzOiJwaWNVcGxvYWRNYXhEaW1ZV2VicGFnZSI7czozOiIzMDAiO3M6MjA6InBpY1VwbG9hZE1heGZpbGVzaXplIjtzOjQ6IjI1MDAiO3M6MjA6InBkZlVwbG9hZE1heGZpbGVzaXplIjtzOjQ6IjMwMDAiO3M6MjA6InVzZVRvcFdlYnBhZ2VQcmV2aWV3IjtzOjA6IiI7czoyNDoidG9wV2VicGFnZVByZXZpZXdQaWN0dXJlIjtpOjA7fXM6MTE6ImF3YWl0Z29vZ2xlIjtzOjI4OiJXYXJ0ZSBhdWYgQW50d29ydCB2b24gR29vZ2xlIjtzOjg6InR4dGltYWdlIjtzOjEzOiJCaWxkIGdlZnVuZGVuIjtzOjk6InR4dGltYWdlcyI7czoxNToiQmlsZGVyIGdlZnVuZGVuIjt9YTowOnt9YTowOnt9YTo3OntzOjE2OiJjb21tZW50TGlzdEluZGV4IjthOjE6e3M6MTg6ImNpZHR0X2NvbnRlbnRfNzEzOCI7YToxOntzOjEwOiJzdGFydEluZGV4IjtpOjU7fX1zOjE0OiJjb21tZW50c1BhZ2VJZCI7aToxNTQwO3M6MTY6ImNvbW1lbnRMaXN0Q291bnQiO3M6NDoiNzEzOCI7czoxMjoiYWN0aXZlbGFuZ2lkIjtpOjA7czoxNzoiY29tbWVudExpc3RSZWNvcmQiO3M6MTU6InR0X2NvbnRlbnRfNzEzOCI7czoxMjoiZmluZGFuY2hvcm9rIjtzOjE6IjAiO3M6MTI6Im5ld2NvbW1lbnRpZCI7Tjt9 YTo1OntzOjExOiJleHRlcm5hbFVpZCI7aToxNTQwO3M6MTI6InNob3dVaWRQYXJhbSI7czowOiIiO3M6MTY6ImZvcmVpZ25UYWJsZU5hbWUiO3M6NToicGFnZXMiO3M6NToid2hlcmUiO3M6MTYyOiJhcHByb3ZlZD0xIEFORCBwaWQ9ODIyIEFORCB0eF90b2N0b2NfY29tbWVudHNfY29tbWVudHMuZGVsZXRlZD0wIEFORCB0eF90b2N0b2NfY29tbWVudHNfY29tbWVudHMuaGlkZGVuPTAgQU5EIChleHRlcm5hbF9yZWZfdWlkPSJ0dF9jb250ZW50XzcxMzgiKSBBTkQgcGFyZW50dWlkPTAiO3M6MTA6IndoZXJlX2RwY2siO3M6OTA6InBpZD04MjIgQU5EIHR4X3RvY3RvY19jb21tZW50c19jb21tZW50cy5kZWxldGVkPTAgQU5EIHR4X3RvY3RvY19jb21tZW50c19jb21tZW50cy5oaWRkZW49MCI7fQ%3D%3D YToyOntpOjA7czoxNDk6IjxpbWcgc3JjPSIvdHlwbzNjb25mL2V4dC90b2N0b2NfY29tbWVudHMvcmVzL2Nzcy90aGVtZXMvdGlzcXVzL2ltZy9wcm9maWxlLnBuZyIgY2xhc3M9InR4LXRjLXVzZXJwaWMgdHgtdGMtdWltZ3NpemUiIHRpdGxlPSIiICBpZD0idHgtdGMtY3RzLWltZy0iIC8%2BIjtpOjk5OTk5O3M6MTUxOiI8aW1nIHNyYz0iL3R5cG8zY29uZi9leHQvdG9jdG9jX2NvbW1lbnRzL3Jlcy9jc3MvdGhlbWVzL3Rpc3F1cy9pbWcvcHJvZmlsZWYucG5nIiBjbGFzcz0idHgtdGMtdXNlcnBpY2YgdHgtdGMtdWltZ3NpemUiIHRpdGxlPSIiICBpZD0idHgtdGMtY3RzLWltZy0iIC8%2BIjt9
Bitte bestätigen Sie
Nein
Ja
Information
Ok

Noch keine Kommentare vorhanden

Ihr Kommentar ist eine Antwort auf den folgenden Kommentar
Vorschau wird geladen ...
*: Pflichtfeld