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

BI in der Cloud – lohnt sich das?

,

Es gibt eine Menge einzelne BI-Angebote in der Cloud, aber ein komplettes Data-Warehouse? Ist das heute bereits realisierbar, oder lohnt es sich noch nicht?

Sollen DWH-Architekturen verändert oder neu aufgebaut werden, stellt sich zunehmend auch die Frage, ob das DWH mitsamt BI-Backend nicht auch in „die Cloud“ verlagert werden kann. Neben den dafür allseitig angeführten Argumenten wie verringerte Bereitstellungszeiten, Elastizität und Kostenersparnis reizen viele Entscheider gerade die Möglichkeiten, die BI-Tools in der Cloud versprechen: Anwender würden immer die aktuelle Version des BI-Stack nutzen und eine hohe Verfügbarkeit ließe sich trotz überschaubarer eigener IT-Ressourcen garantieren. Ein agiles Self-Service-BI verspräche zudem, die Mauer zwischen IT und Business zu überwinden, weil Anwender neue Auswertungen schnell und selbst entwerfen und auch sogleich testen könnten.

Welche Möglichkeiten bieten sich im Einzelnen zur Realisierung an?

Transaktionales BI

Viele Unternehmen sammeln die ersten Erfahrungen auf dem Weg in die Oracle-Cloud mit den „BI Apps“. Eigentlich sind diese eine On-Premise-Lösung, um schnell Daten aus einer Anwendung aufzubereiten und so darzustellen, wie man es von Oracles BI-Lösungen gewohnt ist – inklusive Dashboards und interaktiven Analysen. Relativ früh wurden die BI-Apps in der Oracle-Cloud angeboten. Für die gerne ebenfalls in der Cloud betriebenen Oracle-Applikationen wie HCM (Human Capital Management) existieren fertige Lösungen, die die gewünschten Ergebnisse bereits fertig aufbereitet präsentieren. Selbst die fachliche Logik, also das Wissen darum, welche für die Analyse notwendigen Zahlen in welchen Tabellen der Anwendung verborgen sind, wird bereits mitgeliefert. Der Kunde spart sich die gesamte Wertschöpfungskette des klassischen Data Warehouse: Quellsystem-Analyse, Datenmodellierung, ETL und Erstellung von Dashboards und Reports.

Die BI-Apps sind Teil des sogenannten Oracle-Transactional-Business-Intelligence (OTBI). Transaktional, weil die BI-Elemente direkt aus den operativen Vorsystemen, den transaktionalen Anwendungen, gespeist werden. Wann immer schnelle Analysen aus den Oracle-Applications benötigt werden, ist OTBI eine interessante Lösung: Obwohl schnell und schlank, steht die Aufbereitung der erhaltenen Daten denen der klassischen Präsentation, wie man sie aus On-Premise-OBIEE-Systemen gewohnt ist, kaum in etwas nach – und ist mit minimalem Aufwand in der Oracle-Cloud verfügbar. OTBI ist für viele Oracle-Cloud-Apps einfach als Zusatzoption buchbar.

Was das transaktionale Reporting nicht leistet, ist die Integration verschiedener Quellen, also die klassische Aufgabe des Enterprise Data Warehouse (EDWH). Daten können nur dort aufbereitet und dargestellt werden, wo die notwendigen Transformationen zwischen Quelle und BI-Darstellung durch Oracle vorbereitet sind. Sollen eigene Integrationen durchgeführt oder Daten aus verschiedenen Quellen konsolidiert werden, muss weiter ausgeholt werden.

BI Cloud Services und Analytics Cloud

Neben OTBI unterhält Oracle ein weiteres Cloud-basiertes Angebot: Business-Intelligence-Cloud-Services. BICS ist die Cloud-Alternative zur Installation des Oracle-Business-Intelligence-Servers (OBIEE) im eigenen Hause.

