Oracle Datenbank in UTF8?!

Computer: Software & Programmierung SQL & Datenbank - Programmierung
#1

Wir sind aktuell im Begriff, ein neues Projekt aufzuziehen und ein Kollege hat vorgeschlagen, gleich einen Oracle Server mit Unicode Support zu verwenden. Das hat bei mir einige Fragen aufgeworfen. Da wir mit Java arbeiten, dürfte Unicode hier kein Problem sein. Aber was bedeutet das für die Datenbank selbst?

1.) Jedes eingegebene Zeichen müsste nach meinem Verständnis 1,2,3 oder gar 4 Byte in der Datenbank belegen. Muss ich aus einem VARCHAR(20) dann einen VARCHAR(80) machen? Oder bleibt die Repräsentation nach aussen gleich, d.h. der VARCHAR(20) belegt Server-Intern jetzt einfach mehr Speicher?

2.) Wie funktioniert die Administration einer Unicode DB? In der Shell gibt es nur ASCII-Code, heisst das sqlplus versucht den internen Unicode dann auf die aktuelle Codepage abzubilden?

3.) Ändert sich für die Wartung einer solchen Datenbank etwas?

4.) Was muss man noch beachten?

Gruß Markus

#2

Wir sind aktuell im Begriff, ein neues Projekt aufzuziehen und
ein Kollege hat vorgeschlagen, gleich einen Oracle Server mit
Unicode Support zu verwenden. Das hat bei mir einige Fragen
aufgeworfen. Da wir mit Java arbeiten, dürfte Unicode hier
kein Problem sein. Aber was bedeutet das für die Datenbank
selbst?

1.) Jedes eingegebene Zeichen müsste nach meinem Verständnis
1,2,3 oder gar 4 Byte in der Datenbank belegen. Muss ich aus
einem VARCHAR(20) dann einen VARCHAR(80) machen? Oder bleibt
die Repräsentation nach aussen gleich, d.h. der VARCHAR(20)
belegt Server-Intern jetzt einfach mehr Speicher?

Du hast ganz recht, du musst die Länge entsprechend anpassen. Das kann dir übrigens schon dann passieren, wenn du nur die Codepage wechselst und Umlaute, also höhere ASCII Zeichen im Text hast.

2.) Wie funktioniert die Administration einer Unicode DB? In
der Shell gibt es nur ASCII-Code, heisst das sqlplus versucht
den internen Unicode dann auf die aktuelle Codepage
abzubilden?

Ja, das merkst Du gar nicht - fast jedenfalls. Bei der Ausgabe hat man sich ja eh schon an die paar kryptischen Zeichen gewöhnt, die die ÖÄÜ darstellen. Dem kann man Abhilfe schaffen, wenn man die richtige Codepage bei der Session angibt.

3.) Ändert sich für die Wartung einer solchen Datenbank etwas?

Nö.

4.) Was muss man noch beachten?

Mir fällt beim besten Willen nichts ein. Ausser, dass Du halt immer wieder Probleme beim IMPORT bekommen wirst, weil ein DMP aus einer DB nicht mit Deiner DB mehr kann. (Weil alle CHARACTER Felder jetzt Ihre Größe geändert haben.) Aber das passiert wie gesagt bereits beim einfachen Codepage-Wechsel.

Ach ja, es gibt eine Einstellung für Masochisten: Case-Sensitive Systemtabellen. So was hatte ich mal bei SQL-Server. Das war eine Sch…
Da musste man sogar bei den Tabellennamen die Codepage im Select mit angeben und Characters, die in jeder Codepage identisch sind transformieren. Dagegen hilft dann nur noch DROP DATABASE.

Gruß

Peter

Gruß Markus

#3

Frage zum CHARSET
@Peter: Danke für deine Tipps!

Nach intensivem Studium der Oracle Literatur stehe ich nun vor der schwierigen Entscheidung, den passenden Zeichensatz zu wählen. Ein Großteil der Daten wird im US-ASCII-Format vorliegen, d.h. Indizes und Keys werden hiermit gefüllt. Einige Meta-Daten sollen per NCHAR/NVARCHAR in entsprechenden Spalten verfügbar gemacht werden. Diese Spalten werden dann aber nicht indiziert.

Aus Performance-Gründen spricht ein 8-Bit Zeichensatz (UTF8 o. Latin1) für den Database CHARSET. Das spart in der Datenbank Platz und ist effektiver im Zugriff. Die NLS Typen erhalten als Charset den AL32UTF16 Charset.

Ich gehe nun davon aus, dass alle nicht NLS-Typen (also CHAR/VARCHAR) mit (US-)ASCII gefüllt werden. Demnach belegen UTF8 und Latin1 den gleichen Speicherplatz in der Datenbank. UTF8 kann mit Blick in die Zukunft auch NON-ASCII Zeichen aufnehmen. Spricht die Performance für/gegen UTF8? Welchen Charset würdet ihr in diesem Szenario wählen?

Gruß Markus

#4

Hallo, ich glaube nicht, dass du ein Performance Problem bekommen wirst, wenn Du einen längeren Zeichensatz verwendest. Der UNICODE wird doch eh auf die Codepage der Anzeige transformiert. Das einzige Problem, das ich kenne ist eben, dass man die Länge der CHARACTER-Felder beachten muß.

Ich sehe auch keinen Grund Unicode VARCHAR2-Felder nicht zu indizieren, wenn danach gesucht werden soll.

Gruß

peter

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#5

Hallo, ich glaube nicht, dass du ein Performance Problem
bekommen wirst, wenn Du einen längeren Zeichensatz verwendest.
Der UNICODE wird doch eh auf die Codepage der Anzeige
transformiert. Das einzige Problem, das ich kenne ist eben,
dass man die Länge der CHARACTER-Felder beachten muß.

Ich sehe auch keinen Grund Unicode VARCHAR2-Felder nicht zu
indizieren, wenn danach gesucht werden soll.

Aus der Oracle Dokumenation geht hervor, dass volle NLS Funktionalität (eben UTF16) sich negativ auf die Performance auswirkt. Ich erkläre mir das wie folgt:

a) Wenn die Datenbank intern mit Unicode arbeitet, dann wird jedes Zeichen im Database Charset abgelegt. UTF16 belegt min. zwei Byte, d.h. praktisch verdoppelt sich das Datenaufkommen im Tablespace. Zeitgleich passen auf einen Block weniger Datensätze, womit die Streuung über die Platte größer wird. Im Schnitt wird auf mehr Seiten zugegriffen, was also direkt i/o erzeugt.

b) Die Funktionen zum Vergleich von Zeichenketten sind aufwendiger, hatte ein ASCII String vorher eine interne Länge von 100 Zeichen, so sind es bei 100 Zeichen min. 200Byte. => mehr zu vergleichende Daten.

Laut dem NLS Guide gibt es viele Gründe, NCHAR oder NVARCHAR für den NLS Support zu verwenden. Oracle unterschiedet hierzu den Database Charset (default für alles) und den NLS-Charset (für die NCHAR-Typen)

Gruß Markus

#6

Hallo,

da hab ich auch mal wieder was dazugelernt.

Die meisten DB, mit denen ich zu tun habe, haben ganz andere Probleme als einen Faktor