Database Consultant (Passionate about Database & Cloud Technologies)

Database Architect,Core DBA ,APPSDBA,Mysql DBA,MongoDB,PostgreSQL,MariaDB,Installations,Upgrades on all Flavors of UNIX (LINUX,SOLARIS,HP(AIX)). Oracle E-Business Suite R12 (Upgrades,Patching,Cloning) AWS upgrades and implementation expert. OCI (Oracle Cloud Infrastructure) Architect, Exadata (Oracle Database Exadata Cloud at Customer(Exacc)),Superclusters ,Autonomous Databases, AWS RDS Customs , Sql Tuning Expert. ***Never Stop sharing,Learning and Growing***

Monday, May 18, 2026

online vs downtime mode in ADOP — When Oracle Forces a Full Outage

online vs downtime mode in ADOP — When Oracle Forces a Full Outage | punitoracledba

Oracle EBS DBA Series · May 2026 · punitoracledba.blogspot.com

online vs downtime mode in ADOP — When Oracle Forces a Full Outage

Oracle EBS R12.2 | ADOP apply_mode | Online Patching | Downtime Mode | 8 min read

One of the most common assumptions EBS R12.2 DBAs make is that all patches run in online mode — that users stay connected throughout and the only downtime is the brief cutover window. This is usually true, but not always.

Some patches require downtime mode, which is a fundamentally different way of applying a patch. It bypasses the online patching cycle entirely, patches the run filesystem directly, and requires a full application outage during the apply phase — not just at cutover.

Understanding the difference between online mode, downtime mode, and hotpatch mode is essential before you start any patching session. Getting it wrong means either an unexpected outage or a failed patch apply.

The Three apply_mode Options

ADOP supports three modes through the apply_mode parameter. Each works differently and applies the patch to a different target.

apply_mode	Target	Outage Required	Uses Patching Cycle
`online`	Patch edition and patch filesystem	Only at cutover — 10 to 30 min	Yes — full prepare to cleanup cycle
`downtime`	Run edition and run filesystem directly	Full outage during apply phase	No — no patching cycle needed
`hotpatch`	Run edition and run filesystem directly	None — services stay running	No — no patching cycle needed

The default mode when you run adop phase=apply without specifying apply_mode is online. You never need to type apply_mode=online explicitly — it is assumed unless you specify otherwise.

Online Mode — The Standard Approach

Online mode is what ADOP was built for. The patch is applied to the patch edition of the database and the patch filesystem while the run edition continues serving users. The five-phase cycle runs in full — prepare, apply, finalize, cutover, cleanup.

Standard online mode apply — default behaviour

# apply_mode=online is the default — no need to specify it
adop phase=apply patches=36478206 workers=8

# Same result — explicit is fine but not required
adop phase=apply patches=36478206 apply_mode=online workers=8

What happens during online mode

Patch files are copied to the patch filesystem
Database changes are applied to the patch edition only
Users continue working on the run edition — fully unaffected
Finalize compiles objects and generates forms in the patch edition
Cutover is the only window where services restart — typically 10 to 30 minutes

All Oracle EBS R12.2 CPU patches are designed and tested for online mode. This is the mode you should use for every quarterly CPU patch unless the patch README explicitly states otherwise.

Downtime Mode — When Oracle Forces a Full Outage

Downtime mode bypasses the online patching cycle entirely. There is no prepare phase, no patch edition, and no dual filesystem switch. The patch is applied directly to the run edition and run filesystem — with all application services shut down first.

This is a fundamentally different process. It is not just a longer version of online mode. It is a separate patching method with its own rules.

Downtime mode apply command

# Shut down ALL application services before running this
# ADOP will verify services are down before proceeding
adop phase=apply patches=36478206 apply_mode=downtime

# No prepare phase before this
# No finalize, cutover, or cleanup after this
# The patch is complete when the apply command finishes

What happens during downtime mode

ADOP verifies that all application tier services are shut down
If services are still running, ADOP will refuse to proceed
The patch is applied directly to the run edition of the database
The patch is applied directly to the run filesystem
When apply completes, restart services manually — no cutover needed

Important rules for downtime mode from Oracle:

1. Downtime mode is only supported for production use where it is explicitly documented in the patch README, or when directed by Oracle Support or Development.

2. R12.2 patches are not normally tested in downtime mode. Use it only when Oracle mandates it — not as a shortcut.

3. No online patching cycle can be in progress when running downtime mode.

Shutting down services before downtime mode

Stop all services before downtime mode apply # Source the run environment source /u01/oracle/R122/EBSapps.env run # Stop all application tier services $ADMIN_SCRIPTS_HOME/adstpall.sh apps/<apps_password> # Verify services are down $ADMIN_SCRIPTS_HOME/adstatus.sh # Now run the downtime mode apply adop phase=apply patches=36478206 apply_mode=downtime # After apply completes — restart services $ADMIN_SCRIPTS_HOME/adstrtal.sh apps/<apps_password>

Hotpatch Mode — Online Without a Patching Cycle

Hotpatch mode applies the patch directly to the run edition while services remain running — with no prepare phase and no patching cycle. It is the fastest mode but also the most restricted.

Hotpatch mode is only safe for patches that do not modify existing schema objects or code used by the running application. Oracle restricts hotpatch use to specific patch types — NLS patches, Online Help patches, and any patch whose README explicitly states hotpatch is supported.

Hotpatch mode apply command

# Only use when the patch README explicitly approves hotpatch
adop phase=apply patches=36478206 apply_mode=hotpatch

# Services remain running — no outage
# No prepare, finalize, cutover, or cleanup needed

Do not use hotpatch mode for CPU patches. CPU patches modify schema objects and code. Applying them in hotpatch mode can cause application failures for users who are connected during the apply. Always use online mode for CPU patches.

How to Know Which Mode Your Patch Requires

This is the most practical question and the one most DBAs skip in their rush to start patching. The answer is always in the patch README. Here is how to check.

Step 1 — Read the patch README

Every patch downloaded from MOS includes a README.txt and README.html file. Open it before running any adop command. Look for these specific phrases:

What to search for in the README # Open the README and search for these terms grep -i "downtime\|apply_mode\|hotpatch\|online patching" README.txt # Keywords that mean downtime mode is required: "apply_mode=downtime" "requires downtime" "application services must be down" "not supported in online mode" # Keywords that mean online mode is fine (most patches): "online patching cycle" "adop phase=prepare" "apply in online mode"

Step 2 — Run a dryrun before the real apply

A dryrun simulates the apply without making any changes. If the patch requires downtime mode and you attempt it in online mode, the dryrun will flag the issue before you commit to the real apply.