Zur Anpassung an die Cloud-Umgebung hat Oracle vor allem die Funktionalität des Admin-Tools in eine neue Oberfläche integriert. Das traditionelle Admin-Tool läuft lokal auf einem Entwickler-PC. Mit ihm wird das OBIEE-Repository erstellt: den physischen Datenbankobjekten werden logische Entitäten gegenübergestellt, die beispielsweise Tabellen durch Joins über entsprechende gemeinsame Attribute verbinden, und schließlich wird das für den Benutzer sichtbare Universum aus geschäftlichen Relationen definiert. Diese Funktionalität wurde nun mit Hilfe des neuen Cloud-Admin-Tools weitgehend vom Windows-Client und seiner in die Jahre gekommenen Optik befreit und per Web-Browser nutzbar gemacht.

Einen großen Sprung nach vorne haben die Oracle-BI-Cloud-Angebote durch die Einführung der Analytics-Cloud (OAC) erfahren. Denn BICS wies einige Nachteile auf:

  • Es konnten ausschließlich die Inhalte einerDatenbank aufbereitet werden.
  • Es konnten keine Agenten verwendet werden.
  • Der BI-Publisher und Essbase wurden nicht unterstützt

BICS wurde daher eher als ein abteilungsfokussiertes Angebot eingeschätzt, das für den unternehmensweiten Einsatz nur bedingt tauglich schien. Dementsprechend verhielt sich auch das Preismodell: für USD 3.500[1],– pro Jahr erhielt der Kunde BICS mit einer dazugehörigen Cloud-Datenbank, die auf ein Storage-Volumen von 50 GB und einen Durchsatz von 300 GB begrenzt war.

OAC überwindet all diese Einschränkungen und bringt den zusätzlichen Vorteil mit, dass der zu Grunde liegende Datenbankdienst frei gewählt werden und auch eine bereits vorhandene Datenbanklizenz genutzt werden kann. Im Gegensatz zu BICS ist OAC ein für die Cloud neu entwickeltes Produkt[2]. Die Kosten belaufen sich in der „non-metered“, also pauschal abgerechneten Version auf USD 3.000,– pro Monat und OCPU[3]für die Standard und USD 6.000,– Listenpreis[4]pro Monat und OCPU für die Enterprise Edition. Die Enterprise Edition beinhaltet auch Essbase.

Angebot Kostenpunkt Umfang Zielgruppe
OTBI (-E) Je nach Anwendung Cloud Fusion
spezifisches  transaktionales Berichtswesen
Abteilung bzw.
Organisation (-E)
BICS USD 30k/Jahr/10 Nutzer

(USD 1000/Monat +
USD 150/Monat/Named User)

Abgespecktes OBIEE in der Cloud Abteilung
OAC USD 36(SE)-72k(EE)/Jahr/OCPU

+ DB + IaaS

BI in der Cloud Abteilung und Unternehmen (mit eigener DB und ETL)

Wie jedes BI-Tool muss auch OAC mit den darzubietenden Daten bestückt werden. In der physischen Schicht des OBIEE bzw. BICS könnten natürlich transaktionale Daten der Vorsysteme direkt angeboten werden. Nun ist es aber so, dass die Data-Warehouse-Community ihre Referenzarchitektur nicht ohne Grund entworfen hat: Performance, Konformität und Konsistenz sind nur einige Schlagwörter, die eine Architektur bezeichnen, die sich auf Dauer zwar nicht ganz ohne Aufwand an Modellierung, Ladelogik und Speicherplatz realisieren lässt. Die aber eben doch in den allermeisten Fällen langfristig Zeit und Aufwand spart und zudem die entscheidenden Ergebnisse realistisch liefern kann.

DWH – Platform-as-a-Service

Ein klassisches, vollständiges Data-Warehouse kann Daten aus verschiedenen Quellen annehmen, aufbereiten und in ein gemeinsames Datenmodell integrieren. Die Daten werden – oft weiter zurückreichend als die Quellsysteme – historisiert, und durch Konsolidierung werden Redundanzen vermieden. Für die weitere Verarbeitung werden üblicherweise verschiedene Schichten angelegt: Die Stage, der Core und ein oder mehrere Data-Marts. Die Daten werden auseinandergenommen, transformiert und in ein dimensionales Modell geladen. Um das zu erreichen, werden eine Datenbank zur Ablage der jeweiligen Datenschichten und ein Extract-Transform-Load (ETL)-Tool benötigt.

