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 Business Intelligence Katalog Link fehlt

Oracle BI 11g – Katalog Link fehlt

Ist Ihnen das auch schon passiert? Ein Kunde ruft mich an und sagt mir, dass er mit seinem User-Account keinen Katalog Link mehr sieht. Was tut man hier?

  1. Man prüft den Fehler an sich. Eine Remote-Session zeigt, dass es tatsächlich so ist.   Oracle BI Katalog Link fehlt
  2. Das getan, legt man natürlich einen Vergleichs-Account mit gleichen Berechtigungen an und prüft die Reproduzierbarkeit. Fehlanzeige!

Der Referenzaccount sieht ohne Probleme den Katalog Link. D.h. es stimmt nur etwas mit seinem Account nicht. Nach einer längeren erfolglosen Suche in den Berechtigungen in der Präsentationsserverumgebung fällt mir dann doch etwas Ungewöhnliches am Account des Benutzers auf: Der Eingabehilfe-Modus ist aktiviert!

Oracle BI Katalog - mein Account Link

 

Oracle BI Mein Account Modus Eingabehilfe Ein

Schnell deaktiviert und neu angemeldet und siehe da, der Katalog-Link ist wieder da.

Oracle BI Mein Account Modus Eingabehilfe Aus

 

Oracle BI Katalog Link wieder da

 

Interessant ist natürlich, warum jemand, der eine Eingabehilfe braucht, den Katalog nicht sehen darf, aber Oracle wird sich da schon etwas gedacht haben. Höchstwahrscheinlich entsprechen alle ausgeblendeten Teile einfach nicht den Richtlinien für barrierefreie Webinhalte.

Oracle Day 2014 Vienna, Austria

DBConcepts am Oracle Day 2014

Am 11. November fand in Wien der „Oracle Day 2014“ statt, der heuer unter dem Motto „Digital Disruption – der digitale Umbruch“ stand.

Weltweit über 160 Millionen neue Smartphone User in den letzten zwölf Monaten zeigen die rasante Veränderung der IT-Welt, die immer mehr zu Cloud Service Angeboten führt, wie Martin Winkler – Geschäftsführer von Oracle Österreich, in seiner Keynote ausführte. Oracle reagierte auf diese Veränderungen mit zahlreichen Angeboten in den Bereichen Software as a Service, Plattform as a Service und Infrastructure as as Service. „Wichtig ist uns die Wahlfreiheit des Kunden, ob er in die Cloud auslagern will und welche Lösungen er bei sich vor Ort betreiben möchte “ betonte Martin Winkler.

Wien Oracle Day 2014 Keynotes

Anschließend berichtete Thomas Rumpf vom Bundesministerium für Landesverteidigung unter dem Titel „Das Geheimnis unseres Erfolges: Exadata und DBConcepts“ in einer sehr unterhaltsamen Präsentation von unserem gemeinsam erfolgreich umgesetzten Mega-Projekt.

Durch die über mehrere Monate dauernde physische Leihgabe unserer Oracle Exadata Database Machine und die Unterstützung durch unserer Oracle Exadata Spezialisten direkt vor Ort, konnte gemeinsam der sehr ausführliche Proof of Concepts durchgeführt werden, um die Erreichbarkeit aller gesteckten Ziele und Vorgaben zu testen.

In weiterer Folge war es durch den PoC möglich, alle gesetzten Meilensteine step-by-step erfolgreich umzusetzen, sodass nach dem Go-Live die neue Oracle Exadata Infrastruktur beim Österreichischen Bundesheer in kürzester Zeit den Returen of Investment erreichen konnte.

Beim darauf folgenden Kundenbericht von Horst Glasauer, dem Technik Leiter von Eurotours International, wurde in der Erfolgsstory auf die hervorragende Performance der MPA x4.1 Hardware Lösung hingewiesen, die sich im Produktionsbetrieb als die optimale Wahl für die sehr hohen Anforderungen von Eurotours International bewähren konnte.

Die MPA x4.1 ist eine von DBConcepts erstellte Konfiguration aus aktuellsten und qualitativ hochwertigsten Oracle x86 Hardware Komponenten, die unabhängig von der Datenbank Edition (EE, SE oder SE1) eine sehr hohe Performance bei erstaunlich günstigem TCO für den Betrieb von Oracle Datenbanken zur Verfügung stellt. Weiterführen Infos zur MPA x4.1 >>

