Logo Oracle Deutschland September 2016
Oracle Data Redaction
von Ralf Durben

Seit dem Datenbank Release Oracle Database 12c gibt es im Rahmen der Advanced Security Option (ASO) das Feature 'Data Redaction', welches auch für 11.2.0.4 nachträglich verfügbar ist (Backport). Dieser Tipp zeigt Ihnen, wie Data Redaction funktioniert und wann dieses Feature zum Einsatz kommt. Das Ziel ist dabei ein dynamisches Data Masking, also eine Unkenntlichmachung von Teilen der Ausgabe direkt beim Zugriff auf die Daten.

Einführung

Jeder kennt Data Redaction aus eigener Erfahrung, ohne vielleicht darüber nachgedacht zu haben: Auf dem Kassenbeleg einer Kreditkartenzahlung, wie zum Beispiel in einem Parkhaus, sind nicht alle Ziffern der Kreditkartennummer ausgedruckt, sondern nur die letzten Ziffern dieser Nummer. Die übrigen Ziffern sind zum Beispiel durch '*' unkenntlich gemacht. Traditionell wird dieses unkenntlich Machen in der Anwendung programmiert, und zwar in jeder einzelnen Anwendung, die auf die Kreditkartennummer zugreift. Und damit auch in jedem einzelnen Gerät, wie zum Beispiel die Kassenautomaten. Eine Umstellung der Darstellung im Klartext zu einer unkenntlich gemachten Darstellung oder Veränderung bei der Art der Darstellung, ist daher unter Umständen mit einem großen Aufwand verbunden.

Mit Oracle Data Redaction kann das unkenntlich Machen nun zentral, also direkt in der Tabelle bei den Daten hinterlegt werden und gilt damit für jeden Daten-Zugriff von definierten Benutzern oder Clients (wie im Beispiel die Kassenautomaten), der letztlich zu einer Bildschirm- oder Druckausgabe führt. Dabei findet die Veränderung der Darstellung auf der obersten Ebene des SQL Layers statt, also nach der Auswahl von Zeilen und Spalten. Die Kreditkartennummer, die eigentlich unkenntlich gemacht wird, kann also zum Beispiel in WHERE Bedingungen nach wie vor verwendet werden. Auf Spalten, die mit Data Redaction unkenntlich gemacht werden, können auch nach wie vor Berechnungen durchgeführt oder Indizes angelegt werden.

Mitunter wird nach dem Unterschied zwischen Data Masking, wie es zum Beispiel mit dem Oracle Enterprise Manager Cloud Control Data Masking Pack angeboten wird, und Data Redaction, dem ASO Feature, gefragt. Diese Frage ist naheliegend, denn es geht in beiden Fällen um die Veränderung von Daten. Allerdings verändert Data Masking Daten permanent. Data Masking zielt darauf, in Entwicklungs- und Testumgebungen mit realistischen Daten arbeiten zu können, ohne diese mit dem gleichen Aufwand schützen zu müssen, der für die Originaldaten im Produktivsystem vorgeschrieben ist. Data Redaction verändert zwar ebenfalls Daten, aber ausschliesslich für die Ausgabe und damit der Darstellung von Produktivdaten, die in Berichten oder Anzeigemasken sichtbar werden. Die ursprünglichen, also gespeicherten, Daten bleiben dabei unverändert. Die mit Data Redaction bearbeiteten Daten können sogar nach wie vor für WHERE Bedingungen, in INSERTs, UPDATEs und DELETEs, für Berechnungen und für das Anlegen von Indizes verwendet werden.

Data Redaction: Der Rahmen

Data Redaction wird über das Package DBMS_REDACT eingesetzt. Um Data Redaction zu nutzen wird also das EXECUTE Privileg für das Package benötigt.

Es stehen vier unterschiedliche Möglichkeiten des Redigierens zur Verfügung. Alle erhalten den Datentyp der Daten, auf die sie angewendet werden.

