Migrating Oracle E-Business Suite 11i from Sun Solaris to ... · PDF fileCreate a test...

Code notice ........................................................................................................................................ 3

Executive summary ............................................................................................................................... 5

Introduction ......................................................................................................................................... 5 Conventions .................................................................................................................................... 6 Software versions ............................................................................................................................. 7

Performing the migration of the EBS database to HP-UX............................................................................ 8 Preparation of the target HP Integrity server with HP-UX ........................................................................ 8

Install the HP-UX 11i v3 operating system ........................................................................................ 9 Verify pre-requisite HP-UX patches for Oracle 10.2.0.4 .................................................................. 10 Update HP-UX operating system parameters .................................................................................. 11 Create accounts and groups for the database software ................................................................... 13 Configure networking ................................................................................................................. 13 Plan your disk storage requirements and layout .............................................................................. 14

Installation of the Oracle RDBMS product on HP-UX Integrity ............................................................... 15 Install the base 10.2.0.1 Oracle Database software ....................................................................... 15 Upgrade the database to 10.2.0.4 .............................................................................................. 16 Create a test database using the 10.2.0.4 Oracle Home ................................................................ 16 Create the Oracle 9i NLS data directory ....................................................................................... 16

Migrating the database from Solaris to HP-UX ................................................................................... 17 Step 1: Check that pre-requisites are met for using transportable database ........................................ 18 Step 2: Handle external and platform-specific data ........................................................................ 21 Step 3: Create conversion scripts and templates using rman ............................................................ 24 Step 4: Make the source data files from Solaris available on the target HP-UX system ......................... 26 Step 5: Convert the data files and create the database on HP-UX ..................................................... 27 Step 6: Handle the external and platform-specific data ................................................................... 31 Step 7: Implement EBS‟s AutoConfig ............................................................................................. 33 Step 8: Update the application tier configuration to use the new database ........................................ 36 Step 9: Testing the new EBS database .......................................................................................... 37

Migrating the EBS application tier to Linux ............................................................................................ 38 Preparation of HP BL460c target server with Oracle Enterprise Linux 5.1 .............................................. 38

Initial Oracle Enterprise Linux 5.1 installation ................................................................................ 38 Prepare the Oracle Enterprise Linux 5 update 1 environment ........................................................... 39

Preparation of the Oracle E-Business Suite 11i source server ............................................................... 43 Validating EBS software levels ..................................................................................................... 43 Create a current snapshot of the application environment ................................................................ 44

Migrate the EBS application software components ............................................................................. 45 Step 1: Build a source system manifest and generate the migration patch ......................................... 45 Step 2: Create the target system APPL_TOP files leveraging the source system installation ................... 46 Step 3: Copy or update the JInitiator security information ................................................................ 47

Migrating Oracle E-Business Suite 11i from

Sun Solaris to an HP-UX and Linux split

configuration

Step 4: Construct an AutoConfig XML context file on the target Linux server ...................................... 47 Step 5: Install the middle-tier technology stack and customer-specific EBS application tier patch ........... 48 Step 6: Update the platform-specific EBS business application components ....................................... 49 Step 7: Update the Tech Stack to match the source system level ....................................................... 50 Step 8: Apply the tech stack interoperability patch ......................................................................... 50 Step 9: Regenerate the file system objects ..................................................................................... 51 Step 10: Complete the full AutoConfig configuration of the target Linux system .................................. 51 Step 11: Update third-party extensions .......................................................................................... 52 Step 12: Review any site-specific customizations from the source system ........................................... 52 Step 13: Update font information if the UTF8 character set was in use .............................................. 53 Step 14: Migrating complimentary Oracle software ....................................................................... 53 Step 15: Update printer settings ................................................................................................... 54 Step 16: Update workflow configuration settings ............................................................................ 54 Step 17: Update additional database table based configuration settings .......................................... 55 Step 18: Update CLASSPATH settings ........................................................................................... 56 Step 19: Execute the final AutoConfig session for the migration ....................................................... 56

Testing the new environment ............................................................................................................ 57

For more information .......................................................................................................................... 58

3

Code notice

This document contains examples of code (“Code”) that you may want to use in building or

developing your own application. You may use this Code only as permitted herein. By your use of

Code, you agree to the terms below. The Licensor, Hewlett-Packard Development Company, L.P.

("HPDC"), grants you the rights listed below.

You may use the Code either by referring to it when developing your own application, copying it in

whole or in part into your application, or building upon a portion or all of it to create your own

application based on it. While using the Code to build your own application, you may alter it,

modify it, and create derivative works of the Code. You may also use the Code to test your

application. You may distribute the Code provided that you comply with the conditions on

distribution described below.

Conditions on Distribution

You may:

(1) reproduce and distribute an unlimited number of copies of the Code within your application, in

source code form, internally within your organization, including subsidiaries and affiliates;

(2) you may reproduce and distribute an unlimited number of copies of the Code within your

application, in source code form, externally provided that:

(a) your application adds significant and primary functionality to the Code;

(b) you distribute your application containing the Code under an End-User License Agreement, or

in signed hard-copy form, with terms no less protective than those contained herein, but

permitting your end users only internal distribution as described in item (1) above;

(c) you do not use the HPDC name, trademarks, or logo; or the name, trademarks, or logo of

Compaq Computer Corporation ("Compaq"); or the name, trademarks, or logo Hewlett-

Packard Company (“HP”) to market your application;

(d) you include a valid copyright notice on your application; and

(e) you agree to indemnify, hold harmless, and defend Compaq, HP, and HPDC from and

against any claims or lawsuits, including attorneys' fees, that arise or result from the use or

distribution of your application.

(3) reproduce and distribute an unlimited number of copies of the Code within your application, in

binary form, internally within your organization, including subsidiaries and affiliates, or externally

provided that:

(a) you do not use the Compaq name, trademarks, or logo; or the name, trademarks or logo of

Hewlett-Packard Company; or the name, trademarks, or logo of HPDC to market your

application;

(b) you include a valid copyright notice on your application; and

(c) you agree to indemnify, hold harmless, and defend Compaq, HP, and HPDC from and

against any claims or lawsuits, including attorneys' fees, that arise or result from the use or

distribution of your application.

4

NO WARRANTY

THE CODE IN THIS DOCUMENT IS PROVIDED 'AS-IS', WITHOUT ANY EXPRESSED OR IMPLIED

WARRANTY. IN NO EVENT WILL COMPAQ, HP, OR HPDC AND/OR THEIR SUBSIDIARIES OR

AFFILIATES BE HELD LIABLE FOR ANY DAMAGES ARISING FROM THE USE OF THIS CODE. TO

THE EXTENT PERMITTED BY LAW, COMPAQ AND HP AND HPDC, HEREBY DISCLAIM ALL

WARRANTIES AND CONDITIONS WITH REGARD TO THE CODE, INCLUDING ALL IMPLIED

WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,

TITLE, AND NON-INFRINGEMENT. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE

OF THE CODE IS WITH YOU. SHOULD THE CODE PROVE DEFECTIVE, YOU ASSUME THE COST

OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. IN NO EVENT SHALL COMPAQ, HP,

OR HPDC OR THEIR SUBSIDIARIES OR AFFILIATES BE LIABLE FOR ANY DIRECT, CONSEQUENTIAL,

INCIDENTAL, SPECIAL, EXEMPLARY, OR PUNITIVE DAMAGES, OR DAMAGES FOR LOSS OF

BUSINESS PROFITS, BUSINESS INTERRUPTION, OR LOSS OF BUSINESS INFORMATION, ARISING

OUT OF THE USE OR INABILITY TO USE THE CODE (INCLUDING BUT NOT LIMITED TO LOSS OF

DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD

PARTIES OR A FAILURE OF THE CODE TO OPERATE WITH ANY OTHER PROGRAMS), OR OTHER

DAMAGES WHATSOEVER, EVEN IF COMPAQ, HP, AND/OR HPDC HAVE BEEN ADVISED OF THE

POSSIBILITY OF SUCH DAMAGES.

Reproduction, adaptation or translation without prior written permission is prohibited, except as

allowed under the copyright laws.

5

Executive summary

This white paper describes the procedures for migrating an Oracle® E-Business Suite (EBS) 11i

application and database tiers from a Sun Microsystems SPARC-based server running Solaris to a split

configuration using HP Integrity and HP BladeSystem servers.

The target configuration leverages the mission-critical strengths of the HP-UX operating system and the

HP Integrity server to host the all-important EBS database that your business depends on. Using HP

ProLiant BladeSystem x86 servers with the Linux operating system for the EBS application tier layer

enables a high-performance solution at a very cost effective price point.

In writing this paper, HP performed an EBS 11i migration from a SPARC processor based Solaris

system to the HP Integrity / HP ProLiant split configuration. Our target hardware platforms were all

blade based and contained within an HP BladeSystem c7000 enclosure. Using this target

infrastructure environment enables all of the benefits of HP BladeSystem Matrix to be brought to your

critical E-Business Suite systems.

Detailed instructions and lessons learned from our own migration exercise are included in this

document. They cover the preparation, migration, and testing of both the application and database

tier. The document discusses the migration of a standard EBS 11i environment based on the Oracle

supplied Vision database. Any third-party components or customer-specific customizations may

require some additional steps in order to complete the migration.

Intended audience: The intended audiences for this document are technical specialists who have a

need to redeploy and support Oracle Applications on the HP-UX and Linux platforms.

Introduction

The Oracle E-Business Suite 11i applications environment consists of application and database tier

components certified to run on a variety of platforms from a number of systems vendors. Over time,

EBS implementations may experience changing needs that drive interest in migrating their E-Business

Suite 11i application and database tiers from their current environment to a different architecture. This

paper discusses the methodology for those looking to migrate from Sun SPARC based Solaris systems

to a HP-UX and Linux based split configuration.

HP BladeSystem Matrix makes an excellent platform on which to run and grow an EBS 11i

environment. Within the same BladeSystem enclosure you can combine an HP Integrity server blade

running HP-UX for your database and HP BladeSystem ProLiant blades running Linux for your EBS 11i

application tier. For larger configurations, the HP-UX database tier can leverage highly scalable

standalone HP Integrity servers whilst still keeping the applications tier within the BladeSystem

environment.

The objective of this document is to provide a detailed guide for customers looking to migrate their

application tier from Solaris based systems to an HP-UX and Linux configuration.

The test environment that HP used in developing this white paper was based on an Oracle E-Business

Suite 11i (11.5.10 CU2) with a SPARC Solaris 10 system as the source platform. Both the application

and database tiers resided on the same Solaris server. The target platforms consists of an HP Integrity

BL860c blade server with HP-UX 11i v3 for the database which was located in the same blade

enclosure as the application tier running on an HP ProLiant BL460c x86 blade server.

The rest of this document outlines the migration process for relocating both the database and

application tier from the SPARC Solaris system to the corresponding HP systems. The content is split

into two major sections with migrating the database presented first followed by migrating the

application tier.

6

It is not required that both the database and the application tier be migrated at the same time during

the same maintenance window. A phased approach is possible where the database is migrated first

and the EBS system is then returned back to production use. This can then be followed at a later time

by the application tier migration. Breaking the EBS system migration into two separate steps helps to

reduce the length of time that the system is unavailable to users as well as reducing overall risk within

the project.

As with any significant change to a production EBS environment, we highly recommend that the

processes outlined in this document be fully tested using a representative test environment before

proceeding on to modifying production systems.

Conventions

Table 1. Conventions used throughout this document

Convention Meaning

Application tier Comprised of all nodes running the Admin, Concurrent Processing,

Forms and Web servers.

Source The application tier that is being migrated from – SPARC Solaris

system

SRCHOST The symbolic hostname / network address of the source server

Target For the application tier, the Linux system. For the database tier, the

HP-UX system.

TGTAPPSHOST The symbolic hostname / network address of the target application

tier server. This is the x86 based HP ProLiant blade system running

Oracle Enterprise Linux 5.1.

TGTDBHOST The symbolic hostname / network address of the target database

tier server. This is the HP Integrity system running HP-UX 11i v3.

APPLMGR Linux user who owns the applications file systems.

APPL_TOP Directory location for EBS applications software

COMMON_TOP Directory location for EBS common application utilities

AD_TOP Directory location for EBS‟s appsutil

CONTEXT_NAME Variable referring to the name of the Context file.

CONTEXT_FILE Full path to the context file.

Default for application:

<APPL_TOP>/admin/<CONTEXT_NAME>.xml.

Default for database:

<ORACLE_HOME>/appsutil/<CONTEXT_NAME>.xml

ORACLE_HOME Full path to the database‟s Oracle Home directory.

Database tier System on which the Oracle Database software runs.

ORACLEDBUSER User who owns the database file systems.

7

Convention Meaning

ORACLE_SID Database SID

APPSTIER_ENV_FILE The location of the EBS application tier file that is sourced by the

shell to setup the application tier environment. For a non-shared

APPLTOP, this is usually $APPL_TOP/APPSORA.env. For a shared

APPLTOP environment, the filename is composed from the EBS

instance name and the hostname of the server being accessed:

$APPL_TOP/APPS<instance>_<hostname>.env.

Monospace Text Represents command line text.

< > Text enclosed in angle brackets represents a variable.

# Preceding # on a command line represents ROOT level access.

$ Preceding $ on a command line represents ORACLE applications or

database tier user level access.

SQL> The SQL prompt from the database sqlplus command

Software versions

In HP‟s migration testing, the following software versions were used at the target database and

application tiers for both the operating systems and Oracle Applications environment.

Table 2. Software version

Software Minimum Version Location Details

Oracle EBS

Applications 11i 11.5.10 CU2 application tier Consolidated Update

2 with additional

patches applied

Oracle Database 10.2.0.4 database tier No additional

patches required

over 10.2.0.4

HP-UX 11i 11i v3 database tier Patched and tuned to

meet the Oracle

Database product

needs

Oracle Enterprise

Linux 5.1 Target application

tier Server

Patched and tuned to

meet Oracle

Application‟s

application tier needs

Java™ SDK 1.4.2 Target application

tier

8

Performing the migration of the EBS database to HP-UX

This section of the document shows how to migrate the Oracle Database that stores the EBS data from

the original source Solaris system over to the target HP-UX Integrity server.

The initial sections show how to configure the HP-UX server ready for hosting the migrated database

by providing an in-depth look into the system commands needed to configure and patch HP-UX 11i

v3. This section is likely to contain information that those already familiar with HP-UX system

administration will find familiar and so is targeted at those who are new to the HP-UX enterprise

UNIX® software world.

The second section illustrates the steps necessary to migrate the EBS Oracle Database from the source

system over to the HP-UX target machine using Oracle‟s transportable database capability.

HP has tested this migration process using the Oracle EBS Vision demo database (VIS) implemented

on a single Solaris server. No EBS application customizations or additional supporting infrastructure

software was applied to the source environment. Bear in mind that your environment may use

additional software (for example, Oracle Enterprise Single Sign-on) or have customizations that also

need to be considered as planning for your migration process proceeds.

Preparation of the target HP Integrity server with HP-UX

Figure 1. Target Database System (HP-UX 11.31 on an HP Integrity BL860c blade server)

HP

Inte

grity

BL8

60c

NIC

1

NIC

2

NIC

3

NIC

4

UID

Before proceeding with the migration of the data from the source system, it is important to make sure

that the target HP-UX database system has been fully prepared ready to receive the relocated

database. To reduce migration time, these steps should be carried out and the environment tested

before starting any of the database export processes involving the source system.

Complete details for the Oracle 10gR2 database installation can be found in the Oracle Database

Installation Guide for HP-UX Itanium (Oracle Part Number B25293) and we refer the user to the most

recent version of this document for complete details.

A summary of the steps required to prepare the target HP Integrity server with HP-UX 11i v3 ready for

the Oracle Database installation are:

Install the HP-UX 11i v3 (also known as 11.31) Operating Environment on the target server if your

system was not already pre-installed when shipped from HP.

Ensure that all required pre-requisite HP-UX operating system patches for the Oracle 10gR2

database have been installed

Customize relevant HP-UX kernel parameters and ancillary configuration parameters as per the

Oracle Database Installation Update Notes

Create the user and group accounts needed for the database software

Configure networking and HP-UX libraries

Plan your disk storage requirements and provision the storage to the target HP-UX server

9

Once the underlying HP-UX operating system environment has been prepared, then the Oracle 10gR2

database can be installed. For our migration testing, Oracle Database release 10.2.0.4 was

implemented on the target HP-UX system so that it matched the release being used on the source

Solaris system.

The high-level steps to install the database software are:

Install the base 10gR2 database software (release level 10.2.0.1)

Upgrade the 10.2.0.1 database to release 10.2.0.4

Ascertain whether additional database patches over and above the base 10.2.0.4 level have been

applied to the source Solaris system. If supplementary patches were found then apply those same

patches to the HP Integrity target database system.

On completion of these activities, the target HP-UX system is ready to host the migrated EBS database

