Да, ако вашата база данни на Oracle е създадена с помощта на набор от знаци Unicode, NVARCHAR в SQL Server трябва да се мигрира към VARCHAR2 в Oracle. В Oracle, NVARCHAR типът данни съществува, за да позволи на приложенията да съхраняват данни, използвайки набор от знаци Unicode, когато наборът знаци на базата данни не поддържа Unicode.
Едно нещо, което трябва да знаете при мигрирането обаче, е семантиката на дължината на знаците. В SQL Server, NVARCHAR(20) заделя място за 20 знака, което изисква до 40 байта в UCS-2. В Oracle, по подразбиране, VARCHAR2(20) разпределя 20 байта място за съхранение. В AL32UTF8 набор от символи, който потенциално е достатъчно място само за 6 знака, въпреки че най-вероятно ще обработва много повече (един знак в AL32UTF8 изисква между 1 и 3 байта. Вероятно искате да декларирате вашите Oracle типове като VARCHAR2(20 CHAR) което показва, че искате да отделите място за 20 знака, независимо колко байта изисква това. Това обикновено е много по-лесно за общуване, отколкото да се опитвате да обясните защо са разрешени низове от 20 знака, докато други 10 низа от символи са отхвърлени.
Можете да промените семантиката на дължината по подразбиране на ниво сесия, така че всички таблици, които създавате, без да указвате каквато и да е семантика на дължина, да използват символна, а не байтова семантика
ALTER SESSION SET nls_length_semantics=CHAR;
Това ви позволява да избегнете въвеждането на CHAR всеки път, когато дефинирате нова колона. Също така е възможно да се зададе това на системно ниво, но това се обезсърчава от екипа на NLS-- очевидно не всички скриптове, предоставени от Oracle, са били щателно тествани спрямо бази данни, където NLS_LENGTH_SEMANTICS е променен. И вероятно е имало много малко скриптове на трети страни.
