Wie die Unicode-Migration einer Oracle-DB gelingt

© joingate, 123RF

Ausweg aus Babylon

Die Globalisierung bringt es mit sich, dass der Mitarbeiter in Japan dieselbe Datenbank befüllt wie sein Kollege in Berlin. Voraussetzung ist ein Zeichensatz wie Unicode, der alle sinnvollen Zeichen der Welt beinhaltet. Worauf bei der Umstellung einer Oracle Datenbank auf Unicode zu achten ist und wo Fallstricke lauern, diskutiert dieser Artikel.
RAID-Technologie verspricht höhere Performance und mehr Sicherheit beim permanenten Speichern von Daten. Die ADMIN-Redaktion gibt einen Überblick über ... (mehr)

Für eine Migration zu Unicode bietet Oracle mehrere Möglichkeiten. Allerdings scheitern manche, wie beispielsweise das von Oracle seit 2011 zur Verfügung gestellte Oracle Database Migration Utility for Unicode – kurz DMU – in der Praxis oft daran, dass die Vorgaben der Unternehmen die nötige Downtime nicht zulassen, oder dass die Einsatzvoraussetzungen des Produktes (Release- und Patchstand) nicht gegeben sind. Mit dem hier vorgestellten Verfahren wurden dagegen bereits sehr große Datenbanken in sehr kurzer Zeit migriert.

Warum Unicode?

Jede Datenbank wird mit einer bestimmten Code Page erstellt. Auf dem Weg der Daten von der Anwendung in die Datenbank werden die Zeichen dann entsprechend übersetzt: Die Code Page der Anwendung wird auf die der Datenbank gemapt. Das gilt jedoch nur dann, wenn es sich um Zeichen-Datentypen handelt (»CHAR« , »VARCHAR2« , »CLOB« , »LONG« , »NCHAR« , »NVARCHAR2« , »NCLOB« ), denn Binärdaten möchte man natürlich nicht konvertieren.

Die Konvertierung findet während des Transports (über Oracle Net) automatisch statt, das heißt ein auf dem Windows Rechner eingetipptes Eurozeichen (0x80 unter WIN-1252) wird in der Datenbank als 0xA4 eingetragen, wenn sie mit dem Zeichensatz ISO-8859P15 angelegt wurde. Wurde die Datenbank allerdings mit einem Unicode-Zeichensatz erstellt, dann legt sie das Eurozeichen als drei Byte lange Sequenz ab (0xE282AC), benötigt also dreimal so viel Platz wie zuvor.

In der Vergangenheit wurden die meisten Datenbanken in Europa mit einem Ein-Byte-Zeichensatz angelegt (also ISO-8859 oder MSWIN-1252). Im Zuge der Globalisierung wird es für die Unternehmen nun aber immer wichtiger, Datenbanken weltweit einzusetzen. Daher empfiehlt Oracle seit einiger Zeit, Unicode als Standardzeichensatz zu verwenden. Viele moderne Anwendungen (beispielsweise Java-Applikationen) verwenden darüber hinaus ebenfalls standardmäßig Unicode. Dasselbe gilt für viele heutige Betriebssysteme wie Microsoft Windows 7 oder Linux.

Bei der Umstellung einer Oracle-Datenbank auf Unicode können die folgenden Schwierigkeiten auftreten:

Spalten laufen über

Beim Design von Tabellen ist darauf zu achten, dass die Breite einer Spalte als bestimmte Anzahl von Zeichen und nicht etwa als Anzahl Bytes definiert ist. Als Beispiel eignen sich hierfür Felder, die mit dem Datentyp CHAR angelegt wurden, zum Beispiel

CREATE TABLE status (
statusid CHAR(1),
beschreibung VARCHAR2(50));

Die Frage ist, handelt es sich bei der "1" um die Länge ein Byte oder um ein Zeichen. Für diese Festlegung verwendet die Oracle-Datenbank den Parameter »NLS_LENGTH_SEMANTICS« , der entsprechend auf »CHAR« oder »BYTE« einzustellen ist. Da diese Semantik erst seit Oracle 9i zur Verfügung steht und vorher ausschließlich Byte verwendet werden konnte, ist bei vielen älteren Anwendungen (oder bei Anwendungen, die über mehrere Oracle Releases migriert wurden), die Längensemantik immer noch auf »BYTE« eingestellt. Bei einer Unicode-Migration kann das dazu führen, dass ein Datensatz nicht eingefügt werden kann, weil in ihm beispielsweise ein Umlaut vorkommt. Daraus resultiert dann eine Fehlermeldung wie die folgende:

ORA-02374: conversion error loading table "DEMO"."STATUS"
ORA-12899: value too large for column STATUSID (actual: 2, maximum: 1)

In diesem Fall enthielt die Status-Spalte als ID ein »Ü« , was im Unicode nun aber ein zwei Byte langes Zeichen ist.

Bei neuen Anwendungen gibt man die Längensemantik deshalb immer explizit an. Alte Anwendungen sind im Zuge der Migration anzupassen. Das obige Beispiel wäre also wie folgt zu ändern:

CREATE TABLE status (
statusid CHAR(1 CHAR),
beschreibung VARCHAR2(50 CHAR));

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019