Logo Oracle Deutschland   DBA Community  -  Juni 2013
Oracle Database 12c ist verfügbar: 12 neue Features für DBAs
von Ulrike Schwinn, Heinz-Wilhelm Fabry, Ralf Durben, Sebastian Solbach ORACLE Deutschland B.V. & Co.KG

Seit 25.Juni 2013 steht das neue Datenbank Release Oracle Database 12c für die Plattformen Linux x86 und Solaris (Sparc64 und x86) zum Download zur Verfügung.
Um einen Vorgeschmack auf einige der neuen Features zu geben, haben wir im Folgenden eine Auswahl von 12 interessanten Neuerungen zusammengestellt. Bei den Beschreibungen handelt es sich um eine kurze Zusammenfassung der einzelnen Neuerungen, die nicht nach Prioritäten geordnet ist. In der APEX Community finden Sie parallel hierzu eine Übersicht über interessante Neuerungen für Entwickler.

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. Alle Handbücher sind übrigens über folgenden Link zu finden und geben detaillierte Auskunft über die genaue Syntax und die Einschränkungen der einzelnen Features.

Oracle Database 12c neue Features

  1. Multitenant Database
  2. Data Redaction
  3. Weniger Aufwand bei Migrationen
  4. Information Lifecycle Management
  5. Datenbank Security Erweiterungen
  6. Application Continuity
  7. Manageability
  8. Far Sync Standby
  9. Performance Features
  10. Online Operationen
  11. RMAN Erweiterungen
  12. Partitionierung


Wichtiger Hinweis: Wir haben keine Lizenzhinweise in den Tipp eingefügt, sondern uns nur auf die Funktionalität der neuen Features beschränkt. Detaillierte Informationen zur Lizenzierung der neuen Features finden Sie in Oracle Database Licensing Information 12c Release 1 (12.1)

Multitenant Database

Ein Oracle Datenbanksystem bis zur Version 11g verwendet alle Ressourcen exklusiv. So besteht es immer aus einer Kombination von Datenbank und Instanz, wobei im Fall von Real Application Clusters (RAC) mehrere Instanzen für eine Datenbank verwendet werden. Eine Instanz besteht dabei aus Hauptspeicher (zum Beispiel für die SGA) und Prozessen (zum Beispiel die Hintergrundprozesse SMON, PMON, DBWR, ...). Für jede Datenbank wird ein vollständiges Data Dictionary gespeichert und auch alle Typen von Datenbankdateien werden für jede Datenbank exklusiv angelegt. Jede Datenbank ist somit ein "Komplettpaket". In der heutigen Zeit flexibler Nutzung von Ressourcen hat dieses Modell aber auch Nachteile. So wird zur Laufzeit der Datenbank für deren Instanz Hauptspeicher allokiert, auch wenn dieser gar nicht gebraucht wird. Auch das Data Dictionary wird mehrfach auf einem Server gespeichert, sobald sich auf diesem Server mehrere Datenbanken befinden. Wenn also etwa eine Mandantenfähigkeit über die Trennung von Datenbanken pro Mandanten realisiert werden soll, ergibt sich ein erheblicher Zusatzaufwand.

Ab der Version 12c der Oracle Datenbank gibt es dazu die Alternative, dass sich mehrere Datenbanken eine Instanz und andere Ressourcen teilen und diese Ressourcennutzung auch über mehrere Datenbanken hinweg kontrolliert werden kann. Dieses neue Konzept wird "Multitenant Database" genannt und findet sich in der SQL Syntax unter "Pluggable Database" wieder. Dabei gibt es folgende Neuerungen:

  • Jede Einzeldatenbank (genannt Pluggable Database - PDB) läuft in einer globalen Containerdatenbank (genannt Container Database - CDB). Die CDB stellt eine globale Instanz, Datenbankdateien und den statischen Teil des Data Dictionaries bereit.
  • Jede PDB kann jederzeit von einer CDB in eine andere CDB verschoben werden (unplug und plug).
  • Jede PDB kann dadurch gepatcht oder migriert werden, dass sie von der bisherigen CDB in ein neue bereits gepatchte bzw. migrierte CDB verschoben wird.
  • Jede PDB ist funktional in sich abgeschlossen. Datenbankbenutzer, die innerhalb der PDB definiert sind, haben keinen Zugriff auf PDBs, die in der gleichen CDB betrieben werden.
  • In der CDB können Administratoren definiert werden, die Zugriff auf alle oder auch nur auf ausgewählte PDBs haben, die in dieser CDB betrieben werden.
Aus diesen Neuerungen ergeben sich folgende Vorteile:
  • Konsolidierung
    Sie können mit dem neuen Konzept eine Konsolidierung mit dem Ziel der Reduzierung von Ressourcennutzung betreiben, ohne die Eigenständigkeit der einzelnen Datenbanken anzutasten. Die PDBs sind funktional gesehen vollwertige Datenbanken, nutzen aber wichtige Ressourcen, wie Memory, Storage und CPU gemeinsam.
  • Mandantenfähigkeit
    Eine Anwendung kann dadurch derart mandantenfähig betrieben werden, dass für jeden Mandanten eine eigene Datenbank unter dem Dach eines gemeinsamen Containers betrieben wird, also mit gemeinsamer Nutzung wichtiger Ressourcen. Hiervon leitet sich auch der Begriff "Multitenant Database" ab.
  • Cloudfähigkeit
    Schnelle Bereitstellung und Mobilität von Services ist eine wichtige Anforderung für Cloud-Umgebungen. Mit Pluggable Databases wird dieses perfekt adressiert: Jede CDB stellt eine Seed Datenbank bereit, die zur Erstellung einer PDB herangezogen werden kann. Auch kann eine bereits existierende PDB geclont werden. Beides ist durch spezielle interne Verfahren sehr schnell, sodass eine neue Datenbank einfach und schnell bereitgestellt werden kann. Die Mobilität einer Datenbank ist mit dem einfachen Verschieben einer PDB von einer CDB zu einer anderen CDB perfekt umgesetzt.
  • Patchen / Migrieren
    Diese Wartungsarbeiten nehmen in der klassischen Architektur typischerweise recht viel Zeit und Arbeit in Anspruch. In der neuen Architektur wird eine neue CDB mit dem neuen Softwarestand erstellt. Durch das Verschieben einer PDB von der alten CDB in die neue CDB wird die Datenbank automatisch aktualisiert.
  • Verwaltung von Ressourcen
    Der in der Oracle Datenbank bekannte Database Resource Manager arbeitet innerhalb einer CDB über alle dort betriebenen PDBs hinweg, also datenbankübergeifend innerhalb einer CDB. Das ist ein großer Fortschritt im Vergleich zur bislang datenbankisolierten Arbeitsweise.
  • Data Guard
    Eine Data Guard Umgebung wird auf der Ebene der CDB erstellt, unabhängig von der Anzahl der dort betriebenen PDBs. Dadurch verringert sich der Administrationsaufwand enorm.
  • Backup & Recovery
    Ein Backup wird auf der Ebene der CDB erstellt und umfasst alle Sicherungsdaten aller dort betriebenen PDBs. Die Sicherung aller PDBs in einer CDB ist also nur ein einzelner Arbeitsvorgang. Das Backup kann für die Wiederherstellung (Recovery) jeder einzelnen PDB, sogar für ein Point-in-Time Recovery, verwendet werden.


Zurück zum Anfang des Artikels

Data Redaction

