The Migration happens in 2 phases (any order can be followed)
1. Moving the source database to the target operating system
2. Moving the source application tier to the target operating system
Lets now discuss the first step in detail
1. Porting data for an Apps environment using expdp/impdp
The process consists of five discrete steps
1: Prepare the source system
Tasks that must be performed to prepare the source system for the database export
2: Prepare a target Applications Release 11i database instance
Tasks for creating an empty database instance in preparation for import
3: Export the source Applications Release 11i database instance
Tasks that must be performed to produce a valid export of an Applications Release 11i database instance
4: Import the Applications Release 11i database instance
Tasks for running the import utility
5: Update the imported Applications Release 11i database instance
Tasks that must be performed to restore the imported Applications Release 11i database instance to a fully functional state
Note: The source (export from) and target (import to) ORACLE_HOME directories must be Oracle Database 10g Release 2 (10.2.0). Environments using Oracle8i Enterprise Edition Release 8.1.7, Oracle9i Enterprise Edition Release 2 (9.2.0), or Oracle Database 10g Release 1 (10.1.0) have to be upgraded to Oracle Database 10g Release 2 (10.2.0) before you begin the export/import process.
Section 1: Prepare the source system
This section describes how to ensure that you have the required patches, create your export file, and capture important information that is required to import your database.
· Verify that you have at least 1.5 GB of free SYSTEM tablespace.
· Apply the Applications consolidated export/import utility patch Apply patch 4872830 to the source administration server node. This patch provides several SQL scripts that facilitate exporting and importing an Applications database instance. The patch includes a template for the export and import parameter files and a perl script, which creates an AD patch driver.
· Apply latest Applications database preparation scripts patch Apply patch 5000152 to every application tier server node in the source system (superseded by 5873146)
Generate target database instance creation script adcrdb.sql
The target database instance must be created with the same tablespace and file structure as the source database instance.
Patch 4872830 provides the adclondb.sql script which generates the following scripts:
adcrdb.sql, which you use to create the target database instance with the appropriate tablespace and file structure
adpostcrdb.sql, which you use to convert tablespaces to locally managed.
The adpostcrdb.sql script converts all tablespaces except for SYSTEM to locally managed tablespaces, if they are not already so.
On the source administration server node, use SQL*Plus to connect to the database as SYSTEM and run the
$AD_TOP/patch/115/sql/adclondb.sql script. It creates adcrdb.sql in the current directory. $ sqlplus system/
Record Advanced Queue settings Advanced Queue settings are not propagated in the target database instance during the export/import process. Therefore, you must record them beforehand and enable them in the target database instance afterwards.
Patch 4872830 contains auque1.sql, which generates a script called auque2.sql.
You can use auque2.sql to enable the settings in the target database instance.
Copy the auque1.sql script from the $AU_TOP/patch/115/sql directory on the source administration server node to the source database server node. It does not matter which directory you use. Then, on the source database server node, as the owner of the source database server file system and database instance, use SQL*Plus to connect to the source database as sysdba and run the auque1.sql script.
It generates auque2.sql in the current directory.
$ sqlplus /nologSQL> connect / as sysdba;SQL> @auque1.sql
Section 2: Prepare a target Applications Release 11i database instance
This section describes how to create the empty target database and populate it with all of the required system objects prior to running import.
The Oracle home of the target database instance is on a different machine running a different operating system, for example), but it should use Oracle Database 10g Release 2 Enterprise Edition
· Install the Oracle Software 10.2.0.2
· Create the target initialization parameter file and CBO parameter file The initialization parameter file (init
Copy both files to the Oracle 10g $ORACLE_HOME/dbs directory on the target database server node.Refer to Database Initialization Parameters (init.ora settings) in Oracle Applications Release 11i and update both the init.ora and ifilecbo.ora files with any necessary changes. You may also need to update initialization parameters involving the db_name, control_files, and directory structures.
Comment out the parameters undo_tablespace and undo_management in the initialization parameter file of the target database instance. Add these parameters after the adcrdb.sql script has been run. Ignore the initialization parameters that pertain to the native compilation of PL/SQL code.
Create the target database instance Copy the adcrdb.sql script, generated in Section 1, from the source administration server node to the target database server node. Then update the script on the target database server node with any necessary changes to the directory structures for the log file(s), data file(s), or tablespaces, reflecting the layout of the target database server node.
If the target database server node is running Windows, update the directory structure from UNIX/Linux format to Windows format.
Make sure that the environment of your session on the target database server node is set up properly for the target database instance, especially the ORACLE_HOME, ORACLE_SID, and ORA_NLS10 environment settings. (ORACLE_SID must be set to the same value as the db_name parameter in the init
Then, use the following commands to run adcrdb.sql and create the target database instance:
$ sqlplus /nologSQL> connect / as sysdba;
SQL> spool adcrdb.log;
For UNIX or Linux:
SQL> startup nomount;
SQL> @adcrdb.sql
SQL> exit;
Add the parameters undo_tablespace and undo_management to the initialization parameter file
If PL/SQL of the source database was natively compiled, see the "Compiling PL/SQL Code for Native Execution" section of Chapter 11 of Oracle Database PL/SQL User's Guide and Reference 10g Release 2 (10.2) for instructions on how to natively compile PL/SQL in the target database. Add the parameters that pertain to the native compilation where specified. Do not use the natively compiled code generated by the source database. Oracle does not support switching the PL/SQL compilation mode from interpreted to native (and vice-versa) for an export/import. Exporting/importing using native mode takes significantly more time than interpreted mode.
When the target database instance has been created, restart the database instance.
Copy database preparation scripts to target Oracle home The database preparation scripts that you applied to the source administration server node in Section 1 contain four scripts that are needed on the target database server node.
Copy the following files from the $APPL_TOP/admin directory of the source administration server node to the Oracle 10g $ORACLE_HOME/appsutil/admin directory of the target database server node: addb1020.sql, adsy1020.sql, adjv1020.sql, and admsc1020.sql (UNIX or Linux) or addb1020_nt.sql, adsy1020_nt.sql, adjv1020_nt.sql, and admsc1020_nt.sql (Windows).
As you run each of the next four steps, note the following:
The remarks section at the beginning of each script contains additional information.
Each script creates a log file in the current directory
Set up the SYS schema
The addb1020.sql or addb1020_nt.sql script sets up the SYS schema for use with the Applications.
On the target database server node, use SQL*Plus to connect to the target database instance as SYSDBA and run $ORACLE_HOME/appsutil/admin/addb1020.sql (UNIX/Linux) or addb1020_nt.sql (Windows).
Here is an example on UNIX or Linux:
$ sqlplus "/ as sysdba" @$ORACLE_HOME/appsutil/admin/addb1020.sql
Set up the SYSTEM schema
The adsy1020.sql or adsy1020_nt.sql script sets up the SYSTEM schema for use with the Applications. On the target database server node, use SQL*Plus to connect to the target database instance as SYSTEM and run $ORACLE_HOME/appsutil/admin/adsy1020.sql (UNIX/Linux) or adsy1020_nt.sql (Windows).
Here is an example on UNIX or Linux:
$ sqlplus system/
Install Java Virtual Machine
The adjv1020.sql or adjv1020_nt.sql script installs the Java Virtual Machine (JVM) in the database.
On the target database server node, use SQL*Plus to connect to the target database instance as SYSTEM and run $ORACLE_HOME/appsutil/admin/adjv1020.sql (UNIX/Linux) or adjv1020_nt.sql (Windows).
Here is an example on UNIX or Linux:
$ sqlplus system/
Note: This script can be run only once in a given database instance, because the scripts that it calls are not rerunnable.
Install other required components
The admsc1020.sql or admsc1020_nt.sql script installs the following required components in the database: ORD, Spatial, XDB, OLAP, Data Mining, interMedia, and ConText.
On the target database server node, use SQL*Plus to connect to the target database instance as SYSTEM and run $ORACLE_HOME/appsutil/admin/admsc1020.sql (UNIX/Linux) or admsc1020_nt.sql (Windows).
You must pass the following arguments to the script, in the order specified:
Argument
Value
remove context?
FALSE
SYSAUX tablespace
SYSAUX
temporary tablespace
TEMP
Here is an example on UNIX or Linux: ·
$ sqlplus system/
Note: All of the components are created in the SYSAUX tablespace regardless of where it was installed in the source database.
· Runs adpostcrdb.sql script Copy the adpostcrdb.sql script, generated in Section 1, from the source administration server node to the target database server node. On the target database server node, use SQL*Plus to connect to the database instance as SYSTEM and run the following command.
$ sqlplus system/
· Disable automatic gathering of statistics Copy $APPL_TOP/admin/adstats.sql from the administration server node to the target database server node. Use SQL*Plus to connect to the database as SYSDBA and use the following commands to restart the database in restricted mode and run adstats.sql:
$ sqlplus "/ as sysdba"
SQL> shutdown normal;
SQL> startup restrict;
SQL> @adstats.sql
SQL> exit;
· Back up the target database instance
The target database instance is now prepared for an import of the Applications data.
You should perform a backup before starting the import.
Section 3: Export the source Applications Release 11i database instance
This section describes how to ensure that you have the required patches, create your export file, and capture important information that is required to import your database.
· Create the export parameter file A template for the export parameter file has been included as part of the export/import patch 4872830. Copy $AU_TOP/patch/115/import/auexpdp.dat from the source administration server node to the directory on the database server node where the export dump files are to be created.
Use a text editor to modify the file to reflect the source environment and other customized parameters.
The customizable parameters are:
Parameter
Description
Template Value
directory
directory where the export dump files will be created
dmpdir
dumpfile
export dump file name(s)
aexp%U.dmp
filesize
export dump file size
1GB
log
log file name
expdpapps.log
Note : InterMedia, OLAP, and Data Mining schemas are not exported.
The admsc1020.sql script creates these schemas in the target database.
Ensure that the schema names in the exclude parameters reflect those in your database.
For Windows platforms, add the following line to the parameter file: exclude=table_statistics
Create a directory in the system schema that corresponds to the directory specified in the template.
Here is an example of how to create a directory named dmpdir:
$ sqlplus system/
SQL> create directory dmpdir as '/u01/expimp';
Comment out or remove the transform parameter. It is used only for the import process. Do not change the other parameters.
The export process uses as many of the listed file names as necessary to hold the exported data. You must ensure that the number of dump files specified, as well as the size of each dump file, is sufficient to contain all the data in your source database instance.
· Shut down Applications server processes
Shut down all Applications server processes except the database and the Net8 listener for the database. Users cannot use the Applications until the import is completed.
· Export the Applications database instance
Start an export session on the source database server node using the customized export parameter file.
Use the following command:
$ expdp system/
Typically, the export runs for several hours.
Section 4: Import the Applications Release 11i database instance
This section describes how to use the import utility to load the Oracle Applications data into the target database.
1. Create the import parameter file
Copy the export parameter file you created in Section 1 from the source database server node to the target database server node, renaming it if necessary.
Updating the new file with the following changes converts it to an import parameter file:
o Remove the exclude parameters.
o Remove the filesize parameter.
o Change the name of the log file.
o Uncomment the transform parameter.
Create a directory in the system schema with the name set to the directory specified in the template and the path set to where the export dump files will reside. Here is an example of how to create a directory named dmpdir:
$ sqlplus system/
SQL> create directory dmpdir as '/u01/expimp';
Save the changed file.
· Copy the export dump files
Copy the export dump files from the source database server node to the target database server node.
Import the Applications database instance Start the import session on the target database server node using the customized import parameter file. Use the following command:
$ impdp system/
Typically, import runs for several hours. Once the import is complete, you can delete the export dump files, as well as the export and import parameter files, from the source and target database server nodes
Section 5: Update the imported Applications Release 11i database instance
This section describes how to recreate the database objects and relationships that are not handled by the export and import utilities.
Reset Advanced Queues
Copy the auque2.sql script that was generated in Section 1 from the $ORACLE_HOME/appsutil/admin directory of the source database server node to the same directory on the target database server node.
Then, on the target database server node, as the owner of the Oracle 10g file system and database instance, use SQL*Plus to connect to the target database as SYSDBA and run the $ORACLE_HOME/appsutil/admin/auque2.sql script to enable the Advanced Queue settings that were lost during the export/import process.
The script creates a log file in the current directory.
$ sqlplus /nolog
SQL> connect / as sysdba;
SQL> @$ORACLE_HOME/appsutil/admin/auque2.sql
· Perform post-import steps outlined in the Interoperability documents
Complete the steps in the "After the Database Upgrade" subsection of Section 1 of the Oracle Applications Release 11i with Oracle Database 10g Release 2 (10.2.0) Interoperability Notes. Do not run the Korean lexer fix, import the OLAP analytical workspaces, re-create grants and synonyms, and restart the Applications server processes.
· Create OWA_MATCH package (conditional) (Not Applicable)
If you are using iAS 1.0.2, perform the steps in document 312165.1 to create SYS.OWA_MATCH on the target database.
· Compile invalid objects
On the target database server node, as the owner of the Oracle 10g file system and database instance, use SQL*Plus to connect to the target database as SYS and run the $ORACLE_HOME/rdbms/admin/utlrp.sql script to compile invalid objects. ·
$ sqlplus sys/
First, complete the applications porting so that DB can be made Autoconfig enabled.
Enable autoconfig on the target system database
Section 7: Migrating to AutoConfig on the Database Tier
Complete the steps in this section (in the order listed) to migrate to AutoConfig on the Database Tier. If you have already migrated to AutoConfig on the Database Tier omit this section.
1. Copy AutoConfig to the RDBMS ORACLE_HOME Update the RDBMS ORACLE_HOME file system with the AutoConfig files by performing the following steps:
o On the Application Tier (as the APPLMGR user):
1 Log in to the APPL_TOP environment (source the environment file)
2 Create appsutil.zip file perl
3 This will create appsutil.zip in $APPL_TOP/admin/out .
o On the Database Tier (as the ORACLE user):
$ Copy or FTP the appsutil.zip file to the
$ cd
2. Generate your Database Context FileIf your Applications system was created with the Release 11.5.9 Rapid Install or later, go to Task 3 in this section.
If your Applications system was created with the Release 11.5.8 Rapid Install or earlier, execute the following commands to create your Database Context File:
o On UNIX
$ cd
$ .
$ cd
$ perl adbldxml.pl tier=db appsuser=
Prepare for AutoConfig Complete the following AutoConfig steps.
Review Prior Manual Configuration Changes
The Database Context File may not include manual post-install configuration changes made after the Rapid Install completed. Before running the AutoConfig portion of this patch, review any modifications to specific configuration files and reconcile them with the Database Context file
1. The AutoConfig check utility is located at:
Tier Command Application
Database
2. Check the AutoConfig configuration files by executing the following command:
o On UNIX
adchkcfg.sh contextfile=
1. Generate and Apply AutoConfig Configuration files
Attention: This step performs the conversion to AutoConfig. Once completed, the previous configuration will not be available.
2. Attention: The database server and the database listener must remain available during the AutoConfig run. All the other database tier services should be shut down.
3. Execute the following commands:
On UNIX
$ cd
$ adconfig.sh contextfile=
Noe the database is autoconfig enabled.
· Create ConText and Spatial objects ( to be followed after db is Auto config enabled)
Certain ConText and Spatial objects are not preserved by the import process. The consolidated export/import utility patch 4872830 that you applied to the source administration server node in Section 1 contains a perl script, dpost_imp.pl, that you can run to generate an AutoPatch driver file. You use this driver file to call the scripts that create these objects.
Run the following command: ·
$ perl $AU_TOP/patch/115/driver/dpost_imp.pl
Once the driver file has been generated, use AutoPatch to apply it on the target administration server node.
· Maintain Applications database objects
Run AD Administration on the target administration server node.
From the Maintain Applications Database Objects menu, perform the following tasks:
o Compile flexfield data in AOL tables
o Recreate grants and synonyms for APPS schema
If you use Multiple Reporting Currencies:
o Maintain Multiple Reporting Currencies schemaEnter Yes for the following options:
§ Update MRC schema itself
§ Compile invalid objects after updating MRC schema objects
§ Recreate MRC triggers in the APPS schema
· Start Applications server processes
Start all the server processes on the target Applications system. You can allow users to access the system at this time.
· Create DQM indexes Create DQM indexes by following these steps:
o Log on to Oracle Applications with the "Trading Community Manager" responsibility
o Click Control > Request > Run
o Select "Single Request" option
o Enter "DQM Staging Program" name
o Enter the following parameters:
§ Number of Parallel Staging Workers: 4
§ Staging Command: CREATE_INDEXES
§ Continue Previous Execution: NO
§ Index Creation: SERIAL
o Click "Submit"
· Gather Applications statistics
If you encountered failures importing statistics or if your platform is Windows, gather the statistics by following these steps:
o Ensure that there are no concurrent programs running.
o Log on to Oracle Applications with the "System Administrator" responsibility.
o Click Navigation List > Request > Run.
o Enter appropriate parameters. Specify "ALL" in the schema name to gather statistics for all database objects. You may choose individual schemas to make the process run faster.
o Click "Submit".
Now the database should be on the target operating system.
In the next post I will write how to convert the source application tier to the target application tier.
No comments:
Post a Comment