Step by Step Oracle EBS 12.2 Cloning DB & APPS

 Below is a technical, step-by-step blog article suitable for an Oracle E-Business Suite DBA, Oracle Apps DBA, or enterprise infrastructure team. It covers cloning both the database tier and application tier using Oracle E-Business Suite Release 12.2 Rapid Clone.

The article assumes a traditional on-premises or virtual-machine deployment with a source production environment and a separate target environment (DEV, TEST, UAT, or PRE-PROD). It includes commands, directory structures, validation checks, and important post-cloning activities.

Oracle E-Business Suite 12.2: Step-by-Step Database and Application Tier Cloning Using Rapid Clone

Oracle E-Business Suite (EBS) Release 12.2 is widely used by organizations to manage enterprise business processes, including Financials, Procurement, Supply Chain Management, Human Resources, and Order Management.

In a typical EBS implementation, administrators regularly need to create copies of production environments for development, testing, patching, troubleshooting, and user acceptance testing.

This process is known as Oracle EBS cloning.

Oracle EBS 12.2 uses the Rapid Clone utility to prepare, copy, and configure both the database tier and application tier on a new target environment.

Unlike a simple file-system copy, Rapid Clone updates the configuration files, context files, Oracle Homes, application services, WebLogic components, and database connectivity information to match the target environment.

This article explains the end-to-end cloning process, covering:

1. Source environment preparation.
2. Database tier pre-cloning.
3. Database backup and restoration to the target server.
4. Database tier configuration using Rapid Clone.
5. Application tier pre-cloning.
6. Application file-system transfer.
7. Application tier configuration using Rapid Clone.
8. Post-cloning configuration and validation.

1. Understand the Oracle EBS 12.2 architecture

Before starting the cloning process, it is important to understand the two major components of an Oracle EBS 12.2 environment.

1.1 Database tier

The database tier contains the Oracle Database that stores all EBS application data, including:

• EBS application schemas.
• Business transaction data.
• Application configuration.
• Concurrent processing information.
• Workflow information.
• Database objects and PL/SQL packages.

Typical database directory structure:

text

/u01/oracle/

/u01/oracle/product/19c/dbhome_1

/u01/oracle/product/19c/dbhome_1/appsutil

/u01/oracle/oradata/PROD/

/u01/oracle/fast_recovery_area/

The actual directory structure depends on your database version and installation.

1.2 Application tier

The application tier contains the EBS application components.

Oracle EBS 12.2 uses an online patching architecture with two application file systems:

• RUN file system: Used by the running application.
• PATCH file system: Used during online patching operations.

The application tier also includes:

• APPL_TOP.
• COMMON_TOP.
• Oracle Fusion Middleware (FMW) components.
• Oracle WebLogic Server.
• Oracle HTTP Server.
• Forms and Reports components.
• Concurrent Processing services.
• Application technology stack components.

A typical application directory structure looks like this:

text

/u01/oracle/PROD/fs1/

/u01/oracle/PROD/fs2/

/u01/oracle/PROD/fs_ne/

/u01/oracle/PROD/fs1/EBSapps/appl/

/u01/oracle/PROD/fs2/EBSapps/appl/

The precise locations and directory names depend on the installation.

1.3 Example source and target environments

For this demonstration, we will use the following example configuration.

Component	Source environment	Target environment
Environment	Production	TEST
Database hostname	prod-db.example.com	test-db.example.com
Application hostname	prod-app.example.com	test-app.example.com
Database SID	PROD	TEST
Database port	1521	1524
EBS application user	applmgr	applmgr
Database OS user	oracle	oracle
Application base	/u01/oracle/PROD	/u01/oracle/TEST
Database version	Oracle 19c	Oracle 19c
EBS version	12.2.x	12.2.x

Important: These are illustrative values. Replace them with the actual values in your environment.

For a successful clone, verify that the source and target operating systems, database versions, EBS technology stack, and patch levels are compatible.

2. Pre-cloning checklist

Before starting the cloning process, complete the following checks.

2.1 Check the source application environment

