nvarchar2 - ¿Diferencia entre NVARCHAR en Oracle y SQL Server?

oracle nvarchar2

Question

Estamos migrando algunos datos del servidor SQL a Oracle. Para las columnas definidas como NVARCHAR en el servidor SQL, comenzamos a crear columnas NVARCHAR en Oracle pensando que son similares ... pero parece que no lo son.

He leído un par de publicaciones en stackoverflow y quiero confirmar mis conclusiones.

Oracle VARCHAR2 ya admite Unicode si el conjunto de caracteres de la base de datos es, por ejemplo, AL32UTF8 (lo cual es cierto para nuestro caso).

SQLServer VARCHAR no admite Unicode. SQLServer requiere explícitamente que las columnas estén en el tipo NCHAR/NVARCHAR para almacenar datos en unicode (específicamente en el formato UCS-2 de 2 bytes) ..

Por lo tanto, ¿sería correcto decir que las columnas NVARCHAR de SQL Server pueden / deberían migrarse como columnas Oracle VARCHAR2?

Answer 1

Sí, si su base de datos Oracle se crea utilizando un juego de caracteres Unicode, un NVARCHAR en SQL Server debería migrarse a un VARCHAR2 en Oracle. En Oracle, el tipo de datos NVARCHAR existe para permitir que las aplicaciones almacenen datos utilizando un conjunto de caracteres Unicode cuando el conjunto 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 la longitud del carácter. En SQL Server, un NVARCHAR(20) asigna espacio para 20 caracteres que requieren hasta 40 bytes en UCS-2. En Oracle, de forma predeterminada, un VARCHAR2(20) asigna 20 bytes de almacenamiento. En el AL32UTF8 caracteres AL32UTF8 , eso es potencialmente solo 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, lo que suele ser mucho más fácil de comunicar que intentar explicar por qué se permiten unas 20 cadenas de caracteres mientras que otras 10 cadenas de caracteres se rechazan.

Puede cambiar la semántica de longitud predeterminada en el nivel de sesión para que cualquier tabla que cree sin especificar semántica de longitud use caracteres semánticos en lugar de bytes.

ALTER SESSION SET nls_length_semantics=CHAR;

Eso le permite evitar escribir CHAR cada vez que define una nueva columna. También es posible establecer que a nivel de sistema, pero el equipo NLS no recomienda hacerlo, al parecer, no todos los scripts que proporciona Oracle se han probado exhaustivamente en las bases de datos donde se ha cambiado NLS_LENGTH_SEMANTICS . Y probablemente muy pocos scripts de terceros hayan sido.