Migrieren ohne Downtime - ein Oracle 12.2 Feature

Migration OHNE Downtime – ein cooles Oracle 12.2 New Feature

Mit der Release 2 der Oracle Datenbank 12c bekommt der DBA eine Vielfalt neuer Funktionalitäten, die dem Datenbankadministrator die Arbeit in Zukunft um einiges erleichtern werden. Eines dieser neuen Features ist das Hot Cloning und Relocate von Pluggable Databases, das in diesem Artikel kurz näher vorgestellt wird.

Die Oracle Datenbank 12c Release 2 bringt mit der Multitenant-Architektur viele tolle Features, die man vorher nicht benutzen konnte. Zuallererst sollten wir aber die Aussage des Artikeltitels ein wenig einschränken und erläutern, welcher Themenkreis in diesem Artikel beleuchtet wird.
Eine Migration ohne Downtime ist mehr ein Wunsch als Wirklichkeit, aber mit der Version 12.2 kommen wir dem Ziel näher. Im gegenständlichen Artikel werden wir über die Möglichkeit Pluggable Databases online zu kopieren/migrieren beschreiben.

Ein Blick in die Vergangenheit

In der Version 11.2 hatte der Datenbankadministrator folgende Möglichkeiten, um eine Datenbank von einem System auf ein anderes System zu migrieren:

  • Duplicate
  • Datapump
  • Restore/Recover via RMAN
  • GoldenGate

Welchen Weg man letztendlich wählen wird, hängt ganz von der Situation und den Voraussetzungen ab. Es geht hier nicht um Cross-Platform-Migrationen oder um Migrationen zwischen Systemen mit unterschiedlicher Endianness. Jede Option verlangt gewisse Vorbereitungen und birgt auch mögliche, verborgene Gefahren mit sich, die dann erst im Zuge der Migration sichtbar werden.

Variante „Duplicate“

Bei einem Duplicate hat der Benutzer die Möglichkeit entweder direkt über SQL*Net, oder aus einem vorhandenen Backup, eine Kopie der Datenbank zu erstellen. Die Duplicate Methode ist eigentlich die einfachste, weil man hier entweder nur Firewall Freischaltungen zwischen den Servern benötigt oder man alternativ auf ein Backup, meistens von einem NFS Share oder einer Bandsicherung, zugreift. Wenn zwischen den Servern ein leistungsstarkes Netzwerk zur Verfügung steht, dann führt man am besten den Befehl DUPLICATE TARGET DATABASE TO … FROM ACTIVE DATABASE aus oder benutzt Backups die entweder in einer BACKUP LOCATION gespeichert oder aus Bandsicherungen gezogen werden.  Oracle automatisiert dabei einige Tätigkeiten die man bei Restores sonst manuell machen muss. Grundsätzlich ist es ein automatischer Restore/Recover der Quelldatenbank mit Veränderungen der Datafile Pfade und der DBID.

Variate „Datapump“

Die Variante Datapump ermöglicht dem Datenbankadministrator logische Datenbankbackups zu erstellen, auf ein neues Ziel zu übertragen und dort wieder zu importieren. Datapump bietet auch Features wie Transportable Tablespace oder Full Transportable Export. Dabei werden nur Metadaten exportiert und diese dann mit allen Datafiles kopiert und am Ziel importiert.

Variante „klassische Migration“

Bei der klassischen Migration einer Datenbank mittels RMAN Restore/Recover wird eine Datenbank auf Basis eines Backups neu aufgebaut.

Variante „GoldenGate“

Als letzte Option bleibt GoldenGate. Bei GoldenGate handelt es sich um eine kostenpflichtige Replikationssoftware, die es erlaubt nahezu Zero Downtime Migrationen durchzuführen. GoldenGate unterstützt zudem auch noch andere Datenbankanbieter wie MySQL, MS SQL und Hadoop.

Multitenant Architektur

Mit der Version 12.1 hat Oracle eine neue Datenbankarchitektur eingeführt – die Multitenant Architektur (CDB Architektur). Die Multitenant Architektur wird in Zukunft die derzeitige Non-CDB Architektur ersetzen. In der 12.1 Dokumentation findet man bereits den entsprechenden Hinweis auf die „Deprecation of Non-CDB Architecture“ für kommende Oracle Releases nach 12.2. Oracle empfiehlt hier auf die CDB Architektur zu schwenken. Multitenant ist prinzipiell eine kostenpflichtige Option zur Enterprise Edition, jedoch als Single tenant in allen Oracle Editionen enthalten.

Container Datenbank

Während es vor 12.1 nur eine 1:1-Beziehung zwischen Instanz und Datenbank gab (beim RAC ist es eine n:1-Beziehung), verändert sich das jetzt mit der Multitenant Architektur. In der Multitenant Architektur werden alle gemeinsamen Systemobjekte in eine neue, zentrale, Datenbank – die Container Datenbank (CDB) – gepackt, die alle notwendigen Funktionalitäten bereits vorinstalliert hat. Die eigentlichen Benutzerdaten befinden sich in sogenannten Pluggable Databases (PDB), die in die Containerdatenbank eingehängt werden.

In der Version 12.1 konnte man Datenbanken, die bereits als Pluggable Database definiert waren wesentlich einfacher kopieren, als noch in älteren Versionen ohne Multitenant Architektur. Man musste die Quelldatenbank lediglich in den Read Only Modus setzen und anschließend ein CREATE PLUGGABLE DATABASE Statement ausführen. Im einfachsten Fall bekommt man mit dem Kommando CREATE PLUGGABLE DATABASE ORCL2 FROM ORCL1 bereits eine lokale Kopie der Datenbank.

