Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] [OT] Plan de migración de un sistema y BD

From: Mario Burdman <mburdman(at)gmail(dot)com>
To: Teófilo Oviedo <pgteus79(at)gmail(dot)com>
Cc: "(Syswarp) Carlos Enrique Perez" <carlos(dot)perez(at)syswarp(dot)com(dot)ar>, pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] [OT] Plan de migración de un sistema y BD
Date: 2009-03-05 15:25:03
Message-ID: 14bba8590903050725l149dc52em9d71b26f838c8c57@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Lo que puedo hacer es contarte una experiencia y darte los tips que a mi me
sirvieron y/o me hubieran servido (de los errores se aprende :) )

En mi caso se trataba de migrar un sistema que estaba en VB + Access en
varias bases de datos y muy muy mal diseñando a un sistema desarrollado en
Java con un servidor de aplicaciones (hecho a mano, no un Jboss ni nada de
eso por suerte) y BD postgres.

Lo que hice fue hacer un programa en java que lea del access y utilizando
los servicios del App server vaya creando las cosas del otro lado y en otra
bd (postgres por supuesto!!) iba guardando un mapeo de los ID que necesitaba
para buscar cosas en pasos posteriores. En algunos casos tuve que por ej
modificar el servicio para que reciba una fecha antigua y cosas asi. Por
suerte tenia acceso a fuentes de lo viejo y de lo nuevo.

Si bien es un poco mas lento que hacerlo de BD a BD, con esto me aseguré de
que los datos generados iban a ser consistentes para el nuevo sistema ya que
pasaba a traves de las reglas de negocio. De todas formas no se como es tu
caso y si esto aplica...

Lo que te puedo decir es:

. No migres cosas que no hagan falta. Los usuarios y gerentes te van a decir
"quiero todo lo que tenia" pero muchas veces terminas migrando cosas viejas
que que no sirven y nunca van a mirar. Insistí en este punto, pensá que lo
"ideal" es comendar un nuevo sistema con una BD en blanco, es imposible,
pero tendé hacia eso.

. Pone un ojo en los índices de origen y destino (hay veces que te conviene
agregar un indice en origen y borrar uno en destino para acelerar la cosa)
te puede ahorrar horas!

. Preparate unos controles de exactitud de las cosas críticas (la plata!!!!)
ej: select sum(importe) from tablavieja - select sum(importe) tablanueva
tienen que dar igual...

. Documentá TODO y gastá tiempo en automatizar. Seguro lo vas a hacer muchas
veces y si no lo vas a pagar ...

En otros trabajos usé un sistema propietario que se llamaba SQLMigra en el
que podes programar tus pasos de migración, cada paso tiene un origen y un
destino, en origen haces un select y en destino un insert, podes decirle
cada cuanto queres que haga commit etc... debe haber algo que haga esto pero
desconozco... Lo bueno es que quedaba listo y con un simple "play" hacia
toda la historieta el "dia de".

Espero te sirva de algo...

Saludos!

2009/3/5 Teófilo Oviedo <pgteus79(at)gmail(dot)com>

