Logo Oracle Deutschland   DBA Community
Oracle's Eleven: Das Beste aus der 11g-Datenbank
von Frank Schneede, ORACLE Deutschland B.V. & Co. KG

Im Februar 2011 erfuhren 300 Teilnehmer der Veranstaltungsreihe Oracle's Eleven - das Beste aus der 11g-Datenbank mehr über die Möglichkeiten der Oracle-Datenbank. Im Fokus stand dabei die in Standard- und Enterprise Edition bereits eingebaute Funktionalität.

Für die Mitglieder der deutschsprachigen Communities stellen wir diese Informationen exklusiv nochmals zusammen. Wenn Sie nicht die Gelegenheit zur Teilnahme hatten, finden Sie hier einen groben Überblick über die behandelten Themen und weiterführende Links. Während dieser Artikel vorrangig die DBA-Themen der Veranstaltungsreihe behandelt, finden Sie Inhalte, die sich an Entwickler richten, in unserer deutschen APEX-Community.

Die Folien zur Veranstaltungsreihe stehen unter http://apex.oracle.com/folien zur Verfügung - geben Sie Editionen als Schlüsselwort ein.



Inhaltsverzeichnis
  1. Überblick über die Datenbankeditionen
  2. Funktionen, die Sie sich schon immer gewünscht haben - die Grundausstattung der Datenbank
  3. Ihre Daten gehören (nur) Ihnen - die Sicherheitsausstattung in der Enterprise Edition
  4. Sie läuft, und läuft, und läuft: Verfügbarkeit - Die Mobilitätsausstattung in der Enterprise Edition
  5. Höher, schneller, weiter: Performance - Die Sportausstattung in der Enterprise Edition

Überblick über die Datenbankeditionen


Abbildung 1: Die Oracle-Datenbankeditionen

Die Oracle-Datenbank kann in verschiedenen Editionen lizensiert werden. Am Anfang steht die kostenlose Variante OracleXE. Eine OracleXE-Datenbank darf kostenlos heruntergeladen und - auch produktiv - genutzt werden. Allerdings sind einige Limitierungen zu beachten - diese sind in der Dokumentation genau beschrieben. Weiterhin ist zu erwähnen, dass für OracleXE-Installationen kein Oracle-Support möglich ist - bei Fragen gibt das OTN-Forum Hilfestellung. Konsequenterweise können auch keine Patches aus Metalink heruntergeladen werden.

Die Standard Edition One ist als Lizenz für kleinere Systeme geeignet. Die Limitierungen der OracleXE-Datenbank fallen weg und es kann auch ein Wartungsvertrag geschlossen werden. Die Standard Edition One enthält alle Features der Standard-Edition, kann aber nur auf maximal 2 CPU-Sockets betrieben werden. Die Features im einzelnen aufzulisten, würde zu weit führen - Kapitel 2 gibt einen Überblick. Die Standard Edition der Oracle-Datenbank ist für "mittlere" Systeme vorgesehen und kann auf bis zu 4 Sockets betrieben werden. Eine Besonderheit der Standard Edition ist die Möglichkeit, ein RAC-Cluster aufzusetzen. Es gilt dabei die gleiche Obergrenze: Im gesamten Cluster dürfen maximal 4 Sockets vorhanden sein. Die Anzahl der tatsächlichen CPU-Kerne spielt bei den Standard-Editionen übrigens noch keine Rolle - erst bei der nachfolgend beschriebenen Enterprise Edition sind sie von Belang.

Die Enterprise Edition ist für unternehmensweise Anwendungen ausgelegt. Es gibt keine Limits hinsichtlich der Anzahl CPU oder Sockets, auf denen die Datenbank laufen darf. Neben allen Features der Standard Edition sind zahlreiche weitere Funktionen enthalten, die vor allem auf den verbesserten Betrieb von Datenbanken in großen Rechenzentren zielen. Eine (allerdings nicht vollständige) Liste von Datenbankfeatures mitsamt deren Zuordnung zu Standard- oder Enterprise Edition finden Sie in der Dokumentation "Licensing Guide".

Zurück zum Anfang des Artikels

Funktionen, die Sie sich schon immer gewünscht haben - die Grundausstattung der Datenbank

