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

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

Slides vom DOAG Security Day

,

Hier sind die Folien des Vortrags „Enterprise Security mit LDAP und PKI“ auf dem DOAG Security Day am 22.09.2015 in Leipzig. DOAG_SD22092015_EnterpriseSecuritymitLDAPundPKI

Slides vom DOAG Vortrag zum ZFS-Datenbank-Cloning

, , , ,

cw22-zfs-storage-appliance-2241737Die Folien von meinem Vortrag zum Thema ZFS Appliance Performance auf der DOAG 2014 sind hier: DOAG_2014_loopback.org_Exa

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?

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.

Slides vom Unicode-DOAG-Vortrag

, ,

dmu-logoDie Vortragsfolien vom DOAG-Vortrag zur Datenbank Unicode Migration sind online: DOAG_2013_Unicode_V_1.0

Virtual Desktop Infrastructure in der Praxis

,

Erfahrungen mit einer VDI-Umgebung im Testbetrieb

Motivation und Ausgangssituation

Die Gelegenheit, ein Büro als Projekt „auf der grünen Wiese“ komplett neu mit Arbeitsplätzen auszustatten, ergibt sich nicht mehr allzu häufig. Finden wir sonst in der Regel gewachsene Strukturen vor, lässt für ein solches Projekt die Frage stellen, welche Arbeitsmittel denn genutzt werden sollen.

  • „Traditionelle“ PCs (Windows), Workstations (Linux) oder Apple Macintosh Computer in Form von „Blechkisten unter dem Schreibtisch“. Diese Geräte sind sperrig, aber bieten hohe Performance am Arbeitsplatz. Soll auch remote oder im Home Office gearbeitet werden, muss ein zusätzliches Notebook gestellt werden. Hier stellt sich als nächstes die Frage, wie gut die Synchronisation der Daten zwischen mehreren Geräten funktioniert. Selbst bei Verwendung von Active Directory-Profilen oder mobilen Homeverzeichnissen am MacOSX Server klappt es inder Praxis oft nicht, auf zwei verschiedenen Geräten gleichzeitig mit den gleichen Anwendungen auf den gleichen Daten arbeiten zu können. Und die Zahl der Menschen, die ausschließlich an ihrem Büro-Arbeitsplatz arbeiten, nimmt sicher stetig ab.
  • Notebooks mit Dockingstation, die angedockt als vollwertige Workstation funktionieren. Hier entfällt das Synchronisationsproblem, man arbeitet nur noch an einem Gerät. Probleme entstehen hier bei Anwendungen mit hohem Resourcenbedarf, die das Notebook überfordern, weil dieses zu langsam ist, nicht über genug Arbeitspeicher verfügt und -vor allem bei modernen Notebooks mit SSD- nicht genug Platz für das Arbeiten mit Sammlungen grosser Dateien hat. Ebenfalls problematisch ist, dass Unternehmensdaten auf mobilen Geräten gespeichert sind. Im Falle von Spionage oder dem Diebstahl des Notebooks besteht die Gefahr, dass wichtige Daten in die falschen Hände geraten. Notebooks sind außerdem über verschiedene Hardware-Schnittstellen wie USB und Firewire besonders effizient angreifbar. Im Zweifelsfall kann selbst eine Datenverschlüsselung (Full Disk Encryption) überwunden werden. Ausserdem müssen auch hier mobile Homeverzeichnisse, Profile oder automatische Datensicherungen mit entsprechendem Synchronisationsaufwand benutzt werden, um sicherzustellen, dass ein verlorengegangenes oder defektes Notebook schnell und ohne Datenverlust wieder hergestellt werden kann.
  • BYOD: Der Anwender bringt sein eigenes Notebook mit („Bring Your Own Device“). Hier stellen sich diverse Fragen nach Datensicherheit auf privaten Geräten, der Verstrickung von IT-Support in selbstgepflegte und nicht standartisierte Betriebssystem-Installationen und der Trennung von Firmen- und privaten Daten. In Deutschland sind gesetzliche Regelungen zu beachten, die das Verhältnis zwischen Arbeitnehmer und Unternehmen bezüglich des Datenschutzes regeln. Ein vielversprechender Ansatz ist, den Firmen-Desktop als virtuelles Image auf dem vom Benutzer verwalteten Gerät laufen zu lassen. So sind der Firmen-Arbeitsplatz und der private Desktop voneinander getrennt. Dieses Image muss aber auch synchronisiert werden. Die Alternative ist, überhaupt keine Daten auf dem Gerät mehr vorzuhalten, indem man einen Terminalserver oder Anwendungsvirtualisierung verwendet. Hier laufen alle Programme auf dem Server im Unternehmen, und der Client dient quasi nur noch als Display und Eingabegerät, auf dem sich keine Daten mehr befinden. Dieses Konzept funktioniert natürlich nur, so lange eine ausreichend performante Netzwerkanbindung besteht. Für das Arbeiten im Zug oder Flugzeug ist ein Terminalserver nicht geeignet.
  • Mobile Geräte. Werden ausschliesslich Web-Applikationen (oder gar native Apps für mobile Geräte) benutzt, lassen sich ganz neue Wege gehen. Hier muss nur noch ein absolut minimal installiertes Gerät bereitgestellt werden, das im Wesentlichen nur einen Web-Browser mitbringt. Es kann ein Tablet verwendet werden, oder ein Chromebook. Bis auf bestimmte Sicherheitseinstellung wie der VPN-Zugang muss nach dem Kauf des Gerätes fast nichts mehr angepasst werden. Aber die wenigsten Unternehmen werden in der Praxis auf Desktop-Computer und entsprechende native Anwendungen verzichten können.

Im vorliegenden Fall spielten Sicherheitsüberlegungen eine entscheidende Rolle. Unternehmensdaten sollten sich nicht auf Notebooks befinden, denn auch gute Festplattenverschlüsselung wie TrueCrypt oder FileVault wurde als nicht ausreichend sicher gegen physikalische Angriffe (das laufende Gerät wird im Hotelzimmer oder bei einer Zollkontrolle mit Malware infiziert bzw der Arbeitsspeicher durch physikalischen Zugriff ausgelesen) empfunden.

Aus diesem Grund wurde eine Evaluationsumgebung für eine Virtual Desktop Infrastruktur (VDI) aufgebaut.

Überblick der VDI-Charakteristiken

VDI wird von mehreren Herstellern (VMWare, Microsoft und Oracle) angeboten. Die Idee dahinter ist, Desktop-PC’s zu virtualisieren und auf einem entsprechenden Server laufen zu lassen. Das Display der Anwender wird nun nur noch als Anzeigegerät verwendet, das Betriebssystem und sämtliche Applikationen laufen auf dem Virtualisierungsserver, und sämtliche Daten und Speicherinhalte bleiben auf dem Storage-Server.

