11i eBS TDB Version 3

Oracle 11i E-Business Suite Cross Platform Migration to AIX
This document can be found on the web, http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101174
Version 3.0 Dec 2010
Advanced Technical Skills, Americas Sanjay Ruprell Senior IT Specialist sruprell@us.ibm.com
Trademarks The following terms are registered trademarks of International Business Machines Corporation in the United States and/or other countries: AIX, AIX/L, AIX/L (AIX/L), IBM, IBM (IBM), pSeries, Total Storage, Power PC. The following terms are registered trademarks of International Business Machines Corporation in the United States and/or other countries; Power VM, Advanced MicroPartitioning, AIX 5L, AIX 6 (logo), Micro Partitioning, Power Architecture, POWER6, POWER6, POWER7, Redbooks, System p, System p5, System p6, System p7, System Storage. A complete list of U.S trademarks owned by IBM may be found at: http://www.ibm.com/legal/copytrade.shtml Oracle, Java and all Java based trademarks are registered trademarks of Oracle Corporation in the USA and/or other countries UNIX is a registered trademark in the United States, other countries or both.
Disclaimers While efforts have been made to verify the information, this paper may contain errors. IBM makes no warranties or representation with respect to the content hereof and specifically disclaim any implied warranties of merchantability or fitness for any particular purpose. IBM assumes no responsibility for any errors that may appear in this document. The information contained in this document is subject to change without notice. IBM reserves the right to make any such changes without obligation to notify any person of such revisions or changes. IBM makes no commitment to keep the information contained herein up to date.
IBM Copyright, 2007 http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101174 Oracle 11i E-Business Suite Cross Platform Migration to AIX.
Version 3, December 2010 Page No. 2
Table of Contents Introduction ....................................................................... 6 Oracle Transportable Database....................................... 7 Environment ...................................................................... 8 Prior to Migration ............................................................. 9 Hardware / Server ............................................................ 9 Initial AIX 6.1 tuning for the database & apps server ... 9 Software............................................................................ 9 AIX.................................................................................... 9 JAVA ............................................................................... 10 Visual Age C/C++ Compiler ......................................... 10 Oracle ............................................................................. 10 a) rootpre.sh ................................................................ 10 b) Oracle Universal Installer (OUI) ............................ 10 c) Other known OUI issues & workaround ................ 10 d) Oracle patches for AIX .......................................... 10 e) Other Oracle patches .............................................. 11 Storage & Other Considerations.................................... 11 a) JFS2 mount option for transfer of files. ................. 11 b) Data file fragmentation........................................... 12 c) Identifying & fixing fragmentation issues. ............ 12 Avoid Migration hazards................................................ 13
Database Migration ........................................................ 14 Open Database in READ ONLY mode ........................... 14 Verify Portability ............................................................ 14 Check for external objects .............................................. 14 SQL statement for creating control file .......................... 15 Edit script ....................................................................... 15 Target Database Server .................................................. 16 Transfer Data files from the source database server ..... 16 Create Control file ......................................................... 16 Convert data files using RMAN ...................................... 16 Tuning the conversion of data files ................................ 17 Shut down the database .................................................. 18 Copy files from staging area .......................................... 18 Open Database & miscellaneous completion tasks ....... 18 a) Create Temporary Table space ............................... 18 b) External Objects ..................................................... 19 c) Compile Invalid Objects......................................... 19 d) Set Up and Start the Database listener ................... 19 e) Enable AutoConfig on Database server ................. 19
Migrating the Applications node ................................... 20 Verify Patches on the source applications server .......... 20 Maintain Snapshot Information ..................................... 20 Request custom migration patch from Oracle................ 20 Set Up the Target APPL_TOP ....................................... 21 Copy the Security File for Jinitiator .............................. 21 Clone the AutoConfig XML context file ......................... 21 Install the Technology stack ........................................... 22 AutoConfig Setup............................................................ 22 Apply custom migration patch........................................ 22 Apply Techstack Interoperability patch ......................... 23 Regenerate file system objects........................................ 23 AutoConfig ..................................................................... 24 Finishing Tasks .............................................................. 24 Apply third party extension patches ............................ 24 Misc. and customizations ............................................ 24 Update printer settings ................................................. 24 Update workflow configuration settings ..................... 24 Review CLASSPATH setting ..................................... 25 AIX Specific Forms patches ........................................... 25 Start all services and test ............................................... 26 Summary.......................................................................... 27 References & Acknowledgements ................................. 28
Introduction
The objective of this document is to provide a detailed step by step approach on how to perform a cross platform migration of the Oracle E-Business Suite Database 10gR2 or higher and 11i (11.5.10.x) E-Business Suite Applications environment to AIX. Oracle database operations are similar on all operating systems. However deployment strategies can vary on different operating systems. Migration of an existing Oracle 11i E-Business Suite database to a new architecture can prove to be overwhelming initially due to many factors like New operating system Operating system preparedness Installation nuances Oracle patches Database migration 11i E-Business Suite Application Migration
Oracle Database 10gR2 introduced the transportable database feature which is used for migration of the 11i E-Business Suite database. This is certified by Oracle in the series of steps described in My Oracle Support (MOS) note id 729309.1. Oracle 11i E-Business Suite Application migration is done with a series of procedures described in MOS note id 238276.1. This document is targeted towards users migrating from Solaris and HP-UX to AIX and covers topics mentioned above. The migration steps documented in this paper have been leveraged at numerous customer sites successfully and lessons learnt during these migrations are also included. For the purpose of this document, the source environment is on Sun Solaris and will be referred to as source database. The AIX environment will be referred to as the target database.
Oracle Transportable Database

