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.

Streams und Advanced Replication werden eingestellt

Oracle Streams und Advanced Replication werden seit Oracle Datenbank Version 12c nicht mehr weiterentwickelt. In zuküntigen Versionen der Datenbank werden beide Technologien nicht mehr unterstützt werden. Oracle empfielt Golden Gate als Nachfolgeprodukt in beiden Fällen.

Streams und Replikation wird vielfach in Umgebungen verwendet, in denen verteilt an mehreren Orten auf einem abgeglichenen Datenbestand gearbeitet werden muss, während keines der beteiligten Systeme klar als führendes System bestimmt werden kann, so dass auf allen Systemen Änderungen akzeptiert werden müssen. Einsatzbereiche sind zum Beispiel Kassensysteme in Filialen, die ihren Datenbestand mit der Zentrale abgleichen müssen, oder gleichzeitiges, gemeinsames Arbeiten an Konstruktionsmodellen im Flugzeugbau bei verteilten Standorten.

Das Nachfolgeprodukt Golden Gate muss im Gegensatz zu Streams und Advanced Replication separat lizensiert werden. Es verspricht allerdings auch erhebliche Verbesserungen, etwa Multi-Master-Replikation und Deployment Templates. Der Betrieb von einer Multi-Master-Umgebung mit Advanced Replication war bisher problematisch – entweder musste jede Änderung mit allen beiteiligten Systemen abgeglichen werden (Two Phase Commit), was sehr langsam und anfällig gegenüber Störungen war, oder es entstanden bei der sogenannten asynchronen Replikation zwangsläufig Konflikte. Die Pflege von Änderungen am Datenmodell und der dazugehörigen Anpassungen in der Replikation war ebenfalls sehr aufwändig.

Details im finden sich im Oracle Database Upgrade Guide 12c.

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