Hieraus ergeben sich eine Reihe von Vorteilen:

  • Die Clients bzw. Terminals, die die PCs und Workstations ersetzen, sind kostengünstig, energieeffizient und langlebig. Sie enthalten nur wenige und unkomplizierte Komponenten und keine beweglichen Teile.
  • Notebooks oder iPads als mobile Zugriffs-Clients müssen nur minimal konfiguriert werden (der VPN-Zugang muss eingerichtet und die Virtual-Desktop-Software installiert werden) und enthalten dann keine Unternehmensdaten, sondern dienen immer nor als Sichtgeräte. Auch bei Verlust und Diebstahl ist damit nicht viel anzufangen, sie sind einfach zu ersetzen (weil einfach neu zu installieren), und da sie keine Daten enthalten, können diese nicht nur nicht gestohlen, sondern deren Herausgabe auch nicht erpresst werden, indem etwa die Herausgabe eines Verschlüsselungspasswort abgepresst wird.
  • Durch eine Web-Schnittstelle (bei Oracle Global Desktop genannt) kann in der Regel auch ganz ohne eigenes Endgerät über einen Web-Browser auf den Unternehmens-Desktop zugrgriffen werden. Dieser läuft dann im Browser-Fenster wie ein Film ab.
  • Da die Desktops im Data Center laufen, laufen sie auf Server-Hardware, die Ausfälle durch Versagen billiger PC- oder Notebook-Komponenten lassen sich vermeiden. Redundant ausgelegt, kann eine hohe Zuverlässigkeit des Gesamtsystems erreicht werden.
  • Aus dem gleichen Grund kann eine systematische Datensicherung erfolgen, ohne das ein Notebook synchronisiert werden muss.
  • Desktops lassen sich versionieren und klonen. Eine Windows- oder Linux-Desktop-Installation inklusive der benötigten Applikation kann einmal als Master erstellt und dann in kurzer Zeit geklont und für die einzelnen Anwender bereitgestellt werden. So kann es einfacher sein, eine einheitliche Installationsbasis zu erreichen. Ebenso können Updates zentral und systematisch ausgerollt und Bedrohungen zentral erfasst werden, da sich alle Desktops für die IT-Administration immer im Zugriff befinden.
  • Der Desktop eines Anwenders kann nacheinander auf verschiedenen Geräten (Workstation/Terminal, Notebook, iPad, Web) verwendet werden, ohne das er neu gestartet werden muss. Eine Anwendung kann also weiterlaufen, während sie heute auf dem einen und morgen von unterwegs auf einem anderen Gerät verwendet wird. Ein Anwender kann also seinen tagsüber verwendeten Desktop mit allen Apps abends im Zug oder zu Hause weiterverwenden, und alle Apps sind sind währenddessen weitergelaufen, und ihre Netzwerk-Verbindungen blieben erhalten.
  • Ein Anwender kann auf einem Gerät mehrere Desktops unterschiedlicher Betriebssysteme oder Terminalserver gleichzeitig bzw. nacheinander nutzen.
  • Sicherheitsentscheidungen sind sofort umsetzbar: Ein gesperrter Account ist sofort nicht mehr benutzbar, und alle damit erreichbaren Daten sind sofort nicht mehr zu erreichen.
  • Ein kompromittierter, mit Malware oder Viren verseuchter oder einfach defekter Desktop kann vergleichsweise einfach und schnell neu bereitgestellt werden, indem ein neuer Klon des Master-desktop gezogen wird.

…und Nachteilen:

  • Das Setup der Server ist nicht zu unterschätzen: Virtualisierungs-, Storage und Management-Server müssen eingerichtet, überwacht und betrieben werden.
  • Ein entsprechendes Skillset der IT-Administration muss aufgebaut werden.
  • Ohne Netzwerkanbindung ist kein Arbeiten an den Desktops mehr möglich.
  • Die verwendete Server-Hardware ist durchgehend teuerer als billige Notebook- oder Workstation-Hardware. Da auch triviale Operationen wir beispielsweise das immer wieder ausgeführte Laden von Windows und Office für jeden Desktop auf dem Server abgearbeitet werden muss, relativiert sich die Kostenersparnis schnell.
  • Das zentrale System lässt sich zwar redundant auslegen und absichern, aber wenn es doch einmal ausfällt, kann kein Anwender mehr arbeiten.
  • Es kann schwierig sein, Anwendungen voneinander zu isolieren, und zu verhindern, dass eine CPU- und speicherhungrige Applikation die Ressourcen anderer Anwender „auffrisst“.
  • Die Güte der Grafik und das Antwortzeitverhalten eines optimal konfigurierten PC’s mit hochwertiger Grafik kann in der Regel nicht erreicht werden.
  • Auf Grund technischer und lizenzrechtlicher Einschränkungen lassen sich Macintosh-Desktop’s in keiner der VDI-Umgebungen virtualisiert einsetzen.

Nach einer grundsätzlichen Marktübersicht wurde entschieden, die Evaluationsumgebung als Proof-of-Concept mit der Sun / Oracle Lösung bereitzustellen.

Aufbau der Virtual Desktop Infrastruktur

Als Grundlage dienten zwei VDI-Server: Ein Server für das VDI-Management, der den VDI-Dienst selbst sowie die Software für das Mangement der SunRay-Clients (Sun Ray Server Software, SRSS) und den Secure Global Desktop (SGD, früher als Tarantella benannt) beherbergt. Als Datenbank für die Statusinformationen aller Komponenten sollte eine bereits vorhandene zentrale MySQL-Datenbank verwendet werden, dies gestaltete sich bei der Installation allerdings als so schwierig, dass schließlich eine separate MySQL-Instanz auf dem VDI-Management-Server erzeugt wurde – diese Möglichkeit sehen die Installationsskripte selbst vor. Dieser Server wurde mit Solaris 11 eingerichtet und direkt danach wurde Oracle VDI 3.5 installiert.

EIn weiterer Server wurde als Virtualisierungsserver konfiguriert. Hier wurde aus Kompatibilitätsgründen Solaris 10 verwendet, und danach im Wesentlichen VirtualBox installiert. VDI steuert Virtualbox über SSH-Kommandos und die Ausgabe über RDP, daher ist für das Management kein spezieller Adapter notwendig. Virtualbox muss in einer speziellen Version, die zu VDI kompatibel ist, und der Entwicklung von VirtualBox etwas hinterher hängt, verwendet werden.