Oracle Database 8i introduced the Transportable Table Space (TTS) feature. However, with the release of Oracle 10gR1, this feature has become more useful because the transportable table space feature now supports cross-platform migration. With the release of Oracle Database 10g Release 2 (10gR2), there is now support for transporting an entire database across platforms that share the same endianness. (Note: Endianness refers to the method for sequencing byte order. The big-endian convention arranges most significant byte first, little-endian sequences less significant byte first.). This feature is now known as Transportable Database (TDB). In short, transportable table space has evolved into Transportable Database in Oracle 10gR2 and higher. This paper assumes that the reader has: A high degree of Oracle database-administrator (DBA) skills and is, therefore, well-versed with the import(imp) and export(exp) process A fair amount of UNIX system-administrator skills or the assistance of a UNIX system administrator who can help you in moving files from one system to another By transporting the entire database, it is now possible to replicate the database environment across platforms that share the same endianness. The following table classifies the big-endian and little-endian platforms.
Big-endian AIX 5L and Linux on POWER IBM System z and Linux HP UX (IA-64) HP UX (64-bit) Sun Solaris (SPARC 32- and 64-bit) Apple Mac OS Little-endian Microsoft Windows (32- and 64-bit bit) Windows 64-bit for AMD HP Tru64 UNIX HP Open VMS Solaris (x86) Linux IA (32/64 bit), Linux 64-bit for AMD
Oracle10gR2 (10.2.0.1) or higher is required for transporting a database. The next few steps explain the process for transporting an Oracle 10gR2 database from Sun Solaris to AIX . These steps are the same as they would be if you were transporting a database from any big-endian platform to AIX.
Environment
Source System Configuration: Hardware: Sun Fire V440 Server Software: Solaris 5.9 Oracle 10gR2 (10.2.0.4) or higher 4 x Ultra SPARC IIIi @ 1.59 GHz 32 GB RAM Direct Attach Storage D1000 Arrays.
Target System Configuration: Hardware: IBM p6 570 Software: AIX 6 Visual Age C/C++ Professional v7.0 Oracle 10gR2 (10.2.0.4) or higher 2 x POWER6 CPU @ 3.5 GHz 32 GB RAM IBM N3700.
Prior to Migration
Hardware / Server
Initial AIX 6.1 tuning for the database & apps server
a) Network tuning (interface level) tcp_sendspace & tcp_recvspace=262144 tcp_nagle_limit & tcp_nodelayack = 1 rfc1323=1 b) ioo numfsbufs=1568 j2_maxPageReadAhead=256 c) Misc ulimit a for oracle & apps user should return unlimited for all (except core) maxuproc=4096 export AIXTHREAD_SCOPE=S for oracle and apps user For AIX 5.3 tuning, please refer to a document titled Oracle Architecture & Tuning on AIX and a link to this document is included in the reference section
Software AIX
Following file sets are required for Oracle database and Apps servers. Use the command lslpp l | grep <file set name> to verify the existence of a file set bos.adt.base bos.adt.lib bos.adt.libm bos.perf.libperfstat bos.perf.perfstat bos.perf.protocols xlC.aix.rte
AIX patches should be consistent with MOS note id. 282036.1 Minimum software version and patches required to support Oracle products on IBM Power System.
IBM Copyright, 2007 http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101174 Oracle 11i E-Business Suite Cross Platform Migration to AIX. Version 3, December 2010 Page No. 9
JAVA
AIX uses IBM JDK only for all Oracle products. Depending on the version of the database and the E-business Suite, appropriate version of JAVA should be installed. The version of JDK should be consistent with the source server. For certification of JAVA on Power7 server, please review the references section for additional details.
Visual Age C/C++ Compiler

