Oracle und Unicode: Raus aus der 8-Bit-Welt
Shownotes
Oracle und Unicode: Raus aus der 8-Bit-Welt
Eine Zeichensatz-Migration ist ein Projekt, kein Schalter
Johannes steigt diesmal mit einer Frage aus aktuellem Anlass ein: Gibt es in Roberts Projekten noch Datenbanken mit einem Ein-Byte-Zeichensatz? Gibt es, und zwar reichlich. Datenbanken, die vor zwanzig Jahren aufgesetzt und seitdem immer wieder migriert wurden, ohne dass jemand den Zeichensatz angefasst hätte. Manche davon laufen bis heute mit WE8ISO8859P1, dem Zeichensatz ohne Eurozeichen. Johannes betreut gerade eine Unicode-Migration, die nach zwei Jahren noch nicht abgeschlossen ist, und will wissen, was dabei alles zu beachten ist.
Zunächst die Grundlagen: Oracle 6 und 7 wurden standardmäßig mit US7ASCII installiert, 7 Bit, 128 Zeichen. Das achte Bit wurde für Umlaute zweckentfremdet, war aber nicht supported. Danach kam die Zeit der standardisierten Ein-Byte-Zeichensätze: MSWIN1252 auf Windows, in der Oracle-Datenbank WE8ISO8859P1 ohne und WE8ISO8859P15 mit Eurozeichen. Westeuropa war damit abgedeckt, aber nur westeuropäisch: Das Gravis-Zeichen aus offiziellen Dokumenten fehlt im ISO-Zeichensatz, nordische Umlaute ebenso. Die Oracle-Datenbank kennt dazu einen zweiten Zeichensatz, den National Character Set für NCHAR, NVARCHAR und NCLOB. Johannes nennt ihn einen Exoten, der die Migration nur komplexer macht.
Der Standard für neue Datenbanken ist AL32UTF8, ein Zeichensatz mit variabler Breite von einem bis vier Byte pro Zeichen. A bis Z brauchen ein Byte, Umlaute zwei, das Eurozeichen drei. Damit beginnt das eigentliche Problem: VARCHAR2(50) bedeutet standardmäßig 50 Byte, nicht 50 Zeichen. Nach der Umstellung passen Namen mit Umlauten nicht mehr in die Spalte, und abgeschnittene Namen will niemand. Die Antwort heißt Längensemantik CHAR, also VARCHAR2(50 CHAR). Der Parameter NLS_LENGTH_SEMANTICS könnte das zum Default machen, Oracle rät aber davon ab, ihn auf Instanzebene zu setzen: Das Data Dictionary bleibt ein Ein-Byte-Zeichensatz, und beim Patchen muss der Parameter wieder zurückgedreht werden. Johannes' Empfehlung: von Anfang an mit CHAR-Semantik arbeiten und den Parameter per ALTER SESSION setzen.
Vor der Migration steht der Scan mit dem DMU, dem Database Migration Assistant for Unicode. Das kostenlose Tool von Oracle findet Sonderzeichen, Längenprobleme und Spalten am 4000-Byte-Limit von VARCHAR2, und zwar nicht auf der Produktion, sondern auf einem Backup oder einer Standby-Datenbank. Migriert wird dann per Export und Import in eine neue Datenbank mit AL32UTF8. Das dauert bei Terabyte-Datenbanken Stunden bis Tage und ist komplett offline. Die In-Place-Konvertierung hat Johannes noch nie gemacht, weil ihm Strukturänderungen auf Produktionsdaten zu gefährlich sind.
Robert bringt MAX_STRING_SIZE=EXTENDED ins Spiel, mit dem VARCHAR2 bis 32K groß werden darf. Der Pferdefuß: Ab etwa 4000 Byte speichert Oracle den Wert intern als LOB, also out of line, mit anderer Performance und einer Tabellengröße, die nicht mehr die ganze Wahrheit zeigt. Dazu kommt, dass CLOBs nach der Umstellung doppelt so groß werden, weil sie nicht in AL32UTF8, sondern in UCS-2 mit mindestens zwei Byte pro Zeichen gespeichert sind. Das kostet Platz, Buffer Cache und Performance und muss eingeplant werden. Ein Grund, bei 8 Bit zu bleiben, ist das trotzdem nicht: Java und praktisch alle Anwendungen setzen UTF-8 voraus.
Aus seinem laufenden Projekt berichtet Johannes, warum zwei Jahre vergehen können: viele abhängige Systeme und Datenbanken, die mit umgestellt werden müssen, und die Frage, wie sich die Downtime bei einer großen Datenbank reduzieren lässt. Der Kunde setzt eine Replikationslösung ein, die Änderungen während der Migrationsphase aus der alten in die neue Datenbank überträgt, GoldenGate oder Quest SharePlex. Eine eigene Folge zur Replikation ist damit ausgemacht. Zum Schluss der Klassiker falsch kodierter Altdaten: Ein Client, der der Datenbank sagt, sie brauche nicht zu konvertieren, speichert ein Ü als etwas völlig anderes ab und bekommt es auch so zurück. Garbage in, garbage out. Bei der Migration fällt das auf und muss in der Regel von Hand bereinigt werden. Das Fazit der beiden: 8-Bit-Datenbanken migrieren, neue Datenbanken nur noch mit AL32UTF8 anlegen, und die Umstellung als Projekt aufsetzen.
Diese Folge in der Übersicht:
- Viele gewachsene Datenbanken laufen noch mit Ein-Byte-Zeichensätzen wie WE8ISO8859P1 oder WE8ISO8859P15, weil nie Druck zur Umstellung bestand.
- Historie: US7ASCII bei Oracle 6 und 7, danach MSWIN1252 und die ISO-8859-Familie. Gravis und nordische Umlaute fehlen im westeuropäischen Repertoire.
- Der National Character Set für NCHAR, NVARCHAR und NCLOB ist ein Exot, der die Migration nur komplexer macht.
- AL32UTF8 ist der Standard für neue Datenbanken: ein bis vier Byte pro Zeichen, Umlaute zwei, Eurozeichen drei.
- VARCHAR2(50) bedeutet 50 Byte. Für Unicode braucht es die Längensemantik CHAR, also VARCHAR2(50 CHAR).
- NLS_LENGTH_SEMANTICS nicht auf Instanzebene setzen, sondern per ALTER SESSION: Das Data Dictionary bleibt Ein-Byte, beim Patchen muss der Parameter zurück.
- Der DMU (Database Migration Assistant for Unicode) scannt die Datenbank vorab, kostenlos und mit grafischer Oberfläche. Scan nur auf Kopie, Backup oder Standby.
- Standardweg: Export und Import in eine neue AL32UTF8-Datenbank, komplett offline, bei Terabyte-Datenbanken Stunden bis Tage.
- MAX_STRING_SIZE=EXTENDED erlaubt VARCHAR2 bis 32K, speichert ab etwa 4000 Byte aber intern als LOB.
- CLOBs werden nach der Umstellung doppelt so groß, weil sie in UCS-2 mit mindestens zwei Byte pro Zeichen abgelegt werden.
- Downtime reduzieren: Replikation mit GoldenGate oder Quest SharePlex während der Migrationsphase.
- Falsch kodierte Altdaten (Garbage in, garbage out) fallen erst bei der Migration auf und müssen meist von Hand bereinigt werden.
Weiterführende Links und Ressourcen:
- ora2know Website
- Oracle Database Migration Assistant for Unicode (DMU) (Download und Produktseite)
- DMU Dokumentation (Oracle Docs)
- Choosing a Character Set (Database Globalization Support Guide)
- NLS_LENGTH_SEMANTICS (Database Reference)
- MAX_STRING_SIZE (Database Reference)
- Oracle GoldenGate (Oracle)
- Quest SharePlex (Quest)
- Folge 1: Oracle Database 26ai ist da (Migration als Gelegenheit für den Zeichensatzwechsel)
- Folge 9: Oracle und JSON (JSON ist UTF-8, noch ein Grund für Unicode)
Nützliche Befehle:
-- Zeichensätze der Datenbank anzeigen SELECT parameter, value FROM nls_database_parameters WHERE parameter IN ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET', 'NLS_LENGTH_SEMANTICS');
-- Längensemantik CHAR für die aktuelle Session (nicht auf Instanzebene setzen) ALTER SESSION SET NLS_LENGTH_SEMANTICS = CHAR;
-- Spalte explizit mit Zeichensemantik anlegen CREATE TABLE kunden (name VARCHAR2(50 CHAR));
-- Byte- und Zeichenlänge eines Werts vergleichen SELECT name, LENGTH(name) AS zeichen, LENGTHB(name) AS bytes FROM kunden;
Die Podcast-Hosts und Director:
- Johannes Ahrends: Oracle ACE, DBA, ora2know. Web: carajandb.com
- Robert Marz: Oracle ACE, IT-Architect, ora2know. Web: robbie.databee.org
- Oliver Pyka: Oracle ACE, Freiberufler, ora2know. Web: pyka.de
Über O wie Datenbank:
Der deutschsprachige Oracle-Datenbank-Podcast von ora2know. Johannes Ahrends, Robert Marz und Oliver Pyka bringen zusammen über 90 Jahre Oracle-Erfahrung mit und sprechen an jedem ersten und dritten Dienstag im Monat über das, was DBAs, Entwickler und IT-Entscheider wirklich bewegt: Migration, Architektur, neue Features, Betrieb und Strategie rund um die Oracle Datenbank. Praxisnah, meinungsstark und ohne Marketing-Sprech.
Über ora2know:
Wissen teilen, Netzwerk aufbauen. ora2know ist eine unabhängige Community für Oracle-Datenbank-Administratoren und -Entwickler im deutschsprachigen Raum. Unser Ziel ist der praxisnahe Austausch von Wissen und Erfahrungen rund um Oracle Database, Oracle APEX und Oracle AI. Ohne kommerzielle Interessen, getragen von Enthusiasmus und gegenseitiger Hilfe. Ob DBA, Entwickler oder Architekt: ora2know verbindet Oracle-Profis in Deutschland, Österreich und der Schweiz.
Über diese Podcast-Produktion:
Diese Folge ist eine Eigenproduktion von ora2know.
Transkript anzeigen
00:00:00: O wie Datenbank, ein Oracle-Podcast von ora2know.
00:00:12: Johannes Ahrends: Aus aktuellem Anlass mal eine Frage.
00:00:14: Johannes Ahrends: Hast du eigentlich noch Projekte,
00:00:16: Johannes Ahrends: in denen die Datenbank mit einem Ein-Byte-Charakter-Set benutzt wird?
00:00:21: Robert Marz: Ei Gude, Johannes.
00:00:21: Robert Marz: Erstmal habe ich und zwar all die Datenbanken,
00:00:24: Robert Marz: die schon vor vielen Jahren aufgesetzt worden sind und über die Jahre immer wieder
00:00:28: Robert Marz: migriert wurden, weil vor 20 Jahren gab es noch gar keine UTF-8-Datenbanken.
00:00:34: Robert Marz: Ich habe sogar noch welche, die mit WE8ISO8859P1 gestartet sind.
00:00:39: Robert Marz: Das ist der Zeichensatz, der nicht mal das Euro zeichnen kann.
00:00:42: Johannes Ahrends: Das heißt in den 1990er Jahren so ungefähr.
00:00:46: Johannes Ahrends: Sie sind seitdem immer migriert worden und an dem Zeichensatz ist nichts
00:00:49: Johannes Ahrends: geändert worden oder wie sehe ich das?
00:00:51: Robert Marz: Richtig, da gibt es durchaus Datenbanken und wenn die Anforderungen nicht kamen,
00:00:55: Robert Marz: dann gab es ja auch keinen Druck zu migrieren.
00:00:58: Robert Marz: Und ich habe auch welche,
00:00:59: Robert Marz: da gab es schon Druck und dann haben man komische Workarounds gebaut.
00:01:02: Robert Marz: Aber ich glaube, deswegen fragst du mich nicht, oder?
00:01:05: Johannes Ahrends: Ne, es geht halt darum, dass ich gerade ein Projekt habe,
00:01:08: Johannes Ahrends: wo es um die Unicode-Migration geht und das ist ein doch sehr langfristiges
00:01:12: Johannes Ahrends: Projekt Und deshalb interessiert es mich,
00:01:14: Johannes Ahrends: was denn jetzt eigentlich alles dazu beachten gilt und was es da für Probleme
00:01:19: Johannes Ahrends: geben kann oder Herausforderungen.
00:01:21: Johannes Ahrends: Nennen wir sie lieber Herausforderungen.
00:01:24: Robert Marz: Bevor wir darüber reden, fangen wir da erstmal an,
00:01:26: Robert Marz: so ein bisschen die Basis zu schaffen.
00:01:28: Robert Marz: Was sind denn überhaupt diese Zeichensätze?
00:01:29: Robert Marz: Also als Oracle angefangen hat, das war zu Zeiten,
00:01:32: Robert Marz: bevor ich mich noch mit Datenbanken beschäftigt habe,
00:01:34: Robert Marz: war der Standard-Zeichensatz der US7ASCII-Zeichensatz.
00:01:38: Robert Marz: Oracle 6 und 7 wurde damals so standardmäßig damit installiert.
00:01:42: Robert Marz: Das heißt, da gab es einen 7-Bit-Zeichensatz, also 128 Zeichen maximal abbildbar.
00:01:46: Robert Marz: Das 8-Bit wurde dann immer schon mit Zweck entfremdet für so Umlaute,
00:01:50: Robert Marz: aber das war natürlich nicht supported.
00:01:52: Robert Marz: Und irgendwann hat man gesagt, okay, ein Byte, ein Zeichen.
00:01:56: Robert Marz: Man hat sich dann auf diese Standards gemacht und das war die große Zeit dieser
00:01:59: Robert Marz: standardisierten Zeichensätze wie MSWIN1252 oder in der Oracle Datenbank der WE8
00:02:07: Robert Marz: ISO 8859 P1.
00:02:09: Robert Marz: Das ist der ohne Eurozeichen und der WE8ISO8859P15, das ist der mit Eurozeichen.
00:02:15: Robert Marz: Der wurde dann so ein bisschen Standard und das war lange Zeit so.
00:02:18: Robert Marz: Und wenn man im Westeuropa unterwegs war, dafür steht ja das WE,
00:02:22: Robert Marz: hat man eigentlich alle Sonderzeichen drin gehabt.
00:02:25: Robert Marz: Nur halt eben manche nicht.
00:02:27: Johannes Ahrends: Genau, an der Stelle hake ich direkt mal ein, weil ganz wichtig ist,
00:02:31: Johannes Ahrends: es gibt so offizielle Dokumente und in diesen wird ein Gravis-Symbol
00:02:35: Johannes Ahrends: verwendet.
00:02:36: Johannes Ahrends: Das Gravis-Symbol ist so ein Hochkomma,
00:02:37: Johannes Ahrends: was nach links gekippt ist und das ist im ISO-Zeichensatz nicht drin.
00:02:44: Johannes Ahrends: Witzigerweise im Windows-Zeichensatz ist der enthalten.
00:02:47: Johannes Ahrends: Der ist nämlich von dem Umfang her etwas größer als der ISO-Zeichensatz.
00:02:53: Robert Marz: Es gibt ja auch noch mehr Zeichen.
00:02:55: Robert Marz: Also wenn man jetzt den westeuropäischen Raum ein bisschen verlässt oder schon,
00:02:58: Robert Marz: wenn man nur nach Norden geht bei uns und die nordischen Umlaute mithaben will,
00:03:02: Robert Marz: die sind da ja auch schon nicht mit drin.
00:03:04: Robert Marz: Also braucht man was anderes.
00:03:05: Robert Marz: Und dafür gibt es ja UTF-8 mittlerweile, richtig?
00:03:09: Johannes Ahrends: Ja, und nicht mal mittlerweile,
00:03:10: Johannes Ahrends: weil es gab halt schon länger einen zusätzlichen Zeichensatz.
00:03:14: Johannes Ahrends: Die Oracle-Datenbank kennt zwei Zeichensätze.
00:03:16: Johannes Ahrends: Das eine ist der normale Zeichensatz, mit dem die Datenbank angelegt ist.
00:03:20: Johannes Ahrends: Und der zweite ist der sogenannte National Language Character Set,
00:03:23: Johannes Ahrends: wobei das etwas unverständlich ist,
00:03:26: Johannes Ahrends: warum das denn National Language ist und der andere nicht.
00:03:29: Johannes Ahrends: Sei es drum.
00:03:30: Johannes Ahrends: Das ist ein zweiter Zeichensatz, den man verwenden kann,
00:03:33: Johannes Ahrends: wenn man statt dem Datentyp CHAR oder VARCHAR oder VARCHAR2 oder CLOB das N davor
00:03:38: Johannes Ahrends: setzt.
00:03:40: Johannes Ahrends: Das heißt also NCHAR, NVARCHAR oder NCLOB.
00:03:44: Johannes Ahrends: Und das bedeutet, dass man schon in der Datenbank,
00:03:47: Johannes Ahrends: die eigentlich ein Ein-Byte-Character-Set ist, Daten mit 2,
00:03:49: Johannes Ahrends: 3 oder 4 Byte unterbringen kann.
00:03:53: Johannes Ahrends: Aber es ist einfach ein Exot und wenig verbreitet, Gott sei Dank,
00:03:58: Johannes Ahrends: weil die Migration dann wird dann noch um einiges komplexer.
00:04:02: Robert Marz: Das habe ich technisch tatsächlich so ein bisschen übersprungen.
00:04:04: Robert Marz: Was ich kenne und was ja heute mittlerweile auch Standard ist,
00:04:07: Robert Marz: wenn man eine neue Datenbank anlegt, das ist dieser AL32UTF8-Zeichensatz.
00:04:11: Robert Marz: Der hat so ein bisschen komischen Namen,
00:04:12: Robert Marz: da checken die Leute auch ein bisschen vor zurück,
00:04:14: Robert Marz: weil das UTF8 nur so kurz drin vorkommt.
00:04:16: Robert Marz: Aber das ist der Standardzeichensatz, mit dem wir arbeiten,
00:04:19: Robert Marz: mit dem der alles kann, richtig?
00:04:22: Johannes Ahrends: Genau, das ist der Zeichensatz, den man einstellen sollte.
00:04:25: Johannes Ahrends: Das heißt, wenn man heute eine neue Datenbank aufsetzt,
00:04:27: Johannes Ahrends: dann gibt es eigentlich nichts anderes,
00:04:29: Johannes Ahrends: als dass man diesen Zeichensatz verwendet.
00:04:32: Robert Marz: Und der ist ein sogenannter Zeichensatz mit variabler Breite.
00:04:36: Robert Marz: Das heißt,
00:04:36: Robert Marz: ich kann ein bis vier Byte pro Zeichen belegen oder er entscheidet das selbst,
00:04:41: Robert Marz: die Datenbank entscheidet das selbst.
00:04:43: Robert Marz: Also so die Standardbuchstaben A bis Z haben ein Byte und das Eurozeichen hat,
00:04:49: Robert Marz: glaube ich, drei und ein Beispiel für zwei Bytes fällt mir gerade nicht ein.
00:04:53: Robert Marz: Hast du eins?
00:04:53: Johannes Ahrends: Umlaut.
00:04:54: Johannes Ahrends: Die ganzen Umlaute, die sind bei 2 Byte groß.
00:04:57: Robert Marz: Okay.
00:04:58: Robert Marz: Aber da hört man ja auch schon von der Idee her,
00:05:01: Robert Marz: wenn ich jetzt eine Tabellenspalte habe, die mit VARCHAR2(50) angelegt ist,
00:05:05: Robert Marz: mit was speichert die Datenbank denn dann ab?
00:05:07: Robert Marz: Mit Byte-Breite oder mit Zeichensbreite?
00:05:09: Robert Marz: Wo ist der Default?
00:05:11: Robert Marz: Das
00:05:13: Johannes Ahrends: Genau, das ist leider so, dass der Default immer noch Byte sind.
00:05:17: Johannes Ahrends: Das heißt, eine Definition VARCHAR2(50) bedeutet VARCHAR2(50) 50 Byte.
00:05:22: Johannes Ahrends: Und wenn ich da tatsächlich in Unicode 50 Zeichen drin unterbringen möchte,
00:05:26: Johannes Ahrends: dann reicht das in der Regel nicht aus,
00:05:28: Johannes Ahrends: denn schon ein Umlaut oder ein ß oder was auch immer für ein Zeichen würde
00:05:33: Johannes Ahrends: das gegebenenfalls schon sprengen.
00:05:34: Robert Marz: klingt so, als wenn ich also eine Datenbank migrieren möchte und ich glaube,
00:05:37: Robert Marz: das ist der Grund,
00:05:38: Robert Marz: warum viele Kunden davor zurückstrecken oder warum das ein richtiges Projekt ist.
00:05:42: Robert Marz: Dann muss ich mir das ganz genau angucken,
00:05:44: Robert Marz: dass alle meine Strings noch in meine Tabellen reinpassen nach der Migration,
00:05:49: Robert Marz: oder?
00:05:49: Johannes Ahrends: Ja, entweder das oder ich lasse es zu, dass die Wörter abgeschnitten werden,
00:05:52: Johannes Ahrends: wobei ich glaube, die Leute, deren Namen dann bei 50 Byte aufhört,
00:05:56: Johannes Ahrends: die finden das nicht so spannend.
00:05:58: Johannes Ahrends: Deshalb ist in der Realität natürlich so,
00:06:00: Johannes Ahrends: dass dann die Umstellung auf 50 Zeichen gegeben ist und das ist ein etwas
00:06:07: Johannes Ahrends: größeres Unterfangen.
00:06:08: Johannes Ahrends: Das ist etwas, was man wirklich als Projekt machen muss,
00:06:11: Johannes Ahrends: wo man halt nicht unbedingt einen Schalter umlegen kann,
00:06:13: Johannes Ahrends: obwohl es halt Tools gibt dafür, die behaupten, sie könnten das,
00:06:17: Johannes Ahrends: würde ich das nicht einfach so hinnehmen und einmal mal lax sagen, ach,
00:06:21: Johannes Ahrends: ich schalte mal um auf Unicode.
00:06:23: Johannes Ahrends: Das würde schief gehen, denke ich mal.
00:06:24: Johannes Ahrends: Oder wie siehst du das?
00:06:26: Robert Marz: Also ich denke auch,
00:06:27: Robert Marz: das ist auf jeden Fall ein Projekt und du hast ja auch gerade gesagt,
00:06:29: Robert Marz: du hast selber auch gerade aktuell ein größeres Projekt am Laufen.
00:06:32: Robert Marz: Wenn ich das in-place machen möchte, gibt es denn da Tools,
00:06:34: Robert Marz: mit denen ich mir das angucke oder was sind denn die idealen oder die bevorzugten
00:06:38: Robert Marz: Wege?
00:06:39: Robert Marz: Was empfiehlst du deinen Kunden für kleine, mittlere und große Datenbanken?
00:06:43: Johannes Ahrends: Also ohne Frage als allererstes den Database Migration Assistant for Unicode.
00:06:48: Johannes Ahrends: Das ist ein kleines Tool von Oracle,
00:06:49: Johannes Ahrends: kostet auch noch nicht mal was und damit kann ich die Datenbank durchscannen
00:06:53: Johannes Ahrends: nach besonderen Zeichen,
00:06:56: Johannes Ahrends: nach den genannten Längensemantik oder auch nach der maximalen Größe eines
00:07:02: Johannes Ahrends: VARCHAR2.
00:07:02: Johannes Ahrends: Denn was wir gerade noch verschwiegen haben,
00:07:05: Johannes Ahrends: ist ein VARCHAR2 hat eine maximale Länge von 4000 Byte.
00:07:11: Johannes Ahrends: Das heißt, wenn ich dort Texte eingebe, dann enden die nach 4000 Byte.
00:07:15: Johannes Ahrends: Da beißt die Maus keinen Faden ab,
00:07:16: Johannes Ahrends: da kann ich 4000 CHAR hinschreiben oder nicht.
00:07:18: Johannes Ahrends: Das bringt dann überhaupt nichts.
00:07:20: Johannes Ahrends: Und dieser DMU,
00:07:21: Johannes Ahrends: der scannt meine Datenbank und gibt mir dann ein Ergebnis und gegebenenfalls
00:07:26: Johannes Ahrends: kann er die Datenbank migrieren.
00:07:28: Robert Marz: Der DMU, das ist das offizielle Werkzeug von Oracle.
00:07:30: Robert Marz: Liefert das die Datenbank standardmäßig mit oder muss ich das extra runterladen?
00:07:34: Johannes Ahrends: Das kann ich extra runterladen, wird auch immer wieder aktualisiert.
00:07:38: Johannes Ahrends: Aber im Endeffekt ein relativ überschaubarer Aufwand und die grafische
00:07:43: Johannes Ahrends: Oberfläche, mit dem das Teil kommt, ist eigentlich ganz gut.
00:07:45: Johannes Ahrends: Man kann sich dann entsprechend ansehen, wo es Handlungsbedarf gibt.
00:07:50: Robert Marz: Wie ist jetzt das Standardvorgehen?
00:07:51: Robert Marz: Also migriere ich meine Datenbank oder lege ich sie neu an und mache einen
00:07:55: Robert Marz: Export-Import?
00:07:57: Johannes Ahrends: Wenn ich das mache, dann migriere ich die Datenbank,
00:08:00: Johannes Ahrends: indem ich einen Export-Import mache.
00:08:01: Johannes Ahrends: Das heißt, ich lege eine neue Datenbank an mit dem neuen Zeichensatz.
00:08:05: Johannes Ahrends: Dann lade ich alle Tabellen rein in die neue Datenbank.
00:08:10: Johannes Ahrends: Und dann nach einigen wenigen Stunden oder mehreren Tagen sollte dann die
00:08:15: Johannes Ahrends: ganze Datenbank wieder laufen.
00:08:16: Johannes Ahrends: Und genau das ist im Endeffekt auch eins der Probleme bei der ganzen
00:08:20: Johannes Ahrends: Geschichte.
00:08:20: Johannes Ahrends: Das Ganze ist immer offline.
00:08:22: Johannes Ahrends: Das heißt,
00:08:23: Johannes Ahrends: während der Änderung kann ich die Datenbank nicht nutzen und das bedeutet
00:08:27: Johannes Ahrends: gegebenenfalls mehrere Tage Downtime und das können sich viele Unternehmen
00:08:31: Johannes Ahrends: einfach nicht leisten.
00:08:32: Robert Marz: Gibt es da noch einen anderen Weg mit dem In-Place-Migration oder dauert das
00:08:35: Robert Marz: genauso lang?
00:08:36: Johannes Ahrends: Das mit der In-Place-Migration habe ich noch nie gemacht,
00:08:38: Johannes Ahrends: weil es mir einfach immer zu gefährlich ist.
00:08:40: Johannes Ahrends: Schon gerade,
00:08:41: Johannes Ahrends: wenn ich auf die Produktionsdaten gehe und da irgendwelche Strukturen
00:08:44: Johannes Ahrends: anpasse, dann würde ich immer versuchen, sowas zu vermeiden.
00:08:49: Johannes Ahrends: Das heißt, auch diesen DMU-Scan,
00:08:51: Johannes Ahrends: den lasse ich in der Regel nicht auf Produktionsdaten los,
00:08:54: Johannes Ahrends: sondern ich habe hoffentlich irgendwo ein Backup liegen oder eine
00:08:57: Johannes Ahrends: Standby-Datenbank oder irgendwas anderes,
00:08:58: Johannes Ahrends: sodass ich mir das in einem Sandkasten angucken kann, wie das läuft,
00:09:05: Johannes Ahrends: um dann tatsächlich die Produktion umzustellen.
00:09:09: Robert Marz: Jetzt haben wir ja vorhin schon mal darüber geredet,
00:09:10: Robert Marz: die Datenbank kennt zwei Wege oder zwei Definitionsarten,
00:09:14: Robert Marz: Spaltenbreiten anzulegen, nämlich im Character und Byte.
00:09:18: Robert Marz: Wo ist da der Unterschied und was empfiehlst du, was man da einstellt?
00:09:22: Johannes Ahrends: Also das, was wir vorhin gesagt haben, ist,
00:09:24: Johannes Ahrends: wir haben ein VARCHAR2(50) und ein VARCHAR2(50) sind 50 Byte.
00:09:29: Johannes Ahrends: Bei einem Ein-Byte-Character-Set ist das logisch das gleiche Byte und
00:09:32: Johannes Ahrends: Charakter.
00:09:32: Johannes Ahrends: Wenn ich ein Multi-Byte-Character-Set habe,
00:09:34: Johannes Ahrends: dann ist das logischerweise ein Unterschied und das bedeutet,
00:09:36: Johannes Ahrends: dass ich als Zeichensemantik CHAR verwende.
00:09:42: Johannes Ahrends: Das ist auch etwas,
00:09:43: Johannes Ahrends: wo man mit den Unternehmen erstmal ein bisschen diskutieren muss oft,
00:09:47: Johannes Ahrends: weil die sagen, ja nee, wir verwenden VARCHAR. Und ich sage, nein,
00:09:51: Johannes Ahrends: das ist nicht der Datentyp CHAR, sondern die Längensemantik CHAR,
00:09:54: Johannes Ahrends: was sich genauso schreibt, wo es dann aber heißt,
00:09:57: Johannes Ahrends: der Datentyp ist dann zum Beispiel VARCHAR2, Klammer auf, 20 CHAR, Klammer zu.
00:10:05: Johannes Ahrends: Das ist die sogenannte Längen-Semantik,
00:10:07: Johannes Ahrends: die ist Default-mäßig auf Byte und die kann ich dann, wenn ich will,
00:10:11: Johannes Ahrends: auf Character umschalten.
00:10:12: Johannes Ahrends: Muss das aber bewusst tun, weil wie gesagt, der Default ist Byte.
00:10:19: Robert Marz: Wenn ich jetzt heute eine Tabelle anlege und sage oder auch eine PL/SQL-Variable
00:10:22: Robert Marz: verwende und die deklariere als Spaltenname VARCHAR2(50),
00:10:27: Robert Marz: dann habe ich eigentlich die Syntax nicht voll ausgeschrieben,
00:10:29: Robert Marz: sondern ich müsste eigentlich VARCHAR2(50 BYTE) oder VARCHAR2(50 CHAR) hinschreiben und
00:10:34: Robert Marz: dann sorgt die Datenbank dafür,
00:10:36: Robert Marz: dass da entweder 50 Byte reinpassen oder 50 Zeichen und im schlimmsten Fall halt
00:10:41: Robert Marz: 200 Bytes rein, wenn ich 50 4-Byte-Umlaute da reinschreiben möchte, richtig?
00:10:47: Johannes Ahrends: Genau so ist es.
00:10:48: Johannes Ahrends: Das heißt also an der Stelle, ich verstehe Oracle auch nicht ganz,
00:10:51: Johannes Ahrends: warum man überhaupt noch die Byte-Semantik verwendet.
00:10:54: Johannes Ahrends: Weil, wie gesagt, wenn ich ein Ein-Byte-Character-Set habe,
00:10:56: Johannes Ahrends: dann ist Byte und Characters sowieso das Gleiche.
00:10:59: Johannes Ahrends: Bei einem Multi-Byte, was alle machen sollten,
00:11:01: Johannes Ahrends: weil das auch der mittlerweile Default ist für die Erstellung einer
00:11:04: Johannes Ahrends: Datenbank, sind es halt mehrere Byte.
00:11:07: Johannes Ahrends: Und insofern hat für mich eigentlich diese Byte-Längen-Semantik ausgedient.
00:11:13: Johannes Ahrends: Die sollte man überhaupt nicht mehr verwenden.
00:11:15: Johannes Ahrends: und dafür gibt es, naja, einen Parameter,
00:11:20: Johannes Ahrends: der nennt sich NLS_LENGTH_SEMANTICS und den könnte man so schön auf K
00:11:23: Johannes Ahrends: stellen und die Welt wäre in Ordnung und Oracle sagt,
00:11:25: Johannes Ahrends: bitte nicht als Parameter umstellen, wenn, dann nur auf Session-Ebene ändern.
00:11:31: Robert Marz: Warum sagen die das?
00:11:33: Johannes Ahrends: Weil es das Data-Dictionary gibt und dieses Data-Dictionary weiß immer noch
00:11:38: Johannes Ahrends: nicht, dass es ein Multi-Byte-Character-Set gibt und das bedeutet,
00:11:40: Johannes Ahrends: das Data-Dictionary ist immer ein Ein-Byte-Character-Set und mit dieser
00:11:42: Johannes Ahrends: Längen-Semantik auf CHAR zu setzen,
00:11:44: Johannes Ahrends: würde gegebenenfalls das Dictionary korrumpiert.
00:11:53: Robert Marz: Das ist ein Parameter,
00:11:54: Robert Marz: mit dem ich im schlimmsten Fall die Datenbank kaputt machen kann.
00:11:56: Robert Marz: Das klingt aber jetzt nicht so toll, oder?
00:11:58: Johannes Ahrends: Ja, ich sage mal so, ganz so schlimm ist es nicht.
00:12:00: Johannes Ahrends: Wenn man darauf aufpasst, dass man beim Patchen den wieder zurückdreht,
00:12:04: Johannes Ahrends: dann kann man den durchaus nutzen.
00:12:06: Johannes Ahrends: Ich würde aber eher empfehlen zu sagen,
00:12:08: Johannes Ahrends: dass man von Anfang an mit einer Längen-Semantik arbeitet,
00:12:11: Johannes Ahrends: sich das angewöhnt und entsprechend mit einem Alter Session oder sowas dieses
00:12:16: Johannes Ahrends: NLS_LENGTH_SEMANTICS vorhersetzt.
00:12:19: Johannes Ahrends: Aber das ist eigentlich auch erst der Anfang des ganzen Spektakels,
00:12:24: Johannes Ahrends: kann man es wirklich nennen, weil das Projekt, was ich gerade betreue,
00:12:27: Johannes Ahrends: hat vor zwei Jahren angefangen,
00:12:28: Johannes Ahrends: wir sind mit der Datenbank immer noch nicht fertig.
00:12:31: Johannes Ahrends: Ich muss halt darauf achten, ich habe die richtige Längen-Semantik,
00:12:34: Johannes Ahrends: dann muss ich darauf achten,
00:12:36: Johannes Ahrends: diese 4000 Byte bei VARCHAR2-Feldern dann ist halt im Beton gegossen und das
00:12:42: Johannes Ahrends: bedeutet gegebenenfalls auch da eine Umstellung.
00:12:46: Robert Marz: Aber im Beton gegossen ist die ja seit den neueren Datenbank-Versionen schon nicht
00:12:50: Robert Marz: mehr.
00:12:50: Robert Marz: Ich kann ja schon seit mindestens Oracle 19 sagen,
00:12:52: Robert Marz: MAX_STRING_SIZE=EXTENDED und dann kriege ich 32K maximale Watt-Chart 2
00:12:56: Robert Marz: Längenfelder, richtig?
00:12:58: Johannes Ahrends: Genau, so ist es.
00:12:59: Johannes Ahrends: Das ist eben eine Erweiterung,
00:13:00: Johannes Ahrends: die Oracle mittlerweile Gott sei Dank gemacht hat, auch im Hinblick darauf,
00:13:04: Johannes Ahrends: dass PL/SQL schon lange einen VARCHAR2 von 32K kennt.
00:13:08: Johannes Ahrends: Kennt jetzt die Datenbank, wenn ich es möchte, das heißt,
00:13:11: Johannes Ahrends: wenn ich die Datenbank upgrade,
00:13:13: Johannes Ahrends: einen Extended String Size (MAX_STRING_SIZE=EXTENDED) und dann kriege ich zwar tatsächlich in einem
00:13:17: Johannes Ahrends: VARCHAR2 32K Byte unter.
00:13:20: Robert Marz: Hat das noch irgendwelche anderen Konsequenzen?
00:13:22: Robert Marz: Das klingt ja eigentlich erstmal so, als ob das eine total gute Idee ist,
00:13:25: Robert Marz: das zu setzen, oder?
00:13:26: Johannes Ahrends: Ja,
00:13:27: Johannes Ahrends: es hat aber auch einen leichten Pferdefuß und zwar bin ich ganz sicher auf
00:13:31: Johannes Ahrends: welche Größenordnung,
00:13:32: Johannes Ahrends: aber ab etwa 4010 Byte etwa schwenkt Oracle um und macht aus dem VARCHAR2
00:13:39: Johannes Ahrends: intern ein BLOB-Feld.
00:13:41: Johannes Ahrends: Es wird komplett anders gespeichert,
00:13:42: Johannes Ahrends: die ganze Speicherarchitektur ist anders als im Default.
00:13:47: Robert Marz: Das heißt, ich habe einen Parameter, den ich verwenden kann, der dafür sorgt,
00:13:50: Robert Marz: dass der Default beim Tabellenanlegen in Richtung CHAR geht, anstelle von Byte.
00:13:55: Robert Marz: Den sollte ich aber nicht in der Datenbank-Ebene setzen,
00:13:58: Robert Marz: sondern auf Session-Ebene,
00:13:58: Robert Marz: damit ich beim Patchen oder vor dem Patchen zurücksetze, so zusammengefasst.
00:14:03: Robert Marz: Ich habe immer noch das 4000-Zeichen-Problem, das heißt,
00:14:05: Robert Marz: wenn ich VARCHAR2(4000 BYTE) habe, kriege ich da immer nur 4000 Byte rein.
00:14:10: Robert Marz: Es sei denn, ich setze NLS_LENGTH_SEMANTICS und da muss ich aber aufpassen,
00:14:13: Robert Marz: wenn die Dinger zu lang werden,
00:14:14: Robert Marz: dann habe ich auf einmal meine Werte nicht mehr inline gespeichert,
00:14:18: Robert Marz: sondern out of line und habe dann andere Performance-Probleme potenziell.
00:14:23: Johannes Ahrends: Ja genau und außerdem sehe ich die Größe der Tabelle nicht mehr richtig,
00:14:26: Johannes Ahrends: weil ja B-Lob,
00:14:27: Johannes Ahrends: CLOB an einem besonderen Ort gespeichert werden und in der Tabellengröße
00:14:32: Johannes Ahrends: nicht sichtbar sind.
00:14:34: Johannes Ahrends: Ja und es gibt also noch weitere Pferdefüße oder ein ganz wichtiger,
00:14:38: Johannes Ahrends: wenn ich auf den Unicode-Zeichensatz umstelle,
00:14:40: Johannes Ahrends: dann wird ein CLOB plötzlich doppelt so groß.
00:14:44: Robert Marz: Das habe ich auch schon mal gehört, nie wirklich verstanden, warum es so ist,
00:14:47: Robert Marz: aber dessen muss ich mir bewusst sein.
00:14:49: Robert Marz: Das heißt,
00:14:50: Robert Marz: alle meine CLOB-Spalten sind auf einmal doppelt so groß und Platz verbraucht.
00:14:54: Robert Marz: Ich muss also entsprechend Platz auf meiner Festplatte einplanen dafür, richtig?
00:14:57: Robert Marz: Warum ist das so, dass CLOBs doppelt so lang sind?
00:15:02: Johannes Ahrends: Der Grund dafür ist, dass ein CLOB nicht in AL32UTF8 gespeichert wird,
00:15:07: Johannes Ahrends: sondern in einem Zeichensatz,
00:15:09: Johannes Ahrends: der nennt sich UCS2 und der speichert mindestens zwei Byte ab.
00:15:15: Johannes Ahrends: Das heißt, alle normalen Zeichen,
00:15:17: Johannes Ahrends: die in ein ASCII-Zeichen unterzubringen wären,
00:15:21: Johannes Ahrends: werden jetzt auf einmal zwei Byte groß und das bedeutet gegebenenfalls,
00:15:25: Johannes Ahrends: dass mein CLOB-Feld doppelt so groß ist wie vorher.
00:15:28: Johannes Ahrends: Das bedeutet Performance-Probleme in der Datenbank,
00:15:31: Johannes Ahrends: mehr Platz für die Speicherung, weniger Buffer-Cache,
00:15:34: Johannes Ahrends: weil das alles entsprechend davon betroffen ist.
00:15:37: Johannes Ahrends: Deshalb muss man sich bei solchen Datenbanken sehr vorsichtigen,
00:15:40: Johannes Ahrends: dass man genügend Speicherplatz dafür allokiert.
00:15:44: Robert Marz: Hält uns das jetzt davon ab, auf UTF-8 zu migrieren?
00:15:47: Robert Marz: Oder sind das einfach nur Sachen, mit denen wir umgehen müssen?
00:15:49: Johannes Ahrends: Das sind Sachen, mit denen wir umgehen müssen,
00:15:51: Johannes Ahrends: weil auf etwas anderes als UTF-8 würde ich heute nicht mehr setzen.
00:15:55: Johannes Ahrends: Das heißt, alles, was wir haben in dem Umfeld, ob es Java ist,
00:15:58: Johannes Ahrends: ob Applikationen sonstiger Art sind,
00:16:01: Johannes Ahrends: das basiert alles auf UTF-8 und ich würde mir damit wirklich keinen Gefallen
00:16:05: Johannes Ahrends: tun, wenn ich das nicht einsetze.
00:16:07: Robert Marz: Okay, Johannes, du sagst ja, du bist gerade mitten in einem Projekt drin.
00:16:10: Robert Marz: Gab es da jetzt spannende Herausforderungen, die du uns erzählen möchtest?
00:16:14: Johannes Ahrends: Ja,
00:16:15: Johannes Ahrends: das Projekt dauert jetzt schon zwei Jahre und es wird wahrscheinlich im Ende
00:16:18: Johannes Ahrends: nächsten Jahres entsprechend fertig werden.
00:16:20: Johannes Ahrends: Der Grund dafür ist auch, dass es a, viele abhängige Systeme gibt,
00:16:25: Johannes Ahrends: viele abhängige Datenbanken,
00:16:26: Johannes Ahrends: die logischerweise auch mit umgestellt werden müssen.
00:16:28: Johannes Ahrends: Und B ist es die Frage bei einer großen Datenbank,
00:16:32: Johannes Ahrends: wie reduziere ich die Downtime?
00:16:34: Johannes Ahrends: Weil wie schon gesagt, wenn ich einen Export mache und einen Import mache,
00:16:39: Johannes Ahrends: dann kann das durchaus Tage dauern bei Datenbanken mit Terabyte Größe und das
00:16:43: Johannes Ahrends: möchte ich reduzieren.
00:16:44: Johannes Ahrends: Der Kunde macht das insofern, dass er eine Replikationslösung einsetzt,
00:16:48: Johannes Ahrends: die ihm die Daten, die geändert werden,
00:16:50: Johannes Ahrends: während der Migrationsphase aus der alten Datenbank in die neue überträgt.
00:16:55: Johannes Ahrends: Dafür kann man zum Beispiel sowas wie GoldenGate einsetzen oder mein
00:16:58: Johannes Ahrends: Lieblingsprodukt Quest SharePlex.
00:17:00: Johannes Ahrends: Das sind so die Größten, die in diesem Umfeld von sich reden machen,
00:17:05: Johannes Ahrends: wenn es darum geht, eine Unterstützung zu handeln.
00:17:08: Johannes Ahrends: Nichtsdestotrotz, das Ganze erfordert viel,
00:17:11: Johannes Ahrends: viel Arbeit und ist ein sehr umfangreiches Projekt.
00:17:14: Johannes Ahrends: Deshalb würde ich das nicht auf die leichte Schulter nehmen.
00:17:16: Robert Marz: Und das klingt für mich,
00:17:17: Robert Marz: als ob wir über diese Replikationsgeschichten auf jeden Fall mal eigene Folgen
00:17:21: Robert Marz: machen müssten, oder?
00:17:23: Johannes Ahrends: Ja, auf jeden Fall.
00:17:23: Johannes Ahrends: Eine kleine Randbemerkung noch.
00:17:26: Johannes Ahrends: Es gibt nämlich noch einen Punkt, was ich immer wieder feststelle,
00:17:30: Johannes Ahrends: wenn es darum geht, eine Unicode-Umstellung zu machen, sind Daten,
00:17:33: Johannes Ahrends: die von vornherein falsch waren.
00:17:36: Johannes Ahrends: Das heißt also, jemand hat ein Ü in der Datenbank gespeichert,
00:17:39: Johannes Ahrends: hat das Ü auch wieder rausgekriegt, als er sich angesehen hat,
00:17:42: Johannes Ahrends: Nur in der Datenbank wurde was völlig anderes gespeichert.
00:17:45: Robert Marz: Wie kann denn das passieren?
00:17:46: Johannes Ahrends: Naja, indem ich einfach der Datenbank sage, ach,
00:17:48: Johannes Ahrends: du brauchst gar nicht konvertieren, ich gebe dir das Zeichen so,
00:17:51: Johannes Ahrends: wie du es brauchst.
00:17:51: Johannes Ahrends: Und dann sagt die Datenbank, ja gut, dann gibt man mir so einen Hex-Code her,
00:17:55: Johannes Ahrends: speichert das ab und der Client kriegt das auch so zurück.
00:17:58: Johannes Ahrends: An der Stelle habe ich dann das Problem Garbage in, Garbage out.
00:18:02: Robert Marz: Diese Fälle muss ich aber dann immer von Hand konvertieren.
00:18:04: Robert Marz: Dann muss ich mir selber Konvertierungsprogramme schreiben, oder?
00:18:06: Robert Marz: oder?
00:18:07: Johannes Ahrends: Ich habe tatsächlich mal eine Datenbank gehabt,
00:18:09: Johannes Ahrends: die drei verschiedene Zeichensätze hat und wir haben es geschafft,
00:18:12: Johannes Ahrends: die Exports so hinzukriegen, dass wir die Zeichen richtig exportiert haben.
00:18:15: Johannes Ahrends: Das ist aber dann nochmal eine zusätzliche Aufgabe.
00:18:19: Johannes Ahrends: Das heißt, ja, in der Regel wirst du das manuell anpassen müssen.
00:18:23: Robert Marz: Ich glaube, wir haben heute richtig viel gelernt.
00:18:25: Robert Marz: Wir sind uns einig, 8-Bit-Datenbanken sollte man migrieren,
00:18:28: Robert Marz: wenn der Bedarf besteht.
00:18:29: Robert Marz: Und neue Datenbanken setzen wir sowieso alle nur noch in UTF-8 auf.
00:18:32: Robert Marz: Johannes, möchtest du uns noch was sagen?
00:18:35: Johannes Ahrends: Mehr kann ich auch nicht dazu sagen.
00:18:37: Johannes Ahrends: Insofern kann ich nur dazu plädieren,
00:18:39: Johannes Ahrends: dass ihr das als Projekt macht und entsprechend nicht auf die leichte
00:18:43: Johannes Ahrends: Schulter nehmt.
00:18:54: Robert Marz: Tschüss!
Neuer Kommentar