Last but not least wurde unser Kollege Peter Häusler, Oracle Certified Master, mit der Verleihung der Auszeichnung „Oracle Austria Partner DBA of the Year“ für seine hervorragenden Leistungen bei zahlreichen anspruchsvollen Datenbank Projekten auf die Bühne gebeten und entsprechend gewürdigt.

Oracle Partner DBA of the year 2014 Award

Alles in allem war aus unserer Sicht heuer ein sehr besonderer Oracle Day, den wir aufgrund der vielen Nennungen von DBConcepts bei den verschiedenen Vortägen nicht so schnell vergessen werden.

 

 

Oracle 12c - Profitieren durch migrieren

Business Breakfast Oracle 12c: Profitieren durch migrieren

Mitte Oktober fand wieder unsere schon traditionelle Herbst Business Breakfast Veranstaltung quer durch Österreich statt. Diesmal unter dem Titel „Oracle 12c. Profitieren durch migrieren. So geht´s“.

Der breite Bogen der spannenden Vortragsthemen stieß auf so großes Interesse,  dass sowohl in Bregenz, Salzburg, Linz als auch in Wien die Auslastungsgrenze der Seminarräume erreicht wurde.

Ein Umstand, der uns natürlich sehr freut!

Nur in Innsbruck hätte die Location noch ein paar zusätzliche Teilnehmer erlaubt. Wir arbeiten daran, dass wir auch in Tirol in Zukunft noch mehr Gäste begrüßen können 😉

 

Business Breakfast Oracle 12c Profitieren durch migrieren

 

Die Vorträge

Im ersten Vortrag wurden die neuen Features der aktuellen Oracle 12.1.0.2 Release vorgestellt. Als Beta Tester konnte DBConcepts schon viele Erfahrungen bei diversen Migrationsprojekten sammeln und über viele spannende Details berichten. Weitere Themen der Veranstaltung waren:

  • Welche Überlegungen für eine Migration wichtig und richtig sind und was das Ende des Oracle Premier Support für Oracle 11g bedeutet.
  • Welche Basis Funktionalitäten der Datenbank in zukünftigen Releases nicht mehr enthalten sind und welche anderen Möglichkeiten sich dazu ergeben.
  • Welche neuen Features in der neuen Oracle 12c Release inkludiert sind und wie man davon ohne zusätzliche Lizenzkosten profitieren kann.
  • Bei welchen Szenarien und Voraussetzungen „Database as a Service“ und „Private Cloud“ wirklich Sinn machen.
  • Ob die neue In-Memory Option der 12c Enterprise Edition die hoch gesteckten Erwartungen erfüllen kann.

Im Anschluss an diesen Vortrag wurde über lizenztechnische Änderungen im Umfeld des Oracle Enterprise Managers und über diverse Ankündigungen hinsichtlich nicht mehr unterstützter Funktionalitäten in zukünftigen Releases berichtet.

Der Vortrag zum Thema Oracle Lizenzierung konnte den Teilnehmern einen Überblick über die wichtigsten Änderungen und Stolpersteine im Umfeld der Oracle Lizenzierung mit der Oracle 12c Datenbank bieten, sowie Informationen und aktuelle Neuigkeiten zum Thema Oracle in VMware >=5.1 Cluster Umgebungen.

Nach einer kurzen Pause mit entsprechender Stärkung wurde SharePlex als eine Datenreplikationslösung für Oracle Datenbanken vorgestellt.

Eine Lösung, die sich besonders durch folgende Merkmale auszeichnet:

  • Leistungsfähigkeit. SharePlex ist für hohe Transaktionslast und geringe Latenzzeit ausgelegt.
  • Zuverlässigkeit. SharePlex vergleicht die zu ändernden Daten auf der Zielseite vor Ausführung der Datenänderung und alarmiert bei Out-of-sync-Situationen. Das patentierte Compare-Repair-Verfahren, das ohne Zusatzkosten im Produkt enthalten ist, ermöglicht die Behebung von Synchronisationsfehlern, ohne dass der gesamte Datenbestand erneut aufgesetzt werden muss.
  • Einfache Installation und Bedienung. SharePlex lässt sich in wenigen Minuten installieren, und die Konfiguration der zu replizierenden Objekte ist extrem einfach und flexibel.
  • Flexibilität. SharePlex kann sowohl für Oracle Enterprise Edition als auch Standard Edition verwendet werden. Darüber hinaus werden alle aktuellen Oracle-Versionen unterstützt, und die Replikation ist möglich zwischen verschiedenen Versionen.
  • Günstiger Preis. Nicht nur der grundsätzliche Preisunterschied zu anderen Lösungen macht sich deutlich bemerkbar. Für Oracle SE gilt ein geringerer Preis als EE, und darüber hinaus kann SharePlex für Migrationsprojekt für einen begrenzten Zeitraum lizensiert werden.