Bevor die Beispiele erläutert werden, noch einige wichtige Hinweise.
  1. Während viele Datentypen unterstützt werden, steht Data Redaction zur Zeit für einige Datentypen NICHT zur Verfügung, zum Beispiel für Daten der Typen RAW, BLOB, CLOB, XML Type und einige mehr.
  2. Bei geschachtelten Funktionen wird Data Redaction von innen nach aussen angewendet, bei Inline Views umgekehrt von aussen nach innen.
  3. Objekte von SYS oder SYSTEM können nicht redigiert werden.
  4. Für die Benutzer SYS und SYSTEM werden die Policies zum Data Redaction NICHT angewendet, denn beide verfügen über das System Privileg EXEMPT REDACTION POLICY. SYSTEM kommt über das System Privileg EXP FULL DATABASE zu dieser Ausnahmeregelung, denn EXEMPT REDACTION POLICY ist Teil dieses Export Privilegs. Das EXP FULL DATABASE das Privileg benötigt, bedarf wohl keiner Erklärung.
  5. In den Ausführungsplänen ist die Veränderung der tatsächlichen Daten nicht sichtbar.

Data Redaction: Beispiele

Data Redaction wird im Enterprise Manager Cloud Control (siehe Abbildung) und im SQL*Developer unterstützt.

Das ist zwar sehr komfortabel, fördert aber nicht das Verständnis. Deshalb zeigen die Beispiele die Prozeduraufrufe, die ja letztendlich auch durch die graphischen Oberflächen im Hintergrund erzeugt werden.

Das erste Beispiel zeigt, wie in der Tabelle SCOTT.EMP die Werte der Spalte EMPNO mit der Funktion DBMS_REDACT.PARTIAL entsprechend den Angaben zum Parameter FUNCTION_PARAMETER redigiert wird. Die Ziffer 9 ersetzt die tatsächlichen Ziffern von der zweiten bis zur vierten Stelle. Der in EXPRESSION verwendete Ausdruck veranlasst, dass das Redigieren für alle Benutzer ausgeführt wird, außer für den Benutzer 'KING'. Der Vergleich der beiden Ausgaben zeigt, dass die Bedingung berücksichtigt wird. Will man das Redigieren in jedem Fall ausführen, kann das durch die Expression '1 = 1' erreicht werden. Eine Redaction Policy wird mit der Prozedur ADD_POLICY aus dem Package DBMS_REDACT erstellt (und mit DROP_POLICY gelöscht).

BEGIN
DBMS_REDACT.ADD_POLICY(
object_schema       => 'scott',
object_name         => 'emp',
column_name         => 'empno',
policy_name         => 'empno_redact',
function_type       =>  DBMS_REDACT.PARTIAL,
function_parameters => '9,2,4',
expression          => 'SYS_CONTEXT(''USERENV'',''SESSION_USER'')<>''KING''');
END;
/

-- Als Benutzer SCOTT

SQL> SELECT * FROM emp WHERE empno > 7800;

 EMPNO ENAME      JOB          MGR HIREDATE         SAL       COMM     DEPTNO
------ ---------- --------- ------ --------- ---------- ---------- ----------
  7999 KING       PRESIDENT        17-NOV-81       5000                    10
  7999 TURNER     SALESMAN    7698 08-SEP-81       1500          0         30
  7999 ADAMS      CLERK       7788 12-JAN-83       1100                    20
  7999 JAMES      CLERK       7698 03-DEC-81        950                    30
  7999 FORD       ANALYST     7566 03-DEC-81       3000                    20
  7999 MILLER     CLERK       7782 23-JAN-82       1300                    10

-- Als Benutzer KING (ist nicht automatisch angelegt)

SQL> SELECT * FROM scott.emp WHERE empno > 7800;

 EMPNO ENAME      JOB              MGR HIREDATE         SAL       COMM DEPTNO
------ ---------- --------- ---------- --------- ---------- ---------- ------
  7839 KING       PRESIDENT            17-NOV-81       5000                10
  7844 TURNER     SALESMAN        7698 08-SEP-81       1500          0     30
  7876 ADAMS      CLERK           7788 23-MAY-87       1100                20
  7900 JAMES      CLERK           7698 03-DEC-81        950                30
  7902 FORD       ANALYST         7566 03-DEC-81       3000                20
  7934 MILLER     CLERK           7782 23-JAN-82       1300                10

Für das Monitoring des Data Redaction stehen einige Views zur Verfügung: REDACTION_COLUMNS enthält Informationen zu den redigierten Spalten, REDACTION_POLICIES Details zu den definierten Policies und REDACTION_VALUES_FOR_TYPE_FULL die Werte, die bei einem vollständigen Redigieren in den redigierten Spalten ausgegeben werden.

SQL> select * from REDACTION_POLICIES;

