Beiträge

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!

Regular Expression in APEX Suche

Regular Expressions in der APEX Suche

Die integrierte Suche in Oracle APEX beherrscht auch Regular Expressions.

Das funktioniert auf jeden Fall ab Version 4.1 aufwärts, vermutlich auch schon in Version 4.0 und eventuell auch schon darunter.

Die ganze Sache funktioniert eigentlich sehr einfach und benötigt folgende Syntax in der Anwendung:

regexp:([REGULAR_EXPRESSION])

Regular Expressions in der Apex Suche

Beispielanwendung Regular Expressions

Wobei [REGULAR_EXPRESSION] beliebige Regular Expressions sein können, so wie sie auch in den SQL Funktionen wie z.B. regexp_like verwendet werden. Wichtig zu beachten ist dabei, dass die Anführungszeichen wegfallen. Einige Beispiele dafür wären

  1. regexp:(P\d{4}_NUMMER)
  2. regexp:(P100_.*)
  3. regexp:(P1_EMPNO|P1_EMPNAME)
  4. regexp:(DD.MM.YYYY|YYYY-MM-DD)

Die Bedeutung dieser Regular Expressions ist wie folgt:

  1. Alle Vorkommen von Items die mit P und einer 4-stelligen Zahl beginnen (Standardnamen auf Seite mit 4-stelliger Nummer) und _NUMMER heißen (um alle „Nummer“ Items zu finden)
  2. Alle Vorkommen von Items die mit P100_ beginnen (z.B. um zu prüfen ob diese Items auch außerhalb der Seite 100 aufgerufen werden)
  3. Alle Vorkommen von Items mit den Namen P1_EMPNO oder P1_EMPNAME
  4. Alle Vorkommen von Date Format Models DD.MM.YYYY oder YYYY-MM-DD (um zum Beispiel alle Konvertierungsfunktionen mit diesen Format Models zu finden)

Regular Expressions erweitern das Suchen innerhalb der Applikation um mächtige Möglichkeiten.

Da Regular Expressions aber auf der Performance Seite eher schlecht abschneiden sollten sie nur verwendet werden wenn es wirklich Sinn macht.
Das kann zum Beispiel sein, wenn nicht ganz sicher ist welches Item an welchen Stellen übergeben wird, oder wenn eine Liste mit bestimmt benannten Items benötigt wird.

Die Suche mit einem einfachen Begriff wird deutlich flotter laufen und ist daher zu bevorzugen, wenn möglich.

x6 Oracle Exadata Database Machine veröffentlicht

X6 Oracle Exadata Database Machine veröffentlicht

Anfang April wurde die neue Oracle Exadata Database Machine x6 veröffentlicht, welche zu unveränderten Anschaffungskosten in den Bereichen Performance, Kapazität und Verfügbarkeit wiederholt mit beeindruckenden Spitzenleistungen aufwartet.

Seit jeher liefert die Oracle Exadata Database Machine das besten Preis/Leistungsverhältnis für Online Transaction Processing (OLTP), Analytik und konsolidierten Datenbank Workloads.

Die Oracle Exadata x6 verfügt über die neuesten und schnellsten Intel-Xeon-Prozessoren, ultraschnelles InfiniBand-Netzwerk und ist weltweit die erste und einzige Datenbankplattform welche durch die Kombination von modernsten 3D V-NAND-Flash und  Datenbank-Intelligenz am Storage nahezu den Durchsatz von DRAM Speicherriegeln erreicht. Beeindruckende 300 Gigabyte pro Sekunde Datendurchsatz können pro Rack erreicht werden.

Dadurch zeigt die Oracle Exadata x6 eine beeindruckende In-Memory-Leistung zu einem Zehntel der Kosten einer reinen In-Memory-Plattform.

Zusätzlich kann mittels Hybrid Columnar  Compression Technologie die Speicherkapazität durchschnittlich um den Faktor 10x erhöht werden, wodurch für große Data Warehouse oder konsolidierte Datenbank Workloads ein weiterer Preisvorteil gegeben ist.

Unsere Exadata Spezialisten haben bereits sehr viele Erfahrungen mit der Exadata Database Machine gesammelt und sind nur einen Anruf entfernt.

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 APEX 4.2.3

Oracle APEX Release 4.2.3 veröffentlicht

Die Oracle Application Express Release 4.2.3.00.08 wurde am 16. September 2013 veröffentlicht.
Ab dem genannten Datum ist APEX daher in dieser Version mit allen entsprechenden Verbesserungen verfügbar.

Wenn bereits APEX in Version 4.2.0 oder höher installiert ist, kann man den Patch von My Oracle Support downloaden (Patchnummer #17347169) .

Der Patch bietet etliche Bugfixes – die vollständige Liste ist unter Apex 4.2.3 Relase Notes abrufbar.