Linux Migration

Step#1 1.Create a virtual Linux Machine on the VMware server 2. Install the all OS related RPMs and Packages ( Followed the document 316806.1 ) Command to Install the rpm: Ex: rpm -ivh openmotif21-2.1.30-11.EL5.i386.rpm rpm qa | grep openmotif21-2.1.30-11.EL5.i386.rpm 1 day

Operating System Oracle Linux 4*

Required Patches Quarterly Update 4 or higher (Recommended Version) compat-db-4.1.25-9 compat-gcc-32-3.2.3-47.3 compat-gcc-32-c++-3.2.3-47.3 compat-oracle-rhel4-1.0-5 (from Oracle patch 4198954) compat-libcwait-2.1-1 (from Oracle patch 4198954) compat-libgcc-296-2.96-132.7.2 compat-libstdc++-296-2.96-132.7.2 compat-libstdc++-33-3.2.3-47.3 xorg-x11-deprecated-libs-devel-6.8.2-1.EL.13.37 xorg-x11-deprecated-libs-6.8.2-1.EL.13.37 openmotif-2.2.3-10.RHEL4.5

Oracle Linux 5*

Update 1 (Oracle Linux 5.1) or higher is required

Update 1 (RHEL 5.1) or higher is required. Red Hat Enterprise Linux 5* (base and The following packages are not part of the Oracle Linux 5 or RHEL Advanced 5 distribution media and must be installed manually: Platform) 1 compat-libstdc++-egcs-1.1.2-1 1 compat-libcwait-2.1-1 1 compat-oracle-el5-1.0-5 1 openmotif21-2.1.30-11.EL5 2 binutils-2.15 The following packages must be installed from the Oracle Linux 5 or RHEL 5 distribution media: Note : libXp-1.0.0-8.1.el5 compat-libgcc-296-2.96-138 compat-libstdc++-33-3.2.3-61 compat-db-4.2.52-5.1

Linux Migration
1

: Download from http://oss.oracle.com/projects/compatoracle/files/Enterprise_Linux/ (for both Oracle Linux 5 and RHEL 5) 2 : GNU linker (ld) version 2.15 is required for relinking the modules in Advanced Planning & Scheduling (MSC, MSO, MSR) download binutils-2.15 from http://oss.oracle.com/projects/compatoracle/files/Enterprise_Linux/ (for both Oracle Linux 5 and RHEL 5)

Kernel Requirements Oracle Linux 5 2.6.18-8.EL

Domain Name System (DNS) Resolver Parameters Two Domain Name System (DNS) resolver parameters (timeout and attempts) are set by default to low values when the operating system is installed. These low values may cause attempted network connections to an Oracle database to fail. If this happens, add or update the following entries to these minimum settings in the /etc/resolv.conf file on each server node: options attempts:5 options timeout:15

Net Service Listeners in Multi-user Installations Give all users in a multi-user installation write privileges to the .oracle directory: $ chmod 777 /var/tmp/.oracle

Oracle Linux 4 and 5, Red Hat Enterprise Linux 3, 4 and 5 and SUSE Linux Enterprise Server 8, 9 and 10
This section describes requirements that apply only to Oracle Linux 4 and 5, Red Hat Enterprise Linux 3, 4 and 5 and SUSE Linux Enterprise Server 8, 9 and 10. Verifying Host Names Use the following to verify host name settings: For Oracle Linux 4 and 5, Red Hat Enterprise Linux 3, 4 and 5: 1. Verify that the /etc/hosts file is formatted as follows: 2. 127.0.0.1 localhost.localdomain localhost <ip_address> <node_name>.<domain_name> <node_name> 3. Verify that the /etc/sysconfig/network file is formatted as follows: 4. HOSTNAME=<node_name>.<domain_name> 5. 6. If the /etc/sysconfig/networking/profiles/default/network file exists, remove it.

