Patching history of a file – adfhrept.sql

Oracle Apps 11i and E-Business Suite R12 provides a wonderful utility to get the history of any file applied through patches. When a patch it applied higher version file get implemented in application. This utility will give complete history about a file starting from the initial release till now and which patch has introduced which release at what date.

The file name is adfhrept.sql and is present under $AD_TOP/patch/115/sql

Following is the usage of file.

adfhrept.sql <filename>\

<latest file version only? (Y/N)> \
<start date(mm/dd/rr or ALL)> \
<end date (mm/dd/rr or ALL)> <patchtype/ALL> <language/ALL> \

<limit to forms server? (Y/N)> \
<limit to web server?(Y/N)> \
<limit to node server? (Y/N)> \
<limit to admin server?(Y/N)> \
<only patches that change DB? (Y/N)>

For example:

-bash-2.05b$ sqlplus apps/apps @adfhrept.sql adphst.odf N 12/01/00 12/31/08 ALL ALL ALL N N N N N

SQL*Plus: Release – Production on Mon Jun 30 12:56:21 2008

(c) Copyright 1999 Oracle Corporation.  All rights reserved.

Connected to:
Oracle8i Enterprise Edition Release – Production
With the Partitioning option
JServer Release – Production

Writing data to report file adfilerep.xml…

Done writing data to report file adfilerep.xml

To view the XML report from browser
Copy file adfilerep.xml to OA_HTML top directory

Disconnected from Oracle8i Enterprise Edition Release – Production
With the Partitioning option
JServer Release – Production

This sql will create an XML file at the same location from where you are running this utility. You need to mode the XML file to OA_HTML where its corresponding XSLT file is present. You can then access this XML file using the URL: http://(hostname):(Apache port)/OA_HTML/adfilerep.xml

The output will looks like this.

Hope this helps !!


Metalink Note ID: 162498.1

AutoPatch modes, arguements and options

Here are the various options for applying the patch in Oracle apps 11i and R12. ADpatch comes with lots of option that can be used, especially when we are applying the patch in production.

Modes of ADPATCH

If we talk about the mode of applying patch, there are 3 modes

1) Pre-Install Mode

Pre-install mode is used to update AD utilities before an upgrade and to apply family consolidated upgrade packs.
AutoPatch Pre-AutoInstall mode allows you to apply patches when your installation is missing database information and/or filesystem information that AutoPatch requires to run in normal mode.

Examples of when you would run AutoPatch in Pre-AutoInstall mode (and cannot run it in normal mode) include:

  • Prior to installing Oracle Applications for the first time
  • Prior to upgrading Oracle Applications to the latest release.
  • During an upgrade (to apply a bug fix that stopped your upgrade)

Applying patch in pre-install mode performs following tasks:

  • Version checking
  • File copy actions
  • Relink FND and AD executables
  • Save patch history information to file system

AutoPatch in pre-install mode will NOT:

  • Run SQL of EXEC command
  • Generate files
  • Read product driver files
  • Apply maintenance pack

To apply patch in pre-install mode, run  adpatch preinstall=y

2) Test Mode

AutoPatch provides a test mode in which it tells you everything it would have done in applying a patch, but doesn’t actually apply the patch.

To run AutoPatch in Test Mode, you must include ‘apply=no’ on the AutoPatch command line. For example:

$ adpatch apply=no

Instead of performing an action, AutoPatch indicates that it is not performing the action because “Apply=No”. In general, AutoPatch lists each file it would have copied, generated, relinked, or executed. This shows you exactly what actions it would have performed.

AutoPatch test mode works the same as normal mode, with the following exceptions:

  • It does not copy any files from your patch directory into your installation area.
  • It does not copy any files from your APPL_TOP to JAVA_TOP or OAH_TOP.
  • It does not archive any object modules into your product libraries.
  • It does not generate any forms or reports.
  • It does not relink any executables.
  • It does not run any ‘sql’ or ‘exec’ commands.
  • It does not update the release version in the database.
  • It does not update the patch history file.

AutoPatch asks you the same initial questions in test mode as in normal mode. It performs the following actions to determine what it would have done if run in normal mode:

  • Reads and validates the patch driver file.
  • Reads product file driver files.
  • Extracts object modules from your product libraries (so it can perform version checking on the object modules it extracts).
  • Performs version checking.
  • Looks in the database to determine what ‘sql’ and ‘exec’ comands it would have run.

Its a good practice to run the patch in test mode and analyze the things before applying the patch in normal mode.

3) Non-Interactive Mode

Starting in Release 11.5, you can run AutoPatch non-interactively.

Creating a defaults file

Before you can run AutoPatch non-interactively, you must first create an AutoPatch defaults file for your current environment.

Here is a simple way to create an AutoPatch defaults file for your current environment:

1. Specify defaultsfile=<New Defaults File Name> on the AutoPatch command line. The defaults file must be located under $APPL_TOP/admin/<SID>.

For example:

adpatch defaultsfile=$APPL_TOP/admin/testdb1/my_def.txt

2. Run AutoPatch up to the point where it asks you for the directory where your Oracle Applications patch has been unloaded. Then type ‘abort’ at this prompt.

3. Verify that your defaults file exists.

Once you have an AutoPatch defaults file for your current environment, you can run AutoPatch non-interactively.

Applying a single patch driver file non-interactively

Before applying any Oracle Applications patch, either interactively or non-interactively, you should read the README file (usually called readme.txt) supplied with the patch. You should also read the documentation supplied with the patch (if any).

It is possible to apply just a single patch driver file non-interactively using AutoPatch. Here is an example:

Assume the following:

  • defaults file is $APPL_TOP/admin/testdb1/def.txt
  • Applying copy driver for patch 123456, which is located in directory $APPL_TOP/patch/123456.
  • Using three parallel workers
  • AutoPatch log file name is cpy123456.log

The AutoPatch command line would be:

adpatch defaultsfile=$APPL_TOP/admin/testdb1/def.txt \
logfile=cpy123456.log \
patchtop=$APPL_TOP/patch/123456 \
driver=c123456.drv \
workers=3 \

If we dont give any of the mode as mentioned above and apply the patch simply using adpatch command then its a normal mode of patch application.

Having seen the modes of patch application, now we will see various arguements for applying patch.

1) defaultsfile
Purpose: This option is used when we are running the patch in non interactive mode. In that case we create defaults file and provide that file as an option for running patch in non-interactive mode.
Default: none. No default file read or written.

2) logfile
Purpose: This is the name of adpatch log file which it will write during patch application.
Default: none. Adpatch prompts for this value.

3) workers
Purpose: Specifies the number of workers to run. This value depends on number of CPU and other factors.
Default: none. Adpatch prompts for this value.

