Statistiken - Voraussetzung für gute Performance.
Statistiken sind Voraussetzungen für den Optimizer, um einen optimalen Ausführungsplan bestimmen zu können. Folgende Statistiken sollten vorhanden sein:

• Oracle Data Dictionary Statistics
• Fixed Tabel Statistics
• Schema Statistics
• System Statistics

Oracle empfiehlt, die fixed_objects_stats nur einmalig oder nach einer signifikanten Änderung im Workload der Applikation auszuführen.

zurück...

Explain Plan - sehen, wie Abfragen ausgeführt werden.
Mithilfe der Explain-Plan Funktionalität sehen sie den Ausführungsplan, den Oracle aktuell wählen würde. Voraussetzung für die Anzeige der Pläne ist eine aktuelle plan_table:

Die einfachste Variante ist die Nutzung von 'explain paln for sql' und der Anzeige mit der Tablefunction DBMS_XPLAN. Es gibt auch zalreiche Tools, die ein Userinterface zu dieser Funktionalität bieten.

Vorsicht ist jedoch geboten, da dieser Ausführungsplan zur Laufzeit des Codes abweichend sein kann. Hier bieten sich mehrere Möglichkeiten. Zu aller erst kann der Ausführungsplan sowie wesentliche Faktoren für die Performance über die 'set autotrace on' Funktion ausgegeben werden:

Um den Asuführungsplan auf Dauer stabil zu halten bieten sich 3 Möglichkeiten:

• Oracle Outlines
• SQL-Profiles des Advisors
• Oracle Hints

zurück...

Oracle Advisors - Tuning leichtgemacht.
Im ersten Schritt wird eine Tuningtask definiert. Hier können folgende Möglichkeiten genutzt werden:

• Tuning Task für ein spezielles Statement aus dem AWR-Report
• Tuning Task für ein spezielles Statement aus dem Cursor Cache
• Tuning Task für ein SQL Tuningset
• Tuning Task für ein manuell definiertes SQL Statement

Nach der Definition der Tuning Tasks müssen diese gestartet werden. Tuning Tasks können sehr lange laufen, daher bietet das Package Funktionen zum Stoppen, Löschen und Fortsetzen von Tuningtasks an.

Die Ausgabe der Ergbnisse erfolg über ein einfaches SQL-Statement.

zurück...

Datenkomprimierung - Reduziert die Kosten und den I/O.
Oracles 'compress' Funktionalität erfährt in der Praxis nicht die Beachtung, die es verdiehnt hätte. Im VLDB Umfeld können Reduktionen des Storage-Bedarf um ca 50% (over-all) erreicht werden. Einzelne große Tabellen können duchauch auf 25% komprimiert werden. Dies stellt eine erhebliche Kostenreduktion dar, reduziert aber auch die Anforderungen an den I/O Bedarf da weniger Blöcke gelesen werden müssen.

Entscheidend für den Erfolg ist, das Automatismen zur regelmäßigen Wartung zur Verfügung stehen. Daten weden in Oracle nur komprimiert gespeichert, wenn:

• ein Insert mit append-Hint erfolgt
• die Tabelle z.b. mit 'alter table move tablespace' neu aufgebaut wird

Bei Update-Zugriffen wird die der geänderte Record nicht mehr komprimiert zurück gegeben. Lob Segemente werden nicht komprimiert. Um dauerhaft von einer Komprimierung zu profitieren muß diese in eine autoamtische Wartungsroutine eingebunden sein.

zurück...

Oracle Redefinitio Facility - Maintenance im 7 x 24 Betrieb

Mit dem Redefinition-Package liefert Oracle eine Möglichkeit, im laufenden Betrieb Maintenance-Arbeiten an Tabellen und Indizes durchzuführen. Insbesondere die Partitionionierung von Tabellen bei wachsendem Datenhaushalt läßt sich hiermit einfach umsetzen.

Das Prinzip basiert auf der Erstellung einer neuen Tabelle in der neuen Struktur, dem komfortablen Kopieren alle abhängigen Objekte wie Trigger, Grants, Constraint etc und einer Datensyncronisation basierend auf der Snapshotfunktionalität. Die betroffene Tabelle kann ohne Einschränkungen weiterhin online genutzt werden so das Wartungsintervalle entfallen.

Die Schritte im einzelnen, als Beispiel wählen wir die Partitionierung einer Tabelle.

1. Man erstellt eine neue Tabelle im gewünschten Layout.

2. Prüfung, ob sich die Tabelle für die Verwendung zur Redefinition eigent und der Start dieser. In diesem Schritt werden alle Daten der Originaltabelle in die neue Tabelle übertragen und es wird ein Snapshot Log auf der Originaltabelle angelegt.

3. Optional können neue bzw geänderte Indexe , Trigger oder Constraints angelegt werden. In unserem Fall soll der Primary Key partitioniert werden und muß daher eine neue Spalte bekommen. Anschließend müssen diese Objekte für den folgenden Schritt der Prozedur zur automatischen Erstellung der abhängigen Objekte bekannt gemacht werden. Diese erkennt somit, dass Objekte manuell erstellt wurden und versucht nicht, sie zu kopieren.

4. Die restlichen Objekte werden kopiert. Hierbei gibt es einige zu berücksichtigende Optionen.

5. Zum Abschluss wird die neue Tabelle per dbms_stats analysiert und der Redefinitionsprozess wird abgeschlossen. Dabei wird Oracle die in der Zwischenzeit angelaufenen DML's über den Snapshot Log mit der neuen Tabelle syncronisieren und die Tabelle sowie die erstellten abhängigen Objekte umbenennen. Damit ist die Tabelle in die neue Form überführt und die alte Tabelle kann per 'dop' gelöscht werden. Vorsicht: vor dem 'dop' sollte man zur Sicherheit das Ergebnis verifizieren!

zurück...