How to Patch Oracle 19c to Release 19.29 – A Complete Step-by-Step Blog

 

How to Patch Oracle 19c to Release 19.29 – A Complete Step-by-Step Blog

 

Introduction

I recently had to patch one of my Oracle 19c databases from 19.28 to 19.29. As always, the goal was simple — stay secure, stable, and aligned with Oracle’s quarterly patch cycle. Since this is something we DBAs do every few months, I decided to write down the exact steps I followed. The procedures are the same for all 19c versions.

This is more than just a technical dump. I will walk through all the practical, step-by-step guide, including downloads, checks, patching, verification required for the patching.

Note: On production systems, please do not follow this mindlessly. Always apply on test/dev first!

 

How to Apply Oracle 19.29 Patch – Full Walkthrough

Let’s dive into the actual process.

---

1. Download the Patch and OPatch Utility

• Log in to Oracle Support using your org credentials.
• Select Patches & Product certification matrix from search box
• Provide patch no : 38291812 , 6880880
• Select your platform: For e.g. Linux x86-64
• Download & review the README file 
• Download:
• Patch file: p38291812_190000_Linux-x86-64.zip
• OPatch utility: p6880880_190000_Linux-x86-64.zip

 

  

2. Check and  update OPatch Utility

In the server:

[oracle@ocisoumya ~]$cd $ORACLE_HOME/OPatch [oracle@ocisoumya ~]$./opatch version

 You need version 12.2.0.1.48 or higher.

If it doesn’t show above version, update opatch

[oracle@ocisoumya ~]$mv OPatch OPatch_backup1 [oracle@ocisoumya ~]$cp p6880880_190000_Linux-x86-64.zip $ORACLE_HOME [oracle@ocisoumya ~]$cd $ORACLE_HOME [oracle@ocisoumya ~]$ unzip p6880880_190000_Linux-x86-64.zip

 

Update your .bash_profile to run opatch globally:

[oracle@ocisoumya ~]vi /home/oracle/.bash_profile PATH=$ORACLE_HOME/OPatch:$PATH :wq [oracle@ocisoumya ~]  . ~/.bash_profile

 

3. Prepare the Patch Directory

[oracle@ocisoumya ~]mkdir /home/oracle/patch [oracle@ocisoumya ~] chmod -R 777 /home/oracle/patch

 

Transfer both ZIP files (Patch + OPatch) to this directory using WinSCP or similar.

4. Unzip the Patch

[oracle@ocisoumya ~]cd /home/oracle/patch [oracle@ocisoumya ~]unzip p38291812_190000_Linux-x86-64.zip [oracle@ocisoumya ~]cd 38291812

 

5. Run Pre-checks

Before applying the patch, check for conflicts:

[oracle@ocisoumya ~] ./opatch prereq CheckConflictAgainstOHWithDetail -ph ./

 

If you see “Success”, you’re good to go.

6. Stop Database and Listener

[oracle@ocisoumya ~]sqlplus / as sysdba SQL> shutdown immediate SQL> exit [oracle@ocisoumya ~] lsnrctl stop

 

Verify that all services are down.

---

7. Clean Up Inactive Patches (Optional)

[oracle@ocisoumya ~]cd $ORACLE_HOME/OPatch [oracle@ocisoumya ~]./opatch util listOrderedInactivePatches [oracle@ocisoumya ~]./opatch util deleteInactivePatches

 

8. Make Sure You Have Enough Space

You’ll need at least 12 GB free in /home.

[oracle@ocisoumya ~] df -h

---

9. Apply the Patch

[oracle@ocisoumya ~]cd /home/oracle/patch/38291812 [oracle@ocisoumya ~] ./opatch apply

 

Watch for success messages during the patch process.

---

10. Run DataPatch

This registers the patch inside the database:

[oracle@ocisoumya ~]cd $ORACLE_HOME/OPatch [oracle@ocisoumya ~] ./datapatch -verbose

 

Start Database and Verify Patch

[oracle@ocisoumya ~]sqlplus / as sysdba SQL>startup SQL> select * from v$version; SQL> select * from dba_registry_sqlpatch;

 

You should see 19.29.0.0.0 listed in the output!

 

Final Tips

•  Always patch standby first in Data Guard setups.
•  Never patch production first — test on a non-prod clone.
•  Always read the README.
•  Share this guide if it helped!

 

How to Fix formsweb.cfg When Fusion Middleware Enterprise Manager Is Not Accessible

Recently for one of my customer  I ran into a tricky situation while Fusion Middleware Enterprise Manager (EM) 12c was completely inaccessible. Normally, any configuration changes in Oracle Forms, reports or for weblogic  we use Fusion Middleware Enterprise Manager (EM) . Our requirement was to update especially formsweb.cfg which generally is changed through EM. But when EM itself is down, we had to find a way out.

Below is exactly what we did to safely make the change and bring the environment back without causing configuration corruption.

 

Step 1 — Shut Down the Required Services

First, we stopped the Forms managed server and Admin Server to avoid any configuration lock or file corruption.