Oracle 11i E-Business Suite requires the Visual Age C/C++ compiler 6.0.0.5 and October 2003 PTF (or higher) for AIX 5L or IBM XL 7.0 C/C++ (or higher) on the apps server. Reference -MOS Note id 287453.1 Oracle Applications 11.5.10 Installation Update Notes. Note. XL C/C++ is the follow-on product for VisualAge.
Oracle
The Oracle database version and patches should be consistent with the source server.
a) rootpre.sh
rootpre.sh script is required to be run as a root user prior to invoking the Oracle Universal Installer (OUI) and the rapidwiz installer for apps. Depending on the Oracle & AIX versions, rootpre.sh prepares AIX system for Oracle installation. This script should be executed only once for multiple oracle homes/versions. Do not run the rootpre.sh if there is a newer release of Oracle database already installed on the system.
b) Oracle Universal Installer (OUI)

Oracle installer (OUI) in 10gR2 does not recognize AIX 6.1 as a supported operating system. Use the runInstaller ignoreSysPrereqs.
c) Other known OUI issues & workaround

OUI crash with IBM JDK/JRE 1.5 on POWER7 architecture Ref. MOS Note id 1065579.1 OUI has detected processes running Ref. MOS Note id 287428.1
d) Oracle patches for AIX

Patches listed in this section are bare minimum and pertain only to migration and/or performance. These patches must be installed to begin a successful transition to AIX. a) 10.2.0.4 (10gR2) Patch 7226548 Default enable 64k pagesize support for SGA
b) 11.1.0.7 (11gR1) Patch 7893016 RMAN convert fails with ORA-600 c) 11.2.0.1(11gR2) Patch 7893016 RMAN convert fails with ORA-600
e) Other Oracle patches

The source database server may have some additional generic Oracle patches installed and for consistency, these patches should also be installed on the target database server. On the source database server do an opatch lsinventory to generate a list of Oracle patches installed. Download the equivalent AIX patches from Oracle support site and install it. After the patch installation, create the init.ora file in compliance with MOS note id 216205.1 - Database Initialization Parameters for Oracle Applications Release 11i, and test it out with a startup nomount command. Note. Disable the audit related parameters in the init.ora. Enable them after the migration is completed.
Storage & Other Considerations

The bulk of Oracle database migration time is spent on copying data files between two different host systems. File transfer is accomplished by copying via NFS mounted file systems or FTP over the network. Before the transfer of data files, its important to discuss a couple of issues which can cause performance degradation and/or slow the copy process.
a) JFS2 mount option for transfer of files.

For the purpose of copy/ftp, do not explicitly mount the file system with cio option as this will considerably slow down the copy process because file system operations with a small block size are less efficient on a cio mounted file system. For the purpose of copying, it is recommended to mount the target file system with release behind write (rbw) option. This will enhance serial copy process and also releases the memory pages after they are written to disk. As soon as the copy process is completed, unmount and mount the file system with default options. For general database operations for Oracle 10g & higher on AIX, it is recommended to use concurrent I/O (cio) via Oracle (init.ora parameters filesystemio_options=setall & disk_async_io=true) with default mount options. The control files and redo logs should be isolated in a separate JFS2 file system which has been created with a block size (agblk) of 512 bytes.
Explicit cio mount option should only be used if there is a need for an external access (cp, dd, cpio) to the oracle data files after the database has been opened. It is beyond the scope of this document to discuss all other AIX/Oracle tuning topics, however this is covered in a document titled Oracle Architecture & Tuning on AIX and a link to this document is included in the Reference section.
b) Data file fragmentation.

Fragmentation will occur when multiple copy/ftp processes are run concurrently on a single file system to copy data files in parallel. Data file fragmentation has the potential to introduce serious performance issues, hence it important to do it right the first time. In order to avoid fragmentation, it is recommended to run the copy/ftp process sequentially within each file system. You have the flexibility to copy multiple file systems in parallel while observing the recommended serial copy procedure within each file system. c) Identifying & fixing fragmentation issues. AIX provides the fileplace command which displays the placement of a specified file within the logical or physical volume containing the file. fileplace v displays more information about the file and its placement, including statistics on how widely the file is spread across the volume and the degree of fragmentation in the volume.
#fileplace v tx_idx09.dbf File: tx_idx19.dbf Size: 2097160192 bytes Vol: /dev/oradata_lv Blk Size: 4096 Frag Size: 4096 Nfrags: 512002 Inode: 73913 Mode: -rw-r----- Owner: oracle Group: dba Logical Extent -------------40870240-40870271 40870368-40870399 40870464-40870495 40870560-40870591 40870656-40870687 . . . . 41217280-41217311 41217344-41637599 01625266-01625267 32 frags 420256 frags 2 frags 131072 Bytes, 1721368576 Bytes, 8192 Bytes, 0.0% 82.1% 0.0%
32 32 32 32 32
frags frags frags frags frags
131072 131072 131072 131072 131072
Bytes, Bytes, Bytes, Bytes, Bytes,
0.0% 0.0% 0.0% 0.0% 0.0%
512002 frags over space of 40012334 frags: space efficiency = 1.3% 2845 extents out of 512002 possible: sequentiality = 99.4%
The sequentiality % is more important than the space efficiency %. A high sequentiality % indicates that when a file is read, it won't be moving the actuator (a seek) much due to fragmentation.
A high space efficiency indicates the file's pieces are all close together, but the file could be fragmented requiring lots of seeks to read it, but at least the actuator won't have to move far. The only way to defragment a fragmented file is to create a scratch file system and sequentially copy out the file and sequentially copy in again.
Avoid Migration hazards

