Beiträge

Oracle In-Memory Performance ohne Lizenzkosten

, ,

Im einem unserer Kundenprojekte werden für eine Bundesbehörde die Daten von ärztlichen Behandlungskosten ausgewertet. Hierfür sind teils komplexe Auswertungen nötig, die in weiten Teilen mit dem Oracle Analytics Server (OAS) in Echtzeit erfolgen. Um für die Anwender von Ad-Hoc-Reports keine allzu langen Wartezeiten entstehen zu lassen, wird seit 2021 die Oracle In-Memory Option verwendet, und zwar in der lizenzfreien Base-Level-Variante. Da diese nur die Bereitstellung von 16GB Daten zulässt, wurde ein reduzierter Data Mart entworfen. Auf diese Weise ist trotz der Limitierungen der kostenlosen In-Memory-Variante eine messbare Beschleunigung der Abfragen möglich geworden.

Komplexe Abfragen

Der Datamart des Data Warehouse (DWH) beherbergt 420 Millionen Fakten zuzüglich der entsprechenden Dimensionen. Die Auswertungen bestehen sowohl aus Standardberichten als auch aus interaktiven „Drill Down Reports”. Aus der Zeitdimension und den Dimensionen der zuständigen Bearbeitungsbehörden und Kunden werden für diese Berichte Hierarchien gebildet, die sich je nach Auswertung neu gruppieren. In den Auswertungen spielen die Laufzeiten der Anträge verteilt auf die Bearbeitungsstelle und bestimmte zu errechnende Intervalle (Wochen, Monate und bestimmte Meilensteine in der Antragsbearbeitung) eine entscheidende Rolle. Die fachliche Logik für die so errechneten Kennzahlen wurde im BI-Team zu den ursprünglich vorhandenen Anforderungen ergänzt oder sogar neu erstellt. Die Entwicklung wurde teilweise parallel zur Festschreibung der Anforderungen quasi agil vorangetrieben. Aus diesen Gründen wurde ein Großteil der fachlichen Logik direkt im BI-Tool (OAS, damals OBIEE) entworfen – die Entwicklungszyklen boten keinen Platz für die vorherige Ausgestaltung von ETL-Prozessen.

Lange Wartezeiten

Aus diesen Gründen ist das Datenmodell des Data Mart, aus dem die Berichte versorgt werden, nah an der Datenquelle gestaltet. Die Fakten und Dimensionen sind nicht so gestaltet, dass die Berichte direkt versorgt werden können. Dazu kommt, dass es mehrere Zeitstrahlen gibt, an denen sich die Daten ausrichten (Bi-/Tritemporale Historisierung nach der Zeit des Auftauchens der Datensätze im DWH sowie mehrerer fachlicher Zeitlinien). Die daraus resultieren SQL-Abfragen des OAS sind dementsprechend aufwendig und müssen oft mehrere Fakten miteinander verbinden. Das führte zu langen Wartezeiten beim Erstellen der Berichte. Der Zugriff auf die Standardberichte ist schneller, wenn der OAS diese bereits einmal ausgeführt hat und im Cache hält. Daher werden diese jeden Morgen einmal mit Hilfe eines OAS-Agenten ausgeführt. Das kann aber nur mit einigen wenigen Standardwerten erfolgen. Soll ein individueller Bericht ausgegeben werden, ergeben sich nach wie vor noch längere Wartezeiten.

Ein Datamart in Kleidergrößen

Um die Datenmengen, die kombiniert werden müssen, zu reduzieren, wurden Tabellen mit dem Suffix „XS” eingeführt – angelehnt an die extra kleine Kleidergröße. In den XS-Tabellen werden nur die Fakten der gängigsten Anfrageintervalle aufgenommen. Dieser Prozess wurde in einer Zeit entwickelt, in der es nicht gelang, das OAS Repository so einzurichten, dass das Partitionierungskriterium zuverlässig aufgenommen wurde. Bei der Planung der In-Memory-Konfiguration erwies sich der XS-Datamart neben dem nur noch als Archiv genutzten vollständigen Datamart in Größe L als sehr hilfreich. Denn der gesamte Inhalt der XS-Größe passt in den 16GB-Storage, der für die nutzbaren Daten als maximale Größe (Base-Level-Lizenzvariante) durch Oracle vorgegeben ist.

Beauftragung und Einrichtung