Als Storage-Provider wurde ein ZFS-iSCSI-Filer verwendet. Da keine Sun Storage Appliance zur Verfügung stand, wurde ein weiterer Server mit Solaris 10 und ZFS eingerichtet. Leider ist Solaris 11 mit seinen vielen Verbesserungen im ZFS (zum Beispiel -endlich- Encryption) nicht als VDI Storage Provider verwendbar, da Oracle den iSCSI-Stack ausgetauscht hat. Hier kommt nun COMSTAR zum Einsatz, und Oracle VDI 3.5 ist leider nicht damit kompatibel. Ansonsten ist die Einrichtung des Storage Providers aber einfach, der iSCSI-Servide muss nur eingeschaltet werden, dann kommuniziert die VDI über SSH mit dem ZFS Server und richtet die ZFS-Filesysteme für die „Festplatten“ der Desktops und die ZFS-Snapshots der Desktop-Templates selbstständig ein. Die Datensicherung erfolgte über „zfs send“ bzw das Skript „zetaback“ auf einen zweiten ZFS-Server.

Der Zugriff auf die Desktops sollte mehrschichtig möglich sein:

  • Über Thin Clients. Hier wurden Sun Ray Clients angeschafft. Diese Terminals von Sun bzw. Oracle werden schon sehr lange in verschiedenen Versionen produziert. Allen gemeinsam ist, dass sie einen SmardCard-Reader zur Authentifikation besitzen. Die ersten Versionen (SunRay-1 und -2) waren kleine Desktop-Boxen mit VGA- und/oder DVI-Anschluss für externe Displays sowie USB für Tastaturen und Eingabegeräte. Spätere Versionen kamen mit FC-Netzwerkinterfaces für gesicherte Netzwerke (Baureihe -FS) und integriertem Display (Modell 270). Die Baureihe wird von Oracle weitergeführt und ist aktuell auch mit 21″-Displays erhältlich.
  • Über vorhandene Notebooks und MacBooks, auch mobil über das VPN. Hier wird die Oracle Virtual Desktop Client (OVDC) verwendet, die es für Windows. Linux und MacOSX gibt. Diese simuliert einen Sun Ray Client und unterstützt auch gängige USB-SmartCard-Reader, die dann wir ein Original-SunRay-SmardCard-Reader zur Anmeldung verwendet werden können.
  • Über iPad-Tablets. Für IOS gibt es im Apple App Store die Oracle OVDC App. Wird ein Cisco VPN verwendet, kann sich das iPad direkt im VPN anmelden und dann die OVDC App direkt verwendet werden. Ein SmardCard-Schnittstelle fehlt hier leider. Eine externe Bluetooth-Tastatur funktioniert, und die Maus wird per Touch simuliert.
  • Über das Web mittels SGD / Tarantella. Einzelne virtualisierte Anwendungen oder komplette Desktops können so über das Web erreicht werden. Auch hier fehlt natürlich die SmartCard-Unterstützung.

Die Authentifikation der Benutzer kann über Usernamen und zusätzlich über SmardCards erfolgen. Von Oracle gibt es ein Demo-Pack mit 100 SC-Cards, die in den SunRay Clients und in gängigen USB-Lesegeräten funktionieren. VDI kann so konfiguriert werden, dass eine SmardCard („Token“) mit einem Benutzer und einer Menge an vorgandenen Desktops assoziiert wird. Wird die Karte eingesteckt, ist der damit assiziierte Benutzer vorausgewählt, und Desktops, die an die Karte gebunden sind, können nur verwendet werden, wenn sie eingesteckt ist. Wird die Karte aus einer SunRay entfernt, und in eine andere gesteckt, erscheint der aktuell verwendete Desktop sofort am neuen Terminal. Es ist also möglich, seinen Desktop von einem Raum in den anderen „mitzunehmen“. Diese Möglichkeit macht das System im Gesundheitssektor interessant, wo es neben Regierungsbehörden in den USA relativ häufig verwendet wird, da es dem medizinischen Personal ermöglicht, von Zimmer zu Zimmer zu gehen und beispielweise Röntgenbilder überall zu zeigen – eine Möglichkeit, die aber mittlerweile auch mit Tablet’s besteht.

Wird die Smartcard als Zugriffsberechtigung eingesetzt, ergibt sich unmittelbar eine Two-Factor-Authentication für den Desktop-Zugriff. Für die Anmeldung ist neben einem Faktor, den nur der Benutzer kennt, also dem Passwort („something you know“) immer auch ein Gegenstand im Besitz des Anwenders („something you have“) erforderlich.

Für die passwort-basierte Authentifizierung wurde das Firmen-LDAP verwendet. Es ist in der VDI-Konfiguration direkt möglich, einen LDAP oder Active Directory Server einzubinden. Im vorliegenden Fall handelete es sich um einen Oracle Internet Directory Service.

Einrichtung der Desktops

Es wurden drei Desktop-Pools eingerichtet:

  • Linux Ubuntu LTS
  • Windows 7
  • Windows XP

Laut der Oracle Dokumentation müssen die Desktops mit der Virtualbox-Version, unter der sie nachher in der VDI betrieben werden sollen, installiert werden. Daher war es nötig, zur Installation VirtualBox direkt unter Solaris auf dem Virtualisierungs-Server zu starten und die Ausgabe über X11 zu leiten. Alternatv kann der VirtualBox Guest „headless“ betrieben und per RDP verwendet werden.

Die weitere Installation des Desktops erfolgt dann auf ein Disk Image, dass im Dateisysten des Virtual Box Servers liegt. Es kann dann das Installationsmedium als ISO-Image eingehängt und das Betriebssystem installiert werden. Bereits nach einer rudimentären, aber startfähigen Installation kann der Desktop als Template in VDI importiert werden. Dazu wird in VDI zunächst ein entsprechender Pool für diese Art von Desktops angelegt, und dann der Desktop importiert. Nun ist dessen Image bereits auf dem Storage-Server per iSCSI abgelegt, und das lokale Image aus der initialen Installation kann gelöscht werden.

In den Pool-Einstellungen werden die Ausführungsparameter, die zugeteilten Ressourcen (CPU, RAM) und die Art der Bereitstellung abgelegt. Grundsätzlich gibt es selbstständig und manuell klonende Pools. Bei automatisch bereitstellenden Pools (autocloning) wird ein Zielgröße angegeben, und das System sorgt dann dafür, das stets die entsprechende Anzahl von Desktops zur Verfügung steht. Jeder Desktop bleibt bestehen, bis er „wieder eingeschmolzen“ („recycle)“ wird. Je nach Konfiguration geschieht dies entweder nach Aufforderung, oder wenn der Desktop heruntergefahren, oder die Karte entfernt wird. In diesem Fall wird dem Anwender bei der nächsten Anmeldung ein frischer Desktop aus dem Pool zugeteilt, und der Pool im Hingerund mit einem neuen Desktop, der aus dem Template geklont wird, aufgefüllt.