Migrate & Upgrade. Migration exercise also provides an opportunity to upgrade the database version, apps version or any component (JDK, forms, 8.0.6 client etc) within the applications stack. It is recommended to always perform any kind of upgrade on the source server prior to migration for the following reasons. It becomes difficult to compare performance between the source and target environments due to different versions. Any potential issues uncovered during the migration process may be difficult to pin point due to version change. It always a good idea to upgrade first, test the performance of the upgraded component.
Applications tier migration. Applications tier migration is a sequence of steps. Do not change the order, or circumvent/ skip any step. Examine the log files generated by every step for any errors and rectify them prior to moving to the next step. Always keep the source database in read only mode or in a shut down state until the applications migration is completed. It has been observed that if the source database is open it can be potentially updated by the target migration steps due any user error in the migration process.
Database Migration
Open Database in READ ONLY mode
The first step is to open the database in READ ONLY mode as follows. Unless mentioned otherwise, all the steps mentioned below are to be performed on the source database server.
SQL> startup mount ORACLE instance started. Total System Global Area 4815060992 bytes Fixed Size 2077752 bytes Variable Size 905972680 bytes Database Buffers 3892314112 bytes Redo Buffers 14696448 bytes Database mounted. SQL> alter database open read only; Database altered. SQL>
Verify Portability
The next step is to verify the portability of the database by running the following SQL script which uses the DMS_TDB.CHECK_DB function. If the database is not transportable the SQL script will give an error message.
SET SERVEROUTPUT ON DECLARE db_ready BOOLEAN; BEGIN db_ready := DBMS_TDB.CHECK_DB('AIX-Based Systems (64-bit)'); END; / PL/SQL procedure successfully completed.
Check for external objects

The next step checks for the existence of any external objects within the database, like directories, tables and lists them.
SET SERVEROUTPUT ON DECLARE external BOOLEAN; BEGIN external := DBMS_TDB.CHECK_EXTERNAL; END; / The following directories exist in the database: SYS.APPS_DATA_FILE_DIR, SYS.HZ_DNB_SOURCE_DIR, SYS.DATA_PUMP_DIR, SYS.ADMIN_DIR,SYS.WORK_DIR
SQL statement for creating control file