Eine separate Beauftragung oder Installation der In-Memory-Option war nicht erforderlich. Lediglich die SGA (System Global Area – Speicherbereich der Oracle Datenbank) wurde vergrößert, um Platz für die In-Memory-Area zu schaffen. Die Konfiguration dafür bestand aus dem Setzen von drei Initialisierungs-Parametern:

alter system set inmemory_force=base_level scope=spfile;
alter system set inmemory_size=16G scope=spfile;
alter system set sga_target=42G scope=spfile;

Die Datenbank verfügt über 90 GB RAM in der Produktionsinstanz.
Anschließend ist die angepasste Konfiguration zum Beispiel im AWR-Bericht wie folgt zu sehen:

Der Parameter INMEMORY_SIZE wird in der CDB eingestellt.

Funktionsweise der In-Memory-Option

Bei der Oracle In-Memory-Option handelt es sich um eine Erweiterung der relationalen Datenbank von Oracle. Die Daten werden zusätzlich zur bisherigen Speicherung in der Datenbank auch im Arbeitsspeicher des Datenbankservers gehalten, und zwar im sogenannten „Column Store”. Dabei werden die Daten mittels einer speziellen Komprimierungstechnik (Columnar Compression) stark komprimiert. Je nach Konfiguration sind Kompressionsraten zwischen 2 und 20 möglich. 
Der entscheidende Unterschied zwischen einem reinen Caching der Zugriffe, wie im Database Buffer Cache, und dem In-Memory-Column-Store liegt darin, dass für In-Memory die Daten nicht zeilenweise (bzw. als Tabellenblöcke) in den Arbeitsspeicher geladen werden, sondern spaltenweise komprimiert im RAM gehalten werden. Diese Speichermethode erlaubt sehr effiziente Abfragen auf einzelne oder wenige Spalten von großen Tabellen mit vielen Zeilen, die mittels Filtern eingeschränkt und aggregiert werden. Diese Art von Abfragen kommen typischerweise in Data Warehouses vor.
Ist die In-Memory-Option aktiviert, stehen die Daten sowohl zeilenweise als auch spaltenweise (im In-Memory-Column-Store) zur Verfügung. Je nach Art der Abfrage wird auf die einzelnen Tabellenblöcke (auf Disk oder via Buffer Cache) oder auf den Column Store zugegriffen. Änderungen werden im Column Store nachgeführt, sodass die In-Memory-Option ohne applikatorische Anpassungen verwendet werden kann.

Das Base Level Feature unterstützt alle In Memory Funktionen außer:

  • Automatic In-Memory  (AIM)
  • Compression levels außer MEMCOMPRESS FOR QUERY LOW
  • Excluded columns (Es werden immer alle Spalten einer Tabelle geladen)
  • CELLMEMORY Feature in Exadata

Alle anderen Database In-Memory Features wie In-Memory Expressions, Join Groups, Automatic Data Optimization (ADO) und FastStart stehen zur Verfügung.

Auslagern der XS-Tabellen in die In-Memory-Area

Die Faktendaten in unserem Projekt haben einen Umfang von ca. 45 GB (420 Millionen Zeilen), dazu kommen 116 MB Dimensionen (2 Millionen Zeilen).
Der XS-Datamart hat aktuell einen Umfang von 11 GB (150 Millionen Zeilen). Es sind ein Jahr Abrechnungsdaten enthalten, allerdings inklusive der aktuell bestehenden Referenzen zwischen XS- und XL-Daten.
Die XS-Tabellen entstehen, indem zuerst die Daten für die kompletten Tabellen zusammengerechnet und dann die überflüssigen Daten wieder entfernt werden. All dies erfolgt im Rahmen der nächtlichen Beladung mit dem Oracle Data Integrator (ODI).
Die relevanten Tabellen des XS-Datamarts werden anschließend mittels „ALTER TABLE INMEMORY” in den In-Memory-Bereich geladen. Hierfür wurden PL/SQL-Prozeduren in einem bestehenden PL/SQL-Package angelegt, die den XS-Datamart be- und entladen.

Leistungssteigerung in den Abfragen

Nach dem erstmaligen Einrichten der In-Memory-Area wurden zunächst einige bekannte Abfragen in der Entwicklungstestumgebung ausgeführt, die für ihre langen Antwortzeiten bekannt waren:

Die Laufzeit des obigen Statements war:

