Translate this Page

 

Continue from previous posting.

Step-by-Step Migrate Database and Applications

1. Migrate Database of Oracle EBS

After upgrade the database of Oracle EBS to 10g Release 2, migration process will be more easier than if the database version still in 9i. The supported way to accomplish this prior to Oracle Database 10g Release 2 was to export the data from the database on the old platform, create a new database on the new platform, and import the data into the new database. This process could take a number of days for a large database. Oracle Database 10g provides two additional methods of migration a database to a new platform. Oracle Database 10g Release 2 introduced Transportable Database (TDB), which is used to reduce the amount of time and effort required to migrate a database between platforms that share the same endian format (byte ordering). Oracle Database 10g Release 1 introduced cross platform transportable tablespaces (XTTS), which allows data files to be moved between platforms of different endian format. XTTS is an enhancement to the transportable tablespace (TTS) feature introduced in Oracle8i. TTS was originally released as a method to move a subset of one database into another, such as plugging parts of an OLTP database into a data warehouse on the same platform. With the cross-platform enhancement, XTTS can plug data files into a database on a different platform, including those that are using a different endian format. XTTS may reduce platform migration time by moving all user tablespaces from a source database to an empty target database running on a platform that uses a different endian format. With the XTTS feature, Tablespaces plugged into the empty target database by copying the data files to the target database, converting them to the target system endian format, then importing the object metadata into the target database.

In this document, we used HP-UX as Source System. IBM AIX as target system

  1. Check Prerequisites

Define which method of migration will be use by verify the target platform support for TDB or XTTS.

SQL> SELECT platform_name, endian_format
  2  FROM v$transportable_platform;
PLATFORM_NAME                            ENDIAN_FORMAT
------------------------------------ --------------
Solaris[tm] OE (32-bit)              Big
Solaris[tm] OE (64-bit)              Big  *** Target System
Microsoft Windows IA (32-bit)        Little
Linux IA (32-bit)                    Little
AIX-Based Systems (64-bit)           Big
HP-UX (64-bit)                       Big  *** Source System
HP Tru64 UNIX                        Little
HP-UX IA (64-bit)                    Big
Linux IA (64-bit)                    Little
HP Open VMS                          Little
Microsoft Windows IA (64-bit)        Little
IBM zSeries Based Linux              Big
Linux 64-bit for AMD                 Little
Apple Mac OS                         Big
Microsoft Windows 64-bit for AMD     Little
Solaris Operating System (x86)       Little
IBM Power Based Linux                Big

The result of the query showing Source and Target System have the same Endian Format, it is mean we can use method Transportable Database (TDB).

  1. Prepare for the Platform Migration.

2.1.    Identify External Files and Directories that will need to be created to the target system.

SQL> set serveroutput on
SQL> declare x boolean;
begin x := dbms_tdb.check_external; end;

2.2.    Identify External Tables Files that will need to be transferred to the target system.

SQL> SELECT directory_path || ' / ' || LOCATION external_file_path
  2  FROM dba_directories a, dba_external_locations b
  3  WHERE a.directory_name = b.directory_name;

2.3.    Identify BFILES that will need to be transferred to the target system.

SQL> @tdb_get_bfile_dirs.sql
SQL> @tdb_get_bfiles.sql

2.4.    Shutdown the Application until migration to the new platform is complete.

1. Start the database in READ ONLY mode

SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database open read only;

2. Verify the database is ready for migration

SQL> set serveroutput on
SQL> DECLARE
retcode   BOOLEAN;
BEGIN
retcode := DBMS_TDB.check_db ('Solaris[tm] OE (64-bit)',      DBMS_TDB.skip_none);
END;
/

Any condition reported by CHECK_DB must be resolved before TDB can proceed.

3. Run the RMAN CONVERT DATABASE Command

Once the source database is ready for migration, run the CONVERT DATABASE command in RMAN.

