« ORA-12801: error signaled in parallel query serverORA-38760: This database instance failed to turn on flashback database »

SELECT TO_NUMBER('MUST_HAVE_RUN_PRE-UPGRADE_TOOL_FOR_TIMEZONE')




Haciendo una migración/upgrade de bases de datos, al momento de actualizar el catálogo (catupgrd.sql) , me apareció el siguiente error

SELECT TO_NUMBER('MUST_HAVE_RUN_PRE-UPGRADE_TOOL_FOR_TIMEZONE')
*
ERROR at line 1:
ORA-01722: invalid number

Obviamente mi primera impresión fue la de ahorcarme, pero menos mal que no lo hice y simplemente ...aplique una nota Oracle para resolver el tema :>> he acá el relato de los hechos..

- Se tiene una base de datos en versión 10.2.0.2 en ambiente Windows de 32 bits y se quiere migrar a una versión 11.2.0.3 en ambiente Linux de 64 bits

- Se realiza el proceso básico para migrar una base de datos (no es el objetivo de la nota, por eso se explica como un punteo)

  • Se toma un respaldo con RMAN (Full con la base abajo)
  • Se copia al destino (Un scp a la máquina destino)
  • Se procede a levantar una instancia en el destino (Instancia con los parámetros básicos)
  • Se hace la restauración del control file (Restore controlfile from)
  • Se procede a limpiar el controlfile de todos los respaldos anteriores (Crosschek)
  • Se cataloga el respaldo que se copio en el ambiente de restino (Catalog start with)
  • Se realiza una restauración (Restore database con RMAN)
  • Se abre la base de datos en modo upgrade con resetlogs (alter database open resetlogs upgrade)
  • Una vez abierta, se procede a actualizar el catálogo con la ejecución del archivo catupgrd.sql

    - Cuando se ejecuta el archivo de actualización del catálogo , aparece el inefable error

    DOC>#######################################################################
    DOC>#######################################################################
    DOC> The following error is generated if the pre-upgrade tool has not been
    DOC> run in the old ORACLE_HOME home prior to upgrading a pre-11.2 database:
    DOC>
    DOC> SELECT TO_NUMBER('MUST_HAVE_RUN_PRE-UPGRADE_TOOL_FOR_TIMEZONE')
    DOC> *
    DOC> ERROR at line 1:
    DOC> ORA-01722: invalid number
    DOC>
    DOC> o Action:
    DOC> Shutdown database ("alter system checkpoint" and then "shutdown abort").
    DOC> Revert to the original oracle home and start the database.
    DOC> Run pre-upgrade tool against the database.
    DOC> Review and take appropriate actions based on the pre-upgrade
    DOC> output before opening the datatabase in the new software version.
    DOC>
    DOC>#######################################################################
    DOC>#######################################################################
    DOC>#

    Session altered.

    Table created.

    Table altered.

    SELECT TO_NUMBER('MUST_HAVE_RUN_PRE-UPGRADE_TOOL_FOR_TIMEZONE')
    *
    ERROR at line 1:
    ORA-01722: invalid number

    Con lo anterior, deberíamos proceder a abrir nuestra base de datos en el orígen Windows con motor 10.2.0.2, para ejecutar el script utlu112i.sql y hacer todos los cambios pertinentes, pero ....con el respaldo efectuado, en disco... y ya realizada la restauración procedemos a hacer un cambio para no efectuar todo el trabajo nuevamente..

    Solución :

  • Consultamos la tabla registry$database y vemos el valor que contiene

    SQL> select platform_id , platform_name from registry$database;

    PLATFORM_ID PLATFORM_NAME
    ----------- -----------------------------------------
    7 Microsoft Windows IA (32-bit)

  • Debemos borrar la información errónea de la tabla registry$database e incorporar la nueva versión de nuestra base de datos

    delete registry$database;
    commit;

  • Incorporamos la nueva versión de nuestro sistema operativo

    INSERT into registry$database
    (platform_id, platform_name, edition, tz_version)
    VALUES ((select platform_id from v$database),
    (select platform_name from v$database),
    NULL,
    (select version from v$timezone_file))
    ;

  • Chequemos el sistema operativo donde estamos trabajando (destino final de nuestra base de datos)

    SQL> !uname -a
    Linux nodo1-server-A 3.8.13-68.1.2.el6uek.x86_64 #2 SMP Mon Mar 30 11:56:28 PDT 2015 x86_64 x86_64 x86_64 GNU/Linux

  • Chequeamos el valor de nuestra tabla registry$database, que debe coincidir con nuestro sistema operativo

    SQL> select platform_id , platform_name from registry$database;

    PLATFORM_ID PLATFORM_NAME
    ----------- -----------------------------------------
    13 Linux 64-bit for AMD

    Posterior a esos cambios, podemos ejecutar nuestra actualización de catálogo sin problemas..teniendo en cuenta que para este caso en partícular se debe cambiar la base de 32 bits a 64 bits ;)

  • by Ligarius
    23.10.15. 09:32:06. 647 words, 1859 views. Categories: Base de datos ,