Abfrage Kosten vs. Ausführungsgeschwindigkeit + Parallelität

Question

Meine Abteilung wurde kürzlich (schön) von unserer IT-Abteilung für die Ausführung von Abfragen mit sehr hohen Kosten unter der Voraussetzung, dass unsere Abfragen eine reale Möglichkeit der Destabilisierung und/oder Absturz der Datenbank haben. Keiner von uns ist DBA's; waren nur Forscher, die Abfragen an die Datenbank schreiben und ausführen, und ich bin wahrscheinlich der Einzige, der jemals einen Erklärungsplan vor dem Verweis gelesen hat.

Uns wurde gesagt, dass Abfragekosten über 100 sollten sehr selten sein, und Abfragen mit Kosten über 1000 sollten nie ausgeführt werden. Die Probleme, mit denen ich konfrontiert bin, sind, dass die Kosten keine Korrelation mit der Ausführungszeit haben, und ich verliere die Produktivität, während ich versuche, meine Abfragen zu optimieren.

Als Beispiel habe ich eine Abfrage, die in weniger als 5 Sekunden mit einem Aufwand von 10844 ausgeführt wird. Ich schrieb die Abfrage um eine Ansicht zu verwenden, die die meisten Informationen enthält, und die Kosten auf 109 herunter, aber Die neue Abfrage, die dieselben Ergebnisse abruft, dauert 40 Sekunden. Ich fand hier eine Frage mit einer möglichen Erklärung:

Measuring Query Performance : "Execution Plan Query Cost" vs "Time Taken"

Diese Frage führte mich zu Parallelität Hinweise. Ich versuchte mit /*+ no_parallel*/ in der 10884 Abfrage, aber die Kosten nicht geändert, noch die Ausführungszeit, so bin ich mir nicht sicher, dass Parallelität die Erklärung für die schnellere Ausführungszeit, sondern höhere Kosten ist. Dann habe ich versucht, den /*+ parallel(n)*/ Hinweis zu verwenden, und fand, dass je höher der Wert von n, desto niedriger die Kosten der Abfrage. Im Fall der Abfrage 10844, fand ich, dass /*+ parallel(140)*/ die Kosten auf 97 fallen ließ, mit einem sehr geringen Anstieg der Ausführungszeit. Diese

schien wie ein idealer „betrügen“, um die Anforderungen zu erfüllen, die unsere IT-Abteilung dargelegt, aber dann las ich dies:

http://www.oracle.com/technetwork/articles/datawarehouse/twp-parallel-execution-fundamentals-133639.pdf

Der Artikel enthält den Satz:

Parallel Durch die Ausführung kann eine einzelne Operation alle Systemressourcen nutzen. So

, sind meine Fragen:

Bin ich eigentlich mehr Belastung für die Server-Ressourcen Platzierung durch den /*+ parallel(n)*/ Hinweis mit einem sehr hohen Grad an Parallelität verwenden, obwohl ich die Kosten senken bin?

Unter der Annahme, keine Parallelität, ist die Ausführungsgeschwindigkeit ein besseres Maß für die verwendeten Ressourcen als die Kosten?

Answer 1

Die Regel, die Ihr DBA Ihnen gab, macht nicht viel Sinn. Sich um die Kosten zu kümmern, die für eine Abfrage gemeldet werden, ist sehr selten produktiv. Erstens können Sie die Kosten zweier verschiedener Abfragen nicht direkt vergleichen. Eine Abfrage mit Millionenkosten kann sehr schnell ausgeführt werden und sehr wenige Systemressourcen verbrauchen. Eine andere Abfrage mit Kosten in den Hunderten kann Stunden dauern und den Server mitbringen in die Knie gehen. Zweitens sind Kosten eine Schätzung. Wenn der Optimierer eine genaue Schätzung der Kosten vorgenommen hat, bedeutet dies, dass er den optimalen Abfrageplan erstellt hat, was bedeutet, dass es unwahrscheinlich ist, dass Sie die Abfrage so ändern können, dass dieselben Ergebnisse mit weniger Ressourcen zurückgegeben werden . Wenn der Optimierer eine ungenaue Schätzung der Kosten vorgenommen hat, impliziert dies, dass ein schlechter Abfrageplan erstellt wurde. In diesem Fall hätten die gemeldeten Kosten keine Beziehung zu einer nützlichen Kennzahl, die Sie ermitteln würden. In den meisten Fällen sind die Abfragen, die Sie zu optimieren versuchen, die Abfragen, bei denen der Optimierer einen falschen Abfrageplan generiert hat, da die Kosten verschiedener Schritte falsch geschätzt wurden.

