¿Qué pasa en las bases de datos si usan character set distintos a los Unicode?

Si el character set de destino contiene los caracteres del origen o unos de remplazo se podrá hacer la migración al Unicode, pero para esto necesitamos usar caracteres de reemplazo que resultan ser en la mayoría de los casos el simple usos de las diálisis a letras sin ellas.

Por ejemplo, si está migrando del conjunto de caracteres A al conjunto de caracteres B, entonces el conjunto de caracteres de destino B debe ser un superconjunto del conjunto de caracteres A. El carácter de destino, B, es un superconjunto si contiene todos los caracteres definidos en el conjunto de caracteres A.

Los caracteres que no están disponibles en el juego de caracteres B se convierten en caracteres de reemplazo, que a menudo se especifican por ejemplo como ä (a con una diéresis) se puede reemplazar por a. Los caracteres de reemplazo están definidos por el juego de caracteres de destino.

Posibles problemas

Se pueden ocasionar en la migración de WE8MSWIN1252 a AL32UTF8 están explicados en la documentación anterior DMU (Oracle Database Migration Assistant for Unicode).

Tales problemas como el truncamiento de datos y los problemas que pueden causar estas, así como la solución o que tener en cuenta antes de hacer una migración de las bases de datos usando el DMU.

¿Dónde consultar los problemas?

También podemos ver algunos de los problemas y su correspondiente medida en la hoja de cálculo Characterset_Report en la que brinda información de los problemas encontrados en el escaneo de la base de datos con su correspondiente descripción y cambios que se necesitan tomar en cada uno de los casos.

Como cambiar a los clientes sus character set en función al idioma de cada uno de ellos?

Lo primero que debemos analizar es que si su character set son compatibles con el character set al32utf8

Ventajas de al32utf8:

• Los caracteres suplementarios se almacenan en 4 bytes, por lo que no hay conversión de datos cuando los caracteres suplementarios se recuperan e insertan si la configuración del cliente es UTF-8.
• El almacenamiento de caracteres suplementarios requiere menos espacio en disco en AL32UTF8 que en UTF8.

Desventajas:

• No puede especificar la longitud de los tipos de SQL CHAR en número de puntos de código UCS-2 para caracteres suplementarios. Los caracteres suplementarios se tratan como un punto de código en lugar de los dos puntos de código estándar.
• El orden binario para las columnas SQL CHAR es diferente del orden binario de las columnas SQL NCHAR cuando los datos consisten en caracteres suplementarios. Como resultado, las columnas CHAR y las columnas NCHAR no siempre tienen el mismo tipo para cadenas idénticas. Explicación en el documento varchar2 (10 char).

Más información | Oracle

Aitzol Tola

Soy un Técnico Informático con una gran pasión hacia las nuevas tecnologías.

aitzoltola.com

La entrada Migraciones a clientes usando base de datos universal se publicó primero en Linux Básico.

Las herramientas CSSCAN y CSALTER se usan en servidores de base de datos Oracle, generalmente en las versiones anteriores al 12c.

Para poder realizar una migración de un character set a otro realizaremos los pasos que explico a continuación.

La función CSSCAN es usado para descartar de la base de datos posibles problemas de conversión.

Identificando la cantidad de esfuerzo requerido por el servidor para llevar a cabo la tarea de la migración de un juego de caracteres a otro.

Por ejemplo del juego de carácter (character set) WE8MSWIN1252 al juego de caracteres AL32UTF8 usando la función CSSCAN y CSALTER combinadamente.

Con esta herramienta, tendremos toda la información sobre la migración, como por ejemplo la carga que este conlleva para el servidor o los caracteres que nos darán problemas de truncamientos al realizar el cambio.

Truncamientos

Cuidado con los caracteres que den problemas de truncamiento ya que estos dos caracteres estarán en conflicto sobre su significado en el juego de caracteres a la que va a ser migrado.

Por ejemplo puede llegar a eliminarse el carácter o a tomar un significado o carácter distinto en la que fue guardada como pasar de la ä a la a.

También puede ser un problema que dos caracteres de distintos lenguajes se guarden de la misma forma en el juego de caracteres de destino.

El proceso de migración

El proceso a realizar para ejecutar una migración en un servidor Oracle de una versión anterior al 12c usando el script CSALTER son las siguientes:

El primer paso a realizar es detener la base de datos en modo inmediato.

shutdown inmediate;

A continuación realizaremos una backup completa de la base de datos que vamos a migrar, es recomendable realizarlo en frio y con una copia de utilidad (expdp/impdp).

Al tener esta backup podremos fallar en la migración sin consecuencias ya que algo que debemos tener en cuenta en una migración es que no hay marcha atrás en los cambios realizados en ella.

Para continuar en la migración, volveremos a poner en marcha la base de datos usando el comando startup;

Y procederemos a ejecutar la utilidad csscaner que esta ubicado en $ORACLE_HOME /bin

$csscan "sys/password@db as sysdba" full=y

A continuación del comando nos pedirá que insertemos el nuevo juego de caracteres a la que vas a migrar la base de datos.

Para finalizar el proceso de migración:

Tendremos que iniciar el script CSALTER pero antes de esto deteniendo la base de datos y conectado con el usuario SYS.

Para ello tendremos que acceder a la dirección $ORACLE_HOME/RDBMS/admin y ejecutando csalter.plb