Linux Migration
7. If you changed any files in the previous steps, restart the system. Modifying the Number of Open File Descriptors Open the /etc/security/limits.conf file and change the existing values for "hard" and "soft" parameters as follows. Restart the system after making changes. For Oracle Linux 4 and 5, Red Hat Enterprise Linux 3, 4 and 5 and SUSE Linux Enterprise Server 9 and 10: * hard nofile 65535 * soft nofile 4096 For SUSE Linux Enterprise Server 8: * hard nofile 32768 * soft nofile 32768 Modifying the Port Range Values Open the /etc/sysctl.conf file and change the value of net.ipv4.ip_local_port_range as follows. Restart the system after making changes. net.ipv4.ip_local_port_range = 10000 65000 Please note that this range is a recommended range, and may need to be adjusted according to the specific needs of the user's environment in order to avoid port conflicts. Create symbolic links. For Oracle Linux 5 and Red Hat Enterprise Linux 5 only : # ln -s /usr/bin/ld215 /usr/bin/ld Download and apply the OS library patch 6078836 from My Oracle Support and create the following symbolic link: # ln -s /usr/lib/libdb.so.2 /usr/lib/libdb.so.3 1. Verify that the host name setting is correct. The command should return a fully qualified host name. For example: <host_name>.<domain_name>. # hostname -f Completing Preinstallation Tasks Complete these tasks after you set the environment variables and before you begin the installation steps described in Installing Oracle Applications. 1. Unset the NLS_LANG environment variable, if it is defined prior to installation. 2. For Red Hat Enterprise Linux 3, apply the OS library patch 3006854 (downloadable from My Oracle Support). 3. For Oracle Linux 5, Red Hat Enterprise Linux 5 and SUSE Linux Enterprise Server 10 customers, the LD_ASSUME_KERNEL environment variable should be unset before starting the installation. The installation fails when the LD_ASSUME_KERNEL variable is set by the adgetlnxver.sh file during the

Linux Migration
course of the installation. Patch 6365595 contains the fix for adgetlnxver.sh file. The procedure below is a guideline for replacing the adgetlnxver.sh file in the Oracle Applications 11i shiphome. a. Download the patch 6365595 from My Oracle Support. b. Follow the Oracle Applications Installation guide and set up the stage area. c. Set the STAGE_TOP environment variable to the top level directory of the stage area that contains the subdirectories startCD, oraApps, oraDB, oraiAS and oraAppDB. Make sure that the stage area is read writable.

d. Create the following directories in the stage area. # mkdir -p $STAGE_TOP/oraDB/Disk3/db/stage/appsutil/bin # mkdir -p $STAGE_TOP/oraApps/Disk5/appl/stage/bin e. Copy the adgetlnxver.sh file in the patch 6365595 to the following directories created in earlier step. # cp -p 6365595_PATCH_TOP/ad/bin/adgetlnxver.sh $STAGE_TOP/oraDB/Disk3/db/stage/appsutil/bin # cp -p 6365595_PATCH_TOP/ad/bin/adgetlnxver.sh $STAGE_TOP/oraApps/Disk5/appl/stage/bin f. Update the zip archive with the fix (adgetlnxver.sh file). # cd $STAGE_TOP/oraDB/Disk3/db/stage # zip -u dboh0_appsutil appsutil/bin/adgetlnxver.sh # cd $STAGE_TOP/oraApps/Disk5/appl/stage # zip -u ad_CORE bin/adgetlnxver.sh

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Installed the Linux and created the following mountpoints: Storage Ext 3 : LAEBSLIT1DB : database node + admin node LAEBSLIT1AP : Web node + Forms Create the groups and users in LAEBSLIT1DB Oracle User : oraprd1 Application User : applprd1

groupadd -g 500 prd1 useradd -d /home/oraprd1 -g prd1 -s /bin/bash -m oraprd1 Chown oraprd1:PRD1 <Folder_name> Create the Mount points while Installing the Linux with the following volumes

Linux Migration
/d01 : Oracle and Application binaries /d02 : Datafiles /d03 : Archivelogs + FRA /stage : required software

Install The RDBMS Binaries (1135973.1)

./runInstaller ignoreSystemPreReqs 10.2.0.4 Patchset --- 6810189
Database Installation:
6. Prepare to create the 10.2.0 Oracle home The 10.2.0 Oracle home must be installed on the database server node in a different directory than the current Oracle home. Read Chapters 1 and 2 of the Oracle Database Installation Guide 10g Release 2 (10.2) for your platform. Also read Chapter 1 and the "System Considerations and Requirements" section of Chapter 3 of the Oracle Database Upgrade Guide 10g Release 2 (10.2). Make sure you thoroughly understand the installation and upgrade processes. Perform any step that is relevant for your environment. 7. Install the base 10.2.0 software Log in to the database server node as the owner of the Oracle RDBMS file system and database instance. Ensure that environment settings, such as ORACLE_HOME, are set for the new Oracle home you are about to create, and not for any existing Oracle homes on the database server node. Perform all the steps in Chapter 3 of the Oracle Database Installation Guide 10g Release 2 (10.2) for your platform. In the Installation Types window, use the Product Languages button to select any languages other than American English that are used by your Applications database instance. Choose the Enterprise Edition installation type. In the subsequent windows, select the options not to upgrade an existing database and to install the database software only. Attention You may ignore the errors when running utlu102i.sql as documented in 370825.1.

8. Install Oracle Database 10g Products from the 10g Companion CD On the database server node, as the owner of the Oracle RDBMS file system

