Diese Woche ist eine aktualisierte Version des Whitepapers „Optimizer with Oracle Database 12c“ bei Oracle erschienen. Aus diesem Anlass möchte ich kurz über die wichtigste – und zugleich problematischste – Neuerung im 12c-Optimizer schreiben: Die adaptiven Features.
Heute fühle ich mich genötigt, ein Thema anzusprechen, das zwar ein Grundlagenthema ist, das aber immer wieder gerne in Vergessenheit gerät. ;-)
Anlass ist ein Fund in einer Produktionsumgebung, in der eine Überlastung der CPU bei sehr hoher Anzahl an SQL-Ausführungen zu beobachten war. Die Umgebung basiert sehr stark auf PL/SQL, wobei häufig verwendete SQL-Abfragen gerne in einer Function gekapselt und dann aus SQL heraus aufgerufen werden. Weiterlesen
David Litchfield, der bereits andere Injection-Lücken in Oracle gefunden hatte (s. meine anderen Artikel der Kategorie „Sicherheit“), hat wieder zugeschlagen und eine Injection-Methode unter 12c aufgedeckt:
http://www.davidlitchfield.com/Exploiting_PLSQL_Injection_on_Oracle_12c.pdf
Sehr kurze Zusammenfassung des Dokuments:
Vor ein paar Jahren hatte ich schon einmal über die „WITH-Klausel“ geschrieben, als sie noch ein relativ unbekanntes SQL-Feature war.
Mittlerweile hat sich auch die Oracle-Welt weiter gedreht, und es sind neue Möglichkeiten seit 11g hinzugekommen — z.T. Features, die mit dem ISO-Standard SQL1999 schon etwa 10 Jahre zuvor verabschiedet wurden.
Zeit also, sich einmal wieder mit der Syntax der WITH-Clause zu beschäftigen und sie mit Oracles bisherigen, proprietären Lösungen zu vergleichen!
Heute möchte ich auf ein altes, aber bewährtes Tool von Tom Kyte verweisen, das nach meiner Erfahrung weitgehend unbekannt oder unterbewertet ist, das aber extrem hilfreich ist, wenn man Daten aus Oracle mit bestmöglichem Durchsatz entladen will: Auftritt „unloader“!
Beim Zugriff aus MS Access heraus auf eine Oracle-Datenbank (11.2) kam es zu der folgenden Fehlermeldung, deren Ursache und Beseitigung ich hier kurz beschreiben möchte, da bislang kaum ein kurz zusammengefasster Artikel dazu im Netz zu finden ist:
Bei der Untersuchung der View, auf die zugegriffen wurde, fiel mir folgender Code auf:
(NVL(b.marktwertfondswhg, 0) - NVL(b.einstandswertfondswhg, 0)) / NVL(k.fondsvermoegen, 0)
Mal abgesehen davon, daß hier eine Division durch Null möglich wäre (nein, die View stammt nicht von mir…), war dies die einzige Spalte, in der ein Quotient gebildet wurde. Es lag also der Verdacht nahe, daß es sich um ein Problem mit inkompatiblen Datentypen handeln könnte.
Und in der Tat sollte es sich herausstellen, daß ADO maximal 28 Dezimalstellen unterstützt, wohingegen Oracles NUMBER-Datentyp bis zu 35 Dezimalstellen bietet. Seit Version 10.2 des „Oracle Provider for OLE DB“ stellt dieser Fließkommazahlen nicht mehr als Zeichenkette sondern eben als Zahl bereit, was also ab dem Einsatz dieser Version zu dem Problem führen kann.
Abhilfe schafft der Einsatz der Rundungsfunktion ROUND(). Der problematische Code von oben funktioniert dann problemlos mit folgender Umstellung:
ROUND((NVL(b.marktwertfondswhg, 0) - NVL(b.einstandswertfondswhg, 0)) / NVL(k.fondsvermoegen, 0), 28 )
Aus der Rubrik „heute dazugelernt“: Oracle erlaubt es, mindestens seit 9iR2 (frühere Versionen habe ich nicht getestet), mehr Spalten in einer SELECT-Liste anzugeben, als später in der GROUP BY-Klausel verwendet werden.
Für Aggregatfunktionen wie COUNT(), SUM(), etc. ist das ja klar, es geht darüberhinaus aber auch mit
