Migraciones a clientes usando base de datos universal

Aitzol Tola — Thu, 15 Oct 2020 08:34:07 +0000

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

CSSCAN y CSALTER para qué sirven y cómo usarlos

Aitzol Tola — Sat, 10 Oct 2020 21:10:43 +0000

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.