Die Templates werden über Revisionen verwaltet. Bei Änderungen im Template wie der Installation von Updates oder neuer Software können diese zunächst getestet werden, ist alles zur Zufriedenheit, wird eine neue Version des Templates erzeugt und kann sofort oder zu einem bestimmten Zeitpunkt zur Erzeugung neuer Desktops als Grundlage verwendet werden. Dementsprechend kann auch auf jede alte Version des Templates zurück gewechselt werden. Dieses Szenario könnte zum Beispiel bei Malware-Attacken sehr nützlich sein – über Nacht können alle vorhandenen Desktops gelöscht und das Template korrigiert bzw auf einen Zeitpunkt vor dem Problem zurückgestellt werden.

Im Laufe der weiteren Installation sollten zunächst die VirtualBox-Guest-Additions installiert werden, damit Tastatur und Maus funktionieren und die Bildschirmauflösung korrekt angepasst wird. Nach der Installation der Software-Updates kann die Unternehmensanpassung vorgenommen werden, indem Authentifikation und Profileverwaltung sowie Sicherheitsrichtlinien eingestellt werden. In unserem Fall würde für Windows eine LDAP-Athentifikation am OID über die Open Source Software pGina eingerichtet. Für Linux wurde die Standard-LDAP-Konfiguration verwendet, die Home-Verzeichnisse wurden von einem NFS Server gemountet.

Erfahrungen aus dem Praxisbetrieb

Die Akzeptanz des Systems bei den Test-Benutzern war unterschiedlich und von der Alternative abhängig. Gut aufgenommen wurde das System, wenn es verfügbar und die Terminals gut ausgestattet waren (gutes Display mit nativer Auflösung). Anwender, die als alternative Arbeitsumgebung beispielweise ein aktuelles MacBook mit SSD und Retina-Display besassen, hatten ihre Mühe mit der virtualisierten Umgebung.Der Bildaufbau des Dektops ist über das Netz immer etwas langsamer als bei Desktop-Hardware mit entsprechenden Grafik-Chips.

Laufen ressourcenhungrige Anwendungen in mehreren virtuellen Desktops, kam es in der Testumgebung recht bald zu einer Überlastung des Virtualisierungsservers und / oder des Storage Servers. Eine Anbindung des Storage über ein dediziertes Storage LAN brachte hier etwas Linderung. Gundsätzlich ist zu überlegen, inwieweit gerade eine Testumgebung von Beginn an optiomal ausgestattet werden kann. In einer produktiven Umgebung sollten mehrere Virtualisierungsserver mit einsprechender Kapazität bereitgestellt werden, ebenso eine redundante Auslegung des VDI-Verwaltungsservers (hier ist ein Parallelberieb möglich). Fehlt eine entsprechende Auslegung im Testbetrieb, besteht die reale Gefahr, dass die Anwender die gesamte Lösung nicht akzeptieren, da die Vorteile sich dem Anwender nicht unbedingt auf den ersten Blick erschließen, eine schlechte Performance oder Verfügbarkeit aber unmittelbar ins Auge fällt. Hier ist natürlich ein Problem, wenn für die Testumgebung nur ein begrenztes Budget zur Verfügung steht.

Gerade die subjektive Performance-Wahrnehmung wird gesteigert, wenn die Desktops so konfiguriert werden, dass keine oder nur einfarbige Hintergrundbilder eingestellt sind. In der Oracle Dokumentation sind weitere sinnvolle Tipps zur Konfiguration erwähnt, zum Beispiel entsprechende Windows-Grundeinstellungen. Bildschirmschoner müssen natürlich generell abgeschaltet werden, da sie die anderen Desktops lähmen. Einen sehr grossen Unterschied machen die unter Windows leider unvermeidlichen Virescnanner – bei allengetesteten Produkten verminderte sich die Performance des Desktops nach dem Einschalten spürbar. Bestimmte Produkte wie Symantec funktionieren in VirtualBox überhaupt nicht. Die besten Erfahrungen haben wir mit Kaspersky gemacht.

Laufen die VDI-Server im Single Instance Betrieb und sind nicht redundant ausgelegt, hat ein Ausfall den sofortigen Ausfall sämtlicher Desktops zur Folge. Sind die Ressourcen des VirtualBox-Servers erschöpft, wird der Start neuer Desktops ausgesetzt, und Anwender bekommen bei der Anmeldung die Meldung, dass Ihnen kein Desktop zur Verfügung steht.

Die Authentifizierung mit SmardCards klappt in der Praxis gut, so lange kiene nicht SmatCard-fähigen Geräte verwendet werden solllen – ist dies der Fall, ist das Konzept natürlich durchbrochen, weil die Desktops doch wieder auf Anmeldung mit Username und Passwort konfiguriert werden müssen. Es lassen sich dann beide Verfahren gleichzeitig nutzen, aber die Verwendung der Karte bringt nun keinen Sicherheitsgewinn mehr. Eine Lösung könnte hier eventuell sein, verschiedene Desktops bzw. Pools mit unterschiedlicher Sicherheitseinstufung einzurichten, von denen nur einer für die Anmeldung ohne Karte zugelassen ist.

Wird die Two-Factor-Authentication mit Karte aus Sicherheitsgründen erzwungen, bringt dies natürlich nur einen tatsächlichen Gewinn, wenn die Anwender Ihre Zugangskarten nicht im Terminal stecken lassen oder in den Rollcontainer legen – auch nicht bei kurzen Pausen. Eine gute Lösung wäre sicher, die Hausausweise oder Zugangskarten, wenn vorhanden, mit der SmartCard auf einer Karte zu integrieren, so dass die Karte aus dem Terminal entfernt werden muss, wenn das Gebäude verlassen und wieder betreten werden soll. Eine entsprechende Karte mit SunRay-kompatibler SmardCard-Funktionalität und KABA-kompatibler RFID-Kompatibilität war aber im Rahmen dieses Tests nicht mit vertretbarem Aufwand zu beschaffen. Andererseits muss natürlich auch erwähnt werden, dass die SunRay Terminals keine kryptographischen Funktionen der SmartCards nutzen – es wird lediglich die Sereiennummer der Karte ausgelesen und als Token-ID in VDI verwendet. Hier bieten sich auch interessante Ansätze zu weiteren Anwendungen, zum Beispiel für die PKI-Authentifikation gegenüber weiteren Systemen, auf der SmardCard.