Jeder kennt Data Redaction aus eigener Erfahrung: Auf dem Kassenbeleg einer Kreditkartenzahlung sind nicht alle Ziffern der Kreditkartennummer ausgedruckt, sondern nur die letzten Ziffern dieser Nummer. Die übrigen Ziffern sind zum Beispiel durch * unkenntlich gemacht. Bisher wird dieses unkenntlich Machen in der Anwendung programmiert, und zwar in jeder einzelnen Anwendung, die auf die Kreditkartennummer zugreift. Mit Oracle Data Redaction kann das unkenntlich Machen nun direkt in der Tabelle bei den Daten hinterlegt werden und gilt damit für jeden Zugriff, der zu einer Bildschirm- oder Druckausgabe führt. Die Kreditkartennummer kann dennoch zum Beispiel in WHERE Bedingungen nach wie vor verwendet werden. Auf Spalten, die mit Data Redaction unkenntlich gemacht werden, können auch nach wie vor Berechnungen durchgeführt oder Indizes angelegt werden.

Das Package DBMS_REDACT, das für alle Redact Operationen verwendet wird, stellt vier verschiedene Varianten des unkenntlich Machens zur Verfügung

  • FULL: Der gesamte Wert wird durch eine definierbare Konstante ersetzt.
  • PARTIAL: Ein Teil des Werts wird durch eine definierbare Zeichenkette ersetzt.
  • RANDOM: Der gesamte Wert wird durch einen Zufallswert ersetzt.
  • REGEXP: Der Wert wird mit Hilfe einer Formatmaske (in Form eines regulären Ausdrucks) durchsucht. Wird eine Zeichenkette gefunden, die der Formatmaske entspricht, wird diese Zeichenkette durch einen definierbaren Wert ersetzt.
Das Beispiel soll hier nicht umfassend erläutert werden, sondern nur zeigen, wie bei der Ausgabe die Angestelltennummer EMPNO entsprechend den Angaben zum Parameter FUNCTION_PARAMETER unkenntlich gemacht wird. Hier ersetzt die Ziffer 9 die tatsächlichen Ziffern von der zweiten bis zur vierten Stelle. Der in EXPRESSION verwendete Ausdruck '1 = 1' ist TRUE und bewirkt so, dass das unkenntlich Machen immer ausgeführt wird. Denkbar wäre aber auch, das unkenntlich Machen zum Beispiel von Werten aus der Umgebung des jeweiligen Benutzers abhängig zu machen. 
BEGIN
DBMS_REDACT.ADD_POLICY(
object_schema       => 'scott',
object_name         => 'emp',
column_name         => 'empno',
policy_name         => 'empno_redact',
function_type       =>  DBMS_REDACT.PARTIAL,
function_parameters => '9,2,4',
expression          => '1=1');
END;
/

-- Als Benutzer SCOTT

SQL> SELECT * FROM emp WHERE empno > 7800;

 EMPNO ENAME      JOB          MGR HIREDATE         SAL       COMM     DEPTNO
------ ---------- --------- ------ --------- ---------- ---------- ----------
  7999 KING       PRESIDENT        17-NOV-81       5000                    10
  7999 TURNER     SALESMAN    7698 08-SEP-81       1500          0         30
  7999 ADAMS      CLERK       7788 12-JAN-83       1100                    20
  7999 JAMES      CLERK       7698 03-DEC-81        950                    30
  7999 FORD       ANALYST     7566 03-DEC-81       3000                    20
  7999 MILLER     CLERK       7782 23-JAN-82       1300                    10


Zurück zum Anfang des Artikels

Weniger Aufwand bei Migrationen

Die folgenden Features können eine wichtige Rolle bei Migrationen von anderen Datenbanken hin zu 12c spielen. Die neuen Funktionen gewährleisten beispielsweise eine unveränderte Übernahme von bestimmten SQL Statements oder die Einhaltung des ANSI SQL Standards und sind sicherlich auch interessant für Datenbank Entwickler.

Das erste Feature in dieser Kategorie demonstriert eine neue Möglichkeit, Default Werte zu definieren und zu nutzen. So können automatisch beim INSERT Default Werte zugewiesen werden, die im CREATE TABLE Statement vorab mit dem Schlüsselwort BY DEFAULT definiert worden sind. Diese Werte sind dann entweder explizit definiert oder stammen aus einer Sequence. Die Sequence Spalte kann dabei direkt im CREATE TABLE Kommando über das Schlüsselwort IDENTITY definiert werden. (Wenn nichts weiter definiert ist, startet die Aufzählung bei 1.) In folgendem Beispiel verwenden wir die START WITH und INCREMENT BY Syntax zur genaueren Spezifizierung der Sequence. 

SQL> CREATE TABLE null_id_test (id NUMBER GENERATED BY DEFAULT ON NULL 
     AS IDENTITY (START WITH 100 INCREMENT BY 10));

SQL> INSERT INTO null_id_test VALUES (null);

SQL> SELECT * FROM null_id_test;

ID
---
100
Eine Erweiterung des SELECT Kommandos unterstützt nun die Begrenzung der Zeilen (Row Limit) in der Abfrage. Mit der neuen Syntax FETCH FIRST n ROWS ONLY bzw. FETCH NEXT n ROWS ONLY können beispielsweise die ersten (Top N Queries) bzw. nächsten n Zeilen ausgegeben werden. Die Klausel OFFSET n ROWS erlaubt zusätzlich einen Abstand von n Zeilen. Zur Ausführung werden dabei intern Window Funktionen verwendet. 
SQL> SELECT employee_id, first_name
     FROM hr.employees e
     ORDER BY first_name
     FETCH FIRST 5 ROWS ONLY;
  
EMPLOYEE_ID FIRST_NAME
----------- --------------------
        121 Adam
        196 Alana
        147 Alberto
        103 Alexander
        115 Alexander

SQL> SELECT employee_id, first_name 
     FROM hr.employees e
     ORDER BY first_name 
     OFFSET 3 ROWS FETCH NEXT 2 ROWS ONLY;

EMPLOYEE_ID FIRST_NAME
----------- --------------------
        103 Alexander
        115 Alexander
Im Datentyp Umfeld können VARCHAR2, NVARCHAR2 und RAW ab 12c Inhalte speichern, die das Limit von 4000 Bytes bzw. 2000 Bytes für RAW überschreiten - die sogenannten extended data types . Die neue Begrenzung liegt bei 32767 Bytes. Dazu ist es allerdings notwendig, den neuen Initialisierungsparameter MAX_STRING_SIZE auf den Wert EXTENDED zu ändern, die Datenbank im UPGRADE Mode zu öffnen und das Skript utl32k.sql aus dem Verzeichnis $ORACLE_HOME/rdbms/admin zu starten. Eine Änderung auf den Wert STANDARD (Defaulteinstellung) ist danach nicht mehr möglich. 
SQL> show parameter MAX_STRING_SIZE

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
max_string_size                      string      EXTENDED

SQL> ALTER TABLE products_copy MODIFY prod_desc VARCHAR2(8000);
Table altered.

SQL> SELECT max(length(prod_desc)) FROM products_copy;

MAX(LENGTH(PROD_DESC))
----------------------
                 22848
Ab 12c ändert sich das Verhalten für die Speicherung von LOBs. Standardmässig wird nun die SecureFile statt der BasicFile Speicherung verwendet. Kontrollieren lässt sich dieses Verhalten wie in 11g mit dem Parameter DB_SECUREFILE. Der Default ist nun PREFERRED.


Zurück zum Anfang des Artikels

