Como usar Patch Wizard EBS R12

Patch Wizard, es una herramienta de EBS que nos permite analizar el impacto de aplicar un parche específico en EBS o busar partes recomendados por Oracle en nuestra Aplicación.
Se puede usar mediante las credenciales de support o sin conexión a internet.
Voy a guiarlos como realizarlo sin conexión, ya que tiene cierto grado más de complegidad.

Notas Referentes:
R11i / R12 : Patch Wizard Utility [Video] (Doc ID 976188.1)
Patch Wizard FAQ [Video] (Doc ID 976688.2)
Oracle E-Business Suite Releases 11i and 12.x: Required Updates for Patch Wizard (Doc ID 1267768.1)
How To Use Patch Wizard Without Setting Up Internet Connection (Doc ID 741129.1)

Pasos para validar parches sin conexión a internet:

1) Tener los parches necesarios y recomendador para la correcta ejecución del chequeo.
En la nota 976688.2 van a encontrar los queryes para validar los parches aplicados.

--Check for the Latest 11i Patch Wizard Patches Applied
--Check for the Latest R12.0 Patch Wizard Patches Applied
--Check for the Latest R12.1 Patch Wizard Patches Applied
--Check for the Latest R12.2 Patch Wizard Patches Applied

2) Descargar el InfoBundle, de la nota 741129.1
File: InfoBundleR12.zip (09/2016, tomar en cuenta bajar el más actualizado)
dejar el archivo .zip en el /stage que se definio en la configuración del Patch_Wizard

3) Ahora tenemos dos opciones, ejecutar la herramienta de chequeo para validar todos los parches que nos faltarían para tener el mínimo codelevel recomendado o ejecutar el análisis de impácto por un solo parche.

3.1) Recomendación de parches.

El resultado se va a visualizar en la parche inferior del Tab Patch_Wizard,

Tomar en cuenta que este concurrente puede estar ejecutandose entre 6 y 10hs, dependiendo el Hardware y Módulos actiavos.

3.2) Analizar un parche puntual, sin conexión a internet.

a.

Es importante tomar en cuenta el stage, ya que al realizar este paso manualmente no se generan los directorios automáticamente.

Tenemos que crear un directorio para parches AD y NOAD donde se ponene los parches a analizar.

Tomen en cuenta que no se puede modificar los nombres, solo el path del stage es customizable.

Ejemplo:

/stage/PW/

/stage/PW/ad

/stage/PW/nonad

b.

En este ejmplo dentro de AD, ingreso el .zip del parche AD que tenemos actualmente instalado (siempre se tiene que comparar con el AD actual) y en la carpeta nonad los parches que vamos a analizar.

/stage/PW/ad/p20395533_R12.AD.B_R12_LINUX.zip

/stage/PW/nonad/p22349522_R12.PO.B_R12_LINUX.zip

c.

Los campos con los nombres de los parches se ingresan con el cod_level

22349522_R12.PO.B, 20395533_R12.AD.B

EBS automáticamente tiene que encontrar cada parche en su respectivo directorio.

d. En la siguientes sección se pueden ver los resultados, logs, errores y status.

Tuning OPP EBS (Output Post Processor)

La generación de pdf y xls en EBS puede generar varios problemas de memoria y encolamiento de trabajaos.
Les voy a dejar algunos tips de configuración sobre esta cola de concurrente, llamada OPP o Output Post Processor

1) Modificar el Heap Size para evitar el error por OutOfMemoryError.
Validar el tamaño actual:

select DEVELOPER_PARAMETERS
from FND_CP_SERVICES
where SERVICE_ID = (select MANAGER_TYPE from FND_CONCURRENT_QUEUES
where CONCURRENT_QUEUE_NAME = 'FNDCPOPP');

Setear el nuevo valor (recomendado 2048MB), al ser una aplicación de 32bits, no sirve ponerle más memoria.

 update FND_CP_SERVICES set DEVELOPER_PARAMETERS =