Linux Migration
and database instance, perform the tasks in section 3.5, "Installing Oracle Database 10g Products" in the Oracle Database Companion CD Installation Guide for your platform. Do not perform the tasks in the "Preparing Oracle Workflow Server for the Oracle Workflow Middle Tier Installation" section. In the Installation Types window, use the Product Languages button to select any languages other than American English that are used by your Applications database instance. 9. Perform 10.2.0.4 patch set pre-installation tasks On the database server node, as the owner of the Oracle 10g file system and database instance, unzip and extract the 10.2.0.4 patch set file for your platform. Read the patch set notes (usually README.html). Make sure you thoroughly understand the upgrade and patch set installation process before you begin. Check My Oracle Support or contact Oracle Support Services to determine any known issues with the patch set and its interoperability with Oracle E-Business Suite. Perform the tasks in the "Preinstallation Tasks" section of the patch set notes (if they apply to your system). 10. Perform 10.2.0.4 patch set installation tasks On the database server node, as the owner of the Oracle RDBMS file system and database instance, perform the tasks in the "Installing the Oracle Database 10g Patch Set Interactively" section of the patch set notes. Make sure that: o The ORACLE_HOME environment variable points to the new 10.2.0 Oracle home. o The PATH environment variable includes $ORACLE_HOME/bin and the directory where the new perl executable is located (usually $ORACLE_HOME/perl/bin). o The LD_LIBRARY_PATH environment variable includes $ORACLE_HOME/lib. o The PERL5LIB environment variable points to the directories where the new perl libraries are located (usually $ORACLE_HOME/perl/lib/[perl version] and $ORACLE_HOME/perl/lib/site_perl/[perl version]) o You use the runInstaller (UNIX/Linux) or the setup.exe executable (Windows) provided in the patch set to run OUI.

Create Init.ora and listener

Section 2: Prepare a target Applications Release 11i database instance

This section describes how to create the empty target database and populate it with all of the required system objects prior to running import. The Oracle home of the target database instance can be the same Oracle home that the source database instance uses, or it can be different (on another machine running a different operating system, for example), as long as it uses Oracle Database 10g Release 2 Enterprise Edition. 1. Create target Oracle 10g Oracle home (conditional) If you want the target Oracle 10g Oracle home to be separate from the source

Linux Migration
Oracle home, you must create it now. To complete this task, perform the steps in the "Database Installation" subsection of Section 1 of the Oracle Applications Release 11i with Oracle Database 10g Release 2 (10.2.0) Interoperability Notes. 2. Modify sqlnet.ora file (Windows only) If the target database server node is running Windows, add the following line to the sqlnet.ora file in the %ORACLE_HOME%\network\admin\[SID] directory, if it does not already exist: 3. SQLNET.AUTHENTICATION_SERVICES=(NTS) 4. Create the target initialization parameter file and CBO parameter file The initialization parameter file (init[SID].ora) and cost-based optimizer (CBO) parameter file (ifilecbo.ora) are located in the $ORACLE_HOME/dbs directory on the source database server node. Copy both files to the Oracle 10g $ORACLE_HOME/dbs directory on the target database server node. Refer to Database Initialization Parameters (init.ora settings) in Oracle Applications Release 11iand update both the init.ora and ifilecbo.ora files with any necessary changes. You may also need to update initialization parameters involving the db_name, control_files, and directory structures. Comment out the parameters undo_tablespace and undo_management in the initialization parameter file of the target database instance. Add these parameters after the adcrdb.sql script has been run. Ignore the initialization parameters that pertain to the native compilation of PL/SQL code. You will be instructed to add them later, if necessary. 5. Create the target database instance Copy the adcrdb.sql script, generated in Section 1, from the source administration server node to the target database server node. Then update the script on the target database server node with any necessary changes to the directory structures for the log file(s), data file(s), or tablespaces, reflecting the layout of the target database server node. If the target database server node is running Windows, update the directory structure from UNIX/Linux format to Windows format. Make sure that the environment of your session on the target database server node is set up properly for the target database instance, especially the ORACLE_HOME, ORACLE_SID, and ORA_NLS10 environment settings. (ORACLE_SID must be set to the same value as the db_name parameter in the init[SID].ora file.) Then, use the following commands to run adcrdb.sql and create the target database instance: $ sqlplus /nolog SQL> connect / as sysdba; SQL> spool adcrdb.log; For UNIX or Linux: SQL> startup nomount; SQL> @adcrdb.sql SQL> exit; For Windows: SQL> startup nomount pfile=%ORACLE_HOME%\dbs\init%ORACLE_SID%.ora SQL> @adcrdb.sql