Log in to the source application server as the application OS owner.

bash

su - applmgr

Set the RUN file-system environment.

bash

. /u01/oracle/PROD/EBSapps.env run

Verify the environment:

bash

echo $FILE_EDITION

echo $RUN_BASE

echo $PATCH_BASE

echo $APPL_TOP

echo $INST_TOP

echo $CONTEXT_FILE

Confirm that the RUN edition is active and that the application environment is healthy.

Check the application services:

bash

$ADMIN_SCRIPTS_HOME/adstrtal.sh

Use the appropriate service status utilities for your installation to verify the running services.

2.2 Check the database environment

Log in to the database server.

bash

su - oracle

Set the database environment:

bash

export ORACLE_SID=PROD

export ORACLE_HOME=/u01/oracle/product/19c/dbhome_1

export PATH=$ORACLE_HOME/bin:$PATH

Connect to SQL*Plus:

bash

sqlplus / as sysdba

Check the database status:

sql

SELECT name, open_mode, database_role
FROM v$database;

SELECT instance_name, status
FROM v$instance;

Check the database version:

sql

SELECT banner
FROM v$version;

Ensure the database is healthy and that there are no unresolved database issues.

2.3 Verify disk space

Check available disk space on the source and target servers.

bash

df -h

Check the size of the application file systems:

bash

du -sh /u01/oracle/PROD/fs1

du -sh /u01/oracle/PROD/fs2

du -sh /u01/oracle/PROD/fs_ne

Ensure that the target environment has sufficient capacity for the database files, application file systems, temporary staging files, and backup files.

2.4 Verify network connectivity

Check hostname resolution:

bash

hostname -f

ping test-db.example.com

ping test-app.example.com

Verify the required network connectivity between the application server and database server.

Also check that the target database listener port and application service ports are available.

3. Database tier cloning – source preparation

The first major activity is preparing the source database tier using the Rapid Clone utility.

Step 1: Log in to the source database server

Log in as the Oracle database OS owner.

bash

su - oracle

Set the database environment:

bash

export ORACLE_SID=PROD

export ORACLE_HOME=/u01/oracle/product/19c/dbhome_1

export PATH=$ORACLE_HOME/bin:$PATH

Step 2: Execute the database pre-clone script

Navigate to the database Oracle Home appsutil scripts directory.

bash

cd $ORACLE_HOME/appsutil/scripts/PROD_prod-db

Execute:

bash

perl adpreclone.pl dbTier

This is one of the most important steps in the cloning process.

The adpreclone.pl script prepares the source database Oracle Home for cloning.

It performs activities such as:

• Collecting database configuration information.
• Generating database-tier clone templates.
• Preparing configuration files.
• Creating the required clone directory structure.
• Preparing files needed for target database configuration.

Wait until the script completes successfully.

Review the log files generated by the utility and resolve any errors before proceeding.

Important: The source and target paths in this example are illustrative. Use the actual database context name and directory structure.

Step 3: Verify the database clone directory

Check the clone directory:

bash

cd $ORACLE_HOME/appsutil/clone

ls -ltr

Verify that the required clone utilities and templates have been generated.

The database-tier clone preparation is now complete.

4. Database backup and transfer to the target server

After preparing the source database tier, the next activity is transferring the database to the target environment.

There are several supported approaches, depending on the infrastructure:

• RMAN backup and restore.
• RMAN DUPLICATE.
• Storage-level snapshot and recovery.
• Other supported database cloning solutions.

For this example, we will use the RMAN backup and restore approach.

Step 4: Take an RMAN database backup

Connect to RMAN:

bash

rman target /

An illustrative backup command is:

sql

BACKUP DATABASE PLUS ARCHIVELOG;

Review the RMAN output and verify that the backup completed successfully.

Ensure that all required database files, control file information, archived logs, and recovery information are available for the target restore.

The exact backup and recovery procedure must follow your database architecture and recovery strategy.

Step 5: Transfer the database backup

Transfer the RMAN backup files to the target database server.

For example:

bash