Information Lifecycle Management

Information Lifecycle Management (kurz ILM) konnte schon in 11g über Funktionen wie Komprimierung, Partitionierung, Verlagerung der Daten in einen anderen Tablespace und VPD realisiert werden. Ziel ist dabei, die Daten über den gesamten "Lebenszyklus" im Hinblick auf optimale Performance, Speicherplatznutzung und gesicherten Zugriff der Daten zu verwalten. Dabei ist es Aufgabe des DBAs, die Daten zu klassifizieren und entsprechende Policies bzw. Aktionen meist manuell zu implementieren.

In Oracle Database 12c sind die ILM Lösungen in den Datenbank Kern intergriert. Daten können nun beispielsweise automatisch klassifiziert werden. Applikationsspezifische Regeln (auch Policies) sorgen dann für automatische Datenverlagerung (auch Data Movement bzw.Storage Tiering) innerhalb der Datenbank oder die Komprimierung von Daten falls bestimmte Kriterien erfüllt sind. Die ILM Lösungen umfassen dabei folgende Schlüsselfunktionen:

  • Datenklassifizierung über die sogenannte Heat Map
  • Automatische Daten Optimierung (auch ADO)
  • In-Database Archivierung
Die sogenannte Heat Map dient der Datenklassifizierung und ist Voraussetzung für die automatische Daten Optimierung - kann aber auch ohne die Verwendung von Policies eingesetzt werden. Dabei werden Aktivitäten wie Schreib- bzw. Lesezugriffe auf Segment und Block Ebene aufgezeichnet und zur Verfügung gestellt. Folgende Fragen können damit beantwortet werden: Welche Tabellen oder Partitionen wurden zuletzt verwendet? Welche Art des Zugriffs wurde auf die Segmente durchgeführt? Fand ein Lookup oder einen Full Table Scan statt? Wann wurde ein Block zuletzt verändert? Die Idee dahinter ist, einen möglichst umfassenden Überblick über die Zugriffe auf die Daten zu geben (Cold/Hot Data). Informationen darüber - die sogenannte Heat Map - finden sich dann in Views wie V$HEAT_MAP_SEGMENT, DBA_HEAT_MAP_SEGMENT etc. oder über das Package DBMS_ILM bzw. DBMS_ILM_ADMIN. Eingeschaltet wird das Heat Map Feature in der Datenbank über den neuen dynamischen Initialisierungsparameter HEAT_MAP. Die Defaulteinstellung ist dabei OFF.

Folgendes Beispiel zeigt die aktuellen Aktivitäten in Zusammenhang mit der Tabelle PRODUCTS_COPY. 
-- Ausschnitt aus dem Heat Map Listing V$HEAT_MAP_SEGMENT
SQL> SELECT object_name, track_time, segment_write write, segment_read read, full_scan, lookup_scan 
     FROM v$heat_map_segment;

OBJECT_NAME   TRACK_TIME WRITE READ FULL_SCAN LOOKUP_SCAN
------------- ---------- ----- ---- --------- -----------
PRODUCTS_COPY 26-JUN-13  NO    NO   YES       NO
PRODUCTS_PK   26-JUN-13  NO    NO   NO        YES
...
Wir sehen einen Eintrag in der WRITE Spalte von PRODUCTS_COPY und einen Eintrag in der Spalte LOOKUP_SCAN bei PRODUCTS_PK. Diese Ergebnisse resultieren beispielsweise aus einem UPDATE WHERE Kommando unter Nutzung des Primary Keys.

Basierend auf diesen Informationen können nun ILM spezifische Regeln - Policies - definiert werden. Policies können dabei auf verschiedenen Ebenen (z.B. Row, Segment, Tablespace) implementiert werden. Inhaltlich kann beispielsweise der Komprimierungslevel und / oder der Tablespace bei Datenverlagerung festgelegt werden. Der Zeitpunkt bzw. die Bedingung, wann die Policy angewendet wird (z.B. AFTER 30 DAYS OF NO MODIFICATION), ist dabei ein weiterer Bestandteil einer Policy. 
SQL> SELECT * FROM dba_ilmobjects;

POLIC OBJEC OBJECT_NAME   SUBOBJECT_NAME  OBJECT_TYPE     INHERITED_ ENABL
----- ----- ------------- --------------- --------------- ---------- -----
P201  SH    SALES         SALES_Q4_2000   TABLE PARTITION TABLE        YES
P201  SH    SALES         SALES_Q4_2001   TABLE PARTITION TABLE        YES
P201  SH    SALES         SALES_Q4_2002   TABLE PARTITION TABLE        YES
P201  SH    SALES         SALES_Q4_2003   TABLE PARTITION TABLE        YES
P201  SH    SALES                         TABLE           POLICY NOT   YES
                                                           INHERITED
    
SQL> SELECT policy_name, action_type, compression_level, scope, tier_tablespace, tier_status, 
     condition_type, condition_days days
     FROM dba_ilmdatamovementpolicies;

POLIC ACTION_TYPE SCOPE   COMPRESSION_LEVEL TIER_TABLESPACE TIER_STAT CONDITION_TYPE          DAYS
----- ----------- ------- ----------------- --------------- --------- ----------------------  ----
P202  COMPRESSION SEGMENT ADVANCED                                    LAST MODIFICATION TIME  1
P221  STORAGE     SEGMENT                   ADOTEST         READ ONLY                         180
Dieses Beispiel listet die Policies auf Segment Ebene für die Tabelle SALES. Die Policy P201 vererbt die Eiegnschaft Advanced Row Compression auf die Tabellen Partitionen unter der Bedingung "1 DAY OF NO MODIFICATION". Die zweite Policy verlagert die Partitionen in den Tablespace ADOTEST. Diese Operationen werden standardmässig im Maintenance Window durchgeführt. Die Online Verlagerung von Datendateien und Partitionen (siehe auch Kapitel Online Operationen und das Kapitel zu Partitionierung) sind dabei wichtige Voraussetzungen für die Durchführung einzelner Policies.

In-Database Archivierung folgt einem einfachen Konzept. So werden Archiv Daten in einer Tabelle als inaktiv markiert und sind nicht mehr sichtbar für Applikationen. Wie funktioniert dies? Die "hidden column" ORA_ARCHIVE_STATE wird zu dem entsprechenden Segment hinzugefügt. Je nach Wert der Spalte - ein manuelles Update ist erforderlich - ist dann die Information sichtbar oder nicht.

Hinweis: Mehr Informationen zu diesen Themen sind in den entsprechenden Handbüchern Oracle Database VLDB and Partitioning Guide und im Oracle Database SQL Language Reference zu finden.


Zurück zum Anfang des Artikels

Datenbank Security Erweiterungen

Security wird immer wichtiger. Daher wundert es nicht, dass es in diesem Bereich viel Neues gibt. Hier soll jedoch lediglich auf zwei große Themenblöcke eingegangen werden, die das Gros der DBAs betreffen dürfte:

  1. Least Privilege und
  2. Auditing