Mit der Multitenant Architektur bringt Oracle dem Benutzer eine Vielfalt von Features die das Provisionieren von Datenbanken leichter machen. Man bekommt eine Konsolidierungsplattform für Datenbanken in der man mit dem Ressource Manager Systemressourcen optimal zuteilen kann um wichtigeren Datenbanken mehr Performance zuzusichern. Weiters eine Automationsplattform in der man Datenbank Templates vordefinieren kann um im Anlassfall schnell PDBs zu erstellen oder klonen zu können. Das Kopieren von PDBs geht in 12.1 nicht ganz ohne Downtime ab. Im Internet findet man Artikel die ohne den Read Only Modus eine Kopie der PDBs ermöglichen, in 12.1 ist es jedoch nicht möglich PDBs online zu kopieren. Die Quelldatenbank geht hier in den Quiesce Modus, was mit einer Downtime vergleichbar ist.

Die Gegenwart – Hot Cloning und Relocate

Mit der Version 12.2 wird der Traum des DBAs jedoch endlich wahr: Die von vielen erwartete Lösung für das online kopieren von PDBs. Dieses Feature kommt in Begleitung mit einem anderen neuen Feature, den Local Undo Tablespaces. Um Datenbanken wirklich online kopieren zu können, braucht man die Container Datenbank im Local Undo Mode (und natürlich im Archivelog Mode).
Das Aktivieren des Local Undo Modes in der CDB erstellt automatisch in jeder PDB einen eigenen Undo Tablespace, welcher wiederum Voraussetzung für Flashback, PDBPITR und Hot Cloning in der PDB ist.

Um den Leser nicht weiter auf die Folter zu spannen, schauen wir uns das RELOCATE-Feature in Aktion an. Hier wird die Datenbank automatisch auf eine andere Instanz transferiert und alle DMLs und DDLs bis zum Öffnen der Pluggable Datenbank werden automatisch im Hintergrund verarbeitet, um die Datenbank konsistent zu halten.

In unserem Szenario haben wir 2 virtuelle Maschinen, ora01 und ora02 mit  Version 12.2.0.1 Enterprise Edition installiert, die ora01 verwaltet die cdb1 und ora02 die cdb2.

Beide Datenbanken sind im gleichen Netz, als Storage benutzen wir ASM, das erleichtert auch die Namenskonvention für die Datafiles. Diese Funktionalität (mit und ohne RELOCATE) funktioniert auch in der 12.2 SE2.

Um keine Lizenzverletzung zu begehen, denken Sie daran, dass in einer CDB nur eine Benutzer PDB existieren darf. Mehrere Benutzer PDBs verlangen die Multitenant Option und damit Enterprise Edition.

 

sys@cdb1 SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 ORCL                           MOUNTED

sys@cdb1 SQL> alter pluggable database orcl open ;
Pluggable database altered.

sys@cdb2 SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO

Um die Datenbank auf die neue Maschine zu transferieren, sind ein paar Vorbereitungen nötig. Zuerst ist ein Common User anzulegen, der die notwendigen Privilegien bekommt. Ein in der Dokumentation offensichtlich entdeckter Fehler wird am Ende des Beispiels beschrieben.

sys@cdb1 SQL> create user c##dba identified by oracle container=all ;
User created.

sys@cdb1 SQL> grant create session, create pluggable database to c##dba container=all ;
Grant succeeded.

sys@cdb1 SQL> grant sysoper to c##dba container=all ;
Grant succeeded.

Um die PDB zu erreichen, brauchen wir einen Connect-Descriptor, der die Datenbank identifiziert. In unserem Beispiel werden wir den Alias CDB1 in der tnsnames.ora der CDB2 anlegen.

CDB1 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = ora01)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = cdb1)
    )
  )

Als vorletzte Voraussetzung brauchen wir einen Public Database Link von der CDB2 in die CDB1.

 

sys@cdb2 SQL> create public database link cdb1 
connect to c##dba identified by oracle using 'cdb1' ;
Database link created.

Nachdem wir alle Voraussetzungen erfüllt haben, können wir die Datenbank auf die CDB2 migrieren. Diese Tätigkeit erledigt man mit einem Kommando auf der CDB2:

sys@cdb2 SQL> create pluggable database orcl from orcl@cdb1 relocate ;
Pluggable database created.

Nach dem Erstellen der PDB bleibt die neue PDB in der CDB2 im Zustand MOUNTED. Ohne den Zusatz RELOCATE würden wir einen Hot Clone der PDB „orcl“ erstellen. Um die Near Zero Downtime Migration zu zeigen, erstellen wir in der PDB „orcl“ auf CDB1, die immer noch im Read Write Modus ist, einen neuen Benutzer und eine Tabelle.

sys@cdb1 SQL> alter session set container=orcl ;
Session altered.

sys@cdb1 SQL> create tablespace data ;
Tablespace created.

sys@cdb1 SQL> create user psorger identified by oracle default tablespace data quota unlimited on data;
User created.

sys@cdb1 SQL> grant connect, resource to psorger ;
Grant succeeded.

sys@cdb1 SQL> create table PSORGER.EMP as select level id from dual connect by level<=10 ;
Table created.

Nachdem wir die Tabelle erstellt haben, können wir die neue PDB in der CDB2 öffnen.
Mit dem folgenden Kommando wird die PDB auf CDB1 gelöscht und die PDB auf CDB2 im Read Write Modus geöffnet.

