17 de mayo de 2019

"Inactive No Manager" luego de instalar CPU de April 2019 en EBS/ After April 2019 CPU for EBS, Concurrent Shows Inactive

Luego de la instalación de todos los parches del último CPU de Oracle para EBS, me econtré con el problema que no se estaban ejecutando los concurrentes de la cola Standard. 

Luego de unos días de research, encontré una nota sobre reglas de especialización "Specialization Rules"

 


Esta regla estaba impidiendo a la Cola Standar tomar nuevos request.

Solo tuve que eliminarla y todo volvío a funcionar.

Tome como referencia la siguiente Nota de Oracle:

Concurrent Request Immediately After Submission Ends Up With Inactive or Pending Phase and No Manager Status (Doc ID 1947558.1)

14 de enero de 2019

Migrando EBS 12.2.7 a EBS 12.2.8 en 5 pasos

En esta pequeña entrada les quiero mostrar los 5 pasos fundamentales para hacer un
upgrade de EBS a la última versión.



Toda la información necesario sobre EBS 12.2.8 se puede visualizar en el blog oficial de
Oracle.


Notas

- Asumimos que en este entornos donde se estan realizando estos pasos se encuentra un EBS 12.2.7
con los ultimos parches de seguridad instalados minimamente el CPU de Abril del 2018. Y la versión de Base de Datos 12.1.0.2.también con el último CPU.
Partiendo de esta base, si realmente tenemos nuestro EBS correctamente instalado y sin ningun parche pendiente que pueda surgir de la ejecución del ETCC, con 5 sensillos pasos deberiamos poder hacer el ugrade.
- Importante validar que el tablespace DATA cuente con espacio,  recomiendo setearlo con un crecimiento automático durante la migración.
- En este post no van a ver el paso a paso, comando por comando, pero básicamente son los comandos que se necesitan y los van a ayudar a realizar la migración.

Paso 1.
Ejecutamos la etápa "prepare"


$ adop phase=prepare
Running this
adnodemgrctl.sh: check the logfile /u01/oracle/EBS1228/fs2/inst/apps/
EBS1228_hostname/logs/appl/admin/log/adnodemgrctl.txt for more information ...
 
The prepare phase completed successfully.
adop exiting with status = 0 (Success)


Step 2
Aplicamos el Oracle E-Business Suite Release 12.2.8 Patch 26787767.


$ adop phase=apply patches=26787767 hotpatch=yes patchtop="/stage"

Generating log rep""ort.
Output: /u01/oracle/EBS1228/fs_ne/EBSapps/log/adop/9/20181221_092925/
apply/hostname/adzdshowlog.out
The apply phase completed successfully.

adop exiting with status = 0 (Success)


Step 3
Completamos el ciclo de pacheo de adop ejecutando los siguientes comandos
en el orden que se encuentran.
$ adop phase=finalize
$ adop phase=cutover
$ . /EBSapps.env run
$ adop phase=cleanup


Step 4
Sincronizamos los filesystems.
$ adop phase=fs_clone



Step 5 (opcional)
Aplicamos Oracle E-Business Suite Release 12.2.8 Online Help Patch 26787780
usando adop hotpath en el run file system
$ adop phase=apply patches=26787780 hotpatch=yes


Con estos simple 5 pasos, pude hacer el upgrade de un EBS 12.2.7 a EBS 12.2.8

4 de enero de 2019

Internal Concurrent Manager status could not be determined.

Un error muy facil de solucionar.

Varios opciones donde podemos visualizarlo
adop phase=cutover

en el fndsvcrg.log:
Internal Concurrent Manager status could not be determined.

O en el output
Waiting for Internal Concurrent Manager to go down. [UNEXPECTED]Error trying to find the status of ICM [UNEXPECTED]Error occurred waiting for ICM to go down [UNEXPECTED]Cutover phase has failed.

or validando el estado de los concurrentes
$FND_TOP/bin/FNDSVCRG STATUS

Internal Concurrent Manager status could not be determined.

Para que estén al tanto este proceso utiliza el usuario APPLSYSPUB para conectarse y validar el estado.
Si por algún error tenemos este usuario en la DB bloqueado o con la password a punto de expirar o expirado, falla.

solo debemos desbloquear el user de DB.

Solución:
alter user applsyspub identified by pub;
ALTER USER applsyspub ACCOUNT UNLOCK;


Saludos