The next step generates the trace file which contains the create control file statement for control file. The file is generated in the oracle user dump (udump) area as defined in the init.ora. The file will be used on the target database server to create the control file.
SQL> alter database backup controlfile to trace;
Edit script
Edit the trace file which was generated earlier to create the control file. The trace generates two SQL statements for the creating the control file. For the purpose of migration we will use the section of RESETLOGS (usually set #2 in the file). Edit the path to reflect the locations of the data files on the target server. Delete all the other lines. The contents of your file would be similar as follows :
STARTUP NOMOUNT PFILE='/oracle/db/10gr2/dbs/initPROD.ora' CREATE CONTROLFILE REUSE SET DATABASE "VIS" RESETLOGS NOARCHIVELOG MAXLOGFILES 32 MAXLOGMEMBERS 5 MAXDATAFILES 512 MAXINSTANCES 8 MAXLOGHISTORY 3635 LOGFILE GROUP 1 '/oracle/oradata/log1.dbf' SIZE 7999M, GROUP 2 '/oracle/oradata/log2.dbf' SIZE 7999M DATAFILE '/oracle/oradata/sys1.dbf', '/oracle/oradata/sys2.dbf', '/oracle/oradata/sys3.dbf', . . . '/oracle/oradata/reference10.dbf', '/oracle/oradata/undo07.dbf', '/oracle/oradata/undo08.dbf', '/oracle/oradata/undo09.dbf', '/oracle/oradata/sys8.dbf', '/oracle/oradata/sys9.dbf', '/oracle/oradata/apps_assm_data.dbf', '/oracle/oradata/apps_assm_idx.dbf' CHARACTER SET UTF8; spool off
After editing, copy this script to the target server for later use. The source database can be either shut down or left in a read-only mode.
Target Database Server

The action now shifts to the Target Database server. The source database is still open in read only mode.
Transfer Data files from the source database server

The first step involves transferring the Oracle data files from the source database server using NFS mount or via FTP. Ensure that the files are placed in the file system as mentioned in the create control file script. Redo logs and temp table space data files need not be transferred as they will be re-created on the target database server. After the transfer, the source database can now be shut down.
Create Control file

In the second step the control file is created. The init.ora parameter file should be set up at this point as per the pre-requisites. Verify the location of the control files in the init.ora. Run the script to create the control file.
Convert data files using RMAN

In the third step, SYSTEM & UNDO table spaces related data files are converted and created in the staging area (oradata_new) using the RMAN command. The other data files are not converted (Ref. MOS note id 732053.1 Avoid data file conversion during Transportable Database)
$ORACLE_HOME/bin/rman target / log='convert.log' @@convert_script.rman . . Starting backup at 01-FEB-07 using channel ORA_DISK_1 using channel ORA_DISK_2 channel ORA_DISK_1: starting datafile conversion input filename=/oracle/oradata/system01.dbf converted datafile=/oradata_new/system01.dbf channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:01:16 Finished backup at 01-FEB-07 Starting backup at 01-FEB-07 using channel ORA_DISK_1 using channel ORA_DISK_2 channel ORA_DISK_1: starting datafile conversion input filename=/oracle/undo.dbf converted datafile=/oradata_new/undo.dbf channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:01:06 Finished backup at 01-FEB-07 RMAN> RMAN> **end-of-file**
Tuning the conversion of data files

In every migration exercise, the migration window is usually of limited time duration; hence time is of the essence. With some creativity we can convert data files in parallel and reduce the overall conversion time to as much as fifty percent. This can be achieved as follows create one script for every data file to be migrated create a shell script which calls the individual RMAN script and runs it in the background mode
$cat datafile1.rman RUN { CONVERT DATAFILE '/oracle/oradata/system01.dbf' FROM PLATFORM 'Solaris[tm] OE (64-bit)' FORMAT '/oradata_new/system01.dbf; } EXIT; $cat datafile2.rman RUN { CONVERT DATAFILE '/oracle/oradata/system02.dbf' FROM PLATFORM 'Solaris[tm] OE (64-bit)' FORMAT '/oradata_new/system02.dbf; } EXIT; $ cat parallel_convert.sh #!/bin/ksh rman target=/ @datafile1.rman log=datafile1.log & rman target=/ @datafile2.rman log=datafile2.log & rman target=/ @datafile3.rman log=datafile3.log & wait $ rman target=/ @datafile4.rman log=datafile4.log &
..
In the above example the datafile1.rman and datafile2.rman represent scripts for individual files to be converted. The shell script parallel_convert.sh starts the RMAN command in background mode and waits until the third data file conversion is completed before it starts another set of data file conversions. Depending on the CPU utilization the wait statement can be put after two or four data files. In this way we can convert multiple data files.
Shut down the database

Examine the conversion log files for any error. After the conversion is completed successfully, the database is shut down.
SQL> shutdown immediate ORA-01109: database not open Database dismounted ORACLE instance shutdown
Copy files from staging area

Once the conversion is completed, we copy the converted data files (SYSTEM & UNDO) from the staging area (ordadata_new) to the location specified in the control file. In this example the data files are moved from staging area (/oradata_new) to /oracle/oradata. As per the create control file statements, the data files should be present in the /oracle/oradata directory.
$ $ cd /oradata_new
$ pwd $ /oradata_new $ cp * /oracle/oradata
Open Database & miscellaneous completion tasks

Lastly the database is opened; a recovery is performed using the backup control file and redo logs are reset as follows.
SQL> startup mount ORACLE instance started. Total System Global Area 1744830464 bytes Fixed Size 2071768 bytes Variable Size 654312232 bytes Database Buffers 1073741824 bytes Redo Buffers 14704640 bytes Database mounted. SQL> recover database using BACKUP CONTROLFILE until cancel; . . . . Specify log: {=suggested | filename | AUTO | CANCEL} cancel ----------------------------------------------> Type Cancel Media recovery cancelled. SQL> alter database open resetlogs;
The database migration is complete, however before the database can be used, there are a few additional tasks need to be completed.
a)
Create Temporary Table space
Create the temporary table space as sized on the source database server
SQL> create temporary tablespace temp_table_space_name SQL> tempfile '/xxx/temp.dbf' size 32m autoextend on SQL> extent management local;
b)
External Objects
Use export / import, Data Pump or recreate the external objects on target database server.
c)
Compile Invalid Objects

$<10g ORACLE_HOME>/rdbms/utlrp.sql script.
Using SQLPLUS login as sqldba and compile the invalid objects using the
d)
Set Up and Start the Database listener
Copy the listener.ora from the source database server and make necessary editing to reflect the target hostname and the oracle home. Start the database listener.
e) Enable AutoConfig on Database server

