La cantidad de documentos escritos sobre el tema de migraciones es bastante extenso, pero el mensaje aún no ha llegado a todo el mundo.
Y es que esperamos con ansiedad, que cada migración que realizamos, traiga consigo, mejor rendimiento, mayores funcionalidades y más estabilidad. Sin embargo, la migración a Oracle 11g, tiene una lista de tareas previas, que por desconocimiento o simplemente por omisión, sólo dejar para después, ocasionando serios trastornos en nuestro entorno operativo.
Empecemos a tomar los siguientes puntos en cuenta:
- Evalúe de manera objetiva, su sistema operativo. DOS Gráfico, no debería ser nuestro sistema operativo, para nuestra base de datos de producción. Por seguridad, por rendimiento y por "n" cantidad de argumentos, lo ideal, sería que utilicemos algún sabor LINUX de nuestra preferencia. Ya sea el sombrerito rojo ( Red Hat ), la iguana verde ( SUSE ) o el pingüinito feliz ( Oracle Enterprise Linux ), tome en consideración, los costos de implementación y soporte, a la hora de migrar de sistema operativo. Recuerde OEL es gratis, no requiere ser licenciado y si desea obtener soporte al mismo estilo de los programas tradicionales de Oracle, los precios del mismo, arrancan en menos de $200 por año, dependiendo del hardware de su servidor. El cambiar de sistema operativo Windows a Linux, representa una mejora en rendimiento de más del 40%, en el mismo hardware, por experiencias vividas.
- Verifique que el software disponible para instalación, cumple con las características de arquitectura de su hardware. 32 Bits se instala sin problemas en 64Bits, pero pierdes funcionalidades importantes. A la inversa no es posible hacer la instalación.
- Eliga la mejor metodología de migración. De mi parte, nunca me ha gustado migrar el software con el migrar de la base de datos. Prefiero hacer un full export de toda la base de datos, raspar el equipo, instalar el nuevo software del motor y luego hacer la importación de la data.
- Evite los errores tradicionales de capa 8. Tradicionalmente, me gusta mucho, crear primero el esqueleto de la base de datos en la instancia nueva, así me aseguro que todos los tablespaces y sus respectivos datafiles, quedaran en la ubicación física que deseo. Este paso, siempre me ha ganada mucho tiempo y errores muy comunes, en la importación de la base de datos.
- No se agote. Hace muchos años atrás, acostumbramos a quedarnos velando la importación de la base de datos. Si haces el punto 3, verificas el espacio en disco, tienes suficiente memoria y tu servidor esta conectado a una UPS, deja corriendo el respaldo y anda descansa. Habilita algún medio para conectarte remotamente al servidor, para monitorear el avance del proceso. Si tienes algún factor de riesgo, prepara un buen termo o coffe marker con cafecito y que tengas una feliz noche.
- Cuando hagas el full export de la base de datos, exporta los objetos "Sin Estadísticas". Por alguna extraña razón, he logrado detectar, que si haces el import con los objetos sin estadísticas en una base de datos Oracle 11g, desminuye considerablemente el tiempo de importación de los datos.
- Si vas a migrar a 11gR2, utiliza la última edición disponible del software. No instales 11.2.0.1, luego importas los datos y luego parches a 11.2.0.3. Recuerda que en 11g, las ediciones son sustituciones completas de software, no es requerido instalar la edición base de una versión y luego parcharla.
- Antes de eliminar la instancia actual de la base de datos, genera un listado con todos los paquetes inválidos antes del momento de realizar la migración o recreación de la base de datos, para que tengas un punto de partida con algún nivel de certeza, del estado de salud de todos tus procedimientos, paquetes, funciones y vistas.
- Cuando hallas terminado de hacer el import, verifica siempre el log del mismo y ejecuta el script de compilación general de objetos. Es normal, que después de un proceso de importación, algunos objetos queden inválidos. El mismo se encuentra en ?/rdbms/admin/utlrp.sql
- Cuando termines de hacer la compilación de objetos inválidos, baja la base de datos, reinicia el servidor. Calcula manualmente estadísticas para todos los objetos de la base de datos, ajusta el tamaño del tablespace temporal y UNDO, que podrían haber crecido considerablemente y entonces, procede a realizar las pruebas de conexión de tus clientes.
- Si no realizaste una full recreación de la base de datos en una migración de 10g a 11g, procede una vez terminada la migración con el asistente de Oracle, a purgar la papelera de reciclaje de la base de datos, utilizando: purge DBA_RECYCLEBIN;
- También es recomendable que elimines de tu SPFILE, los parámetros viejos o ocultos ( los que empiezan con un "_", antes de empezar a utilizar tu base de datos nueva en 11g.
- Si estas haciendo una migración desde Oracle 9i con tu asistente, es importante que elimines algunos parámetros, que ya no se encuentran dentro de la versión 11g. Estos parámetros podrían ocasionar que tu migracíón a través de tu asistente de base de datos, tarde más de 40 minutos adicionales en el proceso de migración. Los parámetros son:
- Importante, si tus aplicaciones son cliente/servidor con Developer 6i, necesitas al menos el patchset 13 instalado en todos tus clientes. Oracle liberó el año pasado el patchset 19, recomendado para Oracle 11gR2
- Durante un tiempo prudencial, monitorea tu base de datos, para buscar comportamientos indebidos de SQLs en ejecución. Los planes de ejecución ( explain plan ), podrían haber cambiado, con la forma de ser interpretados por el optimizador de consultas de la base de datos y es posible que tengas que hacer algunos ajustes a los mismos.
- Si tu base de datos, es más OLTP que OLAP, te aconsejo ajustar el parámetro optimizer_mode, ya que de facto el valor es ALL_ROWS, en la versión 11gR2.
- Recuerda, los paquetes opcionales que son utilizados por el OEM para administrar, monitorear y demás tareas específicas realizados con ellos, tienen que ser licenciados previamente para poder ser utilizados y sólo se pueden usar con la edición Enterprise Edition de la base de datos. No arriesgues la seguridad de tu empresa a multas y procesos legales de cobro, por utilizar características que no forman parte de la edición de tu motor de base de datos. Documenta eficazmente, que puedes usar y que no, es el mejor consejo que te puedo dar.
- No se te olvide una vez terminada la migración, probar tus tareas de respaldos. Ya sea el clásico utilitario "exp" o el nuevo "expdb" o "RMAN", verifica que están funcionando al 100%, antes de poner a la gente a generar nueva información.
- Nunca en un proceso de migración o importación, habilites el modo "Archive" de la base de datos. Si lo tienes habilitado, apagarlo antes de iniciar este proceso, es un buen consejo.
- Documenta cada paso de la migración, así si debes volverlo a realizar o algo no salió como pensabas, puedes revisar la bitácora y encontrar el punto en donde cometiste el error.
- _complex_view_merging = FALSE
- _multi_join_key_table_lookup = FALSE
- _library_cache_advice = FALSE
- _index_join_enabled = FALSE
- _push_join_union_view = FALSE
- _push_join_predicate = FALSE
- _always_semi_join = OFF
- _pred_move_around = FALSE
- _unnest_subquery = FALSE
- _predicate_elimination_enabled = FALSE
- _eliminate_common_subexpr = FALSE
- _no_or_expansion = FALSE
- event = '600 trace name systemstate level 10'
- event = '600 trace name errorstack level 10'
- event = '942 trace name errorstack level 10'
- event = '54 trace name systemstate level 10'
- event = '54 trace name errorstack level 10'
- event = '7445 trace name systemstate level 10'
- event = '7445 trace name errorstack level 10'
- event = '10195 trace name context forever, level 1'
- event = '10778 trace name context forever, level 1‘
Estos 20 consejos, pueden ser de mucha utilidad si lo sigues al pie de la letra.
