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

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);

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

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

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ü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

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

• 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

Redundant 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

RAC One Node

Updateable Installer und Checkpunkte

Integrierter Cluster Health Monitor

Knoten Fencing ohne Reboot

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