Linux Migration
SQL> exit; Add the parameters undo_tablespace and undo_management to the initialization parameter file. If PL/SQL of the source database was natively compiled, see the "Compiling PL/SQL Code for Native Execution" section of Chapter 11 of Oracle Database PL/SQL User's Guide and Reference 10g Release 2 (10.2) for instructions on how to natively compile PL/SQL in the target database. Add the parameters that pertain to the native compilation where specified. Do not use the natively compiled code generated by the source database. Oracle does not support switching the PL/SQL compilation mode from interpreted to native (and viceversa) for an export/import. Exporting/importing using native mode takes significantly more time than interpreted mode. When the target database instance has been created, restart the database instance. 6. Copy database preparation scripts to target Oracle home The database preparation scripts that you applied to the source administration server node in Section 1 contain four scripts that are needed on the target database server node. Copy the following files from the $APPL_TOP/admin directory of the source administration server node to the Oracle 10g $ORACLE_HOME/appsutil/admin directory of the target database server node: addb1020.sql, adsy1020.sql, adjv1020.sql, and admsc1020.sql (UNIX or Linux) or addb1020_nt.sql, adsy1020_nt.sql, adjv1020_nt.sql, and admsc1020_nt.sql (Windows). As you run each of the next four steps, note the following: The remarks section at the beginning of each script contains additional information. o Each script creates a log file in the current directory. 7. Set up the SYS schema The addb1020.sql or addb1020_nt.sql script sets up the SYS schema for use with the Applications. On the target database server node, use SQL*Plus to connect to the target database instance as SYSDBA and run $ORACLE_HOME/appsutil/admin/addb1020.sql (UNIX/Linux) or addb1020_nt.sql (Windows). Here is an example on UNIX or Linux: $ sqlplus "/ as sysdba" @$ORACLE_HOME/appsutil/admin/addb1020.sql 8. Set up the SYSTEM schema The adsy1020.sql or adsy1020_nt.sql script sets up the SYSTEM schema for use with the Applications. On the target database server node, use SQL*Plus to connect to the target database instance as SYSTEM and run $ORACLE_HOME/appsutil/admin/adsy1020.sql (UNIX/Linux) or adsy1020_nt.sql (Windows). Here is an example on UNIX or Linux: $ sqlplus system/[system password] \ @$ORACLE_HOME/appsutil/admin/adsy1020.sql 9. o

Linux Migration
10. 11. 12. Install Java Virtual Machine The adjv1020.sql or adjv1020_nt.sql script installs the Java Virtual Machine (JVM) in the database. On the target database server node, use SQL*Plus to connect to the target database instance as SYSTEM and run $ORACLE_HOME/appsutil/admin/adjv1020.sql (UNIX/Linux) or adjv1020_nt.sql (Windows). Here is an example on UNIX or Linux: $ sqlplus system/[system password] \ @$ORACLE_HOME/appsutil/admin/adjv1020.sql Attention
This script can be run only once in a given database instance, because the scripts that it calls are not rerunnable.

13. Install other required components The admsc1020.sql or admsc1020_nt.sql script installs the following required components in the database: ORD, Spatial, XDB, OLAP, Data Mining, interMedia, and ConText. On the target database server node, use SQL*Plus to connect to the target database instance as SYSTEM and run $ORACLE_HOME/appsutil/admin/admsc1020.sql (UNIX/Linux) or admsc1020_nt.sql (Windows). You must pass the following arguments to the script, in the order specified: Argument
remove context? SYSAUX tablespace temporary tablespace FALSE SYSAUX TEMP

Value

14. Here is an example on UNIX or Linux: 15. $ sqlplus system/[system password] \ 16. @$ORACLE_HOME/appsutil/admin/admsc1020.sql FALSE SYSAUX TEMP Attention
All of the components are created in the SYSAUX tablespace regardless of where it was installed in the source database.

17. Run adpostcrdb.sql script Copy the adpostcrdb.sql script, generated in Section 1, from the source administration server node to the target database server node. On the target database server node, use SQL*Plus to connect to the database instance as SYSDBA and run the following command. 18. $ sqlplus "/ as sysdba" @adpostcrdb.sql 19. Disable automatic gathering of statistics Copy $APPL_TOP/admin/adstats.sql from the administration server node to the target database server node. Use SQL*Plus to connect to the database as SYSDBA and use the following commands to restart the database in restricted mode and run adstats.sql:

Linux Migration
20. $ sqlplus "/ as sysdba" 21. SQL> shutdown normal; 22. SQL> startup restrict; 23. SQL> @adstats.sql 24. SQL> exit; 25. Back up the target database instance The target database instance is now prepared for an import of the Applications data. You should perform a backup before starting the import.

Section 3: Export the source Applications Release 11i database instance

This section describes how to ensure that you have the required patches, create your export file, and capture important information that is required to import your database. 1. Create the export parameter file A template for the export parameter file has been included as part of the export/import patch 4872830. Copy $AU_TOP/patch/115/import/auexpdp.dat from the source administration server node to the directory on the database server node where the export dump files are to be created. Use a text editor to modify the file to reflect the source environment and other customized parameters. The customizable parameters are: Parameter
directory dumpfile filesize log