Entscheidend für die Benutzbarkeit des Gesamtsystems ist die Transparenz neue geklonter Desktops. Müssen nach dem Bereitstellen viele Einstellungen angepasst oder gar fehlende Anwendungen nachinstalliert werden, stellt die Neubereitstellung ein erhebliches Hindernis dar. Hier ist besondere Geschicklichkeit im Umgang mit den Lizensierungsfunktionen von Windows und den eingesetzten Applikationen gefragt. Die VDI Umgebung sueht die Möglichkeit vor, die Windows-Lizensierung im Rahmen des Desktop Clonings automatisch vorzunehmen, in der Praxis hat dies mit den vorhendenen Windows-Lizenzen allerdings nicht funktioniert. Ebenso wichtig ist eine vollständige Profilverwaltung mit Active Directory, damit die persönlichen Verzeichnisse der Anwender eine Neubereitstellung des Desktops überdauern. Fehlen nach dem Neu-Klonen die im Benutzerverzeichnis abgelegten Dokumente, entsteht nachvollziehbare Frustration. In unserem Fall war dies mit pGina nicht möglich, daher musste das automatische Klonen neuer Desktops in den Windows-Pools abgeschaltet werden. Bei Linux war dies kein Problem, dafür hatten verschiedene Apps wie Firefox permamanente Probleme mit per NFS eingehängten Home-Verzeichnissen, aber dies ist eine andere Geschichte und gehört zu den Problemen, die nicht direkt mit VDI zusammenhängen.

Die User Experience war an den SunRay-Terminals am besten. Wichtig ist, Original-Sun-Tastaturen zu verwenden, denn bei normalen USB-Tastaturen wurde die Tatstaturbelegung nicht automatisch erkannt, so dass es zu Problemen bei der Passwort-Eingabe kommt. In Guest-OS selbst kann die korrekte Tastaturbelegung dann natürlich eingestellt werden.

Kleine Schwierigkeiten gab es mit den VirtualBox Guest Additions – diese waren teilweise instabil und erfüllten ihre Funktion nach einiger Zeit nicht mehr vollständig. Dies hatte zur Folge, dass Desktops nicht mehr durch den VDI Controller heruntergefahren oder in den Ruhezustand versetzt werden konnten und manuell in der VDI-Kontrolle ausgeschaltet werden mussten.

Als durchgehend positiv wurde die Möglichkeit wahrgenommen, bei Bedarf auch mehrere Desktops unterschiedlicher Betriebssysteme zur Verfügung zu haben. Ebenfalls sehr positiv wurde die Möglichkeit aufgenommen, die Arbeitsplätze nicht nur zentral administrieren, sondrn auch zentrall starten, stoppen und gegenenfalls auch komplett neu initialisieren zu können – und das sogar sehr schnell.

Fazit

VDI ist eine zu traditioneller IT alternative Methode, Desktops im Unternehmen bereitzustellen. Installation und Betrieb der Oracle-Umgebung erscheinen mittlerweile stabil und ausgereift.

Die Arbeit an den virtualisierten Desktops ist flexibel, aber die Benutzer-Erfahrung (snappiness) ist weniger direkt als bei einem gut eingerichteten lokalen Desktop.

Aus Sicht der Unternehmens-IT ist der Einsatz von VDI sicherlich sinnvoll, um Sicherheitsanforderungen abzubilden. Der Hauptvorteil ist, das die Daten das Unternehmen zu keiner Zeit verlassen, und der Zugriff, ebenso wie die verwendete Software, zentral administriert werden kann.

In der Kostenbetrachtung egalisieren sich die Unterschiede bei Betrieb von VDI und traditionellen Desktops. Für kleine Unternehmen wird es sehr schwierig sein, die hohen Kosten für eine hochverfügbare Serverumgebung mit ausreichender Leistung zu budgetieren.

Literatur und Verweise

Datenbankmigration nach Unicode

, ,

cpi-partner-kyrill-schnitt

Einer unserer Kunden ist in der Güterbeförderung auf der Schiene im europäischen Raum tätig. Die Anwendung, mit dem die Abrechnung der Transporte gesteuert wird, basiert auf Oracle Forms und der Oracle Datenbank 11gR2. Dieses System weist sehr viele Schnittstellen unterschiedlichster Natur auf: zum Host, auf dem die Schienenbewegungen erfasst werden, zu einem anderen, ebenfalls Oracle-Forms-basierten System, in dem die Auftraege gesteuert werden, zu SAP, zur Bank und zum Druckdienstleister, der aus den aus der Datenbank geschriebenen XML-Dateien PDF-Dokumente erzeugt.

Im Rahmen der europäischen Integration bekommt das System Zuwachs. Die Bahnen aus osteuropäischen Laendern sollen angeschlossen werden. Dabei ergibt sich ein Problem: In diesen Ländern ist der kyrillische Zeichensatz weit verbreitet. Firmennamen, Ortsnamen, Strassennamen tragen kyrillische Bezeichnungen. Das System soll also in die Lage versetzt werden, neben west- auch osteuropäische Zeichen zu unterstützen. Also muss das gesamte System aus Datenbank, Forms-Server und eigenentwickelten Schnittstellen in Unicode migriert werden. Und da die Datenmengen ständig wachsen, sollte die Umstellung so bald wie möglich erfolgen.

Für neue Datenbank-Installationen ist Unicode, oder UTF-8, bereits seit längerer Zeit Standard. Auch bei Java und XML ist die Verwendung von Unicode längst üblich. Neue Oracle-Datenbank-Installationen werden vom Oracle Universal Installer als Default im Oracle-Zeichensatz AL32UTF8 (NCHAR AL32UTF16) angelegt. Dieser Zeichensatz wird auch als UTF-8 bezeichnet und sollte nicht mit dem Oracle-Zeichensatz UTF8 verwechselt werden. Bei Oracle’s UTF8, auch als CESU-8 bezeichnet, handelt es sich um einen Legacy-Zeichensatz, dessen Verwendung nicht mehr empfohlen wird. Er stammt noch auf den Anfangszeiten von Oracle’s Engagement in Unicode.

AL32UTF8 ist ein dynamischer Multibyte-Zeichensatz, der 1-4 Bytes pro abzubildendem Zeichen verwendet. Für ASCII-Zeichen wird 1 Byte, für europäische Zeichen und solche aus dem mittleren Osten werden in der Regel 2 Bytes, für asiatische Zeichen in der Regel 3 Bytes verwendet. AL32UTF8 entspricht der Unicode 4.0-Konvention.