OBJECT_OWNER OBJECT_NAME POLICY_NAME  EXPRESSION                                    ENABLE    POLICY_DESCRIPTION
------------ ----------- ------------ --------------------------------------------- --------- --------------------------------
SCOTT        EMP         empno_redact SYS_CONTEXT('USERENV','SESSION_USER')<>'KING' YES

Das zweite Beispiel erweitert die bestehende Redaction Policy mithilfe der Prozedur DBMS_REDACT.ALTER_POLICY. Das Verwenden von ALTER_POLICY ist nötig, weil die bestehende Policy erhalten werden soll und mit einer Tabelle nur jeweils eine einzige Redaction Policy verbunden werden kann. ALTER_POLICY kann ausser zum Hinzufügen einer weiteren zu redigierenden Spalte dazu verwendet werden, die Art des Redigierens oder die Parameter des Redigierens für eine Spalte zu ändern, eine andere Bedingung für das Anwenden festzulegen oder das Redigieren für eine Spalte auszuschalten.

BEGIN
DBMS_REDACT.ALTER_POLICY(
object_schema       => 'scott',
object_name         => 'emp',
column_name         => 'sal',
policy_name         => 'empno_redact',
action              =>  DBMS_REDACT.ADD_COLUMN,
function_type       =>  DBMS_REDACT.FULL);
END;
/

-- Wieder als Benutzer SCOTT

SQL> SELECT * FROM emp WHERE empno > 7800;

 EMPNO ENAME      JOB              MGR HIREDATE         SAL       COMM DEPTNO
------ ---------- --------- ---------- --------- ---------- ---------- ------
  7999 KING       PRESIDENT            17-NOV-81          0                10                       
  7999 TURNER     SALESMAN        7698 08-SEP-81          0          0     30
  7999 ADAMS      CLERK           7788 23-MAY-87          0                20
  7999 JAMES      CLERK           7698 03-DEC-81          0                30
  7999 FORD       ANALYST         7566 03-DEC-81          0                20
  7999 MILLER     CLERK           7782 23-JAN-82          0                10

Die Gehälter in der Spalte SAL werden, da als Funktionstyp FULL ohne weitere Angaben vorgegeben ist, mit dem Wert 0 ausgegeben.

Im dritten und letzten Beispiel soll das Einstellungsdatum als Zufallswert ausgegeben werden. Aus den oben genannten Gründen wird auch hier mit DBMS_REDACT.ALTER_POLICY gearbeitet.

BEGIN
DBMS_REDACT.ALTER_POLICY(
object_schema       => 'scott',
object_name         => 'emp',
column_name         => 'hiredate',
policy_name         => 'empno_redact',
action              =>  DBMS_REDACT.ADD_COLUMN,
function_type       =>  DBMS_REDACT.RANDOM);
END;
/

-- Als Benutzer SCOTT

SQL> SELECT * FROM emp WHERE empno > 7800;

 EMPNO ENAME      JOB              MGR HIREDATE         SAL       COMM DEPTNO
------ ---------- --------- ---------- --------- ---------- ---------- ------
  7999 KING       PRESIDENT            11-MAY-25          0                10
  7999 TURNER     SALESMAN        7698 14-DEC-11          0          0     30
  7999 ADAMS      CLERK           7788 17-APR-25          0                20
  7999 JAMES      CLERK           7698 14-DEC-83          0                30
  7999 FORD       ANALYST         7566 24-SEP-69          0                20
  7999 MILLER     CLERK           7782 09-AUG-12          0                10

-- Zur Kontrolle wieder als Benutzer KING

SQL> SELECT * FROM scott.emp WHERE empno > 7800;

 EMPNO ENAME      JOB              MGR HIREDATE         SAL       COMM DEPTNO
------ ---------- --------- ---------- --------- ---------- ---------- ------
  7839 KING       PRESIDENT            17-NOV-81       5000                10
  7844 TURNER     SALESMAN        7698 08-SEP-81       1500          0     30
  7876 ADAMS      CLERK           7788 23-MAY-87       1100                20
  7900 JAMES      CLERK           7698 03-DEC-81        950                30
  7902 FORD       ANALYST         7566 03-DEC-81       3000                20
  7934 MILLER     CLERK           7782 23-JAN-82       1300                10

Wie nicht anders zu erwarten, sieht der Benutzer SCOTT für die Einstellungsdaten zufällige Daten, während KING die korrekten Daten angezeigt erhält.

