PDF de programación - Upgrade Oracle Database versión 11gR1 a 11gR2 en un ambiente e-Business Suite R12

Upgrade Oracle Database versión 11gR1 a 11gR2 en un ambiente e-Business Suite

R12.



Por Francisco Riccio





Introducción

El objetivo de este artículo es presentar un correcto procedimiento de cómo realizar un
upgrade de una base de datos Oracle 11.1.0.7 a versión 11.2.0.3. El procedimiento está
considerando los pasos que debemos realizar cuando la base de datos es el repositorio
de una solución de e-Business Suite R12 (12.1.1).

El escenario presentado está montado sobre una plataforma Oracle Enterprise Linux 5.7
de 32 bits.

I. Requisitos previos al upgrade

Nuestra solución de e-Business Suite R12 (12.1.1) debe contar con los siguientes parches
a nivel de aplicación y de base de datos antes de realizar el upgrade.

a) Parches de e-Business Suite: 9062910, 8919489, 9151516, 9868229, 10163753 y

11071569.

Para obtener la lista de parches instalados de e-Business Suite consultamos la tabla
AD_BUGS.



En mi implementación solo tengo instalado 2 parches de los solicitados como pre-
requisitos. Se debe proceder a instalar los demás parches solicitados.

Para instalar un parche de e-Business Suite normalmente debemos colocar la aplicación
en modo mantenimiento mediante el utilitario adadmin y luego aplicar el parche con el
utilitario adpatch y posteriormente retirar el modo mantenimiento.



1











2





3



Después de tener instalado los parches, volvemos a validar y vemos ya que todos los
parches están instalados.







b) Parches de Autoconfig EBS: 9738085, 9852070 y 12686610.



Al no tener ninguno de los 3 parches solicitados se procede a instalarlos de la misma
forma como se realizó en el punto I.a.

c) Actualización de Timezone

c.1) Debemos validar la versión que tenemos de Timezone en la base de datos.

Asimismo se adjunta la lista de versiones de Timezone disponibles a la fecha de la
creación de este documento. El objetivo será actualizar nuestro Timezone versión 10
hacia la 17.







c.2) Aplicaremos el parche 7695070 en nuestra Base de Datos.

Para validar si tenemos instalado un parche en nuestra base de datos lo validamos con el
comando: opatch lsinventory, ejemplo:





4

En mi escenario no está instalado por lo cual se procede a instalarlo. La instalación de un
parche en la mayoría de casos se realiza con el comando opatch apply.

c.3) Obtenemos la lista de tablas que tienen campos de tipo LOCAL TIMEZONE:

select c.owner || '.' || c.table_name || '(' || c.column_name || ') -'

|| c.data_type || ' ' col

from dba_tab_cols c, dba_objects o

where c.data_type like '%LOCAL TIME ZONE'

and c.owner=o.owner

and c.table_name = o.object_name

and o.object_type = 'TABLE'

order by col

/



En mi escenario ninguna tabla tiene algún campo de tipo LOCAL TIMEZONE.









5

c.4) Validar si existe información que se pueda ver afectada con el cambio de versión.

Para lograr este objetivo debemos ejecutar el siguiente script: utltzuv17.sql.

Después de ejecutar el script debemos consultar la tabla sys.sys_tzuv2_temptab.







6

En nuestro caso, la consulta devuelve 15 filas las cuales todas hacen mención a jobs
estándar de Oracle Database, los cuales no se le ejecuta ningún tratamiento y
procedemos a instalar el parche 12949905. Este parche nos realiza el upgrade a la
versión 17 del Timezone.

El parche 12949905 pide de requisito el parche 7695070 y además recompilar todos los
binarios del ORACLE_HOME.

Para recompilar el ORACLE_HOME lo hacemos a través del comando: relink all. Este
comando lo debemos ejecutar situados en el directorio: $ORACLE_HOME/bin, ejemplo:

Luego procedemos con la instalación del parche: 12949905.





Posterior a la instalación del parche procedemos a borrar las tablas: sys_tzuv2_temptab y
sys_tzuv2_affected_regions.





7

Después de este paso validamos si ya contamos con la versión 17 del Timezone.



Luego procedemos a actualizar el componente del Java Virtual Machine a la versión 17
del Timezone mediante el parche: 12949919



Finalmente procedemos a ejecutar el siguiente script con la finalidad de terminar la
actualización del Timezone en el componente de Oracle Java Virtual Machine.

@?/javavm/admin/fixTZb.sql



Cabe mencionar que el mensaje FAILED o el mensaje presentado son valores esperados
al finalizar la ejecución del script.



Observación:

La actualización del Timezone tiene muchos pasos a ejecutar acorde a nuestra
configuración actual. En nuestro caso no se tuvo ningún campo de tipo LOCAL
TIMEZONE y los únicos objetos afectados por la actualización fueron los JOBS
estándares de la Base de Datos, cualquier otra configuración o resultado de estas
pruebas se tendría que haber ejecutado otros pasos adicionales los cuales están
documentados en My Oracle Support (MOS) Nota: Applying the DSTv17 update for the
Oracle Database [ID 1362718.1].

8



d) Parches de Oracle Application Server: 6400501.

Este parche es solo válido para la versión 10.1.0.5 del Oracle Application Server en
plataforma Unix/Linux.



...







e) SYS.ENABLED$INDEXES:

Si existe la tabla SYS.ENABLED$INDEXES debemos proceder en borrarla.