Nicht nur im Rahmen der Datenbank Community wird immer wieder darauf hingewiesen, dass Benutzer nur die Privilegien erhalten sollten, die sie tatsächlich für die Erfüllung ihrer Aufgaben benötigen. Das bezeichnet der Begriff least privilege. Der Hinweis ist zwar so banal wie richtig, aber im Alltag schwer zu befolgen. Denn die Frage ist natürlich, wie man herausfindet, welche Privilegien ein Benutzer bei seiner täglichen Arbeit tatsächlich benötigt, ohne diesen Benutzer durch die Analyse oder ihr vielleicht falsches oder unvollständiges Ergebnis zu behindern. Die Lösung bietet nun das Package DBMS_PRIVILEGE_CAPTURE. Das Package erfasst die verwendeten Privilegien von Rollen, Benutzern oder Anwendungen und bereitet sie zur Analyse vor. Das Erfassen wird als capture bezeichnet. Im folgenden Beispiel wird das capture zunächst für eine Anwendung konfiguriert (CREATE_CAPTURE), dann aktiviert (ENABLE_CAPTURE), nach angemessener Zeit beendet (DISABLE_CAPTURE) und zur Auswertung aufbereitet (GENERATE_RESULT). 
BEGIN
DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE(
name => 'persanalyse',
description => 'Erfasst verwendete Privilegien beim Einsatz der Personalanwendung',
type => DBMS_PRIVILEGE_CAPTURE.G_CONTEXT,
condition => 'SYS_CONTEXT(''USERENV'', ''MODULE'')=''Personalverwaltung''');
END;
/
EXEC DBMS_PRIVILEGE_CAPTURE.ENABLE_CAPTURE ('persanalyse');

EXEC DBMS_PRIVILEGE_CAPTURE.DISABLE_CAPTURE ('persanalyse');

EXEC DBMS_PRIVILEGE_CAPTURE.GENERATE_RESULT ('persanalyse');
Die Auswertung selbst erfolgt über Data Dictionary Views mit dem Namen DBA_USED_* oder DBA_UNUSED_*. Dabei steht das * etwa für OBJPRIVS oder SYSPRIVS. Wie ein Benutzer ein Privileg erhielt, lässt sich dann aus Views auslesen wie zum Beispiel DBA_USED_SYSPRIVS_PATH.

Auch im Bereich der Rollen und Privilegien setzt sich der Versuch fort, das Prinzip des least privilege in der Datenbank stärker durchzusetzen. Denn seit langem weisen vor allem Sicherheitsexperten darauf hin, dass Routinetätigkeiten der DBAs nicht die uneingeschränkten Privilegien eines SYSDBA voraussetzen sollten. So werden mit Oracle Database 12c einige neue Benutzer und gleichnamige Privilegien sowie einige Rollen neu eingeführt.
  • Der Benutzer SYSBACKUP hat alle Privilegien, um ein Backup der Datenbank mit den Werkzeugen RMAN und SQL*Plus durchzuführen.
  • Der Benutzer SYSDG hat alle Privilegien, um eine Data Guard Umgebung zu verwalten.
  • Der Benutzer SYSKM hat alle Privilegien zur Verwaltung des Oracle Keystore (alte Bezeichnung Wallet) im Rahmen der Verschlüsselung von Benutzerdaten mit Transparent Data Encryption (TDE).
  • Die Rollen AUDIT_ADMIN und AUDIT_VIEWER erlauben das Einrichten des Auditing und Auswerten oder lediglich das Auswerten des Audit Trails im Fall der Rolle AUDIT_VIEWER.
Die Benutzer SYSBACKUP, SYSDG und SYSKM sind - wie der Benutzer SYSDBA - jeweils über betriebssystemspezifische Mittel gesichert. Unter LINUX / UNIX sind also zum Beispiel entsprechende Gruppen zu definieren. Diese Gruppen werden dann bei der Installation der Oracle Software dem RDBMS bekannt gemacht. Eine Person, die einer dieser Gruppen angehört, kann dann jederzeit die Privilegien des Benutzers SYSBACKUP, SYSDG oder SYSKM wahrnehmen. Verfügt eine Person lediglich über die gleichnamigen und mit GRANT zu vergebenden Privilegien, setzt die Wahrnehmung der darin enthaltenen Privilegien eine geöffnete Datenbank voraus. Die Anmeldung erfolgt jeweils wie die Anmeldung als SYSDBA nämlich zum Beispiel mit 
connect / as syskm
Es gibt in dieser Version der Datenbank voraussichtlich zum letzten Mal das Auditing in der Form, wie es seit über 20 Jahren gehandhabt und weiterentwickelt wurde. Zusätzlich gibt es aber ein komplett überarbeitetes, völlig neues Auditing, das sogenannte unified auditing. Der DBA kann zwischen den beiden Varianten wählen, aber selbstverständlich wird empfohlen, die neue Variante zu nutzen. Angesichts der vielen Vorteile sollte das auch sehr verlockend sein. Was zeichnet das neue Auditing aus?
  • Die Audit Daten sind nicht mehr Teil des Schemas SYS, sondern gehören dem Schema AUDSYS. Sie werden zwar standardmäßig im Tablespace SYSAUX abgelegt, das ist jedoch änderbar.
  • Audit Einstellungen können nicht mehr von jedem vorgenommen werden und von jedem gelesen werden, sondern setzen auch für die Objekte des eigenen Schemas die Rolle AUDIT_ADMIN voraus. Eine weitere Rolle, AUDIT_VIEWER, gibt ausschließlich lesenden Zugriff.
  • Es gibt nur noch einen Audit Trail für alle Funktionalitäten. Die Trennung in AUD$ für die Einträge des Standardauditing, FGA_LOG$ für die Einträge des Fine Grained Auditing und AUDIT_TRAIL$ für den Audit Trail des Database Vault entfällt.
  • Auch die Werkzeuge Data Pump, RMAN und SQL*Loader können Einträge im Audit Trail erzeugen.
  • Das neue Auditing verfügt über eine deutlich bessere Performance. Dazu gehört auch, dass steuerbar ist, wann die Audit Einträge geschrieben werden: Wie bisher unmittelbar nach dem zu auditierenden Ereignis oder verzögert gemeinsam mit anderen Audit Einträgen aus einer Queue in der SGA.
  • Audit Policies sind neue Datenbankobjekte. Sie enthalten eine beliebige Reihe von AUDIT Einstellungen, die dann als Ganzes weitergegeben und aktiviert werden können. Da Policies zum Beispiel Bedingungen für das Schreiben von Audit Einträgen enthalten können, ist es endlich auch möglich, Ausnahmen zu formulieren, für die dann kein Audit Eintrag geschrieben wird. Das ist zum Beispiel extrem hilfreich, wenn eine Anwendung ohnehin einen eigenen Audit Trail schreibt, man also als DBA nur noch das Umgehen der Anwendung überwachen will: Auditiert wird alles, ausser das, was aus der Anwendung heraus passiert.


Zurück zum Anfang des Artikels

Application Continuity

Oracle hat in den bisherigen Datenbankversionen viel für die Verfügbarkeit der Datenbank getan: So hat man mit Oracle Real Application Clusters einen hochverfügbaren Cluster, der in wenigen Sekunden umschalten kann, und mit Active Data Guard eine Desaster Recovery System, welches nicht nur für das Desaster Recovery zur Verfügung steht. Leider reicht aber ein verfügbares Datenbanksystem alleine nicht aus, wenn die Applikationen damit nicht umgehen können. Zwar hat Oracle schon seit langem Transparent Application Failover (TAF), aber wirklich transparent ist dies nicht. Die Funktionalität endet schon bei einfachen Selects und beim Thick Client. Zusätzlich ist TAF von der Architektur her nicht in der Lage schnell genug zu reagieren, wie es moderne JDBC Applikation erfordern.

