R12 Database Migration From Solaris to Linux using export/import


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.
  1. Apply prerequisite patches
    Ensure that you have applied steps 1 and 2 in Section 1 of the Oracle E-Business Suite Release 12 with Oracle Database 11g Release 1 (11.1.0) Interoperability Notes if you are importing an E-Business Suite Release 12.0 into 11.1.0, Oracle E-Business Suite Release 12.1 with Oracle Database 11g Release 1 (11.1.0) Interoperability Notes if you are importing an E-Business Suite Release 12.1 into 11.1.0, or Oracle E-Business Suite Release 12 with Oracle Database 11g Release 2 (11.2.0) Interoperability Notes if you are importing an E-Business Suite Release 12.x into 11.2.
    When performing the AutoConfig prerequisite instructions, ensure that steps 3.1 and 3.2.1 of the Using AutoConfig to Manage System Configurations in Oracle E-Business Suite Release 12 document are completed. The other steps in 3.2 are not necessary as they will be done at the target side.
  2. Apply the Applications consolidated export/import utility patch
    Apply patch 13023290 to the source administration server node. This patch provides several SQL scripts that facilitate exporting and importing an Applications database instance.
  3. Create a working directory
    Create a working directory named expimp in the source system that will contain all generated files and scripts required to complete this section. As an example,
    $ mkdir /u01/expimp
  4. Generate target database instance creation script aucrdb.sql
    The target database instance must be created with the same tablespace structure as the source database instance. The export/import patch provides the auclondb.sql script which generates the aucrdb.sql script, which you use to create the target database instance with the appropriate tablespace and file structure. The script converts all tablespaces except for SYSTEM to locally managed tablespaces with auto segment space management, 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 $AU_TOP/patch/115/sql/auclondb.sql script. It creates aucrdb.sql in the current directory.
    $ sqlplus system/[system password] \
        @$AU_TOP/patch/115/sql/auclondb.sql 11
  5. 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. The export/import patch 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 working directory in the source database server node. 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.
    $ sqlplus /nolog
    SQL> connect / as sysdba;
    SQL> @auque1.sql
  6. Create parameter file for tables with long columns (conditional)
    If the source database is Oracle Database 10g Release 2, tables with long columns may not propagate properly in datapump. Therefore, they have to be migrated separately using the traditional export/import utilities.
    Copy the aulong.sql script from the $AU_TOP/patch/115/sql directory on the source administration server node to the working directory in the source database server node. 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 aulong.sql script. It generates aulongexp.dat.
    $ sqlplus /nolog
    SQL> connect system/[system password];
    SQL> @aulong.sql
  7. Remove rebuild index parameter in spatial indexes
    Ensure that you do not have the rebuild index parameter in the spatial indexes. To see if you have any rebuild index parameters, 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 following command:
    SQL> select * from dba_indexes where index_type='DOMAIN' and
      upper(parameters) like '%REBUILD%';
    To remove the rebuild index parameter, use SQL*Plus to connect to the source database as the owner of the index and run the following command:
    SQL> alter index [index name] rebuild parameters [parameters]
    where [parameters] is the original parameter set without the rebuild_index parameter.





Section 2: Prepare a target Release 12 database instance