Die "Grundausstattung der Datenbank" findet sich in der Standard Edition und der Standard Edition One wieder. Die darin enthaltenen Funktionen richten sich vor allem an Entwickler - so sind fast alle (Ausnahmen bestätigen wie immer die Regel) SQL-Funktionen bereits in der Standard Edition verfügbar. Sie finden die Ausführungen zu diesem Themenbereich in dem korrespondierenden Artikel in der APEX-Community.

Zurück zum Anfang des Artikels

Ihre Daten gehören (nur) Ihnen - die Sicherheitsausstattung in der Enterprise Edition

Im Bereich der Sicherheit sind die fortgeschrittenen Funktionen Teil der Enterprise Edition; der Funktionsumfang der Standard-Edition im Bereich der Sicherheit beschränkt sich auf die Standard-Rechteverwaltung (GRANT, REVOKE) sowie das Standard-Benutzer und Rollenkonzept. Erfahren Sie Einzelheiten über die Entwicklerthemen Virtual Private Database und Fine Grained Auditing in dem aktuellen Artikel in der APEX-Community.

Rollen stehen sowohl in der Standard als auch in der Enterprise Edition als Mittel der Zugriffssteuerung zur Verfügung. Durch die Bündelung und Vergabe von Rechten an Rollen, die dann den unterschiedlichen Benutzern zugewiesen werden, können bewährte Konzepte wie zum Beispiel das in diesem Artikel beschriebene least privilege Prinzip effizient umgesetzt werden.

Eine Sonderform der Rollen bilden die sogenannten sicheren Anwendungsrollen, die in der Enterprise Edition zur Verfügung stehen. Eine sichere Anwendungsrolle bietet gegenüber den herkömmlichen Rollen in der Standard Edition eine verbesserte Sicherheit. Die Privilegien von sicheren Anwendungsrollen werden nur innerhalb der betreffenden Anwendung aktiviert und können daher schwerer missbraucht werden. Beliebige Überprüfungen, zum Beispiel nach Parametern der vom Benutzer verwendeten Umgebung, können innerhalb der Anwendung ausgeführt werden und so die Freigabe der Rolle beeinflussen. Weiterführende Informationen zum Thema sichere Anwendungsrollen finden Sie unter folgenden Links.

Zurück zum Anfang des Artikels

Sie läuft, und läuft, und läuft: Verfügbarkeit - Die Mobilitätsausstattung in der Enterprise Edition

Die Mobilitätsausstattung der Oracle Datenbank soll die Verfügbarkeit der Datenbank erhöhen. Dazu gehört nicht nur der Schutz vor menschlichen oder technischen Fehlern, sondern ebenso die Absicherung vor Katastrophen und die Durchführung von Wartungsarbeiten während des laufenden Betriebes. Dem Bereich Backup und Recovery kommt im Sinne der Verfügbarkeit eine besondere Bedeutung zu. Eine geeignete Backup und Recovery Strategie ist gewissermassen die Versicherung gegen Datenverluste. Die Problematik in der Realisierung einer Backup und Recovery Strategie liegt oftmals darin, dass sie keiner regelmäßigen Überprüfung unterliegt. Das bedeutet, dass das Backup der Datenbank im Allgemeinen nicht verifiziert wird und Datenbankadministratoren nicht ausreichend trainiert sind, im Fehlerfall die geeignete Recovery Methode zu wählen und umzusetzen. Dieser Umstand hat dazu geführt, dass immer mehr Automatismen in die Datenbankfunktionalität eingeflossen sind, um den Administrator zu unterstützen.

Der Recovery Manager (RMAN) hat sich mittlerweile im Oracle Umfeld als das Mittel der Wahl zur Durchführung des Backups und des Recoveries etabliert. In zwei Community Artikeln werden die Durchführung des Backups und Recoveries anschaulich beschrieben.


Funktionen der Enterprise Edition, wie das automatische Erstellen von Backup Kopien, helfen, zusätzliche Sicherheiten in die Backup und Recovery Strategie einzubauen. Über die Nutzung von Block Change Tracking und Backup Komprimierung kann das Volumen der Datensicherungen reduziert werden. Für die Durchführung des Recoveries bietet die Enterprise Edition besonders interessante Möglichkeiten, so kann ein einzelner Tablespace mit einem Kommando bis zu einem festgelegten Zeitstempel wiederhergestellt werden.
 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';
 