Selbstverständlich bietet Oracle auch die Datenbank in der Cloud an. Dieses Angebot existiert in verschiedenen Ausprägungen[5]:

  • Database-Schema-Service: Ein Schema in einer Cloud-Datenbank mit 50 GB Volumen.
  • Exadata-Express: Eine Pluggable-Database (PDB) in einer 12.2 Cloud-Datenbank, ebenfalls mit einem Datenvolumen bis 50 GB.
  • Database-Cloud-Service (DBCS): Eine Datenbank auf einer Linux-VM in der Oracle-Public-Cloud, installierbar per Web-Tool in verschieden großen Ausprägungen.
  • Exadata-Cloud-Service: DBCS auf Exadata.
  • (Exadata)-Cloud-Service on Bare-Metal-Servers: DBCS auf einer dedizierter Hardware, die exklusiv für den Kunden reserviert ist (Private Cloud).

Für eine DWH-Datenbank empfiehlt sich, so lange – etwa aus Sicherheitsgründen[6]–  keine dedizierte Hardware benötigt wird, aber DWH-typische Anforderungen an Durchsatz und Zuverlässigkeit bestehen, der Exadata-Cloud-Service.

Allerdings ist von den verfügbaren Methoden, Daten in DBCS zu laden (SQL-Developer-Anbindung, APEX-Maske, REST- und SOAP-Interface sowie ein spezieller Adapter namens DataSync) nur letztere in der Lage, überhaupt Daten in den in DWH-Umgebungen üblichen Größenordnungen entgegenzunehmen. Es handelt sich dabei um ein Java-Tool, das die Daten aus der Quelle lädt und in die DBCS-Datenbank schiebt.

Der eigentlich angestrebte Weg, Daten der Quell-Systeme in ein DWH zu laden, ist aber in der Regel die Nutzung eines ETL-Tools, im Oracle Umfeld gerne des Oracle-Data-Integrators (ODI). Der ODI verfügt über eine Vielzahl von Lade-Adaptern, aber die besten Ergebnisse werden der Erfahrung nach mit der Nutzung von direkten Datenbank-Links erzielt, zumindest, wenn das Quellsystem auch eine Oracle-Datenbank verwendet.

Infrastructure-as-a-Service

Viele Anbieter von Cloud-Lösungen haben versucht, den Markt mit einer naheliegenden Strategie aufzurollen: Zunächst werden die Angebote mit überschaubarer Komplexität in die Cloud verlagert: Produkte, die mit möglichst wenig Anpassungen bei einer möglichst großen Kundenzahl erfolgreich einsatzbar sein könnten.

Auch Oracle hatte im ersten Schritt universell einsetzbare Produkte als Software-as-a-Service (SaaS) oder Platform-as-a-service (PaaS) anzubieten: HCM, BI-Apps, OTBI-Bausteine und BICS. Aber spätestens, wenn ein mehrschichtiges DWH mit selbstmodellierten Schichten, verschiedenen, auch noch nicht in der Cloud vorliegenden Quellen und angepassten ETL-Strecken, die diese konsolidieren aufgebaut werden soll, reichen die vorgefertigten Cloud-Angebote nicht mehr aus, und es bleibt nur der Ansatz Infrastructure-as-a-Service (IaaS) übrig. Hier wird zwar die Infrastruktur in der Cloud betrieben, aber deren Grenzschicht ist das Betriebssystem. Der Kunde erhält eigene virtuelle Maschinen, auf denen er dann die DWH-Komponenten selbst installieren und betreiben muss.

So gibt es zwar ein Produkt mit dem Namen „Oracle Data Integrator Cloud Service“, aber die Installationsanleitung umfasst sämtliche Schritte, die nötig sind, um das Repository, das Studio und die Agenten manuell auf der Kommandozeile in einer VM zu installieren.