So führte Oracle mit 10g schon eine neue Failover Benachrichtigung für Applikationen mit Connection Pooling ein, die auf eine schnelle Re-Initialisierung des Conntection Pools abzielte. Dank Fast Application Notification (FAN) und dem damit zusammenhängenden Implizit Connection Cache im Oracle JDBC Connection Pool bzw. in 11g dem Universal Connection Pool (UCP) wurden inaktive Connections schnellstens geschlossen und neue Connections zu neuen Knoten aufgebaut. Leider überließ diese Technologie die komplette Failover Implementierung dem Anwendungsentwickler.

Mit Oracle 12c Datenbank und dem Oracle 12c Client führt Oracle nun 2 neue Funktionen (Transaction Guard und Application Continuity) ein, um einerseits dem Anwendungsentwickler mehr Möglichkeiten zur genauen Analyse des Fehlerzeitpunktes an die Hand zu geben, und andererseits auch eine eingebaute Funktionalität mitzuliefern, die eine fehlgeschlagene Transaktion neu ausführt.

Eins der großen Probleme in der automatischen Failover Implementierung in der Anwendung ist es, den aktuellen Transaktionsstatus abzufragen: Wenn nach einem Commit das Netzwerk ausfällt bekommt der Anwender zwar eine Fehlermeldung, aus dieser geht aber nicht hervor, ob der COMMIT erfolgreich war, oder nicht. Die Datenbank befindet sich natürlich zu diesem Zeitpunkt in einem vollkommen transaktionskonsistenten Zustand. Hat sie den Commit erhalten und durchgeführt und das Acknowledgement an den Client gesendet, ist die Transaktion erfolgreich gewesen, obwohl das Acknowledgement den Client niemals erreicht hat. War das Netzwerk vor der Übermittlung des Commits weg, führt die Datenbank ein Rollback durch, da die Session des Clients nicht mehr existiert.

Wie sollte sich nun der Applikationsentwickler einer solchen Applikation verhalten? Das Statement einfach nochmals durchführen? Oder besser nicht?

Die Antwort hierzu bietet der in der Enterprise Edition der Datenbank enthaltene Transaction Guard: Transaction Guard führt für jede Transaktion des Clients eine eindeutige logische Transaktions ID, die vom Entwickler verwendet werden kann, um zu überprüfen ob die Transaktion erfolgreich war oder nicht.

Damit allerdings diese Funktion zur Verfügung steht, muss die Applikation sich an einen Service verbinden, bei dem die Eigenschaft COMMIT_OUTCOME=TRUE gesetzt ist. Diese Eigenschaft kann in SQL mit DBMS_SERVICE gesetzt werden oder einfacher bei der Verwendung der Grid Infrastruktur über srvctl: 

srvctl modify service -database orcl -service GOLD -commit_outcome TRUE
Das zu RAC und Data Guard gehörende Feature Application Continuity ist eine Art Client Replay und verwendet dazu das implizit im JDBC Thin Universal Connection Pool (UCP) eingebaute Transaction Guard Feature.

Hierzu merkt sich der Connection Pool die ausgeführten Aktionen und wird diese im Fehlerfalle einfach erneut ausführen inklusive aller gesetzten Session Informationen. Mit Hilfe von Transaction Guard 'weiß' der Connection Pool nun, welche Transaktion bereits abgeschlossen wurde und ob ein Replay notwendig ist.

Viele Applikationen werden somit befähigt, bei einem Ausfall des Netzwerks, des RAC Knotens oder Data Guard Transaktionen erneut auszuführen, ggf. auf einem anderen Knoten. Allerdings hat dieses Replay alle Einschränkungen, die einem Replay eigen sind - so kann nur für Objekte in der Datenbank nachgeprüft werden, ob eine Aktion erfolgt ist oder nicht. Aktionen außerhalb der Datenbank (Zugriff auf das Filesystem o.ä.) würden bei einem Replay mehrmals durchgeführt.

Hinweis: Mehr Informationen zu diesen Themen sind im Handbuch Oracle Database Development Guide 12c Release 1 (12.1) zu finden.

Zurück zum Anfang des Artikels

Manageability

Das erste Tool der Wahl zur Verwaltung einer Oracle Datenbank ist Oracle Enterprise Manager 12c Cloud Control. Dieses gilt auch für die neueste Version der Datenbank. Dank des neuen modularen Aufbaus von Cloud Control kann neue Zielsoftware sehr zeitnah unterstützt werden. Das aktuelle Release 12.1.0.2 von Cloud Control, zusammen mit dem aktuellen Plugin für die Oracle Datenbank (Plugin Version 12.1.0.3.0) unterstützt die meisten Features der Oracle Datenbank 12c, also auch den gesamten Bereich der "Multitenant Database". Weitere Features werden in Kürze durch ein Update des Plugins unterstützt. Dieses neue Plugin können Sie dann leicht über den Self-Update Mechanismus von Cloud Control herunterladen.

Eine einfachere Variante ist Oracle Enterprise Manager 12c Database Express (kurz EM DB Express), welches das von früheren Versionen bekannte Database Control ablöst. EM DB Express ist eine Webanwendung, benötigt aber viel weniger Ressourcen auf dem Datenbank Server als Database Control. Es ermöglicht dabei die Basisadministration der Datenbank unter Verwendung der modernen GUI von Cloud Control.


Die altbekannten Utilities bekommen in 12c einige neue Features. In Data Pump beispielsweise können Aktionen sowohl des Exports als auch des Imports im Rahmen des neuen Auditings auditiert werden. Dazu erstellen Sie eine AUDIT-Policy für die Komponente DATAPUMP: 

CREATE AUDIT POLICY policy_name
ACTIONS COMPONENT=DATAPUMP { EXPORT | IMPORT | ALL };
Im Bereich der Komprimierung können Sie jetzt beim Import die Komprimierungs-Methode wechseln, so dass die importierten Daten anders komprimiert werden, als dieses beim Export vorlag. Dazu verwenden Sie den Parameter TRANSFORM=TABLE_COMPRESSION_CLAUSE. Beim Export können Sie den Komprimierungsgrad einstellen und so einen individuellen Kompromiss zwischen Export-Geschwindigkeit und Speicherbedarf herstellen. Sie geben die Komprimierungsmethode über den Parameter COMPRESSION_ALGORITHM mit den möglichen Werten BASIC, LOW, MEDIUM oder HIGH an.

Auch können jetzt Datenbankviews als Tabelle exportiert werden. Damit sind Sie noch flexibler bei der Erstellung zugeschnittener Exports. Die Handhabung ist sehr einfach, indem Sie den Parameter VIEWS_AS_TABLES verwenden, also zum Beispiel 
expdp red@pdbred directory=dpdir dumpfile=red.dmp views_as_tables=red.eba_sales_opp_v
Das Ergebnis können Sie leicht testen, da in diesem Beispiel ja keine Verschlüselung für das Dumpfile verwendet wurde. Mit 
strings red.dmp > wdg.txt
sehen Sie in der Textdatei reale Daten, zum Beispiel die beiden Datenzeilen (jeweils mit "<" abgeschlossen) 
Asymmetrical Antibiotics Inc
Amy     Albertson
amy.albertson@fastmail.com
Modernization Program
Product Presentation Performed<
Lexington Exports
David
Davidson
david.davidson@fastmail.com
Enterprise Lic Deal
Product Presentation Performed<
Die Dump-Datei wird beim Import so behandelt, dass die Daten nun als Tabelle importiert werden. Dabei hat die Tabelle den Namen der exportierten View. Ein Import in das gleiche Schema funktioniert also nur, wenn eine neue Tabelle erstellt wird und dazu eine Namensänderung festgelegt wird, zum Beispiel mit 
impdp red@pdbred directory=dpdir dumpfile=red.dmp remap_table=red.eba_sales_opp_v:wdg
Hier werden die Daten also in die neue Tabelle WDG importiert. Früher wurden Views nur im Rahmen von Schema- bzw. Full DB Exports exportiert, jedoch nicht deren Daten, sondern nur deren Definition.

