Dependiendo del tipo de iniciativa que se quiera llevar a cabo, es necesario un

planteamiento distinto. Así, podría hablarse de tres formas diferentes de abordar el

data migration:
Usando un software basado en matriz, que es la mejor opción para el movimiento
de datos entre sistemas similares.

Apoyándose en un software basado en el host: que sería la opción más

recomendable para las migraciones específicas de la aplicación. Es el caso de la
copia de archivos, las actualizaciones de la plataforma o la replicación de la base
de datos. Empleando los dispositivos de red. De esta manera, se migran volúmenes,
archivos o bloques de datos del modo más apropiado, en función de su
configuración. Hay algunos factores que se deben considerar en un proyecto de
migración de datos:

 Tiempo que llevará realizar la migración completa.

 Cantidad de tiempo de inactividad que se requerirá.

Riesgo para el negocio derivado de problemas técnicos de compatibilidad,

corrupción de datos, problemas de rendimiento de aplicaciones y pérdida u omisión
de datos. Para minimizar el riesgo inherente al movimiento de datos, es preciso:
Entender qué datos se está migrando, de qué tipo son, cuál es su origen y qué
formato adquirirán en destino, una vez completado el traslado.
Aplicar los procesos ETL (extracción, transformación y carga) preferiblemente antes
de proceder a la migración.
Definir e implementar políticas de migración de datos para garantizar el orden
necesario a lo largo de todo el proceso.
Apostar por las pruebas y validación de los datos migrados, por ser la única manera
efectiva de asegurarse de que reúnen todos los atributos de calidad necesarios.
 ETAPAS DE UNA MIGRACIÓN DE BASES DE DATOS

Tendremos que actuar con el rigor de la operación desde el principio podemos o no

incluir todas las etapas que la migración de datos posee.
Las etapas que se poseen son:

Descubrimiento y análisis

Evaluaremos y comprendemos los datos existentes para así enviarlos al nuevo

sistema. Determinaremos su calidad y origen para detectar los posibles errores y
datos.
En esta parte debemos tener en cuenta esto:
Trabajar sobre la totalidad de los datos
Obtener la guía de trabajo de la base de datos
Validación de la migración.

¿Cómo llevamos a cabo el análisis de datos en la migración? Para poder llevar un

buen análisis de datos tenemos que conocer muy bien el funcionamiento de la base
de datos de la empresa no solo por entidades sino por correlaciones, campo a
campo con el nuevo sistema. Ya con esto claro perfilamos los datos para verificar
la efectividad y calidad de los datos para así evitar claves primarias duplicadas,
tener términos con el mismo concepto o nombre, inconsistencia o datos con
campos vacíos.
Calidad de datos

 En esta parte podemos encontrar las siguientes etapas:

 Limpiar datos de la base antigua: aquí eliminamos los errores, duplicidad e

inconsistencias que puede poseer la base.

 Homogenializarlos: se garantizará que todos los conceptos trabajaran con

una llave única para evitar los posibles errores.

 Enriquecerlos: se completarán y se dotarán de la adecuación necesaria para

garantizar la consistencia, fiabilidad e integridad de los bases de datos.

Conversión

Aquí transformaremos los datos orígenes para adecuarlos al modo en el cual se

necesitará para el sistema nuevo. Se prepararán los datos para cargarlos en la
nueva estructura y por eso necesitamos convertirlos de acuerdo a las reglas de la
empresa y a las configuraciones del sistema actual y del sistema futuro.

¿Cuáles son las claves de una conversión exitosa e impecable? Para poder llegar
a una conversión exitosa e impecable asumimos que ya se reconoció los
requerimientos de los datos en el destino, dominaremos la base, incorporaremos la
fase conversión en cada uno de casos para adquirir una referencia que será útil
para la planificación como para el seguimiento del proyecto, emplear datos
verdaderos y sobre todo como último y con mayor importancia la calidad de los
datos con garantías ya que los resultados sustentaran las etapas anteriormente
nombradas.
Mapeo y Carga

Aquí ya estarán convertidos los datos para ser cargados en el nuevo sistema. Este
proceso lo podernos realizar de una manera directa o de una manera intermedia
donde podemos validar y someter a los datos a unos ciclos de pruebas y a diferentes
simulaciones de carga, para hacer y decir que el proceso de migración de bases de
datos son un éxito y que de esta manera no perdamos la productividad y
ganar una mayor agilidad en los datos para así poder optimizar y minimizar riesgos
en cualquier operación. Ya llegando a este proceso y si la planificación fue exitosa,
los datos trabajaran de manera exhaustiva, no habrá ninguna dificultad, y los
datos no demoran mucho, si no sucede esto, entonces será necesario ir volviendo
hacia atrás en todos los pasos dados hasta encontrar el origen de las
inconsistencias que requiere de soluciones.