TestLaufzeit sPlan
Archiv-Tabellen7,8
XS-Tabellen ohne IM4Hash Join. Nested Loops, Full Scan, Fast Full Scan, Range Scan
XS mit IM0,233Hash join, inmemory full

Ergebnisse für die Anwender

In den Ausführungsplänen des oben genannten Statements in der Produktion lassen sich die In-Memory-Zugriffe gut erkennen.

Die Performance-Steigerung nur in diesem Fall beträgt bei einer Antwortzeit von 0,445 statt 3,359 Sekunden fast Faktor 8.

Beobachtung des In-Memory-Bereiches

Der Füllstand der In-Memory-Area lässt sich mit einer einfachen View beobachten:

Während des Betriebes kann man die Arbeit der In-Memory-Option beim Befüllen des Speicherbereiches auch im AWR-Report beobachten:

Den Füllstand des In-Memory-Speicherbereiches beobachten wir in einem einfachen OAS-Bericht.

Fazit

Ist es möglich, einen Datamart zu erzeugen, der nicht größer als 16GB ist, kann man die kostenfreie BASE LEVEL Variante der Oracle-In-Memory Option durchaus mit messbarem Erfolg einsetzen. Dies erfordert allerdings bei nichttrivialen DWH-Größen die Entwicklung eines Frameworks, das diesen reduzierten Datamart auch pflegt. Wir erledigen das im ODI und mit PL/SQL. Es muss allerdings auch im OAS eine Subject-Area für den reduzierten Bereich erstellt werden. Das ist ein Mehraufwand, den das Projekt für eine in entscheidenden Teilen achtfache Beschleunigung zu tragen gewillt ist.

Quellen

  1. Mike Dietrich: Oracle Database In-Memory BASE_LEVEL Feature available since 19.8.0
  2. Dani Schnider: Oracle In-Memory & Data Warehouse: Die perfekte Kombination?
  3. Oracle Database In-Memory Base Level Feature
  4. Oracle 12c Multitenant – Inmemory admin basics

Datenbank-Link Passwörter sind jetzt noch unsicherer

, ,

Die Passwörter von Oracle Datenbank Links waren Thema des diesjährigen Vortrags “Best of Oracle Security 2017” von Alexander Kornbrust auf der diesjährigen DOAG Konferenz in Nürnberg.

Es ist dank der Arbeit von Mahmoud Hatem mittlerweile möglich, die verschlüsselt abgelegten Passwörter der Datenbank-Links relativ aufwandslos mit Hilfe eines kleinen PL/SQL-Skriptes zu entschlüsseln. Das Skript selbst lässt sich bei  GitHub herunterladen. Das ist ein bisschen schade, aber auch fast vorhersehbar, denn wie auch bei Wallets ist es sehr schwierig, ein symmetrisches Passwort geheim zu halten. Zumal, wenn es automatisch, also ohne Interaktion mit dem Benutzer, verwendet werden soll. In einer ausgelieferten Software finden sich selten sichere “Verstecke” für ein hart-kodiertes Passwort.

Oracle hat offensichtlich versucht, das verwendete Passwort an zwei Stellen zu verbergen – in der Data Dictionary View SYS.PROP$ und im oracle-Binary selbst als Variable “ztcshpl_v6”. Diese ist dort natürlich immer gleich belegt. Vielleicht wäre es besser gewesen, saubere Hash-Werte der Passwörter zu verwenden, als einen solchen “Security through obscurity”-Weg zu gehen.

Jedenfalls ist es nun, Zugriff auf die Data Dictionary Views SYS.LINK$ und SYS.PROPS$ vorausgesetzt, möglich, die Klartext-Passwörter der Datenbank-Links einfach zu ermitteln.

Die Datenbank-Link-Passwörter und deren Geschichte in den Oracle Versionen waren auch hier im Blog bereits Thema, wenn auch fälschlicherweise von Hashes statt verschlüsselten Werten die Rede war. Dennoch hat unser Blog Post es als Quelle auf die Vortragsfolien geschafft, worüber ich mich sehr freue, denn dieser Vortrag von Alexander Kornbrust gehört traditionell zu den Highlights der DOAG Konferenz.

Oracle Security 2017 Slides

(c) Red-Database-Security GmbH

Neuer Kerberos Stack: AD Authentifikation für Datenbank 12c

,

