Resumen ejecutivo- ATI 3.09 – Felicitas Ahumada

Resumen ejecutivo- ATI 3.09 – Felicitas Ahumada
Migracion de datos del SENASA desde la actual plataforma Postgress SQL a la plataforma ORACLE
La actividad corresponde a las que estaban previstas en el POA 4 sin embargo
mediante nota 783 del 6 de Agosto de 2010, la Delegación ha aprobado una
ampliación de la asistencia técnica internacional para el POA 3 incorporando la
presente y otras ATIs a la misma ampliación.
La ATI para esta actividad prevé un aporte total de 110 días personas. La actividad
corresponde a las previstas en el POA x.
La ATI deberá realizar el proceso de migración de la plataforma de base de datos
(Postgress a Oracle) del Organismo, contando de esta manera, con una tecnología
acorde a los requerimientos de confiabilidad, integridad, escalabilidad y soporte que
demandan los sistemas informáticos desarrollados bajo los lineamientos técnicos de la
Coordinación de Gestión Técnica.
Objetivos Generales – Componente 3, Actividad 4 (POA 3)
La plataforma de la base de datos del organismo ha tenido un proceso de migración
contando con los requerimientos de confiabilidad, integridad, escalabilidad y soporte
que demandan los sistemas informáticos, teniendo en cuenta los lineamientos técnicos
del Organismo.
Obj. específico 1. Analizar la estructura de datos existentes, proponer y crear una nueva
estructura sobre la tecnología Oracle. Planificar las tareas necesarias para la migración de los
datos existentes a esa nueva estructura de datos. Migrar los datos existentes. Verificar el
correcto funcionamiento de los sistemas luego de la migración, realizar los ajustes y tareas
conexas pertinentes.
Actividades Específicas
1. Analizar la estructura de datos existente en los ambientes de producción,
desarrollo y testing.
2. Diseñar una nueva infraestructura utilizando la tecnología y herramientas
ORACLE
3. Crear los nuevos ambientes utilizando la tecnología y herramientas ORACLE
y el diseño definido en el punto anterior.
4. Crear, en este nuevo ambiente, las estructuras de datos tanto físicas como
lógicas.
5. Realizar las pruebas iterativas de migración: integración, funcionalidad y
performance.
6. Realizar el armado del Plan de Migración, donde se encuentren definidas
tares y el cronograma de ejecución de la migración.
7. Ejecutar la migración de los datos a la nueva estructura.
8. Realizar los ajustes del nuevo ambiente operativo: Tunning, backup y
restore, scripts de monitoreo y alertas.
2.2
Duración y principales actividades realizadas
El Consultor inició sus tareas el 18 de Octubre de 2010, en las oficinas del Programa de Apoyo
en la Casa Central del SENASA, Paseo Colón 315, sexto piso de la Ciudad Autónoma de
Buenos Aires, Argentina, finalizando el 21 Mayo de 2011, detallándose a continuación las
principales actividades realizadas:


18 de Octubre de 2010. Inicio de las actividades. Reunión del Consultor en las oficinas
del Programa de Apoyo en la Casa Central del SENASA, Paseo Colón 315, sexto piso
de la Ciudad Autónoma de Buenos Aires, Argentina con el Lic. Roberto Bensi sobre los
lineamientos generales del trabajo.
El mismo día, reunión con Guillermo Capelli, de Gestión Técnica del SENASA, quien es
el referente técnico para este proyecto.
Se comenzó a partir de ese momento a realizar el relevamiento de información de la
infraestructura Técnica corriente al momento, consultando a Guillermo en todo momento.

















Se trabajó en configurar una notebook con las herramientas necesarias para trabajar en
el proyecto, esto es software de conexión a la red, software cliente para PostgreSql (
pgAdmin) y para Oracle (cliente Oracle, Oracle Developer).
Se analizó la base Oracle que ya estaba creada en uno de los servidores y se decidió
que se utilizaría para el ambiente de testeo, la misma contiene el ambiente de trabajo del
DW.
Se analizó el uso de la herramienta Pentaho para la conversión de la tecnología de BD
de PostgreSql a Oracle, la misma fue descartada.
Se comenzó a trabajar en el relevamiento de los diferentes tipos de objetos y cantidades
utilizados por todas las aplicaciones en PostgreSql. El SENASA no contaba con esta
información, con lo que se documentó y entregó (ver documento: Listado de objetos por
aplicacion.xls). Este documento se usó como base para la migración.
Se acordó con Guillermo la conversión de tipos de datos que se usaría en la migración y
el criterio a utilizar para los nombres de objetos que superaban los 30 carateres máximos
que permite Oracle.
Se hizo un análisis y recomendación, por pedido del SENASA, del conjunto de
caracteres que se utilizaría para las BD Oracle.
Se comenzó a trabajar en los scripts bases (similar a un template) para la generación de
los objetos usando la sintaxis Oracle. Luego usando éstos se comenzó a generar el
código para crear todos los objetos de las aplicaciones. Al mismo tiempo se crearon los
scripts de asignación de privilegios acorde al esquema de seguridad que define Oracle.
Se creó la BD DESA, dedicada al ambiente de desarrollo.
Se comenzó a crear los objetos por aplicación en la BD DESA.
Se trabajó en la creación de los scripts (templates de carga) para la carga de datos al
momento de la migración.
Se fueron creando los ambientes completos (objetos , privilegios y datos mínimos
(parámetros) necesarios para que los desarrolladores compilen las aplicaciones usando
la BD Oracle.
Se trabajó en tareas específicas de Administración de BD, primeramente se definió la
política de resguardos acorde a las necesidades del SENASA. Luego se configuró la
herramienta RMAN que Oracle tiene para el manejo de resguardos y restauración de BD.
Se creó una BD dedicada al RMAN, esta contiene el catálogo donde se guarda toda la
información de los resguardos. Se crearon los scripts para la ejecución de los resguardos
y se configuró para su ejecución automática. Se realizaron diferentes escenarios de
pruebas de restauración.
Los desarrolladores comenzaron los testeos de las aplicaciones y se trabajó con ellos
dándoles soporte para solucionar los errores que surgieran.
Se trabajó Instalación PSU en el servidor dedicado para las BD de desarrollo y test, se
aplicó la última versión de parche disponible. Se redactó el procedimiento/instructivo para
realizar esta tarea, se entregó y explicó a los técnicos del SENASA que realizarán esta
tarea de mantenimiento.
Se configuró la BD TEST, a medida que los desarrolladores confirmaban que las
aplicaciones funcionaban correctamente en el ambiente de desarrollo (BD DESA) , se
fueron creando los objetos en la BD TEST y se fueron realizando la carga completa de
datos; usando los scripts de carga antes mencionados y los datos de la BD de
producción de PostgreSql, con el objeto de realizar nuevos testeos a las aplicaciones con
todos los datos cargados, probar nuevamente los scripts de carga y tomar los tiempos
que tomarían los mismos. Esta información permitiría la planificación de las tareas al
momento de realizar la migración al ambiente de producción.
Se comenzó a trabajar en la creación del ambiente de producción, se redactó un
instructivo para la instalación y configuración del software del motor de BD Oracle y
creación de la base de datos PROD (ambiente producción), se entregó a Gestión
Técnica y se realizó conjuntamente con ellos, la instalación y creación de la BD. Se
optimizó la parametrización de la misma.
Finalmente se comenzó la migración a producción de las aplicaciones, el SENASA fue
definiendo el orden de cómo se migrarían las mismas.