Sí, si su base de datos Oracle se crea con un juego de caracteres Unicode, un NVARCHAR en SQL Server debe migrarse a un VARCHAR2 en Oráculo. En Oracle, el NVARCHAR El tipo de datos existe para permitir que las aplicaciones almacenen datos usando un juego de caracteres Unicode cuando el juego de caracteres de la base de datos no es compatible con Unicode.
Sin embargo, una cosa a tener en cuenta al migrar es la semántica de longitud de caracteres. En SQL Server, un NVARCHAR(20) asigna espacio para 20 caracteres, lo que requiere hasta 40 bytes en UCS-2. En Oracle, por defecto, un VARCHAR2(20) asigna 20 bytes de almacenamiento. En el AL32UTF8 conjunto de caracteres, que es potencialmente suficiente espacio para 6 caracteres, aunque lo más probable es que maneje mucho más (un solo carácter en AL32UTF8 requiere entre 1 y 3 bytes. Probablemente desee declarar sus tipos de Oracle como VARCHAR2(20 CHAR) lo que indica que desea asignar espacio para 20 caracteres independientemente de la cantidad de bytes que requiera. Eso tiende a ser mucho más fácil de comunicar que tratar de explicar por qué se permiten algunas cadenas de 20 caracteres mientras que se rechazan otras cadenas de 10 caracteres.
Puede cambiar la semántica de longitud predeterminada en el nivel de sesión para que las tablas que cree sin especificar ninguna semántica de longitud utilicen semántica de caracteres en lugar de bytes
ALTER SESSION SET nls_length_semantics=CHAR;
Eso le permite evitar escribir CHAR cada vez que defina una nueva columna. También es posible configurarlo a nivel del sistema, pero el equipo de NLS desaconseja hacerlo; aparentemente, no todos los scripts que proporciona Oracle se han probado exhaustivamente en bases de datos donde NLS_LENGTH_SEMANTICS ha sido cambiado. Y probablemente muy pocos scripts de terceros lo hayan sido.
