RMAN> RECOVER TABLESPACE data1 
       UNTIL TIME "TO_DATE('12-jan-11 16:05:19','YY-MON-DD HH24:MI:SS')" 
       AUXILIARY DESTINATION '/opt/oracle/aux';
 

Eine gute Performance für Abfragen auf einer Oracle Datenbank zu erreichen und zu erhalten, ist eine ständige Herausforderung für den Datenbankadministrator. Verschiedene Technologien dienen dazu, eine gute Performance sicherzustellen. Ein Teil dieser Technologien, der ausnahmslos in der Enterprise Edition zur Verfügung steht, wird in diesem Abschnitt kurz vorgestellt.

Die Oracle Datenbank verfügt über eine Vielzahl von Caches, in denen unterschiedliche Inhalte gehalten werden.

Abbildung 5: Caches in der Oracle Datenbank

Der neue Result Cache kann auf dem Server im Shared Pool oder in OCI Applikationen auf dem Client verwendet werden und ist gedacht für Ergebnisse sich wiederholender Abfragen, Abfragen mit kleinen Ergebnismengen oder lang laufenden Abfragen mit teuren Berechnungen. Der Result Cache wird automatisch bei Datenänderungen aktualisiert und kann über Session- bzw. Systemparameter, Objekteigenschaften der Tabelle oder durch die Verwendung von Hints angesprochen werden. Das folgende kleine Beispiel zeigt die Syntax und die Auswirkung der Verwendung des Result Caches im Ausführungsplan.

WITH view1 AS
(SELECT /*+ result_cache */ department_id, manager_id, count(*) count 
 FROM hr.employees GROUP BY department_id, manager_id ) 
SELECT *
FROM view1 WHERE  count BETWEEN 1 and 10;
...
Execution Plan
-----------------------------------------------------------------------------------------------
Plan hash value: 2700420355
-----------------------------------------------------------------------------------------------
| Id  | Operation            | Name                       | Rows  | Bytes | Cost(%CPU)| Time  |
-----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |                            |   107 |  4173 |4  (25)| 00:00:01 |
|*  1 |  VIEW                |                            |   107 |  4173 |4  (25)| 00:00:01 |
|   2 |   RESULT CACHE       | 8saurmvh28pkx5kc6b2nqwcx9g |       |       |       |          |
|   3 |    HASH GROUP BY     |                            |   107 |   749 |4  (25)| 00:00:01 |
|   4 |     TABLE ACCESS FULL| EMPLOYEES                  |   107 |   749 |3   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
-----------------------------------------------------------------------------------------------
   1 - filter("COUNT">=1 AND "COUNT"<=10)
Result Cache Information (identified by operation id):
 

Ein Community Artikel, eine Demo und ein OBE Tutorial erläutern die Details dieser interessanten Funktion.

• Der Result Cache in 11g: Nutzung, Administration und Monitoring
• Demo: Using Result Cache
• OBE: Improving Application Performance Using Result Cache for Database 11g Release 1

Die anforderungsgerechte Verteilung der zur Verfügung stehenden Datenbank-Ressourcen ist ein wichtiges Instrument, um vereinbarte Service Level Agreements einhalten zu können. Der Database Resource Manager, den es bereits seit Oracle 8i gibt, dient dazu, CPU Ressourcen auf einem Datenbankserver zu verteilen. Hierbei werden Funktionen wie Instance Caging und Automated Maintenace Tasks unterstützt. Der Database Resource Manager kann wahlweise über eine API oder grafisch mit dem Oracle Enterprise Manager eingerichtet und überwacht werden

Abbildung 6: Datenbank Ressourcen verwalten im Oracle Enterprise Manager

Abbildung 7: Ressourcenverwendung anzeigen im Oracle Enterprise Manager

Zu diesem Thema gibt es hilfreiche Community Artikel:

• Ressourcen managen mit Database Resource Manager
• Vorfahrtsregeln: Ressourcenkonflikte in einer APEX Installation mit dem Ressoucen Manager l�sen

