Automating Password Resets with a Shell Script

In non-production environments (like Dev or Test), manually typing passwords into interactive prompts is inefficient. You can automate AFPASSWD using a simple wrapper script that pipes the inputs.

Prepare automation script as name  reset_ebs_pwd.sh using below script.

--------------------------------------------------------------------------------------------------------------------

   #!/bin/bash

# ====================================================================

# Script: reset_ebs_pwd.sh

# Purpose: Automate APPS & SYSADMIN password reset in EBS R12.2

# ====================================================================

# Usage check

if [ "$#" -ne 3 ]; then

    echo "Usage: $0 <CURRENT_APPS_PWD> <NEW_APPS_PWD> <NEW_SYSADMIN_PWD>"

    exit 1

fi

CURR_APPS=$1

NEW_APPS=$2

NEW_SYS=$3

echo "Step 1: Resetting APPS Schema Password..."

# We use printf to feed the current password, then the new password twice

printf "${CURR_APPS}\n${NEW_APPS}\n${NEW_APPS}" | AFPASSWD -s APPS

if [ $? -eq 0 ]; then

    echo "SUCCESS: APPS password updated."

else

    echo "ERROR: Failed to update APPS password."

    exit 1

fi

echo "Step 2: Resetting SYSADMIN User Password..."

# SYSADMIN reset requires the APPS password first

printf "${NEW_APPS}\n${NEW_SYS}\n${NEW_SYS}" | AFPASSWD -f SYSADMIN

echo "Done! Please test login via Browser and SQL*Plus."

=======================================================================

How to Use This in Your Post

1. Safety First: Add a "Pro-Tip" warning that automation should only be used in Non-Prod environments to avoid exposing sensitive passwords in process logs or command history.
   
   
2. Permissions: run chmod +x reset_ebs_pwd.sh before executing.
   
   
3. Command History: Advise users to run history -c after using the script to clear the passwords from the terminal history.

How to Reset APPS and SYSADMIN Passwords in R12.2

Resetting the APPS and SYSADMIN passwords is a fundamental task for any Oracle Apps DBA, but in EBS R12.2, doing it incorrectly can break your environment's connection to the database or the WLS (WebLogic Server).

In this guide, we will use the recommended AFPASSWD utility, which has replaced the older FNDCPASS for many R12.2 tasks.

 Prerequisites

1. Access to the Application Tier as the applmgr user.
2. The run edition environment file must be sourced.
3. Access to the Database Tier as the oracle user (to verify connectivity).
   
   

Step 1: Source the Environment

Before running any utility, ensure you are in the Run Edition environment.

 $ . /u01/install/APPS/EBSapps.env run

Step 2: Resetting the APPS Password

Oracle recommends using the AFPASSWD utility in R12.2. Unlike the old days, this utility handles the integration with the WebLogic Domain automatically.

 $ AFPASSWD -s APPS

Execution Steps:

1. Enter the current APPS password.
2. Enter the new password for the APPS user.
3. Verify the new password.
   
   

Note: The utility will update the password in the database and automatically synchronize it with the WLS Data sources.

 Step 3: Resetting the SYSADMIN Password

The SYSADMIN user is an application-level user (FND_USER). You can change this via the "Define User" form in the application, but if you are locked out, use the command line:

 $ AFPASSWD -f SYSADMIN

Execution Steps:

1. Enter the APPS password.
2. Enter the new password for SYSADMIN.
   
   

Verify the password.

Step 4: Verify the Changes

After resetting, verify that you can still connect to the database from the application tier using the new password:

$ sqlplus apps/<new_password>

Also, log in to the Oracle E-Business Suite Login Page using the SYSADMIN account and the new password to ensure the application listener and OAM are functioning.

Why use AFPASSWD over FNDCPASS?