4) patchtop
Purpose: Top-level directory for the current patch. This is the directory after unzipping the patch. This directory will a patch number.
Default: none. Adpatch prompts for this value.

5) driver
Purpose: Name of the patch driver file. This comes with the patch and is present in patch directory.
Default – none. Adpatch prompts for this value.

6) restart
Purpose: To restart an existing session. Only valid when interactive=no is also specified
Default: No

7) localworkers
Purpose: Used in Distributed AD to specify the number of workers to be run on the current machine. If you have multi node instance (example RAC and shared APPL_TOP), then you can utilize this paramter to run the patch parallely in multiple nodes. You can start few workers on node 1, few on node 2 and so on. The way this can be done is that, you can start adpatch on one node with localworker=<some value less then total workers>. Then run adctrl on other node in distributed mode and start some mode workers. This will speed up the process and utilized the resources effectively.
Default: Value specified for workers.

8) printdebug
Purpose: To display extra debugging information.
Default: No.

Now lets consider some common options that can be used with adpatch options=<value>

1) checkfile
Purpose: To skip running exec, SQL, and exectier commands if they are recorded as already run. Indicates that Autopatch should run the command *only* if a certain file is newer than the version of it that was last run. The idea behind it is to reduce the duration of an Autopatch session by skipping actions that don’t really need to be performed. When used in the right manner, it can dramatically improve Autopatch performance, especially for big patches and/or long running actions.
Default: checkfile (use ‘nocheckfile’ to skip)

2) compiledb
Purpose: To compile invalid objects in the database after running actions in the database driver.
Default: compiledb (use ‘nocompiledb’ to skip)

3) compilejsp
Purpose: To compile out-of-date JSP files, if the patch has copy actions for at least one JSP file.
Default: compilejsp (use’nocompilejsp’ to skip)

4) copyportion
Purpose: To run commands found in a copy driver. This will copy the higher version files from patch to product top.
Default: copyportion (Use ‘nocopyportion’ to skip. Use it only when mentioned in readme of patch)

5) databaseportion
Purpose: To run commands found in a database driver. This portion includes applying the files (like sql, pls etc) to database.
Default: databaseportion (use ‘nodatabaseportion’ to skip. Use it only when mentioned in readme of patch)

6) generateportion
Purpose: To run commands found in a generate driver. This portion will generate new executable files from the copied code of patch. For example if will generate new forms files (fmx) from new .fmb files.
Default: generateportion (use ‘nogenerateporation’ to skip)

7) integrity
Purpose: To perform patch integrity checking. Tells adpatch whether to perform patch integrity checking, which verifies that the version of each file referenced in a copy action matches the version present in the patch.
Default: nointegrity (By default the integrity is not checked)

8) maintainmrc
Purpose: To maintain the MRC schema after running actions found in the database driver.
Default: maintainmrc (use ‘nomaintainmrc’ to skip)

9) autoconfig
Purpose: Tells adpatch to run Autoconfig after patch installation.
Default: autoconfig (use ‘noautoconfig’ to skip)

10) parallel
Purpose: To run actions that update the database or actions (like SQL) that generate files in parallel (like genform).
Default: parallel (use ‘noparallel’ to skip)

11) prereq
Purpose: Tells adpatch whether to perform prerequisite patch checking prior to running patch driver files that contain actions normally found in the copy driver.
Default: prereq (use ‘noprereq’ to skip)

12) validate
Purpose: To connect to all registered Oracle Applications schemas at the start of the patch. Adpatch validates the passwords for each schema.
Default: novalidate (use ‘validate’ to validate schema passwords)

Following flags can be passed to adpatch

1) hidepw
Purpose: This argument is used to hide the passwords in log files
Default: nohidepw

2) trace
Purpose: Tells the adpatch utility whether to log all database operations to a trace file
Default: notrace

3) logging
Purpose: Tells the adpatch utility whether to create indexes using the logging or nologging mode.
Default: logging

Hope this helps !!

Rolling Back Previous Autoconfig Run

In case your autoconfig run has created some issues in your environment and you want to rollback autoconfig run, you can do so by running script.

For every autoconfig run, autoconfig will create a directory “MMDDhhmm” under APPL_TOP/admin/TWO_TASK/out. Inside these directories, there will be several files which autoconfig has taken a backup off before making changes. Also there will be a script This script is going to copy these backup files to the original location and this has the effect to rolling back autoconfig run.

(appmgr02) 06190950 – -bash $ pwd
(appmgr02) 06190950 – -bash $

Hope this helps !!

Running Autoconfig in Test Mode

Before running the autoconfig in production to propogate your changes, its usually a good idea to run autoconfig in test mode. This will reduce the risk and you can understand the impact better. AD tool provides a script to run autoconfig in test mode. This script will create a report which will list all files & profile options that is going to change when you run AutoConfig.

Below is the sample run for the same.

(appmgr02) bin – -bash $
Enter the full path to the Applications Context file:
Enter the APPS user password:

AutoConfig is running in test mode and building diffs…

AutoConfig will consider the custom templates if present.
Using APPL_TOP location     : /slot02/appmgr/PQDC2MS1appl
Classpath                   : /local/java/jdk1.4.2_04/jre/lib/rt.jar:/local/java/jdk1.4.2_04/lib/dt.jar:/local/java/jdk1.4.2_04/lib/tools.jar:/slot02/appmgr/PQDC2MS1comn/java/

Using Context file          : /slot02/appmgr/PQDC2MS1appl/admin/PQDC2MS1/out/06190701/PQDC2MS1.xml

Context Value Management will now update the test Context file
Updating test Context file…COMPLETED

[ Test mode ]
No uploading of Context File and its templates to database.

Testing templates from all of the product tops…

Differences text report is located at: /SLOTS/slot02/appmgr/PQDC2MS1appl/admin/PQDC2MS1/out/06190702/cfgcheck.txt

Generating Profile Option differences report…COMPLETED
Generating File System differences report……COMPLETED
Differences html report is located at: /slot02/appmgr/PQDC2MS1appl/admin/PQDC2MS1/out/06190702/cfgcheck.html

Differences Zip report is located at: /slot02/appmgr/PQDC2MS1appl/admin/PQDC2MS1/out/06190702/

AutoConfig completed successfully.
The log file for this session is located at: /slot02/appmgr/PQDC2MS1appl/admin/PQDC2MS1/log/06190701/adconfig.log