In diesem Markt ist das Angebot von Oracle vergleichbar, wenn nicht austauschbar, mit dem anderer Anbieter wie AWS[7]. Es können zwar einige der ursprünglichen Ziele der Cloud-Migration realisiert werden, der Kunde muss keine eigene Hardware vorhalten und pflegen, aber der Aufwand für die Installation und Wartung der Software bleibt ihm nicht erspart.

Das Endresultat ist ein Gemischtwarenladen

Der Autor hat im vergangenen Jahr ein Cloud-DWH-Einführungsprojekt begleitet, das sämtliche hier diskutierten Aspekte umfasste und auch von Oracle konzipiert wurde.

Der Prototyp der neuen BI-Landschaft bestand aus Applikationen, die größtenteils bereits in der Cloud verwendet wurden: HCM, UCM, Field Service, Finance. ETL wurde mit dem ODI ausgeführt, der als IaaS-Komponente in der Oracle-Compute-Cloud installiert war. Die ODI Studio Clients liefen lokal oder auf einem Terminal-Server in der Compute-Cloud. Modelliert wurde mit einem lokal auf den Entwickler-PCs installierten SQL-Developer-Data-Modeler. Die Versionskontrolle erfolgte über Subversion, dessen Server wiederum in der Compute-Cloud beheimatet war. Die Datenbanken waren in einer Exadata-Cloud-Service-Quarter-Rack-Umgebung untergebracht. Als BI-Komponente diente BI-Analytics-Cloud-Service. Daten aus bestehenden On-Premise-Systemen wurden über einen ODI-Agenten geladen und teilweise in der Storage-Cloud abgelegt.

Eines der angetroffenen Probleme war, das selbst die Oracle-Cloud-Apps nicht immer über automatisiert benutzbare Schnittstellen verfügten, sondern darauf ausgelegt waren, Exporte als Dateien, die per Hand aus einer GUI erzeugt werden sollen, auszuführen. Werden solche Applikationen On-Premise betrieben, existiert meist die Möglichkeit, ETL direkt aus dem Datenmodell der Anwendung zu betreiben – bei den Cloud-Apps ist die Datensenke der Anwendung aber ein geschlossenes System.

Fazit

Die aktuell[8]bereitstehenden Oracle-Cloud-BI-Angebote sind in erster Linie dort erfolgreich einsetzbar, wo es um schnelle, abgrenzbare Lösungen geht. Ein Enterprise-Datawarehouse ist aber in den meisten Fällen kein einfach abgrenzbares Projekt. Der Gedanke, die komplette Business-Intelligence in die Cloud zu verlagern, ist für Entscheider sehr attraktiv, aber nicht immer zufriedenstellend umsetzbar. Hier muss selbst konzipiert, entwickelt und installiert werden. Bestehende Hardware in die Cloud zu verlagern, das funktioniert bei Oracle wie bei Amazon selbstverständlich. Ob die Komplexität der Schnittstellen der unterschiedlichen Cloud-Produkte untereinander am Ende des Tages einfacher zu handhaben ist als technische Schnittstellen von On-Premise betriebenen Systemen, bleibt hingegen abzuwarten. Die Gesamtsumme an Komplexität sowohl technischer als auch vertraglicher Art erhöht sich durch den Cloud-Einsatz sicher nicht.

Und es gibt noch einen anderen Aspekt: Ein strategischer Vorteil eines EDWH ist, einen konsolidierten und vollständigen Datenpool jederzeit im Zugriff zu haben. Erfolgreiche Unternehmen möchten sich natürlich auf ihr Kerngeschäft konzentrieren und keine Unsummen für Anschaffung und Betrieb im Zweifel schnell veralteter IT ausgeben. Aber die Verteilung der eigenen Daten auf eine Vielzahl von gemieteten Cloud-Anwendungen birgt die Gefahr, eben diesen Vorteil aufzugeben. Es droht eine Zersiedelung des Datenbestandes, in der die Übersicht und vor allem auch die Hoheit über die eigenen Daten verloren gehen kann. Und die Entscheidung, die eigene IT nur bei einem Cloud-Provider anzusiedeln, erhöht wiederum die Abhängigkeit von eben diesem Anbieter[9].

