Ja, wenn Ihre Oracle-Datenbank mit einem Unicode-Zeichensatz erstellt wurde, ein NVARCHAR in SQL Server sollte zu einem VARCHAR2 migriert werden im Orakel. In Oracle der NVARCHAR Datentyp existiert, damit Anwendungen Daten mit einem Unicode-Zeichensatz speichern können, wenn der Zeichensatz der Datenbank Unicode nicht unterstützt.
Eine Sache, die Sie bei der Migration jedoch beachten sollten, ist die Semantik der Zeichenlänge. In SQL Server ein NVARCHAR(20) weist Platz für 20 Zeichen zu, was in UCS-2 bis zu 40 Bytes erfordert. In Oracle standardmäßig ein VARCHAR2(20) weist 20 Byte Speicherplatz zu. Im AL32UTF8 Zeichensatz, das ist möglicherweise nur genug Platz für 6 Zeichen, obwohl es höchstwahrscheinlich viel mehr verarbeiten wird (ein einzelnes Zeichen in AL32UTF8 benötigt zwischen 1 und 3 Bytes. Wahrscheinlich möchten Sie Ihre Oracle-Typen als VARCHAR2(20 CHAR) deklarieren was anzeigt, dass Sie Platz für 20 Zeichen zuweisen möchten, unabhängig davon, wie viele Bytes dafür erforderlich sind. Das ist in der Regel viel einfacher zu vermitteln, als zu versuchen zu erklären, warum einige 20-Zeichen-Strings erlaubt sind, während andere 10-Zeichen-Strings abgelehnt werden.
Sie können die Standardlängensemantik auf Sitzungsebene ändern, sodass alle Tabellen, die Sie erstellen, ohne eine Längensemantik anzugeben, Zeichen- statt Byte-Semantik verwenden
ALTER SESSION SET nls_length_semantics=CHAR;
Dadurch vermeiden Sie die Eingabe von CHAR jedes Mal, wenn Sie eine neue Spalte definieren. Es ist auch möglich, dies auf Systemebene festzulegen, aber das NLS-Team rät davon ab – anscheinend wurden nicht alle von Oracle bereitgestellten Skripte gründlich gegen Datenbanken getestet, in denen NLS_LENGTH_SEMANTICS wurde geändert. Und wahrscheinlich waren es nur sehr wenige Skripte von Drittanbietern.