Once autoconfig is run on test mode, it will generate a zip file ( as shown above. You can copy the zip file to $OA_HTML location and unzip the same. You can then view the report using following URL


Hope this helps !!

Upgrading Developer 6i with Oracle Applications 11i


Some times we face problem due to older version or incorrect version of developer 6i in Oracle Applications 11i. For example I can explain my scenario, where I had to upgrade Forms Developer 6i version from Patch level 17 to Patch level 18.

I was trying to apply patch 6372396 TXK AUTOCONFIG AND TEMPLATES ROLLUP PATCH S (APRIL/MAY 2008) to one of the environment. In the pre-reqs section it ask to run script to generate the report, which will actually carry out the analysis of the techstack level in your environment and whether all the techstack level is sufficient enough to apply this patch.

In my case if gave me a report as shown in this link.

So I had to upgrade my Developer 6i version. You can get the current version of Forms Developer 6i by logging on application side and sourcing the environment and running following command

$ORACLE_HOME/bin/f60gen help=y

Upgrading Developer 6i Home:

Following are the steps performed for upgrading developer 6i from (Patch 17) to (Patch 18). (The steps are followed from metalink note ID 125767.1)

1) Check if you have a latest version of Oracle Jinitiator in your application.

Oracle JInitiator is now available on two streams of JDK for Oracle Applications 11i customers. Customers may continue to use JInitiator 1.1.8.x (JDK 1.1 based) or move to JInitiator 1.3.1.x (JDK 1.3 based). In some cases, migration to JInitiator 1.3.1.x requires additional technology upgrades. Please review the list of requirements in MetaLink Note 124606.1 (Upgrading Oracle JInitiator with Oracle Applications 11i) to determine feasibility of migration to JInitiator 1.3.1.x at this time. We strongly recommend you upgrade to the latest version of Oracle JInitiator certified with Applications along either stream.

If you don’t have latest version for Oracle Jinitiator, then you can upgrade the same using this link.

2) Apply Developer 6i Patch set (4948577). This is the techstack patch set and needs to be applied to 8.0.6 oracle home.

Following steps are to be done for applying the patch

  • Download patch 4948577 from metalink
  • Set ORACLE_HOME to your 8.0.6 forms oracle home
  • unzip the patch in you 8.0.6 oracle home
  • cd $ORACLE_HOME/developer6i_patch18
    ./ 2>&1 | tee patch_install_p18.log (ksh)
    ./ |& tee patch_install_p18.log (csh)
  • Check patch_install_p18.log for errors.
  • Relink Procedure Builder, Forms, Graphics and Reports:
    cd $ORACLE_HOME/procbuilder60/lib; make -f install
    cd $ORACLE_HOME/forms60/lib; make -f install
    cd $ORACLE_HOME/graphics60/lib; make -f install
  • Reports has both link-time and run-time dependency with so you need to append either one of:
    in $LD_LIBRARY_PATH before linking Reports.
    Please check your files under $ORACLE_HOME/network/jre11/lib to see which one of the above is appropriate on your system. The same $LD_LIBRARY_PATH should be used at run-time.

    cd $ORACLE_HOME/reports60/lib; make -f install

3) Applying the additional patches as mentioned in metalink docs

  • 5713544
  • 4261542
  • 5216496
  • 5753922 – If your database is 9i, skip this patch as this is for database 10g
  • 6195758
  • 5938515

After applying the Oracle Developer 6i Patch and apps interop on UNIX platforms, you must relink several Oracle Applications executables to include Developer patch changes. The executables are f60webmx,  ar60run , ar60runb, ar60rund, and are all owned by FND.

You can relink these executables by running adadmin
When the Main Menu appears select ‘Maintain Applications Files Menu‘ and then select ‘Relink Applications Program
Answer the questions below as follows, in order to select the individual executables for relinking.

Enter list of products to link (‘all’ for all products)[all] : fnd
Generate specific executables for each selected product [No] ? y
Relink with debug information [No] ? n

(You will then be offered a list of executables that are available for relinking)

Enter executables to relink, or enter ‘all’ [all] : f60webmx ar60run ar60runb ar60rund *

4) Download and apply the apps interop patch (4888294)

This completes the upgrade of developer 6i home from (Patch 17) to (Patch 18).

Run the report once again and check and you will see the report as shown by this link.

Hope this helps !!


Metalink Note ID: 125767.1

Utility to check techstack components – Oracle Applications

There is a good utility for checking all the techstack components and there versions present in e-business application. This is applicable to both 11i and R12 environments.

There is a script $FND_TOP/patch/115/bin/ on apps side which is going to fetch the versions of all components on apps side. This script can be run by giving input to $FND_TOP/patch/115/bin/ script. script takes 2 mandatory arguments, one is the script to run and another is the directory for storing log file and out file. Other then these arguments you must give context file name and location and apps password as well. Also you need to give outfile where it will create report of techstack components.

Login to apps side of your application and source the environment. Run the below command

(appmgr06) appmgr – -bash $ perl $FND_TOP/patch/115/bin/ -script=$FND_TOP/patch/115/bin/ -txktop=$APPLTMP -contextfile=$CONTEXT_FILE -appspass=apps -outfile=$OA_HTML/techstack_info.html
*** STDOUT   = /slot06/appmgr/scmc2mq0comn/rgf/scmc2mq0/TXK/txkInventory_Fri_May_16_04_01_03_2008_stdout.log

Reportfile /slot06/appmgr/scmc2mq0comn/html/techstack_info.html generated successfully.

You can access the above report file using http://(hostname.domain):(port)/OA_HTML/techstack_info.html

The report will look like this.

The report will have following information.

  • Summary of environment details
  • Inventory of HTTP Server Node
  • Inventory of Forms Server Node
  • Inventory of Concurrent Processing Server Node
  • Inventory of Administration Server Node

Similarly you can check on DB side as well

(oracle06) scmc2mq0 – -bash $ perl $ORACLE_HOME/appsutil/bin/ -script=$ORACLE_HOME/appsutil/bin/ -txktop=$ORACLE_HOME/appsutil/temp -contextfile=$CONTEXT_FILE -appspass=apps -outfile=$ORACLE_HOME/appsutil/temp/master_db.html

Hope this helps !!

Compiling JSPs in Oracle Applications

Many times we faces an issue which needs JSPs to be compiled, specially in case of development. Also for example, if some of the class files are missing then, in that case we can compile the JSPs and get the required class files.

In Oracle Applications (11i as well as R12), we have a utility called This script carries out compilation of JSPs. Below is some information regarding this script.

Oracle Apps 11i

In 11i version, this script is present in JTF_TOP/admin/scripts


(appmgr01) scripts – -bash $ ./
syntax: ./ COMMAND {ARGS}
COMMAND –compile               update dependency, compile delta
–create                rebuild entire dependency file
-delta.out <file>       update dependency, list delta to file
-dep.out <xmlfile>      update dependency, output heirarchy to file

ARGS    -s <regex>      matching condition for JSPs filenames
-p <procs>      number of parallel compilations
-log <file>     to override logfile from ojspCompile.conf
-conf <file>    to override ojspCompile.conf
–retry         retry previously failed compilation attempts
–flush         forces recompilation of all parent JSPs
–quiet         do not provide an actively running progress meter
–fast          instantly fail jsps that are *possibly* invalid