Los riesgos de no hacer los debidos pasos para una buena migración se verán
afectados desde la selección de herramientas, la rapidez de la información y sobre
todo la calidad de la información por esto debemos contar con los medios
adecuados para tener una migración exitosa, si no se hace los debidos
procedimientos este cambio será muy peligroso.
 TECNICAS EXISTENTES EN UNA MIGRACION DE BASES DE DATOS

Existen técnicas utilizadas en procesos de migración, los cuales consisten en hacer

que dos bases de datos sean equivalentes en el mismo tiempo.
Algunas de estas técnicas se encuentran:

Sincronización de bases de datos

Esto se logrará con la copia de datos y metadatos destino mediante una herramienta
tecnológica, en la cual se configuran los sistemas de gestión de bases de datos con
bases de datos origen y destino parametrizando la ubicación de particiones y
método de seguridad.
Importación y Exportación de archivos a través de comandos

Para estas actividades es común utilizar los archivos de movimientos de datos, en

los cuales se pueden utilizar diferentes tipos de archivos, pero algunos de los
formatos más comunes son archivos de texto o lo que comúnmente llamamos
archivos planos estos archivos son los que guardan los datos sin ningún formato
usando solo caracteres. Estos archivos son delimitados por comas por puntos y
comas o se delimitan para los campos y así poder definir las filas y las columnas,
como también se puede elegir el ancho para los campos, los cuales utilizaremos
para delimitar las filas y las columnas.

Los formatos más utilizados en las migraciones de datos son el Comma-separated-

