Migracin de datos Hablamos de migracin de datos cuando nos referimos al traspaso de informacin entre bases de datos.

Si tenemos una aplicacin sobre una base de datos como por ejemplo Access y posteriormente "crecemos" de manera que nos hace falta un sistema gestor de bases de datos potente, lo ms seguro es que nos decantemos por Oracle, DB2, Informix, SQLServer o similares. En este caso, los datos, que estarn en formato "access" debern pasar a formato "sqlserver" o formato para "oracle". La migracin de los datos consiste en convertir los datos desde un sistema de base de datos a otro. Esta migracin conlleva la creacin de tablas o modificacin de las existentes, cambios en algunos tipos de datos que existen en una base de datos pero no en otras, etc. Especialmente delicados son los campos fecha, los numricos (enteros, reales, etc), los de tipo "memo" o campos de extensin superior a 256 caracteres, campos para imgenes, etc, ya que cada SGBD los trata o los "espera" de manera diferente. Actualmente la mayora de SGBD incluyen herramientas de ayuda a la migracin ms o menos "fiables". No obstante, ni que decir tiene que el proceso de migracin de datos es lo suficientemente delicado como para realizarlo en un entorno de pruebas, contemplando toda la casustica posible en cuanto a tipos de datos a manejar, tablas involucradas y sus relaciones, etc. Slo en el momento en el que estemos seguros de que la migracin se ha realizado con xito, sin problemas de interpretacin de datos ni prdida de ellos, podemos pasar a un entorno de produccin. Teniendo en cuenta que una migracin mal realizada podra dar por terminada una estructura de informacin completa Tcnicas de Migracin de Datos Planeacin: Lo ms importante al migrar una Base de Datos es llevar a cabo un proceso de planeacin y anlisis del trabajo, puesto que aunque pareciera tomarse algn tiempo adicional, ste ser retribuido en el xito de la operacin y menos costos por errores de datos. Es importante que esto sea aplicado cuando la Base de Datos destino est en produccin. Contador de registros: Si la migracin se realiza de forma manual, mediante alguna consulta de insercin es recomendable inicializar un contador para cada registro insertado con xito y otro para los no insertados, as obviamente, la suma de ambos debe ser igual a los registros originales. Mapeador de Tipos de datos: Algunas plataformas no soportan algunos tipos de datos, as que es necesario planificar el mapeo de los campos en la nueva base de datos. Restricciones y Triggers: Antes de iniciar la migracin de la BD, es recomendable deshabilitar los Triggers y/o restricciones que nos puedan generar error al momento que el DBMS ejecute el proceso de escritura de los datos.

Codificacin de Caracteres: Cuando el copiado se realiza de forma automtica, es necesario identificar la codificacin de caracteres que la BD destino espera, pues as evitaremos el remplazo automtico de caracteres o en su caso, prdida de los mismos.

Recomendaciones para migrar de Access a MySQL Si nuestra base de datos anterior estaba construida en Access lo tenemos bastante fcil, gracias a que MySQL dispone de un driver ODBC para sistemas Windows, que nos permite conectar Access con el propio MySQL y pasar informacin fcilmente. Aunque hay que indicar que si deseamos hacer una exportacin desde Access en local a MySQL en remoto puede haber problemas porque no todos los alojadores permiten las conexiones en remoto con la base de datos. Si no tenemos disponible una conexin en remoto con nuestro servidor de bases de datos vamos a tener que cambiar la estrategia un poco. La idea en este ltimo caso es instalar MySQL en local y realizar la migracin desde Access en local a MySQL en local y luego podramos hacer un backup de la base de datos local y subirla a remoto, tal y como se ha relatado antes. Recomendaciones para migrar desde SQL Server a MySQL Access tambin nos puede ayudar en este caso. Access permite seleccionar una base de datos SQL Server y trabajar desde la propia interfaz de Access. La idea es que Access tambin permite trabajar con MySQL y posiblemente haciendo un puente entre estos dos sistemas gestores podemos exportar datos de SQL Server a MySQL. Lo que es seguro que utilizando el propio Access de puente podramos realizar el trabajo. Primero exportando de SQL Server a Acess y luego desde Access a MySQL. Otras bases de datos u otras tcnicas Si la base de datos origen dispone de un driver ODBC no habr (en teora) problema para conectarla con Access, de manera similar a como se conecta con MySQL. Entonces podramos utilizar Access para exportar los datos, porque desde all se podran acceder a los dos sistemas gestores de bases de datos. Si no tenemos Access, o la base de datos original no tiene driver ODBC, o bien no nos funciona correctamente el proceso y no sabemos cmo arreglarlo, otra posibilidad es exportar los datos a ficheros de texto, separados por comas o algo parecido. Muchas bases de datos tienen herramientas para exportar los datos de las tablas a ficheros de texto, los cuales se pueden luego introducir en nuestro sistema gestor destino (MySQL) con la ayuda de alguna herramienta como PhpMyAdmin.

Para ello, en la pgina de propiedades de la tabla encontraremos una opcin para hacer el backup de la tabla y para introducir ficheros de texto dentro de una tabla (Insert textfiles into table en ingls).

Accediendo a ese enlace podremos ver un formulario donde introducir las caractersticas del fichero de texto, como el carcter utilizado como separador de campos, o el terminador de lneas, etc, junto con el propio archivo con los datos, y PhpMyAdmin se encargar de todo el trabajo de incluir esos datos en la tabla.

Como se habr supuesto, es necesario tener creada la tabla en remoto para que podamos introducirle los datos del fichero de texto. Cambios de un formato de datos a otro

