Setting Up a DMZ in Oracle E-Business Suite

What is a DMZ and Why Does EBS Need One?

A DMZ (Demilitarized Zone) is a secure buffer network positioned between the public internet and your internal corporate network. In Oracle E-Business Suite (EBS), implementing a DMZ allows you to safely expose selected web-facing services—such as iProcurement or supplier portals—to external users, without granting them direct access to your internal application or database servers.

Without a DMZ, enabling external access would require exposing the entire EBS environment to the internet, which significantly increases security risks. By introducing a DMZ:

• External users connect only to the web tier hosted in the DMZ, not to internal application servers.
• Critical components such as the database and concurrent managers remain securely protected behind internal firewalls.
• Even if the DMZ layer is compromised, the internal network and core systems remain isolated and secure.

Architecture Overview

The three-tier DMZ layout for Oracle EBS R12.2 looks like this:

 

Internet / External Users

→

DMZ Node (Web Tier)

→

Internal App + DB Tier

 

In this guide, the example nodes are:

•        Primary Apps Node: appsserver.test.com

•        DMZ Apps Node:     dmzserver.test.com

Prerequisites

Note :- Complete all three prerequisites on every node before starting the setup steps below. Skipping any of these is a common source of errors during cloning.

1.  Add host entries in all three /etc/hosts files — on the Primary DB node, Primary App node, and the DMZ node — so each node can resolve the others by hostname.

2.  Ensure the APPS and Oracle OS user and group IDs are identical across all nodes. Mismatched IDs cause permission errors when copying file systems.

3.  Enable password less SSH between the application tier nodes.

Step-by-Step Setup

STEP 1    Clean Up and Sync the File System (adop cycle)

Start on the Primary Apps Node. Run a complete adop cleanup cycle to ensure both file systems are in a consistent, clean state before cloning anything across to the DMZ.

$ . /u01/R12_2/APPFS/EBSapps.env run $ adop phase=prepare $ adop phase=finalize $ adop phase=cleanup cleanup_mode=full $ adop phase=fs_clone

 

Note :- Do not skip this step. A dirty or inconsistent file system is the most common reason adcfgclone fails during DMZ setup.

STEP 2    Switch Profile Hierarchy Type to SERVRESP

 

DMZ configuration in EBS R12.2 requires profile options to be managed at the Server-Response (SERVRESP) level. This allows different profile values — like different URLs — to be set per node, which is essential for routing internal vs. external traffic correctly.

 

Run the following SQL script on the Primary Node:

$ . /u01/R12_2/APPFS/EBSapps.env run $ sqlplus apps/'apps_password' \   @$FND_TOP/patch/115/sql/txkChangeProfH.sql SERVRESP

You will see confirmation messages for each profile option being updated, for example:

Profile APPS_WEB_AGENT hierarchy type changed to SERVRESP Profile APPS_FRAMEWORK_AGENT hierarchy type changed to SERVRESP Profile APPS_SERVLET_AGENT hierarchy type changed to SERVRESP Profile ICX_FORMS_LAUNCHER hierarchy type changed to SERVRESP

 

STEP 3    Run Preclone on Both File Systems

 

Run adpreclone.pl on both the run and patch file systems on the Primary Apps Node. This prepares the file system metadata for cloning.

Run File System:

$ . /u01/R12_2/APPFS/EBSapps.env run $ cd $ADMIN_SCRIPTS_HOME $ perl adpreclone.pl appsTier

 Patch File System:

$ . /u01/R12_2/APPFS/EBSapps.env patch $ cd $ADMIN_SCRIPTS_HOME $ perl adpreclone.pl appsTier

 

STEP 4    Back Up the Run File System and Copy It to the DMZ Node

 

Create a compressed archive of the run file system on the Primary App Node, then transfer it to the DMZ server using scp.

 On the Primary Node — create and copy the backup:

$ cd /u01/R12_2/APPFS/fs1 $ tar -cvzf appnode1backup.tar.gz EBSapps/ $ scp appsbackup.tar.gz \   applmgr@dmzserver.test.com:/u01/R12_2/APPFS/fs1

 On the DMZ Node — extract the backup:

$ cd /u01/R12_2/APPFS/fs1/ $ tar -xvf appsbackup.tar.gz

STEP 5    Run adcfgclone on the DMZ Node to Register It as a New Node

 

This is the core configuration step. First, start the Patch FS Admin Server on the Primary Node:

$ . /u01/R12_2/APPFS/EBSapps.env patch $ $INST_TOP/admin/scripts/adadminsrvctl.sh start forcepatchfs

 Then, on the DMZ Node, run adcfgclone:

$ cd /u01/R12_2/APPFS/fs1/EBSapps/comn/clone/bin $ perl adcfgclone.pl appsTier dualfs

 

When prompted, respond as follows:

•        Enter APPS password and WebLogic AdminServer password when asked.

•        Answer yes to 'Do you want to add a node?'

•        Confirm the hostname as: dmzserver

•        Accept default paths for all file system directories.

•        Keep same port values as the source system: y

•        When asked to start application services: answer n (do not start yet)

 

Note :- adcfgclone script will display all target directory paths for confirmation before proceeding. Verify the DMZ hostname and paths are correct before continuing.

STEP 6    Stop Primary Patch Admin Server, Run AutoConfig, and Start Services

 

On the Primary Node — stop the patch FS admin server:

$ . /u01/R12_2/APPFS/EBSapps.env patch $ $INST_TOP/admin/scripts/adadminsrvctl.sh stop

 On the DMZ Node — sync context file, run AutoConfig, start services:

$ . /u01/R12_2/APPFS/EBSapps.env run $ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh $ sh adstrtal.sh apps/apps

 Upload the patch context file from DMZ node:

$ . /u01/R12_2/APPFS/EBSapps.env patch $ $ADJVAPRG oracle.apps.ad.autoconfig.oam.CtxSynchronizer \    action=upload contextfile=$CONTEXT_FILE \   logfile=/tmp/patchctxupload.log

 On the Primary Node — sync context and run AutoConfig:

$ . /u01/R12_2/APPFS/EBSapps.env run $ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh

 

Finally, bounce the services on the Primary Node to complete the configuration sync.

STEP 7    Set Profile Options to Mark the DMZ Node as External

 

Log in to EBS using the internal URL as SYSADMIN. Navigate to System Administrator > Profile > System.

Node Trust Level:

Query for the profile option Node Trust Level. At the server level, set it to External for the DMZ server (dmzserver.test.com). Leave the site-level value as Normal.

 Responsibility Trust Level:

For each responsibility you want to expose externally, set the Responsibility Trust Level profile option to External at the responsibility level. Common externally accessible responsibilities include:

 

Product	Responsibility	Additional Profile
iSupplier Portal	iSupplier Portal	POS: External URL, POS: Internal URL
Oracle Sourcing	Sourcing Supplier	PON: External Applications Framework Agent
Oracle iProcurement	Self Registered Employee Default Responsibility	ICX_FORMS_LAUNCHER

 

Note:- Only expose responsibilities that are explicitly needed for external access. Exposing unnecessary responsibilities increases your attack surface.

Managing Services Across All Nodes

Once the DMZ is configured, use these commands from the Primary Node to manage services on all nodes simultaneously:

Start all nodes (including DMZ):

$ sh adstrtal.sh apps/apps_password -mode=allnodes

Stop all nodes:

$ sh adstpall.sh apps/apps_password -mode=allnodes

Firewall Ports to Open

Ensure the following ports are open between your DMZ and internal network zones:

Port	Protocol	Purpose
1571	TCP	Oracle DB listener (DMZ to DB tier)
22	TCP	SSH between app tier nodes
7051 / 7052	TCP	WebLogic Admin Server (HTTP/HTTPS)
8001 / 4443	TCP	OHS Web Entry Point (HTTP/HTTPS)
6701 / 6702	TCP	WebLogic Node Manager

Summary

You have now configured a DMZ for Oracle EBS R12.2. The DMZ node acts as a secure external web entry point. Your internal application and database tiers remain safely behind the firewall. External users access only the responsibilities you have explicitly marked as External via the Node Trust Level and Responsibility Trust Level profile options.

 

