Steps to Complete a Clone in Release 12.2 – Part 8

Log File Locations

Different logs are created for Run Edition and Patch Edition Cloning. The log files are created in the following directories in the Run Edition File System:

<INST_TOP>/admin/log/clone/run

<INST_TOP>/admin/log/clone/patch

Potential Issues

  • Per the instructions in MOS Doc. ID: 1383621.1, Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone:

If the database version is 12c Release 1, you must add the following line in your sqlnet_ifile.ora after adcfgclone.pl execution completes:

SQLNET.ALLOWED_LOGON_VERSION_SERVER = 8 (if the initialization parameter SEC_CASE_SENSITIVE_LOGON is set to FALSE)

SQLNET.ALLOWED_LOGON_VERSION_SERVER = 10 (if SEC_CASE_SENSITIVE_LOGON is set to TRUE)

  • Don’t use a HOSTNAME in UPPER CASE.

Bug 23343062 – Incorrect Patch File System context file with dualfs option when hostname is in uppercase

On a host with uppercase name, the dualfs option of Cloning may result in the context name and context file name being out of sync between the Run and Patch File System. This can happen if the context name or other context variables containing hostname are specified in the pairsfile with the host value in upper case. For example, on host TEST_HOST with database SID prod, if the pairsfile contains the entry s_contextname=prod_TEST_HOST, the Run File System context name and context file name will be set to prod_TEST_HOST and prod_TEST_HOST.xml respectively while the Patch File System context name and context file name will be set to prod_test_host and prod_test_host.xml respectively. This will lead to validation errors during adop execution. To avoid this issue, in case the s_contextname or other context variables containing the hostname are specified in the pairsfile, the specified value should always have the host in lower case.

  • One recent change that came from either a CPU patch or AD-TXK patch affects cloning. You now need to create an etcc directory under the database Oracle Home, $ORACLE_HOME/appsutil/etcc.

From MOS Doc. ID: 1383621.1, Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone:

“Run EBS Technology Codelevel Checker (ETCC) on the database tier.

On the database tier, run the EBS Technology Codelevel Checker (ETCC) described in MOS Doc. ID: 1594274.1, Oracle E-Business Suite Release 12.2: Consolidated List of Patches and Technology Bug Fixes to confirm that all required database patches have been applied. EBS Technology Codelevel Checker (ETCC) is available via Patch 17537119 and analyzes an Oracle Database Oracle Home, and warns of any missing database bug fixes required for Oracle E-Business Suite Release 12.2. It is run with the command checkDBpatch.sh (on UNIX) or checkDBpatch.cmd (on Windows). Further instructions are available in the patch readme. Ensure to install the latest version of ETCC into the directory:

 <RDBMS_ORACLE_HOME>/appsutil/etcc

Cloning/Patching Nuances

  1. Before cloning a system with Rapid Clone, be sure to allow any active online patching cycles to run all the way through the final (cleanup) phase. In case patches are applied in Hotpatch or Downtime Mode, then you must run the cleanup phase of adop. Review Oracle E-Business Suite Maintenance Guide.
  2. Then run fs_clone to synchronize with the other file system, to avoid the need for synchronization to be performed in the next patching cycle. For more information, review Oracle E-Business Suite Maintenance Guide.
  3. A global (central) inventory is generally recommended for all Oracle E-Business Suite Release 12.2 application tier nodes and database tier nodes.

Steps to Complete a Clone in Release 12.2 – Part 7b

6.2 RUN ADPRECLONE ON RUN EDITION 

Run adpreclone.pl on the run edition file system in the Target System.

$ cd $ADMIN_SCRIPTS_HOME

$ adpreclone.pl appsTier

**require Apps User password and Weblogic AdminServer password

6.3 SHUTDOWN THE APPLICATION TIER PROCESSES

cd $ADMIN_SCRIPTS_HOME

./adstpall.sh apps/<apps_password>
**require Apps User password and Weblogic AdminServer password

6.4 Copy Target Run Edition Over Target Patch Edition

Now we need to copy the EBSapps directory from the run edition file system to the patch edition file system on the target application server.

Create the TARGET PATCH EDITION file system (in our case $ORACLE_HOME/<TARGET_DB_SID>/fs2), if it does not already exist:

cd $ORACLE_BASE
mkdir fs2
cd ./fs1
tar –cvf EBSapps.tar EBSapps
mv EBSapps.tar ../fs2
cd ../fs2
tar –xvf EBSapps.tar

Once this is complete, remove the TAR file:
rm –fr EBSapps.tar

IMPORTANT! – Unset the application environment if it set. This is done by logging out of the OS and logging back in making sure not to set the EBS environment.

$ cd $ORACLE_HOME/<TARGET_DB_SID>/fs2

6.5 Run ADCFGCLONE on Target Application Node on Patch Edition

The patch edition file system uses the RUN edition context XML file. At the prompt “Location of Run System Context File”, enter the absolute path to the context file for the run edition file system that was created in the previous step:

In our environment, the path is:
$ORACLE_HOME/<TARGET_DB_SID>/fs1/inst/apps/<TARGET_DB_SID>_apps1/appl/admin/<TARGET_DB_SID>_apps1.xml

Also the PATCH file system port pool MUST be different than RUN file system port pool (0).

Log on to the patch edition file system in the Target System as the applmgr user and enter the following commands:

$ cd $ORACLE_HOME/<TARGET_DB_SID>/fs2/EBSapps/

comn/clone/bin

$ perl adcfgclone.pl appsTier

                   Copyright (c) 2002, 2015 Oracle Corporation

             Redwood Shores, California, USA

          Oracle E-Business Suite Rapid Clone

                   Version 12.2

          adcfgclone Version 120.63.12020000.56

                ***********************************************************

In AD-TXK Delta 7, we recommend you clone the run and patch file systems in a single operation using the ‘dualfs’ option.

Separate cloning of the run and patch file systems will be deprecated

                ************************************************************

Enter the APPS password :

Enter the Weblogic AdminServer password :

Do you want to add a node (yes/no) [no] :

Running: Context clone…

Log file located at $ORACLE_HOME/<TARGET_DB_SID>/fs2/EBSapps/comn/clone/bin/CloneContext_1230145305.log

Target System File Edition type [run] : patch

Enter the full path of Run File System Context file : $ORACLE_HOME/<TARGET_DB_SID>/fs1/inst/apps/<TARGET_DB_SID>_apps1/appl/admin/<TARGET_DB_SID>_apps1.xml

Provide the values required for creation of the new APPL_TOP Context file.

Target System Fusion Middleware Home set to $ORACLE_HOME/<TARGET_DB_SID>/fs2/FMW_Home

Target System Web Oracle Home set to $ORACLE_HOME/<TARGET_DB_SID>/fs2/FMW_Home/webtier

Target System Appl TOP set to $ORACLE_HOME/<TARGET_DB_SID>/fs2/EBSapps/appl

Target System COMMON TOP set to $ORACLE_HOME/<TARGET_DB_SID>/fs2/EBSapps/comn

Target System Instance Top set to $ORACLE_HOME/<TARGET_DB_SID>/fs2/inst/apps/<TARGET_DB_SID>_apps1

Target System Port Pool [0-99] : 1

Checking the port pool 1

done: Port Pool 1 is free

UTL_FILE_DIR on database tier consists of the following directories.

1. /usr/tmp

2. /usr/tmp

3. $ORACLE_HOME/<TARGET_DB_SID>/12.1.0/appsutil/

