Mittwoch, November 15, 2017

Extended Statistics und dynamic sampling

Eigentlich ist dynamic sampling eine Standardantwort auf falsche cardinalities für komplexe Queries mit hoher Laufzeit, bei denen das Parsing gegenüber der Gesamtlaufzeit in den Hintergrund tritt. Leider ist das Zusammenspiel zwischen dynamic sampling und statischen Statistiken noch ausbaufähig: aktuell werden z.B. extended statistics beim Einsatz von dynamic sampling komplett ignoriert - wie Franck Pachot in seinem Blog zeigt. Besonders gut gefällt mir das Fazit:
In this case, Adaptive Dynamic Sampling is a good approximation. But it would be better to have a level of dynamic sampling that does not consider a predicate as a complex one when the extended statistics exactly match the predicate. Before there is enough artificial intelligence to cope with this, the best recommendation is to focus on design. In this case, ensuring that we have only uppercase values is the best way to keep queries and estimations simple.
Ich denke, dass genau solche Effekte dafür sorgen, dass auch in Zeiten von "self-driving databases" in absehbarer Zeit nicht damit zu rechnen ist, dass Datenbankspezialisten über Umschulungen nachdenken müssen.

Freitag, November 03, 2017

Verhalten der auto_sample_size in 12c

Nigel Byliss erläutert im Oracle Optimizer Blog, die erfreulichen Änderungen, die für die auto_sample_size in 12c eingeführt wurden. Dabei ist die auto_sample_size der default-Wert für den Parameter estimate_percent der dbms_stats.gather_*_stats Prozeduren. Obwohl sie für viele Statistiken tatsächlich bereits seit ihrer Einführung sehr gute Ergebnisse lieferte, gab es einen Bereich, in dem ihre Ergebnisse recht erbärmlich ausfallen konnten, nämlich die Erstellung von Histogrammen, denn dafür wurde stets ein mikroskopisches Sample von gerade einmal 5500 Datensätzen verwendet.

In 12c wird nun folgendes Verfahren verwendet:
  • es erfolgt ein full table scan (also 100% Sample).
  • die Ermittlung von NDV-Werten (sprich: number of distinct values) erfolgt ohne Sortierung, sondern verwendet einen "approximate NDV algorithm", der mit Hash Werten arbeitet. Die Genauigkeit dieses Algorithmus ist dicht an 100%.
  • frequency und top frequency Histogramme werden mit den Daten des full table scans aufgebaut - also nicht mehr auf Basis einer minimalen Stichprobe. Zur Erinnerung: ein top frequency Histogramm kommt in Frage wenn die top 254 Werte mehr als 99% aller not null Werte ausmachen.
  • hybrid histograms verwenden weiterhin ein kleineres Sample: dieser Schritt ist also von der Basiserfassung getrennt.
  • Index-Statistiken werden mit einer automatisch ermittelten Stichprobengröße erzeugt.
Da mir die 5500 (non null) Zeilen in der Vergangenheit regelmäßig Ärger bereitet haben, halte ich diese Veränderung für ausgesprochen vorteilhaft.

Mittwoch, Oktober 25, 2017

CTAS-Statement-Texte in 12.2 Trace-Files nicht mehr gekürzt

Der Titel ist beinahe länger als der folgende Text, aber was tut man nicht alles, um den eigenen Blog nicht völlig einschlafen zu lassen: Martin Bach weist in seinem Blog darauf hin, dass die Texte in der SQL-Trace-Ausgabe für "create table as select" (aka CTAS) in 12.2 nicht mehr auf 20 Zeichen gekürzt werden, was in älteren Releases der Fall war und die Analyse solcher Operationen über Trace erschweren konnte. Darüber war ich in älteren Versionen auch schon gelegentlich gestolpert.

Montag, Oktober 02, 2017

Mehrere SQL_IDs zu einem Query-Text

Jonathan Lewis erläutert in seinem Blog ein - zumindest für mich überraschendes (sprich: bisher unbekanntes oder wieder vergessenes) Phänomen: zum gleichen SQL Text kann es mehrere unterschiedliche SQL_IDs geben. Eine relativ bekannte Ursache dafür ist offenbar, dass die Länge der in einer Query verwendeten Bindevariablen einen Einfluss auf die Erzeugung der SQL_IDs hat, was vermutlich ein Effekt des internen library Mechanismus ist und keine Design-Entscheidung.

Darüber hinaus erwähnt der Autor die Möglichkeit, ein Statement über die Prozedur dbms_shared_pool.markhot() - nun ja: als "hot" zu markieren, was dann sinnvoll ist, wenn sehr viele Sessions permanent die gleiche Query ausführen, so dass sehr viele Zugriffe auf den gleichen child cursor erfolgen. In diesem Fall wird eine neues Attribut in v$db_objct_cache ergänzt, dass als zusätzlicher Textbestandteil hinzukommt und damit einen neuen Hash-Wert und eine neue SQL_ID hervorruft. Dazu gibt es auch eine entsprechende unmark-Routine, mit der man die Kopien wieder reduzieren kann.

Mittwoch, September 27, 2017

Performance Feedback Optionen in 12c aktivieren und deaktivieren

Christian Antognini erläutert in seinem Blog, welche Schwierigkeiten sich in 12c ergeben, wenn man das "Performance Feedback" aktivieren oder deaktivieren möchte. Zur Erinnerung: das Performance Feedback ist ein adaptives Feature und dient zur automatischen Prüfung, ob ein initial gewählter Parallelisierungsgrad tatsächlich vorteilhaft ist. Relativ harmlos ist bei der Konfoiguration noch der Faktor, dass sich der zugehörige Parameter in 12.1 OPTIMIZER_ADAPTIVE_FEATURES nennt, während er in 12.2 (bzw. auch in 12.1, wenn man den passenden Patch installiert hat) auf den Namen OPTIMIZER_ADAPTIVE_STATISTICS hört. Daneben muss in beiden Versionen zusätzlich noch der Parameter PARALLEL_DEGREE_POLICY auf true gesetzt werden, um das Performance Feedback zu aktivieren. Weniger schön ist, dass die Reihenfolge der Setzung der Parameter eine Rolle spielt - und darüber hinaus der interne Parameter _OPTIMIZER_PERFORMANCE_FEEDBACK. Die Nacherzählung der Effekte der Reihenfolge spare ich mir an dieser Stelle.