A pesar de que ya la edición de Oracle Database Versión 11g, tiene bastantes años de haber sido liberada en el mercado, aún tiene lugar una mayor porción de fundamentos de datos, corriendo en versiones previos a la revisión actual vigente ( 11.2.0.3 ), o inclusive en versiones previos como Oracle 10g, 9i, 8i, etc. La porción de documentos escritos sobre el asunto 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 abandonar para después, ocasionando serios trastornos en vuestro ámbito operativo. Empecemos a beber los próximos puntos en cuenta: Evalúe de forma objetiva, su sistema operativo. DOS Gráfico, no debería ser vuestro sistema operativo, para vuestra fundamento de datos de producción. Por seguridad, por rendimiento y por "n" porción de argumentos, lo ideal, sería que utilicemos determinado sabor LINUX de vuestra 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 necesita ser licenciado y si quiere conseguir soporte al mismo estilo de los proyectos 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 dificultades en 64Bits, pero pierdes funcionalidades importantes. A la inversa no es probable realizar la instalación. Evite los yerros tradicionales de capa 8. Tradicionalmente, me gusta mucho, crear primero el esqueleto de la fundamento 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 yerros muy comunes, en la importación de la fundamento de datos. No se agote. Hace muchos años atrás, acostumbramos a quedarnos velando la importación de la fundamento de datos. Si haces el punto 3, verificas el lugar en disco, tienes suficiente memoria y tu servidor esta conectado a una UPS, deja corriendo el respaldo y anda descansa. Habilita determinado recurso para conectarte remotamente al servidor, para monitorear el avance del proceso. Si tienes determinado agente de riesgo, prepara un buen termo o coffe marker con cafecito y que tengas una feliz noche. Cuando hagas el full export de la fundamento de datos, exporta los objetos "Sin Estadísticas". Por cierta extraña razón, he logrado detectar, que si haces el import con los objetos sin estadísticas en una fundamento de datos Oracle 11g, desminuye considerablemente el tiempo de importación de los datos. Si vas a migrar a 11gR2, emplea la última edición disponible del software. No instales 11.2.0.1, despues importas los datos y despues parches a 11.2.0.3. Recuerda que en 11g, las ediciones son sustituciones completas de software, no es requerido instalar la edición fundamento de una versión y despues parcharla. Antes de descartar la instancia actual de la fundamento de datos, genera un listado con todos los paquetes inválidos antes del momento de hacer la migración o recreación de la fundamento de datos, para que tengas un punto de partida con determinado nivel de certeza, del estado de salud de todos tus procedimientos, paquetes, funciones y vistas. Cuando hallas terminado de realizar el import, verifica siempre el log del mismo y ejecuta el script de compilación común de objetos. Es normal, que después de un proceso de importación, algunos objetos queden inválidos. El mismo se descubre en ?/rdbms/admin/utlrp.sql Cuando termines de hacer la compilación de objetos inválidos, baja la fundamento de datos, reinicia el servidor. Calcula manualmente estadísticas para todos los objetos de la fundamento de datos, ajusta el dimensión del tablespace temporal y UNDO, que podrían haber crecido considerablemente y entonces, procede a hacer las pruebas de conexión de tus clientes. Si no realizaste una full recreación de la fundamento 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 fundamento 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 iniciar a utilizar tu fundamento de datos nueva en 11g. Si estas haciendo una migración desde Oracle 9i con tu asistente, es significativo 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 fundamento de datos, tarde más de 40 minutos adicionales en el proceso de migración. Los parámetros son: _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? Importante, si tus aplicaciones son cliente/servidor con Developer 6i, requieres 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 fundamento de datos, para buscar comportamientos indebidos de SQLs en ejecución. Los planes de ejecución ( explain plan ), podrían haber cambiado, con la manera de ser interpretados por el optimizador de consultas de la fundamento de datos y es probable que tengas que realizar algunos ajustes a los mismos. Si tu fundamento de datos, es más OLTP que OLAP, te recomiendo 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 preliminarmente para poder ser utilizados y sólo se pueden usar con la edición Enterprise Edition de la fundamento de datos. No arriesgues la seguridad de tu compañía a multas y procesos legales de cobro, por utilizar características que no forman fracción de la edición de tu motor de fundamento 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 colocar a la gente a generar nueva información. Jamás en un proceso de migración o importación, habilites el modo "Archive" de la fundamento de datos. Si lo tienes habilitado, apagarlo antes de empezar este proceso, es un buen consejo. Documenta cada paso de la migración, así si debes volverlo a hacer o algo no salió como pensabas, puedes revisar la bitácora y descubrir el punto en donde cometiste el error. Estos 20 consejos, pueden ser de mucha utilidad si lo sigues al pie de la letra.