outbound/<TARGET_DB_SID>_data1

4. /usr/tmp

Choose a value which will be set as APPLPTMP value on the target node [1] : 1

6.6 Start Application from Run File System and Review

Set RUN file system environment:

. ~/EBSapps.env

Make sure to select the RUN file system when prompted.

Start Application:

$ cd $ADMIN_SCRIPTS_HOME

$ ./ adstrtal.sh

**require Apps User password and Weblogic AdminServer password

From EBS side you can do these checks:

  1. Login to the application. Check that Apache, forms sessions are coming up.
  2. Run Synchronize views for Oracle Workflow

Request Name = Workflow Directory Services User/Role Validation

p_BatchSize = 10000

p_Check_Dangling = Yes

Add missing user/role assignments = Yes

Update WHO columns in WF tables = No

  • Check Concurrent Manager processes.
  • Run a simple Concurrent Program (like the Active Users report). Check if output and log files can be opened.
  • If required, purge old log/out files from $APPLCSF/$APPLLOG and $APPLCSF/$APPLOUT directories as you may find that the output/log files have old dates.

Steps to Complete a Clone in Release 12.2 – Part 7a

Part 4: Copy Database Tier Node

For copying the database tier node from source to target database you can always follow the easiest approach of copying the database files from source to target database by first shutting down the source database system. But not all DBAs have the luxury of taking down their Production database at will to refresh a non-production database.

4.1 Stop Target Database – If Required

Login to the target Database node as the oracle software user.

$ sqlplus / as sysdba

SQL> shutdown immediate

4.2 Cleanup Target Database File

Delete all target data files.

Use a simple rm –rf command to delete these database files

4.3 Restore Your Production Database to the Target Database Server Using the Method of Your Choice

Part 5: Configure Target Database System

Log on to the Target System as the oracle user and enter the following commands to configure the adcfgclone dbTechStack

$ cd [RDBMS ORACLE_HOME]/appsutil/clone/bin

$ perl adcfgclone.pl dbTechStack

The log file is created in the <RDBMS_ORACLE_HOME>/appsutil/log/<CONTEXT_NAME> directory.

Answer the adcfgclone script questions and allow the script to run to completion.

5.1 De-Register the Production Nodes from the Configuration

As the APPS user, run the following command to de-register the current configuration:

Login from the target database node as the APPS user:

$ sqlplus apps/<PASSWORD>

SQL> exec fnd_conc_clone.setup_clean;

PL/SQL procedure successfully completed.

SQL> commit;

Commit complete.

5.2 Execute Autoconfig on Target Database Node

On the target database node from the $ORACLE_HOME/appsutil/bin directory, execute AutoConfig on the database tier by running the adconfig.pl script.

$ cd $ORACLE_HOME/appsutil/bin
$ perl adconfig.pl dbTier

Check the AutoConfig log for any errors.

Also check the CONTEXT_FILE that was generated under $ORACLE_HOME/appsutil

Part 6: Configure Target Application System

Configuring the target system changes instance settings from the source settings to the target settings that match the target hostname, target instance name, SID, paths and ports.

NOTES:

  • At the prompt Do you want to add a node (yes/no), enter the value no.
  • At the prompt: Target System Base Directory, enter the location of the base directory. For example: /u01/oracle/VIS.
  • Provide the new port pools for the Run Edition File System and the Patch Edition File System.
  • When asked the question Do you want to startup the Application Services for <TWO_TASK>? (y/n) you should answer y if you do not need to perform any further actions and n if there are other pending actions that need the Application services to be down.

6.1 Run ADCFGCLONE on Target Application Node Run Edition

Login to the Application node as the OS Apps user.

$ cd $COMMON_TOP/clone/bin

Example :

$ cd $ORACLE_HOME/<TARGET_DB_SID>/fs1/EBSapps/comn/

clone/bin

$ perl adcfgclone.pl appsTier

**This step requires the Apps User password AND the Weblogic Server Admin password

perl adcfgclone.pl appsTier

      Copyright (c) 2002, 2015 Oracle Corporation

             Redwood Shores, California, USA

            Oracle E-Business Suite Rapid Clone

                      Version 12.2

         adcfgclone Version 120.63.12020000.56

               ****************************************************

In AD-TXK Delta 7, we recommend you clone the run and patch file systems in a single operation using the ‘dualfs’ option.

Separate cloning of the run and patch file systems will be deprecated

                ***************************************************

Enter the APPS password :

Enter the Weblogic AdminServer password :

Do you want to add a node (yes/no) [no] :

Running: Context clone…

Log file located at $ORACLE_HOME/<TARGET_DB_SID>/fs1/EBSapps/comn/clone/bin/CloneContext_1230123711.log

Target System File Edition type [run] :

Provide the values required for creation of the new APPL_TOP Context file.

Target System Hostname (virtual or normal) [apps1] :

Target System Database SID : <TARGET_DB_SID>

Target System Database Server Node [apps1] : data1

Target System Database Domain Name [dg.local] :

Target System Base Directory : $ORACLE_HOME/<TARGET_DB_SID>

Target System Base Directory set to $ORACLE_HOME/<TARGET_DB_SID>

Target System Current File System Base set to $ORACLE_HOME/<TARGET_DB_SID>/fs1

Target System Other File System Base set to $ORACLE_HOME/<TARGET_DB_SID>/fs2

Target System Fusion Middleware Home set to $ORACLE_HOME/<TARGET_DB_SID>/fs1/FMW_Home

Target System Web Oracle Home set to $ORACLE_HOME/<TARGET_DB_SID>/fs1/FMW_Home/webtier

Target System Appl TOP set to $ORACLE_HOME/<TARGET_DB_SID>/fs1/EBSapps/appl

Target System COMMON TOP set to $ORACLE_HOME/<TARGET_DB_SID>/fs1/EBSapps/comn

Target System Instance Home Directory [$ORACLE_HOME/<TARGET_DB_SID>] :

Target System Instance Top set to $ORACLE_HOME/<TARGET_DB_SID>/fs1/inst/apps/<TARGET_DB_SID>_apps1

Do you want to preserve the Display [<Target_App_Server>:0.0] (y/n)  : n

Target System Display [apps1:0.0] : :1

Target System Root Service [enabled] :

Target System Web Entry Point Services [enabled] :

Target System Web Application Services [enabled] :

Target System Batch Processing Services [enabled] :

Target System Other Services [disabled] :

Do you want the target system to have the same port values as the source system (y/n) [y] ? : n

Target System Port Pool [0-99] : 0

Checking the port pool 0

done: Port Pool 0 is free

Report file located at $ORACLE_HOME/<TARGET_DB_SID>/fs1/inst/apps/<TARGET_DB_SID>_apps1/admin/out/portpool.lst

UTL_FILE_DIR on database tier consists of the following directories.

1. /usr/tmp

2. /usr/tmp

3. $ORACLE_HOME/<TARGET_DB_SID>/12.1.0/appsutil/outbound/<TARGET_DB_SID>_data1

4. /usr/tmp

Choose a value which will be set as APPLPTMP value on the target node [1] : 1

Steps to Complete a Clone in Release 12.2 – Part 6

Part 3: Copy Application Node Data

The Application tier copy process is different in R12.2 compared to a R12.1.3 environment. In R12.2 we have two file systems, RUN and PATCH. During the copy process, we only need to copy the RUN file system.

3.1 Clone and Configure the Application Tier