Data Redaction: Zusammenspiel mit anderen Features

Data Redaction findet in der Datenbank, wie oben schon erwähnt, im SQL Layer als eine der letzten Aktionen statt. Da stellt sich natürlich die Frage inwieweit Data Redaction Einfluß auf andere Features oder Produkte von Oracle hat.

PL/SQL Prozeduren und Funktionen

PL/SQL Prozeduren und Funktionen verwenden normales SQL und bekommen auch die Ausgabe der gesamten SQL Abfrage als Ergebnis. In einem einfachen Beispiel zeigt sich dieses: in einer Funktion wird im obigen Beispiel das Minimum der Spalte EMPNO angezeigt.

create or replace function min_empno 
 return number
 as
  n number; 
 begin 
  select min(empno) into n from emp;
  return n;
 end;
/

-- Als Benutzer SCOTT
SQL> select min_empno from dual;

 MIN_EMPNO
----------
      7999

Die PL/SQL Funktion wird hier in einem SELECT Kommando für die Tabelle dual aufgerufen. Das Redaction findet also in der Funktion statt, wo das Ergebnis der Abfrage in unkenntlich gemachter Form einer Variablen zugewiesen wird und ggf. auch für weitere Berechnungen herangezogen werden würde. Auch wenn in einer PL/SQL Prozedur oder Funktion mit einem Cursor gearbeitet wird, kommt Redaction zum Einsatz. Die folgende Funktion ermittelt wie das obige Beispiel das Minimum aller EMPNO-Werte:

create or replace function min_empno_by_cursor
 return number
as
 n number:=9999999;
 t number;
 cursor c is select empno from emp;
begin
 open c;
 loop
  fetch c into t;
  exit when c%NOTFOUND;
  if nvl(n,0)>nvl(t,0) then n:=t; end if;
 end loop;
 close c;
 return n;
end;
/

-- Als Benutzer SCOTT
SQL> min_empno_by_cursor from dual;

MIN_EMPNO_BY_CURSOR
-------------------
	       7999

Trigger

Wie sieht es dann in Triggern aus? Hier ein erstes Beispiel, welches auf das obige Szenario aufsetzt. Dabei soll der Trigger den Wert der Spalte EMPNO in die Spalte SAL übertragen:

create or replace trigger t_emp 
 before update on emp 
 forselect  each row 
 begin 
  :new.sal:=:new.empno; 
 end;
 /
SQL> select * from emp;

     EMPNO ENAME      JOB	       MGR HIREDATE	    SAL       COMM     DEPTNO
---------- ---------- --------- ---------- --------- ---------- ---------- ----------
      7999 SMITH      CLERK	      7902 17-DEC-80	    800 		   20
      7999 ALLEN      SALESMAN	      7698 20-FEB-81	   1600        300	   30
      7999 WARD       SALESMAN	      7698 22-FEB-81	   1250        500	   30
      7999 JONES      MANAGER	      7839 02-APR-81	   2975 		   20
      7999 MARTIN     SALESMAN	      7698 28-SEP-81	   1250       1400	   30
      7999 BLAKE      MANAGER	      7839 01-MAY-81	   2850 		   30
      7999 CLARK      MANAGER	      7839 09-JUN-81	   2450 		   10
      7999 SCOTT      ANALYST	      7566 19-APR-87	   3000 		   20
      7999 KING       PRESIDENT 	   17-NOV-81	   5000 		   10
      7999 TURNER     SALESMAN	      7698 08-SEP-81	   1500 	 0	   30
      7999 ADAMS      CLERK	      7788 23-MAY-87	   1100 		   20
      7999 JAMES      CLERK	      7698 03-DEC-81	    950 		   30
      7999 FORD       ANALYST	      7566 03-DEC-81	   3000 		   20
      7999 MILLER     CLERK	      7782 23-JAN-82	   1300 		   10

14 rows selected.

SQL> update emp set deptno=deptno;

14 rows updated.

SQL> select * from emp;

     EMPNO ENAME      JOB	       MGR HIREDATE	    SAL       COMM     DEPTNO