values (que son los valores separados por comas o los comúnmente .CVS donde
para delimitarlos es usada la coma el otro formato utilizado es el lenguaje de
marcado extensible este es usado como lenguaje o metalenguaje extensible de
etiquetas las cuales sirven como estándar para el intercambio de información o
datos estructurados entre distintas plataformas. Su sigla en inglés es .XML.
El otro formato utilizado es la tabulación, estos archivos con esta tabulación y esta
extensión solo son utilizados en ciertas aplicaciones es posible que sean archivos
de datos mas no de documentos o medios de comunicación lo que no se pueden
ver en ciertas circunstancias o programas, este formato de tipo de texto será
utilizado en la tabulación o espacios para separar las columnas o filas de los datos
por esto no se recomienda este tipo de formato debido a que generan muchos tipos
de caracteres en blanco y para poder hacer coincidir las filas y las columnas con las
siguientes correspondiente al campo.
Sentencias de lenguaje de manipulación de datos (DML)

estas sentencias son utilizadas para gestionar datos dentro de schemas. Una
posibilidad de los sistemas gestores de datos es la utilización de esta sentencia para
generar los respectivos scripts SQL que permiten realizar las migraciones
existentes.

Scripts generados por sentencias DML

Los scripts que se generan en esta sentencia se realizarían de la siguiente

manera:

 Copia de Seguridad: en esta encontramos la copia de seguridad de los

usuarios que se encuentren, los inicios de sesión, los grupos y todos los
permisos que se hayan generado
 Creación o actualización de Datos: aquí se crea o se actualiza el código
según sea necesario para la implementación de una base de datos.
 Creación de entorno de pruebas: En esta parte se hace las pruebas de
fallo y error para que en el momento de la migración definitiva no se
presente ningún fallo y funcione bien la base de datos.
 Procedimientos de Extracción, Transformación, Limpieza y carga de
datos: encontramos los procedimientos que organizan el flujo de los datos
entre diferentes sistemas en una organización y aporta los métodos y
herramientas necesarias para mover los datos desde múltiples fuentes a un
almacén de datos, reformatearlos, limpiarlos y cargarlos en otra base de
datos, Data Mart o bodega de Datos.

Las funciones de este sistema son la carga inicial de mantenimiento o refresco

periódico que puede ser diario semanal, trimestral o mensual. El almacenamiento
interno permite realizar transformaciones sin la necesidad de paralizar la base de
datos operacionales y el almacén de datos, también se permite almacenar
metadatos y sobre todo la facilidad de integración de fuentes externas.
Los procedimientos o pasos necesarios para el desarrollo de un proceso de
migración de bases de datos utilizando una metodología de extracción,
transformación, limpieza y carga de datos (ETCL) son:
 ESTRATEGIAS DE MIGRACION DE BASES DE DATOS

Al hablar de estrategias de migración se habla de las acciones muy meditadas para

la efectividad de la migración de datos las cuales resultan efectivas de acuerdo a
los diferentes entornos de las empresas o condiciones técnicas de los diferentes
sistemas. Para ello se hablarán las más conocidas como lo son:

EJECUCION EN PARALELO
Esta estrategia validará por un tiempo en el cual se estipularán los resultados que
tiene el nuevo sistema comparándolo con el anterior, corriendo de manera paralela
los dos sistemas, un ejemplo de ello es la siguiente gráfica:
MIGRACION INCREMENTAL

Los sistemas se activan en una forma incremental de acuerdo como se hacen las
migraciones, aquí no esperamos que nuestro sistema esté listo, sino que vamos
implementándolo. Es decir, trabajando la base al mismo tiempo como lo veremos
en la siguiente gráfica:

BIG BANG

Esta estrategia consiste en seguir usando el sistema actual mientras

implementamos el nuevo es decir la base de datos anterior no la desactivamos.
Por ello aquí requerimos hacer estrategias y trabajar haciendo pruebas en el nuevo
sistema mientras realizamos toda la migración de los datos.
 Data Pump

a. Arquitectura
Data Pump es una utilidad servidor que puede utilizarse para mover datos y/o
metadatos (definiciones) entre las bases de datos Oracle.

Data Pump tiene tres elementos:

un paquete PL/SQL DBMS_DATAPUMP;

un paquete PL/SQL DBMS_METADATA;

dos herramientas cliente de línea de comandos expdp (exportación) y impdp

(importación).

Las herramientas cliente expdp y impdp sirven de interfaz con el paquete

DBMS_DATAPUMP que es, en cierta manera, el API (Aplicación Programming
Interface) de Data Pump. Este paquete está completamente documentado, lo que
permite utilizar directamente las funcionalidades Data Pump en un programa. Data
Pump puede también utilizarse a partir de Database Control.
Las operaciones propiamente dichas de exportación y de importación se efectúan
con el paquete DBMS_DATAPUMP y, por lo tanto, en el servidor Oracle. Esto
incluye fundamentalmente la lectura y/o la escritura de los ficheros: los ficheros
generados en una exportación se escriben en el servidor y los ficheros cargados en
una importación se leen del servidor. El acceso a los ficheros del servidor se efectúa
gracias a los objetos DIRECTORY; un objeto DIRECTORY es un alias hacia un
repositorio del sistema operativo. Estos objetos DIRECTORY se deben crear por el
DBA (véase El objeto DIRECTORY).
En el momento en que un trabajo Data Pump se crea, Oracle crea diferentes
estructuras para gestionar la operación, entre ellas:

una tabla llamada "maestra" en el esquema.

Tabla de Exportaciones / Importaciones

El TABLESparámetro se utiliza para especificar las tablas que se van a exportar. A

continuación se muestra un ejemplo de la sintaxis de exportación e importación de
tablas.

expdp scott / tiger @ db10g tables = EMP, DEPT directory = TEST_DIR dumpfile =
EMP_DEPT.dmp logfile = expdpEMP_DEPT.log

impdp scott / tiger @ db10g tables = EMP, DEPT directory = TEST_DIR dumpfile =
EMP_DEPT.dmp logfile = impdpEMP_DEPT.log
Por ejemplo, los archivos de salida
ven expdpEMP_DEPT.log e impdpEMP_DEPT.log .

El TABLE_EXISTS_ACTION=APPENDparámetro permite importar datos a tablas

existentes.

Esquema Exportaciones / Importaciones

El OWNERparámetro de exp ha sido reemplazado por el SCHEMASparámetro

que se usa para especificar los esquemas a exportar. El siguiente es un ejemplo
de la sintaxis de exportación e importación de esquemas.

expdp scott / tiger @ db10g schemas = SCOTT directory = TEST_DIR dumpfile =

SCOTT.dmp logfile = expdpSCOTT.log

impdp scott / tiger @ db10g schemas = SCOTT directory = TEST_DIR dumpfile =

SCOTT.dmp logfile = impdpSCOTT.log
Por ejemplo, los archivos de salida ven expdpSCOTT.log e impdpSCOTT.log .

Base de datos Exportaciones / Importaciones

El FULLparámetro indica que se requiere una exportación completa de la base de

datos. El siguiente es un ejemplo de la sintaxis completa de exportación e
importación de la base de datos.

expdp system / password @ db10g full = Y directory = TEST_DIR dumpfile =

DB10G.dmp logfile = expdpDB10G.log

impdp system / password @ db10g full = Y directory = TEST_DIR dumpfile =

DB10G.dmp logfile = impdpDB10G.log
Para ver un archivo de salida de ejemplo, consulte expdpDB10G.log .
El usuario de la base de datos que realice la exportación necesitará
el DATAPUMP_EXP_FULL_DATABASErol, y el usuario que realice la importación
necesitará el DATAPUMP_IMP_FULL_DATABASErol.

INCLUYE y EXCLUYE

Los parámetros INCLUDEy EXCLUDEse pueden usar para limitar la exportación /

importación a objetos específicos. Cuando INCLUDEse utiliza el parámetro, solo
los objetos especificados por él se incluirán en la exportación /
importación. Cuando EXCLUDEse utiliza el parámetro, todos los objetos, excepto
los especificados por él, se incluirán en la exportación / importación. Los dos
parámetros se excluyen mutuamente, así que use el parámetro que requiera las
entradas mínimas para obtener el resultado que necesita. La sintaxis básica para
ambos parámetros es la misma.

INCLUYE = object_type [: name_clause] [, ...]

EXCLUDE = object_type [: name_clause] [, ...]
El siguiente código muestra cómo se pueden usar como parámetros de la línea de
comandos.

expdp scott / tiger @ db10g schemas = SCOTT include = TABLE: "IN ('EMP',
'DEPT')" directory = TEST_DIR dumpfile = SCOTT.dmp logfile = expdpSCOTT.log