• Shutdown WLS_FORMS
• Shutdown Admin Server

 

Step 2 — Navigate to Domain Home

[appltest@testapp ~]$ cd $DOMAIN_HOME [appltest@testapp ~]$ pwd [appltest@testapp ~]$ /u01/app/oracle/product/12.2.1.4/user_projects/domains/prd

 

Step 3 — Clear Configuration Lock (edit.lok)

WebLogic sometimes leaves an edit session lock if a previous configuration change did not complete properly.

If the following file exists, remove it

[appltest@testapp ~]$  rm -rf edit.lok

 

Step 4 — Clear Pending Changes

WebLogic stores in-progress configuration updates inside a pending directory. If this folder contains files, the Admin Server assumes an edit session is still active.

Delete any files inside $DOMAIN_HOME/pending/*

[appltest@testapp ~]$ rm -rf $DOMAIN_HOME/pending/*

 

Step 5 — Clear Temporary and Cache Directories

To ensure a clean startup, we removed temporary and cache files. These directories will be recreated automatically when servers restart.

[appltest@testapp ~]$ $DOMAIN_HOME/servers/AdminServer/tmp/ [appltest@testapp ~]$ $DOMAIN_HOME/servers/WLS_FORMS/tmp/ [appltest@testapp ~]$ $DOMAIN_HOME/servers/WLS_FORMS/cache/

 

Step 6 — Edit formsweb.cfg Manually

After cleanup, we updated the required configuration directly in the file:

[appltest@testapp ~]$  vi $DOMAIN_HOME/config/fmwconfig/components/FORMS/instances/forms1/config/formsweb.cfg   userid=new_username/new_password@orcl

 

Step 7 — Restart serivces and Verify

1. Start the Admin Server
2. Wait until it reaches RUNNING state
3. Start Forms services and verify changes.

Dealing with the "Stuck" Workflow Mailer in EBS 12.2: A Practical Guide

 

We all have  seen something like this . We just finished a fresh clone from Production to Test. After the post-clone steps are done, the services are coming up, but then we found the Workflow Notification Mailer is stuck. Its stuck at starting phase.

In a recent project for one of our customer, we noticed this exact scenario. After a successful clone, the mailer was perpetually stuck in a "Starting" phase.

The Problem: New Credentials vs. Old State

After cloning, the Test environment still has the Production SMTP and IMAP settings. Naturally, you have to update these fields—changing the server name which should point to correct smtp address and a valid credential to match the test or your cloned instance mailboxes

The issue seems to be that the Workflow Mailer is trying to start using the new credentials that were recently updated, but it is getting confused because  it is still seeing the previous Running state and some old control messages that came along with the Production snapshot.

The Root Cause: "Identity Crisis"

When an EBS environment is cloned, the target database initially behaves as if it’s still part of the source system. Even after completing adcfgclone and AutoConfig, the Workflow Advanced Queues (AQ) may still retain references or cached state information from the Production environment.

In this situation, the Workflow Mailer was trying to initialize, but it was encountering leftover control messages and orphaned process IDs that did not exist on the new Test server, which prevented it from starting properly.

So here is how we resolved the problem:-

Clearing the Database Block

Our first approach was to manually reset the component status. However, the UPDATE statement became unresponsive, indicating that another session was holding a lock on the FND_SVC_COMPONENTS table.

So, we identified the blocking session and killed it at the database level.

Once the session was killed, lock was cleared, we successfully forced the status to 'STOPPED'

To check workflow mailer status:-

SQL> SELECT component_status FROM fnd_svc_components WHERE component_name = 'Workflow Notification Mailer';

Find out the session stuck with 'FND_SVC_COMPONENTS' component

SQL> SELECT     l.session_id AS blocking_session,     s.username,     s.osuser,     s.program,     s.status,     s.last_call_et AS seconds_in_wait FROM v$locked_object l JOIN v$session s ON l.session_id = s.sid WHERE l.object_id in (SELECT object_id FROM all_objects WHERE object_name = 'FND_SVC_COMPONENTS');

Kill the Session

If the above query shows any rows, it means a session is holding a lock and must be killed to release it. Use the SID and SERIAL# values from the query output and kill that session at the db level.

SQL> Alter system kill session ‘sid , serial#’ immediate;

Update the fnd_svc_components table forcefully as stopped.

SQL> UPDATE fnd_svc_components SET component_status = 'STOPPED' WHERE component_name = 'Workflow Notification Mailer';

Reset the main component status

SQL>UPDATE fnd_svc_comp_requests SET component_status = 'STOPPED' WHERE component_id = (SELECT component_id FROM fnd_svc_components WHERE component_name = 'Workflow Notification Mailer'); SQL> COMMIT;

Also, you must check at OS level. If there is a "zombie" process, the mailer will never start correctly even after the above update.

ps -ef | grep FNDCPGSC

If a process exists, use kill -9 <PID>.

 

Once above steps are done, try to Workflow notification mailer. It should get started.