sys@cdb2 SQL> alter pluggable database orcl open ;
 Pluggable database altered.

sys@cdb2 SQL> alter session set container=orcl ;
 Session altered.

sys@cdb2 SQL> select count(*) from psorger.emp ;

COUNT(*)
 ----------
 10

Nach dem Öffnen der neuen PDB sehen wir, dass alle DML/DDL Statements erfolgreich übertragen wurden.

Um den Fehler in der Dokumentation zu beschreiben werden wir dem C##DBA die Rolle SYSOPER entziehen und SYSDBA vergeben. Mit dieser Rolle vergibt man eigentlich Superprivilegien und logischerweise erwarten wir, dass das funktioniert.

sys@cdb1 SQL> revoke sysoper from C##DBA container=all ;
Revoke succeeded.

sys@cdb1 SQL> grant sysdba to C##DBA container=all ;
Grant succeeded.

sys@cdb2 SQL> select sysdate from dual@cdb1 ;

SYSDATE
---------
09-MAY-17

sys@cdb2 SQL> create pluggable database orcl from orcl@cdb1 ;
Pluggable database created.

sys@cdb2 SQL> create pluggable database orcl1 from orcl@cdb1 relocate ;
create pluggable database orcl1 from orcl@cdb1 relocate
*
ERROR at line 1:
ORA-17628: Oracle error 1031 returned by remote Oracle server
ORA-01031: insufficient privileges

Wie wir hier sehen ist ein Online Clone der Datenbank möglich, aber beim Relocate bekommt der C##DBA mit SYSDBA Privilegien dennoch einen insufficient Privileges Fehler.
Es scheint, dass man dieses Verhalten als einen Bug entweder in der Dokumentation oder in der Software bezeichnen kann.
In der Zukunft werden wir es bestimmt erfahren. 🙂

Um diesen Artikel abzurunden, möchte ich noch die neuen Features der Oracle Public Cloud erwähnen.

Ein neues Feature, der direkte SQL*Net Zugang in die Cloud, erleichtert ab 12.2 die Migration von On-Premise Datenbanken in die Cloud und zurück. Mit diesen zwei neuen Features bekommt der Benutzer die Möglichkeit sehr einfach in die Cloud zu wechseln, dort etwa Performance-Tests durchzuführen und dann die Datenbank wieder zurück ins eigene Rechenzentrum zu verschieben.

Gerade das ist ein Feature, das bei anderen Cloud-Anbietern aktuell kaum zu finden ist!

Oracle Scheduler Jobs Kurzfassung

Oracle Scheduler Jobs – eine Kurzfassung

Wer regelmäßig automatische Vorgänge in seiner Datenbank laufen lässt, wie zum Beispiel das Aufrufen von Services, Datenübernahmen oder regelmäßige Berechnungen, der wird sehr bald auf Oracle Scheduler Jobs treffen. Diese können auf verschiedene Arten regelmäßig Prozeduren und ähnliches in regelmäßigen Abständen ausführen.

Die grundlegende Definition benötigt zumindest folgende Parameter:

  • job_name: der Name des Scheduler Jobs
  • job_type: der Typ des Scheduler Jobs, ist es ein PL/SQL Block oder ein direkter Prozeduraufruf, …
  • job_action: der tatsächlich auszuführende Ausdruck (abhängig von job_type)

und würde dann so aussehen:

Weiterlesen

Düsseldorf Oracle Lizenzierung Seminar Kostenbremse

Erstmals in Düsseldorf – das Oracle Lizenzierungs Seminar

Aufgrund mehrer Anfragen haben wir uns entschieden, am 21. Mai 2016 zum ersten Mal in Düsseldorf unser bekanntes Seminar zum Thema Oracle Software Lizenzierung abzuhalten.

Bisher war es den deutschen Kollegen/innen nur möglich, das Seminar in Österreich zu besuchen.

Obwohl der Seminarort Salzburg immer gerne gebucht wurde, ist die Entscheidung für Düsseldorf natürlich für alle Lizenzmanager und Oracle Datenbank Administratoren aus NRW und den angrenzenden Bundesländern aufgrund der kurzen Anreise eine attraktive Option.

Wir sind überzeugt, dass es mit den zahlreichen Tipps und Praxis Beispielen wahrscheinlich kein anderes Seminar  in dieser Form gibt.

Wie das Feedback der Seminar Teilnehmer zeigt, ist das vermittelte Know-how sofort anwendbar und der Nutzen in kürzester Zeit umzusetzen.

Alle weiteren Details zu den Inhalten, zum Termin und Veranstaltungsort sowie die Anmeldung zum Seminar finden Sie auf der Webseite zum Oracle Software Lizenzierung Seminar – Düsseldorf.

 

Oracle streicht 450 Support Stellen

Oracle streicht in Europa 450 Stellen im Support

Wie zahlreiche Medien berichten, baut Oracle in Europa 450 Stellen im Support ab, alleine 150 davon in Deutschland. Ziel der Maßnahme ist die Verlegung des Supports nach Rumänien.

Alle europäischen Oracle Support Standorte sollen bis Ende März 2016 geschlossen werden – das betrifft sämtliche Support-Zentren mit den Ausnahmen von England, Holland und Rumänien.

Zukünftig werden die Support Anfragen aus Deutschland, Österreich und der Schweiz von rumänischen Oracle Support Mitarbeiter/innen beantwortet.

Wie sehr diese Entwicklung Auswirkungen auf die Qualität der deutschsprachigen Unterstützung und auf die dahinter stehenen Prozesse haben wird, kann nur die Praxis zeigen.