Hasta aquí tenemos todos los requisitos cumplidos. Si nuestra base de datos cuenta con
Oracle Warehouse Builder debemos subirlo al menos a la versión 11.2.0.1 y aplicarle el
parche: 9403153.



9



II. Instalación del Oracle Database versión 11.2.0.3

A continuación indicaré los pasos que se deben realizar para instalar Oracle Database
versión 11.2.0.3 en un ambiente para e-Business Suite R12.

a) Instalación de la versión 11.2.0.3:





10



Es importante seleccionar edición Enterprise Edition.





11















b) Instalar el CD de Examples:

c) Creamos el directorio 9idata con los siguientes pasos:

d) Aplicamos los siguientes parches al ORACLE_HOME del Oracle Database

versión 11gR2: 4247037, 9858539, 12942119, 12960302, 12985184, 13001379,
13004894, 13258936 y 13366268.









12

Al aplicarlos parches debemos validar que estén debidamente instalados de la siguiente
manera:



Nota: Alguno de los parches listados tienen pasos post los cuales se ejecutarán más
adelante.

e) Database PSU:

Se recomienda adicionalmente aplicar el último PSU certificado de Base de Datos Oracle
Database 11g para e-Business Suite. Esta certificación está actualizada en el documento
My Oracle Support (MOS) Nota: Database Patch Set Update Overlay Patches Required
for Use with PSUs and Oracle E-Business Suite [ID 1147107.1] y Oracle Recommended
Patches -- Oracle Database [ID 756671.1].

En nuestro caso que contamos con la versión 11.2.0.3 está disponible a la fecha de la
creación de este documento el Database PSU: 11.2.0.3.2 certificado para e-Business
Suite R12.



13

La aplicación del Oracle PSU 11.2.0.3.2 nos obliga a previamente actualizar el binario
OPATCH a la versión 11.2.0.3.0.

Posterior a la aplicación del Oracle PSU 11.2.0.3.2 es recomendable revisar si
efectivamente está instalado correctamente con el comando: opatch lsinventory.







f) Actualización del Timezone versión 17 al ORACLE_HOME 11gR2

Aplicamos los siguientes parches en el nuevo ORACLE_HOME versión 11gR2: 12949905
y 12949919.

















14

III. Upgrade de Base de Datos

El upgrade de base de datos versión 11.1.0.7 a la versión 11.2.0.3.2 se realizó utilizando
el utilitario DBUA del nuevo ORACLE_HOME instalado.

a) Ejecución del DBUA:







15

En la siguiente pantalla nos aparecerá este BUG:



Este error está documentado en My Oracle Support (MOS) Notas: DBUA Fails With a
Screen Showing 'Null' [ID 1285052.1] y 11gR2 DBUA Fails With "Null" and trace file shows
"Could not launch SQLPLUS. Failed during initialization" [ID 1384810.1].

La solución es ejecutar el siguiente comando: unset ORA_TZFILE y volver a ejecutar el
utilitario DBUA.



16









17







18





b) Aplicación de parámetros recomendados.

Existe una serie de parámetros en la base de datos versión 11gR2 que deben
configurarse para obtener un ambiente e-Business Suite R12 estable. Estos parámetros
están documentados en My Oracle Support (MOS) Nota: Database Initialization
Parameters for Oracle E-Business Suite Release 12 [ID 396009.1].

19



En mi escenario se tuvo que configurar los siguientes parámetros:







c) Post Instalación pendiente de algunos parches RDBMS.

En la sección II.D hubo algunos parches que tenían pasos post, los cuales serán
ejecutados en esta sección.

Parche: 13366268 (No tuvo pasos post).

Parche: 13001379 (Con el usuario SYS ejecutar: execute
sys.dbms_metadata_util.load_stylesheets;)

Parche: 4247037, solicita ejecutar con el usuario SYS el siguiente script:
@?/md/admin/catmgdidcode.sql.

Parche: 9858539, solicita ejecutar los siguientes pasos:

cd $ORACLE_HOME/rdbms/admin

@@catnomtt.sql

@@catnomta.sql

@@dbmsmeta.sql

@@dbmsmeti.sql

@@dbmsmetu.sql

@@dbmsmetb.sql

@@dbmsmetd.sql

@@dbmsmet2.sql

@@catmeta.sql



20

@@prvtmeta.plb

@@prvtmeti.plb

@@prvtmetu.plb

@@prvtmetb.plb

@@prvtmetd.plb

@@prvtmet2.plb

@@catmet2.sql



Parche: 13258936, solicita ejecutar con el usuario SYS el siguiente script:
@?/ctx/admin/ctxpatch/ctxpatch11203.sql


IV. Pasos Post Upgrade

Después del upgrade de Base de Datos a la versión 11.2.0.3.2 se deben ejecutar los
siguientes pasos para que pueda acoplarse a la aplicación de forma correcta.

a) adgrants.sql:

cd $APPL_TOP/admin/adgrants.sql







21

b) Otorgar permisos al usuario CTXSYS:

cd $AD_TOP/patch/115/sql/adctxprv.sql <password_SYSTEM> CTXSYS

c) Setear los parámetros del usuario CTXSYS:

d) Validar las reglas de Workflow:

$FND_TOP/patch/115/sql/wfaqupfix.sql







22

e) Ejecutar un autoconfig:





f) Configurar el autoconfig en la capa de BD:

Los siguientes pasos están documentados