There are several types of conversion, convert on source system or convert on target system. But, it’s better to convert on the target system if it has better performance than the source system. And another benefit if we convert on the target system, if the source system and the target system have the same Endian, then we don’t need to convert all, only the data files that contains undo data that should be converted. Usually data files belong to tablespace SYSTEM and UNDO (NOTE: 732053.1). Before convert, we can modify the scripts that have generated.

To generate script for convert database on target platform, running this scripts on the source system. And it will generate scripts for convert data files (convert_sid.rman), create control file (transport_sid.sql) and initialization parameter file (pfile) in $ORACLE_HOME/dbs.

rman target /
convert database on target platform
convert script '/tmp/convert_sid.rman'
transport script '/tmp/transport_sid.sql'
new database 'sid'
to platform 'Solaris[tm] OE (64-bit)' -- Target Platform
format '/staging_folder/sid%U' -- used for create unique file name
db_file_name_convert '/u01/sourcedata_location','/u02/targetdata_location',
'/u02/sourcedata_location','/u03/targetdata_location';

4. Copy necessary file from source to the target

    • PFILE initialization file—Place these files where the database initialization files are located (for example: $ORACLE_HOME/dbs).
    • Transport SQL script
    • External table file system files—Place these files on the target system in the file system that corresponds to the same directory object as the source system.
    • BFILE file system files—
    • Unconverted data files—Place these files in a staging area, convert RMAN script reads data files from this location and write the converted data files to their final location.

5. Conversion on the target system.

7.1. edit convert RMAN script, we will convert only data files that contain undo data.

To check which data files that contain undo data, we can run this query on the source system:

SQL> SELECT distinct(file_name)
  2  FROM dba_data_files a, dba_rollback_segs b
  3  WHERE a.tablespace_name=b.tablespace_name;
FILE_NAME
------------------------------------------------
/u01/sourcedata_location/system05.dbf
/u01/sourcedata_location/system09.dbf
/u01/sourcedata_location/system08.dbf
/u01/sourcedata_location/system12.dbf
/u01/sourcedata_location/system10.dbf
/u01/sourcedata_location/system03.dbf
/u02/sourcedata_location/rbs03.dbf
/u02/sourcedata_location/rbs02.dbf
/u01/sourcedata_location/system11.dbf
/u01/sourcedata_location/system06.dbf
/u01/sourcedata_location/system04.dbf
/u01/sourcedata_location/system02.dbf
/u01/sourcedata_location/system07.dbf
/u01/sourcedata_location/system01.dbf
/u02/sourcedata_location/rbs05.dbf
/u02/sourcedata_location/rbs04.dbf
/u02/sourcedata_location/rbs01.dbf

7.2.    Install database software on the Target System

7.3.    Convert the data files

To convert data files in the target system, then in target should already startup nomount. Startup nomount using the pfile that generated on the step before (Step 5)

Put the data files that contains Undo data into a staging directory. The converted data files will be put in the directory that we mention in FORMAT. There are two type of conversion data files, from source system or target system. I prefer to convert the data files in target system instead in source system, the one of the reason is there is no I/O & network bottleneck during convert since the conversion do in target system.

The example convert RMAN script in target system:

run {
CONVERT DATAFILE '/staging_folder/system01.dbf'
FROM PLATFORM 'HP-UX (64-bit)'
FORMAT '/u02/targetdata_location/system01.dbf';

CONVERT DATAFILE '/staging_folder/system02.dbf'
FROM PLATFORM 'HP-UX (64-bit)'
FORMAT '/u02/targetdata_location/system02.dbf';

CONVERT DATAFILE '/staging_folder/system03.dbf'
FROM PLATFORM 'HP-UX (64-bit)'
FORMAT '/u02/targetdata_location/system03.dbf';
.
.
.
}

To speed conversion process, separate script into some files and running it background.

cat convert_system01.rman
run {
CONVERT DATAFILE '/staging_folder/system01.dbf'
FROM PLATFORM 'HP-UX (64-bit)'
FORMAT '/u02/targetdata_location /system01.dbf';
}

