Anmeldung zur DBConcepts Sommer-Party 2018

Es ist wieder so weit! Feiern Sie mit uns den Sommer ganz relaxed an der Alten Donau bei einem fantastischen Grill-Buffet und kühlen Getränken!

Für besonders gute Laune sorgt auch heuer wieder die DBConcepts Tretboot-Challenge.

Datum: 30. August 2018
Ort: Le Creperie, An der Oberen Alten Donau 6, 1210 Wien
Uhrzeit: ab 16:00 Uhr  bis 22:00h

  • Die Veranstaltung findet auch bei Schlechtwetter aber ohne Tretboot Challenge statt.
  • Die Teilnahme ist für alle Personen mit Einladung selbstverständlich kostenfrei, setzt aber unbedingt eine Anmeldung voraus.
  • Als Begleitpersonen sind nur Ehepartner/Lebenspartner zulässig, diese müssen aber ebenfalls angemeldet werden. Wir danken für Ihr Verständnis.

Einen Rückblick zur Sommer-Party 2017 finden Sie hier >>

Bitte melden Sie sich rasch für die DBConcepts Sommer-Party an, die Kapazität der Location ist begrenzt.

Anmeldung zur Sommer-Party (bitte alle Felder ausfüllen)

7 + 0 = ?

Meltdown und Spectre jetzt patchen

Meltdown und Spectre – Jetzt Patchen

Während es in der Regel Programmen nicht erlaubt ist, Daten von anderen Programmen auszulesen, kann ein bösartiges Programm die Sicherheitslücken „Meltdown“ und „Spectre“ ausnutzen, um an Daten zu gelangen, die im Speicher anderer laufender Programme gespeichert sind.

 Meltdown (CVE-2017-5754)

Meltdown ermöglicht es, auf Speicherbereiche des Kernels zuzugreifen, die eigentlich vor dem Zugriff durch den Prozess geschützt sein sollten. So ist es etwa mögliche, sensitive Informationen auszulesen. Meltdown kann durch Software-Maßnahmen im Kernel der Betriebssytems behoben werden, allerdings gehen mit dieser Maßnahme teilweise empfindliche Performance-Einbußen einher. Das genaue Ausmaß des Performance-Verlustes hängt hier aber stark von der Charakteristik und der Beschaffenheit des Programms ab.

 

Spectre (CVE-2017-5753 und CVE-2017-7515)

Spectre nützt eine Schwachstelle bei der Hardware-Implementierung der „speculative execution“ von CPUs aus. Diese Schwachstelle kann auf Software-Ebene nur teilweise behoben werden. Neuere Microcode-Versionen für Intel und AMD versuchen, einen Teil der Bedrohung zu entschärfen. Um das Problem nachhaltig zu lösen, bedarf es aber Änderungen am Hardware-Design der CPU.

 

Performance-Auswirkungen