Description
directory where the export dump files will be created export dump file name(s) export dump file size log file name

Template Value
dmpdir aexp%U.dmp 1GB expdpapps.log

interMedia, OLAP, and Data Mining schemas are not exported. The admsc1020.sql script creates these schemas in the target database. Ensure that the schema names in the exclude parameters reflect those in your database. Create a directory in the SYS schema that corresponds to the directory specified in the template. Here is an example of how to create a directory named dmpdir: $ sqlplus "/ as sysdba" SQL> create directory dmpdir as '/u01/expimp'; Comment out or remove the transform parameter. It is used only for the import process. Do not change the other parameters. The export process uses as many of the listed file names as necessary to hold the exported data. You must ensure that the number of dump files specified, as well as the size of each dump file, is sufficient to contain all the data in your source database instance. 2. Shut down Applications server processes Shut down all Applications server processes except the database and the

Linux Migration
Net8 listener for the database. Users cannot use the Applications until the import is completed. 3. Back up AZ table data (conditional) If you are using AZ.H, upgrade to AZ.H.DELTA.1. See document 403092.1 on My Oracle Support for instructions. 10.2 datapump does not allow tables with XML type columns to be migrated. Perform step 2 ofdocument 402785.1 on My Oracle Support to back up the data within XML type columns. 4. Grant privilege to source system schema Grant the exempt access policy privilege to system by using SQL*Plus to connect to the database as SYSDBA and run the following command: 5. SQL> grant EXEMPT ACCESS POLICY to system; 6. Export the Applications database instance Start an export session on the source database server node using the customized export parameter file. Use the following command: 7. $ expdp "'/ as sysdba'" parfile=[export parameter file name] Typically, the export runs for several hours. 8. Revoke privilege from source system schema Revoke the exempt access policy privilege from system by using SQL*Plus to connect to the database as SYSDBA and run the following command: 9. SQL> revoke EXEMPT ACCESS POLICY from system;

Section 4: Import the Applications Release 11i database instance

This section describes how to use the import utility to load the Oracle Applications data into the target database. 1. Create the import parameter file Copy the export parameter file you created in Section 1 from the source database server node to the target database server node, renaming it if necessary. Updating the new file with the following changes converts it to an import parameter file: o Remove the exclude parameters. o Remove the filesize parameter. o Change the name of the log file. o Uncomment the transform parameter. Create a directory in the system schema with the name set to the directory specified in the template and the path set to where the export dump files will reside. Here is an example of how to create a directory named dmpdir: $ sqlplus "/ as sysdba" SQL> create directory dmpdir as '/u01/expimp'; Save the changed file. 2. Copy the export dump files Copy the export dump files from the source database server node to the target database server node. 3. Import the Applications database instance Start the import session on the target database server node using the customized import parameter file. Use the following command:

Linux Migration
4. $ impdp "'/ as sysdba'" parfile=[import parameter file name] 5. Typically, import runs for several hours. Once the import is complete, you can delete the export dump files, as well as the export and import parameter files, from the source and target database server nodes. 6. Revoke privilege from target system schema Revoke the exempt access policy privilege from system by using SQL*Plus to connect to the database as SYSDBA and run the following command: SQL> revoke EXEMPT ACCESS POLICY from system;

Section 5: Update the imported Applications Release 11i database instance

This section describes how to recreate the database objects and relationships that are not handled by the export and import utilities. 1. Reset Advanced Queues Copy the auque2.sql script that was generated in Section 1 from the $ORACLE_HOME/appsutil/admin directory of the source database server node to the same directory on the target database server node. Then, on the target database server node, as the owner of the Oracle 10g file system and database instance, use SQL*Plus to connect to the target database as SYSDBA and run the $ORACLE_HOME/appsutil/admin/auque2.sql script to enable the Advanced Queue settings that were lost during the export/import process. The script creates a log file in the current directory. 2. $ sqlplus /nolog 3. SQL> connect / as sysdba; 4. SQL> @$ORACLE_HOME/appsutil/admin/auque2.sql 5. Perform post-import steps outlined in the Interoperability documents Complete the steps in the "After the Database Upgrade" subsection of Section 1 of the Oracle Applications Release 11i with Oracle Database 10g Release 2 (10.2.0) Interoperability Notes. Do not run the Korean lexer fix. Do not import the OLAP analytical workspaces. Do not re-create grants and synonyms. Do not restart the Applications server processes. 6. Restore AZ table data (conditional) If you performed the step to back up the AZ table data, Perform steps 4 and 5 of document 402785.1 on My Oracle Support to restore the AZ table data. 7. Create OWA_MATCH package (conditional) If you are using iAS 1.0.2, perform the steps in document 312165.1 to create SYS.OWA_MATCH on the target database. 8. Create ConText and Spatial objects Certain ConText and Spatial objects are not preserved by the import process. The consolidated export/import utility patch 4872830 that you applied to the source administration server node in Section 1 contains a perl script, dpost_imp.pl, that you can run to generate an AutoPatch driver file. You use this driver file to call the scripts that create these objects. Run the following command: 9. $ perl $AU_TOP/patch/115/driver/dpost_imp.pl [driver file] Once the driver file has been generated, use AutoPatch to apply it on the target administration server node.