example1: –compile -s ‘jtf%’ -p 20 –retry
example2: –compile -s ‘jtflogin.jsp,jtfavald.jsp’ –flush
example3: –compile –fast –quiet


We can run the script using the above parameters. Example


(appmgr01) scripts – -bash $ ./ –compile –quiet
identifying apache_top…/slot01/appmgr/plmmtqaeora/iAS
identifying apache_config_top…/slot01/appmgr/plmmtqaeora/iAS
identifying java_home…/local/java/jdk1.4.2_04
identifying jsp_dir…/slot01/appmgr/plmmtqaecomn/html
identifying pages_dir…/slot01/appmgr/plmmtqaecomn
identifying classpath…file:///slot01/appmgr/plmmtqaeora/iAS/Apache/Jserv/etc/
auto-logging to /slot01/appmgr/plmmtqaecomn/_pages/ojsp_error.log
starting…(compiling delta)
using 8i internal ojsp ver:
including compatibility flag -whiteSpaceBetweenScriptlet
synchronizing dependency file:
enumerating jsps…15390
parsing jsp…15390
writing deplist…15390
initializing compilation:
eliminating children…12220 (-3170)
searching uncompiled…12199
translating and compiling:
searching untranslated…12199
translating jsps…12199/12199 [failed: 3] in 3m43s
compiling jsps… 51% complete: 6250/12196 ETA: 4m47s
compiling jsps…12196/12196 in 8m44s


Using parameters –compile –quiet will compile only those JSPs which are invalid and needs compilation.

If you want to compile all JSPs (irrespective of status), then you need to use –compile –flush as parameters to

Doing these will replace all the .class files in _pages directory under COMMON_TOP (which is a kind of cache for JSPs).

Also in case of 11i, automatic recompilation of JSPs are done when we access the JSP. This is the default and only behavior. So in case if you delete _pages directory under COMMON_TOP, we can always recreate the same by running or accessing the application directly.

In case we access application directly without running, the access will be little slower, since it will be doing compilation as well.

Oracle E-Business Suite R12

In case of Oracle E-Business suite R12, same script is present for compiling JSPs, but this script is present under FND_TOP/patch/115/bin directory.

Also, you cannot delete _pages directory under COMMON_TOP. Deleting this will make your application non-workable.

The reason for the same being that, in case of R12, JSPs are not compiled as and when you access them. So dynamic compilation of JSPs are not present. This is basically done to improve the performance of application system.  But in case _pages directory has been deleted, then you can recreate the same by running –compile –flush command.

Also some times, its required to have dynamic compilation of JSPs, specially in case of development environment, so that oacore will pick the latest changes. This setting can be done using a parameter in CONTEXT_FILE. The paramter name is s_jsp_main_mode.

This parameter is by default having a value of justrun, this can be changed to recompile. Once changed, you can run autoconfig and Verify that the $INST_TOP/ora/10.1.3/j2ee/oacore/application-deployments/oacore/html/orion-web.xml  has


Doing this will make new JSP to get compiled before it is shown on browser.


Metalink Note ID 458338.1

Upgrading Oracle Application 11i to E-Business Suite R12

Overview of upgrade to R12

Upgrading an application from 11i to R12 involves, upgrading the database side, upgrading the middleware techstack and upgrading the application side.

Supported upgrade path for application side upgrade is as given below.


In case of database upgrade, you have to upgrade the database to 10gR2 (10.2.0). Because application R12 can be used only with 10g database.

Upgrade Process

All upgrade functionality has been consolidated into a single unified upgrade driver that performs the upgrade without reliance on the information formerly captured on the AutoUpgrade screens.

Rapid Install provides the most up-to-date, certified version of Oracle Applications products, along with the certified technology stack components. In an upgrade, it creates the new file system for the application (middle) tier components and the new file system for the database. After the upgrade, you run Rapid Install again to configure servers and start services.

An upgrade also includes various manual steps, including those that direct you to run scripts or apply patches. You rely on AutoPatch to apply all patches, including the unified driver that performs the upgrade to Release 12.

Upgrade Steps in brief

Here are the 4 simple steps, briefly presented below for upgrade. These steps are at very high level of abstraction. We will detailed each steps as we move on further.

1) Understand installed components, system sizing information, NLS considerations
2) Prepare for upgrade using Upgrade Manual Script(TUMS).
3) Upgrading to R12. This includes upgrading the database and applying the required patches through AutoPatch.
4) Post-Upgrade process. Complete the upgrade process by applying the latest RUP patches to keep the system most current.

We wont be considering the functional upgrade task here.

Upgrade steps in detail

1) Understanding installed components

Technology Stack Components

Rapid Install automatically installs and configures the required technology stack components for both the database tier and the application tier.
The database tier technology stack for both a new installation and for a system upgrade is based on Oracle10g Release 2.
The technology stack installed on the application tier includes, among other components:
– Oracle 10g Application Server (AS) 10.1.2
– Oracle 10g Application Server (AS) 10.1.3
– Oracle Developer 10g (includes Oracle Forms)
– Java (J2SE) native plug-in 1.5.0_08
– Java Developer Kit (JDK) 5.0

Memory Requirements

To calculate the memory requirements for an upgrade, consider the following:
– Number of concurrent users
– Infrastructure requirements for multi-tiered architecture
For example:
A test upgrade of the largest Oracle production system (oraprod) used the following:
– Database tier machine – 48 GB of memory
– Application tier machine – 12 GB of memory
A test upgrade of the Vision database and application tier machine used 6 GB of memory.

Database Size

To estimate the increase in required disk space for upgrading, consider the products, the number of languages being installed, and changes in the data model.

For example:
In a test upgrade of the largest Oracle production system (oraprod), the database increased 10-20 percent. In a test upgrade, the Vision database increased 5 percent. For guidelines based on an upgrade of the Oracle production system (oraprod), see E-Business Suite Release 12 Upgrade Sizing and Best Practices (Doc ID: 399362.1).

Database Backup

*** We strongly recommend that you back up your entire system before you begin the upgrade. ***

Database Initialization Parameters

Initialization parameters required at each stage of the upgrade may vary depending on when you upgrade your database. Review the requirements for these parameters before you begin. Refer to metalink note ID 396009.1 for initialization parameters.
Change the following initialization parameters as specified below for upgrade process. Once the upgrade process completes, reset the parameters back.

  • db_file_multiblock_read_count – Remove this parameter. (this is not required).
  • _db_file_optimizer_read_count = 8 (default setting is 8. Keep default setting).
  • job_queue_processes (set the value of this parameters equal to number of CPUs).
  • parallel_max_servers (set the value of this parameters equal to twice the number of CPUs).
  • pga_aggregate_target (refer to metalink note ID 396009.1 for recommended value).

