Logo Oracle Deutschland Dezember 2016
Oracle Database 12c Release 2: unsere Lieblingsfeatures
Ralf Durben, Manuel Hoßfeld, Sebastian Solbach und Ulrike Schwinn

Seit Herbst diesen Jahres steht Oracle Database 12c Release 2 in der Cloud zur Verfügung - seit September mit dem Erscheinen des neuen Oracle Database Exadata Express Cloud Service und ein paar Wochen später im Standard Oracle Database Cloud Service. Der Oracle Database Cloud Service mit Oracle Database 12c Release 2 steht dabei in allen bekannten Cloud Ausprägungen - Standard, Enterprise, High Performance und Extreme Performance - zur Verfügung. Oracle Database Exadata Express hingegen ist eine Art Einstiegssegment: es erlaubt das Arbeiten in einer PDB mit ausgewählten Datenbank Entwickler Features. Unten im Abschnitt "Informationen" finden Sie weiterführende Links zu den Themen.

Weil eine umfassende Beschreibung aller Features den Rahmen des Blogeintrags sprengen würde, konzentrieren wir uns in diesem Beitrag jeweils auf eines unserer Lieblingsfeature. Sie werden also in den folgenden Abschnitten Features aus den Bereichen - Datenbank Entwicklung, Hochverfügbarkeit, Multitenant und Security lesen. Bei den Beschreibungen handelt es sich um eine Einführung, die zeigen soll, wofür die Technologie sich eignet und wie sie eingesetzt werden kann. Wir werden in den kommenden Monaten diese und weitere 12.2 Themen ausführlicher aufgreifen.

Oracle Database 12.2.0.1 - unsere Favoriten

  1. Ralfs Feature
  2. Sebastians Feature
  3. Manuels Feature
  4. Ulrikes Feature

Applikationscontainer in Oracle Multitenant

Die in Oracle 12.1 eingeführte Oracle Multitenant Architektur wird in 12.2 mit einigen sehr weitgehenden Features erweitert. Eines dieser Features sind die neuen Applikationscontainer. Oftmals werden für eine Applikation mehrere Datenbanken benötigt, sei es um neben der Produktions-Datenbank auch Test- und Integrations-Datenbanken zu betreiben, oder auch wenn eine Anwendung mehrfach, zum Beispiel getrennt für verschiedene Filialen, Regionen oder Mandanten, betrieben wird. In allen diesen Fällen benötigen diese Datenbanken das gleiche Datenmodell und der traditionelle Ansatz zur Erstellung einer solchen Datenbank besteht im Ausführen vorgegebener Skripte in jeder einzelnen Datenbank. Die Multitenant Architektur beinhaltet eine Trennung der Speicherung von Data Dictionary Definitionen und auch Inhalten, wobei ein statischer Teil auf CDB Ebene und der dynamische Teil auf PDB Ebene gespeichert wird. Das Data Dictionary ist das Datenmodell der Oracle Datenbank und man kann es mit einem Datenmodell von Anwendungen gut vergleichen. Also kann man auch auf der Ebene der Anwendung diese Trennung durchführen. Es gibt für jede Anwendung

Wenn für eine Anwendung mehrere Datenbanken betrieben werden, stellt sich schnell die Frage, ob man nicht, wie beim Data Dictionary auch, eine einmalige, zentrale Speicherung all dessen durchführen kann, was in allen PDBs gleich genutzt wird. Genau für dieses Ziel gibt es den Applikationscontainer.

