Verificar o histórico de patches SQL, o status dos componentes e os 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;

O que faz

Mostra de relance se a camada SQL foi realmente atualizada após o patch (dicionário compatível com os binários), qual patch falhou em qual PDB, se os componentes do dicionário estão VALID e o número de objetos inválidos.

Quando usar

Como etapa de verificação após cada datapatch, para registrar uma linha de base antes de patch ou upgrade e quando se suspeita de divergência após conectar um PDB.

Atenção

Somente leitura; não exige licença. SOURCE_VERSION/TARGET_VERSION são preenchidos no modelo de RU do 18c+. Se STATUS='WITH ERRORS', corrija o erro no LOGFILE e execute o datapatch novamente. Alguns componentes (ex.: XDB/JAVA não utilizados) podem aparecer como INVALID/REMOVED; compare com o estado anterior ao patch.