{"id":90,"date":"2016-08-08T15:58:21","date_gmt":"2016-08-08T13:58:21","guid":{"rendered":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/?p=90"},"modified":"2022-12-01T15:58:43","modified_gmt":"2022-12-01T14:58:43","slug":"oracle-11-zeichensatz-von-we8mswin1252-auf-utf8-umstellen","status":"publish","type":"post","link":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/?p=90","title":{"rendered":"Oracle 11 &#8211; Zeichensatz von WE8MSWIN1252 auf UTF8 umstellen"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Umstellung des Zeichensatz von WE8MSWIN1252 auf UTF8<\/h2>\n\n\n\n<p>Viele \u201ealte\u201c Oracle Datenbanken laufen noch mit der Kodierung WE8MSWIN1252. Wenn nun die Internationalisierung st\u00e4rker in den Fokus der Entwicklung kommt, werden schnell die Grenzen deutlich, da viele Sprachen mit der Kodierung WE8MSWIN1252 nicht in der Datenbank abgebildet werden k\u00f6nnen.<\/p>\n\n\n\n<p>Die heute \u00fcbliche L\u00f6sung ist die Umstellung der Datenbank auf UTF(8). Wie viele andere administrative Aufgaben ist auch diese bei Oracle Systemen leider nicht trivial und schlecht oder gar nicht dokumentiert. Dieser Blog beschreibt ein Vorgehen, das bei uns f\u00fcr eine Oracle 11 Datenbank funktioniert hat. Je nach den aktuell in der Datenbank verwendeten Datentypen k\u00f6nnen weitere Schritte notwendig sein. Folgende Schritte werden im Folgenden beschrieben:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Anpassung von gro\u00dfen Varchar2 Elementen auf CLOB<\/li>\n\n\n\n<li>Erstellen eines Datenbanksicherung in der Kodierung UTF8<\/li>\n\n\n\n<li>Umstellen der Datenbank auf UTF8<\/li>\n\n\n\n<li>Anpassen des Schemas f\u00fcr Varchar2 Elemente<\/li>\n\n\n\n<li>Import der Tabelleninhalte<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">Umstellung von gro\u00dfen Varchar2 Attributen auf CLOB<\/h2>\n\n\n\n<p>Ein Zeichen in UTF-8 ben\u00f6tigt mehrere Bytes Speicherplatz im Gegensatz zu einem Zeichen in WE8MSWIN1252, welches lediglich ein Byte ben\u00f6tigt. In Oracle werden L\u00e4ngen von Varchar2 Attributen, wenn keine weiteren Angaben gemacht werden, in Byte angegeben. Ein Varchar2(18) Element kann also nicht 18 Zeichen verwalten, sondern 18 Byte. Da Oracle 3 Byte je UTF8 Zeichen ben\u00f6tigt, k\u00f6nnen in einem solchen Feld nach der Umstellung lediglich 6 Zeichen gespeichert werden.<\/p>\n\n\n\n<p>Die Umstellung von kleineren Varchar2-Attributen wird weiter unten beschrieben und erfolgt innerhalb der neuen Datenbank. Problematisch sind Varchar2-Attribute, die in der Ausgangsdatenbank gr\u00f6\u00dfer als 1333 Zeichen (Achtung hier sind wirklich Zeichen gemeint) sind. Diese Elemente w\u00fcrden nach der Umwandlung mehr als 4000 Byte ben\u00f6tigen Die maximale L\u00e4nge eines Varchar2 in Oracle liegt allerdings nur bei 4000 Byte.<\/p>\n\n\n\n<p>Daher m\u00fcssen solche Felder vor den weiteren Schritten in Clobs umgewandelt werden.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Ausgangsattribut l\u00f6schen<\/li>\n\n\n\n<li>Clob Attribut anlegen<\/li>\n<\/ol>\n\n\n\n<p>Die folgende SQL-Anweisung erzeugt ein Skript, um die Varchar2 Attribute mit einer Gr\u00f6\u00dfe von \u00fcber 1333 in clob Felder umzusetzen:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">SELECT 'ALTER TABLE ' || TABLE_NAME || ' DROP COLUMN ' || COLUMN_NAME || ';' || \nCHR(13) || 'ALTER TABLE ' || TABLE_NAME || ' ADD ' || COLUMN_NAME || ' CLOB;' FROM USER_TAB_COLUMNS WHERE DATA_TYPE = 'VARCHAR2' AND DATA_LENGTH &gt; 1333;\n<\/pre>\n\n\n\n<p>Die Ergebniszeilen werden als Skript ausgef\u00fchrt.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Erstellen eines DB-Dumps mit UTF8 Zeichenkodierung<\/h2>\n\n\n\n<p>Nachdem nun alle Vorbereitungen getroffen wurden, kann nun eine Sicherung des Datenbestands erstellt werden. Beim Export wird das \u201enormale\u201c Dump Kommando verwendet und die Zeichenkodierung mit der Umgebungsvariable<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">export NLS_LANG=.UTF8\n<\/pre>\n\n\n\n<p>auf UTF8 gestellt.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Umstellen der Datenbank auf UTF8<\/h2>\n\n\n\n<p>In dem Wiki Beitrag<\/p>\n\n\n\n<p><a href=\"https:\/\/de.wikibooks.org\/wiki\/Oracle:_CharacterSet_%C3%A4ndern\">https:\/\/de.wikibooks.org\/wiki\/Oracle:_CharacterSet_%C3%A4ndern<\/a><\/p>\n\n\n\n<p>ist die (interne) Umstellung von Oracle 11 auf UTF 8 beschrieben. Die folgende Auflistung enth\u00e4lt die Schritte, die bei der in diesem Blog verwendeten Oracle 11 Version notwendig waren:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Als Nutzer sys mit sysdba-Berechtigung via sqlplus an der Oracle-Instanz anmelden. sqlplus &#8222;sys\/password@orcl as sysdba&#8220;<\/li>\n\n\n\n<li>CharacterSet der Datenbank \u00fcberpr\u00fcfen select value from nls_database_parameters where parameter=&#8217;NLS_CHARACTERSET&#8216;; bzw. um s\u00e4mtliche Einstellungen zu sehen select * from nls_database_parameters;<\/li>\n\n\n\n<li>Die Datenbank anhalten shutdown immediate;<\/li>\n\n\n\n<li>Bei der verwendeten Versionen gibt es einen Bug, bei dem ein Fehler beim Ausf\u00fchren von &#8222;startup mount;&#8220; ausgegeben wird. Daher vorher folgenden Befehl ausf\u00fchren: connect \/ as sysdba;<\/li>\n\n\n\n<li>Die Datenbank einh\u00e4ngen aber noch nicht \u00f6ffnen startup mount;<\/li>\n\n\n\n<li>Session f\u00fcr Operation vorbereiten alter system enable restricted session; alter system set job_queue_processes=0;<\/li>\n\n\n\n<li>Nun die Datenbank \u00f6ffnen alter database open; und den CharacterSet \u00e4ndern alter database character set internal_use utf8;<\/li>\n\n\n\n<li>Datenbank wieder schlie\u00dfen und herunterfahren shutdown immediate;<\/li>\n\n\n\n<li>Datenbank normal hochfahren startup;<\/li>\n\n\n\n<li>Nochmals die aktuellen Werte pr\u00fcfen select value from nls_database_parameters where parameter=&#8217;NLS_CHARACTERSET&#8216;;<\/li>\n\n\n\n<li>Damit kann SqlPlus wieder beendet werden exit;<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">Anpassen des Schemas f\u00fcr Varchar2 Felder<\/h2>\n\n\n\n<p>Mit dem folgenden SQL-Befehl wird ein Skript erzeugt, um die verbliebenen Varchar2 Attribute der Tabellen so zu erweitern, dass sie UTF8-Kodierte Zeichen aufnehmen zu k\u00f6nnen.<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\"> \nSELECT 'ALTER TABLE ' || TABLE_NAME || ' MODIFY ' || COLUMN_NAME || ' VARCHAR2(' || DATA_LENGTH || ' CHAR);'\nFROM USER_TAB_COLUMNS WHERE DATA_TYPE = 'VARCHAR2';\n<\/pre>\n\n\n\n<p>Die Ergebniszeilen werden als Skript ausgef\u00fchrt. Wenn in der Datenbank Char Attribute existieren, muss ein analoges Vorgehen f\u00fcr diese verwendet werden.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Import der Tabelleninhalte<\/h2>\n\n\n\n<p>Da wir bisher nur die Datenbank auf UTF-8 umgestellt haben, die Daten aber nicht ver\u00e4ndert wurden, w\u00fcrden bei der Nutzung des aktuellen Standes z.B. alle Umlaute falsch angezeigt werden. Um dies zu bereinigen, m\u00fcssen die Daten aus dem oben erstellten UTF-8 Datenbank-Dump eingespielt werden. Dies erfolgt mit folgenden Schritten:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Deaktivieren der Constraints der Datenbank<\/li>\n\n\n\n<li>Erzeugung eines Scripts, um die Inhalte der Tabellen zu l\u00f6schen<\/li>\n\n\n\n<li>Ausf\u00fchrung des erzeugten Scripts zum L\u00f6schen der Inhalte<\/li>\n\n\n\n<li>Import der Inhalte<\/li>\n\n\n\n<li>Reaktivierung der Constraints.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Constraints deaktivieren<\/h3>\n\n\n\n<p>Mit der folgenden SQL-Anweisung wird ein Skript erzeugt, das die Constraints der Datenbank daktiviert:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\"> \nSELECT 'alter table '|| table_name||' disable constraint '||CONSTRAINT_NAME||';' from user_constraints where table_name In (SELECT table_name from user_tables);\n<\/pre>\n\n\n\n<p>Die erzeugten Ergebniszeilen werden als Skript ausgef\u00fchrt.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">L\u00f6schen der Tabelleninhalte<\/h3>\n\n\n\n<p>Die Inhalte der Tabellen werden mit den Ergebnissen der folgenden Anweisung gel\u00f6scht<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\"> \nSELECT 'TRUNCATE TABLE ' || table_name || ';' from user_tables;\n<\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Einspielen der Tabelleninhalte aus dem Dump<\/h3>\n\n\n\n<p>Die zu Beginn gesicherten Daten in UTF-8 Kodierung werden nun eingespielt. Wichtig sind hierbei die Parameter FULL=Y IGNORE=Y CONSTRAINTS=N und das Setzen der Umgebungsvariable export NLS_LANG=.UTF8.<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">#!\/bin\/bash\n...\nexport NLS_LANG=.UTF8\n...\n$IMP $USER\/$PASS@orcl FILE=$FILENAME LOG=$LOG FULL=Y IGNORE=Y CONSTRAINTS=N\n...\n<\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Constraints aktivieren<\/h3>\n\n\n\n<p>Nachdem die Daten wieder eingespielt wurden, m\u00fcssen nun die Constraints aktiviert werden. Das folgende SQL-Kommando erstellt ein Skript, um die Constraints der Datenbank wieder zu aktivieren:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\"> \nSELECT 'alter table '|| table_name||' enable constraint '||CONSTRAINT_NAME||';' from user_constraints where table_name In (SELECT table_name from user_tables);\n<\/pre>\n\n\n\n<p>Die Ergebniszeilen m\u00fcssen als Skript ausgef\u00fchrt werden.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Zusammenfassung<\/h2>\n\n\n\n<p>Mit dem obigen Vorgehen wurde eine Datenbank auf UTF-8 umgestellt. Da Oracle die \u00c4nderung von Kodierungen nicht unterst\u00fctzt, sind sehr viele manuelle Schritte notwendig. F\u00fcr einen der Marktf\u00fchrer im Datenbank-Sektor ist dies aus meiner Sicht nicht verst\u00e4ndlich.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Umstellung des Zeichensatz von WE8MSWIN1252 auf UTF8 Viele \u201ealte\u201c Oracle Datenbanken laufen noch mit der Kodierung WE8MSWIN1252. Wenn nun die Internationalisierung st\u00e4rker in den Fokus der Entwicklung kommt, werden schnell die Grenzen deutlich, da viele Sprachen mit der Kodierung WE8MSWIN1252 nicht in der Datenbank abgebildet werden k\u00f6nnen. Die heute \u00fcbliche L\u00f6sung ist die Umstellung der [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-90","post","type-post","status-publish","format-standard","hentry","category-allgemein"],"_links":{"self":[{"href":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/index.php?rest_route=\/wp\/v2\/posts\/90","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=90"}],"version-history":[{"count":1,"href":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/index.php?rest_route=\/wp\/v2\/posts\/90\/revisions"}],"predecessor-version":[{"id":91,"href":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/index.php?rest_route=\/wp\/v2\/posts\/90\/revisions\/91"}],"wp:attachment":[{"href":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=90"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=90"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.schoenberg-solutions.de\/arndtblog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=90"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}