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 existe una gran cantidad de bases de
datos, corriendo en versiones anteriores a la revisi�n actual vigente ( 11.2.0.3 ),
o incluso en versiones anteriores como Oracle 10g, 9i, 8i, etc.

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:

_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, 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.
Estos 20 consejos, pueden ser de mucha utilidad si lo sigues al pie de la letra.