Patchset 11.2.0.2 ist verfügbar: 11 neue Features für DBAs
von DBA Community, ORACLE Deutschland GmbH

Seit Mitte September steht das neue Patchset 11.2.0.2 zum Download für die Plattformen Linux x86 und Solaris zur Verfügung. Über die normale Funktionalität eines Patchsets hinaus werden dieses Mal neue Features mitgeliefert zum Beispiel im Installer, im Testing-Bereich, in der Segment Verwaltung und im Bereich der Quality of Service Verwaltung. Um einen Vorgeschmack auf einige der neuen Features zu geben, haben wir im Folgenden eine Auswahl von 11 interessanten Neuerungen zusammengestellt. Bei den Beschreibungen handelt es sich um eine kurze Zusammenfassung der einzelnen Neuerungen, die nicht nach Prioritäten geordnet ist.

Wer mehr darüber erfahren möchte, kann sich auch in einem gesonderten Kapitel im New Features Guide informieren oder aber in einem unserer nächsten Tipps einige Neuigkeiten dazu erfahren.

Patchset 11.2.0.2: 11 neue Features

  1. Installation und Upgrade
  2. Speicherplatz freigeben mit TRUNCATE und ALTER TABLE
  3. Mehr Funktionen im Database Resource Manager
  4. Neues mit Oracle Text
  5. Automatische SQL Tuning Task mit DBMS_AUTO_SQLTUNE
  6. Rund um die Parallelisierung
  7. Quality of Service (QoS) Management mit Exadata
  8. Oracle Cluster File System - Cloud Edition
  9. Segment Creation on Demand
  10. Neuerungen im Grid Infrastruktur und RAC Umfeld
  11. Real Application Testing


Installation und Upgrade

Die Installation dieses Patchsets unterscheidet sich deutlich von der bisherigen Praxis und ist Ausdruck einer neuen Strategie von Oracle. Bislang wurde die Installation der Datenbanksoftware einer Version inklusive Patchset immer in mehreren Schritten durchgeführt: Zunächst musste die Basis-Installation vorgenommen werden (z.B. 10.2.0.1) und dann das Patchset (z.B. 10.2.0.4). Zusätzlich war unter Umständen noch die Installation weiterer Einzelpatches erforderlich. Dieses hat sich in 11.2.0.2 geändert: Das Patchset ist eine "full installation", also eine vollständig zu installierende Version. Sie können also mit einem Schritt diese "Patchset-Version" installieren und sparen damit viel Zeit ein.

Auch beim Upgrade von 11.2.0.1 auf 11.2.0.2 - dem "Einspielen des Patchsets" - macht sich diese Neuerung bemerkbar. Es wird nämlich ein Verfahren angewendet, welches die Downtime der Datenbank verringert und daher auch schon von vielen Kunden bislang manuell angewendet wurde: Statt die vorliegende 11.2.0.1-Installation "in-place" zu verändern, wird zunächst einmal eine neue Installation in einem zweiten ORACLE_HOME vorgenommen - also "out of place". Während dieser Installation ist die 11.2.0.1-Datenbank nicht betroffen und ganz normal verfügbar. Nachdem die Installation der 11.2.0.2 Software abgeschlossen ist, wird die 11.2.0.1-Datenbank heruntergefahren und mit den Executables des neuen 11.2.0.2-ORACLE_HOME wieder hochgefahren. Es schliessen sich die üblichen SQL-Skripte an, die das Data Dictionary aktualisieren. Wenn dieses abgeschlossen ist, kann die Datenbank wieder normal in Betrieb genommen werden. Nach dem Upgrade kann das 11.2.0.1-ORACLE_HOME gelöscht werden. Sie sollten natürlich darauf achten, dass keine Datenbankdateien (Datendateien, Kontrolldateien, Redo Log Dateien usw.) oder für die Datenbank wichtige Konfigurationsdateien in diesem alten ORACLE_HOME liegen. Besonders wichtig ist in diesem Zusammenhang auch die Sicherung von Wallets, die die Master Keys für die Verschlüsselung von Spalten oder Tablespaces enthalten. Gehen diese Wallets verloren, sind die verschlüsselten Daten eventuell auch komplett verloren.