Toda la migracin tiene que tener en cuenta muy especialmente, como ya se seal, las maneras que tenga cada base de datos de guardar la informacin, es decir, del formato de sus tipos de datos. Tenemos que contar siempre con la posible necesidad de transformar algunos datos como pueden ser los campos boleanos, fechas, campos memo (texto con longitud indeterminada), etc, que pueden almacenarse de maneras distintas en cada uno de los sistemas gestores, origen y destino. En algunos casos posiblemente tengamos que realizar algn script que realice los cambios necesarios en los datos. Por ejemplo puede ser para localizar los valores boleanos guardados como true / false a valores enteros 0 / 1, que es como se guarda en MySQL. Tambin las fechas pueden sufrir cambios de formato, mientras que en Access aparecen en castellano (dd/mm/aaaa) en MySQL aparecen en el formato aaaa-mm-dd. PHP puede ayudarnos en la tarea de hacer este script, tambin Visual Basic Script para Access puede hacer estas tareas complejas y el propio lenguaje SQL, a base de sentencias dirigidas contra la base de datos, puede servir para algunas acciones sencillas.

Como migrar/copiar una base de datos a otro servidor. Que opciones tengo para la migracin? Afortunadamente Oracle provee muchos mtodos para realizar esta tarea, de nuevo, todo depende como la queramos hacer y depende de los requerimientos que tengamos. Pero existen soluciones sencillas y soluciones complejas, vamos a ver algunas de ellas de manera general y sin entrar en los detalles de cada una. Sencillas Copia Directa

Suponiendo que el nuevo servidor es exactamente igual que el anterior respecto a versiones de software (sistema operativo, base de datos, parches, etc) en teora si copiamos todos los archivos de datos, control files, redo logs, etc la base de datos debera de funcionar correctamente. Personalmente yo no utilizara esta opcin por que siempre falta algo, un parche, un parmetro, etc. Export/Import (DataPump en 10g)

Este podra ser tambin complejo pero normalmente se hace un export del usuario(s) de la aplicacin y se importa en la otra base de datos, creo que es de las mas sencillas que puede existir ademas que podemos hacer el export de una versin anterior a la nueva base de datos por ejemplo de 9i a 10g. El nico problema de esta opcin es que debemos tener mas o menos el mismo espacio en disco que la base de datos actual para poder hacer el export; por ejemplo en

una base de datos de 10Gb tal vez si es conveniente hacerlo pero en una de 600Gb o de Tb ya no es tan practico hacerlo, y si ademas se tiene que transferir el archivo(s) del export pues seria muchsimo mas tardado. Complejas RMAN Duplicate.

RMAN es una utilitaria de Oracle para realizar backups/restore. Una opcion que es muy interesante es el duplicate y como su nombre lo dice duplica una base de datos a otro servidor. Bsicamente como funciona es de la siguiente manera: se hace un backup de la base de datos fuente/original, una vez con el backup guardado en el tape/disco/etc el resto del trabajo se hace en el servidor destino/nuevo, en el destino se debe tener el software de Oracle instalado, hay que configurar el tnsnames.ora para tener acceso a la base fuente, se copia el init.ora del fuente al destino (para tener la misma configuracin) y se hacen los cambios necesarios al archivo (cambiar el destino de los control files, memoria, etc), se agregan al init.ora 2 parmetros para el duplicate (db_file_name_convert y log_file_name_convert), se crea el spfile y se crea un script de RMAN para duplicar la base de datos. El script se ejecuta en la base de datos destino y bsicamente el script o RMAN buscan el backup que hicimos de la fuente y hace un restore al destino de todos los archivos, hace un recover de la base hasta la hora/scn/etc que le digamos y deja la nueva base de datos lista para trabajar con ella. Personalmente este es un mtodo preferido para hacer refresh de ambientes por ejemplo de produccion a QA o desarrollo, es rpido (bueno depende de ciertos factores red/servidor/discos/etc) y sencillo ya que una vez teniendo los scripts es solo cuestin de ejecutarlos y RMAN se encarga de todo. NOTA.- Muchsimos pasos no son mencionados y cierta configuracion se tiene que hacer para que esto funcione correctamente. Backup/Restore

Es muy similar al Duplicate pero casi todos los pasos los tenemos que hacer manualmente, hacer un backup del fuente, hacer el restore en el destino, recrear control files, hacer recover,etc. Copy a nivel SAN.

Esta opcin es ideal cuando se tienen bases de datos grandes (GB a TB+), en esencia la copia de la informacin se hace a nivel de hardware/discos. Si la base de datos fuente y destino estn en una SAN entonces solo hay que copiar los discos que contienen la base de datos fuente a los discos que van a contener la base de datos destino. Todo esto se hace por medio del sistema operativo y regularmente lo hacen los encargados de los servidores. La participacin del DBA en esta opcin es mnima, solo hay que poner los tablespaces en la base de datos fuente en modo backup, se hace la copia a nivel hardware, una vez terminada la copia se quita el modo backup de la fuente, se envian

los archivos del archive de la fuente al destino (de preferencia se hace un log switch) y en el destino se recrean los control files si es necesario y se hace un recover (aqu va a preguntar por los archives que acabamos de copiar) y listo, la BD queda funcional.

Mrale estas pginas http://interdata.cl/?p=754 http://todoprestashop.com/uploads/migrar_sql.pdf http://www.slideshare.net/carlosgruiz.arahat/mejores-prcticas-para-migracin-de-bases-de-datos

BIBLIOGRAFA: http://es.wikipedia.org/wiki/Migraci%C3%B3n_de_datos http://www.desarrolloweb.com/articulos/1231.php http://delfinonunez.wordpress.com/2009/07/13/como-migrarcopiar-una-base-de-datos-a-otroservidor/ http://www.desarrolloweb.com/articulos/867.php