
| PL/SQL Prozedurale Erweiterung der Abfragesprache SQL (Structured Query Language). |
| Code-Generator Erstellt aus einer Anwendung, wie z. B. PL/SQL, ausführbaren Bytecode. |
| Exceptions Fehlerbehandlungsteil in PL/SQL. |
| PL/SQL Virtual Maschine (PVM) Hier wird der durch den Code-Generator erstellte Bytecode ausgeführt. |
| Black-Box Ein Objekt, bei dem nur das äußere Verhalten von Interesse ist. Seine innere Funktionsweise ist unbekannt. |
| Kompilieren Vorgang des Code- |
In vorherigen Oracle-Versionen wurde PL/SQL-Code eins zu eins übersetzt, ohne an ihm viele Änderungen vorzunehmen. Der Code-Generator der früheren Versionen war sehr mechanisch. Es galt das Motto: "What you write is what you get". Wurde im Quellcode der Weg von A nach B über einen Umweg C gewählt, so wurde dieser Umweg während der Ausführung auch konsequent ausgeführt.
Nun wird ein neuer Code-Generator genutzt, der den Code zur Erzielung einer besseren Performance gegebenenfalls komplett umgestaltet. Und das, ohne jeglichen Eingriff von außen. Bei demselben Quellcode, der von A nach B über den Umweg C führt, weiß der Code-Generator in Oracle 10g nun, dass es auch einen direkten Weg von A nach B gibt, und führt auch nur diesen aus.
Ab Oracle 10g gilt nun: "What you write is NOT what you get"! Dies führt z. B. bei rekursiven Schleifen, wie in unserem Beispiel A zu sehen [1], zu einer enormen Verbesserung der Performance. Viele altbekannte Regeln der PL/SQL-Programmierung sind nun hinfällig, weil sie durch den neuen Code-Generator in den zur Ausführung "günstigsten" Code umgewandelt werden.
Mit dem neuen Code-Generator wurde auch PLSQL_OPTIMIZE_LEVEL, ein neuer Initialisierungsparameter, eingeführt. Dieser beeinflusst die Code-Optimierung und kann mit den Werten 1 und 2 belegt werden, wobei 2 der Standardwert ist. Der Standardwert sollte normalerweise auch der bessere sein. Er liefert die optimale Code-Generierung, wohingegen der Wert 1 die Code-Generierung geringfügiger optimiert, dadurch aber eine kürzere Kompilierungszeit zur Folge hat.
Dauert die Kompilierung bei sehr großen Anwendungen zu lange, sollte der Wert auf 1 gesetzt werden. In sehr wenigen Fällen ist zwischen den beiden Parametern auch eine unterschiedliche Behandlung der Exceptions festzustellen. Eventuell werden Exceptions gar nicht ausgelöst oder zu einem früheren Zeitpunkt als erwartet. Wird der Parameter PLSQL_OPTIMIZE_LEVEL auf 0 gesetzt, so wird das Optimieren des Codes komplett ausgeschaltet. Dies wird natürlich nicht empfohlen.
Die PVM ist, wie in allen anderen Programmiersprachen, z. B. Java, notwendig, um den vom Code-Generator erstellten Code auszuführen. Die PVM wurde zwar nicht wie der Code-Generator komplett erneuert, aber entscheidend verbessert. So werden Konkatenationen nicht mehr wie in früheren Releases nacheinander verarbeitet und temporär zwischengespeichert, sondern sie können in einer einmaligen Verkettung ausgeführt werden.
Die meisten Änderungen wurden an den Befehlen der PVM vorgenommen, z. B. an der Speicheradressierung. Außerdem konnte durch eine bessere Programmierung der PVM selbst die Performance während der Ausführung entscheidend gesteigert werden. Da sich die PVM wie eine "Black-Box" verhält, sind diese Neuerungen vom Entwickler nicht beeinflussbar. Sie sind für ihn aber trotzdem sehr hilfreich.
Folgende Beispiele sollen die Performance-Steigerung in Oracle 10g verdeutlichen:
Jeder PL/SQL-Entwickler weiß, dass eine Rekursion immer langsamer ist als eine gleiche, iterative Lösung.
Diese Aussage trifft zwar auch in Oracle 10g zu, aber in unseren Tests konnten rekursive Lösungen gegenüber Oracle 9i deutlich aufholen. Den Beispiel-Code, der dem Vergleich zugrunde liegt, finden Sie unter [1].
Wie Abbildungen 1 a und b zeigen, sind rekursive Lösungen in Oracle 10g deutlich leistungsstärker als in früheren Versionen. Im Vergleich zu Oracle 9i konnten wir eine bis zu circa 25 Prozent gesteigerte Performance feststellen. Nichts desto trotz konnte die Rekursion die Performance der Iteration nicht einholen.
![]() |
| Abb. 1 a und b: Das Ergebnis des Performance-Vergleichs zwischen Rekursion und Iteration - jeweils für die Versionen 9i und 10g. |
Ein Grundsatz, der für jeden PL/SQL-Entwickler gilt, ist, dass Rechen-Ausdrücke nicht innerhalb einer Schleife zu verwenden sind. Dies führte in Oracle 9i zu deutlichen Performance-Einbußen, da die Rechenoperation in jedem Schleifendurchlauf erneut auszuführen war.
Dies gilt nicht mehr in Oracle 10g. Hier sind sogar fast gleichwertige Zeiten festzustellen. Den Code zu einem einfachen Beispiel finden Sie unter [2].
Auch die Abbildungen 2 a und b zeigen den deutlichen Performance-Unterschied zwischen Expression und Faktor. In Oracle 10g ergibt sich im Fall von Expressions sogar eine Performance-Verbesserung von bis zu 75 Prozent gegenüber der Version Oracle 9i.
![]() |
| Abb. 2 a und b: Performance-Vergleich zwischen Expression und Faktor. |
Als letzte Einflussgröße seien Konstanten erwähnt. Diese hatten bisher keinen Einfluss auf die Performance einer PL/SQL-Anwendung. Dies wird nun mit dem Beispiel unter [3] für Oracle 10g widerlegt. Das Ergebnis aus den Abbildungen 3 a und b belegt, dass die vorzugsweise Nutzung von Konstanten gegenüber einer Nutzung von Variablen geringfügig die Performance verbessert.
Es gibt unzählige weitere Beispiele, die eine Performance-Steigerung in Oracle 10g verdeutlichen. Unsere Tests zeigen es. Probieren Sie es einmal selbst mit Ihren vorhandenen Skripten oder unseren Beispielen aus.
![]() |
| Abb. 3 a und b: Das Ergebnis des Performance-Vergleichs zwischen der Nutzung von Konstanten und Variablen in PL/SQL. |
Mit dem Harness Software Kit stellt Oracle dem Entwickler ein Tool zur Verfügung, mit dem sich die Performance-Unterschiede eines PL/SQL-Programms messen lassen. Das Tool steht zum freien Download zur Verfügung und kann mit den circa 30 vorhandenen Test-Programmen oder mit eigenen PL/SQL-Anwendungen genutzt werden.
Durch eine Vielzahl vorgefertigter Reports lassen sich so z. B. HTML-Dokumente oder sogar Microsoft Excel-Sheets erstellen. Das Tool dient nicht nur zur Performance-Messung der PL/SQL-Anwendungen auf Datenbanken der Versionen 9i und 10g, sondern es kann bereits ab der Version 8.0 benutzt werden. Eine ausführliche Anleitung sowie das komplette Software-Kit finden Sie unter [4] zum Download.
In Oracle 10g wird dem Entwickler die Arbeit vereinfacht. Er braucht sich weniger Gedanken um die Performance-Optimierung, um schnelle Kompilierungszeiten oder gar um das Sammeln von Statistiken zu machen.
Dies erledigt der Code-Generator nun großteils selbst. Und das, wie wir gesehen haben, sogar sehr schnell und zuverlässig. Auch wenn wir die von Oracle angepriesenen 50 Prozent in unseren Testfällen nicht durchweg bestätigen konnten, ist dennoch eine deutliche Performance-Verbesserung festzustellen. Wer trotzdem Code von Hand optimieren möchte und gar keine Optimierung seitens des Code-Generators wünscht, ist aber auch weiterhin mit Oracle PL/SQL sehr gut bedient.
Man sollte sich die beiden folgenden Aspekte bewusst machen: In der Version 10g gilt "Just write it the way that feels most natural" und "What you write is NOT what you get".
Dustin Schmitt (info@ordix.de).