Sim, se seu banco de dados Oracle for criado usando um conjunto de caracteres Unicode, um
NVARCHAR no SQL Server deve ser migrado para um VARCHAR2 em Oráculo. No Oracle, o NVARCHAR tipo de dados existe para permitir que os aplicativos armazenem dados usando um conjunto de caracteres Unicode quando o conjunto de caracteres do banco de dados não oferece suporte a Unicode. Uma coisa para estar ciente na migração, no entanto, é a semântica do comprimento do caractere. No SQL Server, um
NVARCHAR(20) aloca espaço para 20 caracteres que requer até 40 bytes em UCS-2. No Oracle, por padrão, um VARCHAR2(20) aloca 20 bytes de armazenamento. No AL32UTF8 conjunto de caracteres, que é potencialmente apenas espaço suficiente para 6 caracteres, embora provavelmente lidará com muito mais (um único caractere em AL32UTF8 requer entre 1 e 3 bytes. Você provavelmente deseja declarar seus tipos Oracle como VARCHAR2(20 CHAR) que indica que você deseja alocar espaço para 20 caracteres, independentemente de quantos bytes são necessários. Isso tende a ser muito mais fácil de comunicar do que tentar explicar por que algumas sequências de 20 caracteres são permitidas enquanto outras sequências de 10 caracteres são rejeitadas. Você pode alterar a semântica de comprimento padrão no nível da sessão para que todas as tabelas que você criar sem especificar nenhuma semântica de comprimento usem a semântica de caractere em vez de byte
ALTER SESSION SET nls_length_semantics=CHAR;
Isso permite que você evite digitar
CHAR cada vez que você define uma nova coluna. Também é possível definir isso no nível do sistema, mas isso é desencorajado pela equipe do NLS - aparentemente, nem todos os scripts fornecidos pela Oracle foram testados exaustivamente em bancos de dados onde o NLS_LENGTH_SEMANTICS foi mudado. E provavelmente muito poucos scripts de terceiros foram. 