Alternativ gibt es ja auch noch die Möglichkeit, sich eine private Cloud auf Basis der Engineered-Systems oder Cloud-Machine aufzubauen.


 [1] Bei den Preisen werden im Folgenden stets die Listenpreise angeführt

[2] BICS ist aus der Code-Basis des OBIEE entstanden, einem um die Jahrtausendwende entstandenen und mehrmals weiterverkauften Produkt, dessen Code-Qualität Gerüchten zufolge nicht geeignet war, daraus ein echtes Cloud-Produkt zu erzeugen. Siehe auch: http://redpillanalytics.com/introducing-oracle-analytics-cloud/

[3] Oracle Cloud Version der Prozessormetrik bei der Lizenzberechnung (Oracle Core Factor)

[4] https://cloud.oracle.com/enUS/oac/pricing, Stand Mitte 2017

[5] Sehr schön ist auch der „Oracle Public Cloud Data Transfer Service“ zum Migrieren großer Datenmengen in die Cloud: Oracle schickt dem Kunden eine ZS4 Storage Appliance, auf die die Daten zwischengelagert und dann an Oracle zurückgeschickt werden.

[6] Etwa wegen der aktuellen Angriffsmöglichkeiten auf die Isolation virtueller Systeme (Spectre und Meltdown)

[7] Nichtsdestotrotz läuft die Datenbank in der Oracle Cloud einer Enkitec-Studie zufolge deutlich effektiver als bei vergleichbaren IaaS-Providern wie AWS. Siehe auch: https://www.accenture.com/t20161013T060358Z__w__/us-en/_acnmedia/PDF-34/Accenture-Oracle-Cloud-Performance-Test-October2016.pdf

[8] Das angesprochene Projekt fand im Frühjahr 2017 statt.

[9] IT-Infrastruktur in die Cloud zu verlagern, bedeutet, sie von Fremdanbietern betreiben zu lassen, und bedingt ein engeres Verhältnis als etwa ein Lizenzabkommen für Software. Ändert der Anbieter beispielsweise kurzfristig seine Geschäftsbedingungen in einer inakzeptablen Weise, kann es sehr schwer fallen, die Cloud wieder zu verlassen. Für Aufsehen hat in der Oracle-Community im Januar 2017 beispielsweise die Entscheidung gesorgt, überraschend die Core-Factor-Table zu Ungunsten von Nicht-Oracle-IaaS-Providern zu ändern. Siehe: https://oracle-base.com/articles/misc/oracle-databases-in-the-cloud

BI Cloud Vortrag auf der DOAG Konferenz

,

Ich werde auf der diesjährigen DOAG Konferenz in Nürnberg einen Vortrag zum Thema „BI in der Cloud – lohnt sich das?“ halten.

Aus der Agenda:

Welche Cloud-Angebote für DWH und BI gibt es in der Oracle Welt und wie kann man sie nutzen? OTBI, BICS, Database (Exadata) Cloud Service, PaaS und IaaS – wie hängen diese Angebote zusammen, wie kann man sie nutzen, welche benötigt man wirklich und für welche Anwendungsfälle lohnt es sich, die BI Cloud Angebote einer konventionellen On-Premises-Lösung vorzuziehen?

Eine deutsch-norwegische Reederei hat sich für ein SAP-BI-Ablöseprojekt diese Fragen gestellt und und diesem Vortrag werden die gefundenen (und teilweise überraschenden) Antworten vorgestellt.

Der Stream-Leiter „Data Analytics“ empfiehlt, sich den Vortrag nicht entgehen zu lassen:

Das Thema Cloud ist allgegenwärtig – lohnt es sich denn, einen Blick auf die Oracle-Cloud-Angebote für DWH und BI zu werfen? Für welche Anwendungsfälle sind die Cloud-Angebote einer konventionellen On-Premises-Lösung vorzuziehen? Jan Schreiber gibt Einblick in ein SAP-BI-Ablöseprojekt einer deutsch-norwegischen Reederei und verspricht teils überraschende Antworten.

Ich gebe die Empfehlung natürlich gerne wieder.

Performance Probleme mit der Oracle ZFS Appliance

, , , , ,

Für das Data Warehouse eines unserer Projektkunden, eines großen Telekommunikationsversorgers, hat dieser eine Oracle ZFS Appliance angeschafft und per Infiniband direkt mit seinen Exadata-Produktionssystemen verbunden, um ein schnelles Datensicherungs-Medium zu gewinnen, mit dem auch unkompliziert neue Test- und Entwicklungs-Umgebungen erzeugt werden können.

Die ZFS Storage Appliance (ZA) kann, wie jedes moderne Storage-System, Snapshots erzeugen, ohne nennenswert Zeit mit dem Kopieren der Daten zu verbringen. Diese können als Klone auch zum Schreiben geöffnet werden und so als Grundlage für neue Datenbanken dienen. Waren die Entwicklungsdatenbanken bisher stark veraltet, da das Erstellen aus der Produktion viel Zeit und Speicherplatz brauchte, können diese nun spontan geklont und auch einmal auf Zuruf in den Ausgangsstand zurückgesetzt werden. Die dafür notwendigen Schritte auf der ZA werden durch ein Oracle Tool namens Snapshot Management Utility (SMU) erleichtert, der den kompletten Prozess des Klonens inklusive dem notwendigen Recovery der Datenbanken dirigiert. Die Datenbanken werden dann mittels RMAN BACKUP AS COPY als inkrementelles Backup auf den NFS-Share der ZA  gesichert, wo sie als Datafiles vorliegen und nach einem Recovery geöffnet werden können.

Zunächst wurden auf der ZFS Appliance die entsprechenden Projekte und Shares angelegt. Wir haben einen ZA Cluster verwendet, der aus zwei Köpfen besteht, die jeweils alle Platten sehen, aber nur die ihnen zugewiesenen verwenden. In jedem Kopf sind Solid State Disks (SSDs) als Schreib-Cache (ZIL) verbaut. Fällt ein Kopf aus, kann der jeweils andere seine Platten übernehmen. Dieser Vorgang dauert übrigens tatsächlich einige Zeit, hinzu kommt, dass die Caches, wie nach jedem Neustart eines Kopfes, neu gefüllt werden müssen.

Aus Performance-Gründen haben wir nur einen ZFS Pool pro Kopf eingerichtet und ihn als Mirror (und nicht als RAIDZ) konfiguriert. Laut den Vorgaben aus dem entsprechenden Oracle Whitepaper für den Datenbank-Betrieb auf der ZA wurden dann die Shares für Datafiles, Redo und Archivelog entsprechend mit den passenden Einstellungen für Logbias, Recordsize, Kompression und Primarycache konfiguriert:

Share

Logbias

Recordsize

Primarycache

Compression

DATAFILES

latency (oder throughput)

db_blocksize

all

LZJB

INDIZES

latency

db_blocksize

all

off

CONTROLFILES

latency

128k

all

LZJB

Von der in ZFS prinzipiell unterstützen Deduplikation ist übrigens für diesen Einsatzzweck stark abzuraten, da die erforderlichen Ordnungstabellen sehr viel Platz im RAM benötigen und dort mit dem Cache kollidieren.

Die SSDs für das ZIL wurden gestriped eingerichtet. Ein Fehler auf einer SSD kann nun zusammen mit einem Stromausfall und dem daraus folgenden Verlust des Hauptspeicher-Inhaltes zu Datenverlust führen, aber wählt man hier die Konfiguration als Mirror, wird im Latency-Modus die maximale Schreibrate durch den Cache durch die Bandbreite einer SSD begrenzt – zu langsam für uns.