Eine weitere Neuerung ist, dass der Installer nach aktuellen Einzelpatches suchen kann. Diese Einzelpatches können nach Erscheinen der 11.2.0.2 Software produziert worden sein und mussten bislang immer nach der Installation eingespielt werden. Der neue Installer kann diese Einzelpatches herunterladen und in die Installation der Software integrieren. Damit wird die Installation nochmals vereinfacht und auf einen Vorgang reduziert. Mehr dazu findet sich auch in der MOS Note 1189783.1.


Zurück zum Anfang des Artikels

Speicherplatz freigeben mit TRUNCATE und ALTER TABLE

Die Freigabe des Speicherplatz ist zum wiederholten Mal auch in 11.2.0.2 ein wichtiges Thema. Beispielsweise besitzt das TRUNCATE Kommando nun die zusätzliche Klausel DROP ALL STORAGE, die die vollständige Freigabe der Extents der Tabelle und der abhängigen Segmente durchführt. Das bedeutet, das auch die MINEXTENTS, die normalerweise beim TRUNCATE TABLE-Kommando (ohne Verwendung einer zusätzlichen Klausel) erhalten bleiben, damit vollständig gelöscht bzw. deallokiert werden.

SQL> TRUNCATE TABLE test DROP ALL STORAGE;
Table truncated.

SQL> SELECT extent_id, file_id, block_id, blocks FROM dba_extents WHERE segment_name='TEST';
no rows selected
Ein vollständiges Beispiel findet sich in folgendem Blog.

Auch das Kommando ALTER TABLE ist um diese Klausel erweitert worden, so dass auch hier der gesamte Speicherplatz freigegeben werden kann. Einige wenige Einschränkungen existieren noch und sind im SQL Reference Handbuch nachzulesen.


Zurück zum Anfang des Artikels

Mehr Funktionen im Database Resource Manager

Der Database Ressource Manager ist eine Technologie, die seit jeher ohne zusätzliche Installation zur Verfügung steht, um Datenbank-Ressourcen zu verwalten. Eine automatische Anwendung findet der Database Resource Manager übrigens ab 10g: Sobald die sogenannten Maintenance Task Jobs im Default Maintenance Window Statistiken berechnen oder Segment Advisor Aufgaben durchgeführen, wird der Plan DEFAULT_PLAN aktiviert .

Neu in 11.2.0.2 ist, dass die CPU Ressourcen beim Erzeugen einer Direktive durch das neue Attribut MAX_UTILIZATION_LIMIT als "feste" Obergrenze angegeben werden können. So können Ressourcen für bestimmte Applikationen oder Maintenance Windows limitiert werden.

execute DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
                                          plan                  => 'MAXCPU_PLAN',
                                          group_or_subplan      => 'OTHER_GROUPS',
                                          comment               => 'Limitierung von OTHER_GROUPS auf 80',
                                          max_utilization_limit => 80);
Mit Einführung von Oracle Database 11g Release 2 wurde über die Database Resource Manager Technologie und die Einstellung des Parameters CPU_COUNT das sogenannte "Instance Caging" ermöglicht. Das Überwachen dieser Funktion ist nun im neuen Patchset entweder über die Enterprise Manager Konsole oder erweiterte Data Dictionary Views möglich.
SQL> SELECT name, window_name, instance_caging,
     to_char(start_time, 'DD-mon HH24:mi') start_time,
     to_char(end_time, 'dd-mon hh24:mi') end_time
     FROM v$rsrc_plan_history;

NAME                           WINDOW_NAME     INS START_TIME      END_TIME
------------------------------ --------------- --- --------------- ------------
PLAN2                                          ON  05-oct 22:16    05-oct 22:16
DEFAULT_MAINTENANCE_PLAN       TUESDAY_WINDOW  ON  05-oct 22:16    05-oct 22:16
Zusätzliche Erweiterungen im Bereich Parallelisierung mit Parallel Statement Queueing oder die Einführung des Quality of Service Management sind ebenfalls über den Database Resource Manager implementiert. Dazu erfahren Sie mehr in den folgenden Abschnitten.