Für neue erstellte Datenbanken hat Oracle also sinnvolle Default-Einstellungen gesetzt, aber was macht man mit bestehenden Datenbanken? Ältere, westeuropäische Oracle-Installation verwendet oft WE8ISO8859P15, das war auch hier der Fall.

Migrationspfade

Traditionell gibt es zwei Arten der Datenbankmigration nach Unicode:

  • Der Neuaufbau einer frischen Datenbank im neuen Zeichensatz mit anschliessendem Re-Import der Daten. Bei diesem Ansatz wird eine neue Datenbank parallel aufgebaut. Beim Importieren der Daten wird der Zeichensatz dann durch Data Pump konvertiert. Das hat zunächst den Vorteil, den Neuaufbau parallel zum laufenden Betrieb und ohne Zeitdruck durchführen zu können. Allerdings werden hierfür dann auch doppelte Ressourcen benötigt: Es braucht Platz für den Parallelbetrieb der neuen Datenbank. Die Anforderungen an die Downtime („Betra“ – Betriebsausfall) hängen stark vom Datenvolumen ab, denn auch mit Data Pump dauert das Ex- und Importieren abhängig von CPU- und Storage-Leistung lange – in diesem Fall zu lange, um in die maximal mögliche Downtime von zwei Tagen zu passen.
  • Die Migration mit den CSSCAN/CSALTER-Tools. Bei diesen Verfahren wird mit dem Oracle-Tool CSSCAN zunächst überprüft, welche Konflikte in den vorhandenen Daten vorhanden sind. Bestimmte Probleme mit den Ausgangsdaten müssen manuell oder durch Reimport gelöst werden. Diese Tools sind allerdings mittlerweile etwas in die Jahre gekommen und können kein komplexeren Probleme wie das Verlängern von Spaltenbreiten (s.u.) oder die Konvertierung von Data Dictionary Objekten lösen.

Darüberhinaus gibt es einige neuere Ansätze:

  • DMU. Das Thema Unicode-Migration scheint in der letzten Zeit an Aktualität gewonnen zu haben und Oracle hat sich zur Datenbank-Version 11 entschlossen, ein Java GUI Tool zu entwickeln, welches versucht, den gesamten Prozess in einem geführten Workflow abzubilden. Der „Database Assistant for Unicode“ scannt die Datenbank, bereitet die Ergebnisse in einer anschaulichen Übersicht auf, bietet zur Behebung von Qualitätsproblemen einen eigenen Dateneditor und führt abschliessend die Konvertierung und eine abschliessende Kontrolle durch.
  • Abgehängte Migration mit Streams. Hier wird die Datenbank zunächst geklont. Zwischen der Original-Datenbank und der Kopie wird dann eine Streams-Replikation eingerichtet. Ist diese fertig, wird sie wieder angehalten, und nun kann die Kopie in aller Ruhe mit DMU konvertiert werden. Abschliessend wird die Replikation wieder aktiviert, und die Änderungen, die sich in der Zwischenzeit auf der Originalseite angesammelt haben, können übertragen werden. Streams ist in der Lage, diese während der Übertragung nach Unicode zu konvertieren. Sind beide Datenbanken auf dem gleichen Stand, kann der Betrieb in einer sehr kurzen Auszeit auf die Kopie umgeschaltet werden. Diese Methode bietet gleich eine ganze Reihe von Vorteilen: Sie ist neben der kurzen Umschaltzeit beliebig wiederholbar. Zudem kann die konvertierte Datenbank beliebig intensiv getestet werden, bevor sie live geschaltet wird. Wird ein Fehler gefunden, kann der Prozess jederzeit neu begonnen werden.

dmu textlogo

Bei diesem Projekt kamen aus Ressourcengründen alle Verfahren, die den parallelen Aufbau vorsehen, nicht in Frage. Dennoch sollte die Migration in ein Zeitfenster von einem Wochenende passen. Nach einigen Tests zur Geschwindigkeit des Datenex- und Imports wurde schnell klar, dass die 800Gigabyte Daten kaum in diesem Zeitfenster importiert werden konnten – vom zusätzlich notwendigen Aufbau der Unicode-Datenbank ganz abgesehen. Denn im Zeitfenster eines Wochendes müssen am Sonntag vormittag alle Umbauarbeiten abgeschlossen sein, da ein Rückfall auf ein vollständiges Restore mittags beschlossen werden müsste, wenn dieser bis Montag morgen garantiert durchgeführt werden soll. Erste Tests müssten also bis Sonntag Mittag erfolgreich absolviert werden. Aus diesen Gründen kamen nur noch die Methoden CSSCAN und DMU in Frage.

Probleme mit den Ausgangsdaten

cpi_vorgefundene_zeichen

In der nächsten Phase wurde mit CSSCAN und DMU eine Bestandsaufnahme über die in der Ausgangs-Datenbank vorhandenen Daten erhoben. Dabei wurden verschiedene Kategorien vom Ausgangszeichen angetroffen:

  • Daten, die nicht konvertiert werden müssen. Hierbei handelt es sich um Zahlen oder Zeichen, die im Ausgangs- und Ziel-Zeichensatz identisch abgebildet werden. 98% der Daten fielen in diese Kategorie.
  • Daten, die konvertiert werden müssen und können. Dies betraf 1% der Daten, 235 Millionen Zellen. Diese „straighforward“-Konvertierung kann das DMU-Tool von sich aus vornehmen. Aus dieser Kategorie waren neben VARCHAR2 auch LONG und CLOB-Typen vorhanden.
  • Daten, die eine Anpassung der Feldlängen im Datenmodell erfordern („over column limit“). Diese Problematik resultiert daraus, dass Feldlängen in Zeichenlängen früher als Anzahl der verwendeten Bytes angegeben wurden. Unglücklicherweise ist dies immer noch der Default, wenn Tabellen in Oracle angelegt werden. Erst wenn die Umgebungsvariable „nls_length_semantics“ auf „char“ gesetzt wird, oder bei der Spaltendefinition explizit das Wort „CHAR“ angegeben wird, wird die Feldlänge, abhängig vom Datenbank-Zeichensatz, als Anzahl von Zeichen interpretiert. Als BYTE angelegte Spalten können bei einem Multibyte-Zeichensatz wie UTF-8 nicht die ursprünglich vorgesehene Anzahl an Zeichen aufnehmen. Die Spaltendefinitionen müssen daher geändert und die Spaltenlängen vergrößert werden.
  • Zeichenketten, die im Multibyte-Zeichensatz so lang werden, dass sie nicht mehr in ein VARCHAR2-Feld passen („over type limit“). Ein VARCHAR2-Feld kann mit maximal 4000 Byte definiert werden. Solche Daten müssen gesondert behandelt werden, zum Beispiel, indem das VARCHAR-Feld in ein CLOB umgewandelt wird, oder in dem der Inhalt auf zwei VARCHAR-Felder aufgeteilt wird. Solche Änderungen am Datenmodell erfordern natürlich in der Regel auch applikatorische Anpassungen.
  • Daten, die offensichtlich nicht im Datenbank-Zeichensatz vorliegen („invalid binary representation“). Der binäre Wert dieser Zeichen hat keine Entsprechung im Zeichensatz der Datenbank. Da der Ausgangszeichernsatz nicht festeht (der der Datenbank ist es offensichtlich nicht), kann auch keine sinnvolle Konvertierung vorgenommen werden. Diese Daten sind aber auch vor der Konverung schon fehlerhaft: garbage in, garbage out. Wie diese Daten in die Datenbank gekommen sind, lässt sich oft nicht mehr festellen. Meist dürfte es an einem falsch konfigurierten Datenbank-Client liegen, dessen NLS_LANG-Konfiguration nicht der aktuellen Einstellung des Client-Betriebssystems oder dem Aufbau einer Import-Datei entspricht.