scp -r /backup/PROD/* \
oracle@test-db.example.com:/backup/TEST/

Alternatively, use shared storage, NFS, or an approved backup transfer mechanism.

Verify the backup files on the target server.

bash

ls -lh /backup/TEST/

Step 6: Restore and recover the target database

On the target database server:

bash

su - oracle

Set the target database environment:

bash

export ORACLE_SID=TEST

export ORACLE_HOME=/u01/oracle/product/19c/dbhome_1

export PATH=$ORACLE_HOME/bin:$PATH

Restore and recover the database using the appropriate RMAN procedure for the target configuration.

The restoration process must account for:

• Target database SID.
• Target database file locations.
• Control file configuration.
• Redo log configuration.
• Archived log recovery.
• Database name and DBID requirements.
• Database version and compatibility.

Do not simply rename the source database SID in the shell environment and assume the database has been converted to a new target database.

Use a properly planned RMAN restore/duplicate workflow and the required database rename procedure.

At the end of this stage, the target database files should be restored and ready for the EBS database-tier configuration.

5. Database tier cloning – target configuration

Once the database has been restored to the target server, configure the target Oracle Home using Rapid Clone.

Step 7: Verify the target Oracle Home

Log in as the Oracle user:

bash

su - oracle

Set the environment:

bash

export ORACLE_SID=TEST

export ORACLE_HOME=/u01/oracle/product/19c/dbhome_1

export PATH=$ORACLE_HOME/bin:$PATH

Check the database Oracle Home:

bash

echo $ORACLE_HOME

echo $ORACLE_SID

Verify that the required appsutil clone directory and utilities are available.

Step 8: Execute adcfgclone.pl for the database tier

Navigate to:

bash

cd $ORACLE_HOME/appsutil/clone/bin

Execute:

bash

perl adcfgclone.pl dbTier

Rapid Clone will request configuration details for the target database environment.

Depending on the release, configuration, and clone mode, you may be prompted for:

• Target database hostname.
• Target database SID.
• Database listener information.
• Database port.
• Database domain.
• Database Oracle Home.
• Target base directory.
• Database context information.

Provide the correct target values.

For example:

text

Target Hostname: test-db.example.com

Database SID: TEST

Database Port: 1524

Database Domain: example.com

The utility creates the target database context configuration and performs the required Oracle Home configuration activities.

These can include:

• Registering the Oracle Home in the target inventory.
• Relinking Oracle Home components.
• Configuring database-tier files.
• Creating or updating the database context.
• Configuring the listener.
• Configuring database startup and shutdown scripts.

Review the generated logs carefully.

Step 9: Run AutoConfig on the database tier

After the database-tier configuration, run AutoConfig using the generated target context.

bash

cd $ORACLE_HOME/appsutil/scripts/TEST_test-db

Execute:

bash

perl adautocfg.sh

AutoConfig updates database-tier configuration files based on the target context file.

Check the AutoConfig logs for errors.

Step 10: Verify the target database

Connect to SQL*Plus:

bash

sqlplus / as sysdba

Check:

sql

SELECT name, open_mode
FROM v$database;

SELECT instance_name, status
FROM v$instance;

Check the database listener:

bash

lsnrctl status

Verify that the database is accessible using the target service name.

The database-tier cloning activity is now complete, subject to successful application-tier configuration and EBS-specific validation.

6. Application tier cloning – source preparation

The next stage is preparing the Oracle EBS application tier.

Oracle EBS 12.2 has two file systems, RUN and PATCH. The cloning process must preserve the relationship between these file systems.

Step 11: Log in to the source application server

Log in as the application OS owner.

bash

su - applmgr

Source the RUN edition environment:

bash

. /u01/oracle/PROD/EBSapps.env run

Verify:

bash

echo $FILE_EDITION

Expected output:

text

run

Step 12: Execute the application pre-clone script

Navigate to the application administration scripts directory:

bash

cd $INST_TOP/admin/scripts

Execute:

bash

perl adpreclone.pl appsTier

This prepares the application tier for cloning.

The utility collects configuration information and generates the required templates for the target environment.

Typical preparation activities include:

• Collecting application configuration details.
• Preparing application-tier clone templates.
• Preparing Oracle technology stack clone components.
• Preparing the WebLogic and application configuration information.
• Generating the files needed for target application-tier configuration.

For EBS 12.2, the WebLogic administrator credentials are required for relevant cloning operations.

Make sure you have the correct WebLogic administrator credentials before proceeding.

Step 13: Verify the generated clone files

Review the application-tier clone directory.

Typical locations include:

text

$COMMON_TOP/clone/

Check that the required clone files and directories have been generated.

Review the pre-clone log files and ensure that the script completed successfully.

Important: Do not perform the application file-system transfer until the required source preparation has completed successfully.

7. Copy the application file systems to the target server

The next step is transferring the application-tier file systems.

For a standard EBS 12.2 configuration, the main file systems to consider are:

text

fs1  - RUN or PATCH, depending on current edition

fs2  - PATCH or RUN, depending on current edition

fs_ne - Non-editioned file system

The edition assignments can change during online patching cycles.

Step 14: Check the source file-system layout

On the source application server:

bash

ls -ltr /u01/oracle/PROD/

Check the current edition assignments:

bash

. /u01/oracle/PROD/EBSapps.env run

echo $RUN_BASE

echo $PATCH_BASE

echo $NE_BASE

Make a note of the directory mapping.

Step 15: Prepare the target application directories

On the target application server, create the required base directories.

For example:

bash

mkdir -p /u01/oracle/TEST

Ensure the correct ownership and permissions are configured.

For example:

bash

chown -R applmgr:oinstall /u01/oracle/TEST

Adjust the group name and ownership to match your installation standards.

Step 16: Transfer the application file systems

Use an approved file-transfer method to copy the required source application file systems to the target.

For example, an illustrative rsync command is:

bash

rsync -av --progress \
/u01/oracle/PROD/fs1/ \
test-app.example.com:/u01/oracle/TEST/fs1/

Repeat for the other required file systems:

bash

rsync -av --progress \
/u01/oracle/PROD/fs2/ \
test-app.example.com:/u01/oracle/TEST/fs2/

Transfer the non-editioned file system as required by your installation:

bash

rsync -av --progress \
/u01/oracle/PROD/fs_ne/ \
test-app.example.com:/u01/oracle/TEST/fs_ne/

These commands are examples of file transfer, not a complete copy strategy.

For a production-quality clone, use Oracle's supported Rapid Clone procedure for your exact EBS 12.2 patch level and topology. Ensure the source file systems are consistent, the required files are included, and the target has the expected directory layout.

If you are copying while the source application is running, use an appropriate consistency strategy and final synchronization procedure. Avoid copying an actively changing file system and assuming that it represents a consistent application snapshot.

8. Application tier cloning – target configuration

After transferring the application file systems, configure the target application environment using Rapid Clone.

Step 17: Set the target application environment

Log in to the target application server:

bash

su - applmgr

Set the target environment using the appropriate target file-system context.

For example, after the relevant target configuration files are in place:

bash

. /u01/oracle/TEST/EBSapps.env run

Verify the environment variables:

bash

echo $FILE_EDITION

echo $RUN_BASE

echo $PATCH_BASE

echo $APPL_TOP

echo $INST_TOP

Confirm that you are working with the intended target installation.

Step 18: Execute the application-tier Rapid Clone utility

Navigate to the clone utility directory on the target application tier.

A typical location is:

bash

cd $COMMON_TOP/clone/bin

Execute:

bash

perl adcfgclone.pl appsTier

Rapid Clone will prompt for target configuration details.

These typically include:

• Target application hostname.
• Target domain name.
• Target base directory.
• Target instance directory.
• Target port pool.
• Target database hostname.
• Target database port.
• Target database SID or service configuration.
• WebLogic administrator credentials.

For example:

text

Target Hostname: test-app.example.com

Target Domain: example.com

Target Base: /u01/oracle/TEST

Target Database Host: test-db.example.com

Target Database Port: 1524

Target Database SID: TEST

Select a port pool that does not conflict with the source or other services on the target.

For EBS 12.2, the configuration must account for both the RUN and PATCH file systems. Follow the prompts and procedures applicable to the particular Rapid Clone version and topology.

The cloning utility performs activities such as:

• Creating or configuring application context files.
• Configuring the target instance directory.
• Registering Oracle technology stack components.
• Relinking required binaries.
• Configuring Oracle WebLogic components.
• Configuring Oracle HTTP Server.
• Configuring application services.
• Updating target database connectivity.
• Configuring the application-tier environment.

Allow the process to complete.

Review all generated logs and resolve any errors before starting the application services.

Step 19: Verify the application context file

After cloning, locate the generated target context file.

A typical location is:

text

$INST_TOP/appl/admin/

Verify the context file and confirm that it contains the target environment details.

Check important configuration values, including:

text

Target hostname

Database hostname

Database SID

Database port

Application domain

Application base directory

Instance directory

Port configuration

Do not manually change generated configuration files unless required by the documented procedure. Use the context variables and AutoConfig to maintain configuration consistency.

Step 20: Run AutoConfig on the application tier

Once the application-tier clone configuration is complete, execute AutoConfig.

Navigate to:

bash

cd $INST_TOP/admin/scripts

Run:

bash

./adautocfg.sh

Enter the required credentials when prompted.

AutoConfig updates application-tier configuration files based on the generated target context.

Review the AutoConfig log and verify successful completion.

9. Post-cloning database configuration

After completing the database and application tier cloning, several important post-cloning tasks must be performed.

Step 21: Verify database connectivity

Connect to the target database:

bash

sqlplus apps@TEST

Verify that the EBS application schemas are available.

For example:

sql

SELECT username, account_status
FROM dba_users
WHERE username IN ('APPS', 'APPLSYS');

Check the database service:

sql

SELECT name, network_name
FROM v$services;

Verify that the application tier can connect to the target database using the target TNS configuration.

Step 22: Verify database context and configuration

Check the target database context file and configuration.

Typical database context files are located under the database Oracle Home appsutil configuration directories.

Verify:

• Database hostname.
• Database SID.
• Database domain.
• Listener configuration.
• Database port.
• Target Oracle Home.
• Target service name.

If any context changes are necessary, apply them through the appropriate AutoConfig process.

10. Post-cloning application configuration

Step 23: Verify application environment variables

Log in to the target application server:

bash

su - applmgr

Source the target RUN environment:

bash

. /u01/oracle/TEST/EBSapps.env run

Check:

bash

echo $FILE_EDITION

echo $APPL_TOP

echo $COMMON_TOP

echo $INST_TOP

echo $FND_TOP

echo $ADMIN_SCRIPTS_HOME

Ensure that all variables point to the target environment.

Step 24: Verify the WebLogic configuration

Oracle EBS 12.2 uses Oracle WebLogic Server as part of its application technology stack.

Check that the target WebLogic configuration is correct.

Verify:

• WebLogic domain configuration.
• Admin Server configuration.
• Managed Server configuration.
• Node Manager configuration.
• WebLogic administrator credentials.
• Server listen addresses and ports.

Check the relevant WebLogic logs if any managed server fails to start.

Step 25: Start the application services

After the database and application configurations have been verified, start the target application services.

Source the RUN environment:

bash

. /u01/oracle/TEST/EBSapps.env run

Start the application services:

bash

$ADMIN_SCRIPTS_HOME/adstrtal.sh

Provide the required WebLogic administrator credentials when prompted.

Monitor the startup process.

The following components should be checked:

• Oracle HTTP Server.
• WebLogic Admin Server.
• oacore managed servers.
• oafm managed servers.
• Forms managed servers.
• Concurrent Processing.
• Other enabled application services.

Step 26: Verify application services

Use the application service status utilities appropriate for your EBS 12.2 installation.

Check the application logs for errors.

Verify that the application login page is accessible through the target URL.

For example:

text

http://test-app.example.com:8000/OA_HTML/AppsLogin

The hostname and port are illustrative and must match your target configuration.

Log in to Oracle EBS using an authorized test account.

Verify that the home page loads successfully.

11. Important post-cloning activities

A database and application clone is not complete simply because the application login page is accessible.

There are several important business and operational settings that must be reviewed before handing the environment over to users.

Step 27: Disable production integrations

One of the most important tasks is preventing the cloned TEST environment from interacting with production systems.

Review and disable or redirect:

• External bank interfaces.
• Payment gateways.
• Supplier integrations.
• Customer integrations.
• Tax interfaces.
• Third-party web services.
• Outbound email integrations.
• Production SFTP connections.
• External middleware connections.

Verify that all integrations point to the appropriate TEST endpoints.

Step 28: Disable Workflow Mailer and outbound notifications

Check the Workflow Mailer configuration.

Ensure that the TEST environment does not send production business notifications to actual customers, suppliers, or employees.

Disable the mailer or redirect outbound messages to a controlled test mail server.

Step 29: Review concurrent managers

Review the concurrent manager configuration.

Check:

• Internal Concurrent Manager.
• Standard Manager.
• Conflict Resolution Manager.
• Specialized managers.
• Custom concurrent managers.

Verify that only the appropriate managers are enabled.

Review scheduled requests and recurring programs to prevent unintended production-like processing.

Step 30: Update environment-specific URLs

Check the following application configuration values:

• Applications login URL.
• Web entry point.
• External web entry point.
• WebLogic server URLs.
• Forms URLs.
• BI Publisher endpoints, if applicable.
• Integrated third-party URLs.

Ensure that all URLs reference the TEST environment.

Step 31: Review printer and output configurations

Check printer definitions and output destinations.

Ensure that test concurrent requests do not send output to production printers or external business locations.

Step 32: Perform data masking where required

If the source is a production database and the target is a development or testing environment, consider data masking.

Sensitive information may include:

• Employee personal information.
• Customer details.
• Supplier banking information.
• Payment information.
• Contact details.
• Other confidential business data.

Follow your organization's data privacy and security policies before making the cloned environment available to users.

12. Final validation checklist

Once all cloning and post-cloning activities are complete, perform a comprehensive validation.

No.	Validation activity	Expected result
1	Database startup	Database OPEN
2	Database listener	Running
3	Database service	Accessible
4	APPS schema	Available
5	Application context	Target hostname
6	Database context	Target database
7	RUN file system	Configured
8	PATCH file system	Configured
9	Non-editioned file system	Accessible
10	WebLogic Admin Server	Running
11	oacore services	Running
12	Forms services	Running
13	Oracle HTTP Server	Running
14	Concurrent Managers	Running as intended
15	EBS login page	Accessible
16	Workflow Mailer	Controlled
17	External integrations	Redirected or disabled
18	Scheduled requests	Reviewed
19	Data masking	Completed where required
20	Online patching status	Healthy

Step 33: Validate online patching configuration

Oracle EBS 12.2 uses the Online Patching feature.

Check the adop status:

bash

adop -status

Review the output and verify that there are no incomplete or failed online patching cycles that would compromise the environment.

Also verify that the RUN and PATCH file systems are correctly configured.

Do not start a new online patching cycle until the cloned environment has passed the necessary validation.

13. Troubleshooting common cloning issues

Below are some commonly encountered issues during Oracle EBS 12.2 cloning.

Issue 1: adpreclone.pl fails

Possible causes:

• Incorrect environment variables.
• Missing or inconsistent clone utilities.
• Insufficient disk space.
• Incorrect file permissions.
• Incomplete patching or technology stack configuration.

Resolution:

• Source the correct RUN environment.
• Verify the application and database environment variables.
• Check the pre-clone logs.
• Confirm that the required binaries and clone utilities exist.
• Resolve the reported errors and rerun the preparation step.

Issue 2: adcfgclone.pl fails

Possible causes:

• Incorrect hostname or domain.
• Incorrect database connection information.
• Incorrect target directory.
• Port conflicts.
• Missing Oracle inventory configuration.
• Incorrect WebLogic credentials.

Resolution:

• Verify the target hostname and DNS resolution.
• Check the target database listener.
• Verify directory ownership and permissions.
• Confirm the correct port pool.
• Check the Rapid Clone logs.
• Verify WebLogic administrator credentials.

Issue 3: Application services fail to start

Possible causes:

• Database connectivity problems.
• WebLogic configuration errors.
• Port conflicts.
• Incorrect context file values.
• Invalid or inconsistent application configuration.

Resolution:

• Verify database connectivity from the application server.
• Review WebLogic Admin Server and managed server logs.
• Check the application context file.
• Verify port availability.
• Run AutoConfig after correcting supported context configuration values.

Issue 4: Concurrent Managers do not start

Possible causes:

• Database connectivity issues.
• Incorrect application configuration.
• Invalid target node registration.
• Concurrent processing configuration problems.

Resolution:

• Check the database connection.
• Review concurrent manager logs.
• Verify the target node configuration.
• Review the concurrent processing services and configuration.

Issue 5: Application redirects to the production URL

Possible causes:

• Incorrect web entry point configuration.
• Old production URLs in configuration.
• Incorrect context file values.
• Incorrect load balancer configuration.

Resolution:

• Verify the target application context.
• Review the web entry point configuration.
• Check AutoConfig logs.
• Verify the load balancer and reverse proxy settings, if applicable.

14. Recommended cloning sequence

For a successful Oracle EBS 12.2 cloning activity, follow this high-level sequence:

1. Validate source database and application environments.
2. Verify target infrastructure and prerequisites.
3. Run adpreclone.pl dbTier on the source database server.
4. Create and transfer the database backup.
5. Restore or duplicate the database on the target server.
6. Run adcfgclone.pl dbTier on the target database server.
7. Run database-tier AutoConfig.
8. Run adpreclone.pl appsTier on the source application server.
9. Copy the required application file systems.
10. Configure the target application tier using Rapid Clone.
11. Run application-tier AutoConfig.
12. Verify database and application connectivity.
13. Start application services.
14. Disable or redirect production integrations.
15. Validate EBS login, concurrent managers, Workflow, and online patching.
16. Complete security and data masking activities.

15. Conclusion

Oracle E-Business Suite 12.2 cloning is an essential administration activity for maintaining development, testing, UAT, and pre-production environments.

The Rapid Clone utility simplifies the process by automating the configuration of the database and application tiers.

However, successful cloning requires more than transferring files and restoring a database. Administrators must carefully manage the source preparation, database restoration, application file-system configuration, WebLogic configuration, AutoConfig execution, and post-cloning activities.

Following a structured cloning procedure helps ensure that the target environment is properly configured, isolated from production, and ready for business testing.

The most important takeaway: Always use the Oracle Rapid Clone procedure applicable to your exact EBS 12.2 release, AD/TXK patch level, database version, and deployment topology. A successful clone is one that is technically functional, correctly configured, and safe to use independently of production.

Official Oracle references

The following documentation should be consulted alongside the procedure, particularly because some commands and cloning requirements vary by AD/TXK patch level and database architecture.

1. Oracle E-Business Suite Concepts – Cloning (Release 12.2)

Oracle documentation: Cloning and Rapid Clone 

Covers Rapid Clone architecture, source preparation, target configuration, and database/application-tier cloning concepts.

2. Oracle Application Management Pack – Smart Clone for EBS 12.2

Oracle documentation: Smart Clone 

Covers automated database and application-tier cloning, credentials, target configuration, and application node setup.

3. Oracle EBS 12.2 documentation library

Oracle E-Business Suite official documentation 

4. Oracle My Oracle Support – Doc ID 1383621.1 Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone. This is an important reference for the detailed, patch-level-specific cloning procedure. Access requires an Oracle Support account.

Technical note: The article provides a general single-node cloning workflow. Before executing it in production, cross-check the precise file-copy sequence, RUN/PATCH file-system handling, database restore procedure, and Rapid Clone prompts against the applicable Oracle Support documentation.