Always run dryrun first # Run dryrun — no changes are made, issues are flagged adop phase=apply patches=36478206 apply_mode=dryrun # Review the dryrun log for any mode-related warnings tail -100 $APPL_TOP_NE/admin/log/adop/<session_id>/<timestamp>/adop.log

Step 3 — Check MOS for the patch note

For CPU patches, the MOS availability document — MOSFS KA1539 for April 2026 — lists any patches that require downtime mode. Always read this before downloading patches.

Key Differences — Side by Side

Factor	Online Mode	Downtime Mode	Hotpatch Mode
Prepare phase needed	Yes	No	No
Services during apply	Running	Must be down	Running
Patch applied to	Patch edition / patch filesystem	Run edition / run filesystem	Run edition / run filesystem
Cutover phase needed	Yes	No	No
Total user downtime	10 to 30 min at cutover only	Full duration of apply	None
Tested by Oracle internally	Yes — standard	Not normally	Only for specific patch types
Safe for CPU patches	Yes	Only when README states it	No
Can abort if needed	Yes — adop phase=abort	No — no cycle to abort	No — use restart=yes or abandon=yes

Why Some Patches Require Downtime Mode

Online patching in R12.2 works because of Edition-Based Redefinition (EBR) in the Oracle database. EBR allows two editions of database objects to exist simultaneously — the run edition for users and the patch edition for patching. This is what makes online patching possible.

However, not all database objects can be editioned. Objects like database triggers, sequences, synonyms, and certain types of tables are non-editioned — they exist in a single copy shared by both editions.

When a patch needs to modify a non-editioned object, it cannot do so safely while users are connected to the run edition. Making a structural change to a shared object while users are actively using it risks data corruption or application errors. Oracle therefore mandates downtime mode for patches that touch these objects.

Editioned objects — packages, procedures, functions, views, types — safe for online mode
Non-editioned objects — sequences, synonyms, triggers, certain tables — require downtime mode
The patch README will always state which category applies

Planning Your Maintenance Window

The mode your patch requires directly determines how long your maintenance window needs to be. Plan accordingly before communicating downtime to your users.

Mode	When to Communicate Downtime	Estimated Window
Online mode	For cutover phase only	10 to 30 minutes at cutover
Downtime mode	For entire apply phase plus service restart	Duration of apply plus 15 to 30 min for service start/stop
Hotpatch mode	No downtime to communicate	Zero user-facing downtime

When a CPU patch cycle includes both online patches and one downtime-mode patch, plan the maintenance window around the downtime-mode patch. Apply downtime patches in their own separate session. Do not mix modes in the same ADOP cycle.

Quick Decision Guide

Situation	Mode to Use
Quarterly CPU patch — README says online patching cycle	`apply_mode=online` (default)
README explicitly says apply_mode=downtime	`apply_mode=downtime` — shut down services first
NLS patch or Online Help patch	`apply_mode=hotpatch` — only if README confirms
Oracle Support directs you to downtime mode	`apply_mode=downtime` — follow their instructions exactly
Not sure which mode to use	Read the README. Run dryrun. Default to online. Raise SR if unclear.

Common Mistakes to Avoid

Mistake	What to Do Instead
Running downtime mode without reading the README	Always read README first — downtime mode is only for patches that mandate it
Using downtime mode as a shortcut to skip the patching cycle	Online mode is the standard. Downtime mode is not a shortcut — it carries risk
Running downtime mode while services are still up	ADOP will refuse to proceed — shut down all services before running downtime mode
Using hotpatch mode for CPU patches	CPU patches modify schema objects — hotpatch mode will cause application errors
Running downtime mode while an online patching cycle is active	Complete or abort the existing cycle before running downtime mode
Not running dryrun before the real apply	Always dryrun first — it will flag mode-related issues before real apply starts

Summary

Online mode is the default and the standard for all CPU patches — users stay connected throughout, only cutover causes a brief outage
Downtime mode bypasses the patching cycle, patches the run edition directly, and requires a full outage during apply — use only when the patch README mandates it
Hotpatch mode patches the run edition with no outage — restricted to NLS, Online Help, and patches that explicitly document hotpatch support
Always read the patch README before starting any apply session
Always run apply_mode=dryrun before the real apply
When in doubt, default to online mode and raise an SR with Oracle Support

ADOP phase=apply Failed — How to Diagnose and Recover Without Aborting

ADOP phase=apply Failed — How to Diagnose and Recover Without Aborting | punitoracledba

Oracle EBS DBA Series · May 2026 · punitoracledba.blogspot.com

ADOP phase=apply Failed — How to Diagnose and Recover Without Aborting

Oracle EBS R12.2 | ADOP Troubleshooting | Workers | Recovery | 10 min read

A failed adop phase=apply is one of the most stressful moments in EBS patching. Your maintenance window is ticking, users are waiting, and the terminal is showing errors. The instinct of many DBAs is to immediately run adop phase=abort and start again — but this is almost always the wrong move.

In most cases a failed apply can be diagnosed quickly, fixed in place, and restarted using restart=yes — without losing your prepare phase, without aborting the session, and without starting the entire cycle over from scratch.

This post walks through the exact steps to diagnose a failed apply, find the root cause in the logs, fix it, and restart cleanly.

Rule of thumb: Never run adop phase=abort as your first response to a failure. Always try restart=yes first. Abort is a last resort — it leaves the system in an inconsistent state and forces a full new cycle.

Why adop phase=apply Fails

The apply phase uses multiple parallel workers to process patch jobs. If any single worker encounters an error it cannot handle, that worker is marked as Failed and the apply session stops. The most common causes are:

Cause	What It Looks Like
Database object errors	ORA- errors in worker log — invalid object, constraint violation, compile error
Insufficient disk space	Worker stops mid-task — check APPL_TOP, PATCH_TOP, /tmp
File permission issues	Permission denied errors in the worker log
Missing prerequisite patch	Object or file expected by the patch does not exist
Network or DB connectivity drop	Worker loses connection mid-task — ORA-03113, ORA-03114
Locked or busy database objects	ORA-00054 resource busy — object locked by another session

Step 1 — Check the ADOP Session Status

The first thing to do after a failure is check what ADOP knows about the current session. This tells you which phase failed, on which node, and what the overall state is.

Check ADOP session status

# Source the run environment first
source /u01/oracle/R122/EBSapps.env run

# Check overall session status
adop phase=status

# Or query the database directly for more detail
sqlplus apps/<apps_password> <<EOF
SELECT adop_session_id,
       status,
       start_date,
       end_date,
       abandon_flag