Key reference documents:

•        MOS KA1036 — Oracle E-Business Suite R12 Configuration in a DMZ

https://support.oracle.com/ic/builder/rt/customer_portal/live/webApps/customer-portal/?kmContentId=11172164

•        MOS KB503850 — External Access URLs Redirecting to Internal Servers

https://support.oracle.com/ic/builder/rt/customer_portal/live/webApps/customer-portal/?kmContentId=2135366

Caution: Your use of any information or materials on this Blog is entirely at your own risk. It is provided for educational purposes only.

Hybrid Read-Only Mode in Oracle Database 26ai

Oracle continues to evolve its multitenant architecture with features that improve flexibility, availability, and control. One of the most impactful enhancements in Oracle Database 26ai is Hybrid Read-Only Mode—a smart balance between operational continuity and administrative control.

What is Hybrid Read-Only Mode?

Hybrid Read-Only Mode allows a Pluggable Database (PDB) to operate in a unique state where:

• Local users are restricted to read-only access
• Common users (like SYS, SYSTEM, or other CDB-level users) still have read-write privileges

This means that while application users can continue querying data, administrative users can still perform critical changes in the background.

How It Works

In a traditional setup:

• A READ ONLY PDB blocks all write operations (including admin tasks)
• A READ WRITE PDB allows full access to everyone

With Hybrid Read-Only Mode:

• Oracle introduces a middle ground
• Local users - No data modifications allowed
• Common users - Full administrative control remains intact

This separation ensures better governance and operational safety.

Comparison of Modes

Let's get our hands dirty and see how this feature works in a practical lab scenario. We'll use a PDB named ORCLPDB for this demonstration.

First, connect as a privileged user to the root container. You'll need to close the PDB before you can reopen it in the new hybrid state.

Close the PDB:- 

Open the PDB in the new hybrid mode

Verify the State

Test the Access Levels

As a Local User

Hybrid Read-Only Mode in Oracle 26ai is a strategic enhancement that empowers administrators to maintain and patch databases with minimal disruption. It strikes a balance between operational safety and flexibility, making it a valuable tool in modern database management.

Oracle Document :- https://blogs.oracle.com/ace/how-to-use-the-new-hybrid-readonly-mode-for-pluggable-databases-in-oracle-database-23c-free-developer-release

Caution: Your use of any information or materials on this Blog is entirely at your own risk. It is provided for educational purposes only.

Creating a New Pluggable Database Using PDB$SEED

Oracle's Multitenant architecture allows a Container Database (CDB) to host multiple Pluggable Databases (PDBs), each acting as a fully independent Oracle database. One of the most common DBA tasks is provisioning a new PDB — and the fastest, cleanest way to do it is by cloning from PDB$SEED, the read-only template PDB that ships with every CDB.

In this guide, we walk through the entire process — from verifying prerequisites to opening and saving the PDB's state across restarts.

What is PDB$SEED?

PDB$SEED is a special, read-only template PDB that Oracle ships with every Container Database. It contains the minimal set of data files and dictionary objects required to seed a new Pluggable Database. When you create a PDB using the default method, Oracle copies PDB$SEED's data files to a new location and bootstraps a fresh PDB from them.

Key characteristics of PDB$SEED:

•        Always in READ ONLY mode — it can never be opened for writes

•        CON_ID = 2 in every CDB (CDB$ROOT = 1, user PDBs start from 3)

•        Patched automatically when you run datapatch on the CDB

•        Serves as the template for CREATE PLUGGABLE DATABASE ... FROM PDB$SEED (the default)

Note: Never attempt to open PDB$SEED in READ WRITE mode. Oracle will reject it, and attempting workarounds can corrupt your CDB.

Step 1 -Verify Prerequisites

Before issuing the CREATE command, confirm your session is connected to CDB$ROOT and that PDB$SEED is healthy.

1. Confirm you are in CDB$ROOT

    Show CON_NAME

2. Confirm this is a CDB

     SELECT NAME, CDB, CON_ID FROM V$DATABASE;

3. List all existing PDBs
        SELECT CON_ID, NAME, OPEN_MODE, RESTRICTED FROM V$PDBS ORDER  BY CON_ID;