Zurück zum Anfang des Artikels

Neues mit Oracle Text

Oracle Text ist seit jeher die Text-Abfrage und Analyse Engine der Datenbank, die automatisch mit jeder Edition der Datenbank zur Verfügung steht. Eine Weiterentwicklung findet wie bei allen Datenbank-Technologien normalerweise in jedem neuen Release statt. Da das Basis Release 11.2 keine neuen Features für die Text-Engine enthielt, wurde dies im Patchset 11.2.0.2 nachgeholt.

So kann der Nutzer von Oracle Text mit folgenden neuen Features arbeiten:

  • Name Search
  • Result Set Interface
  • Entity Extraction and Identification
Besonders das Feature Name Search dürfte für viele Anwender nützlich sein, da es beispielsweise die Suche nach Namen, die häufig falsch geschrieben werden, erleichtern kann. Die Idee beim Result Set Interface Feature ist, vielfältige komplexe Abfragen für Ergebnismengen im Textumfeld, auf einen einzigen SQL Call zu reduzieren und damit Ressourcen zu sparen und die Performance zu erhöhen. Entity Extraction ermöglicht eine strukturierte und klassifizierte Sichtweise auf Dokumente. Jedes Vorkommen eines Objekts (wie Orte, Namen usw.) in einem Dokument wird als sogenannte Entity Extraction ge-tagged. So kann beispielsweise herausgefunden werden, welche Namen am meisten verwendet wurden.

Ausführliche Informationen zu vielen Oracle Text Funktionen in deutscher Sprache finden Sie im Oracle Text Blog (speziell Name Search Blog bzw. Result Set Interface Blog ).


Zurück zum Anfang des Artikels

Automatische SQL Tuning Task mit DBMS_AUTO_SQLTUNE

Das Package DBMS_AUTO_SQLTUNE ist ein neues Interface zur Verwaltung der automatischen SQL Tuning Tasks. Es ermöglicht das Konfigurieren und Einstellen der SQL Tuning Task Parameter und das Erzeugen von SQL Tuning Reports.

execute DBMS_AUTO_SQLTUNE.SET_AUTO_TUNING_TASK_PARAMETER(
                                                            parameter => 'ACCEPT_SQL_PROFILES', 
                                                            value     => 'TRUE');
SQL> SELECT parameter_name, parameter_value, description 
     FROM dba_advisor_parameters WHERE parameter_name like '%ACCEPT%'

PARAMETER_NAME                 PARAMETER_VALUE
------------------------------ --------------------
DESCRIPTION
--------------------------------------------------------------------------------
ACCEPT_SQL_PROFILES            TRUE
TRUE if SQL Profiles should be created by the task, FALSE otherwise
Zur Nutzung von DBMS_AUTO_SQLTUNE ist die DBA Rolle erforderlich.

Aus Kompatibilitätsgründen ist es auch weiterhin möglich, das Package DBMS_SQLTUNE für diese Aufgaben einzusetzen.


Zurück zum Anfang des Artikels

Rund um die Parallelisierung

Seit Oracle 11g Release 2 können parallele Operationen automatisiert (auch AUTO DOP (kurz für Degree Of Parallelism) genannt) und sogar im Memory ablaufen. Diese Funktionen werden im Wesentlichen über folgende Parameter gesteuert:

  • PARALLEL_DEGREE_POLICY
  • PARALLEL_MIN_TIME_THRESHOLD
  • PARALLEL_SERVER_TARGET
Mit Einführung des Patchsets und Setzen von PARALLEL_DEGREE_POLICY auf AUTO, wird der Parallelisierungsgrad nun auch über die I/O Charakteristik bestimmt. Notwendige Voraussetzung damit AUTO DOP in 11.2.0.2 genutzt werden kann, ist das Vorhandensein von I/O Kalbrierungsstatistiken, die über das Package DBMS_RESOURCE_MANAGER.CALIBRATE_IO bestimmt werden (siehe auch Tipp). Falls diese Statistiken fehlen, enthält die EXPLAIN PLAN Ausgabe folgenden Hinweis im "Note"-Bereich: "automatic DOP: skipped because of IO calibrate statistics are missing". Das bedeutet, AUTO DOP wird nicht verwendet!