• AFPASSWD is more secure (it doesn't show passwords in the process list).
• It is specifically designed to handle the R12.2 Dual File System and WebLogic integration more cleanly.
  
  

 Troubleshooting Common Issues

• Account Locked: If you try to log in with the old password too many times, the APPS schema might get locked in the DB. Have your System DBA run: ALTER USER APPS ACCOUNT UNLOCK;.
  
  
• WLS Connection Pool Errors: If the application fails to start after a password change, run the adcfgclone.pl or adchkcfg.sh to ensure the context files are synced.

Step by Step Guide to Add Secondy Node in Oracle EBS R12.2

🔷 Introduction

Step by Step Guide to Add Secondy Node in Oracle EBS R12.2 | Oracle E-Business Suite (EBS) R12.2 supports a multi-node architecture that allows organizations to scale application tier services such as web, forms, and concurrent processing. Adding a new node is a common requirement for load balancing, performance improvement, or environment expansion.

This guide provides a complete, accurate, and production-ready procedure to add and configure a new application tier node in Oracle EBS R12.2 using Rapid Clone.

🔷 Prerequisites

Before proceeding, ensure the following requirements are met:

• ✅ Oracle EBS R12.2 environment is up and running
• ✅ Same OS version and patches installed on target node
• ✅ Application user (applmgr) and database user (oracle) exist
• ✅ Change shared_file_system to true on run and patch file system context file
• ✅ Passwordless SSH configured between source and target nodes
• ✅ Shared Application Tier File System (via NFS or shared storage)
• ✅ Adequate disk space and memory on the new node
• ✅ Source environment context file backup taken

🔷 Architecture Overview (R12.2)

Oracle EBS R12.2 uses a dual file system:

• fs1 (Run File System)
• fs2 (Patch File System)

Both file systems must be properly configured on the new node.

🔷 Step 1: Prepare the Target Node

On the new node:

• Install required OS packages
• Create users and groups:

groupadd dba

useradd -g dba applmgr

• Create directory structure identical to the source system

Change shared_file_system to true on run and patch file system context file

$ echo $CONTEXT_FILE

$ cat $CONTEXT_FILE|grep shared_file_system

🔷 Step 2: Configure Shared File System (NFS)

On Source Node:

Edit exports file:

vi /etc/exports

 

Add:

/u01/appl_top 192.168.1.20(rw,sync,no_root_squash)

 

Apply changes:

exportfs -ra

systemctl restart nfs-server

On Target Node:

Mount the shared file system:

mount -t nfs source_host:/u01/appl_top /u01/appl_top

Verify mount:

 

df -h

🔷 Step 3: Copy Required Files

Ensure the following are available on the target node:

• Application tier file system
• Context files
• Rapid Clone utility

🔷 Step 4: Run Rapid Clone (Important Step)

Start weblogic admin server on run and patch file system.

Run fs.

$sh adadminsrvctl.sh start

Patch fs.

$sh adadminsrvctl.sh start forcepatchfs

Then run adpreclone on run and patch file system.

Navigate to clone directory:

cd $COMMON_TOP/clone/bin

Run the cloning utility:

perl adclonectx.pl addnode contextfile=/u01/app/run/UAT_s2uatebs01.xml pairsfile=/u01/app/run/UAT_s2uatebs01_run.txt dualfs=yes 

 Note:- Use primary node context file and correct pairsfile.

🔹 Provide Required Inputs:

• Target hostname
• Domain name
• Base directory path
• Port pool (choose unique port pool)

🔷 Step 5: Run AutoConfig

After cloning completes, run AutoConfig:

cd $ADMIN_SCRIPTS_HOME

./adautocfg.sh

✅ This step:

• Creates configuration files
• Registers node automatically
• Synchronizes system settings

🔷 Step 6: Verify Node Registration

Connect to database and run:

SQL>SELECT node_name, support_cp, support_web, support_forms FROM fnd_nodes;

Ensure the new node is listed.

🔷 Step 7: Start Application Services

Start services on new node:

cd $ADMIN_SCRIPTS_HOME

./adstrtal.sh apps/apps

✅ Verify Services:

• Apache → Running ✅
• WebLogic → Running ✅
• Forms Services → Running ✅

🔷 Best Practices

• ✅ Always take full backup before changes
• ✅ Ensure time synchronization between nodes
• ✅ Maintain consistent patch levels
• ✅ Regularly monitor logs and services
• ✅ Validate NFS performance for production environments

🔷 FAQ

✅ Q1: Is downtime required to add a new node?

👉 Minimal downtime may be required depending on environment setup.

---

✅ Q2: Can I add multiple nodes in R12.2?

👉 Yes, Oracle EBS fully supports multi-node architecture.

---

✅ Q3: What is the role of AutoConfig?

👉 AutoConfig synchronizes configuration and registers the node automatically.

---

✅ Q4: Is NFS mandatory?

👉 Yes, for shared application tier file system in most setups.

🔚 Conclusion

Adding a new node in Oracle EBS R12.2 is a straightforward process when using the correct tools and approach. By leveraging Rapid Clone and AutoConfig, you can efficiently scale your environment while maintaining system consistency and stability.

Configuring iSupplier Node in Oracle R12.2 | Step-by-Step Guide

When exposing iSupplier to external node, Oracle recommends configuring a dedicated DMZ web node. This ensures only the web tier is accessible externally, while the application and database tiers remain secure inside the firewall.

---

Here will use two nodes for internal and external.

Internal Server: - 192.168.11.10

External Server: - 192.168.11.20

Step 2: Configuring NFS for Oracle Applications (iSupplier Node Setup)

Before proceeding with the configuration, ensure that both NFS client and NFS server packages are installed on the respective systems.

Step 1: Install NFS Packages on External node

If NFS is not installed, install it using the following command:

yum install -y nfs-utils

Step 2: Verify NFS Service Status

Check the status of the NFS service:

systemctl status nfs-server

If the service is not running, start and enable it:

systemctl start nfs-server

systemctl enable nfs-server

Step 3: Configure NFS Export on Source Server

Edit the exports file on the source server:

vi /etc/exports

Add the Application tier file system path as shown below:

/oracle/apps/ 192.168.11.10 (rw,sync,no_root_squash)

Explanation:

• rw → Read and write permissions
• sync → Synchronous writing for data integrity
• no_root_squash → Allows root access from client (use cautiously in secure environments)

---

Step 4: Restart NFS Service

Apply the changes by restarting the NFS service:

systemctl restart nfs-server

Also reload exports:

exportfs -ra

Step 2 : Run preclone on the existing node(source node)

$ cd $INST_TOP/admin/scripts

$ perl adpreclone.pl appsTier

Step 3 : Clone Context File

Run the adclonectx.pl script to generate a new context file for the external node:

perl $COMMON_TOP/clone/bin/adclonectx.pl

You’ll be prompted for details such as hostname, SID, domain, base directory, ORACLE_HOME paths, APPL_TOP, COMMON_TOP, and instance home. Example:

• Target Hostname: abctest
• Target SID: UAT
• Target Domain: abc-test.com
• Base Directory: /data01/GSTUAT_8026
• APPL_TOP: /data01/GSTUAT_8026/apps/apps_st/appl
• COMMON_TOP: /data01/GSTUAT_8026/apps/apps_st/comn
• Instance Home: /data01/GSTUAT_8026/apps/inst

At the end, a new context file (e.g., UAT_abctest.xml) will be created.

During context file creation, enable only the services required for iSupplier node:

• Root Service: enabled
• Web Entry Point Services: enabled
• Web Application Services: enabled
• Batch Processing Services: disabled
• Other Services: disabled

This ensures the external node runs only web-related services.

Step 4: Set Port Pool

Choose a unique port pool (e.g., 26) to avoid conflicts with internal nodes. Port details will be logged in portpool.lst.

$perl $AD_TOP/bin/adconfig.pl  contextfile=/oracle/PROD/inst/apps/PROD_isupplier/External.xml

Step 5 : Run the txkChangeProfH.sql under $FND_TOP/patch/115/sql using apps user.

SQL>@txkChangeProfH.sql SERVRESP

After adding and generating the new context file on external node, run AutoConfig on the internal node initially, and then execute AutoConfig on the external node. This sequence is required to synchronize the configuration and ensure that the new node is correctly populated in the FND_NODES table.

 Step 6: Run AutoConfig

Once the context file is ready, run AutoConfig on the external node:

$ADMIN_SCRIPTS_HOME/adautocfg.sh

This applies the configuration and sets up the external web tier.

Step 6: Validate Setup

• Check the CloneContext log for errors:
  /data01/GSTUAT_8026/apps/inst/apps/UAT_aceapps/admin/scripts/CloneContext_0804113428.log
  
  
• Verify that only web services are running on the external node.
• Test iSupplier login externally via the DMZ hostname.
  
  

Step 7 : Set below profile as per configuration.

POS: External URL

POS: Internal URL

Query for %NODE%TRUST%. You will see a profile option named 'Node Trust Level'

Set the value of this profile option to External at the server level to external node only

Once set the profile option . Hope you will able to login in External URL accordingly...

 

 Best Practices

• Always configure SSL for secure supplier communication.
• Keep database and application tiers internal.
• Regularly monitor AutoConfig logs and Apache/OHS logs.
• Follow Oracle’s DMZ best practices (DMZ configuration guide).

---

This process ensures that your iSupplier portal is securely accessible to external suppliers while protecting your internal EBS environment.

Would you like me to extend this into a full-length blog post with troubleshooting tips (e.g., handling login redirection or SSL handshake issues), so it’s ready for publishing?

 

How to Duplicate an Oracle Database from Active Instance using RMAN

Oracle DBA Essentials: Cloning with RMAN Active Database Duplication

In a fast-paced database environment, DBAs are frequently asked to "refresh" a test environment or "clone" a production instance for troubleshooting. While traditional backup-and-restore methods work, the RMAN Active Database Duplication is often the superior choice because it streams data directly from the source to the destination over the network, bypassing the need for intermediate backup files.

This guide outlines the professional workflow for performing an Active Duplicate.

---

1. Pre-Requisites & Environment Setup

Before executing any commands, verify that your environment meets these professional standards:

• Source Mode: The source database must be in ARCHIVELOG mode.
• Password Files: The SYS password must be identical on both the source and auxiliary servers.
• Network: TNS aliases for both databases must be configured on both servers.
• Static Listener: The auxiliary (destination) database must have a static entry in listener.ora so RMAN can connect while it is in a NOMOUNT state.

---

2. Step-by-Step Execution

Step A: Prepare the Auxiliary PFILE

On the destination server, create a temporary initialization file (e.g., init_temp.ora). You only need the bare essentials to start the instance.

SQL

db_name='STDBY'

memory_target=2G

control_files='/u01/app/oracle/oradata/STDBY/control01.ctl'

db_file_name_convert=('/u01/app/oracle/oradata/PROD/','/u01/app/oracle/oradata/STDBY/')

log_file_name_convert=('/u01/app/oracle/oradata/PROD/','/u01/app/oracle/oradata/STDBY/')

Step B: Start the Destination in NOMOUNT

The destination instance must be started but not yet associated with a database.

Bash

export ORACLE_SID=STDBY

sqlplus / as sysdba

SQL> startup nomount pfile='/tmp/init_temp.ora';

Step C: Verify Network Connectivity

From the destination server, ensure you can reach the source via SQL*Plus:

Bash

sqlplus sys/your_password@PROD_ALIAS as sysdba

Step D: The Duplication Command

Now, initiate the RMAN session from the destination server. We will connect to the source (TARGET) and the new instance (AUXILIARY).

Bash

rman target sys/password@PROD_ALIAS auxiliary sys/password@STDBY_ALIAS

Once inside the RMAN prompt, execute the duplication block. Using multiple channels (parallelism) is a best practice for production-sized databases to reduce transfer time:

SQL

RUN

{

  # Allocate multiple channels for parallel network transfer

  ALLOCATE CHANNEL p1 DEVICE TYPE DISK;

  ALLOCATE CHANNEL p2 DEVICE TYPE DISK;

  ALLOCATE AUXILIARY CHANNEL a1 DEVICE TYPE DISK;

  ALLOCATE AUXILIARY CHANNEL a2 DEVICE TYPE DISK;

 

  DUPLICATE TARGET DATABASE TO STDBY

    FROM ACTIVE DATABASE

    NOFILENAMECHECK;

}

---

3. What Happens Under the Hood?

When you run this command, RMAN automates several complex tasks:

1. Communications: It establishes a heartbeat between the source and auxiliary instances.
2. Transfer: It copies datafiles directly over the network.
3. Metadata: It creates a new control file for the destination database.
4. Recovery: It pulls the necessary archived logs from the source to make the destination database consistent.
5. Finalization: It opens the new database with the RESETLOGS command and creates an SPFILE from your temporary PFILE.

---

4. Troubleshooting Common Issues

• ORA-12154 (TNS:could not resolve service name): Double-check your tnsnames.ora for typos and ensure the listener is running.
• ORA-01017 (Invalid username/password): Ensure the orapw<SID> file on the destination was copied from the source or has the exact same SYS password.
• Network Timeouts: For very large databases, ensure your network bandwidth can handle the sustained transfer to avoid "TNS: Packet write error."

Conclusion

The DUPLICATE ... FROM ACTIVE DATABASE command is a powerful tool in a DBA's arsenal. It simplifies the cloning process, reduces manual errors, and saves disk space on the source server.

Whether you are building a Data Guard standby or simply refreshing a dev environment, mastering this workflow is essential for modern Oracle administration.

  

✅ Example FAQs

Q1. What is RMAN active duplication?
👉 It allows cloning a database directly from a running source database without backup.

Q2. Does RMAN duplicate require backup?
👉 No, active duplication copies data over the network.

Q3. What is auxiliary instance in RMAN?
👉 It is the target database instance used for duplication.