Linux Migration
10. Compile invalid objects On the target database server node, as the owner of the Oracle 10g file system and database instance, use SQL*Plus to connect to the target database as SYS and run the $ORACLE_HOME/rdbms/admin/utlrp.sql script to compile invalid objects. $ sqlplus "/ as sysdba" @$ORACLE_HOME/rdbms/admin/utlrp.sql

1. Deregister the current database server (conditional) If you plan to change the database port, host, SID, or database name parameter on the database server, you must also update AutoConfig on the database tier and deregister the current database server node. To update AutoConfig on the database tier, follow the instructions in Using AutoConfig to Manage System Configurations with Oracle Applications 11i on My Oracle Support. To deregister the current database server node, run the following command as the owner of the Oracle RDBMS file system and current database instance: $ perl $ORACLE_HOME/appsutil/bin/adgentns.pl appspass=apps contextfile=$CONTEXT_FILE -removeserver 2. Update application tier context file with new database listener port number (conditional) The new 10.2.0 Oracle home uses its own database listener for the database instance, replacing the current database listener. Use the Context Editor to update the following variables in the Applications context file on each application tier server node to reflect the 10.2.0 configuration: Variable Name
s_dbhost s_dbdomain s_db_serv_sid s_dbport s_apps_jdbc_connect_descriptor

Value
New database hostname New database domain name New database SID New database listener port NULL

3. See Using AutoConfig to Manage System Configurations with Oracle Applications 11i on My Oracle Support for instructions on how to update and run the Context Editor.

Linux Migration
After the Database Upgrade:
21. Fix Korean lexers Use SQL*Plus to connect to the database as SYSDBA, and run drkorean.sql using the following command: 22. $ sqlplus "/ as sysdba" @$ORACLE_HOME/ctx/sample/script/drkorean.sql 23. Import OLAP analytical workspaces (conditional) If your database server node was upgraded from the 32-bit Solaris platform, perform detailed steps 6 and 7 of Upgrading OLAP from 32 to 64 bits on My Oracle Support. 24. Start the new database listener (conditional) If the Oracle Net listener for the database instance in the new Oracle home has not been started, you must start it now. Since AutoConfig has not yet been implemented, start the listener with the lsnrctl executable (UNIX/Linux) or Services (Windows). See the Oracle Database Net Services Administrator's Guide, 10g Release 2 (10.2) for more information. Attention
Set the TNS_ADMIN environment variable to the directory where you created your listener.ora and tnsnames.ora files.

25. Run adgrants.sql (conditional) If you have at least AD.I or E-Business Suite release 11.5.10 installed on your system, copy $APPL_TOP/admin/adgrants.sql (adgrants_nt.sql for Windows) from the administration server node to the database server node. Use SQL*Plus to connect to the database as SYSDBA and run the script using the following command: 26. $ sqlplus "/ as sysdba" @adgrants.sql (or adgrants_nt.sql) 27. [APPLSYS schema name] where [APPLSYS schema name] is the Applications Object Library user, most commonly named APPLSYS. 28. Grant create procedure privilege on CTXSYS Copy $AD_TOP/patch/115/sql/adctxprv.sql from the administration server node to the database server node. If you are upgrading to R12, use the R12 version of the file. Use SQL*Plus to connect to the database as APPS and run the script using the following command: 29. $ sqlplus apps/[APPS password] @adctxprv.sql \ 30. [SYSTEM password] CTXSYS 31. Implement and run AutoConfig Implement and run AutoConfig in the new Oracle home on the database server node. If the database listener of the new Oracle home is defined differently than the old Oracle home, you must also run AutoConfig on each application tier server node to update the system with the new listener. See Using AutoConfig to Manage System Configurations with Oracle Applications 11i on My Oracle Support for instructions on how to implement and run AutoConfig. Shut down all processes, including the database and the listener, and restart them to load the new environment settings. 32. Gather statistics for SYS schema

Linux Migration
Copy $APPL_TOP/admin/adstats.sql from the administration server node to the database server node. If you are upgrading to R12, use the R12 version of the file. Note that adstats.sql has to be run in restricted mode. Use SQL*Plus to connect to the database as SYSDBA and use the following commands to restart the database in restricted mode, run adstats.sql, and restart the database in normal mode: 33. $ sqlplus "/ as sysdba" 34. SQL> shutdown normal; 35. SQL> startup restrict; 36. SQL> @adstats.sql 37. SQL> shutdown normal; 38. SQL> startup; SQL> exit;