4. Verify PDB$SEED is READ ONLY

    SELECT CON_ID, NAME, OPEN_MODE FROM   V$PDBS WHERE  NAME = 'PDB$SEED';

Note: If SHOW CON_NAME returns a PDB name rather than CDB$ROOT, switch back: ALTER SESSION SET CONTAINER = CDB$ROOT;

Step 2 - Create the Pluggable Database

CREATE PLUGGABLE DATABASE TESTPDB1 ADMIN USER TESTPDB1 IDENTIFIED BY "StrongPassword#1"  ROLES = (DBA)  DEFAULT TABLESPACE users DATAFILE '/u01/app/oracle/oradata/TEST/TESTPDB1/users01.dbf' SIZE 250M AUTOEXTEND ON NEXT 50M MAXSIZE UNLIMITED  FILE_NAME_CONVERT = ( '/u01/app/oracle/oradata/TEST/pdbseed/',    '/u01/app/oracle/oradata/TEST/TESTPDB1/');

Step 3 - Open the PDB

Newly created PDB is in MOUNTED state. You must open it explicitly before any connections can be made.

Open the PDB in READ WRITE mode

    ALTER PLUGGABLE DATABASE TESTPDB1 OPEN;

Verify the open mode

    SELECT CON_ID, NAME, OPEN_MODE, RESTRICTED FROM   V$PDBS WHERE  NAME = 'PDB_NAME';

Step 4 - Save the Open State

By default, PDBs return to MOUNTED state when the CDB is restarted. Use SAVE STATE to instruct Oracle to automatically re-open the PDB to its saved mode after every CDB startup.

Persist the open state across CDB restarts
 ALTER PLUGGABLE DATABASE TESTPDB1 SAVE STATE;

Confirm the saved state
    SELECT CON_NAME, STATE FROM   DBA_PDB_SAVED_STATES;

Note: SAVE STATE is the equivalent of adding the PDB to a startup trigger. Always run it after opening a new PDB in production.

Step 5 - Post-Creation Tasks

With the PDB open, switch into it and perform the initial housekeeping tasks before handing it off to the application team.

-- Switch into the new PDB

ALTER SESSION SET CONTAINER = TESTPDB1;

-- Confirm context

SHOW CON_NAME;

-- Review tablespaces

SELECT TABLESPACE_NAME, STATUS, CONTENTS FROM   DBA_TABLESPACES; 

-- Create the application user

CREATE USER app_user IDENTIFIED BY "AppPassword#1"

  DEFAULT TABLESPACE users

  TEMPORARY TABLESPACE temp

  QUOTA UNLIMITED ON users;

 GRANT CONNECT, RESOURCE TO app_user;

 -- Return to CDB root

ALTER SESSION SET CONTAINER = CDB$ROOT;

The table below covers the most frequent errors encountered during PDB creation and their resolutions.

Error Code	Cause	Fix
ORA-65012	PDB name already exists	Choose a different name or drop the existing PDB
ORA-17537	Wrong file path	Verify FILE_NAME_CONVERT paths exist on the OS
ORA-65016	FILE_NAME_CONVERT required	Set DB_CREATE_FILE_DEST or specify FILE_NAME_CONVERT
ORA-01109	PDB not open	Run ALTER PLUGGABLE DATABASE pdb_name OPEN
ORA-65040	Not in CDB root	Run ALTER SESSION SET CONTAINER = CDB$ROOT first

Key Takeaways

• PDB$SEED is the read-only seed template — never open it in READ WRITE mode
• Always run from CDB$ROOT with SYSDBA privileges when creating PDBs
• FILE_NAME_CONVERT is mandatory unless OMF (DB_CREATE_FILE_DEST) is configured
• Newly created PDBs are in MOUNTED state — open them explicitly with ALTER PLUGGABLE DATABASE ... OPEN
• Always run SAVE STATE in production so PDBs survive CDB restarts automatically
• Each PDB shares the CDB's redo, undo, and TEMP — but owns its own data files.

Caution: Your use of any information or materials on this Blog is entirely at your own risk. It is provided for educational purposes only.