Standardmässig werden die parallelen Statements nach dem FIFO (first in, first out) Prinzip bearbeitet. Neue Funktionen im Database Resource Manager erlauben nun in 11.2.0.2 über einen CPU Resource Plan die Priorität beim De-queueing zu bestimmen. So können beispielsweise parallele Statements mit hoher Priorität eher verarbeitet werden. Das Monitoring der Queue wird dabei über die Database Resource Manager Ansicht im Enterprise Manager Konsole möglich.


Für eine größere Ansicht auf das Bild klicken

Weitere neue Funktionen erlauben es, ein Queue-Timeout über PARALLEL_QUEUE_TIMEOUT und die Parallelisierungsbegrenzung in Prozent über PARALLEL_TARGET_PERCENTAGE pro Consumer Group einzustellen.
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
                          plan                       =>'REPORTS_PLAN', 
                          group_or_subplan           =>'LONG_SQL_GROUP', 
                          comment                    =>'Directive fuer medium-running Abfragen',
                          mgmt_p2                    => 10,
                          parallel_target_percentage => 50,
                          parallel_queue_timeout     => 14400);


Zurück zum Anfang des Artikels

Quality of Service (kurz QoS) Management mit Exadata

QoS ist die logische Weiterentwicklung der in Oracle 11g Release 2 eingeführten regelbasierten Server Pool Technologie im Grid Infrastruktur und Datenbank Umfeld. Ein Server Pool gibt dabei an, welches die Unter- bzw. Obergrenze der Serveranzahl im Cluster ist, auf denen ein bestimmer Datenbank Service laufen soll. Hierbei war vor der Einführung von QoS die Anzahl der verfügbaren Server und nicht die Performance ausschlaggebend. Eine Rekonfiguration des Clusters wurde automatisch nur durch das Hinzufügen von Servern bzw. den Ausfall eines Servers veranlasst.

Mit QoS kann nun der Cluster auch schon bei Performance-Engpässen eine solche Rekonfiguration vorschlagen. Dabei definiert man in der graphischen Oberfläche im Enterprise Manager das vorgegebene Service Level Ziel (auch SLA für Service Level Agreement), welches für die Datenbankperformance erreicht werden sollte. Wird dieses SLA nicht eingehalten, kann der Cluster ein reines "Umverteilen" der CPU Power innerhalb des Pools mit Hilfe eines speziellen Database Resource Manager Plans veranlassen oder, wenn dies nicht ausreicht, ein Verschieben eines Knotens aus einem anderem Server Pool vorschlagen.

Diese Funktionalität ist im Moment auf Exadata beschränkt und kann nur dort als separate Option lizensiert werden.


Für eine größere Ansicht auf das Bild klicken


Zurück zum Anfang des Artikels

Oracle Cluster File System - Cloud Edition

Das Oracle Cluster File System - Cloud Edition ist die Weiterführung des ASM Cluster File Systems (kurz ACFS) und steht als eigenständig zu lizenzierendes Produkt zur Verfügung. Es besteht aus folgenden Komponenten:

  • Automatic Storage Management (ASM)
  • ASM Dynamic Volume Manager (ADVM)
  • ASM Cluster File System (ACFS)
  • Oracle Clusterware für den Betrieb von ASM und ACFS