Use the following instructions from MOS Doc. ID: 2552208.1, Cloning Oracle E-Business Suite Release 12.2 with Multitenant Database using Rapid Clone to clone and configure the application tier.

3.1.1 Copy the Application Tier File System from the Source Node to the Target Node:

Copy the application tier file system from the source node to the target node by running the following steps in the order listed. Ensure the application tier files copied to the target system are owned by the target applmgr user.

Before you begin, verify the permissions of the executables under ORACLE_HOME/bin that can potentially be owned by root, such as nmonmhs, and nmb and change the owner to the target applmgr user.

Note: In the copying tasks below, UNIX users should ensure that the symbolic links (soft links) are preserved when copying. On most UNIX platforms, you can accomplish this with the cp -prfH command. Consult the UNIX man page for the cp command to check the parameters available on your platform.

For example:
$ cd /Target_dest_dir/apps
$ cp -prfH /Source_dir/apps/.

Alternatively, you can use the tar command to compress the directories into a temporary staging area. UNIX users should ensure that the symbolic links (soft links) are preserved when compressing. On most UNIX platforms, this is the default behavior of the tar command. Consult the UNIX main page for the tar command to review the parameters available for your platform.

  1. Log on to run edition file system in the source system application tier nodes as the applmgr user.
  2. Copy the following application tier directories from the source node to the target run edition file system application tier node:
  • <APPL_TOP>
  • <COMMON_TOP>
  • <OracleAS Tools 10.1.2 ORACLE_HOME>

The same operating system user must own both the run edition and patch edition file systems.
 

Note: In Release 12.2, you can set the base directory to any desired location. However, the subdirectory structure cannot be changed because of dependencies on both the WLS domain and the dual file system required for online patching. Also, the base directory must be the same across all nodes in multi-node configurations.

3.1.2 Dual File System Directory Structure

In Oracle E-Business Suite Release 12.2, the following directory structure exists to support the run edition and patch edition file systems:

Note: <s_base> and <sid> are user-defined values.

<s_base>/<sid>/fs1 (for example, /u01/122/prod/fs1)

<s_base>/<sid>/fs2 (for example, /u01/122/prod/fs2)

Two environment variables, $RUN_BASE and $PATCH_BASE, store these locations. The role (run or patch) of these two file systems switches every time a cutover phase completes.

Note: As Rapid Clone will create a replica of the source node, if the source run edition file system is the first file system (fs1), the target run edition file system will also be the first file system (fs1). Similarly, if the source run edition file system is the second file system (fs2), then the target run edition file system will also be the second file system (fs2). Therefore, when you perform a cloning task, you always clone and copy the source run edition file system to create the target run edition file system, but the directory location of the run edition file system can be pointing either to <s_base>/<sid>/fs1 or <s_base>/<sid>/fs2 based on the source run edition file system base directory.

When copying the files, use the values of $RUN_BASE and $PATCH_BASE variables to determine if the run edition file system should be copied to fs1 or fs2.

For example, the source run edition file system has the following values:

$RUN_BASE=/u01/122/prod/fs2
$PATCH_BASE=/u01/122/prod/fs1

The target <s_base> directory will be /d05/test. Copy the source run edition file system into the target /d05/test/fs2 directory to initially act as run edition file system.

3.2 Configure the Target System Application Tier Nodes

Note: If adcfgclone.pl is being run again after a failure, before a new cloning attempt you must run the steps in Appendix A of MOS Doc. ID:1383621.1, Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone.

  1. Log on to the run edition file system in the target system as the applmgr user and enter the following commands:

cd <COMMON_TOP>/clone/bin
perl adcfgclone.pl appsTier dualfs

  • When prompted for the following, answer as shown:
  • “Do you want to add a node (yes/no)”, enter a value of ‘no’.
  • Target System Database SID, enter the name of the EBS pluggable database.
  • “Target System Base Directory”, enter the location of the base directory. For example: /u02/r122.
  • Provide the new port pools for the run edition file system and the patch edition file system.
  • “Do you want to startup the Application Services for <TWO_TASK>? (y/n)” you should answer ‘y‘ if you do not need to perform any further actions and ‘n‘ if there are other pending actions which need the application services to be down.


Different logs are created for run edition and patch edition cloning. Log files are created in the following directories in the run edition file system:

  • <INST_TOP>/admin/log/clone/run
  • <INST_TOP>/admin/log/clone/patch
  • If the April 2019 CPU patch (or later) is applied to the Oracle E-Business Suite instance, refer to Appendix B of MOS Doc. ID: 1383621.1, Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone, to enable access to the WebLogic Admin console from hosts other than the application tier nodes.
  • To complete the configuration on the primary application tier node, run the finishing tasks as listed in Section 4 of MOS Doc. ID: 1383621.1, Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone.
  • If you want to add secondary application tier nodes, run the steps in Section 5.3 of MOS Doc. ID: 1383621.1, Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone.

3.3 Source Application Tier Data Copy Process

  • Copy the Application Tier File System from the Source Run Edition File System to the Target Run Edition File System.
  • Log on to the Run Edition File System on the Source System application tier nodes as the applmgr user.
  • The next step is important: only copy the directories listed. Copy the following application tier directories from the Source Node to the Target Run Edition File System application tier node:

The EBSapps directory contains:

<APPL_TOP>
<COMMON_TOP>
<OracleAS Tools 10.1.2 ORACLE_HOME>

The EBSapps directory needs to be copied to the target file system ($RUN_BASE).

[<OS Apps User>@<Target_App_Server> fs1]$ pwd

$ORACLE_HOME/<SOURCE DB SID>/fs1

[<OS Apps User>@<Target_App_Server> fs1]$ ll

total 12

drwxrwxr-x.  5 <OS Apps User> dba 4096 Oct 19  2016 EBSapps      ßCOPY THIS FILE SYSTEM

drwxrwxr-x. 11 <OS Apps User> dba 4096 Dec 25  2016 FMW_Home           ß DO NOT COPY

drwxrwxr-x.  3 <OS Apps User> dba 4096 Oct 19  2016 inst               ß DO NOT COPY

[<OS Apps User>@<Target_App_Server> fs1]$

3.4 Cleanup Target Application File System

  • Remove all data under the application directory structure on the target if required.
  • COPY APPS FILESYSTEM BACKUP FROM SOURCE TO TARGET
  • RESTORE THE APPS FILESYSTEM ON TARGET NODE
  • Extract the backup to the target destination

