Migrating Oracle Applications 11i
Platform Migration of Oracle Applications
Migrate Platforms with Oracle Applications 11i to Linux platform
While migrating to a new platform, we must make sure that the new platform is certified/supported by Oracle for both the database and the Apps tiers, if migrating both.
If migrating just one of the tier to the new platform, then that architecture is called a Split Tier architecture, where the database and the apps tiers are on different platforms. Care must be taken to make sure other constraints are evaluated and sufficient alternatives are designed, like for example, in a split tier architecture cloning the database using RapidClone is not certified, so you might have to resort to more traditional methods of cloning the database instead.
Process of migration.
The process of migrating the applications tier to a new platform means to copy over the platform independent files and laying down the new tech stack specific to the new platform, then regenerating the libraries for the new tech stack and finally running autoconfig. It is in a way similar to cloning an applications tier, except we will be using new set of binaries specific to the target platform.
Step by Step process overview.
1. Make sure that the instance has the latest RapidClone patches and has autoconfig implemented.
2. Generate and upload the manifest of customer-specific files
Log in to your Source System primary administration node as the APPLMGR user. Execute the following command to generate the customer-specific file manifest.
This step should take about a minute:
perl $AD_TOP/bin/adgenpsf.pl
This generates a adgenpsf.txt file. Go to http://updates.oracle.com/PlatformMigration(use your Oracle MetaLink username and password) and follow the instructions on the screen to upload the manifest file previously generated:
$APPL_TOP/admin/$TWO_TASK/out/adgenpsf.txt
Once this has been uploaded, after about 45 mins, Oracle will be provide a patch to be applied on top of the new application system on the new platform, to cater to the customer specific updates.
3. Create the Target System APPL_TOP on new platform.
Now we need to copy the middle tier file system from the Source Applications System to the Target Node.
Ensure that the application tier files copied to the Target System are owned by the Target APPLMGR user.
Copy the APPL_TOP file system
<APPL_TOP>
<OA_HTML>
<OA_JAVA>
<COMMON_TOP>/util
<COMMON_TOP>/_pages (when that directory exists)
Attention: Copy only the directories listed, not the full COMMON_TOP, rest of the data for the common_top will be brought in by the new tech stack.
4. Context File
Now we need to clone the Applications context file by copying over the applications context file from the source applications system, and manually edit the context file to provide information regarding the new applications top and its mount points, etc.
NOTE: this method of manually editing the CONTEXT_FILE is usually helpful, only if there are not too may differences in the names of mount points, hostnames and if the same ports are required to be used. So that, we can manually do a global string replace on the Context XML file and providing the new values.
The other more orthodox method is to clone the applications context file by running,
Log on to the Target System as the APPLMGR user and run the following command
perl <AD TOP>/bin/adclonectx.pl migrate java=<JDK HOME> contextfile=<Source System contextfile>
The Clone Context tool will ask for all the new mount points on the Target migration node.
Respond to the prompts. This will create the following Target System context file:
<APPL_TOP>/admin/<SID>_<hostname>.xml
5. Installing the New Tech Stack
Download the Oracle Applications 11i binaries for the new platform and mount and unzip them to a directory where they are accessible.
6. Now run the RapidWiz tool, with the following specific parameters in the command line as input.
cd [Stage11i]/startCD/Disk1/rapidwiz
./rapidwiz -techstack
This should lay the iAS, 806 and other tech stacks on the applications side.
7. Interoperability patches
This is specific to each customer, depending oh what version of the applications you are on and on what version of the operating system the new platform is on.
So you will have to verify from metalink on all the patches that might be needed, depending on your case.
8. Creating custom env files.
At this point care needs to be taken to update all customer specific non applications environment files. These are files like the .profile, .kshrc, path to oracle_homes, $PATH variables etc which will get sourced at logon. The applications specific env files will be taken care of in the next step.
9. Run AutoConfig setup phase on the Target System
Execute the INSTE8_SETUP phase of AutoConfig with the new context file. This will create the environment files required for the AutoPatch session:
cd <AD_TOP>/bin
./adconfig.sh run=INSTE8_SETUP contextfile=<Target System ctxfile>
Note: This command does not require the environment to be sourced
10. Verifying the environment variables.
Now log out f the environment and re-login and make sure the env variables are all set correctly.
11. Applying customer specific generated patch.
By now you should have received an email, saying that the customer specific files have been generated based on the manifest tat you had uploaded to Oracle before.
Directions to download the patch will be given in the email.
This patch now needs to be applied on the APPL_TOP of the target system.
12. Regenerating file system objects.
At this point we need to run adadmin utility on the target node to regenerate forms, reports, messages, jar files etc for the new platform.
13. Run Autoconfig
Now we need to run autoconfig on the target system to publish and propogate the changes of the new system through the entire application.
This should complete a potential platform migration of the applications tier.
NOTE: These are only guidelines taken from the metalink note: 238276.1 as reference.
Common issues that we usually run into are due tothe change in the hostnames of the node and network issues. The target application system since is a new system, the other components of the EBS need to be made aware of the new tier. So the listener configuration need to be validated. We also need to make sure the target is able to communicate with the source database and or any other tiers that might exist as part of the application system.
Furthermore care should be take to perform post migration steps, like updating Workflow setting, printer setting, customizations, any third party software of tools configurations. Adding the new node to the Enterprise Manger, if you use one, by installing an agent and the management plug-ins etc.