Besonders die Funktionalitäten des ACFS mit 11.2.0.2 wurden erheblich erweitert und sind nicht mehr nur auf die Oracle Datenbank Umgebung begrenzt. So stellt das ACFS neben der Clusterfunktionalität und der Copy-On-Write Snapshot Technologie, die auf allen Plattformen verfügbar sind, auf Linux (Stand November 2010) einige zusätzliche Funktionen zur Verfügung:
  • Replikation: Ein Filesystem kann mit einem anderen ACFS z.B. im Standby Rechenzentrum repliziert werden. Dies eignet sich optimal um Daten, die auf einem externen Filesystem liegen, in einer Data Guard Umgebung gleich mit zu synchronisieren.
  • Verschlüsselung: Nicht nur für Datenbanken, auch für Filesysteme wird das Thema Verschlüsselung immer wichtiger. Daten sollten nicht mehr im Klartext auf dem Storage liegen, damit beim Austausch einer Platte in keinem Fall Daten ausserhalb des Unternehmens gelangen.
  • Rollenbasiertes Zugriffskonzept: Das neue Filesystem bietet die technischen Möglichkeiten, die Zugriffe nicht über herkömmliche Betriebssystemmittel sondern über Oracle Database Vault Methoden wie Realms und definierte Regeln zu steuern. So kann beispielsweise auch ein root User nicht mehr auf Files zugreifen, da diese durch einen zweiten Zugriffslayer geschützt sind.
  • File Tagging: Möchte man für ausgewählte Dateien Eigenschaften definieren, ist dies unter Zuhilfenahme der Extended Attribute von Dateien, die man mit Hilfe des ACFS File Taggings festlegt, möglich. So kann man ein Set von Dateien bzw. Ordnern definieren, die repliziert bzw. verschlüsselt werden, unabhängig von der Lage der Dateien.
  • Hinweis: Oracle Cluster File System - Cloud Edition sollte nicht mit dem ehemaligen Oracle Cluster File System (kurz OCFS2) verwechselt werden!


Zurück zum Anfang des Artikels

Segment Creation on Demand

Die mit der 11g Release 2 eingeführte deferred segment creation Technologie funktioniert nun auch für partitionierte Tabellen. Standardmäßig ist diese Funktion über den Initialisierungsparameter DEFERRED_SEGMENT_CREATION bereits aktiviert, kann jedoch nach Bedarf in der Storage-Klausel des betreffenden Objektes oder auch über einen ALTER SESSION / ALTER SYSTEM Befehl individuell gesetzt werden. Da zusätzlich die Grösse des ersten Extents (auch First Extent Size) für partitionierte Tabellen in 11.2.0.2 von 64 KB auf 8 MB angehoben worden ist, kommt der deferred segment creation besondere Bedeutung zu.

Da dieses Feature in alten Versionen noch nicht zur Verfügung stand und somit Tabellen mit leeren Extents existieren können, ergibt sich oft die Anforderung diese Extents freizugeben, um Speicherplatz zu sparen. Zum Löschen dieser leeren Extents steht die neue Prozedur DROP_EMPTY_SEGMENTS des Package DBMS_SPACE_ADMIN zur Verfügung. Umgekehrt lässt sich Speicherplatz mit der Prozedur DBMS_SPACE_ADMIN.MATERIALIZE_DEFERRED_SEGMENTS auch wiederherstellen .


Zurück zum Anfang des Artikels

Neuerungen im Grid Infrastruktur und RAC Umfeld

Mit 11.2.0.2 hat sich auch im Grid Infrastruktur und im RAC Umfeld viel getan. Eine der wichtigsten Veränderungen gibt es beim Interconnect, da sich die Voraussetzungen an die Installation und den Upgrade der Grid Infrastruktur geändert haben. Im folgenden sind die Änderungen kurz zusammengefasst:

Redundant Interconnect

Die Grid Infrastruktur kann mit 11.2.0.2 das Failover und Loadbalancing des RAC Interconnect übernehmen und stellt damit eine bessere Alternative als das Betriebssystem eigene Bonding/Teaming dar. Dazu legt Oracle Clusterware für die Interfaces im Interconnect eigene IP Adressen an - ähnlich der VIP Adressen im Public Netz. Diese Adressen werden dabei aus dem "Link Local" Adressbereich genommen (169.254.X.X) und über Multicast im Bereich 230.0.1.X ausgehandelt. Da sich diese Funktionalität nicht abschalten lässt und auch bei Clustern mit nur einer Netzwerkkarte bzw. mit bestehenden Bonding Lösungen aktiv ist, muss die Multicast-Funktionalität (siehe auch MOS Note 1212703.1) und die Kommunikation über die neuen 169.254 IP Adressen erlaubt sein und funktionieren.

