Oracle Tuning in der Praxis

1 Oracle-Design (S. 1)

Thema des ersten Kapitels sind die Möglichkeiten Oracles für ein Design, das eine gute Performance gewährleistet.

Idealerweise propft man Performance nicht nachträglich auf die Datenbank, sondern berücksichtigt sie von Anfang an im Design. Das setzt natürlich voraus, dass Sie schon beim Design der Applikation mit den entsprechenden Möglichkeiten des Datenbanksystems vertraut sind.

Unabhängig davon, welchen Typ von Objekten Sie verwenden – wobei es sich zum Großteil um Tabellen und Indizes handeln wird –, müssen Sie diese Objekte physikalisch abspeichern. Mit der physikalischen Organisation treffen Sie auch Entscheidungen, die sich auf die Performance auswirken (dieses Thema wird in einem separaten Kapitel en détail besprochen).

Während sich der Rest des Buches vornehmlich der Untersuchung und Analyse bestehender Applikationen widmet, behandelt dieses Kapitel die Frage, wie man Applikationen baut, die Performance bereits im Design berücksichtigen. Dabei liegt der Schwerpunkt auf der Datenbank und SQL. Gleichzeitig handelt es sich hier um jenes Kapitel, das sich vor allem an den Entwickler richtet.

1.1 Datenhaltung in Oracle

1.1.1 Tabellen

Für die Speicherung der applikatorischen Daten bietet Oracle verschiedene Möglichkeiten an. Im Regelfall werden Sie ganz normale relationale Tabellen verwenden. Es existieren zwar auch Objekttypen, aber diese sollten Sie nicht zur Speicherung verwenden, weil dort zu viel hinter der Bühne passiert. Wenn Sie beispielsweise eine Nested Table oder eine Object Table anlegen, generiert Oracle im Hintergrund versteckte Spalten, die Sie der Tabelle erst mal nicht ansehen. Für die Applikationsentwicklung sind diese Typen exzel- lent geeignet, nicht aber für die Persistenz.

Im Regelfall sollten Sie ganz normale relationale Tabellen verwenden. Die einfache CREATE TABLE-Anweisung erzeugt eine relationale Tabelle, genauer gesagt, eine Heap-Tabelle. Ein Heap ist in der konventionellen Programmierung eine bekannte Struktur. Eine Heap-Tabelle hat keine eingebaute Reihenfolge der Einträge, Letztere können dynamisch hinzugefügt und gelöscht werden.

Bei den Tabellen Ihrer Applikation wird es sich zu 95% oder mehr um solche Tabellen handeln. Theoretisch könnten Sie beim Anlegen der Tabelle auch angeben, dass es sich um eine Heap- Tabelle handelt: CREATE TABLE .. ORGANIZATION HEAP. Dies ist aber ohnehin die Voreinstellung. Weitere Details finden Sie in der offiziellen Oracle-Dokumentation in [OraCon 2008] und [OraSql 2008].

Temporäre Tabellen

Es gibt auch temporäre Tabellen, die man zur Speicherung von Zwischenresultaten verwenden kann, sie werden mit CREATE GLOBAL TEMPORARY TABLE erzeugt. Diese Tabelle ist dann für alle Sessions, also global innerhalb der Datenbank, sichtbar. Im Bereich Performance ist der Unterschied zwischen temporären und regulären Tabellen aber oft nicht so signifikant.

Betrachten Sie temporäre Tabellen also vor allem als applikatorische Möglichkeit, nicht als Mittel zur Steigerung der Performance. Zwar generiert eine temporäre Tabelle kein Redo. Das ist gut für die Performance. Bei mehrstufigen Abfragen – also Query A ist Input für Query B und B ist potenziell wieder Input für eine neue Query etc. – sind sie sicher eine sehr naheliegende Lösung.

Sie haben aber – teilweise versionsbedingt – auch keine Statistiken, was unter Umständen wiederum einen schlechten Zugriffsplan verursacht. Dieses Problem lässt sich dann allerdings durch manuelles Setzen der Statistiken über DBMS_STATS oder dynamisches Sammeln der Statistiken (ab 9.2) lösen.