Da eine CDB bis zu 4096 PDBs betreiben kann, werden in aller Regel auch mehrere verschiedene Anwendungen in mehreren PDBs betrieben. Daher können Sie mehrere Applikationscontainer in einer CDB betreiben. Jeder Applikationscontainer ist sowohl eine PDB (in der Haupt-CDB), als auch CDB (für die Anwendungs-PDBs). Auch für den Applikationscontainer kann eine Seed-Datenbank vorbereitet werden, um die Erstellung neuer PDBs zu beschleunigen.

  1. Erstellen eines Applikationscontainers

  2. Um einen Applikationscontainer zu erstellen, melden Sie sich an die CDB an. Sie benötigen das Privileg CREATE PLUGGABLE DATABASE. Dann verwenden Sie das Kommando CREATE PLUGGABLE DATABASE ergänzt um die Klausel AS APPLICATION CONTAINER. Hier ein Beispiel:

    SQL> CREATE PLUGGABLE DATABASE myapp_ac AS APPLICATION CONTAINER 
             ADMIN USER myapp_ac_adm IDENTIFIED BY manager
             FILE_NAME_CONVERT=('pdbseed','myapp'); 
    

    Sie öffnen dann den neuen Applikationscontainer mit folgendem Kommando und können sich nun an den neuen Appplikationscontainer anmelden, um weitere Aktionen durchzuführen.

    SQL> ALTER PLUGGABLE DATABASE myapp_ac OPEN;
    

  3. Erstellen einer Seed-Datenbank in einem Applikationscontainer

  4. Mit einer Seed-Datenbank erstellen Sie durch schnelles Kloning die später angeforderten Anwendungs-PDBs. Um eine Seed-Datenbank zu erstellen, melden Sie sich an den Applikationscontainer an. Dann führen Sie das Kommando CREATE PLUGGABLE DATABASE AS SEED aus. Beachten Sie dabei, dass in einem Applikationscontainer nur eine Seed-Datenbank erstellt werden kann.

    SQL> CREATE PLUGGABLE DATABASE AS SEED ADMIN USER pdbadmin IDENTIFIED BY manager;
    

    Auch diese PDB müssen Sie zunächst öffnen.

    In der SEED-Datenbank können Sie Datenbankobjekte erstellen, die später beim Kloning auch in der PDB lokal gespeichert sind. Dabei wird aber ein Kopieren vorgenommen. Spätere Änderungen in der Seed-Datenbank haben keinen Effekt auf bereits existierende Anwendungs-PDBs. Des Weiteren stellen Sie die PDB-spezifischen Instanzparameter ein.

  5. Erstellen von Anwendungs-PDBs

  6. Wenn Sie den Applikationscontainer inklusive Seed-Datenbank vorbereitet haben, können Sie nun die Anwendungs-PDBs erstellen. Dazu melden Sie sich an den Applikationscontainer an und erstellen die PDB zum Beispiel mit

    SQL> CREATE PLUGGABLE DATABASE pdb_app2
             ADMIN USER pdbadmin IDENTIFIED BY manager 
             DEFAULT TABLESPACE data;
    

    Dabei wird die Seed Datenbank geklont. Beachten Sie, dass nachträgliche Änderungen an der Seed Datenbank nicht für die bereits erstellten Anwendungs-PDBs gelten.

  7. Erstellung des zentral gespeicherten Datenmodells

  8. Sie können im Applikationscontainer Datenbankobjekte speichern, die inhaltlich oder auf der Ebene der Metadaten von den Anwendungs-PDBs referenziert werden. Aus der Sicht der PDB sind dieses lokale Datenbankobjekte, die aber nur einmalig gespeichert sind. Applikationscontainer unterstützen dabei auch eine Versionierung von Anwendungen. Dazu müssen spezielle Rahmenbedingungen geschaffen werden, die unten in einem Beispiel gezeigt werden. Ein einfaches Erstellen einer Tabelle in einem Applikationscontainer reicht also nicht, um diese allen Anwendungs-PDB zugänglich zu machen. Vielmehr muß im Applikationscontainer in einer speziellen Syntax eine Anwendung mit einer angegebenen Version installiert werden. Entsprechend können Sie später diese Anwendung patchen und upgraden.

    Am folgenden kleinen Beispiel erkennen Sie das Prinzip:

    SQL> ALTER PLUGGABLE DATABASE APPLICATION mywdg_app BEGIN INSTALL '1.0';
    SQL> CREATE USER wdg IDENTIFIED BY wdg CONTAINER=ALL;
    SQL> GRANT CREATE SESSION, DBA TO wdg;
    SQL> SQL> CREATE TABLE wdg.plz_verzeichnis SHARING=DATA (PLZ number,ort varchar2(100));
    SQL> INSERT INTO wdg.plz_verzeichnis VALUES (59556 , 'Lippstadt'); COMMIT; 
    SQL> ALTER PLUGGABLE DATABASE APPLICATION mywdg_app END INSTALL '1.0';
    

    Sie beginnen also eine Installation einer Anwendung und erstellen einen Datenbankbenutzer mit der Option CONTAINER=ALL. Unter diesem Benutzer, oder auch mehreren, erstellen Sie dann die Datenbankobjekte. Es gibt dabei drei Varianten der gemeinsamen Nutzung von Objekten:

    Nachdem die Anwendung im Applikationscontainer installiert ist, müssen Sie einen SYNC durchführen mit

     SQL> ALTER PLUGGABLE DATABASE APPLICATION mywdg_app SYNC;
    

    Erst dann sind die neuesten Definitionen verfügbar. Damit können also auch neue Versionen von Anwendungen im Applikationscontainer vorbereitet werden, ohne dass die Anwendungs-PDBs davon betroffen sind. Erst nachdem die neue Version getestet und freigegeben ist, schalten Sie die neue Version mit dem SYNC Kommando "scharf".