Auf der Exadata als Quellsystem und einer X4-2 Maschine, die als Datenbankserver für die Klon-Datenbankenvorgesehen ist, werden nun die Linux-Interfaces für Infiniband eingerichtet:

Enable LACP Link Aggregation
ifcfg-ibx MTU: 65520
Connected Mode

Dann werden die ZA-Shares per dNFS eingehängt. dNFS wickelt die wesentlichen Übertragungsprozesse direkt in den Oracle-Prozessen ab und führt für den Database Writer sowie für RMAN zu erheblichen Geschwindigkeitsvorteilen. Wir haben die folgenden Linux NFS- und Mount-Options verwendet:

rw, bg, hard, nointr, rsize=1048576, wsize=1048576, tcp, vers=3,timeo=600

Die Einstellungen in /etc/sysctl.conf waren:

net.ipv4.tcp_timestamps=0
net.ipv4.tcp_sack=0
net.core.netdev_max_backlog=250000
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.core.rmem_default=16777216
net.core.wmem_default=16777216
net.core.optmem_max=16777216
net.ipv4.tcp_mem="16777216 16777216 16777216"
net.ipv4.tcp_rmem="4096 87380 16777216"
net.ipv4.tcp_wmem="4096 65536 16777216"

dNFS in Kombination mit Remote Direct Memory Access (RDMA) erbrachte die besten Ergebnisse. Allerdings ist RDMA nicht in allen Konfigurationen von Oracle mit dNFS unterstützt.

Insgesamt blieben die Lese- und vor allem Schreibraten, die wir von den Linux-Servern gegen die ZA bekamen, weit hinter den Erwartungen zurück.

Mit dd, CTAS aus der Datenbank oder anderen Testwerkzeuge haben wir folgende Durchsätze gemessen:

Konfiguration / Test

Durchsatz lesend

Durchsatz schreibend

Initiale Konfig, RMAN/OS

 

260 MB/s

CTAS, INSERT APPEND 

 

100 MB/s

Kernel-NFS

400 MB/s

 

dNFS

1,9 GB/s

 

Adaptive Direct IO, NOLOG, throughput bias, rs=128k, IPoIB

1,6 GB/s

 

NFS over RDMA

3,5 GB/s

400 MB/s pro Pool

Bündel-Test, Latency Mode

5,5 GB/s mit beiden Köpfen

1 GB/s

ORION Test

 

600 MB/s (ein Kopf)

_adaptive_direct_read=TRUE

 

55 MB/s (DOP=10)

Mit Patch für Bug 19339320

 

115 MB/s

_direct_io_wslots=32, parallel_execution_message_size=65536

 

315 MB/s

Schreiben mit vielen parallelen Sessions

 

1,2 GB/s

Mit allen SSDs

 

1,7 GB/s

NFS/IPoIB Durchsatz X4-2 / ZA

1,25GB/s pro Interface

 

Ziel mit 2x 4G Wirespeed

7 GB/s

4 GB/s (sustained IO)

Oracle-Angabe

(27TB/h), 17,3GB/s on ZA

 

Viele der genannten Tests beruhen auf Vorschlägen durch den Oracle Support. Wegen dieser Performance sind seit einigen Monaten zwei Oracle-SRs und ist mittlerweile ein Bug offen. In den Griff bekommen haben wir die Probleme bisher trotz Überprüfung von allen denkbaren Komponenten bis hinunter zur Verkabelung und Einsatzes mehrere Oracle-Engineers vor Ort nicht. Eventuell ist hier ein Bug in den Mellanox-Treibern oder im Linux Kernel verantwortlich?

Oracle stellt fünfte Exadata-Generation vor

,

Oracle hat die fünfte Generation der Exadata Database Machine, die Exadata X-4 vorgestellt. Das Engineered System löst das aktuelle Modell X-3 ab und verspricht weitere Verbesserungen von Performance und Storage-Kapazitäten. Die Datenbank-Maschine soll je nach Konfiguration 50 bis 100 Prozent leistungsfähiger sein als das bisherige Modell.

