Tak, jeśli baza danych Oracle jest tworzona przy użyciu zestawu znaków Unicode, NVARCHAR w SQL Server należy przenieść do VARCHAR2 w Oracle. W Oracle NVARCHAR typ danych istnieje, aby umożliwić aplikacjom przechowywanie danych przy użyciu zestawu znaków Unicode, gdy zestaw znaków bazy danych nie obsługuje Unicode.
Jedną z rzeczy, o których należy pamiętać podczas migracji, jest semantyka długości znaków. W SQL Server NVARCHAR(20) przydziela miejsce na 20 znaków, co wymaga do 40 bajtów w UCS-2. W Oracle domyślnie VARCHAR2(20) przydziela 20 bajtów pamięci. W AL32UTF8 zestaw znaków, czyli potencjalnie wystarczy miejsca tylko na 6 znaków, chociaż najprawdopodobniej obsłuży znacznie więcej (pojedynczy znak w AL32UTF8 wymaga od 1 do 3 bajtów. Prawdopodobnie chcesz zadeklarować swoje typy Oracle jako VARCHAR2(20 CHAR) co oznacza, że chcesz przydzielić miejsce na 20 znaków, niezależnie od liczby wymaganych bajtów. To wydaje się być znacznie łatwiejsze do zakomunikowania niż próba wyjaśnienia, dlaczego niektóre 20-znakowe ciągi są dozwolone, podczas gdy inne 10-znakowe ciągi są odrzucane.
Możesz zmienić domyślną semantykę długości na poziomie sesji, tak aby wszystkie tabele, które tworzysz bez określania semantyki długości, używały semantyki znakowej, a nie bajtowej
ALTER SESSION SET nls_length_semantics=CHAR;
Pozwala to uniknąć wpisywania CHAR za każdym razem, gdy definiujesz nową kolumnę. Możliwe jest również ustawienie tego na poziomie systemu, ale jest to odradzane przez zespół NLS — najwyraźniej nie wszystkie skrypty dostarczane przez Oracle zostały dokładnie przetestowane w bazach danych, w których NLS_LENGTH_SEMANTICS został zmieniony. I prawdopodobnie bardzo niewiele skryptów innych firm zostało.