Section 2: Migrate Platforms with Oracle Applications 11i

1. Generate and upload the manifest of customer-specific files a. Log in to your Source System primary administration node as the APPLMGR user and source the APPL_TOP environment file. Execute the following command to generate the customer-specific file manifest. This step should take about a minute: perl [AD_TOP]/bin/adgenpsf.pl b. Go to https://updates.oracle.com/PlatformMigration (use your OracleMetaLink 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 2. Create the Target System APPL_TOP Copy the middle tier file system from the Source Applications System to the Target Node by executing the following steps in the order listed. Ensure that the application tier files copied to the Target System are owned by the Target APPLMGR user.

Note: The Source System can remain up and running until the last step of the migration.

a. Copy the APPL_TOP file system Log on to the Source System application tier node as the APPLMGR user and copy the following application tier directories from the Source System to the Target System APPL_TOP OA_HTML OA_JAVA COMMON_TOP/clone COMMON_TOP/util COMMON_TOP/_pages (when that directory exists)

Attention: Copy only the directories listed, not the full COMMON_TOP. Warning: In order to preserve the Concurrent Manager log files and output files you need to consider the configuration of the variables $APPLCSF/$APPLOG and $APPLCSF/APPLOUT. If these variables are pointing to locations inside the COMMON_TOP directory