DBConcepts – wir sprechen Ihre Sprache

Bei wichtigen und dringenden Support Aufgaben ist es oft von Vorteil, wenn alle Gesprächspartner die gleiche Sprache sprechen und sich auch in der selben Zeitzone befinden.

Alle unsere Remote DBA Mitarbeiter/innen sprechen selbstverständlich Deutsch, um Sie ohne Verständigungsprobleme optimal bei Ihren Anforderungen unterstützen zu können.

Wir befinden uns in Ihrer Zeitzone und sind nur einen Anruf entfernt.

Link: Weiter Infos zu Datenbank Fernwartung durch Remote DBA >>

 

Medien Quellen:

http://www.it-zoom.de/dv-dialog/e/oracle-support-rumaenien-12621/

http://www.heise.de/ix/meldung/Deutscher-Oracle-Kundendienst-schliesst-Ende-Maerz-3117680.html

DOAG Artikel

 

Oracle Datenbank Upgrade 12c

Upgrade auf Oracle 12c

Vieles scheint sich zu verändern: Ganze Datacenter wandern in die Cloud, neue Lösungsangebote wie Database as a Service betreten den Markt, der Trend zur Virtualisierung scheint ungebrochen, Solid State Drives werden herkömmliche Festplatten wohl bald gänzlich ersetzen, Big Data und Datamining sind in aller Munde.

Doch manches verändert sich nicht so schnell: Genauso wichtig wie unternehmerische Innovationen und technologische Paradigmenwechsel ist die Fortführung von bewährten Technologien. Entgegen mancher kurzzeitiger Moden bildet das relationale Datenmodell immer noch das stabile Fundament für viele Anwendungen.

Die IT-Landschaft verändert sich in rasendem Tempo, und Oracle bildet hier keine Ausnahme.
Im Gegenteil: Mit dem Release der Datenbankversion 12c ebnet Oracle diesen Ent-wicklungen den Weg und eröffnet neue und vielversprechende Perspektiven für den Betrieb von Datenbanken, ohne dabei die Stärken einer relationalen Datenbank aufzugeben.

Mit 12c ist es Oracle gelungen, beide Anforderungen zu erfüllen:
Mit der Entwicklung von Features wie Pluggable Database und InMemory wird ein zukunftsweisender Weg aufgezeigt, mit der kontinuierlichen Weiterentwicklung der Stärken der Release 11gR2 eine Erfolgsgeschichte weitergeschrieben.

Wie sich auch entscheiden, wir möchten Sie mit unserem Know-How auf ihrem Weg unterstützen. Doch bevor die Reise beginnt, werfen wir noch einen Blick auf die Gegenwart.

Roadmap 11gR2

Wie bereits über verschiedene Kanäle angekündigt, neigt sich die Unterstützung von Release 11gR2 dem Ende zu. Die Version 11gR2 wurde im Jahr 2009 erstmals veröffentlicht, seitdem erschienen mehrere Subreleases. Momentan ist die Version 11.2.0.4 aktuell, wobei diese Version auch die letzte sein wird (Oracle spricht hier vom terminal patchset).

Das Release 11gR2 wird zwar in Form von PSUs (Patch Set Updates) noch weiter gepflegt, aktuelle Entwicklung findet aber keine mehr statt.

Release  Patching End Date

11.2.0.1  13.09.2011
11.2.0.2  31.10.2013
11.2.0.3  27.08.2015
11.2.0.4  31.01.2018

Wie aus der Tabelle ersichtlich wird, endet das Patching für die Version 11.2.0.3 noch dieses Jahr, bei 11.2.0.4 bleibt noch ein wenig mehr Zeit. Dies betrifft jedoch nur die Bereitstellung von Patches und PSUs, nicht den Support. Hier sieht es anders aus.

 

Premier Support Ends

Achtung: Der Premier Support für 11gR2 ist mit Ende Jänner 2015 ausgelaufen!

Oracle bietet die Möglichkeit, für ein zusätzliches Jahr den sog. „Free Extended Support“ in Anspruch zu nehmen.

Dies ist für alle Kunden mit einem aufrechten Support-Vertrag möglich.

Um in den Genuss von „Free Extended Support“ zu kommen, ist es erforderlich, dass sie bei Oracle einen Vertrag anfordern. Sie bekommen dann eine Rechnung über den Betrag von 0 Euro ausgestellt, der die Aktivierung des „Free Extended Supports“ ausweist. Nach Ablauf des kostenlosen „Free Extended Support“erfolgt keine automatische Verlängerung des Supportvertrags. Ab dem zweiten Jahr (also nach 31.01.2016) würden die vollen Sup-portgebühren anfallen. Sofern sie den „Free Extended Support“ beantragen, ist nach Ablauf des Vertrags nichts mehr zu machen. Sie brauchen den Vertrag weder kündigen, noch wird dieser zu den regulären Supportpreisen verlängert.

Wie aus der Tabelle (siehe unten) ersichtlich wird, ist der „Free Extended Support“ nur für die Version 11.2.0.4 von Relevanz.

Für die Version 11.2.0.3 endet der Support bereits in wenigen Monaten.

Oracle Support Roadmap

 

Release  Free Extended Support Ends

11.2.0.1 No Extended Support available
11.2.0.2 No Extended Support available
11.2.0.3 27.08.2015
11.2.0.4 31.01.2016

Der „Free Extended Support“ für 11.2.0.4 endet mit Ende Jänner 2016. Ab diesem Zeitpunkt gibt es nur mehr den kostspieligen „Extended Support“, der maximal bis Ende Jänner 2018 verlängert werden kann.

 

