Software libre | Diferencias entre... | Fortalezas... | Ubuntu, Apache... | Postgre con Linux...
Análisis... | Migrar... | Caso práctico | Conclusiones...

Uno de los desafíos que se ven enfrentada las empresas al momento de implementar un nuevo Software, ya sea un paquete cerrado, un desarrollo in-house o una aplicación de software libre es el de migrar la información que existe en los actuales sistemas que administran la operación del negocio.  El desafío no es menor, ya que gran parte del éxito del proyecto dependerá de la calidad de los datos con la cual se inicia el nuevo Software.
Cuando se piensa en migrar datos de un sistema a otro, no es sólo realizar programas que permitan efectuar la migración, existen otros factores que se deben tener presente en el proceso de migración de datos. Por ejemplo: Procesos de negocio, limpieza de datos, fuentes de información, equipos de trabajo, herramientas a utilizar, planes de pruebas, etc.
Factor crítico para el éxito de la migración de la base de datos es la realización de pruebas para validar o modificar la arquitectura final y el plan de migración, así como para comprobar que las aplicaciones funcionan correctamente.
Actualmente la información se ha convertido en un activo importante para las organizaciones tanto públicas como privadas; dicha información se obtiene mediante la extracción e interpretación de los datos que posee la organización, algunos de los cuales se encuentran almacenados en sus bases de datos (BD).
Una base de datos en su concepto más simple, se refiere a un conjunto de datos relacionados entre sí con un objetivo común. De acuerdo con C. J. Date, en su libro Introducción a las bases de datos: “es una colección de datos integrados, con redundancia controlada y con una estructura que refleje las interrelaciones y restricciones existentes en el mundo real; los datos que han de ser compartidos por diferentes usuarios y aplicaciones, deben mantenerse independientes de éstas, y su definición y descripción, únicas para cada tipo de dato, han de estar almacenadas junto con los mismos. Los procedimientos de actualización y recuperación, comunes, y bien determinados, habrán de ser capaces de conservar la integridad, seguridad y confidencialidad del conjunto de datos”.
En tanto que una migración de BD es un proceso que se realiza para mover o trasladar los datos almacenados en un origen de datos a otro, para lo cual es indispensable que antes de empezar cualquier proceso de esta naturaleza, se tenga clara y documentada la razón por la cual se está migrando, además de elaborarse la planeación detallada de las actividades contempladas. Dicha migración se requiere llevar a cabo cuando es necesario mover un esquema dentro del mismo servidor, o de un servidor a otro, así como para actualizar la versión del software, y hacer un cambio de manejador de bases de datos por el de otro fabricante o para cambiarlo a una plataforma de cómputo distinta.
Como puede observarse, El proceso de migración de una base de datos puede ser bastante complejo, ya que la diversidad de bases de datos existentes hace difícil elaborar un Plan que funcione en todos los casos. Además de la dificultad de transferir la información entre los dos sistemas gestores de base de datos, influirá mucho en la complejidad del problema, el tipo de los datos de las tablas que se estén utilizando.
Para realizar un plan de migración de bases de datos, es de gran importancia el conocimiento de los dos manejadores de Bases de Datos y por supuesto la mayor experiencia posible, de tal manera que se garantice la migración efectiva y funcional de los datos. En líneas generales se deben tomar en cuenta los siguientes pasos:

• Normalización de las estructuras (esquema) de la base de datos a migrar.
• Sacar de línea la base de datos (Bajar la base de datos).
• Respaldar los datos.
• Aplicar métodos que puedan ayudar a exportar la estructura y los datos de la base de datos por separado.
• Generar la base de datos nueva en el manejador correspondiente.
• Importar la estructura y los datos hacia la base de datos nueva.
• Validar los datos importados de tal manera que no existan incoherencias en los mismos.
• Poner en línea la base datos (Subir la base de datos).
• Conectar varios usuarios con la finalidad de probar el correcto funcionamiento de todo el sistema.

Migración Oracle – Postgre

Migrar la estructura

La migración del esquema de una base de datos Oracle, a una base de datos postgreSQL es más o menos complicada en función de las particularidades de Oracle que incluya. Existen distintas herramientas para automatizar la migración de esquemas de Oracle hacia postgreSQL, pero ninguna de ella es totalmente infalible, y pueden ser necesarios ajustes manuales.
Lo primero que debería hacerse es crear y Ejecutar un script de creación de bases de datos en PostgreSQL.
Si va a exportarse una base de datos postgreSQL a través de ODBC, es conveniente instalar el catálogo de extensiones ODBC, que realiza un ajuste más estricto de las funciones de postgreSQL hacia el estándar ODBC.

Migrar los datos

Tras llevar cabo la migración de la estructura de la BD, el siguiente paso son los datos. Este proceso puede afrontarse desde muchos puntos de vista, en función de la imaginación del encargado, de la magnitud de los datos, y de las posibilidades de los SGBD origen y destino. Dado que nos estamos centrando en Oracle y postgreSQL, destacaremos las siguientes:

• Exportar los datos a un fichero de SQL: La sintaxis de dicho fichero, será más o menos estándar según las variaciones de la BD origen (esta es la manera más habitual de exportar datos del SGBD Oracle). Para realizar la importación, pueden ser necesarios ajustes y modificaciones en el fichero para adaptarlo a la sintaxis del SGBD destino.
• Exportando los datos a un formato de texto plano. Este método es muy efectivo, y puede atacarse desde muchos frentes. Por ejemplo, se puede llevar a cabo conectándose a través de ODBC a la base de datos Oracle con un SGBD que facilite la exportación (por ejemplo MS-Acces). Se importan los datos de las tablas al SGBD intermedio (MS-Acces), y se exportan de nuevo los mismos como texto plano con separadores (por ejemplo tabulaciones y retornos de carro). Tras ello, se pueden utilizar las herramientas de importación del SGBD destino (postgreSQL y pg_dump) para llevar a cabo la importación. Este mismo esquema, puede enfocarse utilizando combinaciones de lenguajes de filtrado para construir el fichero destino (por ejemplo PERL o AWK). Como última opción, existe software comercial que lleva a cabo la migración, como el producto Chyfo de Ispirer Systems

Secuencias y vistas

En muchas bases de datos relacionales, se hace uso de las secuencias, principalmente, en claves primarias e índices. Hay que ser especialmente cuidadoso al migrar las secuencias entre dos bases de datos, ya que, si en la base de datos destino se crea la secuencia pero no se inicializa con el último valor que tenía en la base de datos origen, podemos encontrar muchos problema (por ejemplo, el no poder realizar inserciones porque .aparezcan. errores de claves primarias duplicadas).
En cuanto a las vistas, PostgreSQL proporciona un sistema de vistas compatible sintácticamente con el de otros SGBD, pero que internamente trabaja de una forma poco habitual, pues hace uso de un sistema de reglas. La creación de vistas, por tanto, no presenta a priori grandes problemas de portabilidad, los únicos problemas aparecen en los CAST de las clausulas UNION, donde no podemos aplicar la misma sintaxis que Oracle.

Roles

El concepto de ROL que mantienen hoy en día algunas bases de datos comerciales2, no está implementado en postgreSQL. Sin embargo, postgreSQL plantea un sistema bastante similar, los grupos.
Los grupos de postgreSQL, son distintos a los definidos dentro del sistema operativo sobre el cual está instalado el software. Cualquier conexión a PostgreSQL debe ser realizada con un usuario específico, y cualquier usuario puede pertenecer a uno o más grupos definidos.
La tabla de usuarios controla los permisos de acceso y quién está autorizado a realizar acciones en el sistema (y qué acciones puede realizar). Los grupos existen como un mecanismo para simplificar la ubicación de estos permisos. Tanto las tablas de usuarios como de grupos existen como objetos globales de base de datos, lo que significa que no están adscritas a ninguna base de datos en particular.
La principal diferencia entre los grupos de postgreSQL y los roles Oracle, es que los roles pueden anidarse entre si y los grupos no. Es decir, un ROL puede incluir o actuar como otros ROLES acumulando permisos, pero un grupo de postgreSQL no puede pertenecer a otro grupo. El sistema de postgres, permite conseguir los mismos resultados que el de Oracle, aunque de una manera menos flexible.

Ajustes finales en el servidor Postgre

PostgreSQL tiene fama de ser un SGBD .pesado.. Esta idea estaba totalmente justificada en las versiones 6.x. Sin embargo, las versiones 7.x han mejorado notablemente sus tiempos de respuesta, aunque sigue siendo más lento que otros SGBD cuando se producen muchas consultas simultáneas. No obstante, el postgreSQL puede mejorar notablemente su rendimiento realizando ajustes sobre la instalación:

1. Aumentar el número de clientes (Optión -N del postmaster). Para tener pleno control sobre éste proceso, conviene lleva a cabo una la instalación de postgreSQL compilando los fuentes, puesto que las versiones precompiladas (paquetes RPM), tiene limitado el número máximo de conexiones simultáneas 32.
2. Aumentar la memoria compartida usada como caché de consultas (si tienes mucha memoria, se puede incrementar mucho y el rendimiento aumenta considerablemente) Es la opción -B del backend, que configura el numero de segmentos de 8Kbytes.
3. Si tienes queries complejos, aumentar la memoria de procesamiento de queries, para que quepan todos los datos que se están procesando en esa memoria y los queries sean ejecutados más rápido (opción –o "-Snnn" del postmaster).
4. Configurar bien el número de ficheros abiertos posibles en linux.
5. Configurar bien la memoria compartida de linux, maxima usable, numero maximo de segmentos, tamaño de segmentos. Con ipcs -l podemos conocer los límites de la máquina.
6. Ejecutar el comando "vacuum analyze" diariamente, para que mejore las optimizaciones que hace postgres según los datos que va almacenando de las consultas reales que recibe. El .vaccum. hay que hacerlo después de que el servidor empiece a recibir tráfico real, no con benchmarks, ya que en ese caso realizará optimizaciones poco que talvez sean poco útiles con la carga real.

Realizado por: Jorge Eliecer Jaimes Jimenez - Julio 2008