Mit dem automatischen Blockrecovery können einzelne korrupte Blöcke in einer Enterprise Edition repariert werden. Ein testweises Recovery ist ebenfalls möglich, ohne dass die zurückzuspielenden Datendateien verändert werden. Der Data Recovery Advisor arbeitet mit allen Editionen der Oracle Datenbank zusammen und empfiehlt die in der jeweiligen Edition nutzbare und sinnvolle Recovery Strategie. Die Funktionsweise ist in einem Community Artikel beschrieben worden.
Im Laufe des Lebens einer Datenbank ist es häufig erforderlich, insbesondere bei einer signifikanten Veränderung der Speichernutzung, der Datenverteilung oder der Nutzung von Objekten, Indizes oder Tabellen zu reorganisieren. Dieses geschieht in der Enterprise Edition durch das Package DBMS_REDEFINITION, das in dem folgenden Artikel beschrieben ist.
Der Oracle Enterprise Manager bietet als Bestandteil des kostenpflichtigen Tuning Packs eine grafische Oberfläche, die es auch ohne PL/SQL Kenntnisse möglich macht, einige Redefinitionsaufgaben online durchzuführen. Hierzu gehören die Verlagerung von Objekten in einen anderen Tablespace, der Neuaufbau fragmentierter Tabellen und Indizes oder die Anpassung von Storageparametern - andere, strukturelle Veränderungen erfordern jedoch den Einsatz der API DBMS_REDEFINITION in Skriptform.

Abbildung 2: DBMS_REDEFINITION mit dem Oracle Enterprise Manager

Die schon länger bekannte Flashback Query Funktionalität dient dazu, menschliche Fehler wie das versehentliche Löschen von Daten oder Strukturen innerhalb eines definierten Zeitfensters beheben zu können. In dem folgenden Artikel wird diese Funktionalität ausführlich behandelt.
Mit Data Guard, einem Bestandteil der Enterprise Edition, werden Standby Datenbanken erstellt und aktuell gehalten. Data Guard ist damit ein wertvoller Schutz vor Katastrophen, falls also ein kompletter Standort eines Rechenzentrums verloren geht. Das Prinzip von Data Guard basiert auf der Übertragung von RedoLogs auf den entfernten Standort, der diese im Recovery Modus anwendet und die Standby Datenbank auf diesem Wege aktuell hält. Das folgende Schaubild zeigt den prinzipellen Ablauf.

Abbildung 3: Standby Datenbank mit Data Guard

Das Aufsetzen einer Data Guard Umgebung ist skriptgesteuert sehr einfach zu realisieren und wird in dem Community Artikel
beschrieben. Data Guard kann durch den weniger versierten Datenbankadministrator im Oracle Enterprise Manager ohne zusätzliche Kosten administriert werden, das Erstellen einer Data Guard Konfiguration über die grafische Oberfläche ist als Bestandteil des Provisioning Pack jedoch lizenzpflichtig.

Abbildung 4: Oracle Data Guard mit dem Oracle Enterprise Manager

Einen Sonderfall der Standby Datenbank bildet die Snapshot Standby Datenbank. Da eine Standby Datenbank - außer mit der kostenpflichtigen Zusatzoption Active Data Guard - nicht lesend geöffnet werden kann, bietet die Snapshot Standby Datenbank hier eine Möglichkeit, die Snapshot Seite ohne Betriebseinschränkungen auf der Produktionsseite für eine kurze Zeit zu öffnen, um zum Beispiel Daten für ETL-Prozesse auslesen zu können oder Backups zu erstellen. Nach Abschluß der Arbeiten wird das aufgelaufene Volumen an RedoLogs nachgefahren, wonach die Standby Datenbank wieder als "normaler" sekundärer Spiegel zur Verfügung steht. Zu diesem Thema stehen eine Demo und ein Tutorial als weiterführende Informationen im Oracle Technology Network für Sie bereit.

Zurück zum Anfang des Artikels

Höher, schneller, weiter: Performance - Die Sportausstattung in der Enterprise Edition

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.
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:
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.
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. 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.
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.

Zurück zum Anfang des Artikels

Zurück zur Community-Seite