Zurück zum Anfang des Artikels

Data Guard und No Force Logging

Während Oracle Data Guard von vielen Kunden gerne für OLTP Systeme eingesetzt wird, gab es in der Vergangenheit durchaus Vorbehalte das Gleiche für Analyse-Systeme und DWH Datenbanken zu tun. Der Grund ist dabei nicht etwa, dass DWH Systeme keine Standby Datenbank brauchen! Vielmehr liegt dies an den notwendigen Voraussetzungen für Standby Datenbank. Die wichtigste ist der Archivelog Modus der Datenbank mit der zusätzlichen Option auch wirklich alle Aktionen der Primärdatenbank zu protokollieren. Eine Standby Datenbank befindet sich im ständigen Recovery und muss daher alle Änderungen über die Redologs nachziehen.

Somit ist der sogenannte "Force Logging" Modus der Primärdatenbank eine implizite Vorausetzung für Data Guard - zumindest bis 12.2. Force Logging hat dabei zwei Auswirkungen: Einmal führt es dazu, dass durch die Erzeugung von Redo für jede Aktion gerade Ladejobs der Primärdatenbank immens ausgebremst werden. Andererseits stellt das gestiegene Redolog-Aufkommen auch größere Anforderungen sowohl an die Bandbreite zur Standby Datenbank, als auch an deren Recovery Prozesse. Dabei wurde gerade für der Recovery Prozess mit jedem neuen Release beständig verbessert, so dass mit 12.1 eigentlich fast jede Standby Datenbank mit der Produktion mithalten kann. Falls also mit einer Oracle 10g Datenbank eine Data Guard Umgebung nicht möglich war, sollte durchaus einem aktuellen 11.2 oder 12.1 Data Guard Verbund eine Chance geben.

Die Last auf der Primärseite durch das Logging bleibt aber weiterhin bestehen, sollte der Force Logging Modus verwendet werden. Genau hier setzt eines meiner Lieblingsfeature von 12.2 an: Die Möglichkeit das Primärsystem ohne "Force Logging" zu betreiben und dennoch problemlos eine Data Guard Umgebung betreiben zu können. Aber wie ist das möglich?

No-Logging Operation erzeugen immer schon so viel Redo Informationen, dass die Standby Datenbank weiß, welche Blöcke nicht mehr o.k. sind. Bei Active Data Guard würde man zum Beispiel bei einem Zugriff auf einen solchen Block folgende Fehlermeldung erhalten:

ORA-01578: ORACLE data block corrupted (file # 1, block # 2521)
ORA-01110: data file 1: '/oracle/dbs/stdby/tbs_1.dbf'
ORA-26040: Data block was loaded using the NOLOGGING option
Neu ist nun, dass dies im Controlfile protokolliert wird und über die View V$NON_LOGGED_BLOCK abgefragt werden kann.

Diesen Umstand kann sich in 12.2 und Physical Data Guard nun auch RMAN zu Nutze machen und die Blöcke, die durch eine No-Logging Operation geändert worden sind über ein Block Recovery von der Primary wiederherstellen. Hierzu muss nur das Recovery auf der Standby angehalten werden und der RMAN Befehl "RECOVER DATABASE NONLOGGED BLOCK;" verwendet werden.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

RMAN> RECOVER DATABASE NONLOGGED BLOCK;
Zusätzlich hat man auch die Möglichkeit die Standby Seite auf No-Logging Blöcke zu überprüfen. Dies geschieht ebenfalls mit RMAN:
RMAN> VALIDATE DATABASE NONLOGGED BLOCK;
Allerdings protokolliert V$NON_LOGGED_BLOCK dabei nicht zwingend nur die korrupten Blöcke. Es kann durchaus vorkommen das ein etwas größerer Bereich protokolliert wird, der auch Blöcke enthält die eigentlich in Ordnung sind, aber in direkter Nähe zu den korrupten Blöcken stehen. Dies dient dazu weniger Platz im Controlfile zu belegen. Nach einem VALIDATE können auch hier die fehlerhaften Blöcke von der Primärseite wiederhergestellt werden.

Unter Umständen kann es passieren, dass das Recovery auf einen Fehler läuft. Dies kommt insbesondere dann vor, wenn der Datenbankwriter der Primärdatenbank die Blöcke noch nicht in die Datenfiles hinunter geschrieben hat. In diesem Fall muss der RECOVER Befehl einfach erneut ausgeführt werden.

Interessant in diesem Zusammenhang ist noch der Datenbank Parameter DATA_TRANSFER_CACHE. Dieser gibt die Größe eines Speicherbereiches in der SGA an, der für den Transfer solcher No-Logging Blöcke beim Recover Kommando vorgesehen ist und wird automatisch ermittelt oder explizit angegeben, wenn nicht Automatic Memory Management verwendet wird.

Dank der neuen 12.2 Funktionalität des "RECOVER ... NOLOGGED BLOCK;" steht nun Data Guard und Standby Datenbanken auch Datenbanken zur Verfügung, die bis heute auf Grund von Performance Anforderungen auf No-Logging Operationen nicht verzichten können. Eindeutig einer meiner Favoriten für das Feature von 12.2 im Bereich HA, neben vielen anderen...

Zurück zum Anfang des Artikels

Bessere Isolation und genauere Performance-Steuerung für PDBs

Grundsätzlich sind PDBs innerhalb einer CDB zwar schon immer logisch voneinander getrennt gewesen, die Ressourcenaufteilung und Isolation auf technischer Ebene basierte bisher jedoch überwiegend auf der Prämisse, dass sich einzelne PDBs "gutartig" verhalten. So konnten mittels des Resource Managers zwar CPU-Leistung, Parallel Query Slaves und Storage-I/O für einzelne PDBs gesteuert werden (letzeres allerdings nur für Engineered Systems), nicht aber z.B. der SGA-Verbrauch.
Ähnlich sah es bei der Nutzung von System-Ressourcen und -Privilegien aus: So kann man in 12.1 z.B. nicht verhindern, dass ein PDB-User beim Zugriff auf das Betriebssystem - etwa durch Nutzung des "host"-Kommandos von SQL*plus - dort die gleichen Rechte hat wie der "normale" OS User (gewöhnlich "oracle") auf Ebene der CDB.

Diese Aspekte werden mit Oracle 12.2 erheblich verbessert und erweitert. Zum einen stehen nun folgende Parameter auch auf PDB-Ebene zur Verfügung:

Zum anderen ist das I/O-Management nun auch für "generischen" Storage möglich (also auch außerhalb von Engineered Systems). Dazu dienen die Parameter "Max_IOPS" (zur Beschränkung der I/Os pro Sekunde) sowie "Max_MBPS" (zur Beschränkunge des Storage-Durchsatzes), welche pro PDB gesetzt werden können.
Auch Systemzugriff (über das Spezifizieren eines gesonderten OS Users pro PDB) und Dateisystemzugriff (über das Setzen von speziellen Pfad-Präfixen pro PDB) können in 12.2 auf Wunsch reglementiert werden.

Darüber hinaus wurde mit dem Feature "Lockdown Profiles" ein neues Konzept eingeführt, welches eine genaue Steuerung der Nutzung verschiedener Systemressourcen- und Privilegien für jede PDB erlauben:

Lockdown Profiles

Betrachten wir die Verwendung von Lockdown Profiles am besten anhand eines Beispiels:

Ein Entwickler soll in "seiner" PDB PL/SQL Code schreiben und auch debuggen können. Dazu benötigt er Einfluss auf die Parameter "PLSQL_DEBUG", "PLSQL_CODE_TYPE", "PLSQL_WARNINGS", was widerum im "alter system"-Privileg enthalten ist. Letzteres enthält aber auch Möglichkeiten zur bewussten oder unbewussten Beeinträchtigung der Gesamtperformance (z.B. durch Ändern von von "OPTIMIZER_MODE") welche man einem Entwickler eher nicht geben würde. Der CDB Admin kann nun ein Lockdown Profile definieren, um genau dies zu erreichen:

alter lockdown profile Dev_PDB
disable statement = ('ALTER SYSTEM')
clause = ('SET')
option = ALL EXCEPT
('plsql_code_type', 'plsql_debug','plsql_warnings');

Eingeschaltet wird das Lockdown Profile dann durch ein entsprechendes "alter system" Kommando des CDB Administrators für die jeweilige PDB:

alter system set pdb_lockdown = Dev_PDB;

Ab diesem Moment kann ein Entwickler mit "alter system" Privileg in der so vorbereiteten PDB zwar die "erwünschten", PL/SQL-spezifischen Parameter ändern, nicht aber auf die "unerwünschten", restlichen Parameter die normalerweise mit diesem Privileg änderbar wären.
Näheres zur Verwendung von Lockdown Profiles kann der Dokumentation entnommen werden.

Zurück zum Anfang des Artikels

Case-insensitive Datenbank - das Feature für den Datenbank Entwickler

Die Oracle Datenbank unterstützt seit langer Zeit schon die case-insensitive Sortierreihenfolge: Dazu erforderlich ist beispielsweise die Einstellung des Parameter NLS_SORT mit Werten wie BINARY_CI oder GENERIC_M_CI. In der Session gesetzt oder zu SQL Operationen hinzugefügt, kann man damit case-insensitive Zeichenkettenvergleiche durchführen.

Neu mit Oracle Database 12c Release 2 (12.2) ist nun die Möglichkeit eine Sortierreihenfolge (auch engl. collation) für Spalten beim CREATE TABLE festzulegen - ähnlich wie bei der Festlegung auf einen Datentyp. Auf diese Weise können Spalten einer Applikation als case-insensitiv gelten, ohne dass ein Datenbank Entwickler explizit Funktionen wie UPPER oder LOWER hinzufügen muss. Das Ganze geht soweit, dass ein "normaler" Index in diesem Zusammenhang sogar zum passenden Function Based Index umfunktioniert wird. Alles passiert dabei automatisch ohne dass man dies bei der Programmierung einer Applikation beachten muss.

Folgende kleine Beispiele zeigen die einfache Vorgehensweise. Nehmen wir an, wir haben ein Tabelle TAB_CI, die eine case-insensitive Spalte WORT besitzen soll. In 12.2 kann die Syntax dann folgendermaßen aussehen. Beachten Sie bitte den Zusatz "COLLATE binary_ci" in der Spaltendefinition.

create table tab_ci 
    (n number, 
     wort varchar2(100) collate binary_ci)
Nun fügen wir in die Spalte WORT einige unterschiedlich geschriebene Werte ein wie z.B. klein, Klein und KLEIN. Beim Selektieren muss man nun keinerlei Rücksicht auf die Groß- und Kleinschreibung nehmen, wie folgendes Beispiel zeigt.
SQL> select * from tab_ci where wort='Klein'
         N WORT
---------- ----------
         1 klein
         2 KLEIN
         3 Klein
Der Ausführungsplan legt natürlich - wie auch in anderen Fällen - die Funktionsweise offen: Intern wird NLS_SORT verwendet, wie man im Filter erkennen kann.
Execution Plan
----------------------------------------------------------
Plan hash value: 321651591

----------------------------------------------------------------------------
| Id  | Operation         | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |        |     1 |    65 |     3   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| TAB_CI |     1 |    65 |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter(NLSSORT("WORT",'nls_sort=''BINARY_CI''')=HEXTORAW('6B6C656
              96E00'))
Legt man einen Index auf die Spalte, wird dieser sofort zu einem Function Based Index umfunktioniert, ohne dass man sich um die Funktion kümmern muss.
SQL> create index i_tab_ci on tab_ci (wort);
Index created.

SQL> select index_type from user_indexes where index_name='I_TAB_CI';

INDEX_TYPE
---------------------------
FUNCTION-BASED NORMAL
Diese Eigenschaft kann Übrigens schon vorher - nämlich in der Definition des Users - mitgegeben werden, so dass eine Default Einstellung beim Anlegen von Tabellen implementiert ist. Der User kann dann die Standardsyntax beim Anlegen von Tabellen ohne Erweiterung verwenden und ohne Zutun Case-Insensitivität automatisch nutzen. Die Datenbank ist quasi "case-insensitiv by default"!

Dieses Features existiert natürlich nicht nur für die Groß- und Kleinschreibung, sondern kann für weitere Werte von NLS_SORT wie GERMAN, XGERMAN, XGERMAN_CI, FRENCH, FRENCH_M_AI usw.

Wichtiger Hinweis und Voraussetzung: Bevor man startet muss man allerdings wissen, dass das Feature nur in Zusammenhang mit dem Wert EXTENDED bei MAX_STRING_SIZE funktioniert; der Defaultwert STANDARD ist nicht ausreichend.

Zurück zum Anfang des Artikels

Weitere Informationen

 

Zurück zum Anfang des Artikels

Zurück zur Community-Seite