FROM   ad_adop_sessions
ORDER  BY adop_session_id DESC
FETCH  FIRST 5 ROWS ONLY;
EOF

Find failed workers specifically sqlplus apps/<apps_password> <<EOF SELECT worker_id, status, start_date, end_date FROM ad_workers WHERE status = 'Failed' ORDER BY worker_id; EOF

Note the worker_id of every failed worker. You will use these numbers to find the correct log files in the next step.

Step 2 — Find and Read the Worker Log Files

ADOP stores all log files on the non-editioned filesystem under $APPL_TOP_NE. The log structure follows a predictable pattern based on the session ID and execution timestamp.

Locate the ADOP log directory # Base log location echo $APPL_TOP_NE # Logs are at: $APPL_TOP_NE/admin/log/adop/<session_id>/ # List sessions — find your current session ID ls -lt $APPL_TOP_NE/admin/log/adop/ # Navigate to the apply phase logs for your session cd $APPL_TOP_NE/admin/log/adop/<session_id>/<timestamp>/ # List contents to find worker log files ls -la

Read the failed worker log — replace N with the worker number

# View the last 200 lines of the failed worker log
tail -200 $APPL_TOP_NE/admin/log/adop/<session_id>/<timestamp>/adwork<N>.log

# Search specifically for ERROR lines
grep -i "error\|ORA-\|failed\|fatal" \
  $APPL_TOP_NE/admin/log/adop/<session_id>/<timestamp>/adwork<N>.log

# Also check the main adop log for context
tail -100 $APPL_TOP_NE/admin/log/adop/<session_id>/<timestamp>/adop.log

Always read the log from the bottom up. The actual error is usually the last meaningful line before the worker stopped. Lines above it are the normal processing that succeeded before the failure.

Step 3 — Diagnose the Root Cause

Once you have read the worker log, match the error to one of the common scenarios below and apply the fix before attempting to restart.

Scenario A — ORA- database errors

The most common type. Look for the ORA- error code in the worker log and resolve it before restarting.

Common ORA- errors and what to check ORA-00054: resource busy and acquire with NOWAIT --> A database object is locked. Find and kill the blocking session: SELECT sid, serial#, username, status, machine FROM v$session WHERE status = 'ACTIVE' AND username IS NOT NULL ORDER BY last_call_et DESC; -- Kill the blocking session: ALTER SYSTEM KILL SESSION '<sid>,<serial#>' IMMEDIATE; ORA-04031: unable to allocate memory in shared pool --> Increase shared_pool_size or flush the shared pool: ALTER SYSTEM FLUSH SHARED_POOL; ORA-01536: space quota exceeded --> Increase quota for APPS user or add space to the tablespace

Scenario B — Disk space exhausted

Check disk space on all critical mounts

# Check disk space — need minimum 20GB free on each
df -h $APPL_TOP $PATCH_TOP $APPL_TOP_NE /tmp

