Oracle stellt fünfte Exadata-Generation vor

,

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

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

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

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

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

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

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

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

Unruhe wegen OWB-Abkündigung

,

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

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

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

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.

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

LinuxMagazin Artikel zur CERA-Datenbank

, , ,

Eine 125 TByte große Datenbank unter Linux speichert Simulationsergebnisse im Deutschen Klimarechenzentrum.
Eine ausgefeilte hierarchische Speicherlösung begrenzt den benötigten Plattenplatz.

Von Hannes Thiemann und Jan Schreiber

Erschienen im Linux-Magazin 03/2005

Das Abtauen der Gletscher, den Anstieg des Meeresspiegels, ja selbst so gravierende Folgen wie einen Zusammenbruch des Golfstroms halten Wissenschaftler als Folge eines Klimawandels für möglich. Wirksame Gegenmaßnahmen erfordern einschneidende politische Entscheidungen – und die müssen sich auf überzeugende wissenschaftliche Beweise für einen von Menschen verursachten Klimawandel stützen. Auf der Suche nach solchen Beweisen greift die Klimaforschung einerseits auf empirische Daten zurück, die zum Beispiel die Erwärmung am Ende des 20. Jahrhunderts als Ausnahme in den letzten 1000 Jahren belegt haben. Andererseits arbeitet sie mit Modellen, die Klimaveränderungen auf der Grundlage physikalischer Gesetze durch mathematische Gleichungen simulieren. Solche Modelle sind trotz aller Probleme in der Lage, das Klimasystem und seine Veränderungen zu simulieren. Sie vermitteln eine Vorstellung über das Wechselspiel verschiedener Einflussfaktoren – etwa der Treibhausgase – und haben den Zusammenhang zwischen der Erwärmung der letzten Jahrzehnte und ihren von Menschen zu verantwortenden Ursachen aufgedeckt.

Informationsflut kanalisiert

Diese Simulationen produzieren gewaltige Datenmengen und erfordern Hochleistungsrechner, wie sie am Deutschen Klimarechenzentrum (DKRZ) in Hamburg durch eine kleine Gruppe von Wissenschaftlern betreut werden. Die wertvollste Ressource des Zentrums ist ein Vektorrechner von NEC, der Mitte 2004 ganz vorn auf der Top-500-Liste der Supercomputer stand. Die auf diesem Rechner durch Simulationen erzeugten Daten werden in einem Bandarchiv gespeichert. Die Wissenschaftler, die sie später auswerten, benötigen allerdings trotz des gigantischen Umfangs und der Komplexität der Daten einen einfachen Zugang. Dazu gibt es am DKRZ eine von der Gruppe Modelle und Daten am Max-Planck-Institut für Meteorologie betreute Oracle-9i- Datenbank. Sie stellt zum einen Informationen über Experimente bereit und enthält zum anderen deren wichtigste Ergebnisse. Im Dezember 2004 umfasste dies eine Datenmenge von etwa 125 TByte mit stark zunehmender Tendenz

Globus im Gitternetz

Klimamodelle rechnen auf einem weltumspannenden, dreidimensionalen Gitter. Für jeden der Gitterpunkte wird der Gesamtzustand des Systems in diskreten Zeitabständen von sechs Stunden Modellzeit abgespeichert. Das System setzt sich aus mehreren Parametern zusammen: Temperatur, Niederschlag, Wind und vielen anderen. Ein Problem ist die von der Rechnerleistung abhängige horizontale Auflösung der Modelle, die bei den globalen zurzeit bei etwa 250 Kilometer liegt. Eine solche Auflösung erlaubt weder regionale Prognosen noch die Wiedergabe von räumlich und zeitlich sich schnell verändernden Prozessen wie etwa der Wolkenbildung. Auch die adäquate Wiedergabe der vielen Rückkopplungen im Klimasystem ist ein Problem. Tabelle 2 gibt einen Überblick über die anfallenden Daten. Wie sich zeigt, kommen trotz recht kleiner Datenmengen für jeden einzelnen Zeitschritt insgesamt gewaltige Summen zusammen.

Aus einem Stück

Bis vor kurzem wurde am DKRZ noch eine recht traditionelle Architektur eingesetzt. Vektorrechner waren über LAN an ein Hierarchical Storage Management System (HSM) gekoppelt. Auch skalare Postprocessing-Rechner von Sun waren via LAN angeschlossen, ebenso eine Sun E15k, auf der die noch recht überschaubare monolithische Oracle-Datenbank mit einer Größe von 25 TByte lief.
Ab Anfang 2002 stattete NEC High Performance Computing Europe (HPCE) das DKRZ mit dem neuen Vektorrechner SX-6 aus. Die neueste Generation der SX-Serie dominierte zu diesem Zeitpunk tdie Top-500-Benchmark-Liste mit den schnellsten Supercomputern weltweit, Spitzenreiter war der in Tokyo installierte Earth Simulator. Die SX-6er behielten ihre Führungsposition bis zum Herbst 2004.