Make sure that the temporary tablespace you have is locally managed and not dictionary managed. You can check this information using below query.

select CONTENTS,EXTENT_MANAGEMENT,ALLOCATION_TYPE from dba_tablespaces where tablespace_name=’TEMP’;

———— —————– —————

Else if the extent management is not local, you can drop and recreate temp tablespace using the below command.

NLS Upgrade Considerations

For NLS considerations, please refer to Applications upgrade docs.

Character Sets

You have to be careful while selecting the character set for APPL_TOP. Depending on whether your Applications system connects to the database during the upgrade process, you may be able to select a new character set for the Release 12 APPL_TOP on the Rapid Install wizard upgrade screens. However, if you do, the new set must be either identical to, or compatible with, the existing database character set. If you change the character set in the APPL_TOP to one that is not compatible with the current database character set, the upgraded system will be corrupted.

SQL> create TEMPORARY tablespace TEMP tempfile ’ts_p_temp1.dbf’ size 2048M EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;

2) Prepare for upgrade using Upgrade Manual Script(TUMS) and upgrading database

  • R12 upgrade process involve replacing 11i Tech stack (9iAS & 806) to Fusion Middleware (10g Application Server)
  • Basic upgrade process involves Rapid Install & Autopatch
  • Rapid Install involves installing new R12 tech stack as mentioned in first point
  • Auto patch process involves upgrading E-Business Suite database compatible to R12 (Data Model)
  • Final upgrade process is of updating data model using enhanced version of AutoPatch
  • Minimum version from which you can upgrade to R12 is 11.5.7 and higher
  • Minimum database version from which you can upgrade to R12 is 9i

As per Oracle R12 Upgrade Documentation, Apps 11i Instance is classified in Two Categories based on Apps & DB Version

Category 1 – 11.5.7, 11.5.8, 11.5.9 (CU1), 11.5.10 (CU1)
Category 2 – 11.5.9 (CU2), 11.5.10 (CU2) or

Why we cannot upgrade database to before for category 1 ?
This is because there is no Interoperability patch for above release & was supported for 11.5.9 (CU2) & 11.5.10(CU2) only.

What are advantages of Upgrading database to before R12 upgrade ?
Downtime can be broken down to two small downtimes (one for Database upgrade another one for R12 upgrade) and can be achieved during weekends or long weekends (depending on your system & resources)

The following table lists the paths available for each of the E-Business Suite 11i releases supported for an upgrade to R12



  • Plan Upgrade to R12
    • Follow the standard R12 upgrade path as documented in the Oracle Applications Upgrade Guide: Release 11i to Release 12. Perform all requirements documented in Chapter 1 and all applicable steps in Chapter 2.
  • Install the R12 Technology Stack and Oracle home
  • Upgrade the Database to
  • Apply Database Patches
  • Apply the database patches as per the metalink note ID 403339.1. (6319846 for Linux)
  • Apply Oracle Service patch 5880762 (conditional)
  • Complete the R12 upgrade
  • Perform the remaining steps in Chapter 3 and all applicable steps in Chapter 4 to complete the upgrade to R12.


  • Plan Upgrade to R12
  • Apply Database Patches
  • Apply the database patches as per the metalink note ID 403339.1. (6319846 for Linux)
  • Apply Oracle Service patch 5880762 (conditional)
  • Complete the R12 upgrade


  • Plan Upgrade to R12
  • Upgrade Database to 10.2.0
  • Continue with the R12 Upgrade or Use the 11i/10.2.0 System
  • Apply Database Patches
  • Apply the database patches as per the metalink note ID 403339.1. (6319846 for Linux)
  • Apply Oracle Service patch 5880762 (conditional)
  • Complete the R12 upgrade

In our case, we are following path C. We were having 11.5.10 + CU2 application with 9i database. We will upgraded the database to 10GR2.

Then we will apply the database patches as per metalink note ID 403339.1 followed by service pack and then will upgrade the application to R12.

Now preparing the application system is till main step # 2 which includes upgrading the database as well. From main step 3, upgrade process for R12 starts. You may wish to stop after carring out the upgrade for database, run your business for some time (may be few months) and then go for R12 upgrade. This gives a comparatively less downtime for your existing application as you dont have to do all at the same time and can be done in steps.

The Upgrade Manual Script (TUMS) examines your current configuration and creates a report that lists upgrade tasks that do not apply to your system. This report contains information that is unique to your system configuration, so its output is relevant to your individual upgrade. Omitting the steps listed in the TUMS report can significantly reduce upgrade downtime.You create the TUMS report by applying a Release 11i patch, which loads objects into your APPS schema that TUMS uses to examine your Applications configuration. Your current Applications environment is not affected.

Below are the list of steps I am mentioning, which are the required steps. I am skipping the conditional steps here, just to make it brief. You can as well check the oracle documentation for the complete steps.

Step 1) Apply latest AD patch level. The latest AD patch is 11i.AD.I.6 and checkin number is 6502082.
SQL> select patch_level from fnd_product_installations
2 where patch_level like ‘%AD%’;


Step 2) Run TUMS utility
– Download and apply TUMS patch (5120936). This will supply you one script “adtums.sql”, which you can run to generate the report.
– To generate the report
cd $AD_TOP/patch/115/sql
sqlplus <APPS username>/<APPS password> @adtums.sql <DIRECTORY>
<DIRECTORY> is where the report file will get generated. You need to create directory in database using create directory command. Also the directory path you are mentioning here should exists in UTL_FILE_DIR.

SQL> create directory APPS_DIR as ‘/usr/tmp’;

Directory created.

[applmgr@ocvmrh2081 sql]$ sqlplus apps/apps @adtums.sql APPS_DIR

step 3) Convert to Multiple Organizations architecture

Step 4) Review sizes of old and new tablespaces

Step 5) Run AD preparation scripts
Download patch 5726010. This will provide 3 scripts adgncons.sql, adgrants_nt.sql, adgrants.sql. Script adgrants_nt.sql is not for Linux and so can be ignored.
– First run the script adgncons.sql. This will create script adcrtbsp.sql. This script (adcrtbsp.sql) creates the new tablespaces, allocates unlimited tablespace to all APPS users, updates fnd_product_installation table with correct data and index tablespace information, assigns default tablespace to all APPS users, and sets the new_ts_mode flag in fnd_product_groups to Y.

[applmgr@ocvmrh2081 5726010]$ sqlplus apps/apps @adgncons.sql apps apps

Run adcrtbsp.sql with system user ID and password from database side

[applmgr@ocvmrh2081 5726010]$ sqlplus system/manager @adcrtbsp.sql

– adgrants.sql will grants SYS privileges needed by Applications, and creates required views in SYS.

You need to run this command “as sysdba”. This will prompt you for FND_ORACLE_USERID owner. You need to enter “applsys” when it prompts.

