Verificar el historial de parches SQL, el estado de los componentes y los objetos inválidos

Comando

-- 1) datapatch history (most recent at the bottom):
SELECT patch_id, patch_type, action, status, source_version, target_version,
       TO_CHAR(action_time,'YYYY-MM-DD HH24:MI') AS action_time, description
FROM   dba_registry_sqlpatch
ORDER  BY action_time;

-- Failed entries and their log files:
SELECT install_id, patch_id, action, status, logfile
FROM   dba_registry_sqlpatch
WHERE  status <> 'SUCCESS';

-- In a CDB, for all PDBs (from root):
SELECT con_id, patch_id, action, status
FROM   cdb_registry_sqlpatch ORDER BY con_id, action_time;

-- 2) Components must be VALID:
SELECT comp_id, comp_name, version_full, status
FROM   dba_registry ORDER BY comp_id;

-- 3) Invalid object summary (compare before/after utlrp):
SELECT owner, object_type, COUNT(*) AS invalid_cnt
FROM   dba_objects
WHERE  status = 'INVALID'
GROUP  BY owner, object_type
ORDER  BY invalid_cnt DESC;

Qué hace

Muestra de un vistazo si la capa SQL se actualizó realmente tras el parche (diccionario acorde con los binarios), qué parche falló en qué PDB, si los componentes del diccionario están VALID y el número de objetos inválidos.

Cuándo usarlo

Como paso de verificación tras cada datapatch, para capturar una referencia antes de parchear o hacer un upgrade, y cuando se sospecha de una discrepancia tras conectar una PDB.

Precaución

Solo lectura; no requiere licencia. SOURCE_VERSION/TARGET_VERSION se rellenan en el modelo de RU de 18c+. Si STATUS='WITH ERRORS', corrija el error indicado en LOGFILE y vuelva a ejecutar datapatch. Algunos componentes (p. ej., XDB/JAVA no usados) pueden aparecer como INVALID/REMOVED; compare con el estado previo al parche.