Sonderzeichen im Data Dictionary

Ein weiteres Problem für die Konvertierung sind Sonderzeichen im Data Dictionary. Diese kann der DMU nur in einigen Fällen konvertieren. In diesem Fall sorgten insbesondere Umlaute in Triggern und PL/SQL Packages für Probleme.

Eine Möglichkeit, damit umzugehen, ist, diese Objekte einzeln zu überarbeiten und entsprechende Sonderzeichen zu entfernen. Bei umfangreicher installierter Software ist dies allerdings meist nicht möglich. Andere Alternativen sind, diese Objekt zu ex- und nach der Migration wieder zu re-importieren, oder die Software zu löschen und neu zu installieren.

Ablauf der Migration

Das Projekt gliederte sich in drei Phasen: Bestandsaufnahme, Bereinigung und Konvertierung.

Bestandsaufnahme

dbpropscane

Für die Bestandsaufnahme erfolgte zunächst ein Scan mit dem DMU. Dazu muss zunächst die DMU-Software installiert werden. Jeder Computer mit Verbindung zur Datenbank kommt dafür in Frage, da die Java-Software des DMU prinzipiell unter jedem System mit Java JDK1.6 läuft. Auch in der Datenbank muss ein Package installiert werden: SYS.DBMS_DUMA_INTERNAL. Dies geschieht durch Einspielen des Skriptes ?/rdbms/admin/prvtdumi.plb. Die Datenbank sollte möglichst 11.2.0.3 sein, frühere Versionen erfordern das Einspielen von Patches.

Das Tool kann auch auf dem Datenbankserver selbst gestartet werden, dann muss aber im Fall von UNIX als Server-Betriebssystem für eine stabile Ausgabe von X11 Sorge getragen werden. Aus diesem Grund wurde ein Windows-PC verwendet. Ideal wäre ein Terminalserver oder ein Client in einer Virtual-Desktop-Umgebung, denn die Abläufe mit dem DMU dauern in der Regel sehr lange und während der Migration wäre ein Netzwerkausfall zwischen Datenbank und DMU-Client verheerend, ebenso wie ein Absturz des Client-Computers selbst.

Der Scan erfordert SYSDBA-Berechtigungen und kann während der Produktionszeiten erfolgen. Die Parallelität, mit der der DMU die Datenbank scannt, kann konfiguriert werden, läuft nur ein Prozess, dauert es entsprechend länger. In der Praxis konnten wir mit 8 Scan-Prozessen ohne Probleme während des Betriebes arbeiten, in den Nachtstunden wurde mit 16 Prozessen gearbeitet. Ein Scan dauerte etwa 3 Stunden.

migstattab

Bei Tests ergab sich die Situation, dass während des Scans die Netzwerkverbindung abbrach. Dauerte dieser Unterbruch zu lange, verlor der DMU die logische Verbindung zur Datenbank und reagierte nicht mehr. Nach einem Neustart erkennt der DMU die Situation und versucht, sein internes Repository (DMU-Tabellen im SYS-Schema) zu bereinigen. Dies kann sehr lange dauern und der DMU ist währenddessen nicht benutzbar. In einigen Fällen kam dieser Vorgang gar nicht mehr zum Ende. Entfernte man die Sessions des DMU aus der Datenbank, startete der Prozess bei der nächsten DMU-Anmeldung von Neuem. Einzige Abhilfe brachte in dieser Situation das Deinstallieren des Repositories. Dies kann mit Hilfe des Skriptes drop_repository.sql geschehen, das sich im /admin-Verzeichnis des Tools findet, und hat keine Nebenwirkungen: Danach kann das Tools sich wieder an der Datenbank anmelden und baut ein neues Repository auf. Danach ist natürlich ein frischer Scan nötig.

Bereinigung

DMU_edit_row

Ist die Bestandsaufnahme abgeschlossen, kann in die Ergebnisanalyse eingestiegen werden. In unserem Fall wurde zunächst versucht, die ermittelten Probleme in möglichst viele gleichartige Klassen zu unterteilen, die dann mit Skripten angegangen werden konnten. Zunächst wurde ein Skript erstellt, dass alle Tabellen mit BYTE-Spaltendefinitionen in CHAR-Definition umwandelt. Dies kann schlicht mittels „alter table .. modify“ erfolgen. Dann wurden individuelle Lösungen für die „over type limit“-Fälle geschneidert, meist wurden hier VARCHAR2-Felder in CLOB imgewandelt werden, dazu legt man am Besten eine temporäre CLOB-Spalte an, kopiert den Inhalt der VARCHAR2-Spalte mit einem UPDATE-Statement, lösche diese und benennt das CLOB in den ursprünglichen Namen der VARCHAR-Spalte um.

Bei den „Invalid Binary Representation“-Fällen war ein wenig detektivischer Spürsinn gefragt. Mit etwas Phantasie gelang es in den meisten Fällen den ursprünglichen Zeichensatz zu erraten. Dann konnten spezialisierte Update-Statements geschrieben werden, die die ungültigen Zeichen zusammengefasst bereinigten. Bei der Entwicklung dieser Korrekturscripte wurde versucht, die Datenqualität gleich dauerhaft zu verbessern, und die eine oder andere Stunde an Recherche über die korrekte Schreibweise osteuropäischer Orte und internationaler Produktbezeichnungen aufgewendet.