Redhat gibt in einem detaillierten Artikel (“Speculative Execution Exploit Performance Impacts – Describing the performance impacts to security patches for CVE-2017-5754 CVE-2017-5753 and CVE-2017-5715”, https://access.redhat.com/articles/3307751) Überblick über erwartbare Performance-Einbußen. Für OLTP-Anwendungen konnte Redhat einen Performance-Verlust von 8-19% feststellen.

 

Was ist zu tun?

Prinzipiell ist es ratsam, die betroffenen Systeme zu aktualisieren, wobei für jedes System individuell beurteilt werden muss, welchem Risiko es ausgesetzt ist und ob die möglichen Performance-Einbußen für das System tolerierbar sind.

Eine exakte Schätzung der Veränderung in der Systemleistung ist im Vorfeld schwierig, sofern nicht ein exakt gleich dimensioniertes Testsystem zur Verfügung steht, auf welchem die Workload der Produktion simuliert werden kann.  

Usere Experten haben bereits viele Erfahrungen gesammelt und unterstützen Sie dabei, Ihr System zu patchen und vorab die Performance Auswirkungen auf Ihr System einzuschätzen.
Kontaktieren Sie uns.

 

Aktualisierte Pakete und Kernel-Versionen

Oracle stellt mittlerweile für die Produkte Oracle Enterprise Linux 6 (OEL6), Oracle Enterprise Linux 7 (OEL7) und Oracle VM Server (OVM 3.4) aktualisierte Pakete zur Verfügung.
In den unten angeführten Tabellen sind die – mit Stand 15.01.2018 – verfügbaren Updates ersichtlich.

OEL6

Paket Version Fix für CVE-2017-*
kernel-uek (UEKR4) 4.1.12-112.14.11.el6uek 5754, 5715, 5753
kernel (RHEL) 2.6.32-696.18.7.el6 5754, 5715, 5753
libvirt-* 0.10.2-62.0.1.el6_9.1 5715
microcode_ctl 1.17-25.2.el6_9 5715
qemu-* 0.12.1.2-2.503.el6_9.4 5715

 

OEL7

Paket Version Fix für CVE-2017-*
kernel-uek (UEKR4) 4.1.12-112.14.11.el6uek 5754, 5715, 5753
kernel (RHEL) 3.10.0-693.11.6.el7 5754, 5715, 5753
libvirt-* 3.2.0-14.0.1.el7_4.7 5715
microcode_ctl 2.1-22.2.el7 5715
qemu-* 1.5.3-141.el7_4.6 5715

 

OVM-Server (3.4)

Paket Version Fix für CVE-2017-*
kernel-uek (UEKR4) 4.1.12-112.14.11.el6uek 5754, 5715, 5753
xen 4.4.4-155.0.12.el6 5754, 5715,
microcode_ctl 1.17-25.2.0.1.el6_9 5715
qemu-* 0.12.1.2-2.503.el6_9.4 5715

 

Weiterführende Links:

https://spectreattack.com/

https://access.redhat.com/security/vulnerabilities/speculativeexecution

https://linux.oracle.com/cve/CVE-2017-5715.html

https://linux.oracle.com/cve/CVE-2017-5753.html

https://linux.oracle.com/cve/CVE-2017-5754.html

 

Oracle Open World 2017 Solaris und SPARC Versprechen

Oracle Solaris/SPARC auf der Oracle Open World 2017

In letzter Zeit brodelt die Gerüchteküche rund um das Oracle Solaris Betriebssystem und den damit einhergehenden RISC Prozessor der SPARC Plattformen.

Durch die Akquise von Sun Microsystems erwarb Oracle im Jahr 2009 eine Hardware Sparte, auf der sämtliche aktuellen Systeme sowie auch Oracle’s eigenen Cloud Plattform laufen.
Im Oktober 2017 schockierte Oracle mit einer Kündigungswelle, welche einen großen Teil der Solaris/SPARC Abteilung betraf.

Ungeachtet dessen macht die Oracle Hardware Sparte auch im Jahr 2017 wieder über 10% des Oracle Umsatzes aus und ist die Basis für Oracle’s Engineered Systems.

Ein paar Wochen später auf der jährlichen Hausmesse „Oracle Open World“ stand aber fest: Oracle verspricht wiederholt die Weiterentwicklung und den Support von Oracle Solaris bis mindestens 2034!

Parallel dazu hat Oracle auch eine neue SPARC CPU und die nächste Solaris Release für Herbst 2018 angekündigt. Eine bereits längeres Versprechen, Solaris als Solaris 11.next weiterzuführen, wie wir hier bereits Anfang 2017 berichtet haben.

Weiterhin gilt auch der Support von Solaris 11 und Solaris 10, als auch Solaris 9 und 8 in „Oracle Solaris Legacy Container“ auf der neuesten SPARC Hardware, sowie die seit Jahren gültige „Oracle Solaris Binary Application Guarantee“, um „alte“ Applikationen ohne Modifikation ausführen zu können.

Oracle Open World 2017-das Solaris Zukunft Versprechen

Bild von der Oracle Open World 2017 – das Solaris Versprechen

OOW2017-Das Solaris Next Versprechen

Bild von der Oracle Open World 2017 – das Solaris.next wird kommen

Oracle SPARC M8 Prozessor

Oracle stellt mit Oktober auch eine neue Generation der hauseigenen SPARC CPU vor. Der M8 Prozessor läuft in Oracle’s T8/M8 Systemen auf  bis zu 8 Socket Systemen.

Mit 32 Kernen zu je 8 Threads und vier Instruktionen pro CPU-Cycle bietet der mit 5 GHz getaktete Prozessor noch zusätzlich Coprozessoren für kryptographische Routinen der gängigen Verschlüsselungen und Hashing Algorithmen an.

Die „Data Analytics Acceleration“ (DAX) Einheiten beschleunigen In-Memory Abfragen für die Oracle Datenbank 12c und Java 8 (Streams) um ein Vielfaches.
Oracle spricht sogar imVergleich zu aktuellen Xeon um einen bis zu 10fachen Faktor.

Hierbei werden „Query Functions“ wie „decompress/scan/filter/join“ direkt vom Co-Prozessor übernommen, OZIP Daten direkt in den Memory geladen und ohne zusätzliche und aufwändige Read/Write Operationen „on the fly“ entpackt und verarbeitet.

Für arithmetisch-intensive Workloads bringt die CPU pro Core eine „Oracle Numbers Acceleration Unit“ mit, um den DB Datentyp und dessen Verarbeitung um ein Vielfaches speziell bei rechenintensiven Workloads wie Reporting und Data Warehousing Umgebungen zu beschleunigen.

Die Memory Bandbreite des M8 wurde mit 180 GB/s gemessen, bei einer technischen RAW-Bandbreite der Memory-Links von 374 GB/s pro Prozessor. Mehr als genug Geschwindigkeit, um 16 DDR4-2400 Channels (RAW 307 GB/s) zu verarbeiten. Mit hohen AES-256-CFB verschlüsselt (von Oracle DB verwendet) wurden noch immer über 125 GB/s gemessen!

Dieser „verschlüsselte“ Wert ist höher als die von Intel angegebene unverschlüsselte 119 GB/s Bandbreite einer aktuellen Xeon Platinum 8180M CPU (launch date Q3’17).

AES Encryption: SPARC M8 Performance, Beats x86 Per Core

Neben den klassischen Servern stellt Oracle auch das Engineered System mit SPARC CPUs vor: Der Oracle SuperCluster M8, die laut Oracle schnellste Datenbank Plattform.

SPARC M8 processors running Oracle Solaris 11.3 ran 2.9 times faster executing AES-CFB 256-bit key encryption (in cache) than the Intel Xeon Processor Platinum 8168 (with AES-NI) running Oracle Linux 7.3.

SPARC M8 processors running Oracle Solaris 11.3 ran 6.4 times faster executing AES-CFB 256-bit key encryption (in cache) than the Intel Xeon Processor E5-2699 v4 (with AES-NI) running Oracle Linux 7.2

 

Oracle’s SPARC T8 and SPARC M8 Server Architecture

Oracle Open World Key Takeaways

  • SolarisOracle verspricht Support für mindestens weitere 17 Jahre, bis 2034! Weitere Solaris Entwicklungen sind für 2018 geplant.
  • LegacyAls 8. Generation aus dem Hause Oracle verbessert der M8 sowohl die Performace als auch die Security für High-End, Business kritische Workloads mit einer Binärkompatibilität und lauffähigen Solaris Umgebungen zurück bis Solaris 8.
  • Database – Der M8 wird „co-engineered“ entwickelt, um die Oracle Datenbank schneller als auf jedem anderen Microprozessor lauffähig zu machen.
    Ausschließlich unter Solaris bietet die Datenbank Funktionen wie den dynamischen „Optimized Shared Memory“ oder eine I/O Analyse direkt aus der Datenbank heraus.
  • In-Memory Analytics – Mit Hilfe der Data Analytics Accelerators (DAX) Co-Prozessoren erreicht der M8 Prozessor bis zu 7x mehr Queries pro Minute (QPM/core) als ein aktueller x86 Chip bei Oracle Datenbank IM Abfragen.
  • JAVA – Der aktuelle M8 Chip liefert die zweifach bessere Java Performance als ein aktueller x86 Prozessor und eine 1.3x bessere Geschwindigkeit als sein Vorgänger M7. Java 8 Streams nutzt für Analytische Funktionen die DAX Engine und erreicht ein Vielfaches an QPM.
  • Security – Durch die 32 Crypto-Co-Prozessoren fährt der M8 Chip auch verschlüsselt eine nahezu unveränderte Leistung und unterstützt 16 Industriestandard Algorithmen und zusätzliche „Random Number Generators“. Mit „Silicon Secured Memory“ bietet der M8 Chip einen auf Hardware basierenden Schutz gegen Buffer Overflows oder andere falsch adressierende Hauptspeicher Zugriffe.

Oracle Fujitsu SPARC XII

Auch der japanische Konzern Fujitsu bringt als Kooperationsprodukt einen neuen Solaris Sparc64 Chip heraus. In den auch als Oracle OEM verfügbaren Servern laufen von 1 bis 32 Zwölfkern-Prozessoren bei 4,25 GHz mit bis zu 32 TB Arbeitsspeicher als wassergekühltes „Building-Block“ System.

Oracle X7 Server

Auch die neueste x86 Generation von Oracle wird weiterhin mit Support für Solaris11-x86 angeboten und reicht von ein/zwei CPU Systemen, X7-2 & X7-2L bis zur großen 8 Socket Maschine –  den Oracle X7-8 Server mit 192 Cores und bis zu 6 TB Arbeitsspeicher.

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!

Das war die DBConcepts Sommer-Party 2017

Ein herrlicher Sommer Abend und die tolle Location an der Alten Donau waren der perfekte Rahmen für unsere DBConcepts-Sommer-Party.

Über siebzig gut gelaunte Kunden, Partner, Freunde und Kollegen ließen sich die Gelegenheit nicht entgehen, um gemeinsam in entspannter Atmosphäre einen gemütlichen und lustigen Abend zu verbringen.

Die besondere Herausforderung der ersten „DBConcepts Tretboot-Challange“ wurde von vierzehn unerschrockenen Teams angenommen und ohne „nassen Ausstieg“ bravourös gemeistert.

Im Anschluss verwöhnte der Grillmeister unseren Gaumen mit vielen verschiedenen Köstlichkeiten, die vom reichhaltigen Buffet perfekt ergänzt wurden.

Für die brennenden Wadeln und durstigen Kehlen wurden den ganzen Abend entsprechende Erfrischungen gereicht.

Besonders freut uns das begeisterte Feedback aller Gäste, die uns zur gelungen Sommer-Party gratuliert haben.

Gut möglich, dass der Grundstein für eine jährliche Tradition gelegt wurde.

DBConcepts Sommer-Party 2017

 

Das Gewinner Team „Keine Idee“ mit der fabelhaften Zeit von 1:28, wurde von unseren Chefs entsprechend geehrt!

Rangliste der Tretboot-Challange Teams:

Team Zeit
1 Keine Idee 01:28
2 Die Chefitäten 01:35
2 Die Gewinner 01:35
4 Die Piefke 01:37
5 Die Boesen 01:38
6 Team Wurscht 01:41
7 IASA 01:45
8 Die Entscheidenen 01:51
9 Matepipapo 01:53
9 Piraten 01:53
11 Die Flotten 02:10
12 Snoopy 02:15
13 Supercluster 03:02
14 Die Besten tech. Gebrechen

 

DBC-Sommerfest Collage

 

DBConcepts Sommer-Party 2017- Anmeldung

Feiern Sie mit uns den Sommer ganz relaxed an der Alten Donau bei einem fantastischen Grill-Buffet und kühlen Getränken!

Für besonders gute Laune sorgt die DBConcepts Tretboot-Challenge.

Datum: 31. August 2017
Ort: Le Creperie, An der Oberen Alten Donau 6, 1210 Wien
Start: ab 16:00 Uhr  bis 22:00h

  • Die Veranstaltung findet (ohne Tretboot Challenge) auch bei Schlechtwetter statt.
  • Die Teilnahme ist für alle Personen mit Einladung selbstverständlich kostenfrei, setzt aber eine Anmeldung voraus.
  • Als Begleitpersonen sind nur Ehepartner/Lebenspartner zulässig, diese müssen aber ebenfalls angemeldet werden. Wir danken für Ihr Verständnis.

Bitte melden Sie sich jetzt für die Sommer-Party an, da die Lokation sehr beliebt ist.

Die AOUG Anwenderkonferenz 2017 im Rückblick

Auch heuer fand wieder die Anwenderkonferenz der AOUG – Austrian Oracle User Group in Wien statt. Viele Teilnehmer folgten dem Ruf der Organisatoren, um sich die größte und wichtigste Veranstaltung im Österreich mit dem Schwerpunkt „Oracle“ nicht entgehen zu lassen.

Die Vorstände der AOUG setzte wiederholt den Schwerpunkt auf hochwertige Fachvorträge, sodass in Summe 28 Fachvorträge und Keynotes in manchen Fällen die Auswahl wirklich schwierig machten.

Als langjähriger Sponsor unterstützten wir auch heuer wieder die Veranstaltung und verlosten zusätzlich unter allen Teilnehmern einen Thermen-Gutschein im Wert von 500,- euro.

 

Was erwartet uns mit der neuen EU-Datenschutz Grundverordnung?

Im Rahmen unserer sehr erfolgreichen Business Breakfast Veranstaltung gab es einen Vortrag von RA Dr. Lattenmayer zur neuen EU-Datenschutz Grundverordnung.

Da der Experte nicht an allen Veranstaltungen in den Bundesländern teilnehmen konnte, haben wir zu diesem Thema mit Herrn Dr. Lattenmayer ein Video-Interview erstellt, wo er uns auf eine halbe Stunde komprimiert einen ersten, kurzen Ausblick auf die ab Mai 2018 gültigen Neuerungen und Änderungen im Bereich EU-Datenschutz gibt.

Für alle die nicht dabeisein konnten – Kurz und knackig: 38 Minuten zum Thema „Die neue EU-Datenschutz Grundverordnung“

Ein Auszug aus dem Interview:

Mit Geldbußen bis zu EUR 20.000.000,- bzw. 4 % des weltweiten Jahreumsatzes sanktioniert die ab Mai 2018 in Kraft tretende EU-Datenschutz Grundverordnung ernsthafe Datenschutzverletzungen.
Der gesamte Datenschutz-Rechtsrahmen ändert sich. Unternehmen müssen ihre Datenanwendungen analysieren, Risikofolgenabschätzung für Datenanwendungen tätigen, die Rechtmäßigkeit der Einwilligungen überprüfen, Notfallspläne für Datenverluste bereithalten, Datenübermittlung ins EU-Ausland überprüfen,… und haben umfassende Informations- und  Dokumentationspflichten.
Eine Datenschutz-Zertifizierung kann dabei helfen. Datensicherheitsmaßnahmen sollten vor Datenverlust und drohenden Haftungen schützen.

Oracle Partner of the Year Award 2017 an DBConcepts

Im Rahmen der EMEA Oracle Partner Day 2017 Veranstaltungen, welche am 29. und 30. März 2017 für die Region ECE in Athen stattgefunden haben, wurden auch heuer wieder Oracle Partner in sechs verschiedenen Kategorien ausgezeichnet.

Unser Geschäftsführer DI Peter Macek konnte auf der Bühne die Auszeichnung „Oracle Specialized Partner of the Year 2017“ in der Kategorie „Converged Infrastructure“ entgegennehmen.

Oracle EMEA Partner of the Year 2017 Preisverleihung

Oracle honoriert mit dem Award unser Engagement und unsere Erfolge,  die in den vergangenen zwölf Monaten von unseren Kollegen/innen erreicht werden konnten.

Als einer der wichtigsten Oracle Platinum Partner in Österreich arbeiten wir seit dem Jahr 2000 sehr erfolgreich auf nationaler wie internationaler Ebene mit Oracle zusammen, um die Besten Lösungen für unsere Kunden umzusetzen.

 

Workaround: Unpivot mit ORA-00942 oder ORA-00904

Ausgangslage

Kürzlich trat ein Problem mit einem UNPIVOT Operator in der Entwicklung einer Statistik-Abfrage auf

Select [...]
 from VIEW1 unpivot(val for year in ([...]);
ORA-00942: table of view does not exist

Die Abfrage wurde im gleichen Schema ausgeführt wo auch der View sein sollte. Folgendes Select funktionierte zum Beispiel problemlos:

select * from VIEW1;

Lösung

Eine Recherche ergab anfangs wenig Lösung. Die üblichen Lösungsvorschläge bezogen sich auf Problem mit Arbeiten in unterschiedlichen Schemas oder über Datenbank-Links. Da die Tabelle aber grundsätzlich als vorhanden erkannt wurde musste der Grund woanders liegen. Im Oracle Support habe ich die Lösung gefunden, im Dokument Doc ID 22339954.8.

Laut diesem Dokument handelt es sich hierbei um einen Bug in potentiell allen Datenbankversionen vor 12.2.0.1. Laut diesem Dokument gibt es keinen Workaround. Das Problem kann ich außerdem in langen Laufzeiten äußern selbst wenn keine Fehler auftreten. Die Probleme treten lt. Dokument auf wenn eine Abfrage eine UNPIVOT Operation auf Views mit mehrfachen verschachtelten Abfrageblöcken und/oder einer großen Anzahl von Tabellen macht.

Wir haben einen Workaround gefunden der in unserem Fall das Problem recht leicht und zufriedenstellend gelöst hat:

with base as (select /*+ materialize */ * from VIEW1)
Select [...]
from base unpivot(val for year in ([...]);