Home 
ORDIX News 2/2004
ORDIX News 2/2004
ORDIX News 2/2004
Das IT-Magazin der ORDIX AG mit Fachbeiträgen zu Datenbanken, Unix und Java/XML.
Übersetzung Genesis 11,7"Wohlauf, lasst uns herniederfahren und ihre Sprache daselbst verwirren, dass keiner des andern Sprache verstehe!" |
Zum gegenwärtigen Zeitpunkt kann mit den Möglichkeiten der Oracle-Datenbank jede sinnvoll denkbare Kombination von Sprach- und Zeichensystemen abgebildet werden. Problematisch wird es, wenn bereits eine Datenbank betrieben wird und nachträglich die Notwendigkeit entsteht, auf ein anderes Zeichensystem bzw. ein anderes Character Set zu migrieren.
Kulturelle oder politische Änderungen verlangen beispielsweise, den bislang genutzten Zeichensatz auszuweiten, wie etwa die €-Einführung, oder die Zusammenarbeit mit Menschen oder Firmen jenseits des Horizonts der lateinischen Schrift (z. B. Russland, die arabischen Staaten, aber auch das neue EU-Mitglied Zypern) stellt neue Anforderungen an die "Sprachmächtigkeit" der Datenbank. Dann wird es sehr schnell nötig, Daten unterschiedlicher Sprachen zu speichern, die bei der Erstellung der Datenbank noch nicht vorgesehen waren und die das bei der Installation gewählte Character Set möglicherweise nicht abbilden kann.
Da Umlaute oder akzentuierte Zeichen früher kein Thema waren, arbeiten noch heute viele ältere amerikanische Datenbanken mit ASCII, das mit jeweils 7 Bit Breite für ein einzelnes Zeichen alle nötigen Zeichen abbildet. Insgesamt 128 Zeichen können so dargestellt werden.
Die heutigen, darüber hinausgehenden Anforderungen der europäischen Sprachen, z. B. akzentuierte Buchstaben, führten zu einigen Character Sets, die mit 8 Bit Breite alle nötigen Zeichen (insgesamt 256) der verschiedenen europäischen Sprachen abbilden – die von ASCII abgebildeten Zeichen als Untermenge (Sub Set).
Die silbenorientierte Welt der asiatischen Sprachen ist mit den Möglichkeiten eines 1 Byte breiten Zeichensatzes nicht mehr abzubilden und führte zur Entstehung der Multi Byte Character Sets, die wiederum als Untermenge ASCII mit abbilden.
Die Auswahl des Character Sets bildete bei der Erstellung der Datenbanken immer das möglichst beste Mittel zwischen Vielfalt der Darstellung und Performance: ein Single Byte Character ist natürlich schneller verarbeitet als ein Character, der mehrere Byte groß ist.
Sollen verschiedene Datenbanken zusammenarbeiten, die mit unterschiedlichen Character Sets installiert wurden, wäre die Migration auf ein Character Set notwendig, das alle Zeichen der zuvor verwendeten Zeichensätze enthält, also für diese Zeichensätze ein Super Set darstellt.
Es gibt bei der Vielfalt der Character Sets immer verschiedene Möglichkeiten. Wenn aber die Migration durchgeführt wird, sollte so entschieden werden, dass mit dieser Migration auch zukünftige Entwicklungen und mögliche Anforderungen weitgehend abgebildet werden können. Wenn also in Aussicht steht, dass weitere Sprachen unterstützt werden sollen, sollten diese möglichst schon im ausgewählten Character Set vorhanden sein.
Single Byte Character Sets bieten bessere Performance und brauchen weniger Speicherplatz als Multi Byte Character Sets, begrenzen aber die Anzahl der verfügbaren Zeichen und damit die Bandbreite der zur Verfügung stehenden Sprachen.
Zu bedenken ist auch, dass es bei Clients mit verschiedenen Character Sets zu Konvertierungen kommen kann. Da eine solche Konvertierung Performance kostet, sollten bei solchen Konstellationen möglichst Character Sets ausgewählt werden, die solche Konvertierungen unnötig machen und die effektivste Verschlüsselung für alle genutzten Sprachen oder Zeichensätze bieten. Deshalb sollte ein Character Set gewählt werden, das den Anforderungen der verschiedenen Clients möglichst ohne Konvertierung begegnet.
Zudem sollte das Character Set Super Set für die vorher genutzten Character Sets sein, also für jedes Zeichen ein Äquivalent bieten. Ansonsten besteht die Gefahr des Datenverlustes. Das Character Set der Datenbank sollte möglichst für alle von den Clients verwendeten Character Sets Super Set sein.
Wird nur ein Teil der Zeichen eines Character Sets eines Clients genutzt, sollte dieser Teil im Character Set der Datenbank abgebildet sein. Insbesondere dann, wenn z. B. die Character Sets sehr ähnlich sind, wie WE8MSWIN1252 und WE8ISO8859P1.
Wenn man das €-Symbol nicht braucht, kann ohne Datenverlust von WE8MSWIN1252 zu WE8ISO8859P1 konvertiert werden. Jedes nicht in WE8ISO8859P1 verfügbare Zeichen konvertiert Oracle in ein Ersatzzeichen (siehe Exkurs).
Wenn alle Clients das gleiche Character Set nutzen, ist dieses Character Set oder ein entsprechendes Super Set die beste Wahl. Für Clients mit verschiedenen Character Sets sollte das neue Character Set für alle schon vorhandenen Super Set sein.
Wenn in einer Oracle-Datenbank mit Daten aus verschiedenen Sprach- und Zeichensystemen gearbeitet wird, empfiehlt Oracle als Character Set UNICODE.
UNICODE ist ein universales Character Set, in dem die Zeichen jeder Sprache abgebildet sind. Für jedes Zeichen bietet UNICODE einen eindeutig zugeordneten, binären Wert in verschiedenen Längen – also zum Teil Single Byte, zum Teil Multi Byte.
In einer Datenbank mit dem Character Set UNICODE können Daten in den verschiedensten Sprachen vorgehalten, verarbeitet und von verschiedensprachigen Clients abgefragt werden.
UNICODE bildet für alle in Oracle möglichen Character Sets ein Super Set und ist damit für Globalisierung oder Konsolidierung verschiedener Datenbanken eine sinnvolle Wahl.
Hinsichtlich der Performance gibt Oracle als ungefähre Größe einen Overhead von 10 % gegenüber einer Datenbank mit einem Single Byte Character Set an. Das kann abhängig von der Art und Anzahl der SQL-Funktionen, die den Datenbankbetrieb ausmachen, noch ansteigen.
Sollen verschiedene Zeichensätze, vor allem auch aus dem asiatischen Sprachraum, abgedeckt werden, gibt es zu UNICODE aber wohl keine Alternative.
Wenn nicht alle Daten in UNICODE gespeichert werden sollen, bietet Oracle mit dem NCHAR-Datentyp ab Oracle 9i die Möglichkeit, nur ausgewählte Daten als UNICODE zu speichern.
Wenn nur bestimmte Spalten UNICODE als Character Set benötigen, können diese Spalten mit ALTER TABLE MODIFY COLUMN von CHAR auf NCHAR geändert werden. Das wäre ein sinnvoller Kompromiss zwischen Performance und Breite der Darstellungsmöglichkeiten.
Mit dem Character Set Scanner (CSSCAN) liefert Oracle ein Programm, mit dessen Hilfe die Auswirkungen einer Änderung des Character Sets einer Datenbank prognostiziert werden können.
CSSCAN bietet die Möglichkeiten, die komplette Datenbank, ein Schema oder einzelne Tabellen zu scannen.
Der Scanner liest für den vorgegebenen Bereich alle Daten mit der Eigenschaft "character" und testet jede Datenzeile auf die folgenden Bedingungen:
Die jeweils neueste Version von CSSCAN kann im Oracle technet für die entsprechende Plattform heruntergeladen werden.
CSSCAN benötigt das Schema CMIG in der Datenbank. Dafür liefert Oracle das Skript cminst.sql. Nach erfolgreichem Durchlaufen des Skriptes sind die Voraussetzungen für einen Einsatz von CSSCAN gegeben.
CSSCAN kann auf drei verschiedene Arten aufgerufen werden:
Der folgende Kommandozeilenaufruf testet die Tabelle books auf die Auswirkungen einer Migration von US7ASCII zu WE8ISO8859P15.
Wenn der Parameter fromchar nicht angegeben wird, wird als Default der Character Set der Datenbank angenommen:
csscan system/**** \ table=books \ fromchar=US7ASCII \ tochar=WE8ISO8859P15 \ array=40960 process=1
Das Character Set der Datenbank kann mit der Abfrage
SELECT * FROM sys.props$ WHERE name LIKE ‘NLS%’;
ausgelesen werden.
Die Ergebnisse der Simulation gibt Oracle in Dateien aus. Die wichtigsten Details enthält scan.txt:
[Scan Summary]
All character type application data remain the same in the new character set
Dieses Ergebnis bedeutet, dass durch die Migration des Character Sets keine Daten geändert werden. In diesem Fall sollte die Migration problemlos mit dem Kommando ALTER DATABASE CHARACTER SET durchgeführt werden können.
Gibt CSSCAN den folgenden Satz aus:
[Scan Summary]
Some character type application data are not convertible to the new character set
ist damit zu rechnen, dass es bei einer Migration des Character Sets zu Problemen kommen wird. Der CSSCAN teilt die Daten in 4 verschiedene Kategorien ein:
Daten, die durch die Migration nicht verändert werden, werden als Changeless (Daten ohne Veränderung) bezeichnet. Die binäre Repräsentation bleibt die gleiche. Das ist dann der Fall, wenn das alte Character Set hinsichtlich der vorhandenen Zeichen und den ihnen zugeordneten binären Werten Sub Set des neuen Character Sets ist. Das ist der ideale Ausgangspunkt einer Migration.
Convertible umfasst die Menge der Daten, für die es eine eindeutige Konvertierung gibt und die deshalb bei einer Migration erfolgreich konvertiert werden können. Convertible ist zum Beispiel der Buchstabe ‘A’, wenn er in US7ASCII mit 0x41 repräsentiert wird und nach der Migration in WE8EBCDIC37C mit 0xc1. Alle Zeichen des alten Character Sets sind auch im neuen enthalten, wenn auch nicht mit der gleichen Zuordnung der binären Werte: ein logisches Sub Set.
Truncation tritt dann auf, wenn nach der Migration die Spalte nicht breit genug ist, um die Daten der Zelle aufzunehmen. Etwa nach der Migration von einem Character Set mit Single Byte zu UNICODE, bei der sich die Zeichen von einem auf zwei oder mehr Byte ausdehnen. Hier muss eine Vergrößerung der Spalten vorgenommen werden, ansonsten gehen Daten verloren.
Die Länge der Datentypen VARCHAR2 und CHAR wird in Bytes angegeben, bei Multi Byte Character ist das nicht die Anzahl der Zeichen. Ändert sich durch die Veränderung die Länge eines Zeichens (siehe Abbildung 2), gehen in der Datenbank gespeicherte Werte mit ihrem Speicherbedarf über das hinaus, was der definierte Datentyp einer Tabelle gestattet.
Abb. 2: Größenveränderung von Zeichen.Stellt CSSCAN solche Probleme fest, müssen vor der Änderung des Character Sets die Spaltenbreiten für die betroffenen Bereiche verändert werden, da sonst ein Datenverlust eintritt. Ab Oracle 9i bestehen zwei alternative Möglichkeiten, die Längendefinition für eine Spalte zu definieren:
1. mit byte semantics, also einer festen Anzahl von Bytes, oder
2. dynamisch mit character semantics und damit einer Anzahl von Zeichen gleich welcher Länge.
tritt dann ein, wenn es keinen gleichen Buchstaben nach der Migration gibt. Kann ein Zeichen nicht ersetzt werden, tritt ein Default-Zeichen an seine Stelle. Nach der Migration ist es dann unmöglich, die verschiedenen, nicht konvertierten Zeichen aus einem Default-Character zu konvertieren.
Wenn CSSCAN diesen Fall meldet, ist eine manuelle Änderung in der Datenbank unumgänglich.
Aus diesem Grund sollte das Ziel-Character Set immer ein binäres oder logisches Super Set des Ausgangs-Character Sets sein. Andernfalls werden die im Ziel-Character Set nicht verfügbaren Zeichen von Oracle zu Ersatzzeichen konvertiert, etwa "?", "¿" o. ä. Aus diesem Grund empfiehlt Oracle immer wieder die Migration zu UNICODE, da UTF8 Super Set für die meisten gebräuchlichen Character Sets ist.
Gerade "historisch gewachsene" Oracle-Datenbanken sollten überprüft werden, ob das bei der Installation gewählte Character Set noch den Anforderungen entspricht. Das Werkzeug CSSCAN erlaubt es, durch Simulation mögliche Probleme einer Migration des Character Sets im Vorfeld zu erkennen.
Uwe Rübesamen (info@ordix.de).