Die verbleibenden Fälle, das waren diejenigen, die weniger als zehn Vorkommen aufwiesen, wurden in Einzelfallbearbeitung bereinigt. Der DMU bietet hierzu ein schönes interaktives Interface an, dass die fragwürdigen Zeichen gleich farblich hervorhebt.

Ist die in der Datenbank vorhandene Software in einem eigenen Schema installiert und von dem Schema, in dem die Daten liegen, getrennt, so hat man Glück und kann das Software-Schema exportieren und löschen und anschließend befinden sich keine problematischen Objekte mehr im Data Dictionary. Im vorliegenden Fall war dies nicht möglich, und die betroffenen Trigger und Packages mussten per Skript gelöscht werden. Zum Re-Installieren der Software nach der Migration muss dann natürlich die Software entweder neu installiert werden können. Ist kein Installationsmechanismus vorhanden, müssen diese Objekte, ebenfalls per Skript, neu angelegt werden. Hierfür hat es sich nach einigen Tests mit Perl und dem SQL Developer als am sinnvollsten erwiesen, die Definitionen dieser Objekte vorher mit DBMS_METADATA.GET_DDL zu extrahieren und entsprechende Installationsskripte erstellen zu lassen. Um Umstände zu vermeiden, wurde das PERFSTAT-Schema, das ebenfalls betroffen war, kurzerhand entfernt – PERFSTAT kann hinterher neu angelegt werden.

Zum Abschluss empfiehlt es sich, einen Blick auf den Volumenzuwachs zu werfen. Durch die Multibyte-Repräsentation wächst während der Konvertierung die Datenmenge. Es ist also entsprechend Platz in ASM oder den Filesystemen vorzusehen und darauf zu achten, dass die Datafiles hinreichend Reserven aufweisen oder auf AUTOEXTEND stehen. In unserem Fall haben wir etwa 10% Volumenzuwachs gesehen, das entsprach auch der Vorabschätzung des DMU.

Die Bereinigungsphase ist abgeschlossen, wenn das Status Panel des DMU nach einem abschliessenden Scan den Status „ready for conversion“ anzeigt.

Konvertierung

Vor der Konvertierung sollte sichergestellt werden, dass für die umfangreichen UPDATEs, die das Tool absetzt, genügend Platz für die Archive Logs bereitsteht, bzw ob es sinnvoll ist, ARCHIVELOG während der Migration komplett abzuschalten, was sich natürlich sehr positiv auf die Laufzeit auswirkt.

Es gibt in der Version 1.1 des DMU einen Bug, der während der Konvertierung zu einem Abbruch mit dem Fehler „ORA-22839: Direct updates on SYS_NC columns are disallowed“ führen kann. Um dies zu vermeiden, sollte vor der Konvertierung ein Event 22838 gesetzt werden: „alter system set events ‚22838 TRACENAME CONTEXT LEVEL 1, FOREVER'“.

Vor der Konvertierung sollten zudem alle Jobs abgeschaltet werden („alter system set job_queue_processes=0“).

Die Konvertierung selbst konnte ohne Probleme durchgeführt werden. Die Konvertierungszeit lag bei 17 Stunden. Sollten während der Konvertierung einfache Probleme wie eine volle FRA oder ein fehlendes AUTOEXTEND auftreten, hält DMU an und bietet die Möglichkeit, den Vorgang fortzusetzen, wenn das Problem behoben wurde.

conversion_successfull

Nacharbeiten

Nach der Konvertierung ist der Datenbank-Zeichensatz umgestellt, nun müssen eventuell noch entsprechende Client-Settings angepasst werden, zum Beispiel die Konfiguration von NLS_LANG.

Außerdem ist es empfehlenswert, den Parameter NLS_LENGTH_SEMANTICS=CHAR in der Datenbank zu setzen und die Nls_Length-Semantics-Konfiguration der Clients anzupassen, damit zukünftige Objekte nicht in BYTE-Semantik angelegt werden. Beim SQL Developer kann diese Einstellung in den Settings gesetzt werden. Hier empfiehlt sich eine entsprechende Information aller Entwickler. Auch bei Software-Lieferprozessen, die oft in der Unix-Shell mit sqlplus erfolgen, sollte darauf geachtet werden, hier die richtige Konfiguration, auch von NLS_LANG, zu wählen. Wenn Software-Pakete weiterhin im alten Zeichensatz geliefert werden und eingespielt werden sollen, muss die Variable NLS_LANG beim Aufruf von SQLPlus auf dem Wert für den Zeichensatz stehen, in dem die Datei erzeugt wurde.

sqldeveloper_nls_settings

Nach dem evtl. erforderlichen Re-Import von Software sollten alle Datenbankobjekte unter besonderer Beachtung der korrekten NLS-Settings neu kompiliert werden – ebenso die Views und Materialized Views, die sich evtl vorher auf Tabellen mit BYTE-Semantik bezogen haben. Es empfiehlt sich eine abschließende Kontrolle in dba_tab_columns (CHAR_USED=C) und dba_plsql_object_settings (nls_length_semantics), ob alle Objekte in Char-Semantik vorliegen.

Wird Forms verwendet, muss auch auf dem Forms-Server die NLS-Konfiguration angepasst sowie alle Forms-Module neu übersetzt werden, da sich die Signatur in der Datenbank aller Wahrscheinlichkeit nach geändert hat.

Schnittstellen

Für dateibasierte Schnittstellen, inklusive XML, dass direkt aus der Datenbank erzeugt wird, muss geprüft werden, ob diese zukünftig in Unicode liefern dürfen. Ist dies nicht der Fall, muss die Ausgabe entsprechend konvertiert werden – zum Beispiel mit Hilfe der Funktionen utl_file.put_raw und utl_i18n.string_to_raw.

Sind Clients nicht Unicode-fähig, können sie weiterhin im alten Zeichensatz betrieben werden, wenn deren NLS-Konfiguration entsprechend eingestellt ist (z.B. auf WE8ISO8859P15). Bei diesem Mischbetrieb können sich allerdings Probleme beim Liefern von ISO8859-XML-Dateien ergeben. Bisher im Datenbestand vorhandene Inhalte sind 1:1 abbildbar, da AL32UTF8 eine Obermenge von WE8ISO8859P15 und ISO8859 ist. Nach der Unicode-Umstellung können allerdings auch Unicode-Zeichen eingegeben werden, die in ISO8859 nicht darstellbar sind. Diese Zeichen würden dann im XML durch das Ersetzungszeichen ersetzt werden. Im ungünstigsten Fall könnte also das Ersetzungszeichen „¿“ statt eines kyrillischen Zeichens ausgegeben werden.

Quellen