Oracle EBS Patching Issue: Prepare Phase Stuck Due to job_queue_processes = 0

Introduction

Online patching in Oracle E-Business Suite (EBS) R12.2 relies on multiple background processes to execute successfully. One of the commonly overlooked parameters that can impact patching is job_queue_processes.

This blog explains a real-time issue where the adop Prepare phase was stuck indefinitely, the root cause, and how it was resolved.

---

Environment Details

· Application: Oracle E-Business Suite R12.2

· Patching Method: adop (Online Patching)

· Phase: Prepare

· Database: Oracle 19c

---

Issue Description

During the patching cycle, the Prepare phase was observed to be stuck and not progressing further.

· adop logs did not show any explicit errors

· The process remained active but idle

· No visible failure, but no progress

 This made troubleshooting difficult as the issue was not immediately evident from logs.

---

Understanding the Prepare Phase

The Prepare phase performs several critical operations:

· Environment validation

· Dependency checks

· Data consistency verification

· Internal job execution

These operations rely on Oracle background job queue processes (Jnnn) to execute tasks asynchronously.

---

Root Cause Analysis (RCA)

The issue was traced to the database parameter:

SQL> sho parameter job;

NAME TYPE VALUE

---

job_queue_processes integer 0
max_datapump_jobs_per_pdb string 100
max_datapump_parallel_per_job string 50

 The parameter job_queue_processes was set to 0

Impact of Setting job_queue_processes = 0

When this parameter is set to 0:

· All background job queue processes are disabled

· DBMS jobs do not execute

· Internal EBS patching jobs cannot run

· Prepare / Apply phases may hang indefinitely

In short:
No background workers = No progress in patching

---

Solution

Step 1: Enable Job Queue Processes

Run the following command:

SQL> ALTER SYSTEM SET job_queue_processes = 10;

System altered.

---

Step 2: Verify Parameter Value

SQL> sho parameter job;

NAME TYPE VALUE

---

job_queue_processes integer 10
max_datapump_jobs_per_pdb string 100
max_datapump_parallel_per_job string 50

 Parameter is now enabled

---

Step 3: Resume Patching

· Re-run the Prepare phase

· Monitor adop logs

 The Prepare phase completed successfully after enabling job queue processes

---

Key Takeaways

· job_queue_processes is critical for EBS patching

· Setting it to 0 disables all background jobs

· Prepare phase depends heavily on DB job execution

· Lack of errors in logs does not mean system is healthy

---

Best Practices

· Always verify critical database parameters before patching

· Maintain a baseline configuration for EBS environments

· Monitor background job execution during adop phases

· Avoid setting job_queue_processes to 0 in production

· Document parameter changes for audit and troubleshooting

---

Conclusion

Even a single database parameter misconfiguration can halt the entire Oracle EBS patching cycle. The job_queue_processes parameter plays a crucial role in enabling background job execution, which is essential for successful completion of adop phases.

Ensuring proper configuration of such parameters helps avoid unnecessary downtime and ensures smooth patching operatio

 

 

Oracle Base vs Oracle Home: Understanding the Core Difference

When working with Oracle databases, two directory concepts often confuse beginners and even experienced DBAs at times: Oracle Base and Oracle Home. Though they sound similar, they serve very different purposes in an Oracle installation.
This blog breaks it down in a simple, practical way—exactly what the image illustrates.

What is Oracle Base?

Oracle Base is the top-level directory under which all Oracle software–related files are organized for a user.

Think of Oracle Base as the parent folder that holds:

• Oracle inventory

• Diagnostic files

• Administrative files

• One or more Oracle Homes

Key Characteristics of Oracle Base

• Common across multiple Oracle installations

• Defined once per Oracle user

• Helps standardize directory structure

• Makes administration and maintenance easier

Common Contents of Oracle Base

• oraInst.loc – Oracle Inventory location file

• orainstRoot.sh – Inventory installation script

• oraenv / coraenv – Environment setup scripts

• admin/ – Administrative files

• diag/ – Diagnostic and trace files

• product/ – Contains one or more Oracle Home directories

Tools Available

• OPatch – Oracle patching utility

• runInstaller – Oracle Universal Installer

• In short: Oracle Base is about organization and management.

---

What is Oracle Home?

Oracle Home is the directory where a specific Oracle product is installed.

Each Oracle Home contains:

• Executables

• Libraries

• Network configuration files

• Database binaries