/bin/ksh
rman target / @ convert_system01.rman log=’datafile1.log’ &
rman target / @ convert_system02.rman log=’datafile2.log’ &

7.4.    Startup the Database

7.4.1. Startup nomount, used the pfile that generated on the step before (Step 5).

7.4.2. Create controlfile using transport script that generated on the step before (transport_sid.sql)

7.4.3. After control file created, Open the database.

In the case, version the database in source not same as target (HP-UX DB10g 10.2.0.2.0 –> SUN Solaris SPARC DB10g 10.2.0.3.0) then :

  • Open upgrade the database:
SQL> alter database open resetlogs upgrade;
  • Install and upgrade database components
SQL> @?/rdbms/admin/catupgrd.sql
  • Check the version and the status of the database component after upgrade.
SQL> @?/rdbms/admin/utlu102s.sql

Or you can check by running this script :

SQL> set lin 200
SQL> col comp_name format a40
SQL> select comp_name,version,status from dba_registry;
COMP_NAME                                VERSION         STATUS
---------------------------------------- --------------- -----------
Oracle XML Database                      10.2.0.3.0      VALID
Oracle Text                              10.2.0.3.0      VALID
Spatial                                  10.2.0.3.0      VALID
Oracle interMedia                        10.2.0.3.0      VALID
Oracle Database Catalog Views            10.2.0.3.0      VALID
Oracle Database Packages and Types       10.2.0.3.0      VALID
JServer JAVA Virtual Machine             10.2.0.3.0      VALID
Oracle Database Java Packages            10.2.0.3.0      VALID
Oracle XDK                               10.2.0.3.0      VALID
Oracle Real Application Clusters         10.2.0.3.0      INVALID

If one or more component status is INVALID, we can ignore it as long as we don’t use that component.

  • Shutdown
SQL> shutdown immediate
  • Startup normal
SQL> startup
  • Compile invalid objects
SQL> @?/rdbms/admin/utlrp.sql

If version the database in source as same as target then:

  • Open the database:
SQL> alter database open resetlogs;
  • Add temporary tablespace
SQL> Alter tablespace add temp file;
  • Compile invalid objects
SQL> @?/rdbms/admin/utlrp.sql

2. Step-by-Step of Migrate Applications of Oracle EBS

After migration the database is complete, then we can continue to migrate the applications of Oracle EBS. Although the Applications have different platform with Oracle Database, overall Oracle EBS still can running. In this case, we need to migration the Applications of Oracle EBS also.

1. Generate and upload the manifest of customer-specific files

Log in to your Source System primary administration node as the APPLMGR user and source the APPL_TOP environment file. Execute the following command to generate the customer-specific file manifest. This step should take about a minute:

perl $AD_TOP/bin/adgenpsf.pl

Go to http://updates.oracle.com/PlatformMigration (use your OracleMetaLink username and password) and follow the instructions on the screen to upload the manifest file previously generated:

$APPL_TOP/admin/$TWO_TASK/out/adgenpsf.txt

2. Create the Target System APPL_TOP

Copy the middle tier file system from the Source Applications System to the Target Node by executing the following steps in the order listed. Ensure that the application tier files copied to the Target System are owned by the Target APPLMGR user.

Copy the APPL_TOP file system. Log on to the Source System application tier node as the APPLMGR user and copy the following application tier directories from the Source System to the Target System :

<APPL_TOP>
<OA_HTML>
<OA_JAVA>
<COMMON_TOP>/util    --> Better New install in Target
<COMMON_TOP>/_pages  (when that directory exists)
Attention: Copy only the directories listed, not the full COMMON_TOP.

For <COMMON_TOP>/util in SUN, I install it first from rapidwiz, because if still using from HP, it doesn’t match and it will makes the next step become failed.

Warning: In order to preserve the Concurrent Manager log files and output files you need to consider the configuration of the variables $APPLCSF/$APPLOG and $APPLCSF/APPLOUT.