# Find large files consuming space in PATCH_TOP
du -sh $PATCH_TOP/*
find $PATCH_TOP -name "*.log" -size +500M

# Clean up old adop logs from previous sessions if needed
# Only remove logs from sessions that are fully completed
ls $APPL_TOP_NE/admin/log/adop/

Scenario C — File permission error

Check and fix file permissions # Look for permission denied in the worker log grep -i "permission denied" \ $APPL_TOP_NE/admin/log/adop/<session_id>/<timestamp>/adwork<N>.log # Fix permissions on APPL_TOP if needed # Run as the applmgr OS user chmod -R 755 $APPL_TOP/<product_short_name>/

Scenario D — Missing prerequisite patch

The worker log will show something like object does not exist or file not found for a file or DB object that the patch expects to already be present. This means a prerequisite patch was not applied.

Check the patch README.txt for listed prerequisites
Confirm those prerequisite patches are registered in AD_BUGS
If missing, abort the current session, apply the prerequisite, then start a fresh cycle

Verify a prerequisite patch is applied sqlplus apps/<apps_password> <<EOF SELECT bug_number, last_update_date FROM ad_bugs WHERE bug_number = '<prerequisite_patch_number>'; EOF

Step 4 — Restart the Failed Apply Session

Once the root cause is fixed, restart the apply session using restart=yes. ADOP will pick up from where it failed — it does not re-run jobs that already completed successfully.

Restart the apply session

# Source the run environment
source /u01/oracle/R122/EBSapps.env run

# Restart with the same patch number — ADOP resumes from failure point
adop phase=apply patches=<patch_number> restart=yes

# If you need fewer workers on restart due to resource constraints
adop phase=apply patches=<patch_number> restart=yes workers=4

# Monitor the restarted session
adop phase=status

Important: When restarting, specify the same patch number as the original apply command. Do not change the patches parameter — ADOP uses it to validate the session matches what was started.

Watch the apply session after restart. If the same worker fails again on the same task, the root cause was not fully resolved. Read the log again and look more carefully for the underlying error.

Step 5 — Verify Apply Completed Successfully

After a successful restart, confirm that all workers finished cleanly before moving to the finalize phase.

Confirm all workers completed sqlplus apps/<apps_password> <<EOF -- Should return no rows if all workers completed SELECT worker_id, status FROM ad_workers WHERE status NOT IN ('Completed', 'Assigned') ORDER BY worker_id; -- Check overall session is in apply completed state SELECT adop_session_id, status FROM ad_adop_sessions ORDER BY adop_session_id DESC FETCH FIRST 3 ROWS ONLY; EOF

Once all workers show Completed and the apply phase status is clean, continue to the finalize phase as normal.

Continue the patching cycle adop phase=finalize adop phase=cutover adop phase=cleanup

When Abort Is Actually the Right Choice

There are situations where adop phase=abort is genuinely necessary. Use it only when:

A prerequisite patch is missing and cannot be applied within the current cycle
The patch itself is incorrect or was downloaded for the wrong platform
The database edition is corrupted and cannot be recovered
Oracle Support has reviewed the logs and explicitly recommends abort
The apply failure is due to a known bug in the patch itself

After abort — what happens: An aborted session leaves the patch edition in an unusable state. You must run adop phase=abort,cleanup cleanup_mode=full to fully clean up before starting a fresh prepare. Do not skip the cleanup after abort.

Full abort and cleanup sequence # Abort the current session adop phase=abort # Run full cleanup to remove the patch edition adop phase=cleanup cleanup_mode=full # Verify no pending session remains adop phase=status # Start fresh when ready adop phase=prepare

Quick Log Location Reference

Log File	Location	What It Contains
`adop.log`	`$APPL_TOP_NE/admin/log/adop/<session>/<timestamp>/`	Main ADOP session log — overall progress and phase transitions
`adwork<N>.log`	Same directory as adop.log	Individual worker log — the actual error will be here
`adzdshowstatus.out`	Same directory as adop.log	Status report output from `adop phase=status`
Patch-specific logs	Under `$PATCH_TOP/<patch_number>/log/`	Logs written by the patch driver itself during execution

Recovery Decision Tree

Situation	Action
Worker failed — root cause identified and fixed	`adop phase=apply patches=... restart=yes`
Worker failed again after restart	Re-read the log — root cause not fully resolved. Fix and restart again.
Prerequisite patch missing	Abort, cleanup full, apply prerequisite, start fresh cycle
Disk space exhausted	Free up space, then restart=yes — do not abort
DB object locked	Kill blocking session, then restart=yes
Oracle Support recommends abort	`adop phase=abort` then `cleanup_mode=full`
Unsure of root cause	Read the log again — do not abort until you understand what failed

Key SQL Queries for ADOP Troubleshooting

All queries — run as APPS user -- Current and recent ADOP sessions SELECT adop_session_id, status, abandon_flag, start_date, end_date FROM ad_adop_sessions ORDER BY adop_session_id DESC FETCH FIRST 5 ROWS ONLY; -- Worker status for current session SELECT worker_id, status, start_date, end_date FROM ad_workers ORDER BY worker_id; -- Find blocking sessions if ORA-00054 SELECT s.sid, s.serial#, s.username, s.status, s.machine, s.last_call_et FROM v$session s WHERE s.status = 'ACTIVE' AND s.username IS NOT NULL ORDER BY s.last_call_et DESC; -- Check invalid objects after failed apply SELECT owner, object_type, COUNT(*) AS cnt FROM dba_objects WHERE status = 'INVALID' GROUP BY owner, object_type ORDER BY owner, object_type; -- Confirm a patch is registered after recovery SELECT bug_number, last_update_date FROM ad_bugs WHERE bug_number = '<patch_number>';

Recovery Checklist

#	Step
1	Run `adop phase=status` to confirm which phase failed
2	Query `AD_WORKERS` to find the failed worker IDs
3	Read the failed worker log — `adwork<N>.log` — from the bottom up
4	Identify the root cause — ORA- error, disk, permission, or prerequisite
5	Fix the root cause — kill locks, free disk, fix permissions
6	Restart using `adop phase=apply patches=... restart=yes`
7	Monitor the restarted session with `adop phase=status`
8	Confirm all workers show Completed in `AD_WORKERS`
9	Continue with `adop phase=finalize` then `cutover`
10	Only abort if restart fails repeatedly and root cause cannot be resolved

ADOP Is Not Enough — The Java Patching Step Most EBS DBAs Skip

ADOP Is Not Enough — The Java Patching Step Most EBS DBAs Skip | punitoracledba

Oracle EBS DBA Series · May 2026 · punitoracledba.blogspot.com

ADOP Is Not Enough — The Java Patching Step Most EBS DBAs Skip

Patch 37171025 | EJCPUC | Oracle EBS R12.2 | CPU April 2026 | 8 min read

If you applied the April 2026 CPU to your Oracle EBS R12.2 environment using ADOP and called it done — you are not finished. Java patching is a separate step that many DBAs miss entirely, and it leaves real security vulnerabilities open even after a successful ADOP cycle.

This post explains what EJCPUC is, why Java homes in EBS R12.2 need their own patching process, how to run Patch 37171025, and how to read the output report correctly.

Key point: ADOP patches EBS application code, forms, and database objects. It does not patch the Java runtime environments that WebLogic, OAF, Forms, and other EBS components depend on. Those are separate and require their own patching process.

What Is EJCPUC?

EJCPUC stands for EBS Java Critical Patch Update Checker. It is an Oracle-provided shell script that scans every Java home in your EBS environment, reports the current Java CPU level of each one, and tells you exactly which Java security patches are missing.

Oracle first released EJCPUC with the October 2024 CPU and has updated it every quarter since. The April 2026 version is available as Patch 37171025 — the same patch number since initial release, updated in place each quarter with new content and checks.

Source: Oracle EBS Technology Blog — April 2026 Updates to EBS Java Critical Patch Update Checker (EJCPUC), published 27 April 2026 by Elke Phelps, Product Management Director, Oracle EBS Applications Technology Group. blogs.oracle.com/ebstech

Why Java Patching Is a Separate Step

A typical R12.2 environment contains multiple Java homes, each serving a different component. Each has its own Java version and CPU patch level — completely independent of what ADOP does to the EBS application tier.

Application Tier Java Homes

WebLogic / FMW Java home — $FMW_HOME/jdk
EBS application Java home — $JAVA_HOME (applmgr user)
Oracle HTTP Server Java home — $OHS_ORACLE_HOME/jdk
Forms and Reports Java home — $ORACLE_HOME/jdk

Database Tier Java Homes

DB Oracle home JDK — $ORACLE_HOME/jdk
Oracle JVM inside the database — ojvm component
Grid infrastructure Java (RAC environments) — $GRID_HOME/jdk

It is entirely possible to have one Java home at the January 2026 CPU level while another is still at July 2025. EJCPUC discovers all Java homes on a node and reports each one individually so nothing is missed.

Because each Java home is independent, you must run EJCPUC on both the application tier and the database tier and apply the recommended patches to each home separately using OPatch.

What EJCPUC Does

Discovers all Java homes in the EBS environment on that node
Reads the current Java version and CPU patch level of each home
Compares each home against the April 2026 CPU requirements built into the tool
Generates a report listing every Java home, its current level, and the patches needed to bring it up to date

This is why you must always download the latest version of EJCPUC each quarter. Older versions do not know about patches added after their release date and will silently miss them.

Step 1 — Download Patch 37171025

Log in to My Oracle Support at support.oracle.com and search for Patch 37171025. Download it fresh each quarter even if you have a copy from last quarter on disk. The content changes every CPU cycle.

Stage the patch on your server

# Create a staging directory
mkdir -p /stage/ejcpuc

# Unzip the downloaded patch file
unzip p37171025_R12_GENERIC.zip -d /stage/ejcpuc

# Confirm ejcpuc.sh and README.txt are present
ls -la /stage/ejcpuc/

# Always read the README before running
less /stage/ejcpuc/README.txt

Step 2 — Run on the Application Tier

Application tier — run as applmgr

# Source the EBS run environment
source /u01/oracle/R122/EBSapps.env run

# Navigate to the EJCPUC directory
cd /stage/ejcpuc

# Make the script executable if needed
chmod +x ejcpuc.sh

# Run the checker
./ejcpuc.sh

# Locate the output report file
ls -la ejcpuc_report*.txt

If you have multiple application tier nodes, run EJCPUC on each node separately. Java home configurations can differ between nodes.

Step 3 — Run on the Database Tier

This is the step most DBAs skip. The database tier has its own Java homes including the JDK bundled with the Oracle DB home and the Oracle JVM inside the database. Both need to be at the current CPU level.

Database tier — run as the oracle OS user

# Copy EJCPUC to the DB tier node
scp -r /stage/ejcpuc oracle@dbserver:/stage/ejcpuc

# Log in to the database tier node
ssh oracle@dbserver

# Set the Oracle home environment
export ORACLE_HOME=/u01/oracle/product/19.0.0/dbhome_1
export PATH=$ORACLE_HOME/bin:$PATH

# Navigate and run EJCPUC
cd /stage/ejcpuc
./ejcpuc.sh

# Locate the DB tier report
ls -la ejcpuc_report*.txt

Step 4 — Reading the EJCPUC Report

The report has three sections. Here is exactly what to look for in each one.

Section 1 — Environment summary

Shows the hostname, OS user, run date, and EBS release detected. Verify this matches the node you intended to scan before reading further.

Section 2 — Java home discovery and current CPU level

Lists every Java home found on the node with its path, Java version, and the CPU patch level currently applied. This is where you see which homes are up to date and which ones are behind.

Sample Section 2 output [Java Home 1] Path: /u01/oracle/R122/fs1/FMW_Home/jdk Version: Java 11.0.22 CPU Level: January 2026 -- one CPU behind, needs updating [Java Home 2] Path: /u01/oracle/R122/EBSapps/comn/util/jdk Version: Java 11.0.22 CPU Level: July 2025 -- two CPUs behind, apply urgently [Java Home 3] Path: /u01/oracle/R122/fs2/FMW_Home/jdk Version: Java 11.0.22 CPU Level: April 2026 -- up to date, no action needed

Section 3 — Recommended patches

This is your action list. Every patch listed here must be applied. The section gives you the patch number and the exact Java home it applies to. There are no optional items in this list.

Sample Section 3 output

RECOMMENDED PATCHES:

Patch 36583222 - Java 11 CPU April 2026
  Apply to: /u01/oracle/R122/fs1/FMW_Home/jdk

Patch 36583222 - Java 11 CPU April 2026
  Apply to: /u01/oracle/R122/EBSapps/comn/util/jdk

No patches required:
  /u01/oracle/R122/fs2/FMW_Home/jdk  (already at April 2026)

How to interpret the CPU level in the report

CPU Level Shown	Status	Action Required
April 2026	Up to date	None — this Java home is fully patched
January 2026	One CPU behind	Apply the April 2026 Java patch from Section 3
October 2025 or older	Critical	Apply immediately — multiple vulnerabilities are open
Not recognized	Unknown	Check README for manual scan steps — raise SR if needed

Step 5 — Applying the Recommended Java Patches

Java CPU patches for EBS R12.2 Java homes are applied using OPatch — not ADOP. Each Java home is patched independently using the patch number from EJCPUC Section 3.

Important: In R12.2 you have two filesystems — fs1 and fs2. Java homes exist in both. Apply Java CPU patches to the Java homes in both filesystems, not just the active run filesystem.

Apply Java CPU patch to each Java home using OPatch

# Point to the Java home being patched
export JAVA_HOME=/u01/oracle/R122/fs1/FMW_Home/jdk
export PATH=$JAVA_HOME/bin:$PATH

# Confirm you are pointing to the correct Java
java -version

# Unzip the Java CPU patch from MOS
unzip p36583222_1102_Linux-x86-64.zip -d /stage/java_cpu

# Apply using OPatch
cd /stage/java_cpu/36583222
$JAVA_HOME/../OPatch/opatch apply

# Verify patch was applied successfully
$JAVA_HOME/../OPatch/opatch lsinventory | grep 36583222

# Repeat for every Java home listed in EJCPUC Section 3

Step 6 — Run EJCPUC Again After Cutover

Oracle explicitly recommends running EJCPUC a second time after applying patches and performing ADOP cutover. This confirms that all recommended patches were applied successfully and gives you a clean report to save as compliance evidence.

After the second run, Section 3 should show no remaining recommended patches. Save both reports — the before and after — as part of your change management record.

When to Run EJCPUC

When	Why
Before every quarterly CPU cycle	Identify what Java patches are needed before your maintenance window starts
After ADOP cutover	Confirm all patches applied correctly — this is your audit and compliance evidence
Any time you need to report Java CPU level	Security audits, compliance reviews, management reporting

Common Mistakes to Avoid

Mistake	What to Do Instead
Running EJCPUC on the application tier only	Run on both application tier and database tier every time
Reusing last quarter's EJCPUC download	Download Patch 37171025 fresh at the start of every CPU cycle
Only patching the run filesystem Java homes	Patch Java homes in both fs1 and fs2
Not running EJCPUC after cutover	Run before and after — save both reports as evidence
Assuming ADOP patches Java homes	Java CPU patches are applied separately via OPatch on each Java home

Key References

Reference	Description
`Patch 37171025`	EJCPUC — EBS Java Critical Patch Update Checker. Download fresh every quarter.
`Patch 35583866`	ECPUC — EBS application tier patch checker. Run alongside EJCPUC.
`MOSFS KA923`	Always-current EBS CPU availability document. Bookmark permanently.
`MOSFS KA1539`	EBS R12.2 CPU April 2026 — complete patch list and prerequisites.
`MOSFS KA1033`	FAQ: Oracle E-Business Suite Security.

Sunday, May 17, 2026

Oracle EBS R12.2 — Applying CPU April 2026

Oracle EBS R12.2 — Applying the CPU April 2026 Application Patch

Your Complete Step-by-Step DBA Guide

📅 Released: 21 April 2026 | ✍ punitoracledba.blogspot.com | ⏱ 12 min read

⚠ CVSS 9.8 — Apply Now
The April 2026 CPU includes important Oracle EBS security patches. Some vulnerabilities are remotely exploitable, so this CPU should be treated as urgent and applied as soon as possible.

Introduction

Oracle released the Critical Patch Update CPU for April 2026 on 21 April 2026. As an Oracle EBS R12.2 DBA, applying this CPU is an important security and compliance activity. This guide explains the complete end-to-end process including patch identification, checker tools, ADOP patching cycle, and post-patch verification.

This guide is for Oracle EBS R12.2 only. Application tier patches on R12.2 are applied using ADOP Online Patching. The old adpatch utility is not used for R12.2 application patches.

Step 0 — MOS Starting Point

MOSFS Article ID	What It Contains
KA923	Always points to the latest EBS CPU availability document.
KA1539	April 2026 specific patch list, prerequisites, and known issues for EBS R12.2.
KA1033	EBS Security FAQ and security background reading.

Pro Habit: Always start with KA923 because it points to the current CPU document every quarter.

Step 1 — Run Oracle Checker Tools First

Oracle provides checker utilities for EBS R12.2. Run these tools before downloading or applying patches. They help identify missing patches specific to your environment.

Tool	Patch	Purpose
ECPUC	Patch 35583866	EBS Critical Patch Update Checker. Generates ECPUC.lst.
EJCPUC	Patch 37171025	EBS Java CPU Checker for app tier and DB tier nodes.

How to Run ECPUC

# Source the run edition environment
source /u01/oracle/R122/EBSapps.env run

# Unzip ECPUC patch
unzip p35583866_R12_GENERIC.zip -d /stage/ecpuc

# Connect as APPS and run checker
sqlplus apps/<apps_password>

SQL> @/stage/ecpuc/ECPUC.sql

# Review generated report
cat ECPUC.lst

Review Section 3 of ECPUC.lst carefully. This section lists the required EBS CPU patches for your environment.

How to Run EJCPUC

# Unzip EJCPUC patch
unzip p37171025_R12_GENERIC.zip -d /stage/ejcpuc

# Run on application tier
source /u01/oracle/R122/EBSapps.env run
cd /stage/ejcpuc
./ejcpuc.sh

# Run separately on database tier
cd /stage/ejcpuc
./ejcpuc.sh

Always download the latest version of ECPUC and EJCPUC for the current CPU cycle.

Step 2 — Pre-Patch Health Checks

-- Check stale ADOP sessions
SELECT STATUS, ABANDON_FLAG, START_DATE
FROM   AD_ADOP_SESSIONS
WHERE  STATUS NOT IN ('completed', 'abandoned')
ORDER BY START_DATE DESC;

-- Check failed workers
SELECT WORKER_ID, STATUS, START_DATE
FROM   AD_WORKERS
WHERE  STATUS = 'Failed';

-- Check DB editions
SELECT EDITION_NAME, STATUS
FROM   DBA_EDITIONS
ORDER BY CREATED;

-- Check invalid objects
SELECT COUNT(*)
FROM   DBA_OBJECTS
WHERE  STATUS = 'INVALID';

# Check disk space
df -h $APPL_TOP $COMMON_TOP $NE_BASE

# Check ADOP status
adop phase=status

Backup is mandatory: Take RMAN database backup and application tier backup or snapshot before starting patching.

Step 3 — Apply Patches Using ADOP

In EBS R12.2, CPU application patches are applied using the ADOP cycle. Only the cutover phase requires user downtime.

Phase	Downtime
Prepare	No downtime
Apply	No downtime
Finalize	No downtime
Cutover	Brief outage
Cleanup	No downtime

Phase 1 — Prepare

source /u01/oracle/R122/EBSapps.env run

adop phase=prepare

Phase 2 — Apply

# Dry run first
adop phase=apply patches=PATCH1,PATCH2,PATCH3 apply_mode=dryrun

# Real apply
adop phase=apply patches=PATCH1,PATCH2,PATCH3 apply_mode=online workers=8

# Monitor
adop phase=status

Phase 3 — Finalize

adop phase=finalize

SELECT COUNT(*)
FROM   DBA_OBJECTS
WHERE  STATUS = 'INVALID';

Phase 4 — Cutover

adop phase=cutover

SELECT EDITION_NAME, STATUS
FROM   DBA_EDITIONS
ORDER BY CREATED DESC;

Phase 5 — Cleanup

# Dry run cleanup
adop phase=cleanup mode=dryrun

# Full cleanup
adop phase=cleanup

Step 4 — Post-Patch Verification

-- Confirm patches are registered
SELECT BUG_NUMBER, LAST_UPDATE_DATE
FROM   AD_BUGS
WHERE  BUG_NUMBER IN ('PATCH1', 'PATCH2', 'PATCH3');

-- Confirm active edition
SELECT EDITION_NAME, STATUS
FROM   DBA_EDITIONS
ORDER BY CREATED DESC;

-- Check invalid objects
SELECT COUNT(*)
FROM   DBA_OBJECTS
WHERE  STATUS = 'INVALID';

# Verify services
$ADMIN_SCRIPTS_HOME/adstatus.sh

Run ECPUC again after cutover. If ECPUC.lst shows zero remaining patches, save it as audit evidence.

Complete Checklist

Open MOSFS KA923 and navigate to the current CPU document.
Download and run ECPUC.
Download and run EJCPUC on app tier and DB tier.
Download all patches listed in ECPUC.lst.
Confirm no stale ADOP cycle.
Confirm no failed workers.
Confirm enough disk space.
Take full RMAN and application backup.
Run ADOP prepare, apply, finalize, cutover, and cleanup.
Run ECPUC again after patching.
Complete smoke testing.
Document results and close the change ticket.
Patch order should be DEV → UAT → PROD.

Key References

Reference	Description
MOSFS KA923	Latest EBS CPU document
MOSFS KA1539	April 2026 EBS CPU Availability Document
Patch 35583866	ECPUC Checker
Patch 37171025	EJCPUC Checker
Patch 17537119	ETCC Technology Codelevel Checker

Written by Punit Kumar | Oracle EBS DBA Notes | punitoracledba.blogspot.com

Friday, May 15, 2026

Oracle EBS R12: Create User & Assign Responsibility — Step-by-Step DBA Guide with SQL Verification

This guide explains how to create a user in Oracle E-Business Suite R12, assign a responsibility, and verify the setup using SQL queries.

1. Business Requirement

As an Oracle Apps DBA, you may receive a request to create a new EBS application user and assign required responsibilities.

Example Requirement:

Create EBS user       : MAHILANIA
Assign Responsibility : System Administrator
Application          : System Administration

2. Important Tables Used

Table Name	Purpose
FND_USER	Stores EBS application user details
FND_RESPONSIBILITY	Stores responsibility details
FND_RESPONSIBILITY_TL	Stores translated responsibility names
FND_APPLICATION	Stores application details
FND_USER_RESP_GROUPS_DIRECT	Stores direct user responsibility assignments

3. Source the EBS Environment

cd $INST_TOP/ora/10.1.2
. <CONTEXT_NAME>.env

Or source the main EBS environment file:

. /u01/oracle/EBSapps.env run

4. Connect to SQL*Plus as APPS

sqlplus apps/<apps_password>

5. Create EBS User Using FND_USER_PKG

Use the standard Oracle seeded API FND_USER_PKG.CREATEUSER to create an application user.

BEGIN
  FND_USER_PKG.CREATEUSER(
    x_user_name              => 'MAHILANIA',
    x_owner                  => 'CUST',
    x_unencrypted_password   => 'Welcome123',
    x_start_date             => SYSDATE,
    x_end_date               => NULL,
    x_password_date          => SYSDATE,
    x_email_address          => 'mahilania@example.com'
  );

  COMMIT;
END;
/

Note: Replace the password and email address as per your organization policy.

6. Verify User Creation

SELECT user_id,
       user_name,
       start_date,
       end_date,
       email_address,
       creation_date
FROM   fnd_user
WHERE  user_name = 'MAHILANIA';

7. Find Responsibility Details

Before assigning a responsibility, find the correct responsibility name, responsibility ID, application ID, and security group ID.

SELECT fr.responsibility_id,
       fr.application_id,
       frt.responsibility_name,
       fa.application_short_name
FROM   fnd_responsibility fr,
       fnd_responsibility_tl frt,
       fnd_application fa
WHERE  fr.responsibility_id = frt.responsibility_id
AND    fr.application_id = frt.application_id
AND    fr.application_id = fa.application_id
AND    frt.language = USERENV('LANG')
AND    frt.responsibility_name LIKE 'System Administrator';

8. Assign Responsibility to User

Use FND_USER_PKG.ADDRESP to assign responsibility to the EBS user.

BEGIN
  FND_USER_PKG.ADDRESP(
    username       => 'MAHILANIA',
    resp_app       => 'SYSADMIN',
    resp_key       => 'SYSTEM_ADMINISTRATOR',
    security_group => 'STANDARD',
    description    => 'System Administrator responsibility assigned by Apps DBA',
    start_date     => SYSDATE,
    end_date       => NULL
  );

  COMMIT;
END;
/

9. Verify Responsibility Assignment

SELECT fu.user_name,
       frt.responsibility_name,
       fa.application_short_name,
       furg.start_date,
       furg.end_date
FROM   fnd_user fu,
       fnd_user_resp_groups_direct furg,
       fnd_responsibility_tl frt,
       fnd_responsibility fr,
       fnd_application fa
WHERE  fu.user_id = furg.user_id
AND    furg.responsibility_id = fr.responsibility_id
AND    furg.responsibility_application_id = fr.application_id
AND    fr.responsibility_id = frt.responsibility_id
AND    fr.application_id = frt.application_id
AND    fr.application_id = fa.application_id
AND    frt.language = USERENV('LANG')
AND    fu.user_name = 'MAHILANIA';

10. Check User Login Status

SELECT user_name,
       start_date,
       end_date,
       password_date,
       password_lifespan_days,
       password_accesses_left
FROM   fnd_user
WHERE  user_name = 'MAHILANIA';

11. End Date a Responsibility

If you need to remove access, do not delete records directly. End-date the responsibility using Oracle API.

BEGIN
  FND_USER_PKG.DELRESP(
    username       => 'MAHILANIA',
    resp_app       => 'SYSADMIN',
    resp_key       => 'SYSTEM_ADMINISTRATOR',
    security_group => 'STANDARD'
  );

  COMMIT;
END;
/

12. End Date an EBS User

UPDATE fnd_user
SET    end_date = SYSDATE
WHERE  user_name = 'MAHILANIA';

COMMIT;

13. Common Issues

Issue	Possible Cause	Action
User not visible in EBS	User not committed or wrong username	Verify in FND_USER
Responsibility not visible after login	Incorrect responsibility key or application short name	Verify responsibility details using SQL
Password issue	Password policy restriction	Reset password from System Administrator responsibility
Responsibility expired	End date is already set	Check FND_USER_RESP_GROUPS_DIRECT

14. Best Practices for Apps DBA

Always use Oracle seeded APIs where possible.
Do not directly insert records into FND tables.
Take approval before granting powerful responsibilities.
Use strong password policies.
Validate user and responsibility assignment using SQL.
End-date users when access is no longer required.
Keep audit details for production access changes.

15. Quick Validation Script

SET LINES 200
COL user_name FORMAT A20
COL responsibility_name FORMAT A40
COL application_short_name FORMAT A20

SELECT fu.user_name,
       frt.responsibility_name,
       fa.application_short_name,
       furg.start_date,
       furg.end_date
FROM   fnd_user fu,
       fnd_user_resp_groups_direct furg,
       fnd_responsibility_tl frt,
       fnd_responsibility fr,
       fnd_application fa
WHERE  fu.user_id = furg.user_id
AND    furg.responsibility_id = fr.responsibility_id
AND    furg.responsibility_application_id = fr.application_id
AND    fr.responsibility_id = frt.responsibility_id
AND    fr.application_id = frt.application_id
AND    fr.application_id = fa.application_id
AND    frt.language = USERENV('LANG')
AND    fu.user_name = UPPER('&USER_NAME');

Conclusion

Creating an Oracle EBS R12 user and assigning responsibility is a common Apps DBA activity. The safest approach is to use Oracle seeded APIs such as FND_USER_PKG.CREATEUSER and FND_USER_PKG.ADDRESP. Always verify the user and responsibility assignment from backend tables before confirming access to the business team.

Author: Punit Kumar
Role: Oracle Apps DBA / Oracle DBA Specialist

Tuesday, May 12, 2026

How to Enable HTTPS on Oracle EBS R12.2

punitoracledba.blogspot.com · EBS R12.2 + Okta SSO Series ·

SSL / HTTPS · Phase 1 Prerequisite

How to Enable HTTPS on Oracle EBS R12.2 — Step by Step

Before Okta SSO can work, your EBS environment needs HTTPS. This guide covers Oracle Wallet creation, OHS configuration, and going live on port 443 — with exact commands for your environment.

punitoracledba · EBS R12.2.13 · RHEL 8 · OHS 12.2.x · ~10 min read

EBS R12.2.13 + Okta SSO Implementation

Why HTTPS First?

Okta is a cloud-based Identity Provider (IdP) that communicates over SAML 2.0. Every SAML assertion it sends contains sensitive authentication tokens. Without HTTPS, those tokens travel in plain text — and Okta simply refuses to integrate with HTTP endpoints. No SSL = no SSO. Full stop.

In this post, we configure HTTPS on Oracle HTTP Server (OHS) for EBS R12.2.13 running on RHEL 8, using an Oracle Wallet with a self-signed certificate on port 443.

Note: For production environments, replace the self-signed certificate with one from your internal CA or a trusted CA (DigiCert, Sectigo, etc.). All other steps remain identical.

Environment Reference

Component	Value
Application server	`pc.app.com`
Database server	`pc.db.com : 1533`
Current EBS URL	`http://pc.app.com:8012`
Target HTTPS URL	`https://pc.app.com:443`
OS	RHEL 8
OHS version	OHS 12.2.x (EBS R12.2.13)
Certificate type	Self-signed (lab/dev)

Step 1

Locate Your OHS Instance & Wallet Directory

bash — find OHS paths

echo $INST_TOP

find $INST_TOP -name "cwallet.sso" 2>/dev/null
find $INST_TOP -name "wallet" -type d 2>/dev/null

Typical wallet location:

$INST_TOP/ora/10.1.3/Apache/Apache/conf/ssl.wlt/default/

Step 2

Verify orapki Is Available

EBS R12.2 OHS uses the Oracle Wallet — not openssl. The tool is orapki.

bash — verify orapki

export PATH=$ORACLE_HOME/bin:$PATH
which orapki
orapki version

Tip: If orapki is not found, source your EBS env file:
source $INST_TOP/ora/10.1.3/Apache/Apache/bin/envvar.sh

Step 3

Create the Oracle Wallet

bash — create wallet directory

mkdir -p $INST_TOP/ora/10.1.3/Apache/Apache/conf/ssl.wlt/default
cd $INST_TOP/ora/10.1.3/Apache/Apache/conf/ssl.wlt/default

bash — create wallet with auto-login

orapki wallet create \
  -wallet $INST_TOP/ora/10.1.3/Apache/Apache/conf/ssl.wlt/default \
  -pwd WalletPasswd123 \
  -auto_login

The -auto_login flag creates cwallet.sso — allows OHS to start without a password prompt on server restarts.

Step 4

Generate the Self-Signed Certificate

bash — add self-signed certificate (10-year validity)

orapki wallet add \
  -wallet $INST_TOP/ora/10.1.3/Apache/Apache/conf/ssl.wlt/default \
  -pwd WalletPasswd123 \
  -dn "CN=pc.app.com,OU=IT,O=YourOrg,L=City,ST=State,C=US" \
  -keysize 2048 \
  -self_signed \
  -validity 3650

Verify the certificate was added:

bash — display wallet contents

orapki wallet display \
  -wallet $INST_TOP/ora/10.1.3/Apache/Apache/conf/ssl.wlt/default \
  -pwd WalletPasswd123

expected output

User Certificates:
Subject: CN=pc.app.com,OU=IT,O=YourOrg,L=City,ST=State,C=US

Step 5

Configure ssl.conf for Port 443

bash — backup and edit ssl.conf

cp $INST_TOP/ora/10.1.3/Apache/Apache/conf/ssl.conf \
   $INST_TOP/ora/10.1.3/Apache/Apache/conf/ssl.conf.bkp_$(date +%Y%m%d)

vi $INST_TOP/ora/10.1.3/Apache/Apache/conf/ssl.conf

Set these key directives inside ssl.conf:

ssl.conf — key settings

Listen 443
SSLEngine on

<VirtualHost pc.app.com:443>
  ServerName pc.app.com:443
  SSLWallet "$INST_TOP/ora/10.1.3/Apache/Apache/conf/ssl.wlt/default"
  SSLProtocol TLSv1.2
  SSLCipherSuite HIGH:!aNULL:!MD5
</VirtualHost>

Always back up config files before editing. The $(date +%Y%m%d) suffix keeps backups organised by date.

Step 6

Update httpd.conf

httpd.conf — verify these lines exist

Listen 80
Listen 443
Include conf/ssl.conf

Step 7

Update EBS Context File & Run AutoConfig

This is the step most DBAs miss. The context file drives all generated EBS configuration. Skip this and your EBS URLs will still point to HTTP even after OHS is serving HTTPS.

context file — update these parameters

<s_webentryhost>pc.app.com</s_webentryhost>
<s_webentryurlport>443</s_webentryurlport>
<s_login_page>https://pc.app.com:443/OA_HTML/AppsLocalLogin.jsp</s_login_page>
<s_external_url>https://pc.app.com:443</s_external_url>

bash — run AutoConfig

cd $ADMIN_SCRIPTS_HOME
./adautocfg.sh

Step 8

Open Port 443 on RHEL 8 Firewall

bash — firewalld + SELinux

sudo firewall-cmd --permanent --add-port=443/tcp
sudo firewall-cmd --reload

# If SELinux is Enforcing
getenforce
sudo semanage port -a -t http_port_t -p tcp 443

Step 9

Bounce OHS & Test HTTPS

bash — restart and verify

$ADMIN_SCRIPTS_HOME/adapcctl.sh stop
$ADMIN_SCRIPTS_HOME/adapcctl.sh start
$ADMIN_SCRIPTS_HOME/adapcctl.sh status

# Test HTTPS (-k bypasses self-signed cert warning)
curl -k -I https://pc.app.com/OA_HTML/AppsLocalLogin.jsp

Expected result: HTTP/1.1 200 OK — HTTPS is live!

Final Verification Checklist

Check	Command	Expected
Wallet created	`ls ssl.wlt/default/`	✓ cwallet.sso + ewallet.p12
Certificate added	`orapki wallet display`	✓ CN=pc.app.com
OHS running	`adapcctl.sh status`	✓ Running
Port 443 open	`curl -k https://pc.app.com`	✓ HTTP 200 OK
AutoConfig done	`adautocfg.sh`	✓ Completed
Context file updated	`grep 443 $CONTEXT_FILE`	✓ Shows port 443

What's Next?

With HTTPS confirmed on https://pc.app.com, your environment is ready to receive Okta SAML assertions securely. In Part 2 of this series, we deploy the Oracle EBS Asserter on WebLogic — the middleware that translates Okta's SAML token into an EBS session.

Hit any issues? Drop a comment with the error message and I'll help troubleshoot.

Oracle EBS R12.2 HTTPS OHS Oracle Wallet orapki SSL Okta SSO RHEL 8

Written by

punitoracledba

Oracle DBA Specialist Lead | Oracle EBS DBA | AWS & AI Learner. Turning real-world database experience into practical knowledge. Follow the full EBS R12.2 + Okta SSO series at punitoracledba.blogspot.com