A useful patch baseline links a running database to its actual Oracle home, records the patches installed in that home, and captures SQL patch and component state in every relevant container. This lets an administrator detect an incomplete earlier patch or a wrong-home assumption before planning another change.
Oracle DBA Lesson 82 Part 1 — Identify Exactly What Will Be Patched
Map the database to its Oracle home
An Oracle home is a directory tree containing an installation of Oracle software. One host can contain several homes, and several databases can use the same home. A software change to a shared home needs a scope that includes every database and service that uses it.
Establish the running database's home from the deployment's service or resource configuration and the maintained inventory. Verify that mapping against the running environment. The shell's PATH, a client executable, or an unverified ORACLE_HOME value can refer to another installation.
The database runs from Home A, /opt/oracle/dbhome_a. Home B is another installation. Set the shell to the verified home with the site's procedure before running that home's inspection tools. See running OPatch from the appropriate Oracle home.
Check the software inventory
"$ORACLE_HOME/OPatch/opatch" version
"$ORACLE_HOME/OPatch/opatch" lsinventory| Command | Useful result | Interpretation |
|---|---|---|
opatch version | OPatch utility version | Compare this with the selected patch's required tool version |
opatch lsinventory | Reported Oracle home, installed products and patches | Retain patch IDs, descriptions and the home identity |
Home A reports this inventory:
| Inventory field | Value |
|---|---|
| Oracle Home | /opt/oracle/dbhome_a |
| Patch ID | 98765432 |
| Description | Database Release Update |
Capture the complete inventory, including existing one-offs, rather than keeping only the RU description. Record any inventory error and resolve it before planning an apply operation. Inventory inspection can create OPatch diagnostic logs. It does not apply or remove database patches.
Also capture the database banner:
SELECT banner_full FROM v$version;BANNER_FULL supplies the full database version banner. Retain it with the detailed binary inventory and the SQL patch records. The OPatch tool version and the database software version describe different components. See OPatch syntax and commands and V$VERSION and BANNER_FULL.
Read the SQL patch state
Some database patches include SQL scripts that must update objects inside the database. Datapatch performs the required SQL actions and updates DBA_REGISTRY_SQLPATCH. Each row describes an apply or rollback attempt for a patch. The view is a history of attempts.
The binary inventory describes installed software in a home. SQL patch records describe SQL work in the queried database container. Name the intended container before reading its dictionary:
SHOW CON_NAME
SELECT patch_id, action, status, action_time,
description, logfile
FROM dba_registry_sqlpatch
ORDER BY action_time;SHOW CON_NAME is a SQL*Plus command. Repeat the inspection in each relevant container, or use a correctly scoped CDB-wide collection with verified container visibility. This lesson uses per-container collection so the scope stays explicit.
| Field | Meaning and action |
|---|---|
PATCH_ID | Patch identifier; reconcile it with the intended patch set and home inventory |
ACTION | APPLY or ROLLBACK, identifying the attempted operation |
STATUS | SUCCESS means the attempt completed without errors; WITH ERRORS requires investigation |
ACTION_TIME | When the attempt occurred; read the sequence in time order |
DESCRIPTION | Patch description from OPatch metadata |
LOGFILE | Log for that apply or rollback attempt; inspect it when interpreting a failure |
One old success row is not enough. The root history for patch 98765432 is:
| PATCH_ID | ACTION | STATUS | ACTION_TIME |
|---|---|---|---|
| 98765432 | APPLY | SUCCESS | 22-OCT 08:00 |
| 98765432 | ROLLBACK | SUCCESS | 22-OCT 08:30 |
| 98765432 | APPLY | SUCCESS | 22-OCT 09:00 |
The latest relevant attempt here is the successful apply at 09:00. Retain the complete history and compare applicable patch IDs, actions, logs, and current binary state. A simple “last row” rule across the entire view can overlook other relevant patches. If more detail is needed, retain INSTALL_ID, PATCH_UID, source and target versions, and the associated logs as well.
Do not modify registry rows to make them appear successful. Investigate the failure and use the supported patching procedure to correct the underlying state. See DBA_REGISTRY_SQLPATCH.
Check container coverage
When the home's binary inventory contains patch 98765432, separate inspections can produce this summary:
| Container | Latest relevant action | Status |
|---|---|---|
CDB$ROOT | APPLY | SUCCESS |
| SHOP | APPLY | SUCCESS |
| REPORTING | APPLY | WITH ERRORS |
SHOP and REPORTING are application PDBs. This summary is assembled from separate container inspections. It is not the direct output of the preceding query.
The reporting PDB has an unresolved SQL patch failure. Collect its log and investigate that attempt before rehearsing another change. Record the exact container and patch involved. For a patch that requires SQL actions, include any closed or skipped PDB whose work was deferred and plan its supported completion. Datapatch needs the required PDBs open in the mode specified by the applicable procedure. Opening a PDB or running datapatch is a separate change from recording this baseline.
Inventory the required root, seed handling, and application PDB coverage according to the selected procedure. Preserve each container's identity and collection time. A missing SQL row may mean the patch has no SQL actions, the work was deferred, the wrong scope was queried, or the operation is incomplete. Determine which condition applies from the README and the logs. See Datapatch troubleshooting and open PDB requirements.
Capture database component state
SELECT comp_id, version, status
FROM dba_registry
ORDER BY comp_id;| COMP_ID | VERSION | STATUS |
|---|---|---|
| CATALOG | 19.0.0.0.0 | VALID |
| CATPROC | 19.0.0.0.0 | VALID |
CATALOG identifies the catalog component, and CATPROC identifies the PL/SQL packages and types component. The registry records separately loadable components, their versions, and statuses. Save these results in the relevant containers so later changes can be compared with the baseline. A pre-existing component problem needs an owner and a disposition before the change. A newly introduced problem needs investigation against this baseline.
Component version and status fields serve component inspection. Use the binary inventory and SQL patch history to reconcile the patch set. Retain VERSION_FULL when the component's full version is relevant. See DBA_REGISTRY.
Define the proposed change
| Change | Meaning |
|---|---|
| Release Update (RU) | A bundle of fixes within a database release |
| One-off/interim patch | A fix for a particular issue, product version and platform |
| Oracle-home switch | Change the software installation used to run the database; the base release can remain the same |
| Release upgrade | Move the database to a newer release using a supported upgrade path |
An out-of-place patch commonly uses another home at the intended patch level. The home switch and the release change are separate properties of the plan. Select the supported tool and deployment procedure for the actual release, topology, and package. These inspection commands do not prescribe a universal opatch apply sequence. See Oracle Database patch maintenance and choosing a new Oracle home location.
Record the patch-specific preflight
Use the exact patch package's README and the applicable support and certification material. Do not label a fixed historical RU as permanently “latest.”
| Planning item | Evidence needed before rehearsal |
|---|---|
| Exact target | Patch ID, target RU/release, platform and README revision |
| Supported path | Applicable source/target combination and certification |
| Dependencies | OS, Grid Infrastructure and other topology requirements |
| Patching utility | Required OPatch/tool version compared with the actual version |
| Existing fixes | Documented prerequisite and conflict checks against the current inventory |
| Space and outage | Software, staging/working space, time window and affected services |
| Recoverability | Tested database/home recovery resources and patch-specific rollback route |
| Container state | Scope, SQL patch attempts, component state and deferred work |
Keep the baseline and the intended target in the same record. Resolve the REPORTING failure from its log and the supported procedure, then reassess readiness. Applying binaries, completing SQL patch actions, abort decisions, and fallback execution belong to the later rehearsal.
Recap
Record the verified Oracle home, the OPatch inventory, the full version banner, SQL patch history in every relevant container, and component status. Read the latest relevant action together with the full history. Resolve a container that shows WITH ERRORS, such as REPORTING, before treating the target patch, platform, README, prerequisites, and recovery route as ready.
No comments:
Post a Comment