Zur Beschleunigung von Imports kann die Generierung von Redo Log Information abgeschaltet werden, wie man es auch schon vom SQL*Loader kennt. Dazu verwenden Sie den Parameter TRANSFORM: 
impdp ... TRANSFORM=DISABLE_ARCHIVE_LOGGING:y
Auch für den SQL*Loader gibt es Neuerungen: Es gibt jetzt einen sogenannten Express Modus, bei dem Sie keine Loader-Kontrolldatei mehr brauchen, sondern alle relevanten Informationen als Parameter in der Kommandozeile angeben. Dieses funktioniert derzeit für CSV-Dateien. SQL*Loader erzeugt dann eine passende Loader-Kontrolldatei, die dann für eine spätere Nutzung gespeichert werden kann. Auch im Bereich Auditing gibt es Neues: Direct Path Loads können jetzt auch auditiert werden.

Im Rahmen des Jobsystems in der Datenbank, realisiert durch das PL/SQL Package DBMS_SCHEDULER, stehen Ihnen neue, vorgefertigte Jobtypen zur Verfügung. Die neuen Jobtypen sind:
  • EXTERNAL SCRIPT
    Hier können Sie ein Shell-Skript aufrufen. Bislang waren externe Aufrufe nur über EXECUTABLES möglich, die speziell erstellt werden müssen. Ein Shell-Script ist viel einfacher erstellt.
  • SQL_SCRIPT
    Auch hier handelt es sich um einen externen Skriptaufruf, aber unter Verwendung von SQL*Plus.
  • BACKUP_SCRIPT
    Ein RMAN Skript zur Sicherung der Datenbank. Dabei wird das RMAN Executable des durch die Datenbank verwendeten ORACLE_HOMEs genutzt.


Zurück zum Anfang des Artikels

Far Sync Standby

Data Guard wurde um einige nützliche Features erweitert: So werden nun bei einer logischen Standby beinahe alle Datentypen unterstützt, was das Rollierende Versions Upgrade in Zukunft erheblich erleichtert. Des weiteren gibt es nun ein eigenes PL/SQL Package (DBMS_ROLLING) um diesen Upgrade einfacher zu gestalten.

Zu den interessantesten Data Guard Neuheiten gehört mit Sicherheit aber die zur Active Data Guard gehörenden sogenannten Far Sync Standby. Ist es bisher so gewesen, dass für den Zero Data Loss Modus die Standby Datenbank nicht allzu weit (bis maximal 300 km) von der Primärseite stehen musste (damit es nicht zu merklichen Performanceeinbußen kommt), so erlaubt das Konzept von Far Sync Standby nun sehr viel größere Entfernungen (über Kontinente hinweg). Trotzdem bleibt die Far Sync Standby im Zero Data Loss Modus und somit das Optimum an Datensicherheit.

Zum Aufbau einer Far Sync Standby wird in der Nähe zum Primärsystem eine Art "Redolog-Repeater" aufgebaut, der selber im SYNC Modus zur Primärdatenbank steht. Dieser empfängt die Redologs der Primärdatenbank und leitet diese im asynchronen Modus an die Far Sync Standby weiter. Dabei werden auf diesem Repeater selber weder Datenfiles noch System Tablespaces benötigt, was es erlaubt, ein relativ kleines System als Repeater zu verwenden. Es ähnelt also vom Prinzip her einem kaskadierenden Standby System, allerdings ohne die bisherigen Abhängigkeiten und Problematiken beim Umschalten. Auch ein Ausfall der Internetverbindung zwischen der Far Sync Standby und dem Primärsystem bzw. Repeater hat keine Auswirkungen auf das System, da der Repeater die anfallenden Redolog Informationen zwischenspeichern kann. Wenn das Netzwerk wieder verfügbar ist, übermittelt der Repeater die angefallenen Informationen.

Auf der Empfängerseite kann ebenfalls ein "Redolog-Repeater" stehen, der die asynchron gesendeten Redolog Informationen empfängt und diese synchron an das Standby System weiterleitet. Dieser Aufbau erlaubt auch nach einem Umschalten auf die Standbyseite den Zero Data Loss Modus in umgekehrter Richtung beizubehalten.

Liegt ein Fehler beim Primärsystem vor, hat nun der Repeater dank synchronem Transfer und Zero Data Loss Modus alle Redo Informationen der Transaktionen des Primärsystems und wird diese beim Failover erst an die Standbyseite weitergeben, bevor diese aktiviert wird. Somit erreicht man ein Maximum an Datensicherheit, trotz großer Entfernungen und unsicherer Netzwerkverbindungen.

Eine Voraussetzung für diese Art der kaskadierenden Standby war eine Verbesserung im Transfer bei kaskadierenden Data Guard Umgebungen. So hatte diese bis 12c eine Verzögerung, die Redologinformationen erst nach einem Logswitch an die kaskadierenden Systeme weitergab. Mit 12c werden nun auch Zweit- und Dritt-Systeme immer mit aktuellen Redoinformationen versorgt.


Zurück zum Anfang des Artikels

Performance Features

Im Bereich Performance sind auf verschiedenen Ebenen Neuigkeiten zu finden. Die Beispiele, die wir in diesem Abschnitt aufzeigen, gehören in die Bereiche Memory Management, Statistikmanagement und Plangenerierung. Weitere Features, die auch für die Performance relevant sind, finden Sie im Abschnitt Online Operationen und Partitionierung.

Vor 12c war es beispielsweise nicht möglich, die PGA Größe zu begrenzen. Der Parameter PGA_AGGREGAT_TARGET war nur ein Zielwert und stellte keine Begrenzung der PGA dar. Dies konnte im negativen Fall bedeuten, dass die PGA Memory Werte dynamisch über diesen Wert hinaus anwachsen und sogar Swapping auslösen konnten. Mit dem neuen Parameter PGA_AGGREGAT_LIMIT, der automatisch ab 12c gesetzt ist, kann nun eine feste Begrenzung des PGA Wachstums erfolgen.

Mit Oracle Enterprise Manager Cloud Control 12c wurde die Real Time ADDM Funktionalität eingeführt. Über einen speziellen leichtgewichtigen Connection Typ (auch Diagnostic Mode) kann damit eine Analyse bei Engpässen in der Datenbank (wie Locks, Hängen etc.) angestossen werden, wenn keine weitere normale Connection mehr möglich ist. Um diesen Situationen in 12c rechtzeitig entgegenzuwirken, werden nun automatisch in regelmäßigen Intervallen von MMON die In Memory Performance Daten auf mögliche Engpässe (wie I/O bound; CPU bound, Over Allocated Memory etc.) untersucht. Werden die vorgeschriebenen Grenzen dabei überschritten, führt der Real Time ADDM eine Analyse durch, und die Daten werden im AWR notiert.