Im Zuge des Umbaus im DKRZ wurde zudem entschieden, auch für die Verwaltung der Simulationsergebnisse ein neues Konzept zu entwickeln und sich von dem monolithischen, Sun-basierten Ansatz zu entfernen und stattdessen auf Linux zu setzen.

Verteilte Zukunft

Bei den für die Datenbank unter Linux eingesetzten NEC-TX-7-Systemen handelt es sich um Itanium-2-Rechner mit einer Taktrate von 1 bis 1,5 GHz und 3 MByte Level-3-Cache auf dem Chip. Der Systembus kann 6,4 GByte/s transportieren, das System schafft damit eine Stand-alone-Performance von 4,0 GFlops. Der Speicherzugriff erfolgt per Cache-Coherent Non-Uniform Memory Access (CCNUMA). Das System ist in vier Zellen mit jeweils vier CPUs organisiert. Eine High-Performance- Crossbar, die die TX-7-Rechner aus dem Supercomputing-Bereich geerbt haben, verbindet diese Zellen zu einem Gesamtsystem mit bis zu 32
CPUs. Hersteller NEC liefert es wahlweise mit Linux oder HP-UX aus.

Schon zu Beginn des Projekts wurde klar, dass das neue Datenbanksystem aus mehreren kleineren, zusammenarbeitenden
Zellen bestehen soll. Die NECTX- 7-Maschinen und NECs HPC-Linux eigneten sich zwar für 24 CPUs, aber Oracle war nur für Red Hat und United Linux zertifiziert. Diese Distributionen unterstützten im Planungsjahr 2003 weder die CCNUMA-Architektur der TX-7-
Hardware noch 24 CPUs, sodass der Ausbaustand der Sun E15k mit ihnen nicht nachzubilden war. Oracle hatte sich aber am DKRZ bewährt. Der kommerziell verfügbare Support, die guten Erfahrungen mit der Skalierbarkeit, das vorhandene Know-how
und das gute Datenhandling dieser Plattform waren schwer zu ersetzen. Also fiel die Entscheidung gegen einen Ansatz mit symmetrischem Multiprocessing und für die bei Oracle Federate Database genannte Struktur: fünf Rechner mit mehreren
Datenbankinstanzen und einer gemeinsamen Darstellung der verfügbaren Daten nach außen.

Ergebnis- und Metadaten

Möglich wird dies durch die Trennung der Ergebnisdaten in Form von BLOBs (Binary Large Objects) und der Metadaten, sozusagen dem Inhaltsverzeichnis. In diesem Inhaltsverzeichnis, also der Meta-Datenbank, musste nun ein Zeiger auf die BLOB-DB eingefügt werden, in der die Ergebnisdaten der Simulationen liegen. Durch die zentrale Verwaltung der Zugriffsrechte auf einem LDAP-Server mit Benutzeridentifikation über SSL ist ein quasi-transparenter Zugriff auf alle Datensätze möglich, obwohl sie in
verschiedenen Datenbanken liegen.

Der größte Aufwand ergab sich aus dem Transfer der BLOB-Daten von der Sun- Architektur zu Linux. Denn das Format von Oracles binären Datenfiles ist zwischen Oracle für Solaris und Oracle für Linux unterschiedlich. Die auf dem alten Backend abgelegten Datenfiles ließen sich daher nicht einfach auf den neuen Maschinen mounten.
Eine Machbarkeitsstudie verglich zunächst die Performance verschiedener denkbarer Transportwege: Die erste Alternative
war ein Export einzelner Daten von der ursprünglichen Sun-DB, anschließend Transfer per FTP zur neuen
Linux-DB und nachfolgender Import. Alternative zwei bestand in einem Remote Select mit Hilfe eines Database-Links zwischen den Maschinen. Geschwindigkeit und Handling überzeugten nur bei der zweiten Methode. Kalkuliert war eine Laufzeit des Übertragungsskripts, das in PL/SQL entwickelt wurde, von mehreren Monaten. Hier war es natürlich besonders spannend, abgebrochene und wieder anlaufende Übertragungen möglichst reibungslos zu gestalten, denn während einer derart langen Laufzeit musste zumindest mit einigen Wartungsarbeiten und Reboots gerechnet werden.

Cluster bewährt sich

