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

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 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.