Oracle Database 19c Release Update Verification
Technology – Oracle Database 19c, Release Update (19.32), Multitenant.
Lab Date – 12th November 2026.
Overview
Applying a Release Update to your Oracle Database is an important part of the DBA role.
However, simply applying a patch may not mean that all parts of your database will run as expected.
The DBA should verify that the patch has been applied successfully, in Oracle 19c (especially with the multi-tenant architecture), by checking at different levels.
Even though the patch may have been applied to the Oracle Home, we also need to check that the SQL have been applied. We should also ensure that our Container Database (CDB) and Pluggable Databases (PDBs) are open and running correctly.
This guide will demonstrate how to verify that this is the case using a combination of Oracle OPatch, SQLPlus, Dictionary Views and SQL.
Lab Evidence
The aim of this guide is to demonstrate how you can verify that your patch has been applied successfully.
Oracle Database 19c Test Environment
I carried out my verification in a test environment with the following setup:
Section
Details
Database
Oracle Database 19c
Release Update
19.32
Patch ID
39472050
Architecture
Container Database (with Pluggable Database)
Verification Tool
SQLPlus
Verification
Patch was applied to Database via SQL. PDB status was confirmed. PDB was confirmed to be ‘Saved’.
As the database contains sensitive information, we should not include any database names, server names or anything specific to the infrastructure.
The SQL examples will include generic names.
Why Patch Verification Is Important
Oracle will release patches to fix any issues relating to defects, security, stability and other issues.
A Release Update (RU) is a cumulative patch provided as part of Oracle’s regular maintenance cycle.
As a DBA there are 3 key areas we should consider:
Oracle Home Patches
Oracle Home contains all of the required binaries, executables, libraries and tools needed for the database.
We can use the OPatch tool to identify what patches have been applied.
SQL Patches
Some patches will require SQL to be applied to the database dictionary or components.
Oracle provide us with a tool called datapatch to APPLY these SQL patches.
The database will have a registry showing what SQL patches have been applied.
Database Running Correctly
Even though the registry may show that the patch was applied successfully, we should also verify that the database and PDBs are running correctly.
For example, the PDB may not be available for applications as it is still mounted.
Or the PDB may be open successfully but not have any saved state so will remain mounted after the instance is restarted.
Therefore multiple checks are required to verify that the patch was applied successfully.
- Oracle Home Patch Verification
An important first step is to check what patches have been applied to your Oracle Home.
Login to your database server with the correct owner account for the Oracle software.
Ensure that you have the correct Oracle Home set up.
echo $ORACLE_HOME
Run the following command:
$ORACLE_HOME/OPatch/opatch lspatches
For detailed information run:
$ORACLE_HOME/OPatch/opatch lsinventory
This can give us information about the patch IDs, descriptions and software that have been applied.
Our Oracle Database 19c Release Update (19.32) patch ID was:
39472050
Patch Description:
Database Release Update: 19.32.0.0.260721
Why This Is Important
This will help us identify whether the correct binaries have been applied for our patch. However, this alone will not tell us if the SQL patches were successfully applied to all of the database containers. Therefore we should now check the SQL patches.
[Note: The lab material I used for this article shows that the SQL registry was successful. However, I did not have a standalone test OPatch inventory to compare. The commands above will help you verify the inventory.]
- Check SQL Patches In CDB & PDB
Oracle Database provide dictionary views to allow you to check what SQL patches have been applied.
One of the most important views is:
CDB_REGISTRY_SQLPATCH
Login to the CDB root with a valid admin session.
First, check what container you are in.
SHOW CON_NAME;
Now run the following command:
SELECT
con_id,
patch_id,
action,
status,
action_time
FROM cdb_registry_sqlpatch
ORDER BY action_time DESC, con_id;
Column Details
Column
Description
CON_ID
Container ID identifying the database container
PATCH_ID
Patch ID identifying the patch
ACTION
Whether the patch was Applied or Rolled Back.
STATUS
Status of the patch.
ACTION_TIME
Time of action.
To specifically check for our Oracle Database Release Update (19.32) run:
SELECT
con_id,
patch_id,
action,
status
FROM cdb_registry_sqlpatch
WHERE patch_id = 39472050
ORDER BY con_id;
Lab Result
The SQLPlus command above returned:
CON_ID PATCH_ID ACTION STATUS
1 39472050 APPLY SUCCESS
3 39472050 APPLY SUCCESS
This proves that the SQL patch was successfully applied to both the CDB root and test PDB.
In this environment the container ID 1 was the CDB root and the container ID 3 was the user PDB.
Important Note
The SUCCESS means that the datapatch was applied successfully. However, this is just showing the history of the patch. We should also check whether there has been a more recent rollback or failure.
You cannot always assume that the latest patch state will be displayed as there may be an older successful row.
Also notice that there is no separate row for the PDB Seed. Do not assume that the PDB Seed has been patched successfully or not based on this output. You should review the relevant datapatch logs and patch documentation.
- Confirm PDB Open Mode
Having checked the SQL patches we should now check the current status of our pluggable databases.
In Oracle Database 19c, we have a multi-tenant architecture meaning we can have multiple PDB’s within the CDB.
Each PDB will have their own open mode.
Login to SQLPlus and run:
SHOW PDBS;
Or:
SELECT
con_id,
name,
open_mode,
restricted
FROM v$pdbs
ORDER BY con_id;
What The Output Means
READ WRITE
The PDB is open and can be used for reading and writing. This depends on user permissions and application.
READ ONLY
The PDB is open but cannot be used for normal data changes in applications.
MOUNTED
The PDB is not open.
RESTRICTED
If Restricted is set to YES then only users with the required privilege will have access.
Lab Result
Our test showed:
Container Open Mode Restricted
PDB Seed READ ONLY NO
User PDB READ WRITE NO
This proves that our test PDB was open in Read Write mode and was not restricted.
Opening PDB If Required
If a valid DBA decides that the PDB needs to be opened run the following command from the correct admin context:
-- Make sure to change LAB_PDB to correct PDB name.
-- Admin command to change database.
ALTER PLUGGABLE DATABASE LAB_PDB OPEN READ WRITE;
Do not run this command unless you have confirmed what state you want the database in and any change control.
Opening a PDB is an operational command and does not prove that the database was patched successfully.
- Confirm PDB Saved State
Another important part of verifying the patch is confirming that the PDB has a saved open state.
Whilst the PDB could be manually opened during maintenance/testing, the open mode may not be saved when the instance is restarted.
Oracle provide us with a way to save the desired open mode.
Within a valid test environment an administrator can run:
-- Make sure to change LAB_PDB to correct PDB name.
ALTER PLUGGABLE DATABASE LAB_PDB SAVE STATE;
This can be checked using:
SELECT
con_name,
instance_name,
state
FROM dba_pdb_saved_states
ORDER BY con_name;
Explanation
CON_NAME – Name of PDB.
INSTANCE_NAME – Name of database instance the state was saved.
STATE – Describes the open mode of the PDB.
Lab Result
The verification showed that the test PDB had a saved state:
STATE
OPEN
This proves that the PDB had a saved open state.
Why This Is Important
During planned maintenance the DBA may restart the database instance successfully but find that an application PDB is still mounted.
This can mean applications cannot connect.
By checking that the PDB has a saved state we can identify whether it has been configured to open in the desired mode.
In a multi-instance/RAC environment we should also check that the saved state is being applied to the correct instances.
Whilst this proves that there is a saved state configuration, a controlled restart and application connectivity would give stronger evidence.
- Real Test Results & Screenshots
We should base our report around the evidence of what was executed.
From our lab we had the following:
Verification Summary
Verification Result Interpretation
Oracle SQL Patch ID 39472050 Database RU 19.32
CDB Root SQL Patch APPLIED/SUCCESS SQL Patch applied successfully
User PDB SQL Patch APPLIED/SUCCESS SQL Patch applied successfully
PDB Open Mode READ WRITE Open in Read Write mode
PDB Restricted NO Not restricted
PDB Saved State OPEN Open state saved
OPatch Inventory (Oracle Home)
Not verified in this evidence. Will need to run inventory.
This proves that we have carried out the SQL Patch and PDB checks.
However, this does not prove that we have full application compatibility, that the database can be restored and recovered and that there are no issues at runtime.
Screenshot 1 – SQL Patch Registry
[Insert original SQLPlus screenshot]
This should show you have queried the CDB_REGISTRY_SQLPATCH view. Include Patch ID, container ID’s, action and status.
Remove/obscure any unnecessary information.
Screenshot 2 – PDB Open Status
[Insert original SHOW PDBS screenshot]
This should show that the test PDB is in Read Write mode and not restricted.
Screenshot 3 – PDB Saved State
[Insert original DBA_PDB_SAVED_STATES result]
This should show that the PDB has a saved OPEN state.
Screenshot 4 – OPatch Inventory
Only add if ran separately.
Having a current OPatch inventory can help strengthen your article. This proves that both the binaries and SQL have been verified.
Do not make up a screenshot, use a real one.
- Key Takeaways & Best Practice
We should have a structured approach to verifying our Oracle Database after applying a patch.
- Check Binaries & SQL
Whilst having a successful OPatch and datapatch are related they are separate.
Use OPatch inventory to confirm what software patches have been applied. Use SQL Patch registry to confirm what SQL have been applied to the database.
- Check All Relevant Containers
Within a multi-tenant environment we should consider the CDB root and user PDBs.
Check that all relevant containers have the correct Patch Status.
- Database Availability
When verifying your patch you should also check that the database is available.
A PDB may have been patched successfully but still be mounted.
- Check PDB Saved State
After carrying out maintenance, confirm that the PDB starts in the correct way.
If required, save the desired open state and check the relevant dictionary entry.
- Check Errors & Patch Logs
If there are any unexpected statuses in the patch registry, datapatch failures or discrepancies between the OPatch inventory and database SQL patch history investigate further.
Don’t blindly re-run any patching tools without understanding what the current state is and what the patch README says.
- Application Checks
Just because the database has been patched successfully does not mean that the applications will run as expected.
A full maintenance process should include valid checks to ensure applications can connect, critical functions are working and any relevant integration dependencies.
- Keep Evidence
Have a valid maintenance document detailing what patches have been applied, what results were achieved, what queries were run to verify and the time. This should be detailed enough to help troubleshoot any issues but should not expose any confidential information.
- Recommended Post-Patch Checklist
The following is a summary of what we should verify:
Verification Expected Evidence
Correct Oracle Home Environment & Inventory
Check RU Binaries Applied OPatch shows correct patch
Check SQL Patch Registry Latest applicable patch was applied successfully
Check CDB & PDB’s Checked relevant containers
Check PDB Open Mode Confirmed that PDB is open in correct mode
Check Restricted Matches intended access
Check PDB Saved State Confirmed that PDB has correct saved state
Check Datapatch Logs No unresolved patch failures
Check Database Components Investigate any unexpected invalid components
Application Checks Critical functions tested
Final Evidence Valid maintenance documentation
These are all complimentary checks and not all were proven from the lab evidence above.
Conclusion
We should not simply take it at face value that our Oracle Database has been patched successfully based on what the installer says. In an Oracle Database 19c multi-tenant environment we should check the Oracle Home inventory, SQL patch history, PDB availability and saved start up states.
Our lab results proved that we had SQL patches applied to our Oracle Database RU 19.32. The CDB root and user PDB had APPLIED/SUCCESS.
Our test PDB was confirmed to be open in Read Write mode, not restricted and had an OPEN saved state.
This provides us with useful evidence.
Overall we should have a reliable process for maintaining our patches. This includes verifying our software, database and operational checks, along with clear documentation. Having a structured checklist can help DBA’s identify any incomplete steps when maintaining.
References
Oracle Database Patch Maintenance (Release 19c and later)
https://docs.oracle.com/en/database/oracle/oracle-database/19/dbptc/index.html
Oracle Database 19c – DBA_REGISTRY_SQLPATCH
https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/DBA_REGISTRY_SQLPATCH.html
Oracle Database 19c – DBA_PDB_SAVED_STATES
https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/DBA_PDB_SAVED_STATES.html
Oracle Database 19c – Administering Pluggable Databases
Oracle Database 19c RU 19.32 – Oracle Linux 9 & RHEL 9 Install Guidance
Abdulrawof Totakhil
Database Administrator