Hinter der Gittertür sorgen zwei zwölf-Kern-Xeon-Chips E5-2697 und 256 GB RAM pro Datenbank-Server für die nötige Computing-Leistung. Das RAM kann auf 512 GB erweitert werden. Auch die Storage-Server arbeiten mit jeweils zwei Intel-Xeon-Prozessoren, die datenintensive Workloads beschleunigen.

Jeder Storage-Server beinhaltet vier Exadata Smart Flash Karten, auf denen der Datencache aufgebaut wird. Sie erreichen eine Rohkapazität von 3,2 TB. Laut Oracle liegt die effektive Flash-Kapazität der Exadata Smart Flash Karten zehn Mal höher als beim physischen Flash-Cache. Ein vollständig ausgebautes Rack hätte laut Oracle somit eine effektive Flash-Kapazität von 440 TB.

Die Exadata Smart Flash Cache Compression ermöglicht darüberhinaus eine dynamische Steigerung der Kapazität durch transparente Kompression der Daten im Flash-Cache.

Die Schreib- und Lesegeschwindigkeiten haben sich laut Oracle um 77 bis 100 Prozent verbessert und erreichen nun maximal 2,66 Millionen Input/Output operations Per Second pro Rack und 1,96 Millionen Schreib-IOPs auf Flash-Speicher.

Mit Infiniband und dem „Zero-Loss Zero-Copy Datagram Protocol“ (ZDP) wird nun die doppelte Datenmenge verarbeitet. Zusätzlich sorgt das Network Resource Management für niedrige Antwortzeiten bei Latenz-kritischen Operationen, auch wenn parallel dazu andere Aufgaben wie Berichte, Batch-Jobs oder Backups durchgeführt werden.

In der vollständig ausgebauten Konfiguration hat das System einen Listenpreis von 1,1 Millionen US-Dollar. Die Exadata X-4 wird entweder mit Oracle Linux 5 Update 9 oder Solaris 11 Update 1 ausgeliefert. Abgesehen vom Betriebssystem sind etwaige Software-Lizenzen, auch für die Exadata Storage Server Software, nicht im Preis enthalten.

Die neue Version der Oracle Exadata Software unterstützt alle früheren Exadata Hardware-Generationen sowie Oracle Database 12c (inklusive Multitenant Option) und Oracle Database 11g Release 2.

Unruhe wegen OWB-Abkündigung

,

Die Ankündigung, das der Oracle Warehouse Builder, das mit der Datenbank mitgelieferte ETL-Tool, ab der Datenbank Version 12.2 nicht mehr unterstützt wird, sorgt für Unruhe bei den deutschen Anwendern. Laut einer Umfrage des Anwenderverbandes DOAG setzen mehr als 95% der Befragten, „die in Deutschland ihr Data Warehouse auf Basis der Oracle-Infrastruktur betreiben und ETL-Tools nutzen“, den OWB ein. Die Migration auf das Nachfolgeprodukt Oracle Data Integrator (ODI), so schätzten über 80% der Befragten, wird sehr teuer sein und einen hohen Aufwand bedeuten. Details sind einer DOAG-Presseerklärung zu finden.

Entsprechend werden ETL-Projekte zur Zeit gestoppt. Viele Oracle-Anwender haben in den letzten Jahren in Schulungen und interne Organisation zum OWB investiert, während das ODI-Know-How bisher kaum in der Breite verankert ist. Dies könnte ein erhebliches Hemmnis bei der Verbreitung von 12c in der DWH- und BI-Welt darstellen.

Ob die Bemühungen der DOAG, Oracle’s Produktstrategie zu Gunsten der deutschen Kunden erfolgreich sein werden, bleibt mit Spannung abzuwarten. Nach Streitigkeiten über Oracle’s Lizenzmodell und Support-Infrastruktur in den letzten Jahren ist es nicht der erste mal, dass es zu Unzufriedenheit bei mehr auf langfristige Strategien bedachten deutschen Kunden kommt.