For the purpose of applications tier migration, autoconfig should be enabled on the target database tier. On the source Applications node Execute $AD_TOP/bin/admkappsutil.pl to generate appsutil.zip for the database tier. Transfer this appsutil.zip to database tier in the <10g ORACLE_HOME>. Unzip this file to create appsutil directory in the <10g ORACLE_HOME>. Set the following environment variables as
o o o o o ORACLE_HOME =<10g ORACLE_HOME> LD_LIBRARY_PATH = <10g ORACLE_HOME/lib, <10g RACLE_HOME>/ctx/lib> ORACLE_SID = instance name running on this database node. PATH= $PATH:<$10g ORACLE_HOME>/bin; TNS_ADMIN = <$10g ORACLE_HOME>/network/admin
From the <10g ORACLE_HOME/appsutil/bin> directory, create an instance-specific XML context file by executing the command:
$ perl adbldxml.pl tier=db appsuser=<userid> appspasswd=<password>
From the <10g ORACLE_HOME>/appsutil/bin directory, execute AutoConfig on the database tier by running the adconfig.pl script. Check the AutoConfig log file located in <10g ORACLE_HOME>/appsutil/log/
The database migration is now complete. Its advisable to take a cold backup of the database at this point in time.
Migrating the Applications node

This section of the document is based on MOS note id 238276.1. Please refer to this note during a migration project, as the patch numbers mentioned in this document can be superseded by newer patches.
Verify Patches on the source applications server

Generate a patch list via sqlplus <AppsUsr>/<AppsPwd> @$AD_TOP/sql/adutconf.sql, verify the following patches are installed AD.I.5 (5161680) or higher is required If source applications was created using 11.5.8 or earlier, implement the autoconfig as per Oracle MOS note id 165195.1 Apply the latest AutoConfig template patch as per Oracle MOS note id 165195.1 Apply the latest Rapid Clone patch as per Oracle MOS note id 230672.1
Maintain Snapshot Information

Run adadmin to maintain snapshot information on application tier node.
adadmin 2. Maintain Applications Files menu 5. Maintain Snapshot information 2. Update current view snapshot
Request custom migration patch from Oracle

Log in to the source application tier node as apps user and source the environment file. Execute the following command to generate the customer specific file manifest which will be output in $APPL_TOP/admin/$TWO_TASK/out.
$ perl $AD_TOP/bin/adgenpsf.pl
Go to http://updates.oracle.com/PlatformMigration and login using the My Oracle support user id and password. Follow the instructions on the screen to upload the manifest file previously generated. An email is sent out in 30 minutes with details on how to download the migration patch. If an email notification does not arrive in thirty minutes or so, login to the same site and download the patch.
Set Up the Target APPL_TOP

Copy the middle tier file system from the Source Applications System to the Target Node in the order listed. This should be done by the target system apps user. 1. <APPL_TOP> 2. <OA_HTML> 3. <OA_JAVA> 4. <COMMON_TOP>/util 5. <COMMON_TOP>/_pages Note. Copy only the directories listed, not the full COMMON_TOP.
Copy the Security File for Jinitiator

If the source system digital signature needs to be preserved on the migrated system, copy the identitydb.obj from the source system. This file is located in the apps user home directory. If a new digital signature is required, remove the $APPL_TOP/admin/appltop.cer file
Clone the AutoConfig XML context file

Log on to the target system as the apps user and run the following command from $AD_TOP/bin
$ perl adclonectx.pl migrate java=<JAVA HOME> contextfile=<sourcecontext file>
Where <JAVA HOME> - absolute path where JDK is installed <source context file> - absolute path pointing to copied source system applications XML context file located in APPL_TOP/admin
The clone context tool will ask for all the new mount points, port information for the target migration node. This will create the target system context file in APPL_TOP/admin/<SID>_<hostname>.xml.
Install the Technology stack

Install the tech stack from 11i media. Use the rapidwiz techstack option to install the iAS technology stack. When prompted for the Applications Context file, select open an existing context file and provide the path and the context file name created in the earlier step. Note. If the rapidwiz installer displays updating Oracle Inventory message for a long time and shows no progress after that, then open a telnet window and search for a writer.lock file in the Oracle inventory directory and rename it.
AutoConfig Setup
This is the most important step in the entire cloning process of the apps tier node. This step populates the target database server with all the relevant target apps server information and uses the applications context file generated earlier. Anything wrong information in the applications context file can potentially update the source database server hence the source database should be either shut down or be in the read only mode. Prior to running this command it is advisable to use the grep command on the applications context file and check values on the target host for s_dbhost, s_dbsid, s_dbport. This command will also create the apps environment file.
$./adconfig.sh run=INSTE8_SETUP context_file=<target system contextfile>
Note. Ignore any adident executable errors as this executable is still an Solaris/HP executable at this point. Exit out form the telnet session, login back and source the newly generated environment file. Verify that /usr/vaccp/bin in included in $PATH.
Apply custom migration patch