Die Grundlage für die Ausführung von SQL Statements bilden Ausführungspläne. Da eingesetzte Datenbankversion, Datenbestand, Statistiken oder auch die Anwendung selbst Änderungen unterworfen sind, können sich auch die Ausführungspläne mit zum Teil unerwünschten Nebenwirkungen ändern. Um diesen Effekt zu verhindern und für eine Stabilität der Ausführungspläne zu sorgen, wurde mit Oracle 11g das SQL Plan Management eingeführt. Das Konzept basiert darauf, dass SQL PLäne historisiert abgelegt werden und auf diese Weise plötzliche Änderungen bemerkt werden können. Die Datenbank legt einen Ausführungsplan, der zum wiederholten Mal ausgeführt wird, als sogenannte Baseline ab und greift darauf zurück, wenn ein modifizierter Ausführungsplan verwendet würde. Neue Pläne können gegebenenfalls durch den Datenbankadministrator manuell akzeptiert werden, so dass nur verifizierte Pläne angewendet werden. Das ist besonders bei einem Datenbank Upgrade interessant, wie das folgende Schaubild illustriert.

Abbildung 8: Schematische Darstellung eines Upgrade Szenarios mit SQL Plan Management

Zu dem Umgang mit SQL Ausführungsplänen gibt es zwei Community Artikel, die das Thema näher beleuchten.

• Ausf�hrungspl�ne mit DBMS_XPLAN
• SQL Pl�ne in 11g und das SQL Plan Management Feature

Der schonende Umgang mit Plattenspeicher ist trotz der ständig sinkenden Kosten ein wichtiges Thema in der Administration von Datenbanken, denn die Bearbeitung und der Transport großer Datenmengen durch die Datenbank hat auch einen nicht zu unterschätzenden Performanceaspekt. Nicht zuletzt kostet natürlich Plattenplatz, der unnötigerweise - zum Beispiel für Segmente ohne Inhalt - verbraucht wird, Geld. Diesen Umstand adressiert die Funktion der Deferred Segment Creation, mit der Segmente erst bei Bedarf, also mit dem ersten Datensatz des Segmentes, angelegt wird. Zwei Community Artikel beschreiben diese in Oracle 11gR2 erweiterte Funktionalität.

• 11g Release 2: Deferred Segment Creation und Zero Size Unusable Index
• Platz sparen mit Deferred Segment Creation in 11.2.0.2

Eine andere Möglichkeit, Platz einzusparen, ist die Nutzung von Komprimierung. Diese funktioniert mit der Enterprise Edition standardmäßig nur für Bulk Load Operationen. Die Komprimierung erfolgt auf Blockebene, wie die schematische Darstellung zeigt.

Abbildung 9: Blockkomprimierung in der Enterprise Edition

In dem folgenden Community Artikel wird die Komprimierung in der Enterprise Edition und vor allem auch die Verwendung des Compression Advisors näher beschrieben. Der Compression Advisor ist im Standardumfang der Oracle Datenbank enthalten und dient dazu, erreichbare Komprimierungsraten zu berechnen oder festzustellen, wie ausgewählte Daten komprimiert worden sind.

• Komprimierung und der Compression Advisor DBMS_COMPRESSION

Es gibt verschiedene Wege, eine Oracle Datenbank mit Daten zu befüllen. Neben SQL bzw. PL/SQL Code und Werkzeugen wie SQL*Loader oder Data Pump können externe Tabellen, das neue Datenbank Filesystem und Transportable Tablespaces verwendet werden. Erstmals in Oracle 8i eingeführt, werden mit Transportable Tablespaces mittlerweile auch unterschiedliche Datenbankblock-Größen unterstützt. Selbst ein plattformübergreifender Transport ist seit Oracle 10g möglich. Bei abweichender Endianness wird die RMAN-Konvertierung verwendet, um beispielsweise Tablespaces von einer Windows-Plattform zu einer Unix-Plattform zu transportieren. Ein Community Artikel zeigt den Umgang mit Transportable Tablespaces, mit dem ein Datentransfer zwischen Datenbanken nahezu unabhängig von der übertragenen Datenmenge möglich ist.

• Transportable Tablespaces: Grundlagen und Einsatz am Beispiel

Zurück zum Anfang des Artikels

Zurück zur Community-Seite