SQL-Patch-Historie, Komponentenstatus und ungültige Objekte prüfen

Befehl

-- 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;

Was es tut

Zeigt auf einen Blick, ob die SQL-Schicht nach dem Patchen wirklich aktualisiert wurde (Dictionary passend zu den Binaries), welcher Patch in welcher PDB fehlschlug, ob die Dictionary-Komponenten VALID sind und wie viele ungültige Objekte es gibt.

Wann einsetzen

Als Prüfschritt nach jedem datapatch, um vor dem Patchen oder Upgrade eine Baseline festzuhalten, und wenn nach dem Einstecken einer PDB ein Mismatch vermutet wird.

Vorsicht

Nur lesend; keine Lizenz erforderlich. SOURCE_VERSION/TARGET_VERSION sind im RU-Modell ab 18c befüllt. Bei STATUS='WITH ERRORS' den Fehler in LOGFILE beheben und datapatch erneut ausführen. Einige Komponenten (z. B. ungenutztes XDB/JAVA) zeigen eventuell INVALID/REMOVED; mit dem Zustand vor dem Patchen vergleichen.