ASM und eine 11.2.0.2 Datenbank erben diese Informationen von der Clusterware und kommunizieren dann über diesen redundanten Interconnect.
SQL> SELECT * FROM v$cluster_interconnects;

NAME            IP_ADDRESS       IS_ SOURCE
--------------- ---------------- --- -------------------------------
eth1:1          169.254.19.176   NO
eth2:1          169.254.229.181  NO
Sollten im Cluster noch ältere Datenbanken (10.2 oder 11.1) laufen, sollte weiterhin ein Bonding verwendet werden.

RAC One Node

RAC One Node ist mit 11.2.0.2 auf allen Plattformen verfügbar, auf denen auch RAC zertifiziert ist. Die komplette Administration und das Management ist dabei in die vorhandenen Tools, wie dem DBCA und dem srvctl integriert - es gibt keine separaten Skripte mehr. Zusätzlich wurde auch die erlaubte Zeit für ein Online Database Relocation (neuer Name für OMotion) von 30 Minuten auf 12 Stunden erhöht, damit weitere Applikationen von diesem Feature profitieren können.

Updateable Installer und Checkpunkte

Der Oracle Universal Installer kann vor einer Installation neue Packages direkt von MySupport laden und damit bekannte Schwachstellen bei der Installation im Vorfeld beheben. Zusätzlich gibt es sogenannte Checkpunkte beim root.sh Skript der Clusterinstallation, um ein abgebrochenes root- Skript neu aufzurufen.

Integrierter Cluster Health Monitor

Der Cluster Health Monitor wird nun automatisch mit der Oracle Clusterware installiert und sammelt Betriebssysteminformationen zur Diagnose des Clusters. Installiert wird allerdings nur die Serverkomponente nicht die graphische Oberfläche. Diese ist weiterhin auf folgender Webseite erhältlich.

Knoten Fencing ohne Reboot

Bei Problemen im Cluster muss der fehlerhafte Knoten, aus dem Cluster herauskonfiguriert werden. Dieser Vorgang wird auch als Fencing bezeichnet und wurde in der Vergangenheit immer durch einen Reboot des Knoten bewerkstelligt. In 11.2.0.2 wird in den meisten Fällen (z.B. Interconnect Ausfall) zuerst versucht nur die Clusterware auf dem Rechner durchzustarten und nicht gleich den ganzen Knoten. Damit können nun Fehlerfälle im Cluster schneller und einfacher behoben und analysiert werden.


Zurück zum Anfang des Artikels

Real Application Testing

Seit Oracle Database 11g besitzt die Datenbank ein Testing Werkzeug - die sogenannte Real Application Testing Option, die aus den beiden sich ergänzenden Komponenten SQL Performance Analyzer (SPA) und Database Replay (DB Replay) besteht. SPA wird dabei bei detaillierten SQL Statement Analysen eingesetzt, Database Replay hingegen testet die Performance des gesamten Datenbank Workloads.

Im Basis Release 11g Release 2 gab es die ersten Neuerungen z.B. mit der Einführung des Replay Filters und der Aufhebung von gewissen Einschränkungen beim Capture. Auch in 11.2.0.2 sind beide Komponenten erweitert worden. Dabei liegt der Fokus auf der Vereinfachung und Erweiterung der Komponenten. So hilft beispielsweise ein neues Analyse Werkzeug - der Workload Analyzer - den Capture Workload vorab zu analysieren, um gegebenenfalls die Replay-Einstellungen anzupassen. Ausserdem können SQL Tuning Sets automatisch während des Replays generiert werden und unterstützen damit die Integration von SPA in Database Replay.


Für eine größere Ansicht auf das Bild klicken

Im Folgenden sind die wichtigsten Funktionen pro Komponente kurz zusammengefasst:

  • Zusätzlicher SPA Workflow für Optimizer Statistics Refresh (siehe Screenshot) in der Database Enterprise Manager Konsole
  • Vollständige Unterstützung von SPA in Active Data Guard
  • Integration von SPA im DB Replay
  • Workload Analyse beim Preprocessing im DB Replay


Zurück zum Anfang des Artikels

Zurück zur Community-Seite