expdp scott / tiger @ db10g schemas = SCOTT exclude = TABLE: "= 'BONUS'"
directory = TEST_DIR dumpfile = SCOTT.dmp logfile = expdpSCOTT.log
Si el parámetro se usa desde la línea de comandos, dependiendo de su sistema
operativo, los caracteres especiales en la cláusula pueden necesitar ser
escapados, de la siguiente manera. Debido a esto, es más fácil usar un archivo de
parámetros.

include = TABLE: \ "IN (\ 'EMP \', \ 'DEPT \') \"

Una sola importación / exportación puede incluir múltiples referencias a los
parámetros, por lo que para exportar tablas, vistas y algunos paquetes podríamos
usar cualquiera de los siguientes métodos.

INCLUYE = TABLE, VIEW, PACKAGE: "LIKE '% API'"

INCLUYE = TABLA
INCLUYE = VER
INCLUYE = PAQUETE: "ME GUSTA '% API'"
Se pueden apuntar varios objetos en una sola declaración utilizando
los operadores LIKEy IN.

EXCLUDE = SCHEMA: "LIKE 'SYS%'"

EXCLUDE = ESQUEMA: "IN ('OUTLN', 'SYSTEM', 'SYSMAN', 'FLOWS_FILES',

'APEX_030200', 'APEX_PUBLIC_USER', 'ANONYMOUS')"
Las trayectorias de tipo de objeto válidos que pueden ser incluidos o excluidos se
pueden visualizar utilizando
los DATABASE_EXPORT_OBJECTS, SCHEMA_EXPORT_OBJECTSy TABLE_E
XPORT_OBJECTSpuntos de vista.

Contenido y consulta

El CONTENTparámetro le permite alterar los contenidos de la exportación. El

siguiente comando utiliza el METADATA_ONLYvalor del parámetro para exportar
el contenido del esquema sin los datos.

expdp system / password @ db10g schemas = directorio SCOTT = TEST_DIR

dumpfile = scott_meta.dmp logfile = expdp.log content = METADATA_ONLY
Para capturar los datos sin los metadatos use el DATA_ONLYvalor del parámetro.

expdp system / password @ db10g schemas = directorio SCOTT = TEST_DIR

dumpfile = scott_data.dmp logfile = expdp.log content = DATA_ONLY
El QUERYparámetro le permite alterar las filas exportadas desde una o más
tablas. El siguiente ejemplo realiza una exportación completa de la base de datos,
pero no incluye los datos para las tablas EMP y DEPT.
expdp system / password @ db10g full = directorio Y = TEST_DIR dumpfile =
full.dmp logfile = expdp_full.log query = 'SCOTT.EMP: "WHERE deptno = 0",
SCOTT.DEPT: "WHERE deptno = 0"'
La forma en que maneje las comillas en la línea de comando variará según lo que
esté tratando de lograr. Aquí hay algunos ejemplos que funcionan para tablas
individuales y varias tablas directamente desde la línea de comandos.

# Mesa única. Múltiples métodos de cotización posibles.

expdp scott / tiger @ pdb1 schemas = scott directory = TEST_DIR dumpfile =
scott1.dmp logfile = scott1.log query = SCOTT.EMP: '"DONDE deptno = 10"'
expdp scott / tiger @ pdb1 schemas = scott directory = TEST_DIR dumpfile =
scott2.dmp logfile = scott2.log query = SCOTT.EMP: \ "WHERE deptno = 10 \"
expdp scott / tiger @ pdb1 schemas = scott directory = TEST_DIR dumpfile =
scott3.dmp logfile = scott3.log query = 'SCOTT.EMP: "DONDE deptno = 10"'

# Cláusula WHERE múltiple en cada tabla.

expdp scott / tiger @ pdb1 schemas = scott directory = TEST_DIR dumpfile =
scott4.dmp logfile = scott4.log query = 'SCOTT.EMP: "WHERE deptno = 10",
SCOTT.DEPT: "WHERE deptno = 20"'