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

/von

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.

/von

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?

/3 Kommentare/von

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.

/von

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.

/von