Auch wenn einige der im DKRZ verwendeten Oracle-Komponenten, etwa der Internet Application Server, noch nicht
für Itanium und Linux vorliegen und weiterhin auf Solaris betrieben werden müssen, nahm der neue Linux-Datenbankcluster den Datenstrom flüssig und störungsfrei an. Dieser setzte sich aus der Migration und den parallel einfließenden neuen Produktionsdaten, die ständig von den Post-Processing-Systemen hinter dem Vektorrechner erzeugt wurden, zusammen. Bei Störungen oder bei zu geringem Cache für das Zwischenspeichern der Ergebnisse hätten die Produktionsläufe im Vektorrechner gestoppt werden müssen. Insgesamt wurden 8000 unpartitionierte und 4000 partitionierte Tabellen mit 12980 Partitionen übertragen.

Jahr DB-Größe
1999 2 TByte
2000 4 TByte
2001 7 TByte
2002 11 TByte
2003 25 TByte
2004 125 TByte

Auflösung pro Zeitschritt pro Modellmonat pro 500-Jahreslauf
110 km 100 KByte 5,2 GByte 30 TByte
300 km 16 MByte 650 MByte 3,7 TByte

Globales Filesystem verkürzt Zugriffspfad

Das im DKRZ eingesetzte Linux ist ein Red Hat Advanced Server mit Kernel 2.4.18. Der Kernel wurde mit einigen für
den Betrieb im Datacenter erforderlichen Features übersetzt, zum Beispiel dem Support für das Global File System (GFS). Das GFS ist eine Weiterentwicklung von NFS (Network File System). Der Unterschied zwischen beiden besteht in erster Linie darin, dass die
Daten bei NFS über das LAN vom NFS-Server zum NFS-Client laufen. Im Klimarechenzentrum hätte dies zur Folge, dass die Daten vom Massenspeicher (Bandsilo, Diskcache) über das SAN zum NFS-Server gelangen müssten, bevor sie wiederum von dort über das LAN beim Client eintreffen.
Zwar beginnt ein GFS-Transfer genauso mit einer Anfrage des Clients an den Server nach einem Datenblock beziehungsweise
nach einer Datei. Der GFS-Server antwortet darauf jedoch nicht mit den angefragten Daten selbst, sondern verweist den Client auf eine Speicheradresse, über die er die Daten direkt aus dem SAN vom gemeinsam genutzten Massenspeicher abholt. Der GFS-Server verwaltet dabei die Inode-Operationen auf dem Filesystem des Massenspeichers, das dadurch konsistent bleibt
Da die meisten Wissenschaftler besonders an Zeitserien einzelner Variablen (zum Beispiel an der Oberflächentemperatur) interessiert sind, werden auch die Daten dieser Struktur entsprechend in der Datenbank gespeichert. Jede dieser
Zeitserien wird kontinuierlich in einer einzelnen Tabelle abgelegt. Die Daten eines bestimmten Zeitpunkts bilden eine BLOB-Zeile. Einige Tabellen erreichen schon sehr bald eine Größe bis zu mehreren 10 GByte. Die Abfragemimik erlaubt es den Benutzern jedoch, ihre Downloads beliebig granular zu gestalten, sodass sich die Datenmenge beim Transfer schnell reduziert.
Bei der Implementation war der verfügbare Plattenplatz ein wichtiges Kriterium. Zurzeit wird die Datenbank auf rund 20 TByte betrieben. Die aktuelle Datenbankgröße beträgt jedoch bereits 125 TByte.

Mehr Platzbedarf als Platten

Um die gewaltige Datenmenge trotz dieser Diskrepanz vorhalten zu können, ist die Oracle-Datenbank in die am DKRZ betriebene HSM-Umgebung eingebettet. Bei dem HSM-System handelt es sich um Unitree/DXUL (mittlerweile im Besitz von EMC) auf der Grundlage von Linux. Ergänzt wird es durch ein Zusatzprodukt namens Disk Xtender. Diese Ergänzung verwaltet lokale Filesysteme,
deren Files sie nach bestimmten Kriterien automatisch auf ein Backend- System kopiert, wonach sie gegebenenfalls von der Platte gelöscht werden können. Als Kriterien verwendet Disk Xtender die Größe der Files sowie die Zeit der letzten Änderung beziehungsweise des letzten Zugriffs.

Datenfiles und Partitionen

Das Verfahren würde normalerweise von Oracles Strategie durchkreuzt, die Datenfiles regelmäßig zu aktualisieren. Das gilt jedoch nicht für Datenbankdateien, die nur lesbar sind. Solche Dateien bleiben unverändert – wie sich ja auch die in ihnen gespeicherten Ergebnisse der Simulationen nicht mehr ändern. Außerdem sind die Tabellen mit Hilfe eines Schlüssels unterteilt (Range Partitioning). Den Partitionen lassen sich wieder eigene Datenfiles zuweisen.