Viele Eweiterungen sind auch im Statistikmanagement zu finden. Dazu gehören Concurrent Statistics Gathering, automatische Column Group Generierung, neue Typen von Histogrammen, Statistik Collection im Reporting Mode oder Online Statistics Gathering für Bulk Load Operationen - um nur einige zu nennen. Zudem gibt es auch die Möglichkeit, Statistiken für globale Temporäre Tabellen zu erzeugen. Die neue Tabellen Präferenz GLOBAL_TEMP_TABLE_STATS ermöglicht dabei, die Statistiken als SHARED (Default) oder SESSION zu deklarieren. Falls SESSION eingestellt ist, werden die Statistiken nur für diese Session berechnet. Der Optimizer überprüft beim Zugriff zuerst auf Session spezifische dann auf Shared Statistiken. Beide Statistik Typen können natürlich parallel verwendet werden.

Das neue Feature "Adaptive Query Optimization" führt in 12c zu fundamentalen Änderungen / Erweiterungen bei der Plangenerierung bzw. Statementoptimierung. Um einen optimalen Plan zu generieren, benutzt der Optimizer bisher Statistiken, zugehörige Zugriffsobjekte und Umgebungseinstellungen. Diese Informationen sind manchmal nicht ausreichend, um einen optimalen Plan zu erzeugen. Daher gibt es nun weitere Mechanismen zur Plangenerierung wie zum Beispiel Adaptive Pläne, dynamische Statistiken und eine automatische Re-Optimierung. Die Nutzung von adaptiven Plänen bedeutet dabei, dass der Optimizer in gewissen Fällen über zusätzliche alternative Pläne und einen sogenannten Statistik Kollektor bei der Plangenerierung verfügt. Basierend auf den Informationen des Statistik Kollektors kann der finale Plan dann zum Beispiel eine Hash Join Ausführung statt eines Nested Loop Joins enthalten. Folgendes Beispiel zeigt dieses Verhalten im Note Abschnitt der DBMS_XPLAN.DISPLAY_CURSOR Ausgabe. 

...
------------------------------------------------------------------------------------------                                            
| Id  | Operation          | Name                | Rows  | Bytes | Cost (%CPU)| Time     |                              
------------------------------------------------------------------------------------------                                           
|   0 | SELECT STATEMENT   |                     |       |       |     8 (100)|          |                                
|*  1 |  HASH JOIN         |                     |    13 |   416 |     8   (0)| 00:00:01 | 
|*  2 |   TABLE ACCESS FULL| ORDER_ITEMS         |    13 |   156 |     3   (0)| 00:00:01 |                                            
|   3 |   TABLE ACCESS FULL| PRODUCT_INFORMATION |   288 |  5760 |     5   (0)| 00:00:01 |                              
------------------------------------------------------------------------------------------                                  
Predicate Information (identified by operation id):                                                                      
---------------------------------------------------                                                                     
   1 - access("P"."PRODUCT_ID"="O"."PRODUCT_ID")                                                                                      
   2 - filter(("O"."UNIT_PRICE"=15 AND "QUANTITY">1))                                                                                 
Note                                                                                                                     
-----                                                                             
   - this is an adaptive plan


Zurück zum Anfang des Artikels

Online Operationen

Mehr Funktionalität im Online Operationen Umfeld ist ein weiteres wichtiges Thema. Die neuen Online Erweiterungen sind grundlegende Bausteine, um weitere Automatismen in der Datenbank zu erlauben oder größere Unterbrechungsfreiheit innerhalb von Anwendungen zu garantieren. Als erstes Beispiel wird das Umbenennen von Datendateien demonstriert. In 11g kann eine Datendatei zwar umbenannt werden, der Status muß allerdings dabei OFFLINE sein. Das neue MOVE DATAFILE Kommando in 12c erlaubt eine Umbenennung bzw. Verlagerung, ohne dass eine Status Änderung notwendig ist. 

SQL> SELECT status, name FROM v$datafile;

STATUS  NAME
------- ----------------------------------------
SYSTEM  /opt/oracle/oradata/orcl/system01.dbf
ONLINE  /opt/oracle/oradata/orcl/example01.dbf
...
ONLINE  /opt/oracle/oradata/orcl/user1.dbf

SQL> ALTER DATABASE MOVE DATAFILE '/opt/oracle/oradata/orcl/user1.dbf' TO '/home/oracle/user01alt.dbf';
Database altered.

SQL> SELECT status, name FROM v$datafile;

STATUS  NAME
------- ----------------------------------------
SYSTEM  /opt/oracle/oradata/orcl/system01.dbf
ONLINE  /opt/oracle/oradata/orcl/example01.dbf
...
ONLINE  /home/oracle/user01alt.dbf
Nicht nur Datendateien können online verlagert werden. Neuerdings stehen auch einige weitere wichtige Operationen mit der Option ONLINE zur Verfügung. Beispiele für solche Operationen sind die DDL Kommandos ALTER TABLE ... MOVE PARTITION ONLINE, DROP INDEX ...ONLINE etc. Dabei ermöglicht die Syntax Erweiterung ONLINE die Ausführung ohne blockierende DML Sperren (TM Lock). Parallel durchgeführte DML Operationen, die normalerweise in 11g durch die entsprechenden Locks blockiert wären, sind nun möglich. So können Anwendungen ohne Unterbrechungen auch bei geplanten Schemaänderungen weiterlaufen.

Bisher konnte die Eigenschaft INVISIBLE nur bei Indizes verwendet werden. Sie sorgt dafür, dass diese Indizes für die Statementausführung unsichtbar (engl: invisible) sind. Allerdings ist der Index physikalisch vorhanden und wird bei allen DML Operationen gepflegt. Jetzt steht diese Technik auch für User definierte Spalten zur Verfügung. Interessant ist dieses Feature immer dann, wenn Applikationsänderungen zu einer Änderung an den Tabellenstrukturen führen. Die Implementierung erfolgt über eine Kommando Erweiterung beim CREATE und ALTER TABLE. 
SQL> ALTER TABLE emp ADD (e_inv NUMBER INVISIBLE);

-- Spalte nur sichtbar mit folgendem SET Kommando

SQL> SET COLINVISIBLE ON

Name     Null     Type         
-------- -------- ------------ 
EMPNO    NOT NULL NUMBER(4)    
ENAME             VARCHAR2(10) 
...
E_INV (INVISIBLE) NUMBER
Wenn es um Schema Änderungen geht, können auch Indizes betroffen sein. In 12c wird es möglich sein, Indizes - verschiedenen Typs (z.B. B*tree, Bitmap) oder verschiedener Partitionierungsarten (z.B. range, hash, global, local, bitmap) - auf die gleichen Spalten zu legen.


Allerdings kann zu einer Zeit nur einer dieser Indizes genutzt werden und somit "visible" sein. Folgendes Beispiel zeigt eine einfache Implementierung. 
SQL> SELECT i.index_name, i.visibility, i.index_type, c.column_name 
     FROM user_indexes i, user_ind_columns c 
     WHERE i.index_name=c.index_name AND i.table_name='EMP';

INDEX_NAME           VISIBILIT INDEX_TYPE                  COLUMN_NAME
-------------------- --------- --------------------------- --------------------
BIT_DEPTNO_ENAME     INVISIBLE BITMAP                      ENAME
BIT_DEPTNO_ENAME     INVISIBLE BITMAP                      DEPTNO
B_DEPTNO_ENAME       VISIBLE   NORMAL                      ENAME
B_DEPTNO_ENAME       VISIBLE   NORMAL                      DEPTNO


Zurück zum Anfang des Artikels

RMAN Erweiterungen