Step 6) Gather schema statistics for CBO
You can do this by Submitting “Gather Schema Statistics” concurrent request for “ALL” schemas.

Step 7) Backup Database
Take the backup of database before we go further with upgrade process

Step 8 ) Upgrading the database from 9i to 10g. You can refer to upgrade database in Oracle applications 11i post to have detailed steps. The database version should be

Step 9) Prepare the application for upgrade. You need to run the rapid wizard in upgrade mode. This will create the required file system, install the required techstack components. Below are the screen flow for the same.

















After running this wizard, you will find that your existing application is intact and also a new file system has been created for you.

All your services should be up and running. Your 11i application should be intact. You might face an issue, that services (specially Apache) wont come up and your URL wont open. In this case you can check if the services get started from “inst” directory that got created after you run the wizard.

You can go to location /u01/app/applmgr/inst/apps/<TWO_TASK>/admin/scripts and run script from that location. If the services were started from this location, then it will be stopped. Then you can start the services back from $COMMON_TOP/admin/script/<TWO_TASK> location.

Also during running of the wizard configuration information will be written to following files. you can check at your prompt and it will list the configuration files.

Configuration file written to: /u01/app/oracle/db/tech_st/10.2.0/appsutil/conf_PROD.txt
Configuration file written to: /u01/app/applmgr/apps/apps_st/appl/admin/ocvmrh2081/conf_PROD.txt
Configuration file written to: /u01/app/applmgr/inst/apps/PROD_ocvmrh2081/conf_PROD.txt

3) Upgrade Process

Below are the steps for upgrade process from 11.5.10.CU2 to 12.0.0. Till now we have just prepared the application for upgrade. Creating the neccessary filesystem layout and database upgrade was part of preparing for upgrade.

Step 1) Shut down application tier listeners and concurrent managers

Step 2) Back up the database – Once again take a backup. I am not crazy asking backup so many times, but in case we face any issue and if we dont have latest stable backup, we will be helpless.

Step 3) Ensure that Maintenance Mode is enabled – Put your application in maintenance mode

Step 4) Apply Release 12 AD minipack (4502962)
For applying this patch, you need to go in R12 APPL_TOP directory and source the env file present in that APPL_TOP. This is becasue you will be applying this patch to your new APPL_TOP and not 11i APPL_TOP. So make sure to source env file present in new APPL_TOP.

Step 5) Run the American English upgrade patch driver (u4440000.drv)
For applying this patch also, you need to go in R12 APPL_TOP directory and source the env file present in that APPL_TOP.

Step 6) Run the NLS upgrade patch driver (conditional)

For other product related steps and NLS synchronization, please check the Oracle Upgrade docs for 11i to R12.

Step 7) Disable Maintenance Mode

Once these step are carried out last step is finishing the upgrade process. Follow the below steps.

1) generate on appmgr side and copy the same to new ORACLE_HOME. The new ORACLE_HOME directory structure will be created as /u01/app/oracle/db/tech_st/10.2.0
2) unzip in new ORACLE_HOME
3) run autoconfig in new ORACLE_HOME

Once these steps are done, run rapid install again by provding the config file which was generated before. The file location as we noted down before is /u01/app/applmgr/apps/apps_st/appl/admin/ocvmrh2081/conf_PROD.txt

After these steps are performed, the application system will be configured and ready for use. This completes the upgrade activity from 11i to R12.


Metalink Note ID : 394692.1
Metalink Note ID : 403339.1
Metalink Note ID : 396009.1
Metalink Note ID : 329476.1
Metalink Note ID : 215527.1

FNDCPASS – Best Practices and Tricks

In Oracle Application 11i and R12, we have an FND functionality for changing the passwords for either application user, or product schema password or most important – the “APPS” password. The FND binary which will help us is doing these things is FNDCPASS. This is present in $FND_TOP/bin directory.

This post explains the usage of FNDCPASS, best practices that needs to be followed while using FNDCPASS and some tricks when FNDCPASS screws up the instance :))


Below is the usage for FNDCPASS

-bash-2.05b$ FNDCPASS
Usage: FNDCPASS logon 0 Y system/password mode username new_password
where logon is username/password[@connect]
system/password is password of the system account of that database
username is the username where you want to change its password
new_password is the new password in unencrypted format
example FNDCPASS apps/apps 0 Y system/manager SYSTEM APPLSYS WELCOME
FNDCPASS apps/apps 0 Y system/manager ORACLE GL      GL1
FNDCPASS apps/apps 0 Y system/manager USER   VISION  WELCOME

You can just type FNDCPASS and press enter, it will give you these details.

The first usage

FNDCPASS apps/apps 0 Y system/manager SYSTEM APPLSYS WELCOME
is for changing the password for apps and applsys. These are the database schema users (most important for application to work). Password for both these users should be in synch. You can change the password of these users using this command. Note that this is the only way to change the password for apps and applsys. Please do not try any other method for changing apps and applsys password. Oracle recomends using FNDCPASS only to change apps and applsys password. Also note that using this command will change the password for both apps and applsys.

Following activities will take place

(1) applsys validation. (make sure APPLSYS name is correct)
(2) re-encrypt all password in FND_USER
(3) re-encrypt all password in FND_ORACLE_USERID
(4) update applsys’s password in FND_ORACLE_USERID table.
(5) Update apps password in FND_ORACLE_USERID table.

Also changes are made in DBA_USERS table.

The second usage

FNDCPASS apps/apps 0 Y system/manager ORACLE GL      GL1
is for changing password for any other product schema like MSC, GL etc.
Following activities will take place

(1) update GL’s password in FND_ORACLE_USERID table. The new password is re-encrypted with the current applsys password.

If GL does not exists, step (2) below does not happen. Message for invalid oracle user is written in the log file.

(2) alter user to change GL’s password.

The third usage

FNDCPASS apps/apps 0 Y system/manager USER   VISION  WELCOME
is for changing the application level passwords like sysadmin etc used for logging into application.

Following activities will take place

(1) update VISION’s password in FND_USER table. The new password is re-encrypted with the current applsys password.

If VISION does not exist, message for invalid application user is written in the log file.
No products affected by the patch

When you run FNDCPASS command it will check the integrity of all schema password in the application. If any of the password is corrupt then this will through and error and will not change the password.

The tables that it uses is FND_USER and FND_ORACLE_USERID. All the application passwords and schema passwords are stored in these two tables. Ofcourse DBA_USERS will have the schema users and password stored as well.

When we run FNDCPASS it will update all the above 3 tables.

Best practices for using FNDCPASS

Before using FNDCPASS and changing the passwords from default to some thing else, always follow the following best practices.