---------- ---------- --------- ---------- --------- ---------- ---------- ----------
      7999 SMITH      CLERK	      7902 17-DEC-80	   7369 		   20
      7999 ALLEN      SALESMAN	      7698 20-FEB-81	   7499        300	   30
      7999 WARD       SALESMAN	      7698 22-FEB-81	   7521        500	   30
      7999 JONES      MANAGER	      7839 02-APR-81	   7566 		   20
      7999 MARTIN     SALESMAN	      7698 28-SEP-81	   7654       1400	   30
      7999 BLAKE      MANAGER	      7839 01-MAY-81	   7698 		   30
      7999 CLARK      MANAGER	      7839 09-JUN-81	   7782 		   10
      7999 SCOTT      ANALYST	      7566 19-APR-87	   7788 		   20
      7999 KING       PRESIDENT 	   17-NOV-81	   7839 		   10
      7999 TURNER     SALESMAN	      7698 08-SEP-81	   7844 	 0	   30
      7999 ADAMS      CLERK	      7788 23-MAY-87	   7876 		   20
      7999 JAMES      CLERK	      7698 03-DEC-81	   7900 		   30
      7999 FORD       ANALYST	      7566 03-DEC-81	   7902 		   20
      7999 MILLER     CLERK	      7782 23-JAN-82	   7934 		   10

14 rows selected.

SQL> rollback;

Rollback complete.

Der Trigger wurde gezündet und ausgeführt. Dabei wurden aber die Originalwerte der Spalte EMPNO in die Spalte SAL übertragen. Dieses liegt an dem speziellen Zugriff auf die EMPNO durch :new.empno, welches kein normales SQL ist und daher nicht durch die Redaction Policy geht. Dieses wird klar bei folgendem Beispiel:

create or replace trigger t_dept 
 before update on dept 
 for each row 
 declare
  n number;
 begin 
  select min(empno) into n from emp where deptno=:new.deptno;
  :new.dname:=n; 
 end;
 /
SQL> select * from dept;

    DEPTNO DNAME	  LOC
---------- -------------- -------------
	10 ACCOUNTING	  NEW YORK
	20 RESEARCH	  DALLAS
	30 SALES	  CHICAGO
	40 OPERATIONS	  BOSTON

SQL> update dept set deptno=deptno;

4 rows updated.

SQL> select * from dept;

    DEPTNO DNAME	  LOC
---------- -------------- -------------
	10 7999 	  NEW YORK
	20 7999 	  DALLAS
	30 7999 	  CHICAGO
	40		  BOSTON

SQL> rollback;

Rollback complete.

Da hier der Trigger ein normales SQL Kommando ausführt, ist das Ergebnis der Abfrage wieder entsprechend der Redaction Policy.

Database Links

Eine Abfrage über einen Datenbank Link ist letztlich wieder eine normale Abfrage, die in der Datenbank ausgeführt wird, die per Database Link angesprochen wird. Wenn also von einer anderen Datenbank, ohne Redaction Policy ein Zugriff auf EMP erfolgt:

SQL> select * from emp@pdbc101;

     EMPNO ENAME      JOB	       MGR HIREDATE	    SAL       COMM     DEPTNO
---------- ---------- --------- ---------- --------- ---------- ---------- ----------
      7999 SMITH      CLERK	      7902 17-DEC-80	    800 		   20
      7999 ALLEN      SALESMAN	      7698 20-FEB-81	   1600        300	   30
      7999 WARD       SALESMAN	      7698 22-FEB-81	   1250        500	   30
      7999 JONES      MANAGER	      7839 02-APR-81	   2975 		   20
      7999 MARTIN     SALESMAN	      7698 28-SEP-81	   1250       1400	   30
      7999 BLAKE      MANAGER	      7839 01-MAY-81	   2850 		   30
      7999 CLARK      MANAGER	      7839 09-JUN-81	   2450 		   10
      7999 SCOTT      ANALYST	      7566 19-APR-87	   3000 		   20
      7999 KING       PRESIDENT 	   17-NOV-81	   5000 		   10
      7999 TURNER     SALESMAN	      7698 08-SEP-81	   1500 	 0	   30
      7999 ADAMS      CLERK	      7788 23-MAY-87	   1100 		   20
      7999 JAMES      CLERK	      7698 03-DEC-81	    950 		   30
      7999 FORD       ANALYST	      7566 03-DEC-81	   3000 		   20
      7999 MILLER     CLERK	      7782 23-JAN-82	   1300 		   10

14 rows selected.

wird die Redaction Policy auf der Seite der Daten liefernden Datenbank angewandt.

Views und Materialized Views