Wir haben in diesem Blog des öfteren die Empfehlung ausgesprochen, eine zentrale Benutzerverwaltung statt lokaler Benutzerkonten für den Zugang zu Oracle Datenbanken zu verwenden. Für Umgebungen mit bestehender Active Directory Infrastruktur bietet sich hierfür in erster Linie die AD-Anbindung über LDAP und Kerberos an.

Die Kerberos-Unterstützung ist bereits seit Version 7 der Oracle Datenbank vorhanden und gut dokumentiert. Für die Anbindung an Active Directory wird in der Regel ein Oracle LDAP-Server (OID oder OUD) verwendet, um die Oracle-spezifischen Einstellungen nicht im Active Directory Verzeichnis speichern zu müssen. Die Einrichtung dieser Komponenten mit der Datenbank 11gR2, dem Oracle Internet Directory als LDAP-Server und Microsoft Windows Server 2008 haben wir bereits in diesem Blog und in unserem Wiki beschrieben.

Für einen Kunden haben wir die zentrale Authentifikation mit Kerberos, AD, OUD und EUS gerade mit den aktuellen Software-Versionen (Datenbank 12.1, Windows Server 2012 und Java 8) aufgebaut und sind dabei auf eine Reihe von Besonderheiten gestossen, die bei der Einrichtung beachtet werden sollten. Ansonsten sieht man sich schnell mit einer Reihe von Inkompatibilitäten konfrontiert, die verhindern, das die Komponenten miteinander funktionieren. Die alten Anleitungen funktionieren nicht mehr. Das liegt vor allem daran, das Oracle den Kerberos Stack in der Datenbank 12c komplett überarbeitet oder sogar neu geschrieben hat.

Beachtet werden muß im Einzelnen:

Für Oracle Universal Directory (OUD):

  • Der Network Configuration Assistant funktioniert nicht mit Active Directory. Die LDAP-Konfiguration muss per Hand angelegt werden.
  • Das EUSM-Tool zum Einrichten der Zuordnung zwischen AD- und Datenbank-Benutzern (EUS Mappings) ist von mehreren Bugs betroffen und funktioniert nicht mehr. Abhilfe schafft:
    • Installation von Patch 20529805 im OUD (Hintergrund: Bug: 20529805 – SUPPORT FOR EUSM 12C AUTHENTICATION SCHEME IN OUD IS MISSING: Falsche DN-Syntax durch neue SASL-Implementation in  OUD)
    • Verwendung von AES-Hashes für OUD-Passwörter ist für EUS obligatorisch, um OUD aber nicht standardmässig aktiviert, daher muss das OUD “Default Passwort Storage Scheme” verändert werden
  • Die Datenbank möchte unbedingt eine SSLv3-Verbindung zum LDAP-Server aufbauen, SSLv3 ist aber in Java 8 nach der Poodle Attacke abgeschaltet. Es gibt einen Oracle-Patch, der aber nicht öffentlich ist. Alternativ kann SSLv3 im Java des OUD-Servers wieder eingeschaltet werden

Für Kerberos:

  • Für die Datenbank 12c müssen Kerberos-Keytab-Dateien auf dem AD-Server Windows 2012 unter Umständen mit der Option “-crypto RC4-HMAC-NT” erzeugt werden. In einigen Fällen erzeugt der AD Keytab-Dateien mit DES statt AES, wenn die RC4-HMAC-Option nicht explizit angefordert wurde. In diesen Fällen sollte die AD-Konfiguration überprüft werden. DES ist natürlich keine aktuelle Option mehr, aber RC4-HMAC eigentlich auch nicht.
  • In einigen Fällen ist es notwendig, Kerberos Pre-Authentication-Support in der SQL-Net Konfiguration einzuschalten, oder Pre-Authentication im AD auszuschalten.

Wir haben die gesamte Konfiguration in zwei Wiki-Artikeln zu jeweils EUS/OUD und Kerberos beispielhaft und mit allen Fehlerbehandlungen beschrieben.

Oracle Wallets hacken

, , ,

Oracle Wallets werden benutzt, um SSL Zertifikate, die dazugehörigen Schlüssel, aber auch Klartext-Passwörter (Secure Enterprise Password Store) abzulegen. Sie werden normalerweise durch ein Wallet-Passwort geschützt, das bei jedem Öffnen oder Auslesen eingegeben werden muß.