1) Always, Always, Always keep the back of tables FND_USER and FND_ORACLE_USERID. You can take back of these tables using CREATE TABLE — AS SELECT * FROM —.
You must have backup of these tables before running FNDCPASS. In case if FNDCPASS fails then it might corrupt the passwords of your application and worst can happen that the application wont come up. So always be cautions about this command.

2) If possible also keep an export dump of these two tables.

3) verify each arguement you are providing to FNDCPASS. Like verify that apps and system passwords you are providing is correct.

4) Never update apps, applsys or any schema password directly from database using the alter command. Always use FNDCPASS. System password can be set directly using ALTER command in database.

Issue with APPLSYS and APPS password

Scenario 1:

As you know that apps and applsys password should be in synch and should be changed using FNDCPASS.

There can be situation where a novice user changes applsys password from the backend database. In that case when you try to start the services it will show following error

APP-FND-01496: Cannot access application ORACLE password
Cause: Application Object Library was unable access your ORACLE password.

You can even reproduce this issue (ofcourse after taking the backup of FND_USER and FND_ORACLE_USERID table) using the following steps

1. Use the ALTER USER command to change the APPLSYS password

2. Try to run the script to start Apps services.

3. You will get an error “Cannot complete applications logon. You may have entered an invalid applications password, or there may have been a database connect error.”

4. Then try FNDCPASS to fix password and you will get the error the APP-FND-01496 error.

If this situation happens then you cannot access the application. Infact the services even wont start.

Resolution to such problem is to rollback the 2 tables FND_USER and FND_ORACLE_USERID. Once you rollback the tables, apps and applsys passwords will be in synch and password will be older one. You can then run FNDCPASS and change the password.

Scenario 2:

Some times when you run FNDCPASS, you get following error

APP-FND-01502: Cannot encrypt application ORACLE password
Cause: Application Object Library was unable encrypt your ORACLE password.
Action: Contact your support representative. (ORACLEUSER=APPS_SERV)

The error comes because the table fnd_oracle_userid contain rows for schemas that does not exist. Those rows must be deleted from the table.

Use the following query to get the details of the schema that doest not exists

select * from fnd_oracle_userid
where oracle_username not in
(select username from all_users);

The rows returned by this query can be deleted from FND_ORACLE_USERID table. This will resolve this issue.

Scenario 3:

There can be situation where users has update APPLSYS password using ALTER command in database directly and also you dont have backup of those tables. Under such situation, it is very difficult to recover the application and make it working. Still following methodology is proposed which might help you to restore the password back and make your application work fine.

For this to work you should have some other application (may be debug or UAT) which is having the same passwords or default passwords for schemas. If you have such application the following the below steps in the application which is affected by password mismatch.
This method is for resetting apps and applsys passwords. Below are the SQL statements that will help you reset the APPS and APPLSYS passwords to APPS, the APPLSYSPUB password to PUB, and the SYSADMIN password to SYSADMIN.

WARNING: This procedure will cause all user passwords to become invalid. ALL users passwords will need to be reset through the sysadmin responsibility.

Step 1) Reset the Oracle User IDs

Open a SQL*Plus as SYSTEM and reset the passwords for the APPS, APPLSYS, and the APPLSYSPUB Oracle user ID:


Step 2) Backup the FND_ORACLE_USERID and FND_USER tables (even though these tables are right now corrupted, do take a backup. You can restore the same when ever you want).

Open a SQL*Plus session as APPLSYS and backup the tables:

create table FND_ORACLE_USERID_BAK as (select * from FND_ORACLE_USERID);

create table FND_USER_BAK as (select * from FND_USER);

Step 3) Reset the APPS and APPLSYS application encrypted passwords

Open a SQL*Plus session as APPLSYS and update the FND_ORACLE_USERID table.

set ENCRYPTED_ORACLE_PASSWORD = ‘ZGA34EA20B5C4C9726CC95AA9D49EA4DBA8EDB705CB7673E645EED570D5447161491D78D444554655B87486EF537ED9843C8’

This encrypted string we are updating is the default encrypted string for apps. So if your application is having apps password the encrypted string will look like this. We are updating this encrypted string here directly.

Verify the table update:


Step 4) Reset the APPLSYSPUB application encrypted password

Open a SQL*Plus session as APPLSYS and update the FND_ORACLE_USERID table.


The above encrypted string is the encrypted string for password pub. If your applsyspub password is pub then the encrypted string in FND_ORACLE_USERID will look like this.

Verify the table update:


Once these updates are done, try your luck by running FNDCPASS and it should work fine.

Hope this help !!!


Metalink note ID 445153.1

Metalink note ID 429244.1
Oracle Apps Technology Blog

Cloning Oracle Application 11i Instance


This section will cover the detailed steps required for cloning an 11i instance. Cloning an instance is creating a duplicate of the instance. But this definition is not exactly true, because during cloning we change various details like hostname, SID etc and configure the system as per these new values. But if we see the application data and other techstack versions are exactly same as source instance.

Need for Cloning

Some time situations arise where we have to clone our application system. For example, if we have a production instance and we want to create a test instance or a debug instance, then in that case we can just make a duplicate of production instance by cloning. Test instance is usually used when we want to test some patches before applying into production so as to avoid any unknown downtime for production system. Also some times we face issues in production and we want to reproduce the same error in test and get it fixed in test. Such kind of situations demands test instance.

This post is based on Metalink note ID 230672.1

Environment Information

My environment is 11.5.10.CU2. Database version is
Further details about OA Framework version etc can be seen using following URL

OA Framework Version InformationOA Framework Version
MDS Version (build 481)
UIX Version 2.2.18
BC4J Version

The process

There are 2 major methods for cloning an application system.

1) Cloning Oracle application without rapid clone.

Cloning Oracle Applications Release 11i was originally published in conjunction with Release 11.5.5 and is applicable for all 11i releases up to 11.5.5 that are not AutoConfig enabled.

2) Cloning Oracle application using Rapidclone technology

Cloning Oracle Applications Release 11i with Rapid Clone is applicable for all 11i systems that have migrated to AutoConfig and enabled Rapid Clone. This method contains steps to install AutoConfig and Rapid Clone.

Rapid Clone is the new cloning utility introduced in Release 11.5.8. Rapid Clone leverages the new installation and configuration technology utilized by Rapid Install. See OracleMetaLink Note 230672.1 (Cloning Oracle Applications 11i with Rapid Clone) for instructions on installing and enabling Rapid Clone.

Also there is one more method for cloning Oracle application with autoconfig, but this has been fully replaced by Cloning Oracle application using Rapidclone technology and is no longer supported by Oracle.

We will first discuss the method for cloning an Oracle Application with rapidclone.