Das Optimieren des Optimierers durch Hinweise, die den Abfrageplan möglicherweise ändern (oder nicht) (z. B. abhängig davon, wie die Parallelität konfiguriert ist), ist sehr wahrscheinlich, um ein Problem zu lösen - es ist viel wahrscheinlicher, die Schätzungen des Optimierers zu verursachen weniger genau sein und es wahrscheinlicher machen, dass es einen Abfrageplan auswählt, der viel mehr Ressourcen verbraucht, als er benötigt. Ein parallel Hinweis mit einem hohen Grad an Parallelität beispielsweise würde Oracle dazu bringen, die Kosten für einen vollständigen Tabellenscan drastisch zu reduzieren, was es wahrscheinlicher macht, dass der Optimierer dies über einen Indexscan auswählen würde. Das ist selten etwas, was Ihre DBAs sehen möchten.

Wenn Sie nach einer einzelnen Metrik suchen, die Ihnen sagt, ob ein Abfrageplan sinnvoll ist, würde ich die Menge an logischen I/O verwenden. Logische I/O korreliert ziemlich gut mit der tatsächlichen Abfrageleistung und der Menge an Ressourcen, die Ihre Abfrage verbraucht. Das Betrachten der Ausführungszeit kann problematisch sein, da sie je nachdem, welche Daten zwischengespeichert werden, sehr unterschiedlich ist (weshalb Abfragen beim zweiten Ausführen häufig viel schneller ausgeführt werden), während sich die logische E/A nicht aufgrund der Daten ändert im Cache. Sie können Ihre Erwartungen auch skalieren, indem Sie die Anzahl der Zeilen ändern, die Ihre Abfragen verarbeiten müssen. Wenn Sie beispielsweise eine Abfrage schreiben, bei der Daten aus 1 Million Zeilen aggregiert werden müssen, sollten Sie weit mehr Ressourcen benötigen als eine Abfrage, die 100 Datenzeilen aus einer Tabelle ohne Aggregation zurückgeben muss. Wenn Sie logische E/A betrachten, können Sie Ihre Erwartungen einfach an die Größe des Problems anpassen, um herauszufinden, wie effizient Ihre Abfragen realistisch sein können.

In Christian Antognini der „Troubleshooting Oracle Performance“ (Seite 450), zum Beispiel, er Faustregel gibt, die ziemlich vernünftig ist

• 5 logische liest pro Zeile, die zurückgegeben/aggregiert ist wahrscheinlich sehr gut
• 10 logische liest pro Zeile, die zurückgegeben wird/aggregiert ist wahrscheinlich ausreichend
• 20+ pro Zeile logische liest, die wahrscheinlich ineffizient zurück/aggregiert und muss

abgestimmt werden

Verschiedene Systeme mit unterschiedlichen Datenmodellen können es wert sein, die Buckets ein wenig zu optimieren, aber diese sind wahrscheinlich gute Startpunkte.

Meine Vermutung ist, dass wenn Sie Forscher sind, die keine Entwickler sind, Sie wahrscheinlich Abfragen ausführen, die relativ große Datenmengen aggregieren oder abrufen müssen, zumindest im Vergleich zu denen, die Anwendungsentwickler üblicherweise schreiben. Wenn Sie eine Million Datenzeilen scannen, um aggregierte Ergebnisse zu generieren, werden Ihre Abfragen natürlich wesentlich mehr Ressourcen verbrauchen als ein Anwendungsentwickler, dessen Abfragen eine Handvoll Zeilen lesen oder schreiben. Möglicherweise schreiben Sie Abfragen, die aus einer logischen E/A-Perspektive pro Zeile genauso effizient sind, und Sie können sich nur noch viele weitere Zeilen ansehen.

Wenn Sie Abfragen für die Live-Produktionsdatenbank ausführen, befinden Sie sich möglicherweise in einer Situation, in der es sinnvoll ist, die Arbeitslast zu trennen. Die meisten Unternehmen erreichen einen Punkt, an dem das Ausführen von Berichtsabfragen für die Live-Datenbank beginnt, Probleme für das Produktionssystem zu verursachen. Eine gängige Lösung für diese Art von Problem ist die Erstellung einer separaten Berichtsdatenbank, die vom Produktionssystem gespeist wird (entweder über eine nächtliche Momentaufnahme oder durch einen fortlaufenden Replikationsprozess), wo Berichtsabfragen ausgeführt werden können, ohne die Produktionsanwendung zu stören. Eine andere gängige Lösung besteht darin, mithilfe von Oracle Resource Manager die Anzahl der für eine Benutzergruppe (in diesem Fall Berichtsentwickler) verfügbaren Ressourcen einzuschränken, um die Auswirkungen auf Benutzer mit höherer Priorität (in diesem Fall auf Benutzer der Produktion) zu minimieren System).