Um auch automatisiert mit Wallets arbeiten zu können, gibt es die Auto-Login-Funktion. Wird diese aktiviert, wird eine zusätzliche Datei im Wallet erzeugt, die sogenannte Single Sign On Datei (.sso). Diese ist ebenfalls verschlüsselt, aber nicht mit einem benutzerdefinierten Passwort, sondern mit einem Standard-Passwort. Auto-Login-Wallets werden in der Regel verwendet, um eine automatisierte Anmeldung an der Datenbank durchführen zu können, ohne dass ein Passwort im Klartext in Skripten, Konfigurationsdateien oder Umgebungsvariablen abgelegt werden muss.

Damit es nicht möglich ist, ein Wallet einfach zu kopieren und von einem anderen Rechner aus zu verwenden, gibt es die Auto-Login-Local-Funktion. Wird diese für ein Wallet eingestellt, so kann das Auto Login Wallet nur auf dem Rechner verwendet werden, auf dem es erzeugt wurde.

Weiterlesen

Enterprise Security mit LDAP und PKI – Varianten der zentralen Benutzerverwaltung für Oracle Datenbanken

, , ,

Einleitung

Direkte Benutzerkonten und Passwörter in der Datenbank sind eine Sicherheits-Schwachstelle, da in der Regel keine eindeutige Zuordnung von natürlichen Personen zu Benutzerkonten möglich ist, keine unternehmenseinheitliche Sicherheitsregel durchgesetzt werden kann und ausgeschiedene Mitarbeiter nicht sicher und sofort aus sämtlichen Systemen ausgeschlossen werden können.

In diesem Artikel werden die verschiedenen Möglichkeiten aufgezeigt, Enterprise Single Sign On und Public Key Infrastructure (PKI) zu nutzen, um Datenbankbenutzer zu authentifizieren. Anhand von Projekterfahrungen aus der Praxis wird die Integration der Oracle Datenbank mit LDAP-Verzeichnissen (OID, OUD) und Microsoft ActiveDirectory mit und ohne Oracle Virtual Directory (OVD) erklärt sowie die Einführung von SmartCard-basierter PKI als Alternative vorgestellt. Weiterlesen

Passwörter wiederherstellen in Oracle 11g

,

In der Datenbank Version 11gR1 hat Oracle bekanntlich case-sensitive Passwörter und einen neuen Passwort-Algorithmus eingeführt. In der Datenbank werden nicht die Klartext-Passwörter, sondern nur deren Hashes abgelegt, und der Algorithmus, mit dem diese Hashes berechnet werden, war bei 10g 3DES, und ist seit 11g SHA1. Im 10g-Hashverfahren fliesst der Username als Salt in den Hash mit ein, während ab 11g ein zufälliges Salt verwendet wird. Ab 11g können die Hashes also zwischen verschiedenen Benutzern geteilt werden.

Will man das Passwort eines Benutzers sichern, um es beispielsweise in einer anderen Datenbank wieder einzuspielen, kann man sich den Hash im Data Dictionary suchen (der 10g Hash steht in SYS.USER$.PASSWORD, der 11g Hash in SYS.USER$.SPARE4), und dessen Wert mit Hilfe der “BY VALUES” Klausel beim Anlegen eines neuen Users angeben:

CREATE USER AKIRA IDENTIFIED BY VALUES ‘DA3A39221404DD55’; –10g hash

ALTER USER AKIRA IDENTIFIED BY VALUES ‘S:3CAFD1F43D6958FD4F67C2EDD91B3FF54913344723750F6AE48C802D37E4’ –11g hash

Oracle erkennt hier selbstständig aus dem verwendeten Wert, ob es sich im einen 10g oder um einen 11g Hash handelt. Wird ein 11g Hash angegeben, löscht die Datenbank allerdings den 10g Hash aus dem Dictionary – und umgekehrt. Normalerweise kann man mit dieser Syntax also nur entweder einen alten oder einen neuen Hash setzen, aber nicht beide, wie man es zur vollständigen Wiederherstellung eines bisherigen Zustandes in einigen Fällen bräuchte.

In der MOS Note (Doc ID 1051962.101) hat Oracle beschrieben, wie man beide Hashes mit der “BY VALUES” Syntax eintragen kann:

alter user TEST identified by values
‘7A0F2B316C212D67;S:F3F4BA77C0E960A5973095AF787988CBE52410CB2EA53F6AF008AD99179B’;

Indem man beide Hashes mit einem Semikolon getrennt zusammen angibt.

