Migraciones a clientes usando base de datos universal

migracion
¿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.

  ¿Cómo diferenciar VARCHAR2 en Oracle Data Base?

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

4.2/5 - (5 votos)

Deja una respuesta