Im letzten Vortag wurde der Themenbogen mit aktuellen Informationen zu Oracle Hardware Lösungen abgerundet. Anhand einiger Beispiel konnte aufgezeigt werden, wie die Migration auf Oracle 12c Datenbank mit Einsatz von Oracle Hardware reibungsfrei durchgeführt wird und gleichzeitig Optimierungen bei den Lizenzkosten erzielt werden können.

 

 

 

 

 

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 12c Specialized Auszeichnung

Auszeichnung als weltweit zweiter „12c Specialized“

Am Sommerfest der Österreichischen Oracle Partner Lounge wurde DBConcepts von Oracle mit der Auszeichnung als “weltweit zweiter DB 12c Specialized” Oracle Partner ausgezeichnet.

Die beiden Geschäftsführer von DBConcepts nahmen den Preis von den Oracle Partner Managern mit großer Freude entgegen.

Damit wurde das jahrelange Engagement von DBConcepts gebührend gewürdigt, die zahlreichen erzielten Spezialisierungen am aktuellsten Stand zu halten und stetig auszubauen.

 

„Oracle Specialized“ kennzeichnet das spezielle Know-how und die damit verbundene Zertifizierungen jedes einzelnen Oracle Partner.

 

AOUG Anwenderkonferenz 2014 Messestand DBConcepts

AOUG Anwenderkonferenz 2014

Am 17.6. fand heuer die AOUG (Austrian Oracle User Group) Anwenderkonferenz im Hotel Savoyen Vienna statt.

Als besonderer Keynote Speaker konnte dieses Jahr Andrew Holdsworth, den Senior Direktor der Oracle Real World Performance Gruppe, gewonnen werden.

Neben seiner unterhaltsamen Keynote gab er auch bei einem technischen Vortrag wertvolle Einblicke in die Arbeitsweise seiner Performance Group.

Neben zahlreichen interessanten Vorträgen in vier verschieden Tracks wurden die Teilnehmer auch von den Sponsoren mit wertvollen Informationen versorgt.

Datenbankwunderwuzzi T-ShirtZusätzlich gab es an unserem Messestand für alle Neuanmeldungen zu unserem DBConcepts Newsletter ein kostenloses Exemplar des beliebt „Datenbankwunderwuzzi“ T-Shirts.

 

Die Nachfrage nach dem T-Shirt war so groß, dass wir über eine Wiederholung der Aktion bei einem der nächsten Events nachdenken.

 

 

 

 

Feedback Lizenz Seminar

Rückblick: Oracle Software Lizenzierung Seminar

Am 1. April fand in den Seminar Räumlichkeiten von DBConcepts das Oracle Software Lizenzierung Seminar statt. Aufgrund zahlreicher Nachfragen von Interessenten, die für ein In-House Seminar im eigenen Unternehmen nicht genügend Teilnehmer zur Verfügung stellen können, war es zum ersten Mal möglich, im öffentlich Rahmen an diesem Seminar teilzunehmen.

Ziel des Lizenz Seminar war es, teure Lizenzierungsfehler eindeutig zu erkennen und zu vermeiden, sowie Lizenzkosten zu optimieren.

Aufgrund des großen Erfolges und des positiven Feedback der Seminar Teilnehmer wird dieses Seminar wiederholt >>

Bitte reservieren Sie Ihren Platz rechtzeitig!

„Sehr gut, sicherlich einzigartig. Sonst erfährt man die Lizenzprobleme nie in einer derart kompakten Form.“

„Das Wissen von DBConcepts und die praktische Erfahrung sind sehr gut rübergekommen. Die ausgehändigten Unterlagen sind ausgezeichnet.“

 

 

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.