You can have multiple Oracle Homes under a single Oracle Base (for example, different database versions).

Common Contents of Oracle Home

• bin/ – Executables (sqlplus, rman, expdp)

• lib/ – Oracle libraries

• network/ – tnsnames.ora, listener.ora

• dbs/ – init.ora, spfile.ora

• rdbms/ – Core RDBMS files

• sqlplus/ – SQL*Plus related files

• netca/ – Network Configuration Assistant

In short: Oracle Home is about running the database software.

---

Oracle Base vs Oracle Home – Key Differences

Aspect	Oracle Base	Oracle Home
Purpose	Parent directory for Oracle software	Product-specific installation
Scope	Common for all Oracle products	Specific to one Oracle product/version
Count	One per Oracle user	Multiple allowed
Contains	Inventory, diagnostics, admin	Binaries, libs, config
Example	/u01/app/oracle	/u01/app/oracle/product/19c/dbhome_1

---

Why This Separation Matters

Oracle introduced this separation to:

• Support multiple Oracle versions cleanly

• Simplify patching and upgrades

• Improve file management and troubleshooting

• Enable better standardization across environments

For DBAs, understanding this distinction helps avoid mistakes during:

• Patching

• Cloning

• Upgrades

• Environment configuration

---

Final Thoughts

If you remember just one thing:

Oracle Base is the container. Oracle Home is the engine.

Both work together, but each has a clear responsibility. Once you understand this structure, navigating Oracle installations becomes much easier—and much safer.

AutoConfig Failure Due to Custom Template Version Mismatch in Oracle E-Business Suite R12.2

Introduction

During online patching in Oracle E-Business Suite (R12.2), the AutoConfig phase plays a criticalrole in validating and applying configuration changes across the application tier.This blog explains a real-time issue encountered during an adop apply cycle, where AutoConfig failed due to a custom template version mismatch, along with the root cause and resolution steps.

---

Environment Details

· Application: Oracle E-Business Suite R12.2

· Patching Method: adop (Online Patching)

· Phase: apply

· Node: Application Tier

---

Issue Summary

During the adop apply phase, the patching process failed while executing AutoConfig.

Observed Errors

[UNEXPECTED] Error occurred running "sh .../adconfig.sh ..."

[UNEXPECTED] Error occurred while executing AutoConfig on current node.

[UNEXPECTED] Apply phase has failed.

---

Error Details from AutoConfig Log

The AutoConfig log clearly indicated a template version conflict:

[ VERSION CONFLICTS INFORMATION ]

Template shipped by Oracle :

.../template/oacore_web_xml_FMW.tmp (version: 120.17.12020000.33)

Custom template :

.../template/custom/oacore_web_xml_FMW.tmp (version: 120.17.12020000.31)

Please resolve the differences between the two templates or refer to the Oracle E-Business Suite Setup Guide.

---

Understanding the Issue

Oracle EBS allows DBAs to maintain custom AutoConfig templates under:

template/custom/

During patching:

· Oracle delivers updated standard templates

· AutoConfig validates version consistency

· Any mismatch between standard and custom templates leads to failure AutoConfig enforces strict version control to prevent configuration inconsistencies.

---

Root Cause Analysis (RCA)

The failure occurred due to the following:

· A custom template file oacore_web_xml_FMW.tmp existed in the custom directory

· The custom version (120.17.12020000.31) was outdated

· Oracle patch delivered a newer version (120.17.12020000.33)

· AutoConfig detected the mismatch and terminated execution

 In short:

Outdated custom template caused AutoConfig to fail during validation

---

Resolution Steps

1. Backup Existing Templates

cp -pr template template_ori_171125

---

2. Copy Latest Oracle Template to Custom Directory

cp /u01/oracle/PRETEST/fs2/EBSapps/appl/fnd/12.0.0/admin/template/oacore_web_xml_FMW.tmp

/u01/oracle/PRETEST/fs2/EBSapps/appl/fnd/12.0.0/admin/template/custom/oacore_web_xml_FMW.tmp

---

3. Verify Template Version

ls -ltr oacore_web_xml_FMW.tmp*

 Ensure both files reflect the same version (120.17.12020000.33)

---

4. Resume Patching Cycle

· Restart the patch session

· Continue with adop apply AutoConfig executed successfully after version alignment

---

5. AutoConfig Execution

 No manual AutoConfig run required adop internally completed AutoConfig

---

Post-Fix Outcome

· Patch applied successfully