If these variables are pointing to locations inside the COMMON_TOP directory structure (i.e. $COMMON_TOP/admin/out/$CONTEXT_NAME and $COMMON_TOP/admin/log/$CONTEXT_NAME you will need to copy these files into similar directory structures on the Target System.

3. Copy the security file for JInitiator

If you wish to preserve the Source System digital signature on the migrated System, copy the identitydb.obj file from the Source System to the Target System. This file is located in the APPLMGR user’s home directory on UNIX or the root directory of the %SystemDrive% on Windows.

If you want the migrated System to have a new digital signature, remove the following file from the Target System:

rm <APPL_TOP>/admin/appltop.cer

4. Clone the AutoConfig XML context file on the Target System

The Clone Context tool will ask for all the new mount points on the Target migration node.

Log on to the Target System as the APPLMGR user and run the following commands:

cd $AD_TOP/bin
perl adclonectx.pl migrate java=<JDK HOME> contextfile=<Source System contextfile>

perl adclonectx.pl migrate java=/usr/java  contextfile=$APPL_TOP/admin/<CTXFILE>.xml

Where:

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

<Source System contextfile>:  full path to the Source System Applications XML context file located in <APPL_TOP>/admin on the Target System.

Respond to the prompts. This will create the following Target System context file:

<APPL_TOP>/admin/<SID>_<hostname>.xml

Warning:

When you run this step, it will remove the HP-UX JDK in $COMMON_TOP/util. Since the JDK for HP-UX is totally different, it will be better to install $COMMON_TOP for the Target Platform.

5. Install the Middle Tier Technology Stack

Run the Rapid Install Wizard with the -techstack option to install the iAS technology stack. Use the Target System context file created in the previous step.

cd [Stage11i]/startCD/Disk1/rapidwiz
./rapidwiz -techstack

Follow the instructions in the “Installation Tasks” section of Installing Oracle9i Application Server 1.0.2.2.2 with Oracle Applications 11i” (document 146468.1).

Note: Use the latest startCD available in OracleMetalink. Refer to the “Current Version of Rapid Install” section in the Oracle Applications Release Notes for details on the latest startCD Patch. More details on how to execute rapidwiz can be found on the Oracle Applications 11i Installation Manual.

Attention: Review the log files (setup_stubs.<timestamp>.log) under the iAS ORACLE_HOME to ensure that there are no errors.

6. Run AutoConfig setup phase on the Target System

Execute the INSTE8_SETUP phase of AutoConfig with the new context file. This will create the environment files required for the AutoPatch session:

cd <AD_TOP>/bin
./adconfig.sh run=INSTE8_SETUP contextfile=<Target System ctxfile>

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

Warning: If autoconfig unsuccessful because it doesn’t found ORACLE_HOME (it will go to /tmp), you should execute next step (Install the Middle Tier Technology Stack), then back to this step. Use <the New Install Source System contextfile>

7. Update 3rd party extensions

If your Applications System is implementing any products which use Ilog, Roguewave, or Quantum, you will need to update the Target System with the objects for the 3rd party extensions and relink any dependent products.

Software  Details:

ILOG                 Apply patch 2837811 and relink dependent executables.

ROGUEWAVE   Apply patch 3006092 and relink dependent executables.

QUANTUM        Follow instructions in document 224273.1 on OracleMetaLink

After Apply, relink product module : MSO WIP WPS MSR

- MSO: MSONEW

- WIP: WICDOL WICMEX WICMLX

- WPS: WPCWFS

- MSR: MSRNEW (if using Release 11.5.4 or later)

8. Download and apply the customer-specific update with AutoPatch

Within 30 minutes from the time you uploaded the manifest file at step 1.b you will receive a notification email saying that your customer specific update patch is ready.

Follow the instructions in the email to download it from Oracle MetaLink. The patch should be applied on all Target System application nodes. Source the APPL_TOP environment file and follow the instructions in the README to apply the patch. AutoPatch will automatically relink the executables.

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

adpatch options=noprereq

9. Review the technology stack patch level

Identify any patches previously applied to your Source System technology stack which are not included in the “Release Versions” section of ” Installing Oracle9i Application Server 1.0.2.2.2 with Oracle Applications 11i”    (document 146468.1). Apply these patches to your Target System technology stack.

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

Attention: You need to Re-Apply Patch for JINIT, FORM, TXK and ADX since there are specific patch for specific platform. After apply manifest, adadmin will use the latest version of AD minipack.

10. Download and apply the techstack interop patch

Apply patch 4139957 to the Target Oracle Applications file system.

11. Regenerate the file system objects

Source the APPL_TOP environment file and perform the following tasks to regenerate the platform dependent files on the Target System:

If migrating the Forms node, run the following script:

$AD_TOP/patch/115/bin/adgensgn.sh <Apps User>/<Apps Password>

Run adadmin to generate messages, forms, reports, graphics and jar files.

Clean unused node

SQL> EXEC FND_CONC_CLONE.SETUP_CLEAN;
SQL> COMMIT;
SQL> EXIT;

12. Run AutoConfig to complete the Target System configuration

$AD_TOP/bin/adconfig.sh contextfile=<Target System context file>

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

13. Finishing Task

  • Review and update your Target System application tier settings and customizations. Recompile any custom code (forms, C) in the Target System APPL_TOP.
  • If you were using UTF8 charset, Discoverer 4i, SSO or Portal 3i on the Source System, refer to the c corresponding setup documentation to complete the migration:

UTF8   “Installing Oracle Applications 11i” Manual, Chapter 5, “Set Up UTF8 Character Set”.

Discoverer 4i    Document 139516.1 on OracleMetaLink.

SSO or Portal 3i    Document 146469.1 on OracleMetaLink.

  • Update printer settings

If the newly migrated System needs to utilize different printers, update the Target System with the new printer settings now.

  • Update Workflow configuration settings

Migrating an Oracle Applications instance will not update the host and instance specific information used by Oracle Workflow. Review the following tables and columns to verify there is no instance-specific data in the Workflow configuration on the Target System.

Table Name Column Name Column Value Details
WF_NOTIFICATION_ATTRIBUTES TEXT_VALUE Value starts with http://<old web host> : Update to new web host
WF_ITEM_ATTRIBUTE_VALUES TEXT_VALUE Value starts with “http://<old web host> : Update to new web host
WF_SYSTEMS GUID Create a new System defined as the new global database name using the Workflow Administrator Web Applications responsibility.
WF_SYSTEMS NAME Value needs to be replaced with the database global name
WF_AGENTS ADDRESS Update database link with the new database global name.
FND_FORM_FUNCTIONS WEB_HOST_NAME Update with the new web host name
FND_FORM_FUNCTIONS WEB_AGENT_NAME Update to point at the new PLSQL listener name
FND_CONCURRENT_REQUESTS LOGFILE_NAME Update with the correct path to the logfile directory
FND_CONCURRENT_REQUESTS OUTFILE_NAME Update with the new directory path on the Target System
  • Review your CLASSPATH setting

Log in to the Target APPL_TOP environment (source the environment file) and perform the following tasks to consolidate your CLASSPATH:

Verify the AD classpath:

$ADJVAPRG -version

If the result shows a java version of 1.3.1 or higher, use Context Editor to update the variable s_adovar_classpath in the context file: replace appsborg.zip by appsborg2.zip in the classpath string.

Verify the AF classpath:

$AFJVAPRG -version

If the result shows a java version of 1.3.1 or higher, use Context Editor to update the variable s_adovar_afclasspath in the context file: replace appsborg.zip by appsborg2.zip in the classpath string.

  • Run AutoConfig as described in document 165195.1 on OracleMetalink.
  • Start all services on the Target System

Start all services by running the script:

adstrtal.sh <AppsUser>/<AppsPwd>

located in <COMMON_TOP>/admin/scripts/<ContextName>/

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

   
© 2012 LevICORP's webnote Suffusion theme by Sayontan Sinha