Release 12c

Das Datenbank-Release 12c wurde am 22.06.2013 zum ersten Mal veröffentlicht. Mittlerweile (Stand: Februar 2015) steht die Release 12.1.0.2 zur Verfügung. Allerdings betrifft dies nur die Enterprise Edition der Datenbank, für die Standard Edition ist das letzte verfügbare Patchlevel 12.1.0.1.6.

 

Edition      Release and PSU-Level

Enterprise   12.1.0.2.2 (includes PSU Jan2015)

Standard      12.1.0.1.6 (includes PSU Jan2015)

 

Ein „Direct Upgrade“ auf 12c ist nur von folgenden Versionen aus möglich:

•             ≥ 10.2.0.5
•             ≥ 11.1.0.7
•             ≥ 11.2.0.2

Sollten sie eine ältere Version im Einsatz haben, ist ein Zwischenschritt notwendig. Doch auch hier gibt es wie immer mehrere Möglichkeiten.

Wir beraten sie gerne hinsichtlich der möglichen Upgrade-Szenarien und stimmen dieses gerne auf ihre Anforderungen hinsichtlich Downtime und Applikationstests ab.

 

Neben der in Verwendung befindlichen Version des RDBMS spielt das Client-Umfeld eine entscheidende Rolle für ein erfolgreiches Upgrade auf 12c.

  • Welche JDBC-Versionen sind im Einsatz?
  • Welche Client-Versionen verbinden sich zur Datenbank?
  • Wurde am Applikationsserver ein Connection Pool konfiguriert?
  • Und wie authentifizieren sich die Clients gegenüber der Datenbank?

Das sind nur einige der Fragen, die es im Vorfeld zu erheben gilt.

Wir unterstützen sie bei der Erfassung dieser Informationen und der möglicherweise notwendigen Konfigurationsänderungen.

 

Are you ready for Oracle 12c?

Um ihnen den Umstieg auf 12c so einfach wie möglich zu machen, bieten wir ihnen umfassende Prüfung ihrer Datenbanken und ihrer Clients im Vorfeld des Upgrades an.

 

Basierend auf unserer Erfahrung, die wir bei diversen Upgrades auf 12c sammeln konnten, haben wir einen Upgrade-Check erarbeitet, der in nicht-invasiver Weise die vorhandene Datenbank-Landschaft prüft und auf mögliche Stolpersteine beim Upgrade hinweist.

 

Am Ende des Prüfvorgangs erhalten Sie von uns einen detaillierten Bericht, wie sich ein Upgrade-Szenario darstellen würde, was hinsichtlich Datenbank und Client-Umfeld zu tun wäre und mit welchen Serviceeinschränk-ungen während des Upgrades zu rechnen wäre.

Dieser Check bildet die Grundlage für ein erfolgreiches Upgrade auf 12c.

Also: Sind sie dabei? Oder anders gefragt: Are you ready for 12c?

 

 

 

JavaScript Object Notation Support in Oracle 12c

JavaScript Object Notation Support in Oracle 12.1.0.2

Mit der Oracle 12c Release 12.1.0.2 hat die Oracle Datenbank JSON Unterstützung erhalten. JSON kann nun direkt gespeichert, abgefragt und auch indiziert werden. Im Folgenden soll dazu ein kurzer Überblick gegeben werden.

JSON steht für JavaScript Object Notation und beschreibt wie der Name schon ausdrückt eine Möglichkeit komplexe Objekte zu notieren und zu verarbeiten. Die Datenbank verwendet intern grundsätzlich immer UTF-8, entsprechend notwendige Konvertierungen bei der Ein- und Ausgabe werden automatisch durchgeführt.

Folgendes Beispiel eines Studenten soll dies verdeutlichen:

{    „Matrikelnummer“    : 123564869,
    „Name“    : „Otto Mayer“,
    „Studiengang“    : „Informationstechnik“,
    „aktuelles Semester“    : „WS2014/15“,
    „Fächer“    : [    „Business Englisch“,
            „Objektorientiertes Programmieren“,
            „Mathematik 3“]
}

Um nun ein JSON speichern zu können wird eine simple VARCHAR2 oder bei größeren Objekten eine CLOB Spalte verwendet. Neu dazukommen ist der Check-Constraint IS JSON um sicherzustellen, dass die Spalte auch wirklich immer valide JSON-Syntax enthält.

Eine Tabelle mit einer JSON Spalte sieht dann z.B. folgendermaßen aus:

CREATE TABLE students
    (id            RAW(16) NOT NULL,
    date_loaded   DATE,
    student_info  CLOB
    CONSTRAINT ensure_json CHECK (student_info IS JSON));

In diese Tabelle kann nun in die Spalte STUDENT_INFO ein Text im JSON-Format eingefügt ([…] wurde hier als Platzhalter verwendet) werden.

INSERT INTO students
VALUES ( sys_guid(),
        sysdate,
        ‘{      „Matrikelnummer“    : 123564869,
           „Name“            : „Otto Mayer“,
           [...] }’);

Die Daten können nun über eine ganz einfache Punkt-getrennte-Notation wie man sie von JavaScript kennt ausgelesen werden. Folgende SQL-Query ergibt z.B. das Ergebnis 123564869.

select st.student_info.Matrikelnummer
from students st

Es muss folgendes beachtet werden:

Die Schlüsselwerte sind case-sensitive – das gleiche muss in SQL berücksichtigt werden – das Statement oben würde kein Ergebnis liefern wenn statt „Matrikelnummer“ „matrikelnummer“ oder „MATRIKELNUMMER“ geschrieben wird. Sollten Leerzeichen oder Sonderzeichen wir Umlaute im Key sein – was grundsätzlich zu vermeiden ist – dann muss die entsprechende Angabe unter Anführungszeichen gesetzt werden also z.B.:

select st.student_info.”aktuelles Semester”
from students st

Sollte es sich um ein verschachteltes Objekt handeln so wird die Punkt-getrennte-Notation einfach auf allen Ebenen angewandt bis man bei dem gewünschten Wert angelangt ist.

Oracle bietet noch drei Funktionen die in SQL oder PL/SQL verwendet werden können die ich hier noch kurz beschreiben will: JSON_VALUE, JSON_QUERY, JSON_TABLE und JSON_EXISTS.

Allgemein nutzen alle JSON-Pfad-Notationen. Diese entspricht der Punkt-getrennten Notation die bereits besprochen wurde, und kann auch Elemente aus Arrays nutzen.

JSON_VALUE

Selektiert einen Wert wie zum Beispiel mit dem Ergebnis „Business English“ bei folgendem Query:

select json_value(st.student_info, '$.Faecher[0]')
from students st

JSON_EXISTS

Prüft ob ein bestimmer Schlüssel im JSON existiert. Das erste Query gibt ein Datum zurück bei allen Zeilen, denn das Array hat ein zweites Element (0 ist der Start-Index). Das zweite Query gibt nichts zurück da das Array nur 3 Elemente hat (und [3] das vierte Element abfragt).

select date_loaded
from students st
where json_exists(student_info, '$.Faecher[1]')


select date_loaded
from students st
where json_exists(student_info, '$.Faecher[3]')

JSON_QUERY

Im Gegensatz zu JSON_VALUE wird hier ein Teilstück des JSON selektiert und nicht nur ein Wert, folgendes Query gibt die Liste der Fächer zurück:

select json_query(student_info, '$[*].Faecher')
from students

JSON_TABLE

Diese Funktion dient dazu JSON-Daten in eine virtuelle Tabellenform zu überführen. Sie bietet damit die Möglichkeit im FROM-Teil der Query eingesetzt zu werden und dadurch mehrere Werte auf einmal ohne mehrmaliges Aufrufen von JSON_VALUE oder JSON_QUERY zu selektieren. Das bringt einen Geschwindigkeitsvorteil da die Daten so nur einmal geparst werden und nicht für jeden Funktionsaufruf immer wieder.

select jt.matrikelnummer, jt.fach1, jt.fach2, jt.fach3
from students st,
       json_table(st.student_info,
                 '$' COLUMNS(matrikelnummer NUMBER PATH '$.Matrikelnummer',
                         fach1 VARCHAR2(240) PATH '$.Faecher[0]',
                         fach2 VARCHAR2(240) PATH '$.Faecher[1]',
                         fach3 VARCHAR2(240) PATH '$.Faecher[2]')) jt

Die neuen JSON Funktionen bieten nützliche Werkzeuge, gerade im Zusammenhang mit APEX, dass durch seine Web-Browser Basis JavaScript massiv nutzt können sich dadurch hilfreiche Vereinfachungen implementieren lassen.

Weitere Infos zu JSON in der Oracle Datenbank finden sie hier:

http://docs.oracle.com/database/121/ADXDB/json.htm

Oracle 12c In-Memory Option Patchset 12.1.0.2

Oracle 12c mit In-Memory Option im Patchset 12.1.0.2 veröffentlicht

Am 22. Juli 2014 veröffentlichte Oracle Inc. das erste Patchset (12.1.0.2.0) für die 12c Datenbank.

Das Patchset enthält viele interessante neue Features, die es Wert sind, genauer unter die Lupe genommen zu werden.

  • Die bereits im Vorjahr auf der OpenWorld angekündigte In-Memory Option ist nun verfügbar.
    Die In-Memory Option enthält folgende Funktionalitäten:

    • In-Memory Column Store (Link)
    • Fault Tolerant In-Memory Column Store (setzt Exadata oder Supercluster voraus)
    • In-Memory Aggregation (Link)
    • ACHTUNG: Die In-Memory Option ist eine Option der Enterprise Edition und kann daher zu zusätzlichen Lizenzkosten führen (Link)
  • Force Full Caching Mode
    • Force Caching ist nun für alle Objekte möglich (Link)
    • Überprüfen Sie vorab, ob die Größe Ihre Datenbank in die SGA passt und aktivieren Sie dieses neue Features (ALTER DATABASE FORCE FULL DATABASE CACHING)
  • Automatic Big Table Caching
    • Dieses neue Feature ermöglicht es, große Tabellen in einem separaten Buffer zu speichern. Dadurch können Cache Rotations verhindert werden. (Link)
    • Der Big Table Cache ist ein Prozentteil des BUFFER CACHE. Es macht daher Sinn, die Memory Size zu überprüfen (zum Aktivieren verwenden Sie den DB_BIG_TABLE_CACHE_PERCENT_TARGET Paramteter)
    • Das Feature wird für Parallel Query beim RAC mit PARALLEL_DEGREE_POLICY auf AUTO oder ADAPTIVE unterstützt.
    • Auch auf Single Instanzenen für Single und Prallel Query
  • Advanced Index Compression
    • Ermöglicht Indexes auf effiziente Art zu komprimieren (Link)
    • Achtung: Dieses neue Features ist Teil der Advanced Compression Option kann daher zu zusätzlichen Lizenzkosten führen (Link)
  • READ Privilege
    • In früheren Releases gab es oft Probleme mit Usern, die das SELECT Recht auf spezielle Tables gegranted hatten. Dadurch ware es möglich, dass Tabellen in Exclusive Mode gelocked waren oder eine SELECT … FOR UPDATE möglich war. (Link)  Die neue Berechtigung “READ” wurde eingeführt und diese Problematik in Zukunft zu verhindern. (Link)
  • Viele neue Features für CDB und PDBs:
    • Flashback Data Archive (FDA) Unterstützung für CDBs (Link)
    • PDB CONTAINERS Clause
      • Query tables in einenm Subset von PDBs (Link)
    • PDB File Placement in OMF (Link)
    • PDB Logging Clause
      • Turn on NOLOGGING // LOGGING for the whole PDB (Link)
    • PDB Metadata Clone (Link)
    • PDB Remote Clone
      • Ein PDB // Non-CDB über einen Datenbank Link Clonen? Ja, natürlich ist das möglich (Link)
    • PDB Subset Cloning
      • Die USER_TABLESPACES Clause spezifiziert welcher Tablespace in der Plugable Database (PDB) verfügbar sein soll (Link)
    • PDB STANDBYS Clause (Link)
    • PDB State Management Across CDB restart. Dieses Features hat in der 12.1.0.1 wirklich gefehlt. Details hier oder eine Beschreibung des alten Problems finden Sie hier)