Example: (If using the COLD BACK-UP method (Linux tar command)

$ nohup tar xvfz /tmp/dba_apps_22apr13.tar.gz &

Steps to Complete a Clone in Release 12.2 – Part 5

2.6 Clone and Configure Target Single-Node Database from an Oracle RAC Database Source

It is possible to clone from an Oracle RAC-enabled Oracle E-Business Suite (source) environment to a single instance Oracle E-Business Suite (target) environment following nearly the same process detailed above for a target single-node database.

While entering values to the prompts during the run of adclonectx.pl, disregard any references to secondary node configuration as they will not apply here.

For example:

Target Instance is RAC (y/n) [y] : n

Because you are cloning the context file from an Oracle RAC enabled source system, the interview question above pre-selects a default value of being an Oracle RAC Instance. Ensure you answer “N” to the above question. By creating a context file without Oracle RAC attributes present, Rapid Clone will configure and convert the database technology stack and its binaries on the target system such that a Single Instance restore can be performed.

All other steps remain the same as in Section 2.1.

The final step is to edit the init<sid>.ora file and remove the duplicate entries for aq_tm_processes and job_queue_processes (which are set to 0). Ensure you restart the database after you make these changes.

Note: In an Oracle RAC to single instance cloning scenario, no changes are made to the database regarding undo tablespaces or redo log groups or members. These data structures will therefore be as if they were present in the source system Oracle RAC database. Optionally, you may decide to reduce the complexity that was carried over from the source Oracle RAC environment to the single instance.

Steps to Complete a Clone in Release 12.2 – Part 4

2.5 Clone and Configure the Target System Secondary Database Nodes (Clone Additional Nodes)

This section is optional as it only applies when the target database is an Oracle RAC database.

Use the following steps to clone the secondary nodes (for example, Node 2) on to the target system.

2.5.1 Add Secondary Oracle RAC Node Information to sqlnet.ora

This is a two-node Oracle RAC example.

  1. Go to the primary node and add the secondary node information to the sqlnet.ora file:

    RAC node 1: host1.example.com
RAC node 1 vip: host1-vip.example.com
RAC node 2: host2.example.com
RAC node 2 vip: host2-vip.example.com

  • Open the  $ORACLE_HOME/network/admin/<context>/sqlnet.ora file for editing and add the Oracle RAC Node 2 information by changing the line shown.

    FROM:

tcp.invited_nodes=(host1.example.com, host1-vip.example.com)

    TO:

tcp.invited_nodes=(host1.example.com, host1-vip.example.com, host2.example.com, host2-vip.example.com)

  • Then reload the listener to reflect the change.

Note: The host1 entries should be already there in the sqlnet.ora after a successful clone of Oracle RAC Node 1.

2.5.2 Uncompress the Archived ORACLE_HOME Transferred from Source System

Uncompress the source system ORACLE_HOME archive to a location matching that on your target system primary node. The directory structure should match that present on the newly created target system primary node.

tar -xvzf rac_db_oh.tgz

2.5.3 Archive <ORACLE_HOME>/appsutil Directory Structure from New Primary Node

Log in to the new target system primary node, and run the following commands:

cd <ORACLE_HOME>

zip -r appsutil_node1.zip appsutil

2.5.4 Copy appsutil_node1.zip to the Secondary Target Node

Transfer and then expand the appsutil_node1.zip into the secondary target Oracle RAC node <NEW ORACLE_HOME>.

cd <NEW ORACLE_HOME>
unzip -o appsutil_node1.zip

2.5.5 Update pairsfile.txt for Secondary Target Node

Alter the existing pairsfile.txt (from the first target node) and change the s_undo_tablespace parameter.

The <NEW_ORACLE_HOME>/appsutils/clone/pairsfile.txt will look like this example:

s_undo_tablespace=<Source system secondary node undo tablespace name>
s_dbClusterInst=<Total number of Instances in a cluster e.g. 2>
s_db_oh=<Location of new ORACLE_HOME>

2.5.6 Create Context File for Secondary Node

Navigate to <ORACLE_HOME>/appsutil/clone/bin and run the adclonectx.pl utility as follows:

$cd <ORACLE_HOME>/appsutil/clone/bin
$perl adclonectx.pl \
contextfile=<Full Path to Existing Context File on First Node> \
template=<ORACLE_HOME>/appsutil/template/adxdbctx.tmp \
pairsfile=<ORACLE_HOME>/appsutil/clone/pairsfile.txt addnode

Where:

ParameterDescription
contextfileAbsolute path to the existing context file from the first (primary) node.
TemplateAbsolute path to the existing database context file template.
PairsfileAbsolute path to the pairsfile created in last step.

Several of the interview prompts are the same as on Node 1. However, there are some new questions which are specific to the “addnode” option used when on the second node.

Note: When answering the following questions, review your responses carefully before entering them. The rest of the inputs (not shown) are the same as those encountered during the context file creation on the initial node (primary node).

Target Instance is RAC (y/n) [y] : y
Please provide the details to connect to one of live RAC nodes
Host name of the live RAC node : <Hostname of RAC Node 1>
Domain name of the live RAC node : <Domain name of RAC Node 1>
Database SID of the live RAC node : <PDB name>
Listener port number of the live RAC node : <Database Listener port of RAC Node 1>
Provide information for the new Node:
Host name :
Virtual Host name : <Virtual hostname of current node>
Instance number : 2
Private interconnect name : <Private interconnect name>
Current Node:
Host Name : <Current hostname>
SID : <PDB Name>
Instance Name : <CDB Instance name>
Instance Number : 2
Instance Thread : 2
Undo Table Space: <Undo tablespace name, if set>
Listener Port : <DB Listener port provided in above prompt>

Notes:

  • At the conclusion of these “interview” questions related to the context file creation, look carefully at the generated context file and ensure that the values contained therein compare to the values entered during context file creation on Node 1. The values should be almost identical, a small but important exception being the local instance name will have a number 2 instead of a 1.
  • The value of the context variables  s_db_util_filedirs_ecx_log_dirs_bis_debug_log_dir, and s_outbound_dir will be retained from Node 1. Hence, review these directory paths and ensure that these directories are accessible on the current node.
  • Verify that the value of the context variable s_undotablespace is set correctly in the context file. If not, you must edit it manually.

2.5.7 Configure Oracle Home

Run the commands below to move to the correct directory and continue the cloning process:

cd <ORACLE_HOME>/appsutil/clone/bin
$perl adcfgclone.pl dbTechStack <Full path to the database context file created in previous step>

Note: Ensure to add the following line in your sqlnet_ifile.ora after the adcfgclone.pl run completes:  .ALLOWED_LOGON_VERSION_SERVER = 10 (since SEC_CASE_SENSITIVE_LOGON is set to TRUE)

Note: If this secondary node uses Oracle ASM with database job role separation, run the following commands as the grid user to set correct permissions and group for the oracle executable in the database Oracle home.

$ cd <Grid Home>/bin
$ ./setasmgidwrap o=<ORACLE_HOME>/bin/oracle

2.5.8 Create the listener.ora and tnsnames.ora Files for the Target CDB

Create the listener.ora and tnsnames.ora files for the target CDB by running the following commands:

cd <ORACLE_HOME>/appsutil
source ./txkSetCfgCDB.env -dboraclehome=<ORACLE_HOME>
cd <ORACLE_HOME>/appsutil/bin
$perl txkGenCDBTnsAdmin.pl -dboraclehome=<ORACLE_HOME> -cdbname=<Name of the target container database> \
-cdbsid=<SID of the target container database> -dbport=<Target DB port> -outdir=$ORACLE_HOME/appsutil/log \
-israc=<yes/no> [-virtualhostname=<virtual hostname>]

2.5.9 Source the New Environment File in ORACLE_HOME

Run the commands below to move to the correct directory and source the environment:

cd <NEW ORACLE_HOME>
source <CDB_SID>_<Hostname>.env

2.5.10 Start the Oracle RAC Database

  1. Create the init file or spfile for the secondary database node, as desired.
  2. Start the target container database using the following commands:

$export ORACLE_SID=<CDB SID>
$sqlplus / as sysdba
SQL>startup

  • Startup the pluggable database and save its state by running the following command:

$export ORACLE_SID=<CDB SID>
$sqlplus / as sysdba
SQL>alter pluggable database all open instances=all; (if an Oracle RAC database)
SQL>alter pluggable database all save state instances=all;

2.5.11 Set the UTL_FILE_DIR value

  1. Run the following command to create the directory object for the outbound directory (pointed to by the s_outbound_dir context variable in the database tier context file).

cd <ORACLE_HOME>
source <CONTEXT_NAME>.env
perl <ORACLE_HOME>/appsutil/bin/txkCfgUtlfileDir.pl -contextfile=<CONTEXT_FILE> \
-oraclehome=<ORACLE_HOME> -outdir=<ORACLE_HOME>/appsutil/log -mode=createDirObject

       When prompted for the OS path for the directory object to be created, enter the value of the s_outbound_dir context variable in the database tier context file.

       Note: Ensure that the directory path set for the s_outbound_dir  value already exists on the node. If not, create the directory before running the above step.

  • Sync up the value of UTL_FILE_DIR in the database tier context file by running the following command:

perl <ORACLE_HOME>/appsutil/bin/txkCfgUtlfileDir.pl -contextfile=<CONTEXT_FILE> \
-oraclehome=<ORACLE_HOME> -outdir=<ORACLE_HOME>/appsutil/log -mode=syncUtlFileDir \
-skipautoconfig=yes

2.5.12 Run AutoConfig

Run AutoConfig to generate the correct listener.ora and  tnsnames.ora files:

$cd <ORACLE_HOME>/appsutil/scripts/<CONTEXT_NAME>
$./adautocfg.sh

If AutoConfig fails and you see any type of “TNS” errors in the AutoConfig log files, you should ensure the listeners are registered properly. After doing so, re-run AutoConfig on the second node.

2.5.13 Carry Out Target System (Primary Node) Final Oracle RAC Configuration Tasks

2.5.13.1 Recreate the listener.ora and tnsnames.ora Files

Log in to the target primary node (Node 1) and run AutoConfig to perform the final Oracle RAC configuration. Create a new listener.ora and  tnsnames.ora file for the PDB. This is needed as the FND_NODES table did not contain the second node host name until AutoConfig was run on the secondary target Oracle RAC node.

$cd <ORACLE_HOME>/appsutil/scripts/<CONTEXT_NAME>
$./adautocfg.sh

Note: This AutoConfig run on the primary target Oracle RAC Node 1 will add the second Oracle RAC Node connection information to the first node’s  tnsnames.ora, such that listener load balancing can occur. If you have more than two nodes in your new target system cluster, you must repeat Section 4.2 and Section 4.3 for all subsequent nodes.

Steps to Complete a Clone in Release 12.2 – Part 3

2.4.3 Create the Context File for a Single-Node Database

Run the adclonectx.pl utility to create a new target context file.

$cd <NEW ORACLE_HOME>/appsutil/clone/bin
$perl adclonectx.pl \
contextfile=<Source database context file>\
template=<NEW ORACLE_HOME>/appsutil/template/adxdbctx.tmp \
[pairsfile=<generated Pairs file>]

2.4.4 Configure the Database Technology Stack

Configure the database technology stack copied by running the following steps:

  1. Go to <ORACLE_HOME>/appsutil/clone/bin 
  2. run Rapid Clone adcfgclone.pl utility:

$perl adcfgclone.pl dbTechStack <Complete path to the target context file>

Because the database is not restored, database connections will fail.

The above command will also create the directory <s_outbound_dir>. Make sure the value of the <s_outbound_dir> is set correctly before running the above command.

You may need to create the directory manually or change the  <s_outbound_dir> context variable to resolve the issue.

If your EBS database tier is on AIX platform, make sure that you have run the <ORACLE_HOME>/clone/rootpre.sh script and set the environment variable ROOTPRE_EXECUTED to ‘Y‘ before running the above command.

2.4.5 Create the listener.ora and tnsnames.ora for the Target CDB Database

  1. Set the environment.

cd <ORACLE_HOME>/appsutil
$source ./txkSetCfgCDB.env -dboraclehome=<ORACLE_HOME>

  • Generate the listener.ora and tnsnames.ora.

cd <ORACLE_HOME>/appsutil/bin
$perl txkGenCDBTnsAdmin.pl -dboraclehome=<ORACLE_HOME> -cdbname=<Name of the target container database> \
-cdbsid=<SID of the target container database> -dbport=<Target DB port> -outdir=$ORACLE_HOME/appsutil/log \
-israc=<yes/no> [-virtualhostname=<virtual hostname>]

  • Start the listener for the target container database as follows:

    $ cd <ORACLE_HOME>/appsutil/scripts/<CONTEXT_NAME>
    $ ./adcdblnctl.sh start <CDB SID>

2.4.6 Restore and Start the Target Database

1.    Copy and restore the database using your preferred method, such as RMAN restore or SAN snapshot.

  • The database initialization file and control files also need to be restored from the source manually.
  • The database initialization parameters should be updated to have values specific to the target. Ensure that the service_names parameter is also updated to refer to the target CDB name.
  • Start the new target CDB in open mode.

Note: To register the database with the clusterware, follow the instructions in Appendix A of MOS Doc. ID: 1679270.1, Cloning Oracle E-Business Suite Release 12.2 RAC Enabled Systems with Rapid Clone.

  • Set the environment variable ORACLE_SID to the CDB SID :

    export ORACLE_SID=<CDB SID>
  • If the Target PDB name needs to be changed to a value different from the Source PDB Name, perform the following:
    • Verify if any service already exists with the Target PDB name.

      Run the following commands:

$sqlplus / as sysdba
SQL>alter session set container=<SOURCEPDB_NAME>”;
SQL>select count(*) from cdb_services c, service$ s
where upper(s.name) = upper(‘<TARGETPDB_NAME>’)
and s.deletion_date is null
and s.name = c.name;

  • If any service already exists with the Target PDB name, delete it as follows:

sqlplus / as sysdba
SQL> alter session set container=”<SOURCE PDB_NAME>”;
SQL> dbms_service.delete_service(‘<TARGET PDB_NAME>’);

  • Run the following steps to rename the PDB.

$sqlplus / as sysdba
SQL>alter pluggable database <SOURCE PDB NAME>” close;
SQL>alter pluggable database <SOURCE PDB NAME>” unplug into ‘<ORACLE_HOME>/dbs/<SOURCE PDB NAME>.xml’;
SQL>drop pluggable database <SOURCE PDB NAME>“;
SQL>create pluggable database <NEW PDB NAME> using ‘<ORACLE_HOME>/dbs/<SOURCE PDB NAME>.xml’ NOCOPY SERVICE_NAME_CONVERT=(‘ebs_<SOURCE PDB NAME>,’ebs_<TARGET PDB NAME>,’<SOURCE PDB NAME>_ebs_patch’,’<TARGET PDB NAME>_ebs_patch’);
SQL>alter pluggable database <TARGET PDB NAME> open read write;

  • The PDB name should not be more than 8 characters.
  • The PDB should be renamed only using the above approach to retain the case of the PDB name.
  • Startup the PDB and save its state by running the following commands:

sqlplus / as sysdba
SQL>alter pluggable database all open; (single-node database)

SQL>alter pluggable database all save state instances=all;

  • Run the library update script against the Oracle database.

cd <ORACLE_HOME>/appsutil/install/<CONTEXT_NAME>
$sqlplus / as sysdba @adupdlib.sql <libext>

<libext> should be set to sl for HP-UX, so for any other UNIX platform, or dll for Windows.

2.4.7 Set the Target UTL_FILE_DIR Values in Oracle Database

Starting with Oracle Database 19c, UTL_FILE_DIR is not a supported database initialization parameter.

Set the target UTL_FILE_DIR values in the database.

  1. Source the environment file.

    cd <ORACLE_HOME>
    source <CONTEXT_NAME>.env
  2. Obtain the existing value for the UTL_FILE_DIR using the following commands:

perl <ORACLE_HOME>/appsutil/bin/txkCfgUtlfileDir.pl -contextfile=<DB Context File> \
-oraclehome=<ORACLE_HOME> -outdir=<ORACLE_HOME>/appsutil/log -mode=getUtlFileDir

This will create a text file <DB_NAME>_utlfiledir.txt under the <ORACLE_HOME>/dbs directory with references to the target Oracle home.

  • Review the <DB_NAME>_utlfiledir.txt file and edit the values, if required.

Note: Before proceeding to the next step, ensure to create the physical directories for all directory paths being specified in the <DB_NAME>_utlfiledir.txt file.

  • Run the following command to store the updated values for UTL_FILE_DIR in the database:

cd <ORACLE_HOME>/appsutil/bin
perl <ORACLE_HOME>/appsutil/bin/txkCfgUtlfileDir.pl -contextfile=<DB Context File> \
-oraclehome=<ORACLE_HOME> -outdir=<ORACLE_HOME>/appsutil/log \
-mode=setUtlFileDir

This command will validate the directory paths provided in the <DB_NAME>_utlfiledir.txt for existence and will also create directory objects for all the physical directory paths.

  • Run the following command to create the directory object for the outbound directory (pointed to by the s_outbound_dir context variable in the database tier context file).

perl <ORACLE_HOME>/appsutil/bin/txkCfgUtlfileDir.pl -contextfile=<DB Context File> \
-oraclehome=<ORACLE_HOME> -outdir=<ORACLE_HOME>/appsutil/log -mode=createDirObject

When prompted for the OS path for the directory object to be created, enter the value of the s_outbound_dir context variable in the database tier context file.

  • Sync up the value of UTL_FILE_DIR in the database tier context file by running the following command:

perl <ORACLE_HOME>/appsutil/bin/txkCfgUtlfileDir.pl -contextfile=<DB Context File> \ -oraclehome=<ORACLE_HOME> -outdir=<ORACLE_HOME>/appsutil/log -mode=syncUtlFileDir \ -skipautoconfig=yes

2.4.8 Configure the Target Database

Run the adcfgclone utility to configure the target database.

cd <ORACLE_HOME>/appsutil/clone/bin
$perl adcfgclone.pl dbconfig <Target Database context file>

The target database context file is  <ORACLE_HOME>/appsutil/<Target context_name>.xml.

Note: The dbconfig option will configure the database with the required settings for the new target, but it will not recreate the control files.

Steps to Complete a Clone in Release 12.2 – Part 2

Part 2: Preclone Process on Source System

As of Release 12.2, the adpreclone.pl process on the application tier creates a complete compressed archive of the Oracle Fusion Middleware and its components:

  • A compressed archive of the Oracle WebLogic Server home, Oracle Web Tier Utilities home, Oracle Common Utilities home and the Oracle E-Business Suite home:

<COMMON_TOP>/clone/FMW/FMW_HOME.jar

  • A compressed archive of the Oracle E-Business Suite WebLogic domain:
    <COMMON_TOP>/clone/FMW/WLS/EBSdomain.jar
  • The Oracle E-Business Suite WebLogic domain’s configuration template:
    <COMMON_TOP>/clone/FMW/WLS/plan/moveplan.xml
  • A compressed archive of the Oracle Web Tier/Oracle HTTP Server configuration instance:

<COMMON_TOP>/clone/FMW/OHS/ohsarchive.jar

  • The Oracle HTTP Server configuration instance’s configuration template:
    <COMMON_TOP>/clone/FMW/OHS/moveplan.xml

The adpreclone log files are created in the <INST_TOP>/admin/log/clone directory.

2.1 adpreclone for the Database Tier

Begin by following precloning steps to prepare your environment to be copied. Log on to the Source database System as the Oracle user (<OS_DB_User>), and run the following commands:

$ cd $ORACLE_HOME/appsutil/scripts/$CONTEXT_NAME

$ perl adpreclone.pl dbTier

2.2 adpreclone for the Application Tier

Login to the run edition on the Source System as the applmgr user and run:

$ cd $INST_TOP/admin/scripts

$ perl adpreclone.pl appsTier

When run for the first time, this process will add 3-4 GB more data under $COMMON_TOP.

The adpreclone.pl process on the application tier creates the following files that collectively form a complete archive of the Oracle Fusion Middleware components:

  • A compressed archive of the Oracle WebLogic Server home, Oracle Web Tier Utilities home, Oracle common utilities home, and the Oracle E-Business Suite home:
    <COMMON_TOP>/clone/FMW/FMW_Home.jar
  • A compressed archive of the Oracle WebLogic Server domain:
    <COMMON_TOP>/clone/FMW/WLS/EBSdomain.jar
  • The Oracle WebLogic domain’s configuration template:
    <COMMON_TOP>/clone/FMW/WLS/plan/moveplan.xml
  • A compressed archive of the Oracle Web Tier/Oracle HTTP Server configuration instance:
    <COMMON_TOP>/clone/FMW/OHS/ohsarchive.jar
  • The Oracle HTTP Server configuration instance’s configuration template:
    <COMMON_TOP>/clone/FMW/OHS/moveplan.xml

Log files for the adpreclone operation are created in the  <INST_TOP>/admin/log/clone directory.

2.3 Copy the Database Node File System

  • Log on to the Source Application tier node as the applmgr user, and  shutdown the application tier processes.
  • Log on to the Source database node as the oracle user and  perform a normal shut down of the Source System database.

2.4 Clone and Configure the Target Database

With Oracle Database 19c, the database needs to be cloned manually. The Rapid Clone feature will only perform configuration of the database tier node.

Run the following as the target oracle user.

2.4.1 Copy and Uncompress ORACLE_HOME

Copy the ORACLE_HOME archive from the source system and uncompress it. Choose a suitable location and rename the extracted top-level directory name to something meaningful on the new target system.

tar -xvzf db_oh.tgz

2.4.2 Create pairsfile.txt File

Create a  <NEW_ORACLE_HOME>/appsutil/clone/pairsfile.txt text file.

For a single-node database, if you want to generate the context file non-interactively, you can use the following content:

s_undo_tablespace=<Source (PDB) system undo tablespace name>
s_db_oh=<Location of new ORACLE_HOME>
s_dbhost=<Target hostname>
s_dbSid=<Target PDB name>
s_pdb_name=<Target PDB name>
s_cdb_name=<Target CDB SID>
s_base=<Base directory for DB Oracle Home>
s_dbuser=<DB User>
s_dbgroup=<DB group> (Not applicable on Windows)
s_dbhome1=<Data directory>
s_display=<Display>
s_dbCluster=false
s_isDBCluster=n
s_dbport=<DB port>
s_port_pool=<Port pool number>

Note: If there are data tops other than the one defined in s_dbhome1, you should define them by adding the context variables  s_dbhome2s_dbhome3 and s_dbhome4.

Steps to Complete a Clone in Release 12.2 – Part 1

Cloning is the process of creating a copy of an existing Oracle E-Business Suite system. As part of your upgrade testing, you’ll need to clone your environments periodically. This chapter covers the cloning process based on Oracle’s documentation and our own experience. You should reference MOS Doc. ID: 2552208.1, Cloning Oracle E-Business Suite Release 12.2 with Multitenant Database using Rapid Clone.

In case the instance has an Oracle RAC database, also refer to Section 2 of MOS Doc. ID: 1679270.1, Cloning Oracle E-Business Suite Release 12.2 RAC Enabled Systems with Rapid Clone for additional prerequisites.

R12.2 follows a somewhat new process when cloning the Application Tier. Although most of the clone steps are similar to the process used in cloning an 11i/R12.1, some of the steps are new. Below we will cover the process of cloning both the database and application tier in your environment.

“Standard” cloning is defined as copying an existing Oracle E-Business Suite system to a target instance, for example, to clone the production instance to a test instance. With Standard cloning, you can change the instance name, hostname, SID, paths, and ports.

Cloning from Source to Target system, from the Run Edition to the Run Edition

The steps discussed below are for Standard cloning. Standard cloning consists of:

  1. Preparing the Source System, both the database tier and application tier.
  2. Copying both database tier and application tier nodes from the Source System to Target System.
  3. Configuring the Target System for both database tier and application tier. Users can only use the Target instance after it has been configured.

Environment Overview

EBS Version: R12.2.x

Assumptions

  • Both the source and target EBS R12.2 systems have 1 database node and 1 application node
  • COLD back-ups will be used to create the target EBS environment (CLONE).
  • Source database is not running Oracle RAC or ASM.

Part 1: Prerequisite Tasks

1.1 Make sure there are no current patch cycles open

The cleanup phase should be complete and  fs_clone should have been run to synchronize the RUN and PATCH application file systems.

We can check this easily by running the following SQL statement as the APPS user:

SQL> select ADOP_SESSION_ID,PREPARE_STATUS,APPLY_STATUS,FINALIZE_STATUS,CUTOVER_STATUS,CLEANUP_STATUS,ABORT_STATUS,STATUS,ABANDON_FLAG,NODE_NAME from AD_ADOP_SESSIONS order by ADOP_SESSION_ID;

ADOP_SESSION_ID P A F C C A S ABANDON_FLAG NODE_NAME

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

2 X Y N X N X C    <Target_App_Server>

4 X Y X X Y X C    <Target_App_Server>

As can be seen in the above output, the last online patching session (4) completed successfully all the way to the cleanup stage (indicated by the Y).

1.2 Check the Disk Space on the Source and Target systems

On the source system, make sure  there is at least 6GB of space free space in /usr/tmp and 6GB free under $COMMON_TOP.

adpreclone will create a backup of the important files from the source system under $COMMON_TOP and this will require a minimum of 6 GB of space.

On the target system, free space should match or exceed that of the source environment.

AD/TXK Patches

Apply the latest AD/TXK patches to the Source system. You can check the version installed with the following SQL statement:

SQL> SELECT abbreviation,codelevel FROM AD_TRACKABLE_ENTITIES WHERE abbreviation in (‘txk’,’ad’);

ABBREVIA CODELEVEL
——– ———

ad            C.11
txk           C.11

Maintain Snapshot Information

Login  to the Application Tier node as the APPLMGR user and use  adadmin to run the “Update current view snapshot” as follows:

adadmin >

1. Maintain Applications Files menu >

2. Maintain snapshot information >

3. Update current view snapshot >

4. Update Complete APPL_TOP

Note: This process can take up to an hour to complete.

The Big Picture of the R12.1.3 Upgrade

The Big Picture is an overview of the Release 12.1.3 upgrade process.
The number #1 reason to upgrade is to keep you’re My Oracle Support in compliance, followed by new feature adoption, and plans to use new business processes.
Oracle Support Compliance
Release 11.5.10.2 Support Milestones
Premium Support for E-Business Suite 11.5.10.2 ended November 30, 2010.
• First year of 11.5.10.2 EBS Extended Support fees are waived.
• Mandatory Patches – Minimum Baseline Patches for Extended Support 11.5.10.2 – After December 1, 2010 (Note 883202.1)
Release 12.0 Support Milestones
• February 1, 2012 – Premium Support Ends (R12.0.6) (845809.1)
Release 12.1 Support Milestones
• July 1, 2011 – You must apply R12.ATG_PF.B.delta.2 (R12.1.2 ATG RUP) (845809.1)
• February 1, 2012 – You must apply R12.ATG_PF.B.delta3 (R12.1.3 ATG RUP) (1066312.1)
• February 1, 2013 – You must upgrade to EBS R12.1.3

Why Not Wait for Fusion?
Nadia Benedjedou lays out short and long term goals for migrating to fusion:

The steps Nadia lays out to migrate to Fusion include:
Implement OBIEE
Implement Identity Management
Start using BI Publisher
Use Enterprise Manager, if you’re not already, to manage more of the enterprise.
Move your customizations to a Fusion compatible framework, JDeveloper and ADF.
Centralize and Consolidate your data using Oracle’s Master Data Management.

The Upgrade is an Iterative Process, until all the issues are resolved and new functionality is working.

The Technical Upgrade is like Evolution – It’s an Iterative Approach
The faster you can iterate, the faster you can resolve problems and proceed to the production upgrade.
In general, the iterative cycle is as follows:
1. Follow the steps in the upgrade guide
2. Run patchsets.sh
3. Run Patch Wizard – • Patch Wizard Update for 11i (Patch 9803629)
4. Apply any new patches
5. Iterate back to Step 3 and run Patch Wizard, until there are no new patches
The 12.0.4 and 12.0.6 Upgrade
We started with the upgrade to 12.0.4 from 11.5.10.2 and learned with each book we wrote. Our initial upgrades were based on VISION upgrades with base 11.5.10.2 patches. The same basic way Oracle initially tests the upgrade. We’ve done many technical upgrade assessments, functional assessments and customization assessments. The technical assessment is an important step to establish your patch levels for each module. If you want to continue receiving support from Oracle, then you’ll need to be patched with the Mandatory patches.
First Pass Upgrade to 12.1.1
Real customer data introduces new combinations of patch levels and possible data issues. This gave us greater insight into the upgrade issues. We then introduced the “First Pass” upgrade. We come on-site and upgrade your instance in 2 weeks. The whole assessment -1st pass upgrade usually takes 4-6 weeks, nt including customizations. This gives us many data points in our analysis of what patches are required. The 1st pass upgrade gives your functional analysts an instance to perform gap analysis and the developers an instance to see what customizations are broken.
The combination of assessments and 1st Pass upgrades help define the P3 Upgrade Methodology.
From the assessments and 1st pass upgrades we gathered new issues /solutions and developed an upgrade methodology that we use at every customer. The following picture shows the book covers for the project plan, the overview for managers and team members and the detailed, step-by-step instructions to complete the upgrade to R12.1.3.
With another release and more clients patch levels/issues, we’ve identified even more issues. The following are the pictures for the covers for the project plan, the overview and detailed upgrade guide.

Plan
Decision: re-implement or upgrade
Understand the hardware requirements and the upgrade path
Procure upgrade hardware
Purge unnecessary data
Train the functional super users in the new features of Release 12.1
Create an upgraded instance for gap analysis
Start with an assessment and a 1st pass upgrade.
Technical Assessment
Determine future capacity requirements, tech stack version compatibility and patch levels, including CPUs and PSUs. We review current issues from log files, unresolved service requests, and identify potential issues with the R12.1 Upgrade.
Architecture – Hardware Assessment
We review hardware configurations including options like: RAC vs SMP, Shared Application Tier with Distributed Processing, Parallel Concurrent Processing, SAN vs JBOD, RMAN vs Snapshots.
If the plan includes buying new hardware, consider migrating from the current 32-bit platform to a 64-bit platform.
Functional Assessment
The R12 Upgrade is not just a technical upgrade
The functional upgrade consists of mapping new business requirements with new functional features in R12.
Identify AS-IS Processes
Determine TO-BE Processes
Evaluate Potential Data Issues
Which New Features may replace customizations?
Estimate R12 New Features Training Needs
Recommend “Best Practices”

Example of Functional Issues
SQL> select count(*), country from ap_bank_branches group by country;
COUNT(*) COUNTRY
1081 (null)
112 US
3 NZ
226 CA
1 BB
2 GB
1 DE

The best solution is to have the AP functional superusers update the banks to their proper value. However, the following SQL statement can be used temporarily:
update ap_bank_branches set country=’US’ where country is null;
There are many other functional checks that are provided as a part of the functional assessment. We also provide a summary of functional new features for your installed modules.

Customization Assessment
CEMLI = Configurations, Extensions, Modifications, Localizations, and Integrations
The CEMLI Upgrade Assessment includes determining technical impact of Oracle E-Business Suite Release 12.1 on CEMLIs, upgrading CEMLIs to the new technology stack, retrofit of CEMLIs for compatibility and usability on Oracle E-Business Suite Release 12.1.
Identify all customizations
Check-in all customizations into configuration management
Determine customizations that are replaced by new R12.1 functionality
Re-Code customizations
Prepare Customization Upgrade Implementation Plan
Customization Configuration Management

Start by identifying all customizations. In some environments the customizations aren’t well documented and some customizations may have been lost due to previous patching. Check-in all customizations into configuration management. Customizations are easier to customize if you can find them and have some version control.
Determine the customizations that are replaced by new R12.1 functionality. This requires an analyst that knows the new functionality of R12.1 and understands the customizations.
Lastly, determine the customizations that need to be fixed or added to the upgrade to preserve or extend the process alignment.
Prepare
Train the Super Users and Technical Staff
Buy Hardware
Create Upgraded Instance for detailed gap analysis
Practice Testing
Practice Upgrades
Use the Maintenance Wizard (215527.1)
Step-by-step, graphical user interface for performing upgrade tasks
Consolidates instructions from multiple sources to present a comprehensive upgrade picture
Reduces upgrade tasks by filtering out those that do not apply to you (using TUMS)
Indicates critical patches that your system requires
Can automatically execute upgrade tasks for you
Run patchsets.sh

Use Patch Wizard from Oracle Application Manager (OAM)
We recommend that when you finish your upgrade to what you believe is the latest version of 12.1.3, with all the patches and Family Packs identified from patchsets.sh, this book, and your own research, you should run Patch Wizard again to see if additional patches are found.

Note that Patch Wizard may require patches for both Release 11i and Release 12 (9643141, 10629956).
If possible complete the following prior to the R12.1 upgrade weekend:
Upgrade the Database to 11.2.0.2
Migrate to OATM
Install the R12.1.1 software
Run Downtime Reducing steps
Run pre-upgrade verification steps
Technical Upgrade – Details
R12.1 Upgrade Paths
Path A DB 9iR2, 10gR2 Apps 11.5.7 or 11.5.8
DB Upgrade & Apps Upgrade need to be completed during the same downtime window.
Path B If the DB already at 11gR1, Apps 11.5.9.2 or 11.5.10.2
Only upgrade the Apps Stack
Path C Upgrade the DB & Apps in different phases
If upgrading from a release prior to 11.5.7, the upgrade path may require an interim upgrade to Release 11.5.10.2. Because of the significant downtime required to upgrade from Release 11.0 to Release 12, it may be more feasible to first upgrade to Release 11.5.10.2 and then some time later upgrade to Release 12. This requires the functional users to learn Release 11.5.10.2, and perform all the testing for another upgrade. The amount of work necessary to perform two rounds of system acceptance testing may justify another day or two of downtime, so that the upgrade from Release 11.0 to Release 12.1 can be completed in one longer period of downtime.
Upgrade Paths
The light green circles indicate the most documented upgrade path from 11.5.10.2 to 12.1.1 and 12.1.3.

These bubbles show the upgrade paths. If your initial release is 11.0.3, you will need to upgrade to an interim release, 11.5.10.2, before you can upgrade to 12.1.1. The following chart lists the initial release, interim release and final release, with the associated patch number,
Initial Release Interim Release Final Release R12 Patch
11.0, 11.5.1 – 11.5.6 11.5.10 CU2 12.0.0 4440000
11.5.7. 11.5.8, 11.5.9*, 11.5.10* Release 12.0.0 4440000
11.5.7, 11.5.8, 11.5.9.2, 11.5.10.2 Release 12.0.4 6394500
11.5.9*, 11.5.10* Release 12.1 6678700
12.1.1 Release 12.1.2 7303033
12.1.1 Release 12.1.3 9239090
* includes CU1 and CU2 (consolidated update)
Figure 4 indicates that a direct upgrade path exists from Release 11.5.7 to Release 12.0.0.

The Applications Upgrade path is constrained by the database release. The following chart shows the application release and the database versions that are certified on Solaris. If the application release is 11.5.10.2, then you can upgrade the database to 11gR2 before the application upgrade, saving downtime during upgrade weekend, if you plan you use 11gR2, and you should always try to use the latest certified version of the database.
Release Certified Database Versions on Solaris
12.1 10gR2, 11gR2 and the 64 bit versions
12.0 10gR2, 11gR2 and the 64 bit versions
11.5.10.2 10gR2 or 11gR2 and the 64 bit versions
11.5.9.2 10gR2 and the 64 bit versions
11.5.7 8.1.7, 9.0.1 9.2, and 9.2-64 bit

We can see that there is no certified database version that is certified with both Release 11.5.7 and Release 12.1. Therefore, we can’t do the database upgrade before the downtime window.
Overview of the R12.1 Technical Upgrade

The database upgrade is a bit more complicated if you’re running 9.2.0.6, because of Daylight Savings Time.
• The database installed by the 11.5.10.2 RapidWiz is Version 9.2.0.6. This database version does not support Daylight Savings Time (DST). Therefore, we have two choices:
• Upgrade the database to Version 9.2.0.8, which has support for DST, and then upgrade to Version 11.2.0.1, or

Perform the Upgrade
11i pre-reqs for Release 12.1.1
11870353, 5880762, 7477784, 7721754, 7828862, 8579398, 8757781, 8761881, 8798855, 8845395, 8908907, 8990356, 8991381, 9003549, 9053932, 9109247, 9128838, 9187813, 9288021, 9304675, 9442701, 9446543, 9476923, 9535311, 9685457, 9725579, 9747572, 9871422, 9889680, 3865683, 6408117, 8242248, 6024690, 4619025, 5368595, 5357791, 5970422, 59105548, 5194357, 5230979, 4396821, 5377946, 6741394, 6505416, 7418579, 4963569, 5259121, 4551977, 4607647, 6027561, 5760729, 5382135, 4699061, 6696828, 4582937, 4507073, 8340090, 4350832, 4563075, 4582937, 4607647, 4699061, 4939444, 4963569, 4969938, 5259121, 5382135, 6349338, 6351946, 6694260, 6696828, 8340090, 8487779, 10258309, 6264601, 3153717, 4252634
This list of patches continually changes. You should run Patch Wizard to determine any missing patches for your environment. When you’ve determined your patch list, cut and paste the patch list into the Patch Search form, on My Oracle Support.