The custom migration patch which was requested in step 4, should be downloaded and applied, In order for this patch to run successfully, all the object files and archives (.o and .a files) need to be removed. The patch should be applied using adpatch command which is delivered with the patch. Source the environment file, run the following shell script and then apply the patch.
for top_name in `ls $APPL_TOP` do if [ -d $APPL_TOP/$top_name/11.5.0/lib ]; then cd $APPL_TOP/$top_name/11.5.0/lib rm *.o rm *.a ar rv lib$top_name.a fi done $. /adpatch options=noprereq uses the adpatch provided by the migration patch
Note: Executables dependent on third party products (Ilog, Roguewave, and Quantum) might fail during relinking. This is expected and is addressed in "Section 14: Finishing Tasks". In that case, answer "yes" when adpatch asks whether to "Continue as if it were successful". Shared top binaries do not get relinked and need to be relinked manually:
$ adrelink.sh force=y crp CYCPLN $ adrelink.sh force=y crp CYCCRP $ adrelink.sh force=y crp CYRRCP $ adrelink.sh force=y crp CYQLIB $ adrelink.sh force=y crp CYCROL
Apply Techstack Interoperability patch

Download and apply interoperability patch 4139957 to target applications node. Note. All other techstack patches which have been applied on your source application server should be applied at this point (example. Forms 6i patch)
Regenerate file system objects

Source the APPL_TOP environment file and perform the following tasks to regenerate the platform dependent files on the Target System
$ $AD_TOP/patch/115/bin/adgensgn.sh <Apps User>/<Apps Password>
Run adadmin to generate messages, forms, reports, graphics and jar files.
AutoConfig
Run adconfig.sh to update the database.
$ $AD_TOP/bin/adconfig.sh contextfile=<Target System context file>
Finishing Tasks
The entire task list mentioned in this section is optional depending on your specific environment.
Apply third party extension patches

If any of the Applications modules use ilog, Roguewave or Quantum, please apply the following patches and re-link any dependent products. 1. ILOG Patch 2837811 2. ROUGEWAVE Patch 3006092 3. QUANTUM Follow instructions in MOS note id 224273.1
Misc. and customizations

1. Recompile any custom form or Pro*C on the target system 2. If using UTF8 charset, Discoverer 4i, SSO or Portal 3i o For UTF8 refer to Installing Oracle Applications 11i Chapter 5, Setup UTF8 Character set o For Discoverer 4i refer to MOS note id 139516.1 o For SSO or Portal 3i refer to MOS note id 146469.1
Update printer settings

Update the target system with the new printer settings.
Update workflow configuration settings

Workflow configuration settings need to be updated manually. Review the following tables and columns to verify there is no instance-specific data in the Workflow configuration on the Target System. Table Name
WF_NOTIFICATION_ATTRIBUTES WF_ITEM_ATTRIBUTE_VALUES WF_SYSTEMS WF_SYSTEMS WF_AGENTS
Column Name
TEXT_VALUE TEXT_VALUE GUID NAME ADDRESS
Column Value Data

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 Admin Web Applications responsibility Replace it with db global name Update new DB link
FND_FORM_FUNCTIONS FND_FORM_FUNCTIONS FND_CONCURRENT_REQUESTS FND_CONCURRENT_REQUESTS
WEB_HOST_NAME WEB_AGENT_NAME LOGFILE_NAME OUTFILE_NAME
Update it to new web hostname Update it to new plsql listener name Update correct logfile directory path Update with new directory path
Review CLASSPATH setting

Log in to the target apps tier node, source the environment and verify the following Verify AD CLASSPATH. Run $ADJVAPRG -version. If the results show 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 by appsborg2.zip in the classpath string. Run $AFJVAPRG version. If the results show 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 by appsborg2.zip in the classpath string. Any changes to the context file should always be completed by running AutoConfig as described in MOS note id 165195.1.
AIX Specific Forms patches

Depending on your Oracle forms version, you may need to apply an AIX specific patch. When a form is obtaining a long list of values, the operation may fail and the following two Oracle Forms error messages will be displayed. FRM-40815 : Variable GLOBAL.LLL10 does not exist FRM-40502 : Oracle error : unable to read list of values. Bug 4670400: This is the main bug for the above problem. Patch for this bug is for Forms version 6.0.8.25.x (Patch 16) only. Bug 4689213: Backport for Forms 6.0.8.24.x (Patch 15) Bug 4689364: Backport for Forms 6.0.8.26.x (Patch 17)
Start all services and test