from the source system as both the operating system and the database code have been installed and

patched to the appropriate level.

Further details on how to perform each of these steps follow.

Install the HP-UX 11i v3 operating system

HP Integrity servers can be ordered with the HP-UX 11i v3 operating system already pre-installed so

that on delivery no further core operating system installation activities are necessary. HP recommends

that HP-UX 11i v3 is used as the foundation for your Oracle EBS 11.5.10 environment.

If your HP Integrity server is being repurposed for the EBS migration and a suitable HP-UX level is not

already installed then a fresh installation of the HP-UX 11i v3 operating system can be made. HP-UX

11i v3 can be installed either from DVD media or, if your IT infrastructure already includes an

Ignite-UX server, or from a network depot. Please refer to the latest HP-UX 11i v3 Installation Update

Guide available at the HP documentation website (http://docs.hp.com/en/oshpux11iv3.html) for

instructions on how to perform a core operating system installation.

If you are implementing a new HP-UX 11i v3 operating system, ensure that appropriate disk sizes are

specified during the disk layout section of the installation process. Two items are of special note – the

system swap space and the /tmp directory.

The Oracle Database installer asks that at least 400Mb of space be available in the /tmp directory

which, for many HP-UX installations, is more than the default space allocated by the HP-UX installer.

Increasing the /tmp allocation space during initial installation will avoid having to expand it later in

the migration process or having to override the default temporary file location using the TMP or

TMPDIR shell variables.

Oracle documentation recommends that a certain amount of swap space is available for the database

server. The swap space to allocate for your server can be specified during the HP-UX installation

process by modifying the defaults on the install menus presented. For all but the smallest systems, a

minimum swap size of at least 0.75 times the physical memory is required although depending on

what additional applications might be executing on your HP-UX server you may want more. Further

swap space can be dynamically added to the HP-UX system after the installation has completed but

you may find that having a single swap space rather than multiple is more convenient.

In addition to the core HP-UX 11i v3 operating system you may also need to install extra products

depending on your specific needs. For example, if you plan to use the compiled PL/SQL feature on

the database server then a supported HP C compiler will be required. Details on what additional HP

software may be required to support your specific database configuration can be found in the Oracle

installation guide.

http://docs.hp.com/en/oshpux11iv3.html

10

You should also ensure that the X11MotifDevKit.MOTIF21-PRG HP-UX fileset is installed as under

certain configurations these libraries are needed during Oracle linking.

If your server is already installed, the swlist command can be used to determine which software levels

are installed on your HP-UX machine. To determine the software level of the operating system core,

the following command can be used:

# swlist -l product OS-Core

# Initializing...

# Contacting target "dbhost"...

#

# Target: dbhost:/

#

OS-Core B.11.31 Core Operating System, plus Software Terms & Conditions

#

To establish which quality pack bundle (a cumulative patch collection) has been installed, the

following command can be used:

# swlist -l bundle QPKBASE

# Initializing...


#

# Target: dbhost:/

#

QPKBASE B.11.31.0809.326 Base Quality Pack Bundle for HP-UX 11i v3, September 2008

#

Another very useful HP-UX tool in analyzing and updating your HP-UX operating environment is the

HP-UX Software Assistant (or swa). One mode of the swa command scans your current HP-UX

software levels and automatically compares these levels against the very latest HP recommended

versions resulting in a report. The generated report provides recommended actions and a list of

patches that can be applied to your particular installation to bring it to the most appropriate software

levels. The same swa tool can then be used to download the previously evaluated patch list in

readiness for patch application via the HP-UX swinstall command.

Verify pre-requisite HP-UX patches for Oracle 10.2.0.4

A number of pre-requisite HP-UX operating system patches are required when installing the Oracle

Database. The most current list of pre-requisite patches can be found at the Oracle Metalink website

(http://metalink.oracle.com) in document ID 169706.1. Details on pre-requisites are also found in the

Oracle 10.2 Database for HP-UX Itanium Readme file that is available on the software installation

media.

At the time of writing, four additional patches were documented in Metalink document 169706.1 as

being required for HP-UX 11.31 in order to run the Oracle 10.2.0.4 databases. These patches are:

1. PHKL_38038

2. PHKL_35900

3. PHKL_36248

4. PHKL_36249

5. PHKL_35936

You can determine what patches are currently applied to your HP-UX system using the swlist

command. For example, to check whether patch PHKL_38949 is applied you would use the following

command:

http://metalink.oracle.com/

11

# swlist -l patch PHKL_38949

# Initializing...


#

# Target: dbhost:/

#

# PHKL_38949 1.0 vm cumulative patch

# PHKL_38949.C-INC 1.0 ProgSupport.C-INC applied

# PHKL_38949.CORE-ENG-A-MAN 1.0 OS-Core.CORE-ENG-A-MAN applied

# PHKL_38949.CORE2-KRN 1.0 OS-Core.CORE2-KRN applied

# PHKL_38949.KERN-ENG-A-MAN 1.0 OS-Core.KERN-ENG-A-MAN applied

#

The HP-UX software update mechanism includes functionality that allows for older patches to be

superseded by newer ones. An older patch that is superseded is replaced by a newer patch that

contains all aspects of the preceding patch, as well as possibly containing additional changes.

It is not uncommon for the HP-UX pre-requisite patches documented in the Oracle product notes to be

superseded such that there is a newer version of the patch available. Whether a specific patch has

been superseded can be determined either by using HP‟s IT Resource Center website

(http://itrc.hp.com) or through the use of the swlist –l patch –a supersedes command.

Once it has been determined which additional pre-requisite HP-UX patches are required, they can be

downloaded from HP‟s IT Resource Center. The ITRC download mechanism creates a packaged depot

that bundles together all requested patches in a single entity.

Once downloaded, these patches can then be installed using the swinstall command using a

command line similar to:

# swinstall –s <path_to_your_depot> <patch_name>

For example:

# swinstall –s /tmp/depot PHKL_38949

For some patches, a reboot of the system will be necessary as the update impacts system software that

is currently active and in use. For these types of patches, the swinstall command will display a

message indicating that a reboot will be required as part of the patch processing and will not

proceed further.

To apply patches that require a system reboot, the swinstall command includes the –x autoreboot=true

command line option. Using this flag causes the system to automatically restart after the specified

patch has been applied and so this command format should be used with care. The swinstall

command format to use is:

# swinstall –s <path_to_your_depot> -x autoreboot=true <patch_name>

Update HP-UX operating system parameters

Before installing the database software, a number of kernel parameters are updated to enable HP-UX

to best meet the resource demands of the Oracle Database software. The recommended kernel

settings are available in Metalink document 169706.1 and are listed below for reference. Please

refer to the Metalink document for the latest recommended settings as they may be updated over time.

You may find that several of the kernel parameters are already at the required value and do not need

further modification.

The following list provides the kernel tunables that need updating (or validating) when running Oracle

Database 10.2.X on HP-UX 11i v3 (11.31):

http://itrc.hp.com/

12

KSI_ALLOC_MAX (NPROC*8) EXECUTABLE_STACK 0 MAX_THREAD_PROC 1024 MAXDSIZ 1073741824 bytes MAXDSIZ_64BIT 2147483648 bytes MAXSSIZ 134217728 bytes MAXSSIZ_64BIT 1073741824 bytes MAXUPRC ((NPROC*9)/10)+1 MSGMNI NPROC MSGTQL 4096 NCSIZE (NINODE+1024) NFILE (15*NPROC+2048) NFLOCKS 4096 NINODE (8*NPROC+2048) NKTHREAD (((NPROC*7)/4)+16) NPROC 4096 SEMMNI 4096 SEMMNS (SEMMNI*2) SEMMNU (NPROC - 4) SEMVMX 32767 SHMMAX Up to the available amount of physical memory in your server SHMMNI 512 SHMSEG 120 VPS_CEILING 64

Two methods are available for querying and setting HP-UX kernel parameters by authorized users.

The first option uses a web based interface and the HP-UX System Management Homepage (SMH).

The SMH facility provides an extensive collection of system management tools that are securely

accessed through a web browser by appropriately authorized users. The SMH console can be

connected to by directing your web browser to http://<system_hostname>:2301 where

<system_hostname> should be substituted with your HP-UX system‟s hostname.

To navigate to the kernel tunables page, first login using the root user and then select the tools page

through the top menu bar. Once at the tools main page, select Tunables under the Kernel

Configuration selection. This page presents available tunables along with their current values and the

option to modify their settings by clicking on the modify tunables link.

An alternative method for those more familiar with the shell command line is the HP-UX kctune

command. This command can be run by the root user to query and set various kernel tunable values.

To establish the current value of a kernel tunable using kctune use:

kctune <parameter_name>

For example:

# kctune nproc

Tunable Value Expression Changes

nproc 4096 4096 Immed

#

To set a tunable to a specified value, use the following form of the kctune command: kctune <parameter_name>=<new_value>

where new_value can be a formulae or an absolute value. For example:

# kctune nproc=4096

==> Update the automatic 'backup' configuration first? yes

* The automatic 'backup' configuration has been updated.

* Future operations will update the backup without prompting.

* The requested changes have been applied to the currently

running configuration.

NOTE: No change to the tunable 'nproc' was needed.

Tunable Value Expression Changes

nproc 4096 4096 Immed

#

13

A system reboot is required to activate the subset of kernel tunables that do not support the immediate

change mode. HP recommends making all kernel changes that require a system restart at the same

time and then follow this with a single system restart.

Create accounts and groups for the database software

The Oracle Database installation process requires a number of HP-UX operating system user and

groups to be defined.

Two common groups that are defined in installations are the oinstall group (which owns the Oracle

Inventory information) and the dba group whose members have SYSDBA privileges. These groups can

be created either via the web-based SMH or more directly by using the HP-UX groupadd command:

# groupadd oinstall

# groupadd dba

Oracle Database also requires a user ID which owns the Oracle Database software and instance. The

usual convention in EBS is to name this user based on the EBS instance ID concatenated with the

string “ora”. For example, if the EBS instance ID is “prod” then the Oracle Database user ID would by

convention be “oraprod”.

In this document, we refer to this HP-UX user ID that owns the database instance as ORACLEDBUSER.

Either the SMH web based interface or the HP-UX useradd command can be used to define new

users. The relevant command line syntax is:

# useradd -m -g oinstall -G dba <ORACLEDBUSER>

#

where the –m flag indicates that a new home directory should be created, -g specified the primary

group and –G specifies the secondary group. Once the userid is created we strongly recommend that

the password be immediately reset using the passwd command.

Configure networking

The Oracle Database installer uses networking name resolution during the installation process to map

between symbolic textual names and network addresses. HP-UX supports a number of name resolution

protocols including the “files” method where network resolution information is held in configuration

files on the local server itself.

To make sure that the network resolution information in those files is available to the Oracle installer,

validate that the /etc/nsswitch.conf file includes a line that enables the use of local files for hostname

lookup. For example, an nsswitch.conf file might contain the contents below where the line starting

with hosts indicates that files and then DNS will be used for name lookup:

#

# /etc/nsswitch.conf

#

passwd: compat

group: compat

hosts: files dns

ipnodes: files dns

networks: files

protocols: files

rpc: files

publickey: files

netgroup: files

automount: files

aliases: files

services: files

14

The HP-UX network resolver routines will now first use the /etc/host local file to obtain networking

information and if that does not produce a mapping then the DNS server will be consulted.

The /etc/hosts file contains the file-based lookup mappings between TCP/IP network addresses and

their corresponding symbolic text names. An example host file might contain:

# @(#)B.11.31_LRhosts $Revision: 1.9.214.1 $ $Date: 96/10/08 13:20:01 $

#

# The form for each entry is:

# <internet address> <official hostname> <aliases>

#

#

1.2.3.4 db_host.yourcompany.com db_host

127.0.0.1 localhost loopback

To make sure that the HP-UX system can resolve its own name correctly, use the hostname command

to obtain the server‟s hostname and then use the nslookup command with the returned hostname to

make sure the correct network address is returned.

Plan your disk storage requirements and layout

How much disk storage and what the layout of that storage is on the HP-UX target system will be

heavily influenced by the current disk usage on the source EBS database system. As the EBS database

will be transferred from the source Solaris system to the target in its entirety then at a minimum

sufficient disk space must be made available to house that complete data. This planning step is also a

good opportunity to prepare for any future database expansion and to make sure that sufficient

storage is available to handle planned future growth.

Our database migration methodology relies on the transportable database capability available with

Oracle Database 10.2.0.3 and above. This approach takes the underlying database files from the

source system and directly converts them on the target system via the rman command.

If the source database files are available over a networked file system (such as NFS) then the

conversion process can derive its input from the remotely mounted file system and directly write

converted files to the local HP-UX file system. This conversion approach only requires as much disk

storage be available on the target system as the original size of the database itself on the source.

However, if the source database files are not available via a networked file system then it becomes

necessary to copy the original source databases files to the target first and then subsequently convert

them. This means that at least as much as twice the disk storage as was used by the original source

system is needed on the target as both the unconverted and converted files are being concurrently

stored there.

HP-UX provides both a web-based interface as well as a command line interface into the tools that are

used to manage storage. The web-based interface uses the Systems Management Homepage (the

same tool that was used for kernel tunables) and from the tools tab, select the links under the Disks

and File Systems collection. The command line environment provides many flexible tools that can be

used to configure disks, the volume manager and file systems at a detailed level. For an overview of

the various storage capabilities that are supplied with HP-UX please see the HP-UX System

Administration Guide available at http://docs.hp.com/en/5992-4580/ch03s03.html.

In addition to allocating storage for the data files in which the EBS data is held, it is also necessary to

factor in the disk space required for the Oracle RDBMS product files (often called the “Oracle

Home”). Details on the minimum disk space required for the Oracle RDBMS install is provided in the

database installation guide and release notes. In our test environment approximately 6 GB of space

was required for the 10.2.0.4 Oracle Home.

http://docs.hp.com/en/5992-4580/ch03s03.html

15

It is important to understand the performance characteristics of the storage attached to your target HP-

UX system as disk and file system planning proceeds. Placing key elements of your EBS data on high

performance storage will help remove I/O bottlenecks which is one element that contributes towards

improving overall system performance.

Installation of the Oracle RDBMS product on HP-UX Integrity

Up to this point, the HP Integrity server has been installed with the HP-UX 11i v3 operating system and

been appropriately customized for running the Oracle Database software. The next step in the

process is to install the Oracle Database software and to patch it to the desired release level so that a

suitable Oracle Home is available to receive the transported database.

For our migration exercise we have selected to use Oracle 10gR2 at release level 10.2.0.4. It is

important that the specific release and patch levels of the database on the HP-UX based target server

is identical to that on the source Solaris server. We see later in the data transportation process that

checks are made via the Oracle opatch command to ensure that this criteria is met.

The installation process of the Oracle Database software on an HP-UX Integrity Server will be very

familiar to those who have installed the database on other platforms. The runInstaller graphical user

interface command is used to carry out the installation process for the core database, the companion

products and the 10.2.0.4 patch set.

As with any Oracle Database installation, it is recommended that the release notes that accompany

the product install images are consulted to make sure that any last minute changes and updates are

noted. If you have access to Oracle‟s Metalink website, it is also a good idea to check there for any

special notices for more recent issues and resolutions that may apply.

Install the base 10.2.0.1 Oracle Database software

As a first step, the base 10.2.0.1 version of the Oracle RDBMS product needs to be installed.

Since the Oracle installation program uses a graphical user interface, the installing user must be

logged on via an X-Windows capable terminal to be able to initiate the process. Although it is

possible to run the installation program using a non-interactive mechanism avoiding the X-Windows

requirement, this generally adds extra complexity to the process.

After the Oracle product media for the 10.2.0.1 HP-UX Integrity database is available on your

system, execute the runInstaller –ignoreSysPrereqs command using the ORACLEDBUSER user ID that

was defined earlier. The –ignoreSysPrereqs flag is required because even though Oracle RDBMS

10.2.0.1 is certified for use with HP-UX 11.31, the original 10.2.0.1 installer predates the HP-UX

11.31 release and so it does not recognize this particular operating system release. Using the

–ignoreSysPrereqs flag indicates to the installer that it should not validate the pre-requisites and thus

will proceed with the installation process without reporting an error.

Once the installer has started, proceed through the panels specifying that the Enterprise edition of the

database is to be installed and make note of the names and locations that this new Oracle Home will

be identified by. As we will be subsequently transferring the database from the Solaris system, it is not

necessary to create a new database at this point and so the “Install database software only” option

should be taken.

On completion of the core Oracle 10.2.0.1 database install, we recommend examining installer log

files to look for any errors or unexpected problems that may have occurred. If problems are identified

then it is important to resolve these before progressing further.

Following a successful 10.2.0.1 database install, the next step is to install selected components from

the Oracle 10.2.0.1 companion products media. Oracle requires that the companion database 10g

products be installed into the same Oracle Home as the core database as EBS internally relies on

several of the features that are delivered as part of this software.

16

After replacing the Oracle 10.2.0.1 database installation media with the 10.2.0.1 database

companion media, use the runInstaller –ignoreSysPrereqs command once again to initiate the

installation. In this session, select the “Oracle Database 10g Products 10.2.0.1” as the product to

install. Ensure that the Oracle Home that was installed in the previous step is specified when

prompted for a destination location during this installation session.

When the installer has completed, we recommend scanning its output log files to validate that there

were no unexpected problems or errors.

The HP-UX system now has an Oracle Home with the core database and EBS required companion

products installed at release 10.2.0.1. The next step is to upgrade this environment to match the level

of database software on the source Solaris system (which is 10.2.0.4 in our case).

Upgrade the database to 10.2.0.4

Upgrading the database on the HP-UX Integrity system to 10.2.0.4 from its base release of 10.2.0.1

involves apply Oracle patch 6810189. This patch is downloadable from Oracle‟s Metalink website

under the patch section.

Before applying the patch, we strongly recommend reading through the release notes provided with

the patch itself as well as checking Oracle‟s Metalink website for any other late breaking news.

The patch installation process once again uses the runInstaller command and, as this is a more recent

release, there is no need for the special –ignoreSysPrereqs flag as the installer now recognizes HP-UX

11i v3 as a certified environment. It is important that you use the runInstaller command found within

the patch media itself and not to use the version of the command that was previously installed into the

10.2.0.1 Oracle Home directory.

As the installer executes, select the existing 10.2.0.1 Oracle Home as the target for the patch. When

the installer has completed, we recommend scanning the log files for any errors that may have been

encountered during the patching process.

Create a test database using the 10.2.0.4 Oracle Home

Although not strictly required, we recommend creating a test database using the Oracle software that

was just installed and patched above to make sure that all is operating properly. This can be done

either manually from the sqlplus command prompt (using the CREATE DATABASE… statement and

manually creating configuration files) or automatically via the dbca command.

Remember to drop the database once your testing has completed using either dbca or the DROP

DATABASE statement from sqlplus.

Create the Oracle 9i NLS data directory

The EBS version 11.5.10 product has been implemented assuming the National Language Support as

implemented in the Oracle 9i database system. To maintain compatibility when using 10gR2, it is

necessary to add the 9i NLS conversion information to the new 10gR2 Oracle Home so that country

specific information is handled correctly.

The 10gR2 database installation includes a script which can be used to create the 9i data directory

that holds the legacy NLS information. This script is the cr9idata.pl script and can be found in the

$ORACLE_HOME/nls/data/old directory. Note that this Perl script assumes that the Perl interpreter is

located in the /usr/local/bin directory which may not be the case for your system. If this happens,

then you can run this script by explicitly by using the command /<path_to_perl>/perl cr9idata.pl

where path_to_perl maps to the directory where Perl was installed.

Once the $ORACLE_HOME/nls/data/9idata has been created using the cr9idata.pl Perl script, set

the ORA_NLS10 shell environment variable to point to this directory so that the database uses this

information. Setting this variable in the ORACLEDBUSER shell profile is the easiest way to ensure that

the variable is set on every log in and hence the correct NLS data should be used.

17

Migrating the database from Solaris to HP-UX

Now that our target HP-UX server has been prepared to receive the EBS database, the migration of

the data from the source Solaris SPARC system over to the HP-UX system can proceed. As both the

source and target systems processors share the same endianess then we are able to use Oracle‟s

transportable database feature available with Oracle RDBMS 10.2.0.3 and above to transition the

data.

Transportable database provides an efficient mechanism for transferring data between platforms and

instances that meet the necessary pre-requisite criteria. Rather than requiring a full database

import/export exercise, transportable database takes the approach of converting the underlying

source system database files so that they are suitable for use on the target platform. These database

files (often referred to as “dbf” files) undergo the conversion process using the database rman

command. The converted files are used on the target platform as the new instance‟s database storage

in much the same way as the original files were used on the source system.

Using the transportable database mechanism to migrate an EBS database from one platform to

another is noticeably faster as compared to performing the traditional import/export approach - and

is often less error prone too. This means that your EBS system is unavailable to end users for a shorter

period of time thereby reducing the business impact of the transition.

An important characteristic of the transportable database methodology for migrating your database to

the HP-UX platform is that the source database data is not substantially modified as part of the

process. The only update that is made is the creation of a directory object that is used for exporting

Analytical Workspaces and no modification of critical business data is made. This means that should

an unexpected problem occur during the migration then the original source system is still available for

use within the production environment.

As with any significant change against a production environment, we strongly recommend validating

the database migration process first using a test environment that closely reflects your production EBS

configuration. This will help to identify in a testing environment any unexpected problem and glitches

that may occur before changes are made to the production system.

The remainder of this section provides step by step instructions for performing the database migration

over to the HP-UX Integrity system. These activities can be broken down into the following high-level

steps:

1. Check that all pre-requisites required for transportable database use are met

2. Determine if any “external” or platform-specific data needs transferring that cannot be handled by

the transportable database mechanism. Export this data (once you have entered your database

migration maintenance window) ready for import later.

3. Using rman, automatically build the scripts and template configuration files used to perform the

data file conversions

4. Make the data files from the source Solaris system available to the HP-UX Integrity server

5. Perform the data file conversion at the target system and create the new database instance

6. Import the external and any other exception data as determined in step 2.

7. Implement EBS‟s AutoConfig on the new database tier

8. Update the application tier configuration to use the new database

9. Test the environment before releasing the system back to production usage

Each of these steps is expanded on in the following sections. Further details can also be found in

Oracle Metalink document 729309.1 and the Oracle white paper “Platform Migration Using

Transportable Database Oracle Database 11g and 10g Release 2”.

18

Step 1: Check that pre-requisites are met for using transportable database

In our migration testing, we executed the process of transferring the EBS database using Oracle

RDBMS release 10.2.0.4 from a Solaris SPARC system to an HP-UX Integrity server. This combination

of platforms is supported by the transportable database mechanism.

Validating suitable platforms:

If you are planning a migration from a different type of source system and want to verify its suitability

for use with HP-UX and HP Integrity Servers then you can query the v$db_transportable_platform

view. The view list platforms that have the same endianess as the system on which the query is run

and so running the following select on the HP-UX server provides a list of suitable source migration

systems:

SQL> select * from v$db_transportable_platform;

PLATFORM_ID PLATFORM_NAME ENDIAN_FORMAT

----------- -------------------------------- --------------

1 Solaris[tm] OE (32-bit) Big

2 Solaris[tm] OE (64-bit) Big

6 AIX-Based Systems (64-bit) Big

3 HP-UX (64-bit) Big

4 HP-UX IA (64-bit) Big

9 IBM zSeries Based Linux Big

16 Apple Mac OS Big

18 IBM Power Based Linux Big

8 rows selected.

SQL>

Checking the source database with dbms_tdb.check_db:

The Oracle Database includes a PL/SQL package called dbms_tdb that helps support the

transportable database feature. The check_db function within this package is used to scan and verify

that your source database environment is capable of using transportable database to the named

target.

The check_db function requires that the source database be started in read only mode and so this step

cannot be executed whilst EBS is active. If a suitable maintenance window is not available in which to

run this transportable database validation, then the check can be deferred to the beginning of step 3

(the data file conversion process). However, if the check is deferred and issues are found when

check_db is run then delays in the database migration process are likely to occur.

The following PL/SQL sample code provides an example of how to run the dbms_tdb.check_db()

function on the source database system and specifically validates the transfer of the database to an

HP-UX Integrity system. This can be either typed interactively at the sqlplus prompt or stored in a file

that is subsequently executed via sqlplus.

set serverout on

declare

db_ready boolean;

begin

db_ready := dbms_tdb.check_db('HP-UX IA (64-bit)',dbms_tdb.skip_none);

if (db_ready = TRUE)

then

dbms_output.put_line ('Database can be transported') ;

else

dbms_output.put_line ('Database CANNOT be transported!') ;

end if;

end;

/

19

The following shows the output when the above is saved into a file called check_db.sql and then

executed on the source database system:

SQL> @check_db

Database can be transported

PL/SQL procedure successfully completed.

SQL>

Verifying that you are at the latest level of EBS’s AutoConfig:

The EBS instance being migrated should be setup to use the AutoConfig capability for managing the

application and database tier EBS configuration information. This is the case with the sample VIS

database that we are using to illustrate the Solaris to HP-UX migration process.

It is important to make sure that you have the very latest updates and features in the version of

AutoConfig that is implemented on your EBS system. Consult Metalink document 165195.1 to

determine what the latest AutoConfig patch is that is available for your EBS 11i system. At the time of

our testing the latest applicable patch for AutoConfig was 6372396 and that version was applied to

the source EBS system.

Remember that applying the AutoConfig patch will update the specific application tier system that ran

adpatch but will not transfer those updates to the AutoConfig instances on the database server or

other application tier machines. Depending on your application tier configuration, you may need to

replicate the AutoConfig patch to other applications tier nodes that make up your EBS 11i

environment too.

To replicate the updated AutoConfig environment to the database system, use the

$AD_TOP/bin/admkappsutil.pl utility. This Perl script will package up the AutoConfig code and data

from the newly patched application tier node into the appsutil.zip file which is then suitable for

copying to the database server. Once the appsutil.zip file is on the database server, unzip it in the

database‟s Oracle Home directory whilst logged in as ORACLEDBUSER. Now that the latest version

of AutoConfig is available on the database server, run the adautocfg.sh command so that the

generated configuration is refreshed. Full details on this process are provided in Metalink document

165195.1.

The process of applying the AutoConfig patch uses the standard EBS adpatch utility and consequently

requires a maintenance window on your EBS system to carry these actions out.

Verifying the Oracle RDBMS release and patch levels on the source and target:

One further verification step is to ensure that the database software on the target HP-UX system is at

an identical software level to that currently installed on the source Solaris system. In addition to

making sure that the database versions are the same (10.2.0.4 in our case), it is also important to

check for any additional one-off patches that may have been applied to the source database.

One-off patches may have been applied to the database software to meet specific product

certification requirements or to fix issues that have been identified after the certification process has

completed.

The opatch command provided with the database software is used to determine what software levels

and one-off patches have been applied to your system. You can find this command in the

$ORACLE_HOME/OPatch directory and the utility can be used to apply new patches as well as query

the patch inventory for existing patch data.

20

The output from opatch for our test source Solaris Database instance is shown below:

$ ./opatch lsinventory

Invoking OPatch 10.2.0.4.3

Oracle Interim Patch Installer version 10.2.0.4.3

Copyright (c) 2007, Oracle Corporation. All rights reserved.

Oracle Home : /oracle/db/visdb/10.2.0

Central Inventory : /var/opt/oracle/oraInventory

from : /var/opt/oracle/oraInst.loc

OPatch version : 10.2.0.4.3

OUI version : 10.2.0.4.0

OUI location : /oracle/db/visdb/10.2.0/oui

Log file location : /oracle/db/visdb/10.2.0/cfgtoollogs/opatch/opatch2009-02-23_14….

Lsinventory Output file location :

/oracle/db/visdb/10.2.0/cfgtoollogs/opatch/lsinv/lsinventory2009-02-23_14-51-45PM.txt

--------------------------------------------------------------------------------

Installed Top-level Products (3):

Oracle Database 10g 10.2.0.1.0

Oracle Database 10g Products 10.2.0.1.0

Oracle Database 10g Release 2 Patch Set 3 10.2.0.4.0

There are 3 products installed in this Oracle Home.

There are no Interim patches installed in this Oracle Home.

--------------------------------------------------------------------------------

OPatch succeeded.

This shows that the system initially had the core database and database companion products at

release 10.2.0.1 installed followed by the application of the 10.2.0.4 patch set. No one-off patches

have been applied.

To make sure that the HP-UX system has the same database software levels, run the opatch command

and compare the output:

Invoking OPatch 10.2.0.4.3

Oracle Interim Patch Installer version 10.2.0.4.3

Copyright (c) 2007, Oracle Corporation. All rights reserved.

Oracle Home : /oracle/ebsdbhome

Central Inventory : /home/oracle/oraInventory

from : /var/opt/oracle/oraInst.loc

OPatch version : 10.2.0.4.3

OUI version : 10.2.0.4.0

OUI location : /oracle/ebsdbhome/oui

Log file location : /oracle/ebsdbhome/cfgtoollogs/opatch/opatch2009-02-23_14-50-15PM.log

Lsinventory Output file location :

/oracle/ebsdbhome/cfgtoollogs/opatch/lsinv/lsinventory2009-02-23_14-50-15PM.txt

--------------------------------------------------------------------------------

Installed Top-level Products (3):

Oracle Database 10g 10.2.0.1.0

Oracle Database 10g Products 10.2.0.1.0

Oracle Database 10g Release 2 Patch Set 3 10.2.0.4.0

There are 3 products installed in this Oracle Home.

There are no Interim patches installed in this Oracle Home.

--------------------------------------------------------------------------------

OPatch succeeded.

21

In our example above, the patch level output reported on the HP-UX server is the same as for the

source Solaris system and so no additional patches need be applied.

Step 2: Handle external and platform-specific data

Handling data that is external to the database:

While the vast majority of EBS data is held within the database itself, there are some occasions where

information may be stored in external entities. Those items that are external to the database are not

stored within the core database data files (that is, they are not contained within the “dbf” files) but are

located elsewhere including in the file system of the underlying database server. Examples of external

objects that may be stored elsewhere on the server include external tables, BFILE objects or items that

are referenced through database directory entities.

As this external data is not located within the core database storage then they need to be specially

handled outside of the transportable database process. To assist in identifying external objects that

need extra handling when using transportable database Oracle provides the check_external function

in the dbms_tdb package. This feature examines the source database looking for any external data

that would require a manual migration process outside of transportable database mechanism.

The following shows sample PL/SQL code that can be used to call the dbms_tdb.check_external()

function. It can be executed using the sqlplus command against an active database using the sys

userid:

set serverout on

declare

db_has_external boolean;

begin

db_has_external := dbms_tdb.check_external ;

if (db_has_external = TRUE)

then

dbms_output.put_line ('Database has external entities that need manual transport') ;

else

dbms_output.put_line ('Database does not have external entities') ;

end if;

end;

/

The output from this PL/SQL when run against our test VIS database is:

$ sqlplus "/ as sysdba" @check_external

SQL*Plus: Release 10.2.0.4.0 - Production on Fri Feb 20 15:19:49 2009

Copyright (c) 1982, 2007, Oracle. All Rights Reserved.

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

The following directories exist in the database:

SYS.WORK_DIR, SYS.ADMIN_DIR, SYS.ORACLE_OCM_CONFIG_DIR, SYS.DATA_PUMP_DIR,

SYS.ECX_UTL_XSLT_DIR_OBJ, SYS.ECX_UTL_LOG_DIR_OBJ, SYS.APPS_DATA_FILE_DIR

Database has external entites that need to be manually transported

PL/SQL procedure successfully completed.

SQL>

In this case, there are a number of DIRECTORY entries in the database which point to external

locations in the source database‟s file system. There are no BFILES or external tables shown here but

depending on your EBS installation there may be cases where these are also indicated.

22

Each type of external object will need to be individually evaluated to determine whether it should be

transferred from the source Solaris database system to the target HP-UX system. Recollect that both

Sun SPARC servers with Solaris and HP Integrity servers with HP-UX have the same data endianess

which helps to reduce data conversion issues for any external objects.

The following SQL was used to further examine the directory entries that were reported during the

evaluation of our test system. This SQL queries the file system locations which the directory entries

were referencing on the source database server:

SQL> select * from dba_directories where directory_name in

('WORK_DIR','ADMIN_DIR','ORACLE_OCM_CONFIG_DIR','DATA_PUMP_DIR',

2 'ECX_UTL_XSLT_DIR_OBJ','ECX_UTL_LOG_DIR_OBJ' , 'APPS_DATA_FILE_DIR') ;

OWNER DIRECTORY_NAME DIRECTORY_PATH

---------- ------------------------ -----------------------------------------------------

SYS WORK_DIR /oracle/db/visdb/10.2.0/work

SYS ADMIN_DIR /oracle/db/visdb/10.2.0/md/admin

SYS ORACLE_OCM_CONFIG_DIR /oracle/db/visdb/10.2.0/ccr/state

SYS DATA_PUMP_DIR /oracle/db/visdb/10.2.0/admin/VIS/dpdump/

SYS ECX_UTL_XSLT_DIR_OBJ /usr/tmp

SYS ECX_UTL_LOG_DIR_OBJ /usr/tmp

SYS APPS_DATA_FILE_DIR /oracle/db/visdb/10.2.0/appsutil/outbound/VIS_b46t200

7 rows selected.

SQL>

Understanding how each of these database directory references is used by their corresponding

applications helps to derive a plan as to whether this external data needs to be transferred. At a

minimum, the corresponding file system directories should be created on the target system. If after

further investigation it is found appropriate, the contents of the source directory and its subdirectory

structure may well be copied to the target too.

Some of these file system directories in the listing above have the source database machine‟s Oracle

Home directory as its prefix. Some also include the database machine‟s hostname. If you plan to use

a different Oracle Home location or hostname at the target system consider modifying the file system

paths appropriately. For example, the APPS_DATA_FILE_DIR in the example above is really located in

ORACLE_HOME followed by a concatenation of the EBS instance ID and hostname. Both the

ORACLE_HOME and hostname may well be different on the target HP-UX machine and so that path is

a candidate for updating.

If external data has been found on the source database environment that needs to be relocated to the

target, then proceed with the transfer once you have entered the maintenance window set aside for

the whole database migration process. EBS applications must be inactive before you start the transfer

so that no potential changes to external data is made that would make it inconsistent with the rest of

the database.

Transferring platform-specific data in the database:

Although transportable database is able to easily migrate large amounts of data with a wide variety

of objects types between systems of like endianess, there is one exception related to OLAP‟s

Analytical Workspaces (AWs). This exception relates to a platform-specific data type that is used

within OLAP‟s AW that potentially results in error situations if not migrated properly.

To circumvent this problem, an export is made into a file of the application-related AWs from the

source database which is subsequently then imported into the target database later on. Using the

export format for the AW negates the effect of the platform-specific data type and so the OLAP

environment can be correctly restored on the target system.

As we are now migrating active data to the target HP-UX database system, it is important that the EBS

application system is shutdown and that the work is carried out during the planned maintenance

23

window with sufficient time to migrate the whole database. If it was necessary to handle the external

data from the previous step then your EBS environment should already be shutdown at this point.

The first step in handling the AW export process is to determine which workspaces need to be

exported. Once the list has been identified then appropriate PL/SQL code can be generated to

perform the export process for those specific AWs. To find the AWs that need special attention use

the following SQL from sqlplus when connected as the sys user ID:

SQL> select awname, owner# from sys.aw$ where owner# != 0 ;

AWNAME OWNER#

------------------------------ ----------

ZPBANNOT 266

ZPBCODE 266

ZPBDATA 266

SQL>

This query results in the name of the AWs that need handling but not the owner. The following SQL

can be used to get the AW owner and the current status of the AW:

SQL> select owner , object_name , status from dba_objects

2 where object_name like 'AW$%' and object_name != 'AW$'

3 group by owner,object_name,status;

OWNER OBJECT_NAME STATUS

------------------------------ ------------------------ -------

ZPB AW$ZPBDATA VALID

SYS AW$AWXML VALID

SYS AW$AWMD VALID

SYS AW$AWREPORT VALID

ZPB AW$ZPBANNOT VALID

SYS AW$AWCREATE VALID

ZPB AW$ZPBCODE VALID

SYS AW$AWCREATE10G VALID

SYS AW$EXPRESS VALID

9 rows selected.

SQL>

Now that the list of AWs has been obtained, we can use the dbms_aw PL/SQL package to initiate an

export of each of the workspaces. The following script was used to export the three AWs that were

identified by the first SQL as needing special handling:

drop directory AW_DUMP ;

create directory AW_DUMP as '/export/home/oravis/aw';

exec dbms_aw.execute('aw attach ZPB.ZPBANNOT rw');

exec dbms_aw.execute('allstat');

exec dbms_aw.execute('export all to eif file ''AW_DUMP/zpbannot.eif ''');

exec dbms_aw.execute('aw detach ZPB.ZPBANNOT');

exec dbms_aw.execute('aw attach ZPB.ZPBCODE rw');


exec dbms_aw.execute('export all to eif file ''AW_DUMP/zpbcode.eif ''');

exec dbms_aw.execute('aw detach ZPB.ZPBCODE');

exec dbms_aw.execute('aw attach ZPB.ZPBDATA rw');


exec dbms_aw.execute('export all to eif file ''AW_DUMP/zpbdata.eif ''');

exec dbms_aw.execute('aw detach ZPB.ZPBDATA');


The create directory statement is used to build a reference in the file system where the AW export files

will be stored. It is used within the “export all to eif” statement as a prefix for the filename and after

running this script any AW dump files will be stored in this location.

24

For each AW that needs to be exported, use the same sequence of attach, allstat, export and detach

dbms_aw.execute commands until all workspaces that need to be saved have been processed.

When we ran the above script in our test environment against the VIS test database it was discovered

that ZPB.ZPBANNOT and ZPB.ZPBDATA were empty and an error was reported. No export files

were created for these two AWs.

These exported AW files will be re-imported back into the target database at step 7 of the database

migration process documented below.

Step 3: Create conversion scripts and templates using rman

Now we have validated that all of the pre-requisites have been met and handled those data objects

which cannot be migrated using transportable database, we proceed to the next step of creating

scripts and templates ready for the database‟s data file relocation.

The automatically generated scripts and templates are created by running the rman command on the

Solaris source system.

The scripts and templates are used to:

1. Automate the process of converting the source database‟s data files for use on the HP Integrity

system. The conversion process is performed at the HP-UX system using the convert_ebs.rman script

that is output by the rman session.

2. Create the new database on the HP Integrity server target using the converted data files. This is

handled by the transport_ebs.sql script and the associated database initialization file template

(“init.ora”). Both of these files are automatically generated by rman.

To being the process, the EBS application tier must be shutdown and the source database system

started in read-only mode:

SQL> startup mount;

ORACLE instance started.

Total System Global Area 2.5770E+10 bytes

Fixed Size 2185512 bytes

Variable Size 876193496 bytes

Database Buffers 2.4881E+10 bytes

Redo Buffers 10813440 bytes

Database mounted.

SQL> alter database open read only;

Database altered.

SQL>

Once the database is available in read-only mode, the rman command is run to build the scripts and

template files. The transportable database procedure allows for the conversion of the database data

files either at the source or the target system. In our testing, we elected to convert the data on the HP-

UX server and so the command syntax shown in the example below is applicable. If for some reason

it is necessary to convert the data files on the source system then the rman syntax will need to be

revised.

$ rman

Recovery Manager: Release 10.2.0.4.0 - Production on Mon Feb 23 16:40:30 2009

Copyright (c) 1982, 2007, Oracle. All rights reserved.

RMAN> connect target /

connected to target database: VIS (DBID=232332311)

25

RMAN> convert database on target platform convert script

'/export/home/oravis/rman/convert_ebs.rman'

2> transport script '/export/home/oravis/rman/transport_ebs.sql'

3> new database 'VIS' format '/ebsdata/visdata/%U' db_file_name_convert

'/oracle/db/visdata','/ebsdata/visdata';

Starting convert at 23-FEB-09

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=985 devtype=DISK

Directory SYS.WORK_DIR found in the database

Directory SYS.ADMIN_DIR found in the database

Directory SYS.ORACLE_OCM_CONFIG_DIR found in the database

Directory SYS.DATA_PUMP_DIR found in the database

Directory SYS.ECX_UTL_XSLT_DIR_OBJ found in the database

Directory SYS.ECX_UTL_LOG_DIR_OBJ found in the database

Directory SYS.APPS_DATA_FILE_DIR found in the database

channel ORA_DISK_1: starting to check datafiles

input datafile fno=00020 name=/oracle/db/visdata/reference1.dbf

channel ORA_DISK_1: datafile checking complete, elapsed time: 00:00:00


input datafile fno=00021 name=/oracle/db/visdata/reference2.dbf



input datafile fno=00001 name=/oracle/db/visdata/sys1.dbf








…

.. similar messages for all of the Oracle database “dbf” files ..

…


input datafile fno=00050 name=/oracle/db/visdata/ctx1.dbf



input datafile fno=00053 name=/oracle/db/visdata/owa1.dbf


Run SQL script /export/home/oravis/rman/transport_ebs.sql on the target platform to create

database

Edit init.ora file /ebsdata/visdata/init_00k83k38_1_0.ora. This PFILE will be used to create

the database on the target platform

Run RMAN script /export/home/oravis/rman/convert_ebs.rman on target platform to convert

datafiles

To recompile all PL/SQL modules, run utlirp.sql and utlrp.sql on the target platform

To change the internal database identifier, use DBNEWID Utility

Finished backup at 23-FEB-09

RMAN>

Explaining the rman command syntax used above:

RMAN> convert database on target platform convert script

'/export/home/oravis/rman/convert_ebs.rman'

The conversion will be carried out on the target HP-UX system and not on the originating source

database system. A conversion script is generated and saved to the file

/export/home/oravis/rman/convert_ebs.rman. This file is subsequently copied to the HP-UX system

and is executed there under rman to perform the data file conversions.

2> transport script '/export/home/oravis/rman/transport_ebs.sql'

The transport script provides the necessary SQL commands to recreate the database on the HP-UX

system using the converted database data files. It is copied to the HP-UX system and executed there

after the data files have been converted using rman with the convert_ebs.rman script.

26

3> new database 'VIS' format '/ebsdata/visdata/%U' db_file_name_convert

'/oracle/db/visdata','/ebsdata/visdata';

The target database will continue to be called VIS as indicated by the database clause.

The format and db_file_name_convert clauses provide a mechanism for specifying the location of the

files that will be used on the target HP-UX system. It influences the directory path names used inside of

the scripts and templates so that files are located in their desired locations at the target server.

The db_file_name_convert rule instructs rman to convert all occurrences of the /oracle/db/visdata

pathname on the source server to /ebsdata/visdata at the target. That is, if a data file is called

/oracle/db/visdata/sys1.dbf on the source system it should be renamed to

/ebsdata/visdata/sys1.dbf at the target. This is especially useful if the names and locations of the file

system directories where the Oracle EBS database is to be stored are different on the target when

compared to the source.

If a file is not covered by the db_file_name_convert rule then the format clause is used to specify the

file system location to use. The %U in this case indicates that rman should automatically generate a

unique filename. Note: The template database initialization file that gets created by rman will be

saved on the source system at the location specified in the format clause. If that directory does not

exist then rman will fail with an open file error.

Once the scripts and initialization template files are generated, copy them from the source system to

the new HP-UX database system ensuring that the files are owned by the HP-UX user ID associated

with the Oracle instance.

Step 4: Make the source data files from Solaris available on the target HP-UX system

To create the database data files for the target HP-UX system, we take the automatically generated

rman scripts and template files and then apply them against the source system‟s data files using rman.

By executing the scripts, the rman command reads the source data files from the Solaris system and

processes them to create a new set of data files that are then usable on the HP-UX server. The rman

process does not modify the source data files during this activity.

The HP-UX server‟s access to the source data files can be made in a number of ways and which is the

most appropriate will depend on the environment that you have in place.

If there is sufficient free disk space available on the target HP-UX system such that two copies of the

database data files can be kept then it may make sense to initially copy the source data from the

Solaris system to the HP-UX system before proceeding with the conversion. This option is likely to

provide the fastest I/O processing speeds during the rman conversion given that all data is located on

locally or SAN attached disk storage. However, the time to copy the data from the source to the

target system also needs to be factored into the time estimates.

Another option is to use NFS to mount the source data files from the Solaris system to the HP-UX

system. Rman processing is then initiated with the source database data files being accessed via NFS

and the target data files stored on fast locally or SAN attached storage. This option requires that the

HP-UX system only have sufficient free disk capacity to hold one database copy but is potentially

slower as all source file access I/O will be via the network. This approach was the method that we

used during our EBS database migration testing.

Whichever method is chosen to make the source data available to the target HP-UX server, it is

important to make sure that the source data files are located at the same path as indicated in the

rman conversion script.

The source file path is generally the same as that of the data files location on the source system

although that can be changed by manually editing the auto generated rman conversion script. For

example, reviewing one typical entry within the rman conversion script shows:

27

CONVERT DATAFILE '/oracle/db/visdata/reference1.dbf'

FROM PLATFORM 'Solaris[tm] OE (64-bit)'

FORMAT '/ebsdata/visdata/reference1.dbf';

In this case, when the rman conversion process is initiated it will read the source data file from

'/oracle/db/visdata/reference1.dbf' and will write the corresponding HP-UX system ready output

file to '/ebsdata/visdata/reference1.dbf'. If the path names used in the rman conversion script do

not match with the file system layout on the HP-UX server then the conversion will fail. Also worth

validating is that the appropriate file and directory permissions are set such that rman will run

correctly under the ORACLEDBUSER user ID.

Step 5: Convert the data files and create the database on HP-UX

Convert the source data files at the target system:

Now that the conversion scripts, database initialization template and source data files are available

at the target HP-UX system we are now ready to carry out the data file conversion and create the new

target database.

As a precursor to executing the rman command, make sure that the shell environment on the HP-UX

server is setup correctly. Login with the ORACLEDBUSER HP-UX user ID and make sure that the

following shell variables are set:

ORACLE_HOME Set to the directory location where the target Oracle Home was installed.

PATH Extend the shell‟s path variable to include the Oracle binaries that are

used during the conversion process. For example, include

$ORACLE_HOME/bin within the $PATH variable

ORACLE_SID Set this to the SID of the migrated database. This was provided during the

rman conversion process and should be the same as the source database.

ORA_NLS10 Set this to the directory where the 9i NLS data was created during the

initial install and setup of the database.

Next, review the template init.ora file that was generated in step 3 to make sure that file and directory

locations are set as desired. As the initialization template file was auto generated by rman with the

“%U” flag in the format option, it has created a series of unique filenames for the control file and

dump destination directories. If preferred, these unique names can be modified by editing the

database initialization file at this stage so that they are more readable and easier to manage.

Once the database initialization file has been validated then the rman conversion process can be

started. In HP‟s migration testing we used the HP-UX script command to save a copy of the terminal‟s

session so that it could be reviewed later for any errors or problems that may be encountered.

The first step in converting the data files is to start the rman command from the shell prompt and then

starting up the database using the rman startup command:

$ rman

Recovery Manager: Release 10.2.0.4.0 - Production on Wed Feb 25 15:51:29 2009

Copyright (c) 1982, 2007, Oracle. All rights reserved.

RMAN> connect target /

connected to target database (not started)

RMAN> startup nomount pfile=/ebsdata/visdata/init_00k83k38_1_0.ora

28

Oracle instance started

Total System Global Area 25769803776 bytes



Database Buffers 25014829056 bytes


RMAN>

Note that the rman startup command uses the option:

nomount pfile=/ebsdata/visdata/init_00k83k38_1_0.ora

This indicates that the database should not be mounted (there is no database yet on the HP-UX system

to mount) and that the template database initialization template file should be used which in this case

is located at /ebsdata/visdata/init_00k83k38_1_0.ora. Once the database has been successfully

started, then the rman conversion script can be run:

RMAN> @convert_ebs.rman

RMAN> RUN {

2>

3> CONVERT DATAFILE '/oracle/db/visdata/reference1.dbf'

4> FROM PLATFORM 'Solaris[tm] OE (64-bit)'

5> FORMAT '/ebsdata/visdata/reference1.dbf';

6>

7>

… entries similar to the above for each of the database’s data files to convert…

276>

277>

278> CONVERT DATAFILE '/oracle/db/visdata/owa1.dbf'

279> FROM PLATFORM 'Solaris[tm] OE (64-bit)'

280> FORMAT '/ebsdata/visdata/owa1.dbf';

281>

282>

283> }

Starting backup at 25-FEB-09

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=986 devtype=DISK

channel ORA_DISK_1: starting datafile conversion

input filename=/oracle/db/visdata/reference1.dbf

converted datafile=/ebsdata/visdata/reference1.dbf

channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:15:27


… Entries similar to the above for each of the database’s data files converted …

Starting backup at 26-FEB-09

using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile conversion

input filename=/oracle/db/visdata/owa1.dbf

converted datafile=/ebsdata/visdata/owa1.dbf

channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:08


RMAN>

RMAN> **end-of-file**

Once the conversion has completed, shutdown the database within rman:

RMAN> shutdown

Oracle instance shut down

RMAN>

29

Recovery Manager complete.

$

If the HP-UX script command was being used to record the session, stop that now by exiting the

associated shell (using control-d or the exit command) and save the recorded output using a more

meaningful filename.

Review the output from the rman conversion to check that there were no reported errors.

If the process completed without any problems, then a set of database data files suitable for use on

the HP-UX server will now be available ready for the database creation step.

Create the database:

Now that the EBS database files have been transferred to the HP-UX server and conversion using

rman has completed, we can proceed to the database creation step. The new database is created

using the transport SQL script that was generated earlier. This script essentially constructs a new

database instance based on the newly converted data files that hold the EBS data in them.

Before proceeding with executing the transport SQL script (which is named transport_ebs.sql in our

testing), review the contents in case any of the auto-generated filenames included in the script need

updating for use in your environment.

The SQL transport file options that we changed as part of our testing were:

The control file name: Note that multiple control file copies should be in place for your production

environment and that the initial template initialization file only creates one. Multiple control file

copies can be implemented after the database has been created.

The temporary tablespace data file name: The temporary tablespace is defined as part of the

database creation on the target system and is not transported over from the source database

machine.

The filenames of the database log files used for the new instance. The transport script originally

used character sequences in the filenames that were likely to be unique on the target system.

However, it is not easy to identify from those names that the files contain database log information

and so a more intuitive naming scheme was substituted.

Once the transport script has been updated with the appropriate filenames and directory locations,

run the script whilst logged in as ORACLEDBUSER using sqlplus. We recommend once again using

the HP-UX script command to capture the terminal session so that it can be reviewed after the script

completes for any errors.

$ sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.4.0 - Production on Thu Feb 26 09:40:48 2009


Connected to an idle instance.

SQL>

The transport script includes the statement required to initially startup the Oracle instance and follows

this by creating the database. It finishes the process by forcing a recompilation of the PL/SQL objects

in the EBS database:

SQL> @transport_ebs.sql





30



Control file created.

Database altered.

Tablespace altered.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* Your database has been created successfully!

* There are many things to think about for the new database. Here

* is a checklist to help you stay on track:

* 1. You may want to redefine the location of the directory objects.

* 2. You may want to change the internal database identifier (DBID)

* or the global database name for this database. Use the

* NEWDBID Utility (nid).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Database closed.

Database dismounted.

ORACLE instance shut down.







Database mounted.

Database opened.

SQL>

SQL> WHENEVER SQLERROR EXIT;

SQL>

... Script continues processing …

SQL>

SQL> Rem ===========================================================================

SQL> Rem END utlrp.sql

SQL> Rem ===========================================================================

SQL> set feedback 6;

SQL> Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit

Production


$

On successful completion of the transport script, the new database instance is created on the target

HP-UX system. As the new database has been built using converted data files from the source Solaris

system, the database already contains the majority of the EBS data.

Migrate the database initialization file:

Up to this point, the template database initialization file has been used for converting and creating

the HP-UX database instance. Although this template is sufficient for these initial steps, the database

initialization file from the original EBS database should now be transferred and updated for the target

HP-UX system.

To migrate the database initialization file, copy over and review the initialization files from the Oracle

Home directory on the source Solaris database environment to the target. These files are generally the

init<instance>.ora and <instance>_hostname_ifile.ora files located in the dbs directory in the Oracle

Home where <instance> is the name of your database instance. Substitute your database instance

name and hostname when copying these files for your environment.

Review the database initialization files for any items that may need to be updated to reflect the new

HP-UX database environment. For example, the names and location of the control files or perhaps the

dump destination locations could be different between the two systems. The values should be

correlated with the settings from the transport SQL script and template initialization files run earlier.

31

Although not recommended at this step, the initialization file should also be updated and tuned to

take advantage of the different capacity of the target HP-UX server. Areas to review include increased

memory capacities that mean that SGA and PGA parameters can be increased, or perhaps less but

more powerful processors which might suggest different values for the number of DB writers, parallel

workers or the number of queue workers.

Tuning the database initialization file should be done after the whole migration process has

completed. For the rest of the database migration activities, the initialization file should keep its

settings largely identical to those found on the source database.

Step 6: Handle the external and platform-specific data

Our target HP-UX database instance now contains the majority of the data from the source system

with the exception of the external and platform-specific items identified in Step 2 above. To complete

the data migration, those items from Step 2 must now be imported into the HP-UX database and

appropriately handled based on their data type and characteristics.

For our migration testing of the VIS database, two areas of external and platform specific data were

identified. These were items referenced through database directory links and OLAP‟s Analytical

Workspaces which contained platform-specific formatted data.

Importing the Analytical Workspaces on the HP-UX system:

In an earlier step we exported the data from those analytical workspaces (AWs) which were

associated with EBS application data. The exported data from those AWs were saved in operating

system files with an .eif filetype. In this step we use that exported data and create SQL scripts to

import the AW contents into the target HP-UX database system so that valid workspaces are available

once again for application use.

In our sample migration we identified three workspaces that needed special processing and these

were ZPBANNOT, ZBPCODE and ZPBDATA all of which were found in the ZPB schema. During the

export process it was discovered that although the ZPBANNOT and ZPBDATA workspaces were

defined they held no data and so no export file was created. For this reason, only the ZPBCODE

analytical workspace will be imported whilst the other two workspaces will be simply created.

The first step in the AW import process is to transfer the exported “.eif” data files from the source

system to the HP-UX server ready for processing by the database‟s dbms_aw utility. Once the data is

available on the target, it is suggested that a SQL script be created that when run deletes the current

invalid analytical workspaces from the database, creates the new workspaces and then imports the

saved data into those workspaces.

The following sample script was used in our migration testing:


create directory AW_DUMP as '/home/oracle/aw';

exec dbms_aw.aw_delete('ZPB' , 'ZPBANNOT');

commit;

exec dbms_aw.execute('aw create ZPB.ZPBANNOT');

exec dbms_aw.execute('update');

commit;

exec dbms_aw.execute('aw detach ZPB.ZPBANNOT');

exec dbms_aw.aw_delete('ZPB', 'ZPBCODE');

commit;

exec dbms_aw.execute('aw create ZPB.ZPBCODE');


commit;

exec dbms_aw.execute('aw attach ZPB.ZPBCODE rw');

exec dbms_aw.execute('import all from eif file ''AW_DUMP/zpbcode.eif ''data dfns');


commit;

exec dbms_aw.execute('aw detach ZPB.ZPBCODE');

32

exec dbms_aw.aw_delete('ZPB' , 'ZPBDATA');

commit;

exec dbms_aw.execute('aw create ZPB.ZPBDATA');


commit;

exec dbms_aw.execute('aw detach ZPB.ZPBDATA');


The script can be broken down into the following activities:

create directory This creates a database directory object that references the HP-UX

file system directory where the “.eif” import files will be located

dbms_aw.aw_delete Delete the existing analytical workspace that are still held in the

target database. Although the transportable database mechanism

keeps the analytical workspace data in the new target database,

it still contains platform-specific information from the source system

that will cause errors if accessed from the HP-UX target.

aw execute with create This command creates the new analytical workspace in the HP-UX

database instance. It is possible to add additional parameters to

the create subcommand specifying the degree of parallelism and

tablespace in which the workspaces should be stored. In our

testing, the source system stored the ZPB owned workspaces in the

APPS_TS_TX_DATA tablespace. As APPS_TS_TX_DATA is the default

tablespace for the ZPB user, no additional parameters were

necessary when recreating the workspaces on the target system.

aw execute with update Save the current set of changes to the database. A commit must

also be processed for the work to be made permanent.

aw execute with import Import the data from the file identified into the workspace. In our

sample migration, only the zpbcode workspace needed importing.

aw execute with detach Detach from the current workspace.

drop directory Drop the database directory object created at the start of the script.

Once a similar script has been created based on the needs of your particular source database

environment, execute it and check for any reported errors. If a problem is found, the script can be run

again as it deletes any existing AWs first before recreating or importing them.

External Directory Data:

As part of the external data discovery process in step 2, a list of database directory objects was

obtained from the source database system. These directory objects were examined to see if they

referenced any EBS or related data that needed migration from the source system to the HP-UX target.

If any external data was determined to need relocation, that data can now be transferred from the

source system to the target database file system.

If the original file system paths that were identified in the source database‟s directory entries are kept

the same, then the file data copied from the source to the target must be located in exactly the same

directory at the target. If practical, it is possible to update the database directory entries in the target

33

database so that they reference a different location within the HP-UX file system. This may be

especially desirable if the filename contains entries based on the hostname of the database server

which has now likely changed with the database migration.

Other External Data:

In our sample migration we have handled the special cases of external data in the form of database

directory entries and analytical workspaces. The dbms_tdb.check_external() routine may have

identified additional entities on your source server that may need special handling. If other external

data was identified in step 2, handle those special cases at this point before proceeding.

Step 7: Implement EBS’s AutoConfig

At this stage of the migration, the EBS database has been fully transferred from the source system to

the HP-UX target and is almost ready for use by the application tier. While the database itself has

been fully migrated, the EBS AutoConfig framework used to configure the database‟s environment has

not been implemented on the new server and this step now completes this configuration.

Implementing AutoConfig on the database node:

EBS AutoConfig support for the database tier is enabled via configuration utilities and data files that

are located in the appsutil directory within the database‟s Oracle Home. The contents of the appsutil

directory are not provided as part of the Oracle Database software installation but rather shipped as

a component of the EBS product suite.

To enable the appsutil directory on the database‟s Oracle Home directory, EBS provides the

admkappsutil.pl Perl script. This script allows the AutoConfig software to be transferred from one

machine to another using a ZIP file. The admkappsutil.pl script is run on the source machine (which in

this case would be the Solaris application tier) and the resulting zip file copied over to the target HP-

UX database server.

On the source Solaris based server, run the admkappsutil.pl script and note the location of the

resulting ZIP file:

$ perl $AD_TOP/bin/admkappsutil.pl

Starting the generation of appsutil.zip

Log file located at /oracle/apps/visappl/admin/log/MakeAppsUtil_03170954.log

output located at /oracle/apps/visappl/admin/out/appsutil.zip

MakeAppsUtil completed successfully.

$

Copy the ZIP file to the database server:

$ scp /oracle/apps/visappl/admin/out/appsutil.zip oracle@<HP-UX-TARGET>:.

Password:

appsutil.zip 100% |***************** … ************| 2826 KB 00:00

$

Whilst logged on as ORACLEDBUSER, uncompress the appsutil.zip file from within the database

instance‟s ORACLE_HOME directory. This will create the appsutil sub-directory in the target system‟s

ORACLE_HOME which now contains the AutoConfig code and template data needed for AutoConfig

to run.

Although the AutoConfig code and template data is now available at the HP-UX database system, the

database-side context file and EBS topology database have not yet been customized to reflect the

specific configuration now in place.

34

Building the new HP-UX database system’s autocontext template:

The adbldxml.pl script is used to construct an AutoConfig context file that reflects the characteristics of

the HP-UX database system‟s configuration. This script is run from the newly created appsutil/bin

directory on the HP-UX database system and requires that the ORACLE_HOME, ORACLE_SID and

PATH shell variables be properly setup before executing. The script also requires that the database

and database listener be started as it connects to the database as part of it processing.

The following shows an example of running this command:

$ perl adbldxml.pl tier=db appsuser=apps appspasswd=apps

Starting context file generation for db tier..

Using JVM from /oracle/ebsdbhome/jdk/bin/java to execute java programs..

The log file for this adbldxml session is located at:

/oracle/ebsdbhome/appsutil/log/adbldxml_02271510.log

AC-20010: Error: File - listener.ora could not be found at the location:

/listener.ora

indicated by TNS_ADMIN. Context file can not be generated.

Could not Connect to the Database with the above parameters, Please answer the Questions

below

Enter Hostname of Database server: TGTDBHOST

Enter Port of Database server: 1521

Enter SID of Database server: VIS

Enter the value for Display Variable: :0.0

The context file has been created at:

/oracle/ebsdbhome/appsutil/VIS_TGTDBHOST.xml

$

On completion of the script, a new AutoConfig context file has been built (VIS_TGTDBHOST in this

case) that contains the appropriate definitions for the target HP-UX system. This context file is

subsequently used as input to adconfig.sh which generates the familiar database-side administration

scripts in addition to updating the internal EBS topology database.

Before running the adconfig.sh script, we recommend validating that the context file has values set as

anticipated to avoid any unexpected configuration problems later. Also note that the database and

listener need to be started for this step to complete successfully.

Running adconfig.sh on the HP-UX database server:

The adconfig.sh command is used to build new configuration files and command scripts on the target

HP-UX database system and to update the EBS topology information with the new node‟s information.

Before running the adconfig.sh command, we recommend removing the EBS node topology

definitions for the original source Solaris database system from the copy of the database now running

on the target HP-UX system. If the definitions for the Solaris database system were not removed before

the database was transferred to the HP-UX system, then those will still be considered to be active by

the AutoConfig framework even though the database is now on the target system.

Should the adconfig.sh command be run with the Solaris system still defined in the EBS topology then

the generated configuration will reflect entries for both databases. For example, the tnsnames.ora file

that is written by the AutoConfig process will list both databases servers for the EBS instance‟s

database service. If this situation inadvertently occurs then it is possible to make unintended changes

against the original source database.

35

To validate the current contents of the EBS topology database either the fnd_net_services.show()

PL/SQL function can be called or the FND_NODES table queried directly. An example of using the

fnd_net_services package is shown below:

$ sqlplus apps/apps

SQL*Plus: Release 10.2.0.4.0 - Production on Fri May 22 15:22:35 2009


Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production


SQL> set serverout on

SQL> exec fnd_net_services.show('VIS') ;

System Name Version Owner CSI Number

--------------- --------------- -------------------- ---------------

VIS 1 Oracle Apps N/A

>

… more entries…

>

Server Name Internal Type Node Host Domain

-------------------- ---------- ---------- ---------- ---------- ---------------

TGTDBHOST_VIS_DB Y DB TGTDBHOST

>>

Home Name|Path Version Description

-------------------- --------------- ------------------------------

APPS-DB db102

/oracle/ebsdbhome

>>>

….

The fnd_net_services.show() PL/SQL function displays the EBS topology database for the whole EBS

instance and database entries are show with a type of DB.

In our migration exercise, we removed the original Solaris database from the EBS topology database

using the method outlined in Metalink document 218089.1. This involves calling the

fnd_net_services.remove_server() PL/SQL routine while connected to the target database via sqlplus.

An alternative approach is to call the fnd_conc_clone.setup_clean PL/SQL routine whilst connected to

the target database which effectively removes all of the existing EBS topology information for both the

applications and database tier. If this approach is taken, then executing AutoConfig on the database

and all application tier servers will fully redefine the topology database once again.

Once the EBS topology database has been verified, the adconfig.sh command can be run. The

following shows an example of using the adconfig.sh command in our migration test environment:

$ ./adconfig.sh

Enter the full path to the Context file: CONTEXT_FILE

Enter the APPS user password: <APPS_PW>

The log file for this session is located at:

/oracle/ebsdbhome/appsutil/log/VIS_TGTDBHOST/02271513/adconfig.log

AutoConfig is configuring the Database environment...

AutoConfig will consider the custom templates if present.

Using ORACLE_HOME location : /oracle/ebsdbhome

Classpath :

/oracle/ebsdbhome/jdk/jre/lib/rt.jar:/oracle/ebsdbhome/jdk/lib/dt.jar:/oracle/ebsdbhome/jdk/

lib/tools.jar:/oracle/ebsdbhome/jdbc/lib/ojdbc14.jar:/oracle/ebsdbhome/appsutil/java/xmlpars

erv2.zip:/oracle/ebsdbhome/appsutil/java:/oracle/ebsdbhome/jlib/netcfg.jar:/oracle/ebsdbhome

/jlib/ldapjclnt10.jar

Using Context file : /oracle/ebsdbhome/appsutil/VIS_TGTDBHOST.xml

Context Value Management will now update the Context file

Updating Context file...COMPLETED

36

Attempting upload of Context file and templates to database...COMPLETED

Updating rdbms version in Context file to db102

Updating rdbms type in Context file to 64 bits

Configuring templates from ORACLE_HOME ...

AutoConfig completed successfully. $

When this command completes, AutoConfig has generated the appropriate configuration and control

scripts within the $ORACLE_HOME/appsutil/scripts/VIS_TGTDBHOST directory and these can now

be used to start and stop the EBS database environment. Examining the EBS topology database

should also now reflect the new database host environment for the target HP-UX system.

Step 8: Update the application tier configuration to use the new database

The final step in the database migration process is to reconfigure the application tier layer so that it

now uses the freshly migrated database located on the HP-UX system. Once reconfigured, the new

EBS environment should be fully tested to ensure that all is operating correctly before releasing the

system back to production usage. We also suggest taking a full backup of the database and

applications tier at this point.

Updating the application tier node configuration to use the migrated database:

Modifying the application tier configuration involves updating each of the participating application

tier node‟s context files with the details of the newly migrated HP-UX database system. Once the

context file configuration changes have been made, adautocfg.sh is run so that those changes are

activated by writing local configuration files and updating the EBS configuration information in the

database.

Key context file parameters that requiring updating to reflect the migrated database‟s environment

include:

s_idDB If you were previously running EBS in a configuration where a single machine was

both the database and the applications tier then these settings need updating. With

the new configuration, the database is located on a separate server and the original

system is now only running applications tier processing. Set this variable to false

to indicate that the node is not running the database any more.

s_dbhost This is the hostname of the database server. Reset this value to the “short” hostname

for the HP-UX database system (TGTDBHOST in our examples).

s_dbdomain Set this to the DNS domain name that is associated with the HP-UX database system

s_dbport Set this to the port number used by listener on the HP-UX database server. This is

normally 1521 but can be updated if desired.

s_apps_jdbc_connect_descriptor Update the JDBC URL so that the hostname in the URL

reflects the new HP-UX server and not the original database system. If the listener

port number was changed then this also needs updating in the JDBC URL.

Use the tools that are most familiar to update these settings in the context file and once the changes

are made, review the context file for correctness before proceeding to run adautocfg.sh.

Once the adautocfg.sh command has completed, check the log file for any error messages or non-

zero return codes. If all completed successfully, then the application tier on that server is ready to

start.

37

After reconfiguration has occurred on each of the application tier server, we suggest that AutoConfig

be run once again on the HP-UX database system. Under certain circumstances, AutoConfig on the

database tier will not fully update the sqlnet.ora file with the names of all of the application tier

systems. This can cause permission denied errors at the application tier layer when it initially contacts

the listener as the application tier hostname is not included in the sqlnet.ora permission list.

Step 9: Testing the new EBS database

Although not strictly required as part of the process, we suggest comparing the count and status of the

database objects between the source and the target systems before starting the application tier. You

may find the following SQL examples useful when comparing the object state between the source and

the target systems:

Total object count summarized by object type:

select object_type , count(1) as TypeCount from dba_objects

group by object_type order by 2 asc;

Total object count summarized by object owner:

select owner , count(1) as OwnerCount from dba_objects group by owner order by 2 asc;

Total invalid object count broken down by object owner:

select owner , count(1) as InvalidObjectCount from dba_objects where status != 'VALID'

group by owner order by 2 asc;

If there are differences between the invalid object count between the source and target database

systems, consider first recompiling those objects using the utlrp.sql script found in the database‟s

$ORACLE_HOME/rdbms/admin directory. If the object counts still remain substantially different, then

we suggest investigating this before proceeding to starting the application tier.

If the object count comparisons does not show any substantial problems then proceed to starting the

EBS application tier. Use the customary adstrtall.sh command to start EBS on each of the application

tier nodes and validate that there are no errors reported in the startup log files during its processing.

When all nodes have started successfully, run through the test scenario that is applicable to your EBS

environment to make sure that all is operating as expected. Check for any unexpected error messages

in both the application tier nodes as well as the database‟s alert log file.

Using functional, performance and scalability testing tools such as HP‟s LoadRunner suite is great way

to validate that your EBS system is operating correctly and can meet the demands of your user

population.

Once all functional and load testing that would normally apply against an updated EBS system has

been completed successfully, the environment is then ready to be released back to production use.

38

Migrating the EBS application tier to Linux

The first part of this paper outlined the process of migrating an EBS database from a source Solaris

system to the target HP-UX database environment. The second part of the document covers the

methodology that can be used to migrate an EBS application tier from a source Solaris environment to

an Oracle Enterprise Linux (OEL) implementation.

As part of this document‟s preparation, HP tested the migration process for relocating an EBS 11i

application tier from a SPARC based Solaris system to Oracle Enterprise Linux on an HP BL460c

blade server. The source EBS environment was based on the Oracle EBS Vision demo database

environment in which all of the application tier components were run on a single server. Concurrent

Manager is considered to be part of the application tier in our test configuration and was not

implemented on the database server.

We describe the process of application tier migration by breaking the set of activities into two major

parts. The first task covers the preparation of the HP BL460c blade server with OEL and the necessary

configuration and patching required to host the EBS application code. The second task covers the

actual migration process from Solaris to OEL itself.

Preparation of HP BL460c target server with Oracle Enterprise Linux 5.1

Figure 2. Target System (Oracle Enterprise Linux 5.1 on an HP BL460c blade server)

NIC 1

NIC 2

UID

HP

Pro

Lia

nt

BL

46

0c

Initial Oracle Enterprise Linux 5.1 installation

In testing the migration, HP chose to use Oracle Enterprise Linux 5.1 as the release of Linux on which

to host the application tier. Other versions of Linux are also certified with the EBS 11.5.10 CU2

application stack and details of those can be found in the Certify section of Oracle‟s Metalink

website. We recommend validating with the Metalink certify information to make sure that the version

of Linux you plan to use is certified with 11.5.10.2 and to check for any last minute updates that may

have been posted for that combination.

A key document to review when installing Linux for the EBS application tier is the 11.5.10 CU2 Install

and Update Notes (IUN) which can be found in Metalink document 316806.1. This document

provides specific details on what software, patches and configuration updates are required to run EBS

11.5.10.2 on each of the different varieties of certified Linux operating systems.

39

HP provides a number of ways to perform the initial Linux operating system install of its ProLiant and

BladeSystem servers, ranging from the use of physical media devices through installations via the

network using HP Insight Rapid Deployment Software (also known as RDP). In our migration testing,

the virtual media feature of the Integrated Lights Out controller was used which allows for ISO image

files stored on a remote PC to be presented to the BL460c server and appear as a locally accessible

DVD device.

HP also delivers the Oracle Enterprise Linux 5 software bundle that contains a collection of drivers

and utilities specifically designed for OEL 5 in the HP ProLiant environment. The software bundle

includes the drivers necessary for supporting hardware options that are commonly used with ProLiant

systems in addition to other value added utilities. The software can be downloaded from the

http://www.hp.com website by searching for “Oracle Enterprise Linux 5 Software Bundle”.

One consideration during the installation process is the disk storage layout. If you plan to locate the

EBS application files on disk drives that are internal to the server, ensure that you have enough free

space for the installation and any log files that may be generated during the normal operation of EBS.

This is especially important for the node(s) that run the Concurrent Manager where the size of the log

and out files can potentially be significant.

For the HP test environment, the initial OEL 5.1 install did not enable the SELinux security and iptables

firewall options. If additional security features such as iptables are required then additional care will

be needed during the port selection process during the EBS migration. Also, when asked by the OEL

installation program what features should be installed, we recommend that the application

development option be selected as several of the required RPMs for the installation of the EBS

applications tier are bundled in this set.

An easy mistake to make when initially installing the Linux software on the HP ProLiant or HP

BladeSystem servers is to inadvertently use the installation media for the 64 bit version of the

operating system rather than the 32 bit version. Oracle EBS 11.5.10 is certified only on the 32 bit

version of the Linux operating system and so that version must be installed.

To validate whether you have the 32 bit version of the Linux operating system installed, use the

uname –p command and check that it returns i686 as the CPU type. If it returns x86_64 then you

likely have the 64 bit version of Linux installed.

Once the OEL 5.1 operating system has been installed it then needs further customizations to prepare

it for use with the EBS 11.5.10.2 applications environment. These customizations are detailed in the

following sections.

Prepare the Oracle Enterprise Linux 5 update 1 environment

Oracle Enterprise Linux 5.1 pre-requisite software:

To run Oracle EBS 11.5.10.2 with OEL 5.1 requires that specific levels of a number of software

packages be installed in addition to what is provided by the core operating system. The specific levels

required are outlined in the EBS 11.5.10.2 Installation Update notes available on Metalink and are

summarized below:

Table 3: Pre-requisite OEL Software

Package Name Version Available From

kernel 2.6.18-8.el5 (at a minimum for

OEL 5.1)

OEL Update distribution

glibc 2.3.4-2.26 (at a minimum for OEL

5.1)

OEL Update distribution

http://www.hp.com/

40

Package Name Version Available From

compat-libstdc++-egcs 1.1.2-1 Oracle OSS website at

http://oss.oracle.com/projects

/compat-

oracle/files/Enterprise_Linux

compat-libcwait 2.1-1 Oracle OSS website

compat-oracle-el5 1.0-5 Oracle OSS website

openmotif21 2.1.30-11.EL5 Oracle OSS website

binutils 2.15 Oracle OSS website

libXp 1.0.0.-8.1.el5 OEL 5.1 Install Media

compat-libgcc 296-2.96-138 OEL 5.1 Install Media

compat-libstdc++ 33-3.2.3-61 OEL 5.1 Install Media

compat-db 4.2.52-5.1 OEL 5.1 Install Media

To determine which version of a package is currently installed on your OEL 5.1 system, use the rpm

command with the –q flag to query a specific package:

# rpm -q glibc

glibc-2.5-18

#

In this case, the version of the glibc package is 2.5-18 which is higher than the minimum required for

use with OEL 5.1.

The pre-requisites so far have focused on the necessary software to correctly run the EBS application

tier on the Linux system once a migration has completed. To support the migration process itself, it is

also necessary to make available Perl and a Java Virtual Machine (JVM) on the target OEL system so

that the various migration scripts and programs can function correctly.

For Perl, version 5.0.0.5 or greater is needed for running the Perl-based migration scripts. The OEL

5.1 installation provides Perl version 5.8.8 by default so this requirements is normally met without

further action.

A functioning Java Virtual Machine is required to run the Java code that is used during the migration

process. In our migration testing, we installed version 1.4.2_04 of Java as this the release that was

being used within the source Solaris environment. The Java software for Linux x86 can be

downloaded from the internet at http://java.sun.com and we installed our Java environment in the

/usr/local/java directory. Note that the GCJ-based version of Java that is supplied with the OEL

operating system should not be used with EBS either in production or during the migration process.

OEL 5.1 operating system configuration updates:

With all pre-requisite packages now installed on the OEL 5.1 system, the next step is to configure the

operating system so that it is ready to host the Oracle EBS 11.5.10.2 software. There are several

areas of the operating system that require customization and these are presented in the follow

sections:

http://java.sun.com/

41

1. Increase the number of open file descriptors by modifying the /etc/security/limits.conf system file.

Edit: /etc/security/limits.conf

# Modify the open file descriptors per Oracle EBS

# 11.5.10.2 installation notes

* hard nofile 65535

* soft nofile 4096

2. Increase the TCP/IP networking port range value by modifying the /etc/sysctl.conf system file.

Edit: /etc/sysctl.conf

# Modify the port range per Oracle EBS 11.5.10.2

# installation notes

net.ipv4.ip_local_port_range = 10000 65000

Note: The lower value of the port range may need to be adjusted depending on your final port

allocations within EBS. The ip_local_port_range parameter indicates to the Linux kernel the range

of lowest to highest port numbers that it can use when a connection is initiated that isn‟t explicitly

bound to a local port address. If the lower end of the range is set too low then it is possible that

this can conflict with a port that EBS plans to use causing potential networking errors within EBS.

Set the lower end of the range to greater than any planned port numbers that EBS will utilize.

3. Modify the DNS resolver parameters for timeout and attempt limits by editing the /etc/resolv.conf

system file and including the following lines:

Edit: /etc/resolv.conf

# Modify session limits per Oracle EBS 11.5.10.2

# installation notes

options attempts:5

options timeout:15

4. Ensure that the /etc/hosts file has entries in it for the systems that are participating in the EBS

environment. The format of each host entry is important and requires that the fully qualified domain

name (FQDN) be the first entry after the assigned IP address. The FQDN entry is then followed by

the corresponding short hostname. The text below provides an example of the format that should

be used:

Edit: /etc/hosts

127.0.0.1 localhost.localdomain hostname

10.1.1.2 appsource.mycompany.com appsource

10.1.1.3 apptarget.mycompany.com apptarget

10.1.1.4 dbserver.mycompany.com dbserver

5. Validate Linux network settings that are used during the system startup process to correctly specify

the machines hostname and default routing settings. The individual network interfaces are

configured during the initial OEL 5.1 installation process and this step validates that the hostname

and default route/gateway options are set correctly. For OEL 5.1, review the

/etc/sysconfig/network file to make sure that a fully qualified name is specified for the hostname

and that the gateway address is correct for your specific networking environment:

File: /etc/sysconfig/network

NETWORKING=yes

NETWORKING_IPV6=no

HOSTNAME=TGTAPPSHOST.hp.com

GATEWAY=10.1.2.3

Note that in our testing we also disabled IPv6 so that the traditional IPv4 networking protocols

were the only ones in use.

Also, if the /etc/sysconfig/networking/profiles/default file was created during the installation

process, then delete it at this time.

42

6. If you made any modifications to configuration files on the target EBS application server up to this

point then a reboot of the machine is required to make them active. We suggest rebooting at this

point to make sure that you have the appropriate environment in place for the subsequent

configuration/installation steps.

7. Certain EBS applications require that a specific version of the ld command (linker/loader) is in

place in order to perform EBS re-links correctly. The loader version needed by EBS is 215 and this

should already have been provisioned by installing the compat-binutils215 rpm package. To make

the 215 version of the ld command the one that is used by default, enter the following commands

whilst logged as the root user:

# cd /usr/bin

# mv ld ld.orig

# ln -s /usr/bin/ld215 /usr/bin/ld

# ./ld -v

GNU ld version 2.15.92.0.2 20040927

#

These commands rename the original ld executable to ld.orig and then creates a symbolic link so

that the ld215 executable can be referenced to simply as ld. To confirm that the correct version is

indeed in place, run the “ld –v” command and check that it displays the correct version.

8. Apply Oracle patch 6078836. This patch provides a copy of the libdb shared library for use with

the OEL system and is available as a download from the Oracle Metalink website. After

downloading the patch, verify the instructions in the patch readme for instructions on how to install

the library. In our migration testing, the patch was installed by the root user by unzipping the

downloaded image, moving the libdb.so.2 file to /usr/lib and then symbolically linking libdb.so.3

to it:

# cp libdb.so.2 /usr/lib

# ln -s /usr/lib/libdb.so.2 /usr/lib/libdb.so.3

Check the libraries are correctly in place:

# ls -las libdb.so.*

8 -rw-r--r-- 1 root root 5825 Mar 4 15:32 libdb.so.2

0 lrwxrwxrwx 1 root root 19 Mar 4 15:34 libdb.so.3 -> /usr/lib/libdb.so.2

#

9. Create the APPLMGR user and DBA group on the target system. Although not strictly required, it is

often easier if the same UID and GID numeric values are chosen for the user and group at the

target application server environment as were originally used on the source system. Specific GID

and UID values can be requested on the useradd and groupadd command lines using the –u and

–g flags respectively.

The following shows a specific example of creating a dba group with a gid of 501 and the

applmgr user ID with a uid of 502:

# groupadd -g 501 dba

# useradd -u 501 -g 501 -m applmgr

# id applmgr

uid=501(applmgr) gid=501(dba) groups=501(dba)

#

Once the user ID is created, change the password for the EBS application tier user ID via the

passwd command.

10. Create the file system(s) that will accommodate the application tier directory structure on the target

system. In our testing, we used the same directory structure on the target Linux system as was in

place on the source Solaris machine. This potentially makes the migration easier as file and

directory locations on the source and target systems have the same path names. Maintaining the

43

same file system layout makes the environment easier for administrators to understand and also

reduces the need for modifications to site-specific scripts or programs that may be in use.

Create the directory structure at the target based on the layout on the source server:

<APPL_TOP>

# mkdir /oracle/apps/visappl

<COMMON_TOP> # mkdir /oracle/apps/viscomn

<COMMON_TOP>/util # mkdir /oracle/apps/viscomn/util

<COMMON_TOP>/_pages # mkdir /oracle/apps/viscomn/_pages

<OA_JAVA> # mkdir /oracle/apps/viscomn/java

<OA_HTML> # mkdir /oracle/apps/viscomn/html

The directory ownership should now be reset to APPLMGR now that the directory structure is in

place at the target system:

# chown –R applmgr:dba /oracle

This completes the initial OEL installation, operating system patching and pre-requisite configuration

steps on the target Linux system. It is now ready to receive the migrated EBS application tier.

Preparation of the Oracle E-Business Suite 11i source server

With the target Linux server now installed and the operating system updated, the next step in the

process is to prepare the source Solaris EBS applications tier environment for the migration. This set of

activities involves validating that components of the source EBS applications software are at the

appropriate level for the migration, that AutoConfig is fully implemented and that the release of the

EBS database meets the minimum required.

Validating EBS software levels

The EBS Database Server:

In our migration testing we used an EBS application instance that ran against an Oracle 10.2.0.4

database server. If your environment includes a database server that is lower than Oracle 8.1.7.4

then the database will need to be upgraded in order for the migration to continue.

If you have already migrated your database from the source Solaris system to the HP-UX system as

outlined earlier in this document then your database will already be at 10gR2 and so no action is

required. This check is relevant if only the EBS application tier is being relocated to a Linux server.

Apply the latest AD patch to the source EBS application tier:

For the migration to proceed, the AD product level must be at AD.I.5 or higher.

The current level of the AD product can be determined either by running the adadmin command and

checking the version reported once you reach the main menu or by running the adutconf.sql script

which will report a wider collection of EBS software levels.

44

To run the adutconf.sql script, login to the source application tier server using the APPLMGR user ID

and source the application tier environment file. Then run:

$ sqlplus apps/<appspw> @$AD_TOP/sql/adutconf.sql

This generates the adutconf.lst file which holds the product level details for that node.

In our test environment it was necessary to upgrade the AD environment and we applied patch

6502082 as the latest AD patch at the time of testing. This patch brought our AD software up to level

AD.I.6. Instructions on how to apply the patch and special patch application procedures are

documented in the patch readme.

We recommend checking Metalink to find what is the most recent AD patch available is at the time of

your migration.

Implement AutoConfig on the source EBS application tier instance:

EBS‟s AutoConfig must be implemented on the source EBS instance in order for the migration to

proceed. If your current environment does not use AutoConfig, please follow the instructions in

Metalink document 165195.1 on how to perform the migration from a non-AutoConfig to AutoConfig

environment.

In our migration testing we used the EBS sample VIS environment that came with Oracle EBS 11.5.10

CU2. This instance already has AutoConfig implemented and so no further actions were required.

Update the AutoConfig templates to the latest levels via the latest TXK patch:

The AutoConfig environment uses template files during the configuration process to automatically

generate the underlying configuration information that the EBS application code and technology stack

(tech stack) uses. It is important to make sure that these template files are up to date before

proceeding with the migration.

These AutoConfig template files are updated by applying the TXK AutoConfig Template rollup patch,

the latest version of which can be found documented in Metalink document 165195.1. In our

migration testing, we applied patch 6372396 which was the latest available at the time of our

migration exercise.

Apply the latest Rapid Clone patch:

The migration process utilizes EBS‟s Rapid Clone functionality and so this component needs to be

updated so that it is at the latest level available at the time of the migration. The most recent Rapid

Clone patch numbers can be found in Metalink document 230672.1 and in our migration testing we

ensured that patches 3453499 and 6718351 were applied.

Create a current snapshot of the application environment

So that the EBS current snapshot information is fully up to date within the database, run the adadmin

command and choose the “update current view” option. This activity should be carried out on all of

the source EBS application tier nodes so that the snapshot information is accurate for every node that

participates in the EBS instance. This is especially important if any patches have been applied as part

of the preceding steps to make sure the updated file information is current in the EBS snapshot

database.

To update the snapshot information, log in as APPLMGR, source the application tier environment file

and then run adadmin to create a snapshot of the current view of the APPL_TOP information.

$ . APPSTIER_ENV_FILE

$ adadmin

45

From the AD Administration Main Menu

select 2. Maintain Applications Files menu

select 5. Maintain snapshot information

select 2. Update current view snapshot

Note: We suggest that a complete working backup of the

entire database is also performed at this point prior to

continuing.

Migrate the EBS application software components

Now that the source EBS application tier environment has been brought up to the appropriate patch

levels and the target BL460c server has OEL 5.1 installed and customized, we can begin the process

of migrating the application tier code from the source system to the target.

The migration process is composed of a number of steps that builds a new EBS application tier

through a combination of copying selected files, installing and patching software, executing software

rebuilds and reconfigurations and finally testing the environment.

The following pages break down the migration process into a series of discrete steps which on

completion should yield a migrated EBS application tier on the target Linux system.

Step 1: Build a source system manifest and generate the migration patch

The customer-specific patch is an automatically generated EBS patch that is applied to the target

system later in the migration process. The patch includes much of the Linux platform-specific code for

the target system that cannot be leveraged from the source Solaris system due to its different processor

and operating system environment.

The first step to generating your customer-specific patch is to build a manifest list of EBS application

files from the source Solaris system. This list is then uploaded to the Oracle Platform Migration website

found at http://updates.oracle.com/PlatformMigration. This Oracle website analyzes the contents of

the source system manifest and generates a new customer-specific patch which is then applied to the

target system at a later stage.

To generate your site specific manifest file on the source Solaris system, run the adgenpsf.pl Perl script

whilst logged into the Solaris system using the corresponding APPLMGR user ID:


$ perl $AD_TOP/bin/adgenpsf.pl

The command will proceed to create the manifest file and store its output to the file located at

$APPL_TOP/admin/$TWO_TASK/out/adgenpsf.txt. Examining this file should show content similar

to the following:

# Application_System_Name: VIS

# Release: 11.5.10.2

# Appl_Top_Name: srcsrvr # Platform: SUN_OS5

ad adadmin.o 115.82

ad adadmin_main.o 115.7

http://updates.oracle.com/PlatformMigration

46

ad adapps.o 115.1

ad adcasesn.o 115.34

ad adccfl.o 115.2

ad adcds.o 115.1

ad adcfil1.o 115.7

ad adcfil2.o 115.4

ad adchkdig.o 115.3

….

Once the manifest file has been created, upload it to the Oracle Platform Migration website which

will then proceed to build your customer-specific applications patch for the target Linux system.

Start a browser and navigate to http://updates.oracle.com/PlatformMigration and use your Metalink

username and password to access the site. Once logged in, follow the directions to upload the

manifest file ensuring that you specify the target system platform type as Linux x86 and the EBS

release as 11i.

After submitting the manifest file to the website, the patch will be generated and made available for

download. An e-mail is sent when the patch is accessible and the e-mail will include a password that

you use during the download of your customer-specific patch.

Note: In our testing, the size of adgenpsf.txt observed

during this procedure was approximately 298KB. The

special patch created using this manifest file was in the

order of 64MB.

Step 2: Create the target system APPL_TOP files leveraging the source system installation

As some components of the EBS application tier environment are built using software that is platform

independent, these entities can be directly copied from the source Solaris system to the target Linux

based server. For example, Java classes and Jar files, Oracle Forms, PL/SQL code, html and other

technologies used within EBS can easily be moved from one system to another as their machine-

specific dependencies are located in the corresponding tech stack components.

To start populating the Linux system‟s APPL_TOP, selected files from the Solaris system‟s EBS

application tier are copied to the target Linux server. The specific directories (including their contents

and subdirectories) that should be copied are:

$APPL_TOP (/oracle/apps/visappl in the HP test environment)

$OA_HTML (/oracle/apps/viscomn/html in the HP test environment)

$OA_JAVA (/oracle/apps/viscomn/java in the HP test environment)

$COMMON_TOP/util (/oracle/apps/viscomn/util in the HP test environment)

$COMMON_TOP/_pages (/oracle/apps/viscomn/_pages in the HP test environment)

In our migration testing, we used the rsync command to move the files from the source system to the

target, but any file transfer mechanism that performs binary file transfers of files and directories is

usable. Other commands that could be used include rcp, scp or even tar and ftp.

Once the recursive file copies for the above directories have completed, validate that file user and

group ownership settings are the same on the target system as they are on the source. This is

http://updates.oracle.com/PlatformMigration

47

especially important if the Linux UID and/or GID associate with the APPLMGR user are different on

the source and target operating systems.

One situation that we ran into during a later stage of our migration testing was the versions of the

Java that are under the $COMMON_TOP/util directory. As the contents of $COMMON_TOP/util

were copied from the source Solaris system, the Java Virtual Machines in $COMMON_TOP/util/jre

and $COMMON_TOP/util/java are not applicable for the x86 Linux environment. We resolved this

problem when we encountered it by installing the same Java version but for the x86 Linux

architecture. This new JVM installation replaced the original one that was copied over from the Solaris

source machine.

Step 3: Copy or update the JInitiator security information

One element of the EBS client security mechanism uses certificates and JAR signing techniques. This

helps to protect the end-user‟s JInitiator environment from malicious activities and also enables trusted

mode when running Java on the end-user‟s PC.

When migrating from the source Solaris system to the Linux EBS application tier it is possible to either

continue to use the original digital certificate environment from the Solaris system or to regenerate

new certificates that contain the specific details about the new application tier environment. The

digital certificates do contain information about the source machine on which they were generated

but it is not required that a certificate‟s host information match the machine(s) on which they are

installed.

To continue using the original certificates generated on the Solaris system during its initial installation,

copy over the identitydb.obj file to the Linux system. Taking this approach means the least impact to

the existing end-user base as their currently installed JInitiator environment already includes the details

on the original digital certificate.

In HP‟s testing, we chose to have the digital certificate regenerated and this is achieved by removing

the appltop.cer file from the $APPL_TOP/admin directory. The certificate file (and other Java security

related files) are then automatically recreated and updated by the AutoConfig process that is carried

out in a later step. As Jar files will now be signed with a new digital signature that the EBS end-users

PC population is not aware of, it is likely that updates to those PCs will be required so that they

recognize and trust the new security certificate. If you wish to avoid requiring any changes to the PCs

of the EBS end-user population, we suggest choosing to retain the original certificate from the source

system.

If you are interested in validating the contents for the appltop.cer file you can use Java‟s keytool

command to print out the various fields within the certificate. This is useful for validating that the new

certificate has indeed been regenerated and that the various fields are as expected. Use the keytool -

printcert -file appltop.cer whilst in the $APPL_TOP/admin directory to print out the current certificates

contents.

Step 4: Construct an AutoConfig XML context file on the target Linux server

A pre-requisite of the AutoConfig process is the XML context file that is used to store the EBS

configuration information for each server that participates in the EBS instance. This file is named using

the convention <EBS_Instance>_<hostname>.xml and is located in the $APPL_TOP/admin directory

on each node in the EBS instance. For example, the AutoConfig file for our target Linux server would

be located in the /oracle/apps/visappl/admin directory with a filename of VIS_TGTAPPSHOST.xml.

We refer to the context file‟s absolute pathname symbolically in this document as CONTEXT_FILE.

As the target Linux system is a new node it is necessary to build a fresh XML context file that

represents the initial configuration to be used on that server. To generate this new context file, the

adclonectx.pl script is used.

48

Whilst logged into the target Linux system as APPLMGR, change to the $AD_TOP/bin directory and

run the following command:

$ perl adclonectx.pl migrate java=JDK_HOME contextfile=CONTEXT_FILE

Where:

JDK_HOME is the location where the Java Virtual Machine was installed on the Linux target server

And

CONTEXT_FILE is the location where the created context file will be saved. This is normally set to

$APPL_TOP/admin/<EBS_instance_id>_<node_hostname>.xml.

Note: When executing this command in our test environment we found that it initially failed as it could

not connect to the running database. This problem was diagnosed as an issue with the database-side

security settings as the Linux application tier node was not yet listed in the tcp.invited_nodes list within

sqlnet.ora file. Adding the hostname of the Linux server to the tcp.invited_nodes list in sqlnet.ora file

and restarting the listener resolved this problem.

As the adclonectx.pl script runs it prompts for information about the new server. After providing the

information that adclonectx.pl needs, the command completes and creates a fresh context file stored

in the $APPL_TOP/admin directory. We recommend reviewing this context file to double check that

there are no unexpected entries or typing mistakes that might cause configuration errors later in the

migration.

Step 5: Install the middle-tier technology stack and customer-specific EBS application tier patch

Install the middle-tier technology stack:

The previous activities migrated elements of the EBS application functionality from the source Solaris

system to the target Linux server by copying over the platform-independent program files. Many of

these programs are platform-independent because they are developed utilizing infrastructure software

such as Java, Oracle Forms, Oracle Database, Oracle Reports and so on which allow for programs

built on one platform to be run without recompilation on another.

In this stage, the technology stack software that is specific to the Linux server is installed so that the

supporting infrastructure software that enables Java, Oracle Forms and the other programming models

is available.

Installing the technology stack on the Linux server involves running the Rapid Install Wizard

(RapidWiz) with the –techstack option. This indicates to RapidWiz that only the relevant technology

stack software should be installed and not the full EBS applications tier software environment.

Before starting the RapidWiz command check that your EBS install media is at the appropriate

product level and is the most recent version available. In our testing, we migrated an 11.5.10 CU2

system and so used the Rapid Install media for 11.5.10.CU2 as our base.

Updates are occasionally distributed by Oracle for the Rapid Install media and, if available, can be

downloaded via Oracle Metalink by referencing the Release Notes for the appropriate Oracle

Applications version. In HP‟s testing, we used the 11.5.10.CU2 Rapid Install media which was found

to be at version 11.5.10.35 as identified by the RapidWizVersion command. At the time of the

testing, Metalink document 316803.1 indicated that this was the most current level available.

To start the tech stack installation process, log in as the APPLMGR user ID using an X-Windows

capable device as the RapidWiz installer is a GUI based command. In our case, we ran the installer

from the Linux machine‟s graphical console by using the HP BladeSystem Remote Console capability.

49

Once logged in, run the rapidwiz –techstack command to start the installer. As RapidWiz proceeds, it

asks for information on what required components are needed and the file system locations where the

software should be installed:

Choose the 9iAS as the tech stack to install (Database is the other available option)

When prompted for the context file, choose the option to use an existing file and supply the location

of the context file created in the previous step via adclonectx.pl

Enter the desired locations for the 806 and iAS Oracle Homes. In our testing, we preserved the

familiar Oracle Home paths from the source system (/oracle/apps/visora/8.0.6 for the 806

Oracle Home and /oracle/apps/visora/iAS for IAS)

Once all of the required options and information has been provided, RapidWiz will proceed resulting

in the Linux platform tech stack components being installed into their corresponding Oracle Homes.

When RapidWiz completes, scan the log files associated with the installation session for any errors or

issues that may have been encountered, especially during the linking phase.

This step installs the EBS 11i tech stack on the Linux system at the software levels that were first

certified when the original RapidWiz media was released. Although the source Solaris system may

still be operating at this original tech stack software level, it is more likely that tech stack components

have been patched or upgraded since the initial installation was completed. If this situation has

occurred, then the newly installed Linux system will be at a lower tech stack version as compared to

the Solaris source machine and will need updating appropriately. This situation is addressed in Step

7 where the current Linux tech stack environment is upgraded so that it is at the same software levels

as the source system.

Step 6: Update the platform-specific EBS business application components

Up to this point we have installed on the target system the platform specific tech stack and copied

over much of the platform-independent parts of the EBS application from the source system. In this

step, the customer-specific applications patch that was generated earlier is applied which delivers

many of the platform-specific components for the Linux implementation of the application tier.

Before applying the customer-specific patch, it is necessary to partially run the AutoConfig utility so

that enough of the environment files are in place that the adpatch command will operate properly.

Run the AutoConfig INSTE8_SETUP phase on the target Linux system:

To allow adpatch to run properly, execute the INSTE8_SETUP phase of AutoConfig using the new

context file that was created in step 4. This is achieved by logging into the system using APPLMGR

and then running adconfig.sh with the run=INSTE8_SETUP flag:

$ cd <AD_TOP>/bin

$ ./adconfig.sh run=INSTE8_SETUP contextfile=<target system contextfile>

where:

AD_TOP is set to the ad/11.5.0 directory under the EBS visappl directory

(/oracle/apps/visappl/ad/11.5.10 in our test environment)

<target system contextfile> is set to the full pathname of the context file that was created earlier using

adclonectx.pl.

After the command has completed, check the AutoConfig log file (the location of which is shown

during the command‟s execution) for any error or warnings.

50

Apply the customer-specific EBS Applications patch:

In Step 1, a manifest file was created containing information about the source Solaris application tier

system. This file was uploaded to an Oracle website with a request to generate a customer-specific

patch for the use in a migration to Linux.

Once the patch has been created by Oracle, an e-mail is sent providing the patch number and a

password-protected location from which it can be downloaded. This patch will now be applied to the

target Linux system.

The downloaded patch from the website is in a zip format. Select a directory with sufficient free space

to hold the patch‟s contents and unzip the file. In HP‟s testing, the size of the directory holding the

unzipped customer-specific patch for our Linux system was just under 400Mb.

Review the README file that is provided as part of the patch for any special instructions. To apply the

patch, login as APPLMGR, change to the directory in which the patch was unzipped, source the

APPSTIER_ENV_FILE environment file and then run the adpatch options=noprereq command. This

sequence is illustrated below:

$ cd <custom-patch-extraction-directory>


$ ./adpatch options=noprereq

As part of the patch application process, a re-link of EBS application binaries will occur so that the

newly patched libraries are used to rebuild the Linux specific binaries.

For some programs, the re-link will fail as Linux versions of certain third-party products have not yet

been installed and so those dependencies cannot be met. For example, EBS components that rely on

iLog or Quantum libraries cannot link successfully as those libraries are not yet in place on the Linux

system. This is an expected situation and is resolved in Step 11 where those third-party products are

subsequently installed and an additional adrelink performed.

If errors are reported during the link related to the missing third-party libraries, accept the error and

continue with the link process. Do not stop the link process due to these types of errors.

Step 7: Update the Tech Stack to match the source system level

Using the tech stack-only install option with RapidWiz provisions the initial software versions of the

tech stack software that were originally certified with EBS 11.5.10 CU2. As time has progressed,

your source Solaris system may have undergone further patching and upgrading of its tech stack

components so that its software is at a higher revision than that installed by RapidWiz on Linux. If this

is the case, then the tech stack software on the target Linux system should undergo the same patching

and upgrades as was performed for the original Solaris system.

As an example, in our HP test environment we applied the Developer 6i Patch Set 19 to the source

Solaris system as a pre-requisite for our database migration activities. As this patch set was applied

on top of the core 11.5.10 CU2 environment then we also need to apply this patch to our Linux target

system.

Review all tech stack patches and upgrades on the source Solaris system that have accumulated on

top of the core 11.5.10 CU2 software levels and apply those same updates to the Linux target system

at this point.

Step 8: Apply the tech stack interoperability patch

Apply patch 4139957 to the Linux application tier which enables the environment to interoperate

correctly with Developer 6i Patch Set 15.

51

In our testing, we found that this patch had already been applied as we had previously installed all

the relevant patches to support Developer 6i Patch Set 19. As a result, no additional action was

required for this step.

Step 9: Regenerate the file system objects

With the majority of the EBS application and tech stack components now in place on the Linux system,

it is now possible to regenerate many of the EBS application objects (Forms, Reports, Messages and

so on) from their source.

If in your configuration, the target Linux server is designed to run the Forms applications then the first

step is to regenerate a number of Forms objects via the adgensgn.sh command. First source the

application tier environment file whilst logged in with APPLMGR and then run the adgensgn.sh

command found in the $AD_TOP/patch/115/bin directory:


$ $AD_TOP/patch/115/bin/adgensgn.sh apps/<appspw>

Starting Regeneration of FNDSCSGN and attached libraries...

Generating $AU_TOP/resource/APPCORE.plx ...

Generating $AU_TOP/resource/APPCORE2.plx ...

Generating $AU_TOP/resource/APPDAYPK.plx ...

Generating $AU_TOP/resource/APPFLDR.plx ...

… continues with a series of forms resources …

$

Once the specialized form related object regeneration has completed, use adadmin to regenerate the

remaining Messages, Forms, Reports, Graphics and Jar files:

$ adadmin

From the AD Administration Main Menu

Select 1. Generate Applications Files menu

From the Generate Applications Files Menu select each of

the following options in turn to regenerate these categories of items:

1. Generate message files

2. Generate form files

3. Generate report files

4. Generate graphics files

5. Generate product JAR files

Verify at each step of the regeneration process that there are no unexpected errors, and if there are,

investigate the cause and resolve the issue before proceeding. It is almost certain that an object that

fails to regenerate properly and is used within your EBS environment will cause issues and problems

once the system becomes live.

Step 10: Complete the full AutoConfig configuration of the target Linux system

With enough of the EBS application tier environment now in place on the target Linux system, we can

proceed to run a full AutoConfig session to complete the machine‟s full configuration. As this step will

fully instantiate the new application tier system, the existing source Solaris system will need to shut

down before proceeding. All users will not be able to access the EBS system until the remaining steps

of the migration are completed.

52

We recommend reviewing the Linux system‟s EBS application tier context file and comparing it to the

configuration represented by the context file from the source Solaris system before proceeding. If the

comparison shows unexpected differences then investigate and resolve those first.

Run AutoConfig using the APPLMGR user ID to complete the Linux target system configuration; source

the application tier environment file first:


$ cd $AD_TOP/bin

$./adconfig.sh contextfile=CONTEXT_FILE

Check the log file for any reported errors or warnings after the AutoConfig utility has completed its

processing. If any are found, make sure that they are investigated and resolved before moving on to

the final steps.

Step 11: Update third-party extensions

If your EBS application tier environment utilizes functionality that depends on third-party products

(such as iLog, Rogewave or Quantum) then these will need to be installed now. Third party

dependency products are delivered via patches which are available from the Oracle Metalink

website.

During the earlier initial re-link phase on the Linux system, you may have encountered link errors due

to missing program libraries that are delivered as part of these third-party products. After installing the

relevant patches that supply the missing libraries, the EBS programs can once again be re-linked

using adadmin. As all dependencies should now have been met then the adrelink should not fail.

At the time of writing, the following patches deliver the specified third-party products:

Table 4. Patch information

Software Details

ILOG Apply patch 2837811.

ROGUE WAVE

The documentation suggests applying patch 3006092. However,

during our testing we found that this patch was missing the libcplex8.a

library. Applying the more recent 4297568 Rogue Wave patch resolved

this issue.

QUANTUM Follow the instructions in document 224273.1 on Oracle Metalink

The above patches do not use the adpatch utility for installation but implement their own patch-specific

processes. Make sure to review the README file shipped with each patch for full details on how to

apply the updates.

Once the relevant patches for your environment are applied, use the adadmin command and re-link

the EBS application tier product executables once again. Start adadmin, choose “Maintain

Applications File” and then “Relink Application Programs”. At this stage, there should be no link

errors during the process as all dependencies have been met by the application of the third-party

dependency patches.

Step 12: Review any site-specific customizations from the source system

If your EBS environment on the source Solaris system involved any implementation-specific

customizations then these should be reviewed and now implemented on the target system.

http://updates.oracle.com/ARULink/PatchSearch/process_form?bug=2837811&language=0&process=Submit

http://updates.oracle.com/ARULink/PatchSearch/process_form?bug=3006092&language=0&process=Submit

http://metalink.oracle.com/metalink/plsql/ml2_documents.showNOT?p_id=224273.1

53

Typical tasks include compiling and validating any specially written code for your instance or

ensuring that any modifications to the standard EBS applications are also brought forward to the Linux

system. Updated specialized Forms, Reports, Java code, XML data or native “C” code are all targets

for review.

Any code customizations that were only implemented at the database system do not need to be

reviewed as they do not involve change at the application tier.

EBS implementations can also be customized through various profile and configuration options that

are typically stored within the database and are not directly updated through the AutoConfig process.

Some of the customizations may include the application tier system node names as part of their

parameter or option strings. If during the migration the target application tier system now has a

different node name than the original source system then these profiles and configuration options will

need updating.

Some examples of where node or host names are configured directly within EBS include the Parallel

Concurrent Processing option for the Concurrent Manager. In this case the definitions for the jobs that

run within the system specify which Concurrent Manager node(s) each job should be executed on.

Similarly, for more advanced EBS configuration topologies, there are a number of profile options that

include node names that are used by EBS for constructing the URLs that are sent back to the end user‟s

web browser.

If your target application tier node name has changed then review your EBS configuration and profile

options to make sure that the new node name is now used in place of the original setting.

Step 13: Update font information if the UTF8 character set was in use

If your source EBS application tier instance was setup to use the UTF8 character set, ensure that EBS

on the Linux system has also been customized for that environment. Details on how to enable UTF8

support can be found in the EBS installation guide in Chapter 6 and involves editing the Tk2Motif.rgb

files found under the 8.0.6 ORACLE_HOME directory.

If you are not sure whether the source system was using the UTF8 character set, search the

Tk2Motif.rgb files found under the {8.0.6 ORACLE_HOME}/guicommon6/tk60/admin directory for

the property named Tk2Motif*fontMapCs. If this property remains commented out (as was the case in

our sample migration environment) then no action is required. If the property is not commented out

and then modify the corresponding Tk2Motif.rgb file on the target Linux system to also reflect this

same setting.

Note that there are several directories under the ORACLE_HOME/guicommon6/tk60/admin that

correspond to different languages and each directory also has its own copy of the Tk2Motif.rgb file.

Make sure that you verify the settings for all national languages that your EBS system is required to

support.

Step 14: Migrating complimentary Oracle software

Many EBS implementations also implement additional Oracle software products that provide added

capabilities over and above the core EBS functionality. For example, EBS can optionally be integrated

with the Oracle Single Sign-on (SSO) product which allows for a user to authenticate once and gain

access to EBS and other applications without requiring further logins.

If your site uses these additional capabilities then these will need to be migrated over to the new Linux

application tier environment.

If you have implemented SSO capabilities or use Oracle Portal 3.0.9 with your EBS 11i instance then

see Metalink document 146469.1 for details on how to install and configure that environment on the

new Linux system. Note that both SSO and Portal at the 3.0.9 release are now no longer covered by

premier support and the recommendation is to migrate to a newer product such as Oracle Application

Server 10g.

54

If your business uses Oracle Discoverer 4i for business intelligence analysis then details are provided

in Metalink document 139516.1 on how to implement this on the target Linux server. Similar to the

SSO and Portal case, Discoverer 4i has announced the end of error support for this product and the

recommendation is to migrate to the newer product environment provided by Oracle Business

Intelligence Discoverer 10g. Information on using Discoverer 10g with EBS 11i can be found in

Metalink document 313418.1.

Step 15: Update printer settings

To enable printing from the new Linux target server, configure the same set of printers that were

available from the source Solaris machine. OEL provides the system-config-printer GUI utility to assist

with the printer configuration processes.

Note that additional RPM packages may be needed over and above the default system installation to

support certain types of printers on Linux. For example, the hplip rpm package can be used to

provide drivers for some HP printers and multi-function devices.

If you are currently not using PASTA for printing then this may be a good time to investigate and

consider moving to this output framework.

Step 16: Update workflow configuration settings

An integral component of the EBS applications environment is the workflow infrastructure. Some

applications within EBS are designed specifically to use workflow during their processing and on

occasions those applications include host-specific information as part of their submitted workflow

data.

As an example, some data in the workflow includes web URL addresses that are used for obtaining

status about particular workflow items. Those URLs include the specific hostname of the server which

the browser should contact when status is needed. In the case where the application tier machine‟s

hostname has changed as part of the migration process, the URL will now be incorrect as it does not

reference the new Linux server.

If the hostname of your application tier servers has changed as part of the migration process then the

host-specific information within the workflow infrastructure will need to be updated.

The following table provides information on the specific workflow related database tables that may

need updating as part of the migration. Each row in the table below includes information on what

column within the database table need validating and the types of updates that may be required.

Table 5. Workflow related database tables

Table Name Column

Name Column Value Details

WF_NOTIFICATION_ATTRIBUTES TEXT_VALUE

Relevant rows will contain Web URLs with the

original source application tier system hostname in

them. Rows that require updating match the SQL

search string „%http%<old web hostname>%‟.

Update the old_web_hostname field with the new

Linux server‟s hostname.

WF_ITEM_ATTRIBUTE_VALUES TEXT_VALUE

Relevant rows contain Web URLs with the original

source system hostname in them. Rows that

require updating match the SQL search string

„%http%<old web hostname>%‟. Update the

old_web_hostname field with the new Linux

55

Table Name Column

Name Column Value Details

server‟s hostname.

WF_SYSTEMS GUID

The workflow system name needs to be updated

to reflect the new server. Refer to Metalink

document 387337.1 for details on how to

proceed. In our testing, we used option (2) from

this Metalink document and ran the txkWfClone.sh

script. Option (1) from the Metalink document

could not be followed as the full applications tier

was not yet fully available.

WF_SYSTEMS NAME

Value needs to be replaced with the database

global name. In our testing, the txkWfClone.sh

script ran for the GUID column updated this

column to the correct value.

WF_AGENTS ADDRESS

Update the database link component of the

address with the current database global name. In

our testing, we found that the DB Link name was

initially set to VIS34 which did not the match any

links in our current installation. We updated the

db link part of the name to point to our global

database name (VIS). Note that as part of an

application tier migration exercise the database

global name should not change.

Step 17: Update additional database table based configuration settings

In addition to the workflow settings discussed above, it is also necessary to update other EBS

database tables that may hold information that reflect the pre-migration state. The following provides

information on the specific tables and columns within those tables that need evaluating for update:

Table 6. Tables and columns within those tables that need evaluating for update

Table Name Column Name Column Value Details

FND_FORM_FUNCTIONS WEB_HOST_NAME

Search for any rows that have a

web_host_name that matches the original

Solaris based server. If rows are found,

update the column with the hostname for

the new Linux system. In our migration

testing we did not find any rows that

required updating.

FND_FORM_FUNCTIONS WEB_AGENT_NAME

Validate that there are no source system

host-specific values specified in this field.

If there are, update web_agent_name to

point at the new target system instead.

FND_CONCURRENT_REQUESTS LOGFILE_NAME Update this column if the applications tier

directory structure has changed between

56

Table Name Column Name Column Value Details

the source and target systems for the

location of the Concurrent Manager job

log files. The logfile_name column

contains the full pathname to the log file

and when modifying this column only the

directory part of the string should be

updated.

FND_CONCURRENT_REQUESTS OUTFILE_NAME

Update this column if the applications tier

directory structure has changed between

the source and target systems for the

location of the Concurrent Manager job

output files. The outfile_name column

contains the full pathname to the log file

and when modifying this column only the

directory part of the string should be

updated.

Step 18: Update CLASSPATH settings

Selected CLASSPATH entries within the target Linux EBS environment may need updating depending

on the versions of Java that were installed on the system. If the Java version is 1.3.1 or above, then

any references to the appsborg.zip file need updating to appsborg2.zip within the classpath setting.

To validate which Java version is being used by the AD component, use the “java –version” command

where the correct Java executable from the AD associated Java Home needs to be run. Within our

testing, we used the following commands to validate the AD Java version:

$ $ADJVAPRG -version

java version "1.4.2_04"

Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)

Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode)

$

Here we see that Java version 1.4.2_04 is being used and so the related appsborg2.zip file must be

in the AD classpath. This can be verified by checking that the s_adovar_classpath element within the

context file includes appsborg2.zip and not appsborg.zip.

For Concurrent Manager nodes, the $AFJVAPROG –version command can be used to evaluate which

Java version is used with concurrent programs. If the version reported is 1.3.1 or higher then ensure

that the s_adovar_afclasspath element in the context file includes appsborg2.zip and not

appsborg.zip.

In general, we would recommend moving to the most recent supported version of Java with your EBS

11i environment. For some platforms, Java versions earlier than Java 1.4.2 are considered at End Of

Life status which limits the support available for them.

If modifications to the context file were necessary, then the next step of running AutoConfig will

update the EBS configuration files so that the new appsborg2.zip files are subsequently used.

Step 19: Execute the final AutoConfig session for the migration

As the final step before starting up the new migrated environment, run a full AutoConfig session on all

of the nodes in the EBS environment (applications and database) so that the new configuration is fully

propagated. This is achieved using the usual adautocfg.sh command found in the admin directories

on all of the application tier nodes and the database node.

57

In our migration testing, we found that it was important to re-run the AutoConfig on the database

node after all the application tier nodes had been configured. If the database node is configured

before the new application tier node(s) have been added, then the listener security list in the

sqlnet.ora file is not updated with the new node names and those new application tier instance will

not be able to connect to the database.

Once all AutoConfig sessions have been completed and their corresponding log files checked for any

errors then the migration phase has completed and the new environment is ready for startup using the

adstrtal.sh command.

Testing the new environment

Now that the application tier has been migrated from the source Solaris system to Linux, it is

recommended that the environment undergo an appropriately detailed degree of testing before it is

released to the end user population. How much testing and what areas of the EBS application are

exercised are normally customer specific, but as a simple first step “smoke test”, the following

procedure using Oracle Applications Manager (OAM) can be used:

Access the Oracle Applications Manager using a web browser:

From an Internet browser, select the address for the Applications Server Apache Port to access the

Welcome screen for OAM.

http://apptarget.mycompany.com:8000

Select the link for Apps Logon Links.

Select the link for Oracle Applications Manager.

User ID: OPERATIONS

Password: <Your OPERATIONS PASSWORD>

This will display the HOME PAGE for the OAM.

Select the SITE MAP link.

Select the HOSTS link to view the status of the applications environment.

Select the SITE MAP link.

Select the Diagnostics and Repair tab.

With the application set to “HTML Platform”, select Launch Diagnostic Tests.

Select the Basic tab.

Select the Run All Groups button.

All tests should complete without any errors.

For more information

HP BladeSystem overview http://www.hp.com/go/blades

HP BL860c, Intel® Itanium® processor based blade http://www.hp.com/go/bl860c

HP BL870c, Itanium processor based blade http://www.hp.com/go/bl870c

HP-UX Enterprise Class UNIX operating system http://www.hp.com/go/hpux

HP BladeSystem ProLiant x86 processor based blades

http://h18004.www1.hp.com/products/blades/components/c-class-bladeservers.html

HP StorageWorks information site http://www.hp.com/go/storage

HP and Oracle Alliance http://www.hp.com/go/oracle

Certified HP Hardware with OEL http://www.hp.com/go/oelcert

Online documentation for HP products http://docs.hp.com

To help us improve our documents, please provide feedback at

http://h20219.www2.hp.com/ActiveAnswers/us/en/solutions/technical_tools_feedback.html.

Technology for better business outcomes

© Copyright 2009 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

Intel and Itanium are trademarks of Intel Corporation in the U.S. and other countries. Java is a US trademarks of Sun Microsystems, Inc. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. UNIX is a registered trademark of The Open Group.

4AA2-6655ENW, Revision 2, June 2009

http://www.hp.com/go/blades

http://www.hp.com/go/bl860c

http://www.hp.com/go/bl870c

http://www.hp.com/go/hpux

http://h18004.www1.hp.com/products/blades/components/c-class-bladeservers.html

http://www.hp.com/go/storage

http://www.hp.com/go/oracle

http://www.hp.com/go/oelcert

http://docs.hp.com/

http://h20219.www2.hp.com/ActiveAnswers/us/en/solutions/technical_tools_feedback.html

Migrating Oracle E-Business Suite 11i from Sun Solaris to ... · PDF fileCreate a test...

Documents

Transcript of Migrating Oracle E-Business Suite 11i from Sun Solaris to ... · PDF fileCreate a test...