Oracle RAC (migración rápida 10g a 11g) REAL

Describiremos los pasos reales en la migración a Oracle 11g GridInfraestructure a partir de una instalación Oracle RAC 10g,  a partir de la idea de migración del post: http://www.soportedba.com/2011/12/oracle-rac-migracion-rapida-10g-11g.html

Estos pasos también servirían por ejemplo, si ocurre una catástrofe en el RAC antiguo y se pierden todos los nodos y backups (quedando sólo el acceso al almacenamiento).


Pasos básicos para el upgrade de la bbdd: http://onlineappsdba.com/index.php/2009/01/22/upgrade-oracle-database-10g-to-11g-r1-111x/

Antes de la migración se debe “registrar” la bbdd en el RAC, para ello simulamos la creación de una bbdd en otro grupo de discos FRA por ejemplo, con el mismo nombre , para posteriormente cambiar directamente el spfile y los recursos asociados, aunque se podría hacer de otra forma, registrando bien los recursos ...
 
Se hace el switch del init de la bbdd "initdbmaq1.ora" por el antigo pfile (cambiando varios parámetros como cluster_database=no, compatible=11.1.0, eliminar user_dump_dest, backgroup_dump..., etc)


En el proceso de migración, el “catupgrd.sql” se obtiene el error:

TO_NUMBER(value$) != (SELECT tz_version from registry$database))
*
ERROR at line 6:
ORA-00942: table or view does not exist

Que se evitaría habiendo lanzado los pasos previos (motor de la 10g ejecutando el utlu112i.sql) pero como no lo hicimos, lo que se hace es eliminar la comprobación del TZ_VERSION del script que llama el catupgrd.sql que se llama “catupstr.sql”, parece que el proceso de migración avanza correctamente, aunque está claro que podrá haber corrupción en datos almacenados con Timezone o similar.

Ejecución del script upgrade principal correcta:

@?/rdbms/admin/catupgrd.sql

Tras la ejecución de los últimos scripts:

@?/rdbms/admin/utlu112s.sql
@?/rdbms/admin/catuppst.sql
@?/rdbms/admin/utlrp.sql

Todo correcto y todo compilado.

Ahora cambiamos el init para que se utilice el +DATA

create spfile=’+DATA’ from pfile;

ponemos en los initdbmaqX.ora :

SPFILE=’+DATA/DBMAQ/initdbmaq.ora’

Todo arranca y funciona correctamente.

Para deregistrar el spfile y que tenga en cuenta el grupo DATA, (en otro caso, en los arranque se sustituye automáticamente el init* por los de la preinstalación previa apuntando al FRA)
 
srvctl modify database -d dbmaq -p ' ' -a "DATA,FRA"

(ver http://oraganism.wordpress.com/2010/01/02/srvctl-p-option/)

Arracamos el dbconsole:
 
emctl start dbconsole

Aparece un error que evita podamos acceder, recreamos la key:

emctl config emkey -repos -force

Todo correcto, el acceso a los datos correcto, el acceso al EM Database Control correcto.