Abgesehen von dieser Aufzählung gibt es noch zahlreiche zustätzliche neue Features, die im Feature Guide aufgelistet sind (Link)

 

select blobs über Datenbank Link

Große BLOBs über einen Datenbank Link selektieren

Heute habe ich versucht ein BLOB über einen Datenbank Link zu selektieren.

Ich weiß, es gibt in solchen Fällen einige Einschränkungen, aber in diesem Fall gab mir der Business Case keine andere Wahl.

Mein Ziel war daher die BLOBs über einen Datenbank Link transparent zu selektieren. Einen passenden Workaround konnte ich nicht finden. Von support.oracle.com kam folgendes Statement:

 

  • SELECT with a LOB and DBLink Returns an ORA-22992: Cannot Use LOB Locators Selected from Remote tables (Doc ID 1234893.1)
    • “The error is expected because the use of DBLinks and LOBs via the SELECT from PL/SQL is not supported.”
  • Ora-22992 workaround (Doc ID 436707.1)
    • Getting ORA-1406 with lobs greater than 32KB – 1
  • ORA-1406: Fetched Column Value was Truncated When Selecting Remote Column into Local BLOB Variable (Doc ID 459557.1)
    • “This means that we are not able to retrieve BLOBs columns greater than 32KB – 1 in size through a database link.”

Zusammengefasst bedeutet diese Aussage, dass ein BLOB nativ über einen Datenbank Link nicht selektiert werden kann, falls dieser großer als 32KB-1 ist. Interessante Tatsache in diesem Zusammenhang ist, dass man DBMS_LOB Operators auf der lokalen und remoten Seite verwenden kann.

Mein persönlicher Favorit ist die DBMS_LOB.SUBSTR Funktion. Der Name der Funktion ist etwas ungenau, denn man kann damit BLOBs und auch CLOBs ansprechen.

 

Daraus hat sich mein folgender Ansatz ergeben, um BLOBs über einen Datenbank Link selektieren zu können:

Lösung VERSION 1 (Chunk Methode):

create or replace function GETBLOBVIADBLINK
( dblnk in varchar2
  ,tbl  in varchar2
  ,col  in varchar2
  ,rwid in urowid)
return blob
is
  retval blob;
  tmpraw raw(2000);  
  tmplen number;
  tmpchk number;
  chksize number;
begin
  --preset vars
  chksize:=2000;
  dbms_lob.createtemporary (retval,true);
  execute immediate 'select dbms_lob.getlength@'||dblnk||' ('||col||') from '||tbl||'@'||dblnk||' where rowid=:rwid' into tmplen using rwid;
  
  -- precalc  
  tmpchk:=floor(tmplen/chksize);

  -- applicate frist chunks  
  for i in 0 .. tmpchk-1
  loop  
    execute immediate 'select dbms_lob.substr@'||dblnk||'('||col||','||chksize||','||((i*chksize)+1)||') from '||tbl||'@'||dblnk||' where rowid=:rwid' into tmpraw using rwid;
    dbms_lob.append(retval,tmpraw);
  end loop;
  
  -- applicate last entry
  if (tmplen-(tmpchk*chksize)) > 0 then
    execute immediate 'select dbms_lob.substr@'||dblnk||'('||col||','||(tmplen-(tmpchk*chksize))||','||((tmpchk*chksize)+1)||') from '||tbl||'@'||dblnk||' where rowid=:rwid' into tmpraw using rwid;
    dbms_lob.append(retval,tmpraw);
  end if;
  return retval;
end;
/

Die Erklärung der Funktion ist sehr einfach:

  1. Ein TEMP LOB auf der lokalen Seite erstellen
  2. Die Limitation von DBMS_LOB.SUBSTR als RAW(2000) als mximale chunk size definieren
  3. Die einzelnen Chunks (max 2000 bytes) über den Datenbank Link kopieren und mit den Chunks auf der lokalen Seiten temporär ein BLOB zusammenfügen
  4. Das BLOB lokal auf dem Aufrufer übergeben

In Anschluss daran eine VIEW mit den neuen Definitionen erstellen:

CREATE OR REPLACE FORCE VIEW TESTVW1 (ID, MYLOB) AS 
SELECT id
       ,getblobviadblink('ARCHIV','MYLOBTABLE','MYLOB',rowid) MYLOB