Linux Migration
structure (i.e. $COMMON_TOP/admin/out/$CONTEXT_NAME and $COMMON_TOP/admin/log/$CONTEXT_NAME you will need to copy these files into similar directory structures on the Target System.

Copy the security file for JInitiator If you wish to preserve the Source System digital signature on the migrated System, copy the identitydb.obj file from the Source System to the Target System. This file is located in the APPLMGR user's home directory on UNIX or the root directory of the %SystemDrive% on Windows. If you want the migrated System to have a new digital signature, remove the following file from the Target System: rm $APPL_TOP/admin/appltop.cer 3. Clone the AutoConfig XML context file on the Target System The Clone Context tool will ask for all the new mount points on the Target migration node. Log on to the Target System as the APPLMGR user and run the following commands: o cd <COMMON_TOP>/clone/bin o perl adclonectx.pl migrate java=[JDK HOME] \ contextfile=[SOURCE SYSTEM CONTEXT FILE]

c.

where: JDK HOME complete path where the JDK is installed.

Full Path to the Source System Applications XML SOURCE SYSTEM context file located in APPL_TOP/admin on the CONTEXT FILE Target System.

4. Respond to the prompts. This will create the following Target System context file: $APPL_TOP/admin/[SID]_[hostname].xml

Note: See document 216664.1 on OracleMetaLink for more information on port pool.

5. Install the Middle Tier Technology Stack Run the Rapid Install Wizard with the -techstack option to install the iAS technology stack. Use the Target System context file created in the previous step. cd [Stage11i]/startCD/Disk1/rapidwiz ./rapidwiz -techstack Follow the instructions in the "Installation Tasks" section of Installing Oracle9i Application Server 1.0.2.2.2 with Oracle Applications 11i" (document 146468.1).

Note: Use the latest startCD available in OracleMetalink. Refer to the

Linux Migration
"Current Version of Rapid Install" section in the Oracle Applications Release Notes for details on the latest startCD Patch. More details on how to execute rapidwiz can be found on the Oracle Applications 11iInstallation Manual. Attention: Review the log files (setup_stubs.[timestamp].log) under the iAS ORACLE_HOME to ensure that there are no errors.

6. Apply the Oracle interoperability patches for Red Hat Enterprise Linux If the Application System is 11.5.9 or lower, and on Red Hat Enterprise Linux 3.0 or 4.0, then apply the following Oracle server interopability patches.

Patches 3830807 3170128 3846086

Description Oracle 8.0.6.3 Interop patch Oracle 8.0.6 Interop patch for Discoverer 4i 8.1.7.4 Interop patch for iAS ORACLE_HOME

7. 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: o cd $AD_TOP/bin o ./adconfig.sh run=INSTE8_SETUP contextfile=[TARGET SYSTEM CONTEXT FILE]

Note: This command does not require the environment to be sourced.

8. Download and apply the customer-specific update with AutoPatch Within 30 minutes from the time you uploaded the manifest file at step 1.b you will receive a notification email saying that your customer specific update patch is ready. Follow the instructions in the email to download it from Oracle MetaLink. The patch should be applied on all Target System application nodes. Source the APPL_TOP environment file and follow the instructions in the README to apply the patch. AutoPatch will automatically relink the executables.

Note: Executables dependent on third party products (Ilog, Roguewave, Quantum) might fail during relinking. This is expected and is addressed in "Section 3: Finishing Tasks". In that case, answer "yes" when adpatch asks whether to "Continue as if it were successful".

9. Apply patch 3077161 (only if migrating from Windows): Only if you are migrating from Windows, download and apply the Linux patch 3077161 containing the Unix-specific files that don't exist in a Windows

Linux Migration
APPL_TOP. 10. Review the technology stack patch level Identify any patches previously applied to your Source System technology stack which are not included in the "Release Versions" section of " Installing Oracle9i Application Server 1.0.2.2.2 with Oracle Applications 11i" (document 146468.1). Apply these patches to your Target System technology stack.

Note: For information and instructions on applying the latest Developer 6i patchset, seeNote 125767.1 on OracleMetaLink

11. Download and apply the techstack interop patch Apply patch 4139957 to the Target Oracle Applications file system. 12. Regenerate the file system objects Source the APPL_TOP environment file and perform the following tasks to regenerate the platform dependent files on the Target System: . If migrating the Forms node, run the following script: $AD_TOP/patch/115/bin/adgensgn.sh [Apps User]/[Apps Password] a. Run adadmin to generate messages, forms, reports, graphics and jar files. 13. Run AutoConfig to complete the Target System configuration $AD_TOP/bin/adconfig.sh contextfile=[TARGET SYSTEM CONTEXT FILE]

Note: The database will be updated to reflect the new Target System profile. Make sure all users are off the system and shut down the Source System application tier server processes. After this step, the Source System middle tier will no longer be available.

Section 3: Finishing Tasks

This section lists tasks that may be necessary depending on your implementation and the intended use of the migrated System. 1. Update 3rd party extensions If your Applications System is implementing any products which use Ilog, Roguewave, or Quantum, you will need to update the Target System with the objects for the 3rd party extensions and relink any dependent products.

Software
ILOG

Details Apply patch 2837811 and relink dependent executables.

ROGUEWAVE Apply patch 3006092 and relink dependent executables. QUANTUM

Follow instructions in document 224273.1 on OracleMetaLink

2. Review and update your Target System application tier settings and customizations a. Recompile any custom code (forms, C) in the Target System

Linux Migration
APPL_TOP. b. If you were using UTF8 charset, Discoverer 4i, SSO or Portal 3i on the Source System, refer to the corresponding documentation to complete the migration:

Setup
UTF8

Documentation "Installing Oracle Applications 11i" Manual, Chapter 5, "Set Up UTF8 Character Set". Document 139516.1 on OracleMetaLink.

Discoverer 4i

SSO or Portal 3i Document 146469.1 on OracleMetaLink.

3. Update printer settings If the newly migrated System needs to utilize different printers, update the Target System with the new printer settings now. 4. Update Workflow configuration settings Migrating an Oracle Applications instance will not update the host and instance specific information used by Oracle Workflow. Review the following tables and columns to verify there is no instance-specific data in the Workflow configuration on the Target System.

Table Name

Column Name

Column Value Details

Value starts with http://[old web host] : Update to new web host Value starts with "http://[old web host] : Update to new web host Create a new System defined as the new global database name using the Workflow Administrator Web Applications responsibility. Value needs to be replaced with the database global name Update database link with the new database global name. Update with the new web host name

WF_NOTIFICATION_ATTRIBUTES TEXT_VALUE

WF_ITEM_ATTRIBUTE_VALUES TEXT_VALUE

WF_SYSTEMS

GUID

WF_SYSTEMS

NAME

WF_AGENTS

ADDRESS

FND_FORM_FUNCTIONS

WEB_HOST_NAME

Linux Migration
FND_FORM_FUNCTIONS WEB_AGENT_NAME Update to point at the new PLSQL listener name Update with the correct path to the logfile directory Update with the new directory path on the Target System

FND_CONCURRENT_REQUESTS LOGFILE_NAME

FND_CONCURRENT_REQUESTS OUTFILE_NAME

5. Review your CLASSPATH setting Log in to the Target APPL_TOP environment (source the environment file) and perform the following tasks to consolidate your CLASSPATH: a. Verify the AD classpath: Run $ADJVAPRG -version If the result shows a java version of 1.3.1 or higher, use Context Editor to update the variable s_adovar_classpath in the context file: replace appsborg.zip byappsborg2.zip in the classpath string. b. Verify the AF classpath: Run $AFJVAPRG -version If the result shows a java version of 1.3.1 or higher, use Context Editor to update the variable s_adovar_afclasspath in the context file: replace appsborg.zip byappsborg2.zip in the classpath string. c. Run AutoConfig as described in document 165195.1 on OracleMetalink. 6. Start all services on the Target System Start all services by running the script: adstrtal.sh [AppsUser]/[AppsPwd] located in $COMMON_TOP/admin/scripts/[CONTEXT NAME]

Export the source database and import into the newly created linux database