Y con este proceso de migración conseguiríamos migrar la base de datos de un juego de caracteres de Oracle anteriores a la versión 12c, para las bases de datos posteriores a este tenemos la herramienta añadida DMU.

Aitzol Tola

Soy un Técnico Informático con una gran pasión hacia las nuevas tecnologías.

aitzoltola.com

La entrada CSSCAN y CSALTER para qué sirven y cómo usarlos se publicó primero en Linux Básico.

Es importante, diferenciar el uso de VARCHAR2 (n byte o char). A continuación, conoceremos qué es VARCHAR2 en Oracle Data Base.

Para diferenciar las dos cadenas de caracteres, hay que tener en cuenta que VARCHAR2 (byte) delimita en bytes mientras que VARCHAR2 (char) delimita el número de caracteres.

Aun así, se podría gestionar mejor los bytes de almacenamiento, usando NVARCHAR2, ya que su función es la misma que la de VARCHAR2 (10 CHAR).

Según el juego de caracteres usada en la base de datos, por ejemplo, AL32UTF8 los caracteres pueden ser de hasta 4 byte. Cosa que no pasa en WE8MSWIN1252 ya que en este caso todos los caracteres eran de un solo byte y no requiere almacenamiento multibyte.

Según el caso, cambiarían los bytes almacenados, dándonos un menor o mayor espacio, si por ejemplo, son caracteres de la zona de Asia.

En ese caso, mejor usar NVARCHAR2 antes que VARCHAR2 (n CHAR) y así será menor los bytes almacenados en la base de datos.

Usar NVARCHAR2 es mejor que VARCHAR2 (n CHAR) solo en el caso de que se vaya a usar la base de datos con caracteres asiáticos.

Es conveniente usar siempre el tipo de datos VARCHAR2 para almacenar cadenas de caracteres de longitud variable. Los cuales son todos aquellos caracteres que pueden ser de más de un byte de longitud.

Si la base de datos se ejecuta en un conjunto de caracteres de un solo byte (por ejemplo, US7ASCII, WE8MSWIN1252 o WE8ISO8859P1).

No importa si se usa VARCHAR2 (BYTE) o VARCHAR2 (CHAR) porque los caracteres en estos son de un solo byte y la cantidad delimitada en ambos casos sería la misma.

Solo hace una diferencia cuando la base de datos se ejecuta en un conjunto de caracteres de varios bytes (por ejemplo, AL32UTF8 o AL16UTF16).

Simplemente puede verse en este ejemplo:

CREATE TABLE my_table (
    VARCHAR2_byte VARCHAR2(1 BYTE), 
    VARCHAR2_char VARCHAR2(1 CHAR)
);

INSERT INTO my_table (VARCHAR2_char) VALUES ('€');
1 row created.

INSERT INTO my_table (VARCHAR2_char) VALUES ('ü');
1 row created.

INSERT INTO my_table (VARCHAR2_byte) VALUES ('€');
INSERT INTO my_table (VARCHAR2_byte) VALUES ('€')
Error at line 10
ORA-12899: value too large for column "MY_TABLE"."VARCHAR2_BYTE" (actual: 3, maximum: 1)

INSERT INTO my_table (VARCHAR2_byte) VALUES ('ü')
Error at line 11
ORA-12899: value too large for column "MY_TABLE"."VARCHAR2_BYTE" (actual: 2, maximum: 1)

Podemos apreciar que al insertar un carácter multibyte en un solo byte, nos dará el error de falta de espacio usando VARCHAR2 (1 BYTE) pero al insertarlo en VARCHAR2 (1 CHAR), nos dejara guardar el carácter que queramos sin importar su peso en byte, ya que en el caso de Unicode podrían ser de hasta 4 bytes.

Sin embargo, VARCHAR2 (4000 CHAR) no significa que tenga la garantía de almacenar hasta 4000 caracteres. El límite sigue siendo de 4000 bytes, por lo que en el peor de los casos puede almacenar solo hasta 1000 caracteres en dicho campo.

Además, después de la versión 12c, el máximo para varchar2 ahora es 32767 byte solo si el parámetro de inicialización “MAX_STRING_SIZE” está en “EXTENDED”, en el caso de no ser así, el máximo por defecto seguiría siendo de 4000 byte.

Si se necesita más que eso, sería conveniente usar una cadena de caracteres CLOB que nos daría un límite de bytes mayor.

En el PL/SQL, los bytes almacenados de las ambas formas, ya sea VARCHAR2 (n byte) o VARCHAR2 (n char) se guardaran usando los mismos bytes por carácter.

Acorde a esta información si sabemos exactamente la cantidad de bytes que serán almacenados, la mejor forma de guardarlos sería usando VARCHAR2 (n byte).

Sabiendo que siempre serán los mismos caracteres ya que al usar otros podría verse afectado el máximo de bytes de no saber cuántos byte van a ocupar esos caracteres y queremos delimitarlos en cantidad de caracteres, será más apropiado usar VARCHAR2 (n char).

Si te ha sido útil puedes leer mas entradas sobre bases de datos en nuestra web.

Aitzol Tola

Soy un Técnico Informático con una gran pasión hacia las nuevas tecnologías.

aitzoltola.com

La entrada ¿Cómo diferenciar VARCHAR2 en Oracle Data Base? se publicó primero en Linux Básico.