Below is a typical Oracle Cloud Infrastructure OCI - DB System (DBCLI-managed) Oracle Enterprise Linux (OEL) OS patching procedure using DBCLI. This procedure assumes the system is managed by DBCLI and that the patch is available in Oracle's repository or Object Storage. (Update the DB System Resources Using dbcli)
Step 1: Pre-Patching Checks
1. Login to the database server
ssh opc@<dbserver>
sudo su -
2. Check current DBCLI version
dbcli -v
3. Verify current system components
dbcli describe-component
Example Output:
Component Name Installed Version Available Version
----------------------------------------------------------
OS 8.x.x 8.x.x
GI 19.x 19.x
DBHOME 19.x 19.x
This identifies whether updates are available.
4. Check available OS patches
dbcli get-availableospatches
Example:
Update Available Reboot Required
------------------------------------
Yes Yes
If Reboot Required = Yes, plan a maintenance window.
Step 2: Database Health Check
Check that databases are healthy.
srvctl status database -d <dbname>
or
crsctl stat res -t
Ensure there are no failed resources.
Step 3: Backup
Oracle recommends taking a backup before applying OS updates.
Examples:
RMAN backup
Storage snapshot
VM snapshot (if applicable)
This is a recommended prerequisite before OS patching.
Step 4: Run OS Patch Precheck
Run the DBCLI precheck.
dbcli update-server -c os -p
Example output:
{
"jobId":"7fc5cadd-d256-436a-be0d",
"description":"OS Patching Prechecks"
}
Step 5: Monitor the Precheck Job
dbcli describe-job -i <JOB_ID>
Wait until:
Status : Success
If the precheck fails, resolve the reported issues before continuing. (Update the DB System Resources Using dbcli)
Step 6: Start OS Patching
Execute:
dbcli update-server -c os
Example:
{
"jobId":"bee1c6d9-45fb-4e5b",
"description":"OS Patching"
}
Step 7: Monitor Patch Progress
dbcli describe-job -i <JOB_ID>
or
watch dbcli describe-job -i <JOB_ID>
Monitor until:
Status : Success
Step 8: Reboot Server (If Required)
If the available OS patch indicated Reboot Required = Yes, reboot the server.
reboot
Oracle recommends rebooting after kernel updates. (Update the DB System Resources Using dbcli)
Step 9: Verify Cluster Services
After reboot:
crsctl check cluster
crsctl stat res -t
Verify:
CRS
ASM
LISTENER
VIP
SCAN
Database resources
are all ONLINE.
Step 10: Verify Database
srvctl status database -d <dbname>
or
SELECT INSTANCE_NAME, STATUS FROM V$INSTANCE;
Step 11: Verify OS Version
cat /etc/oracle-release
Check kernel:
uname -r
Step 12: Verify No Pending OS Updates
dbcli get-availableospatches
Expected output:
Update Available : No
Useful DBCLI Commands
| Purpose | Command |
|---|---|
| Show components | dbcli describe-component |
| Available OS patches | dbcli get-availableospatches |
| Run precheck | dbcli update-server -c os -p |
| Apply OS patch | dbcli update-server -c os |
| Monitor job | dbcli describe-job -i <jobid> |
| Show latest patches | dbcli describe-latestpatch |
| DBCLI version | dbcli -v |
RAC (2-node) Best Practice
For a 2-node RAC environment, patch one node at a time to maintain service availability:
Patch Node 1.
Reboot Node 1 if required.
Confirm CRS, ASM, and the database are healthy.
Relocate services if needed.
Patch Node 2.
Reboot Node 2.
Perform final cluster validation.
This rolling approach minimizes downtime and keeps nodes at consistent patch levels within the maintenance window. (Update the DB System Resources Using dbcli)
This procedure follows Oracle's documented DBCLI workflow: check for available OS updates, run the mandatory precheck (dbcli update-server -c os -p), apply the update (dbcli update-server -c os), monitor the job, reboot if required, and verify cluster and database health after patching. (Update the DB System Resources Using dbcli)
