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)
Currently working as Service Solution Architect, CSS, MCR at Oracle. Especialista Oracle. Security on OCI, E-Business Suite / OBIEE / HYPERION / OCI / MIDDLEWARE (all Oracle :-D ) - Instructor y Speaker / Oracle DBA. / OCI Certifications - PreSales on CCS Service at Oracle
17 de mayo de 2019
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.
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.
Oracle.
Notas
- Asumimos que en este entornos donde se estan realizando estos pasos se encuentra un EBS 12.2.7con 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
$ 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.
en el orden que se encuentran.
$ adop phase=finalize
$ adop phase=cutover
$ .
$ 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
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
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
Suscribirse a:
Entradas (Atom)