· AutoConfig completed without errors

· Template versions synchronized

· Application environment stabilized

---

Key Takeaways

· AutoConfig strictly validates template versions

· Custom templates must always match Oracle-delivered versions

· Even minor version differences can break patching

· Always review custom directory during patching cycles

---

Best Practices

· Maintain version control for all custom templates

· Compare standard vs custom templates after every patch

· Document all template customizations

· Backup template directories before patching

· Periodically clean unused custom templates

---

Conclusion

Custom template management is a critical aspect of maintaining Oracle E-Business Suite environments. Version mismatches, even minor ones, can disrupt AutoConfig and halt patching activities.By ensuring proper alignment between standard and custom templates, DBAs can avoid unexpected failures and ensure smooth patching cycles.

 

How to Create a New PDB with TDE Enabled and Encrypted Tablespace in Oracle 19cIntroduction

In modern Oracle database environments, securing sensitive data at rest is a critical requirement. Transparent Data Encryption (TDE) ensures that data stored in tablespaces is automatically encrypted without requiring application changes.

This blog provides a practical, step-by-step guide to:

· Create a new Pluggable Database (PDB)

· Enable TDE inside the PDB

· Create and activate a master encryption key

· Verify wallet status

· Create an encrypted tablespace

This guide is useful for DBAs working in Oracle 19c multitenant environments.

---

Environment

· Oracle Version: 19c

· Architecture: Multitenant (CDB/PDB)

· Encryption: TDE

---

1. Connect as SYSDBA

SQL> sqlplus / as sysdba

Verify container:

SQL> SHOW CON_NAME;

Expected:

CDB$ROOT

 Ensure you are in the root container.

---

2. Create a New PDB

SQL> CREATE PLUGGABLE DATABASE DFMS
ADMIN USER admin IDENTIFIED BY "SU5d4e2VG#Q";

Open the PDB:

SQL> ALTER PLUGGABLE DATABASE DFMS OPEN READ WRITE;

Save state:

SQL> ALTER PLUGGABLE DATABASE DFMS SAVE STATE;

Switch to PDB:

SQL> ALTER SESSION SET CONTAINER = DFMS;

---

3. Check TDE Wallet Status

SQL> SELECT * FROM v$encryption_wallet;

Expected status:

OPEN_NO_MASTER_KEY

 Wallet is open but no master key exists.

---

4. Create TDE Master Encryption Key

SQL> ADMINISTER KEY MANAGEMENT CREATE ENCRYPTION KEY
USING TAG 'DFMS_REKEY'
FORCE KEYSTORE IDENTIFIED BY "SU5d4e2V-G_Q"
WITH BACKUP USING 'DFMS_REKEY';

Verify:

SQL> SELECT key_id FROM v$encryption_keys WHERE tag='DFMS_REKEY';

 Valid key_id confirms creation.

---

5. Activate the Encryption Key

SQL> ADMINISTER KEY MANAGEMENT USE ENCRYPTION KEY
'Ad+0E2RijU+iv9Xur6AYQWgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
FORCE KEYSTORE IDENTIFIED BY "SU5d4e2V-G_Q"
WITH BACKUP;

 Key is now active in the PDB.

---

6. Verify Wallet Again

SQL> SELECT * FROM v$encryption_wallet;

 Wallet remains OPEN/AUTOLOGIN and key is active.

---

7. Create Encrypted Tablespace

SQL> CREATE TABLESPACE FMS
DATAFILE '+DATA' SIZE 1G
AUTOEXTEND ON NEXT 128M MAXSIZE 30G;

 Tablespace created successfully with encryption enabled.

---

Important Notes

· TDE must be configured at CDB level

· Always backup keystore after key creation

· Ensure wallet is open before operations

· Use strong passwords

---

Common Issues

Wallet Not Open

· Check sqlnet.ora

· Verify wallet location

Key Not Found

· Verify tag name

· Ensure correct PDB

---

Best Practices

· Backup wallet regularly

· Use AUTOLOGIN wallet

· Monitor encryption status

· Avoid hardcoding passwords

· Follow key rotation policy

---

Key Takeaways

· TDE secures data at rest

· Each PDB needs its own key

· Wallet validation is critical

· Encrypted tablespaces ensure data protection

---

Conclusion

Implementing TDE in a multitenant Oracle environment ensures strong data security with minimal impact on applications. By following this approach, DBAs can securely deploy encrypted PDBs and protect sensitive data effectively.