Vérifier l'historique des patchs SQL, l'état des composants et les objets invalides

Commande

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

Ce que fait la commande

Montre d'un coup d'œil si la couche SQL a vraiment été mise à jour après le patch (dictionnaire en phase avec les binaires), quel patch a échoué dans quelle PDB, si les composants du dictionnaire sont VALID, et le nombre d'objets invalides.

Quand l'utiliser

Comme étape de vérification après chaque datapatch, pour capturer une référence avant un patch ou une mise à niveau, et lorsqu'une incohérence est suspectée après le branchement d'une PDB.

Attention

Lecture seule ; aucune licence requise. SOURCE_VERSION/TARGET_VERSION sont renseignés dans le modèle RU 18c+. Si STATUS='WITH ERRORS', corrigez l'erreur indiquée dans LOGFILE et relancez datapatch. Certains composants (par ex. XDB/JAVA inutilisés) peuvent apparaître INVALID/REMOVED ; comparez avec l'état avant patch.