Die neueste RMAN Verbesserung macht einen Plattformwechsel zu einem Kinderspiel. RMAN erlaubt es nun, ein Backup einer Datenbank auf jeglichem System mit einer 12c Datenbank wiederherzustellen, auch über verschiedene Endianess hinweg. Einzige Voraussetzung ist, dass die Plattform in der View V$TRANSPORTABLE_PLATFORM enthalten ist. Dem Backup eines Itanium Systems und dem Restore des Backupsets auf einer Exadata unter Linux steht somit nichts mehr im Wege und macht die händische Migration über Transportable Tablespaces überflüssig. Allerdings verwendet der Mechanismus intern genau diesen Transportable Tablespace Ansatz. Hierzu muss dem Backup ein passendes Export Data Pump File (wie bei Transportable Tablespaces) mitgegeben werden. Dies funktioniert bei RMAN 12c automatisch mit dem zusätzlichen Schlüsselwort FOR TRANSPORT beim Erstellen des Backup Sets. Interessanterweise funktioniert das auch mit älteren Backups (10g oder 11g), wenn ein entsprechendes Dump File mit den Metadaten erzeugt wurde.

Ebenfalls erlaubt RMAN mit 12c nun einzelne Tabellen aus einem Backup wiederherzustellen. Das Vorgehen bzw. interne Mechanismen sind dabei ähnlich einem Tablespace Point in Time Recovery (TSPITR), mit dem Unterschied, dass eben nur die einzelne Tabelle mit Hilfe einer Auxiliary Datenbank wiederhergestellt wird. Dabei kann die zu recovernde Tabelle direkt in die Datenbank wieder zurückgespielt werden oder in ein Data Pump Set ausgelaget werden. 

RECOVER TABLE SCOTT.EMP
UNTIL TIME 'SYSDATE-1'
AUXILIARY DESTINATION '/tmp/oracle/recover'
DATAPUMP DESTINATION '/tmp/recover/dumpfiles'
DUMP FILE 'emp_dump.dat'
NOTABLEIMPORT;
Eine weitere wichtige Neuerung ist das Erstellen einer Multisektions Image Kopie einer Datendatei. Dies ist gerade für die Verwendung besonders großer Datendateien (wie beim Bigfiletablespace) interessant: Konnte bisher eine Image Kopie immer nur von einem RMAN Prozess erstellt werden und war somit an eine CPU gebunden, kann nun die Image Kopie von mehreren Prozessen gleichzeitig (ein Prozess pro Sektion) vorgenommen werden und kann somit das Erstellen von Image Kopien beschleunigen. Das ist nicht nur für die präferierte Backup Strategie interessant sondern auch beim Duplizieren von Datenbanken über das Netz (from active database). 

BACKUP AS COPY
SECTION SIZE 10M
DATAFILE '/u01/app/oracle/oradata/orcl/users01.dbf';


Zurück zum Anfang des Artikels

Partitionierung

Wie in allen anderen Vorgänger Releases gibt es auch mit 12c erneut Erweiterungen im Bereich Funktionalität, Performance und Verwaltung, die für den DBA den Umgang mit partitionierten Tabellen weiter verbessern. Funktional wird zum Beispiel die mit 11g eingeführte Reference Partitionierung um die Interval Partitionierung erweitert. Falls neue Daten hinzugefügt werden, werden die Reference Tabelle und ihre Child Tabellen somit automatisch um die entsprechenden Partitionen erweitert. Zusätzlich dazu werden TRUNCATE PARTITION und EXCHANGE PARTITION Operationen für Reference bzw. Reference Interval partitionierte Tabellen kaskadierend auf den referenzierenden partitionierten Child Tabellen durchgeführt. Diese Operationen sind damit auf die Child Tabellen vererbt und vereinfachen die Maintenance Aufgaben im Bereich Reference Partitionierung.

PARTITION / SUBPARTITION MOVE Kommandos sind um das Schlüsselwort ONLINE erweitert worden und erlauben nun wie bei den IOTs parallele konkurrierende DML Operationen ohne Locking (siehe auch Abschnitt Online Operationen). Globale und lokale Indizes werden dabei automatisch mitgepflegt. Diese Erweiterungen liefern damit eine wichtige Voraussetzung für die Implementierung und Durchführung von ILM Policies. So können ILM Policies automatisch und online Partitionen/Subpartitionen verschieben oder beispielsweise die Komprimierungseigenschaft von Partitionen/Subpartitionen verändern (siehe auch Abschnitt zu ILM).

Eine Kommando Erweiterung bei den Operationen ALTER TABLE SPLIT und ALTER TABLE MERGE usw. führt dazu, dass nun mehrere Partitionen/Subpartitionen mit einem einzigen Befehl verarbeitet werden können. Die Anzahl der Kommandos kann dadurch erheblich eingeschränkt werden - besonders falls viele Partitionen betroffen sind. Ein einfaches Beispiel mit 3 Partitionen zeigt die Funktionalität. In 11g wären für diese Operation zwei Kommandos notwendig gewesen, um das gleiche Endresultat zu erhalten. Folgendes Beispiel zeigt eine Implementierung in 12c. 

ALTER TABLE test MERGE PARTITIONS p1 TO p3 INTO PARTITION P3;
Um die Performance zu erhöhen, ist die Instandhaltung von globalen Indizes bei Kommandos wie DROP PARTITION und TRUNCATE PARTITION nun asynchron implementiert. Nur die Metadaten werden bei der Durchführung verändert; die globalen Indizes werden nachgelagert beispielsweise während der Maintenance Tasks angepasst.

Partitionierte Indizes können bis 11g die Eigenschaften lokal oder global (partitioniert oder nicht partitioniert), USABLE oder UNUSABLE haben. Um mehr Flexibilität bei der Indexerzeugung zu erhalten, ist es in 12c möglich, lokale und globale Indizes auf einer Untermenge von Partitionen der Tabelle zu erzeugen. Beim Anlegen einer Tabelle wird einfach die neue Indexeigenschaft INDEXING ON bzw. INDEXING OFF pro Tabelle und / oder pro Partition mitgegeben. Diese Eigenschaft wird dann beim Index Anlegen verwendet, wenn das Schlüsselwort PARTIAL mitgegeben wird. Für lokale Indizes bedeutet eine INDEXING ON Eigenschaft einer Tabellen Partition die Eigenschaft USABLE ansonsten die Eigenschaft UNUSABLE für die Index Partition. Globale Indizes beinhalten nur die Partitionen mit INDEXING ON. 
CREATE TABLE tab_partial_idx (
  col1 NUMBER(12),
  col2 NUMBER(12),
  col3 NUMBER(12),
  col4 number(12))
   INDEXING OFF
   PARTITION BY RANGE (col1)
   (PARTITION p1 VALUES LESS THAN (100) INDEXING ON,
    PARTITION p2 VALUES LESS THAN (200),
    PARTITION p3 VALUES LESS THAN (400) INDEXING ON);

CREATE INDEX p1_idx ON tab_partial_idx(col1) LOCAL INDEXING PARTIAL;

SQL> SELECT index_name, partition_name, status 
     FROM user_ind_partitions WHERE index_name LIKE 'P%IDX';

INDEX_NAME PARTITION_ STATUS 
---------- ---------- --------
P1_IDX     P1         USABLE   
P1_IDX     P2         UNUSABLE    
P1_IDX     P3         USABLE   

SQL> SELECT index_name, indexing 
     FROM user_indexes WHERE index_name LIKE 'P%IDX';

INDEX_NAME INDEXING
---------- --------
P1_IDX     PARTIAL


Zurück zum Anfang des Artikels

Zurück zur Community-Seite