Bei der Authentifikation ab 11g existiert eine erschreckende Sicherheitslücke im O5LOGON Protokoll, das es einem Angreifer ermöglicht, den Session Key und das Salt auszulesen, ohne Spuren zu hinterlassen. Um sie zu schließen, haben einige Datenbankadminstratoren die 11g-Authentifizierung ganz ausgeschaltet, indem sie den Parameter “SEC_CASE_SENSITIVE_LOGON=FALSE” gesetzt oder alle 11g-Hashes aus dem Dictionary gelöscht haben.

In dieser Kombination kann es zu dem Effekt kommen, dass Passwörter zum Beispiel beim Aufbau einer Testumgebung mittels der BY VALUE Methode mit einem gespeicherten 11g-Hash zurückgesetzt werden, sich aber danach kein Anwender anmelden kann, weil in der Quell-Datenbank noch der 10g-Hash verwendet wurde, dieser aber durch das Neu-Setzen des 11g-Hashes überschrieben wurde, und die Anmeldung nur mit einem 11g-Hash nicht funktioniert. Hier hilft dann die oben beschriebene Methode, beide Hashes anzugeben, so man sie denn gesichert hatte.

Siehe auch zum Thema:
  • Marcels Blog Post zum Thema Hashes in 11g. Hier wird auch der verwendete Algorithmus vollständig beschrieben.
  • “Cryptographic flaws in Oracle Database authentication protocol”, Esteban Martínez Fayó

DB Link Passwörter Metadaten in 11.2.0.4

, ,

Seit der Datenbank Version 11.2.0.4 funktioniert das Auslesen der Beschreibungen für Datenbank-Links über DBMS_METADATA.GET_DDL nicht mehr. Statt des Passwort Hashes wird nun eine Bind Variable angezeigt.

Die Passwörter von Datenbank-Links wurden früher in der PASSWORD-Spalte der Tabelle SYS.LINK$ im Klartext abgelegt und waren einfach lesbar. In Version 10gR1 wurde der Zugriff auf diese Tabelle aus der Rolle SELECT ANY DICTIONARY entfernt, mit 10gR2 wurde die Spalte PASSWORDX eingeführt, die nun nur noch den Hash speichert.  Mit der Sicherheit dieses Hashes steht es allerdings auch nicht zum Besten.

Während es in älteren Versionen möglich war, die komplette Link-Beschreibung inklusive der Passwort-Hashes in einer “BY VALUES”-Klausel auszulesen, sieht das Ergebnis in 11.2.0.4 so aus:

SQL> SELECT OWNER, DB_LINK, DBMS_METADATA.GET_DDL('DB_LINK',DB_LINK,OWNER) as DDL FROM DBA_DB_LINKS;
OWNER          DB_LINK      DDL
-------------- ------------ ----------------------------------------------------------
SYS            TEST_LINK    CREATE DATABASE LINK "TEST_LINK"
                            CONNECT TO "DBLINK_ACCOUNT" IDENTIFIED BY VALUES ':1'
                            USING 'TNSALIAS'

Der für den Link notwendige Hash steht allerdings immer noch in der PASSWORDX-Spalte der SYS.LINK$-Tabelle, und kann mit Hilfe von DBMS_CRYPTO recht einfach ausgelesen werden:

SQL> select 
 name, 
 userid, 
 utl_raw.cast_to_varchar2(dbms_crypto.decrypt((substr(passwordx,19)), 
  4353, (substr(passwordx,3,16)))) 
from sys.link$;

NAME       USERID         UTL_RAW.CAST_TO_VARCHAR2(DBMS_CRYPTO.DECRYPT
                          ((SUBSTR(PASSWORDX,19)),4353,(SUBSTR(PASSWORDX,3,16))))
---------- ---------      -------------------------------------------------------
TEST_LINK  DBLINK_ACCOUNT GEHEIMESPASSWORT

Oft wird eine solche Möglichkeit benötigt, um Skripte zu erstellen, die Objekte wie Links zusammensuchen, um sie zu paketieren und für Deployment bereitzustellen.

Dieser Bug in der Datenbank Version 11.2.0.4 ist bei Oracle klassifiziert unter: Bug 18461318. Der Status dieses Bus steht allerdings auf “44 – Not Feasible to fix, to Filer“, was nicht sehr vielversprechend klingt.


Update 23.11.2017: Es findet eine Verschlüsselung, keine Hash-Wert-Berechnung, des Link-Passwortes statt, und diese lässt sich brechen.