> Gracias Carlos, pero te comento que la BD en Postgres ya fue diseñada
> según la necesidad del nuevo sistema y el sistema ya está siendo
> desarrollado sobre esa nueva BD que corre en Postgres.
>
> La BD del sistema que hoy en día está en producción que está en DBF
> tiene aproximadamente 260 tablas y el sistema que se está
> desarrollando tiene hasta el momento 146 tablas.
>
> Mi situación es conseguir pasos o reglas a seguir para hacer la
> migración de los sistemas.
> por ejemplo, qué cosas tengo que contemplar para la migración y qué
> pasos tengo que dar para analizar las soluciones.
>
> De por sí sé que tengo que ver el mapeo de tablas, unificación de
> datos, división de datos. Pero como es mi primera vez que hago una
> migración no conozco todas las áreasque tengo que contemplar para
> hacer mi programa de migración.
>
> Gracias,
>
> El día 5 de marzo de 2009 12:34, (Syswarp) Carlos Enrique Perez
> <carlos(dot)perez(at)syswarp(dot)com(dot)ar> escribió:
> > Te sugiero una solucion sencilla pero entiendo que la cantidad de dbf no
> > deben ser muchas sino vas a tardar demasiado.
> > Crea la base en postres (sin foreing key ni nada de eso por ahora porque
> las
> > dbf no tienen fk entre si y seguro podes tener incosistencias). Se
> > sobreentiende que cada dbf deberia ser una tabla (los indices (idx, ntx,
> > cdx... Según el lenguaje que utilices (foxpro, clipper, etc) te sirven
> para
> > ver como estaban indexadas dichas tablas, podrias aprovecharlos como para
> > que una vez que tengas migrados los datos crees los mismos indices.
> > Levanta las dbf con excel
> >
> > . Desde excel armas el comando insert para el primer registro, o sea
> yendote
> > a una columna mas del ultimo campo poner algo como insert into tabla
> values
> > ( A1 &','& B1 ....
> > . Si ves que te funciona, copia y pega toda esa columna hasta el fin y te
> > armas el primer ddl de la tabla
> > . Repeti la operación para todas las dbf.
> >
> > . Para mi es lo mas rapido porque de movida tenes los nombres de campos
> en
> > mayusculas en las dbf y eso a postgres no le gusta.
> >
> > Espero que te sirva.
> > Saludos cordiales.
> >
> >
> >
> > -----Mensaje original-----
> > De: pgsql-es-ayuda-owner(at)postgresql(dot)org
> > [mailto:pgsql-es-ayuda-owner(at)postgresql(dot)org] En nombre de Teófilo Oviedo
> > Enviado el: jueves, 05 de marzo de 2009 10:55
> > Para: pgsql-es-ayuda(at)postgresql(dot)org
> > Asunto: [pgsql-es-ayuda] [OT] Plan de migración de un sistema y BD
> >
> > Amigos,
> >
> > Ya hace un tiempo que no venía consultando ni participando pero siempre
> leo
> > las consultas de los demás, me enseña muchisimo.
> >
> > Estoy con la situación que tengo que hacer la migración de una BD que
> está
> > en DBF con un sistema hecho por el dpto informatica de la empresa. Ahora
> se
> > está desarrollando un nuevo sistema también por el dpto de informática y
> se
> > desea alojar los datos sobre PostgreSQL.
> >
> > El antiguo sistema no fue bien diseñado y contempla muchos casos de
> > excepción lo que hace que el sistema sea semi-manual y muy burocrático.
> >
> > El nuevo sistema quiere eliminar la mayoría de los casos de excepción y
> > estandarizar procesos para que puedan ser automatizados.
> >
> > Ahora bien, hace 2 semanas entro en esta empresa y me encuentro con la
> > situación que casi no tienen documentación sobre lo que se desea hacer y
> que
> > los relevamientos no fueron eficientes.
> >
> > Como es mi primera vez en hacer una migración y estoy un poco apretado de
> > tiempo quisiera pedirle la ayuda para hacer el plan de migración. No sé
> si
> > ya hay unos pasos, reglas o técnicas de migración de sistemas que se
> pueda
> > seguir para hacerla ordenada, así como por ejemplo están las reglas de
> Coud
> > para hacer una BD.
> > Ahora mismo me están pidiendo cuánto tiempo llevará hacer la migración
> > completa. Y lo que deseo hacer es poder contemplar todas las situaciones
> con
> > las que debo encontrarme para medir adecuadamente los tiempos. Pero por
> mi
> > ignorancia puedo no contemplar algunas situaciones y calcular mal los
> > tiempos.
> >
> > Gracias y saludos a todos!
> >
> > Teófilo Oviedo
> > Dpto. TI
> > http://www.pneuma.com.py
> > --
> > TIP 2: puedes desuscribirte de todas las listas simultáneamente
> > (envía "unregister TuDirecciónDeCorreo" a majordomo(at)postgresql(dot)org)
> >
> >
> >
> --
> TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net
>

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message (Syswarp) Carlos Enrique Perez 2009-03-05 15:26:22 RE: Migrar sql a postgres
Previous Message Teófilo Oviedo 2009-03-05 14:46:47 Re: [pgsql-es-ayuda] [OT] Plan de migración de un sistema y BD