Damit ergibt sich folgender Ablauf:
■ Einfüllen der Daten in die Partition n.
■ Sobald Partition n voll ist, erfolgt das weitere Schreiben in Partition n+1.
■ Partition n wird read-only gesetzt.
■ Kopieren der Partition n in ein vom Disk Xtender verwaltetes Filesystem.
■ Löschen der ursprünglichen Datenbankdatei.
■ Nun ist der Platz wieder frei für Partition n+1, die sich im weiteren Verlauf automatisch vergrößert.

Dateien, die der HSM-Mechanismus nach dem Kopieren in ein Disk-Xtender- Filesystem auslagert, werden dort in kleinere – konfigurierbar große Stücke – unterteilt (256 bis 512 MByte in der am Klimarechenzentrum verwendeten Konfiguration).

Datenstummel bleiben liegen

Wird eine Datei komplett von der Platte gelöscht (gepurged), müsste sie zunächst aus Datenbanksicht offline gesetzt werden, damit die Datenbank nicht versucht auch nur lesend auf das nicht mehr vorhandene File zugreifen. Um das zu vermeiden, lässt man nach dem Purgen der Datei immer den so genannten Stub, also den Kopf der Datei, auf der Platte stehen. Die Länge dieses Stubs ist konfigurierbar. Für Oracle-Datenbanken empfiehlt sich eine Größe von 256 KByte. Das Purgen entfernt also nur den Teil hinter diesem Header von der Platte. Aus Datenbanksicht bleibt die Datei weiterhin verfügbar und muss folglich auch nicht offline gesetzt werden. Greift ein Benutzer über die Oracle-Datenbank auf gepurgte Dateien zu, so startet der Disk Xtender im Hintergrund einen Prozess, der – transparent für den Benutzer und die Datenbank – das jeweils benötigte Stück (und nur dieses) zurücklädt. Der Download der Daten dauert dann entsprechend etwas länger. Um unnötige Bandzugriffe zu vermeiden, ist es wichtig, beim Anlegen der Tabellen die Speicherparameter sorgfältig zu wählen.

Langsam, aber sparsam

Ein Bandzugriff dauert meist knapp fünf Minuten. In dieser Zeit wird das Band ausgesucht, automatisch in ein Laufwerk geladen, bis zum Beginn der gewünschten Aufzeichnung vorgespult und gelesen. Danach gelangen die Daten via FTP zu dem Datenbankrechner. Erst jetzt bekommt der Anwender seine Daten zu sehen, der gesamte Download läuft im Hintergrund. Der Vorteil kleinerer Downloads ist, dass das System nicht immer die gesamte Datei von Band zurückzuladen braucht. Bei größeren Downloads muss dieser Zyklus jedoch mehrfach wiederholt werden. Das kann dann zu sehr langen Download-Zeiten führen, da die Datenbank nur ein Benutzer des HSM-Systems unter mehreren ist. Als großer Vorteil ergibt sich jedoch ein drastisch verringerter Bedarf an Plattenplatz für die Datenbank. Erkauft wird dies jedoch mit einer erhöhten Antwortzeit des Systems.

Petabyte-Datenbank schon im Blick

Die Anforderungen an die Klimavorhersage und damit auch an die Klimamodelle werden in Zukunft weiter steigen. Neben einer verfeinerten regionalen Auflösung ist es ebenfalls erforderlich, zusätzliche physikalische Prozesse des Klimasystems abzubilden. Die von den Klimamodellen erzeugte Datenmenge wird sich damit sicherlich nochmals beträchtlich erhöhen. Die im Klimarechenzentrum verwendete Architektur einer verteilten Oracle-Datenbank unter Linux wird grundsätzlich diesen Anforderungen gerecht. Die Zuverlässigkeit und Verfügbarkeit der Kombination Oracle und Linux hat sich in der Praxis als gut erwiesen. Die implementierte Lösung ist durch Hinzufügen weiterer TX-7-Zellen ausbaufähig. Einer Petabyte-Oracle-Datenbank unter Linux in absehbarer Zeit steht damit prinzipiell nichts entgegen. (jcb)

Info
[1] Deutsches Klimarechenzentrum GmbH:[http://www.dkrz.de]
[2] Max-Planck-Institut für Meteorologie:[http://http://www.mpimet.mpg.de]
[3] NEC HPCE Skalar SMP Page:[http://www.hpce.nec.com/465.0.html]
[4] Oracle unter Linux:[http://www.oracle.com/technologies/inux/index.html]
[5] Atlas-Projekt: [http://sourceforge.net/projects/atlas-64/]
[6] Top 500 Supercomputer:[http://www.top500.org]

Die Autoren

Hannes Thiemann ist Geophysiker und Datenbankadministrator am Hamburger Max-Planck- Institut für Meteorologie, Gruppe Modelle und Daten.

Jan Schreiber arbeitet als freiberuflicher Oracle-Consultant (Loopback.ORG)