Start all services by running following script in <COMMON_TOP>/admin/scripts/<ContextName>.
$ adstrtal.sh <AppsUser>/<AppsPwd>
Review the logs of all the services. After verification, backup the entire applications file systems. Note. If the concurrent managers fail to start up, from the sql prompt execute the fnd_conc_clone.setup_clean and re-run adautocfg. This step will clean up the FND_NODES table and will enable the concurrent manager to start up.
Summary
Transition to a new architecture is an expensive proposition. In order to be successful, proper planning is the key for all Oracle platform migration projects. Its important to identify and line up all resources prior to execution. Every migration exercise is different and hence multiple mock migrations are essential to a successful transition as they provide an opportunity to tune the migration. Oracle Transportable Database certainly helps in migrating complex databases. The introduction of Transportable Database provides a highly performing and straightforward migration technology than earlier Export/Import or Data Pump options. However some infrastructure challenges remain as an obstacle for faster cross platform migration. Transferring large data files from source to target via the network can take time. This can be challenging for very large database sizes which can run into multiple terrabytes. Technologies like VERITAS Portable Data Containers can be utilized to overcome moving the data files. This concludes the topics for this document. Please refer to the listings in the References section for sources of additional information on questions that you may have,
IBM Copyright, 2007 http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101174 Oracle Database Cross Platform Migration to AIX.
Version 2, March 2009 Page No. 27
References & Acknowledgements

Oracle Architecture & Tuning on AIX http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100883 My Oracle Support Notes 282036.1 - Minimum software versions and patches required to support Oracle products on IBM Power System. 468472.1 rootpre.sh script and rootpre directory are missing from the Oracle 11g Release 1. 362203.1 - Oracle E-Business Suite Release 11i with Oracle Database 10g Release 2 Interoperability notes. 452783.1 - Oracle E-Business Suite Release 11i with Oracle Database 11g Release 1 Interoperability notes. 881505.1 Oracle E-Business Suite Release 11i with Oracle Database 11g Release 2 Interoperability notes. 216205.1 Database Initialization Parameters for Oracle Applications Release 11i. 1068136.1 Database is slow after applying the January 2010 CPU. Oracle patches Patch 6613550 rootpre.sh JAVA for POWER7 information is available on this link http://www.ibm.com/developerworks/java/jdk/power7/index.html
Acknowledgements
Several people provided technical input and guidance for this paper including: Peter Barnett Dan Braden Timothy Spencer Stephen Poon
IBM Copyright, 2007 http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101174 Oracle Database Cross Platform Migration to AIX.
Version 2, March 2009 Page No. 28

11i eBS TDB Version 3

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

11i eBS TDB Version 3

Uploaded by

Copyright:

Available Formats

Oracle 11i E-Business Suite Cross Platform Migration to AIX

This document can be found on the web, http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101174

Version 3.0 Dec 2010

Advanced Technical Skills, Americas Sanjay Ruprell Senior IT Specialist sruprell@us.ibm.com

Version 3, December 2010 Page No. 2

Version 3, December 2010 Page No. 3

Version 3, December 2010 Page No. 4

Version 3, December 2010 Page No. 5

Version 3, December 2010 Page No. 6

Oracle Transportable Database

Version 3, December 2010 Page No. 7

Version 3, December 2010 Page No. 8

Visual Age C/C++ Compiler

b) Oracle Universal Installer (OUI)

c) Other known OUI issues & workaround

d) Oracle patches for AIX

Version 3, December 2010 Page No. 10

e) Other Oracle patches

Storage & Other Considerations

a) JFS2 mount option for transfer of files.

Version 3, December 2010 Page No. 11

b) Data file fragmentation.

frags frags frags frags frags

131072 131072 131072 131072 131072

Bytes, Bytes, Bytes, Bytes, Bytes,

0.0% 0.0% 0.0% 0.0% 0.0%

Avoid Migration hazards

Version 3, December 2010 Page No. 13

Check for external objects

Version 3, December 2010 Page No. 14

SQL statement for creating control file

Version 3, December 2010 Page No. 15

Target Database Server

Transfer Data files from the source database server

Create Control file

Convert data files using RMAN

Version 3, December 2010 Page No. 16

Tuning the conversion of data files

Version 3, December 2010 Page No. 17

Shut down the database

Copy files from staging area

Open Database & miscellaneous completion tasks

Create Temporary Table space

Compile Invalid Objects

Set Up and Start the Database listener

e) Enable AutoConfig on Database server

Version 3, December 2010 Page No. 19

Migrating the Applications node

Verify Patches on the source applications server

Maintain Snapshot Information

Request custom migration patch from Oracle

Version 3, December 2010 Page No. 20

Set Up the Target APPL_TOP

Copy the Security File for Jinitiator

Clone the AutoConfig XML context file

Version 3, December 2010 Page No. 21

Install the Technology stack

Apply custom migration patch

Version 3, December 2010 Page No. 22

Apply Techstack Interoperability patch

Regenerate file system objects

Version 3, December 2010 Page No. 23

Apply third party extension patches

Misc. and customizations