This section describes how to create the empty target database and populate it with all of the required system objects prior to running import.
The Oracle home of the target database instance can be the same Oracle home that the source database instance uses, or it can be different (on another machine running a different operating system, for example), as long as it uses Oracle Database 11g Release 1 Enterprise Edition.
  1. Create target Oracle 11g Oracle home (conditional)
    If you want the target Oracle 11g Oracle home to be separate from the source Oracle home, you must create it now. Perform the steps in the "Database Installation" subsection of Section 1 of the Oracle E-Business Suite Release 12 with Oracle Database 11g Release 1 (11.1.0) Interoperability Notes, Oracle E-Business Suite Release 12.1 with Oracle Database 11g Release 1 (11.1.0) Interoperability Notes, or Oracle E-Business Suite Release 12 with Oracle Database 11g Release 2 (11.2.0) Interoperability Notes.
  2. Modify sqlnet.ora file (Windows only)
    If the target database server node is running Windows, add the following line to the sqlnet.ora file in the %ORACLE_HOME%\network\admin\[SID] directory, if it does not already exist:
    SQLNET.AUTHENTICATION_SERVICES=(NTS)
  3. Create the target initialization parameter file and CBO parameter file
    The initialization parameter file (init[SID].ora) and cost-based optimizer (CBO) parameter file (ifilecbo.ora) are located in the $ORACLE_HOME/dbs directory on the source database server node. Copy both files to the Oracle 11g $ORACLE_HOME/dbs directory on the target database server node.
    Refer to Database Initialization Parameters for Oracle Applications Release 12 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.
    Ensure that the undo_tablespace parameter in the initialization parameter file of the target database instance matches with the default undo tablespace set in the aucrdb.sql script.
    Ignore the initialization parameters that pertain to the native compilation of PL/SQL code. You will be instructed to add them later, if necessary.
  4. Create a working directory
    Create a working directory named expimp in the target system that will contain all generated files and scripts required to complete this section. As an example,
    $ mkdir /u01/expimp
  5. Create the target database instance
    Copy the aucrdb.sql script, generated in Section 1, from the source administration server node to the working directory in 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. You may enlarge the file sizes to ensure that tablespaces do not run out. If the target database server node is running Windows, update the directory structure from UNIX/Linux format to Windows format or vice versa.
    Make sure that the environment of your session on the target database server node is set up properly for the target database instance, especially the ORACLE_HOME, ORACLE_SID, and ORA_NLS10 environment settings. (ORACLE_SID must be set to the same value as the db_name parameter in the init[SID].ora file.) Then, use the following commands to run aucrdb.sql and create the target database instance:
    $ sqlplus /nolog
    SQL> connect / as sysdba;
    SQL> spool aucrdb.log;
    For UNIX or Linux:
    SQL> startup nomount; 
    SQL> @aucrdb.sql
    SQL> exit;
    For Windows:
    SQL> startup nomount pfile=%ORACLE_HOME%\dbs\init%ORACLE_SID%.ora
    SQL> @aucrdb.sql
    SQL> exit;
    If PL/SQL of the source database was natively compiled, see the "Compiling PL/SQL Code for Native Execution" section of Chapter 12 of Oracle Database PL/SQL Language Reference 11g Release 1 (11.1) or Oracle Database PL/SQL Language Reference 11g Release 2 (11.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.
    Note: You may modify the sizes of the database files in aucrdb.sql to ensure enough tablespace. Querying the dba_free_space and dba_data_files tables in the source database can give you an idea of how much tablespace is required. However, this is no guarantee as the space requirements may change depending on the extent sizes used by each object. Not having enough tablespace will cause failures as well as a major performance degradation in the import run.
  6. Copy database preparation scripts to target Oracle home
    The export/import patch 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 $AU_TOP/patch/115/sql directory of the source administration server node to the working directory in the target database server node: audb1110.sql/audb1120.sql, ausy1110.sql/ausy1120.sql, aujv1110.sql/aujv1120.sql, and aumsc1110.sql/aumsc1120.sql (UNIX or Linux) or audb1110_nt.sql/audb1120_nt.sql, ausy1110_nt.sql/ausy1120_nt.sql, aujv1110_nt.sql/aujv1120_nt.sql, and aumsc1110_nt.sql/aumsc1120_nt.sql (Windows).
    As you run each of the next four steps, note the following:
    1. The remarks section at the beginning of each script contains additional information.
    2. Each script creates a log file in the current directory.
  7. Set up the SYS schema
    The audb1110.sql, audb1120.sql, audb1110_nt.sql, or audb1120_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 audb1110.sql/audb1120.sql (UNIX/Linux) or audb1110_nt.sql/audb1120_nt.sql (Windows).
    Here is an example on UNIX or Linux for 11.2.0:
    $ sqlplus "/ as sysdba" @audb1120.sql
  8. Set up the SYSTEM schema
    The ausy1110.sql, ausy1120.sql, ausy1110_nt.sql, or ausy1120_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 ausy1110.sql/ausy1120.sql (UNIX/Linux) or ausy1110_nt.sql/ausy1120_nt.sql (Windows).
    Here is an example on UNIX or Linux for 11.2.0:
    $ sqlplus system/[system password] @ausy1120.sql
  9. Install Java Virtual Machine
    The aujv1110.sql, aujv1120.sql, aujv1110_nt.sql, or aujv1120_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 aujv1110.sql/aujv1120.sql (UNIX/Linux) or aujv1110_nt.sql/aujv1120_nt.sql (Windows).
    Here is an example on UNIX or Linux for 11.2.0:
    $ sqlplus system/[system password] @aujv1120.sql
    Attention: This script can be run only once in a given database instance, because the scripts that it calls are not rerunnable.
  10. Install other required components
    The aumsc1110.sql, aumsc1120.sql, aumsc1110_nt.sql, or aumsc1120_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 aumsc1110.sql/aumsc1120.sql (UNIX/Linux) or aumsc1110_nt.sql/aumsc1120_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 for 11.2.0:
    $ sqlplus system/[system password] \
        @aumsc1120.sql FALSE SYSAUX TEMP 
    Attention: All of the components are created in the SYSAUX tablespace regardless of where it was installed in the source database.
  11. Set CTXSYS parameter (conditional)
    If your target database is 11g Release 2 (11.2.0), use SQL*Plus to connect to the database as SYSDBA and run the following command:
    $ sqlplus "/ as sysdba"
    SQL> exec ctxsys.ctx_adm.set_parameter('file_access_role', 'public');
  12. 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> alter system enable restricted session;
    SQL> @adstats.sql
    $ sqlplus "/ as sysdba"
    SQL> alter system disable restricted session;
    SQL> exit;
  13. 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 Release 12 database instance

This section describes how to ensure that you have the required patches, create your export file, and capture important information that is required to import your database.
  1. Create the export parameter file
    A template for the export parameter file has been included as part of the the export/import patch. Copy $AU_TOP/patch/115/import/auexpdp.dat from the source administration server node to the working directory in the source database server node. 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
    interMedia, OLAP, and Data Mining schemas are not exported. The aumsc1110.sql script creates these schemas in the target database. Ensure that the schema names in the exclude parameters reflect those in your database.
    If your source database is Oracle Database 11g (11.x), add the following line to the parameter file:
    QUERY=applsys.wf_item_attribute_values:"where item_type!='WFERROR' and
      name != 'EVENT_MESSAGE'"
    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/[system password] 
    SQL> create directory dmpdir as '/u01/expimp';
    Do not change the other parameters.
    The export process uses as many of the listed file names as necessary to hold the exported data. You must ensure that the number of dump files specified, as well as the size of each dump file, is sufficient to contain all the data in your source database instance.
  2. Shut down Applications server processes
    Shut down all Applications server processes except the database and the Net8 listener for the database. Users cannot use the Applications until the import is completed.
  3. Grant privilege to source system schema
    Grant the exempt access policy privilege to system by using SQL*Plus to connect to the database as SYSDBA and run the following command:
    SQL> grant EXEMPT ACCESS POLICY to system;
  4. Export OLAP analytical workspaces (optional)
    The export/import of OLAP analytical workspaces may take up a lot of resources. It may cause memory issues such as bug 10331951. Customers who use OLAP may export/import OLAP through the DBMS_AW package directly as an alternative.
    Perform the detailed steps 1-3 as documented in My Oracle Support Note 352306.1, Upgrading OLAP from 32 to 64 bits, to export OLAP analytical workspaces on the source machine. Copy the export files to the target machine.
  5. Drop XLA packages (optional)
    The export/import of large Sub-ledger Accounting (XLA) packages may take up a long time. The XLA packages can be dropped before the export and re-created after the import to optimize the export/import process.
    On the source database server node, use SQL*Plus to connect to the source database as APPS and run the following to determine the XLA packages:
    $ sqlplus apps/[APPS password]
    SQL> select distinct('drop package '||db.owner||'.'|| db.object_name || ';')
    from dba_objects db, xla_subledgers xl
    where db.object_type='PACKAGE BODY' and db.object_name like 'XLA%AAD%PKG'
    and substr(db.object_name,1,9) = 'XLA_'||
    LPAD(SUBSTR(TO_CHAR(ABS(xl.application_id)), 1, 5), 5, '0')
    and db.object_name NOT IN ('XLA_AAD_HDR_ACCT_ATTRS_F_PKG','XLA_AMB_AAD_PKG')
    order by 1;
    Copy the output to SQL*Plus to drop the packages.
  6. Export the Applications database instance
    Start an export session on the source database server node using the customized export parameter file.
    If the source database is 10.2.0 or 11.1.0, use the following command:
    $ expdp system/[system password] parfile=[export parameter file name]
    If the source database is 11.2.0, use the following command:
    $ expdp "'/ as sysdba'" parfile=[export parameter file name]
    Typically, the export runs for several hours.
  7. Export tables with long columns (conditional)
    If the source database is Oracle Database 10g Release 2 (10.2.0), start an export session on the source database server node using the customized aulongexp.dat file generated in Section 1. Use the following command:
    $ exp parfile=aulongexp.dat
  8. Export tables with XML type columns (conditional)
    If the source database is Oracle Database 10g Release 2 (10.2.0), copy $AU_TOP/patch/115/import/auxmlexp.dat from the source administration server to the working directory in the source database server node. Start an export session on the source database server node using the following command:
    $ exp parfile=auxmlexp.dat
  9. Revoke privilege from source system schema
    Revoke the exempt access policy privilege from system by using SQL*Plus to connect to the database as SYSDBA and run the following command:
    SQL> revoke EXEMPT ACCESS POLICY from system;

Section 4: Import the Release 12 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 files
    Copy auimpdp.dat, aufullimp.dat, and auimpusr.dat from the $AU_TOP/patch/115/import directory in the source administration server node to the working directory in the target database server node. Make sure that the directory, dumpfile, and logfile parameters in auimpdp.dat and auimpusr.dat are set properly.
    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/[system password] 
    SQL> create directory dmpdir as '/u01/expimp';
    Save the changed file.
  2. Copy the export dump files
    Copy the export dump files from the source database server node to the working directory in the target database server node.
  3. Import the users into the target database (conditional)
    If the source database is Oracle Database 10g Release 2 (10.2.0), start an import session on the target database server node using the customized import parameter file. Use the following command:
    $ impdp system/[system password] parfile=auimpusr.dat
  4. Import tables with long columns into the target database (conditional)
    If the source database is Oracle Database 10g Release 2 (10.2.0), modify the aufullimp.dat file with the following:
    1. Set userid to "sys/[sys password] as sysdba".
    2. Set file to the dump file containing the long tables (longexp by default).
    3. Set the log file appropriately.
    4. Leave the ignore parameter commented out.
    Import the tables using the following command:
    $ imp parfile=aufullimp.dat
    Attention: You will get failures for the triggers as the dependent tables have not yet been imported.
  5. Import the Applications database instance
    If your source database is Oracle Database 11g (11.x), remove or comment out all the exclude parameters in the auimpdp.dat parameter file. If your source database is Oracle Database 10g Release 2 (10.2.0), leave the parameter file as is. Start an import session on the target database server node using the auimpdp.dat parameter file.
    If the target database is 11.1.0, use the following command:
    $ impdp system/[system password] parfile=auimpdp.dat
    If the target database is 11.2.0, use the following command:
    $ impdp "'/ as sysdba'" parfile=auimpdp.dat
    Typically, import runs for several hours.
  6. Import triggers into the target database (conditional)
    If the source database is Oracle Database 10g Release 2 (10.2.0), modify the aufullimp.dat file with the following:
    1. Set userid to "sys/[sys password] as sysdba".
    2. Set file to the dump file containing the long tables (longexp by default).
    3. Change the log file name.
    4. Uncomment the ignore parameter.
    5. Add a line with the parameter "rows=n".
    Start an import session on the target database server node using the customized import parameter file. Use the following command:
    $ imp parfile=aufullimp.dat
  7. Import OLAP analytical workspaces (conditional)
    If you exported OLAP analytical workspaces, perform the detailed step 7 as documented in My Oracle Support Note 352306.1 to import the OLAP analytical workspaces that were previously exported from the source machine.
  8. Revoke privilege from target system schema
    Revoke the exempt access policy privilege from system by using SQL*Plus to connect to the database as SYSDBA and run the following command:
    SQL> revoke EXEMPT ACCESS POLICY from system;

Section 5: Update the imported Release 12 database instance

This section describes how to recreate the database objects and relationships that are not handled by the export and import utilities.
  1. Reset Advanced Queues
    Copy the auque2.sql script that was generated in Section 1 from the working directory in the source database server node to the working directory in the target database server node. Then, on the target database server node, as the owner of the Oracle 11g file system and database instance, use SQL*Plus to connect to the target database as SYSDBA and run the 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> @auque2.sql
  2. Start the new database listener (conditional)
    If the Oracle Net listener for the database instance in the new Oracle home has not been started, you must start it now. Since AutoConfig has not yet been implemented, start the listener with the lsnrctl executable (UNIX/Linux) or Services (Windows). See the Oracle Database Net Services Administrator's Guide, 11g Release 1 (11.1) or Oracle Database Net Services Administrator's Guide, 11g Release 2 (11.2) for more information.
    Attention: Set the TNS_ADMIN environment variable to the directory where you created your listener.ora and tnsnames.ora files.
  3. Run adgrants.sql
    Copy $APPL_TOP/admin/adgrants.sql (adgrants_nt.sql for Windows) from the administration server node to the working directory in the database server node. Use SQL*Plus to connect to the database as SYSDBA and run the script using the following command:
    $ sqlplus "/ as sysdba" @adgrants.sql (or adgrants_nt.sql) \
        [APPS schema name]
    Note: Verify the usage of adgrants.sql in the adgrants.sql script. Older versions of adgrants.sql require the APPLSYS schema name parameter to be passed instead of APPS.
  4. Grant create procedure privilege on CTXSYS
    Copy $AD_TOP/patch/115/sql/adctxprv.sql from the administration server node to the database server node. Use SQL*Plus to connect to the database as APPS and run the script using the following command:
    $ sqlplus apps/[APPS password] @adctxprv.sql \
        [SYSTEM password] CTXSYS
  5. Apply patch 6494466 (conditional)
    If the target database is Windows and the source is not, apply patch 6494466 on the target database tier. Create the appsutil directory if needed.
  6. Deregister the current database server (conditional)
    If you plan to change the database port, host, SID, or database name parameter on the database server, you must also update AutoConfig on the database tier and deregister the current database server node.
    Use SQL*Plus to connect to the database as APPS and run the following command:
    $ sqlplus apps/[APPS password]
    SQL> exec fnd_conc_clone.setup_clean;
  7. Implement and run AutoConfig
    Implement and run AutoConfig in the new Oracle home on the database server node. If the database listener of the new Oracle home is defined differently than the old Oracle home, you must also run AutoConfig on each application tier server node to update the system with the new listener.
    See Using AutoConfig to Manage System Configurations in Oracle E-Business Suite Release 12 on My Oracle Support, especially section 3.2, for instructions on how to implement and run AutoConfig.
    Shut down all processes, including the database and the listener, and restart them to load the new environment settings.
  8. Gather statistics for SYS schema
    Use SQL*Plus to connect to the database as SYSDBA and use the following commands to restart the database in restricted mode, run adstats.sql, and restart the database in normal mode:
    $ sqlplus "/ as sysdba"
    SQL> alter system enable restricted session;
    SQL> @adstats.sql
    $ sqlplus "/ as sysdba"
    SQL> alter system disable restricted session;
    SQL> exit;
    Attention: Make sure that you have at least 1.5 GB of free default temporary tablespace.
  9. Re-create custom database links (conditional)
    If the Oracle Net listener in the 11g Oracle home is defined differently than the one used by the old Oracle home, you must re-create any custom self-referential database links that exist in the Applications database instance. To check for the existence of database links, use SQL*Plus on the database server node to connect to the Applications database instance as APPS and run the following query:
    $ sqlplus apps/[apps password]
    SQL> select db_link from dba_db_links;
    The EDW_APPS_TO_WH and APPS_TO_APPS database links, if they exist, should have been updated with the new port number by AutoConfig in the previous step.
    If you have custom self-referential database links in the database instance, use the following commands to drop and re-create them:
    $ sqlplus apps/[apps password]
    SQL> drop database link [custom database link];
    SQL> create database link [custom database link] connect to
         [user] identified by [password] using
         '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=[hostname])
         (PORT=[port number]))(CONNECT_DATA=(SID=[ORACLE_SID])))';
    where [custom database link], [user], [password], [hostname], [port number], and [ORACLE_SID] reflect the new Oracle Net listener for the database instance.
  10. Create ConText and AZ objects
    Certain ConText objects and the AZ objects dependent on the tables with XML type columns are not preserved by the import process. The consolidated export/import utility patch 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/bin/dpost_imp.pl [driver file]\
      [source database version]
    Set [source database version] to 10 if the source database is 10.2 or to 11 if the source database is 11g.
    Once the driver file has been generated, use AutoPatch to apply it on the target administration server node.
  11. Import tables with XML type columns into the target database (conditional)
    If the source database is Oracle Database 10g Release 2, modify the aufullimp.dat file with the following:
    1. Set userid to "az/[az password]"
    2. Set file to the dump file containing the tables with XML types (xmlexp by default).
    3. Change the log file name.
    4. Comment out the ignore parameter.
    Start an import session on the target database server node using the customized import parameter file. Use the following command:
    $ imp parfile=aufullimp.dat
    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.
  12. Populate CTXSYS.DR$SQE table
    To populate the CTXSYS.DR$SQE table, use SQL*Plus on the database server node to connect to the Applications database instance as APPS and run the following command:
    $ sqlplus apps/[apps password]
    SQL> exec icx_cat_sqe_pvt.sync_sqes_for_all_zones;
  13. Compile invalid objects
    On the target database server node, as the owner of the Oracle 11g file system and database instance, use SQL*Plus to connect to the target database as SYS and run the $ORACLE_HOME/rdbms/admin/utlrp.sql script to compile invalid objects.
    $ sqlplus "/ as sysdba" @$ORACLE_HOME/rdbms/admin/utlrp.sql
  14. Re-create XLA packages (conditional)
    If you dropped the XLA packages in the source environment, copy $XLA_TOP/patch/115/sql/xla6128278.sql from the administration server node to the target working directory, use SQL*Plus to connect to the database as APPS, and run the following script to re-create the XLA packages:
    $ sqlplus apps/[APPS password]
    SQL> @xla6128278.sql [spool log file]
  15. Maintain Applications database objects
    Run AD Administration on the target administration server node. From the Maintain Applications Database Objects menu, perform the following tasks:
    1. Compile flexfield data in AOL tables
    2. Recreate grants and synonyms for APPS schema
  16. 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.
  17. Create DQM indexes
    Create DQM indexes by following these steps:
    1. Log on to Oracle Applications with the "Trading Community Manager" responsibility
    2. Click Control > Request > Run
    3. Select "Single Request" option
    4. Enter "DQM Staging Program" name
    5. Enter the following parameters:
      • Number of Parallel Staging Workers: 4
      • Staging Command: CREATE_INDEXES
      • Continue Previous Execution: NO
      • Index Creation: SERIAL
    6. Click "Submit"




Documents to follow
  1. Export/import process for R12 using 11gR1 or 11gR2 [ID 741818.1]





1 comment :

hamada said...

Hi,

I really didn't understand the first lines of section 2:
"This section describes how to create the empty target database and populate it with all of the required system objects prior to running import.
The Oracle home of the target database instance can be the same Oracle home that the source database instance uses, or it can be different (on another machine running a different operating system, for example), as long as it uses Oracle Database 11g Release 1 Enterprise Edition."

How the Oracle home of the target database instance can be the same Oracle home that the source database instance uses?
The source Oracle Home is on Solaris while the target Oracle Home should be in Linux. Could you please clarify this point?

Regards
Ahmed