With the flexible and sophisticated architecture of Oracle Applications Release 1i, simply copying all of the components will not provide you with a working applications system. For instance, there are numerous configuration files in your file system that must be modified based upon the physical topology. In addition, the Rapid Install installation process utilizes Oracle Universal Installer (OUI), which writes key information about the installation to a binary registry file. When you copy the system to a target location, you invalidate the binary registry file. Consequently, you will not be able to apply patches to the OUI-based

Cloning the application system using rapid clone involves 3 major steps.

  1. Preparing the Source System
  2. Copy the file System to target location
  3. Configuring the target system

Preparing The source file system

Preparing The source file system actually contains 2 sub steps.

  1. Checking the pre-requisites patches
  2. Preparing the source system for cloning.

We will start with checking the pre-requisites for cloning.

1) Make sure that patch 2115451 is applied to the application system. This will create the neccessary perl script. In our case the version of application is 11.5.10CU2, so this patch was already applied.

2) Apply the latest AD Minipack (Apply patch 4712852 (AD.I.4) or higher).
Check the current AD level of your application.

SQL> select PATCH_LEVEL from fnd_product_installations
2  where PATCH_LEVEL like ‘%AD%’;


The latest version of this AD patch is now 11i.AD.I.5. But atleast make the version to 11i.AD.I.4 as mentioned in metalink note ID 230672.1

3) Apply the latest Autoconfig patch to the application. As per the note ID 165195.1 the latest patch for autoconfig is 5985992(JUL/AUG 2007). Please carry out the post install steps properly as mentioned in the README.txt present in the patch directory.

4) Next step is to check if the latest rapid clone patches are applied or not. As per the metalink note ID 230672.1 the latest rapid clone patches are

* 3453499 (11i.ADX.F)
* 5225940 (Post ADX.F Fixes)
* 5972212 (For SLES 10)

SQL> select count(*) from ad_bugs
2  where bug_number = ‘3453499’;


SQL> select count(*) from ad_bugs
2  where bug_number = ‘5225940’;


Third patch is required only if the application is on SLES linux.

5) Run Autoconfig on Application tier as well as on database tier. Make sure you did not encounter any error.

Completing till this step concludes that this environment can be now rapid cloned. We have all latest AD patches and autoconfig patches applied to the environment and also we have all latest rapid clone patches applied to the environment. Now next step is the actual preparation step for cloning the instance. Stay tuned !!

Preparing the source system for cloning

In this step we will prepare the source file system for cloning. This involves gathering the required configuration information. In a broad way this step will create the staged clone directory which will be having the driver files and configuration file of the source.

6) According to metalink note ID 230672.1, preparing the source system consists of preparing the database side and preparing the appltop side. We need to run script on both database side and appltop side. Lets check the details.

6a) Running adpreclone on database side.

[oracle@ocvmrh2122 oracle]$ cd $ORACLE_HOME
[oracle@ocvmrh2122 9.2.0]$ cd appsutil/
[oracle@ocvmrh2122 appsutil]$ cd scripts/
[oracle@ocvmrh2122 scripts]$ cd PROD_ocvmrh2122/
[oracle@ocvmrh2122 PROD_ocvmrh2122]$ ls  adstrtdb.sql  adstopdb.sql
bash-2.05$ ./  dbTier pwd=apps

When we run this command on the database side following things happens.


It will create following directories in the ORACLE_HOME/appsutil/clone

drwxr-xr-x   4 oracle01 oinstall    1024 Dec 31 02:00 jlib
drwxr-xr-x   5 oracle01 oinstall      96 Dec 31 02:00 db
drwxr-xr-x   5 oracle01 oinstall      96 Dec 31 02:00 data

“db” will contain the techstack information, “data” will contain the information related to datafiles and required for cloning.

Creates driver files at ORACLE_HOME/appsutil/driver/instconf.drv
Converts inventory from binary to xml, the xml file is located at $ORACLE_HOME/appsutil/clone/context/db/SCMIDC_ap101fam.xml

Prepare database for cloning:

This includes creating datbase control file script and datafile location information file at

-rwxr-xr-x   1 oracle01 oinstall    4826 Dec 31 02:00 adcrdbclone.sql
-rwxr-xr-x   1 oracle01 oinstall    4508 Dec 31 02:00 dbfinfo.lst
Generates database creation driver file at ORACLE_HOME/appsutil/clone/data/driver

bash-2.05$ ls -rlt
-rw-r–r–   1 oracle01 oinstall     794 Dec 31 02:00 data.drv

Copy JDBC Libraries at ORACLE_HOME/appsutil/clone/jlib/classes12.jar and appsoui

6b) Running adpreclone on appltop side

[applmgr@ocvmrh2122 prodappl]$ cd $COMMON_TOP
[applmgr@ocvmrh2122 prodcomn]$ cd admin/scripts/PROD_ocvmrh2122/
[applmgr@ocvmrh2122 PROD_ocvmrh2122]$ ./ appsTier pwd=apps

This will create stage directory at $COMMON_TOP/clone. This goes into two stages


Creates template files for

Creates Techstack driver files for


APPL_TOP preparation:

-It will create application top driver file

-Copy JDBC libraries

Copy the file System to target location

Once the application system is prepared for cloning. Next thing that you have to do is to bring down database and listener as well (complete application system is down) and copy the whole application to the location, where you want to create a clone.
You need to copy the following components.

On Application side:
<COMMON_TOP>/_pages  (when this directory exists)

On Database side (Do a proper shutdown of database (immediate)):
copy DBF files

Configuring the target system

Once all the copy is done on the target system, you can start your source application system for normal use.
Target system can be configured as given below.

On database side:

cd $ORACLE_HOME/appsutils/clone/bin
perl dbTier pwd=apps

This will use the templates and driver files those where created while running on source system and has been copied to target system.

Following scripts are run by for configuring techstack

  • — This will check the system for ld, ar, cc, and make versions.
  • — This will clone the context file. Because when we copy the application files from source system to target system, we also copy the context file. But this context file wont be of use here. So we need to create a new context file as per the details of this instance. Here hostname, ports and other details will change.
  • runInstallConfigDriver — located in $Oracle_Home/appsutil/driver/instconf.drv
  • Relinking $Oracle_Home/appsutil/install/ — This will relink ORACLE_HOME

For data on database side, following scripts are run

  • Driver file $Oracle_Home/appsutil/clone/context/data/driver/data.drv
  • Create database
  • Autoconfig is run
  •  Control file creation adcrdbclone.sql

On Application Side:

COMMON_TOP/clone/bin/perl appsTier pwd=apps

Following scripts are run by

Creates context file for target

Run driver files

Relinking of Oracle Home

At the end it will run the driver file $COMMON_TOP/clone/appl/driver/appl.drv and then runs autoconfig.


Metalink Note ID: 216664.1 – Frequently Asked Questions Cloning Oracle Applications 11i

Metalink Note ID: 230672.1 – Cloning Oracle Applications Release 11i with Rapid Clone