FROM  MYLOB@archiv;

Fertig.
Nun ist es möglich über einen Datenbank Link auch größere BLOBs als 32KB-1 zu selektieren!

 

Es gibt aber auch noch andere Lösungswege:

Lösung VERSION 2 (temporary table Methode)

create global temporary table tmplob (tmplob blob) ON COMMIT PRESERVE ROWS;
create or replace function getblobviadblink2
( dblnk in varchar2
  ,tbl  in varchar2
  ,col  in varchar2
  ,rwid in urowid)
return blob
is
  PRAGMA AUTONOMOUS_TRANSACTION;
  retval blob;
begin

  execute immediate 'insert /*+ NOLOGGING */ into tmplob select '||col||' from '||tbl||'@'||dblnk||' where rowid=:rwid' using rwid;
  select tmplob into retval from tmplob;
  delete /*+ NOLOGGING */ from tmplob;
  commit;
  return retval;
end;
/

Beide Methoden sind möglich, aber die Version 2 ist wesentlich schneller.

Darüber hinaus gibt es sicherlich auch noch andere Lösungsmöglichkeiten.

Ich würde mich freuen, wenn Sie im Kommentar Ihre Erfahrungen posten.

 

 

Oracle Securefiles Performance Boost

Performance Boost mit SecureFiles und NOLOGGING

In diesem Beitrag vergleichen wir SecureFiles und BasicFiles. Es gibt einige Beiträge auf anderen Webseiten die zeigen wie schnell Secure Files sind, aber ich möchte diesmal einige Fakten und Benefits der NOLOGGING Option aufzeigen, welche bereits in einem früheren Beitrag auf diesem Blog beschrieben wurde.

The default value of the initialization parameter DB_SECUREFILE has changed in 12c from PERMITTED to PREFERRED

Die Test Umgebung

Alle hier angeführten Test wurden auf unserer eigenen Oracle Exadata X2 (Patch Level Jänner 2014) unter OEL5 auf einer 11.2.0.4 Datenbank durchgeführt.

Es wurde dafür die Tabelle lob_test erstellt und die NOCACHE Option aktiviert, welche mit der NOLOGGING Option zwingend notwendig ist.

CREATE TABLE lob_test (id     raw(16) default sys_guid() primary key,
                       lob1 BLOB,
                       lob2 BLOB,
                       lob3 BLOB,
                       lob4 BLOB,
                       lob5 BLOB)
        LOB(lob1) STORE AS SECUREFILE(
                  NOCOMPRESS NOCACHE LOGGING )
        LOB(lob2) STORE AS SECUREFILE(
                  NOCOMPRESS NOCACHE NOLOGGING)
        LOB(lob3) STORE AS SECUREFILE(
                  NOCOMPRESS NOCACHE FILESYSTEM_LIKE_LOGGING)
        LOB(lob4) STORE AS BASICFILE  (
                        NOCACHE LOGGING )
        LOB(lob5) STORE AS BASICFILE  (
                        NOCACHE NOLOGGING);

Das wurde getestet

Zuerst wurde ein Load und Unload Test mit 5 Gigabyte Daten (500 Files) durchgeführt, wobei jede einzelne Column seperat getestet wurde. Es wurden Basicfile vs. SecureFile und die NOLOGGING Option vs. LOGGING Option verglichen. Zusätzlich wurde auch die FILESYSTEM_LIKE_LOGGING Option gestestet, welche laut Dokumentation keinen bzw. minimalen Effekt in Vergleich zu NOLOGGING zeigen sollte:

In this case, if NOLOGGING is the default value, the SecureFile will default to FILESYSTEM_LIKE_LOGGING.

Bitte beachten Sie, dass es sich bei den Tests nicht um einen klassischen Performance Benchmark, sondern um die Simmulation einer üblichen Applikation handelt. Die Ergebnisse zeigen einen Vergleich der Performance Steigerungen auf der eingesetzten Hardware.

Test #1 Execution Time

Lob Load Time

Die Load Time zeigt die Zeitspanne für das Laden von 500 Files in die Test Tabelle. Die Diffenenz zwischen Lob2 und Lob3 ist marginal, was auch Sinn macht. Das Basicfile Lob5 mit NOLOGGING benötigt 127 Sekunden um die Daten zu laden, im Vergleich dazu benötigt Lob3 nur 14 Sekunden. In diesem Fall ist das Laden via SecureFile also 9x schneller als via Basicfile.

LOB Unload Time

Der umgekehrte Weg beim Unload der 500 Files von der Tabelle in das Filesystem zeigt ein ähnliches Bild. Das SecureFile benötigt circa 550 Sekunden für den Unload, das Basicfile benötigt 2351 Sekunden und ist circa 4x langsamer.

Test #2 IO Performance

LOB IO

Der I/O Durchsatz wird mit MB/s beim Laden in die Tabelle gemessen. Das Securefile erreicht einen Wert von 358/MB auf lokalen Server Harddisks. Das Basicfile erreicht nur 39 MB/s im NOLOGGING Mode.

 

Test #3 NOLOGGING Performance

Redo Size

Die NOLOGGING Performance bedeutet auch wie die Redo Information geschrieben wird. Das Securefile lob1 benötigt circa 5100MB Redo, was etwa der Datenmenge entspricht die in die Datenbank geladen wurde.

Interessant ist, dass das Basicfile 176MB Redo Data benötigt.
Das SecureFile benötigt nur 30MB, was circa 6x geringer ist.