Normale Views sind gespeicherte Abfragen, die dann mit der Abfrage, die die View aufruft zu einer Gesamtabfrage zusammengebaut werden. Daher wird die Redaction Policy auch hier erst am Ende des Bearbeitungsprozesses durchgeführt. Als Beispiel dient eine einfache View:

SQL> create or replace view v_emp
as
select empno from emp;

-- Als Benutzer SCOTT
SQL> select * from emp where empno=7654;

     EMPNO ENAME      JOB	       MGR HIREDATE	    SAL       COMM     DEPTNO
---------- ---------- --------- ---------- --------- ---------- ---------- ----------
      7999 MARTIN     SALESMAN	      7698 28-SEP-81	   1250       1400	   30

SQL> select * from v_emp where empno=7654;

     EMPNO
----------
      7999

Es gibt, wie die erste Abfrage zeigt, einen Mitarbeiter mit der 'empno=7654'. Dieses Kriterium kann auch in der View verwendet werden, obwohl die Definition suggeriert, dass die gespeicherte Abfrage das unkenntlich gemachte Ergebnis enthält. Dem ist aber nicht so. Die Abfrage wird mit der durch die View definierten Abfrage zu einer Gesamtabfrage zusammengesetzt und erst dann als EINE Abfrage ausgeführt.

Wie sieht das bei Materialized Views aus, bei denen das Ergebnis der Abfrage ja wirklich gespeichert wird? Im folgenden Beispiel versucht der Benutzer SCOTT eine Materialized View anzulegen, wobei er das Recht "CREATE MATERIALIZED VIEW" besitzt.

SQL> create materialized view mv_emp
enable query rewrite
as
 select empno,ename,sal from emp;

ERROR at line 4:
ORA-28081: Insufficient privileges - the command references a redacted object.

Dieses schlägt also fehl. Mit den Rechten eines DBAs ausgestattet ist der Versuch erfolgreich:

SQL> create materialized view mv_emp
enable query rewrite
as
 select empno,ename,sal from emp;

Materialized view created.

SQL> select * from mv_emp

     EMPNO ENAME	     SAL
---------- ---------- ----------
      7369 SMITH	     800
      7499 ALLEN	    1600
      7521 WARD 	    1250
      7566 JONES	    2975
      7654 MARTIN	    1250
      7698 BLAKE	    2850
      7782 CLARK	    2450
      7788 SCOTT	    3000
      7839 KING 	    5000
      7844 TURNER	    1500
      7876 ADAMS	    1100
      7900 JAMES	     950
      7902 FORD 	    3000
      7934 MILLER	    1300

14 rows selected.

Die Daten in der Materialized View sind also als Originaldaten gespeichert. Es ist auch nicht möglich, wirksame Redaction Policies direkt für die Materialized View zu erstellen. Die Nutzung von Materialized Views ist ja dadurch gekennzeichnet, dass der Zugriff eigentlich auf die Ursprungstabelle (oder mehrere) durchgeführt wird und dann ein Query Rewrite erfolgt, wobei auf Daten der Materialized View zurückgegriffen wird. Letztlich ist es dann aber eine Abfrage auf die Ursprungstabelle(n) (hier im Beispiel die Tabelle emp), für die deren Redaction Policy dann zum Einsatz kommt.

Golden Gate

Golden Gate ist eine Replikationslösung und dabei stellen sich zwei Fragen, deren Antwort hier auch gleich gegeben wird:

Weitere Features

Informationen dazu, wie Data Redaction mit weiteren Datenbankfeatures zusammenspielt, finden Sie im Handbuch.

Hinweis zur Lizenzierung

Data Redaction ist im Rahmen der Advanced Security Option separat zu lizenzieren.

Weitere Informationen

Informationen zu Data Redaction auf OTN mit Hinweisen zu Whitepaper, Referenzen und weiteres.

Die vollständigen Informationen zum Thema Data Redaction finden sich in den entsprechenden Handbüchern und zwar in den Kapiteln der Oracle Advanced Security Administrator Guides für die Version 11 beziehungsweise für die Version 12 sowie in den Kapiteln des Referenzhandbücher Oracle Database PL/SQL Packages and Types Reference der Version 11 oder der Version 12. Die Unterschiede in der Funktionalität sind minimal und beschränken sich auf den Umgang mit LOBs, wenn sie vollständig durch Defaultwerte ersetzt werden.

Zurück zum Anfang des Artikels

Zurück zur Community-Seite