'J:oracle.apps.fnd.cp.gsf.GSMServiceController:-mx2048m'
where SERVICE_ID = (select MANAGER_TYPE from FND_CONCURRENT_QUEUES
where CONCURRENT_QUEUE_NAME = 'FNDCPOPP');  

2) El parametro por default del OPP, 

oracle.apps.fnd.cp.opp.OPPServiceThread:2:0:max_threads=5

Podemos ampliar los hilos de ejecución a 5/8 como máximo, pero no tocar el OPPServiceThread  este parámetro indica la cantidad de servicios en ejecución.

Es recomendable aumentar los hilos mientras la memoria lo permita.

3) Cantidad de Procesos

En caso de ejecutarse muchos reportes, se puede aumentar el nro de procesos de la cola:

4) Optimizar el "FO Processing"

Dentro de las configuraciones del XML Publisher:

5) Parches Recomendados para 12.1

Patch 16000609 - OPP IS UNSTABLE / UNRELIABLE

Patch 12627470 - 1OFF:12.1.3:11721940:WORKSHIFTS DON'T WORK WITH JAVA MANAGERS

Nota de Referencia: #1399454.1

Se puede aumentar los procesos de la cola de concurrentes "Administrador Solución Conflictos"?

Existe una nota de Oracle que hace referencia al tema #1534383.1
La cual explica que la cola fue diseñada para trabajar con un solo proceso, lo cual me parece lógico ya que tiene que ir evaluando de a uno los concurrentes para validar que no tengo conflicto con otro.
Por lo cual en caso de definir mas procesos, siempre va a trabajar con uno solo.

Lo que si podemos hacer, para mejorar el rendimiento de esta cola, es bajar el tiempo de espera que tiene configurado en los turnos de trabajo que por defecto es 30 segundos.
Se podría configurar en 10 segundos o 5 en caso de ser necesario.

Esto se realiza entrando en la definición del concurrente con la responsabilidad de SYSADMIN, buscamos la cola de concurrentes y hacemos click en turnos de trabajo.

Como vincular un concurrente con la Session de Base de Datos

1) Con la siguiente query, identificamos el ORACLE_SESSION_ID

select    oracle_process_id,                        --> SPID de la Base de datos
             oracle_session_id,                        --> es el campo AUDSID de la V$Session
             os_process_id                               --> Operating System Process ID for Concurrent Program
from      apps.FND_CONCURRENT_REQUESTS
where     request_id='REQUEST_ID'        --> numero de request_id del concurrent manager

2) Luego con el resultado de la primer query, podemos consultar la v$session según el audsid
select * from v$session where audsid=os_process_id (resultado obtenido en la query anterior)

De esta forma podemos ver que esta realizando en la DB el concurrente que se esta ejecutando.

Verificar el Estado y Etapa de la Cola de Concurrentes y significado de STATUS_CODE & PHASE_CODE

El fin del siguiente post es mostrarles que significan los códigos de estado de la tabla de concurrentes "fnd_concurrent_worker_requests"

Columna STATUS_CODE

A Waiting
B Resuming
C Normal
D Cancelled
E Error
F Scheduled
G Warning
H On Hold
I Normal
M No Manager
Q Standby
R Normal
S Suspended
T Terminating
U Disabled
W Paused
X Terminated
Z Waiting

Ccolumna PHASE_CODE

C Completed
I Inactive
P Pending
R Running

Ejemplo de un query para ver los Concurrentes Pendientes por cola

  SELECT concurrent_queue_name "QUEUE",
         user_CONCURRENT_PROGRAM_NAME "PROGRAM",
         COUNT (1) CANT
    FROM fnd_concurrent_worker_requests
   WHERE     phase_code = 'P'
         AND hold_flag != 'Y'
         AND requested_start_date <= SYSDATE
GROUP BY user_CONCURRENT_PROGRAM_NAME, concurrent_queue_name;