Quick Driving for Upgrading Oracle Apps 11.5.10.2 to R12 (12.0.

4)
Preparing System (11.5.10.2) for Upgrade
Step 1 Apply 11i.AD.I patch. The most current version of this minipack is
11i.AD.I.7 and ptach Number is 7429271
select patch_level from fnd_product_installations where patch_level like '%AD
%';
Step 2 Run TUMS Utility
The TUMS report lists tasks that you can omit from the upgrade because they do
not apply to your system (for example, a task required for a product that you do
not use or for applying a patch that you have previously applied). TUMS is
delivered in a patch, which supplies the scripts you need to examine your system
and create the report. We strongly recommend you create and review the TUMS
report before you begin the upgrade.
Patch Number 6727612 and apply it to the administration server node on your
Release 11i APPL_TOP. It supplies you with the script (adtums.sql) you need to
generate the TUMS report (tumsr12.html).
Generate the TUMS report.
UNIX:
$ cd $AD_TOP/patch/115/sql
$ sqlplus <APPS username>/<APPS password> @adtums.sql <DIRECTORY>
For the <DIRECTORY> value, enter the full path of the directory that you want
the report to be written to. This directory must be listed in the UTL_FILE_DIR
parameter of the init.ora file before TUMS can write the report and must have the
appropriate WRITE permissions.
Review the report.
The tumsr12.htm report lists the steps (identified by the TUMS step key in this
book) that do not apply to your installation. You may safely ignore any steps
listed in this report.
Step 3 Back up database, Applications, and customizations (recommended)
Make a cold backup of the Oracle Applications database. You can use it to restore
the database should you encounter problems during the upgrade process.
Step 4 Prepare an upgrade plan for customizations (conditional)
Rename any custom database objects with Applications prefixes that you have
created so that they do not conflict with Oracle object names.
At your discretion, and depending on the customizations in your system, you

should also perform the following tasks:

Preserve the CUSTOM library by making a backup copy of CUSTOM.pll. You can
use this copy later in the upgrade process to migrate your CUSTOM library to
Release 12.0.4.
If you have customized forms with Oracle Forms 6i, upgrade them to Oracle
Forms 10i after the upgrade.
Step 5 Convert to Multiple Organizations architecture (Functional Task)
Multiple Organizations architecture supports performance improvements across
all Oracle Applications. It also supports Multiple Organizations Access Control,
which enables an Applications responsibility to access multiple operating units if
desired. This release requires that Multiple Organizations be enabled. If you have
not done so already, you must convert to this architecture now.
Converting to Multiple Organizations does not require the use of multiple
operating units or sets of books it does enable you to use this functionality at
any time in the future. If you are converting from a Single Organization
architecture to a Multiple Organization architecture, complete the following
steps:
1. Create an operating unit.
2. Assign the operating unit you created to the profile option MO:Operating Unit.
Step 6 Drop event alert triggers in custom schemas (conditional)
To drop all event alert database triggers in custom schemas, run the alrdtrig.sql
script, located in $ALR_TOP/admin/sql (in your Release 11i system). Re-create
the triggers after the upgrade is complete.
Step 7 Review sizes of old and new tablespaces
Make sure you allocate sufficient tablespace. For guidelines based on an upgrade
of the largest Oracle production system (oraprod), see E-Business Suite Release
12 Upgrade Sizing and Best Practices (Doc ID: 399362.1).
Step 8 Run AD preparation scripts
To prepare your system for the Oracle Applications Tablespace Model (OATM)
functionality, you must run some preparation scripts. Download and unzip patch
5726010. Follow the instructions in the readme for running these scripts:
adgncons.sql
The tablespace model for this release (OATM) is based on database object type
rather than product affiliation. The adgncons.sql script prepares adcrtbsp.sql,

configures the database to hold the new products to be added during the upgrade,
and switches your system to use the new tablespace model.
adcrtbsp.sql
Generated by adgncons.sql, this script creates the new tablespaces, allocates
unlimited tablespace to all APPS users, updates fnd_product_installation table
with correct data and index tablespace information, assigns default tablespace to
all APPS users, and sets the new_ts_mode flag in fnd_product_groups to Y.
adgrants.sql (adgrants_nt.sql for Windows)
Grants SYS privileges needed by Applications, and creates required views in SYS.
Step 9 Gather schema statistics for CBO (required)
Step 10 Back up the database (recommended)
Step 11 Disable AOL Audit Trail (conditional)
If you use the Oracle Applications Object Library Audit Trail feature, you must
disable it before the upgrade.
From the System Administrator responsibility under the 11i APPL_TOP, navigate
to Security > Audit Trail > Groups. In the Audit Groups window, set the Group
State field to Disable - Prepare for Archive for each audit group defined. Run the
Audit Trail Update Tables report from the Submit Requests window (Requests >
Run).
If you plan to re-enable auditing after the upgrade, archive and purge the shadow
tables now. Data changes made after implementing this step are not audited.
Step 12 Disable custom triggers, constraints, and indexes (conditional)
Disable custom triggers or constraints on Oracle Applications tables. Re-enable
these triggers after the upgrade. If you have custom indexes on Applications
tables, determine whether they can affect performance during the upgrade, and
drop them if necessary. If you are not sure, it is best to drop the indexes and add
them after the upgrade, if the new release has not created a similar index.
Step 13 Drop MRC schema (conditional)
All programs and reports now use the APPS schema. Because the MRC_APPS
schema is no longer needed, dropping it frees space and reduces processing
overhead during the upgrade. If you have not previously done so, drop the MRC
schema now.

UNIX:
$ cd APPL_TOP/admin
$ sqlplus <SYSTEM username>/<SYSTEM password> @addrpmrc.sql \
<APPLSYS username> FORCE
Windows:
C:\> cd %APPL_TOP%\admin
C:\> sqlplus <SYSTEM username>/<SYSTEM password> @addrpmrc.sql \
<APPLSYS username> FORCE
Step 14 Down the database and Application Service completely.
Install Upgraded R12 file system
Step 1 Run Rapid Install (R12)
Note:
Configuration file written to (for Apps Tier):
/apps/inst/apps/PROD_prod1/conf_PROD.txt
Configuration file written to (for DB Tier):
/apps/db/tech_st/10.2.0/appsutil/conf_PROD.txt
Database log file:
/apps/db/tech_st/10.2.0/appsutil/log/PROD_prod1/xxxxxx.log
Appltop logifle:
/apps/inst/apps/PROD_prod1/logs/xxx.log
CONTEXT FILE:
<INST_TOP>/appl/admin/<CONTEXT_NAME>.xml
We use the Rapid Install wizard to lay down the file system and install the new
technology stack for your Release 12.0.4 Oracle Applications system. The wizard
collects configuration parameters and stores them in a configuration file
(config.txt) in the Applications database. When you run Rapid Install, it uses
these values to lay down the file system structure and technology stack
components for your configuration. As it runs, it creates a context file
(<CONTEXT_NAME>.xml) that contains all the parameters that describe your
system. This context file is created and managed by AutoConfig.
We run Rapid Install again after the upgrade to configure and start the servers
and services. Rapid Install also delivers the unified upgrade driver that you will
use later to perform the upgrade.
Upgrade the Database to Oracle10g Release 2

Step 1 We must use oracle 10g software, which is laid down by R12 Setup
a) Connect to the oracle database form 9i and run pre-upgrade scripts (utlu102i),
which is store in Oracle 10 g Home/rdbms/admin.
b) Follow the steps suggested from output of above steps.
Step 2 Copy init file from 9i default directory to 10G default directory
Step 3 Connect to the new oracle 10g instance as a user sysdba privilege and
issue following command:
SQL>STARTUP UPGRADE
You dont need to use the PFILE option to specify the location of your
initialization parameter file in our case because we are using INIT file in default
location (which is reside in Oracle10gHome/database). We have just put init file
at new oracle 10g home from 9i.
The error may be occur, when you attempting to start the new oracle Database
10g release. If you receive, issue the SHUTDOWN ABORT commands to shut
down the database and correct the problem.
Step 4 Create SYSAUX tablespace
Create SYSAUX table space for the database.
CREATE TABLESPACE sysaux DATAFILE sysaux01.dbf
SIZE 500M REUSE
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO
ONLINE;
Note:
If you are upgrading from 10.1, then skip step4 otherwise create SYSAUX
tablespace. In oracle 10g , the SYSAUX tablespace is used to consolidate data
from a number of tablespace that where separated in previous release.
Step 5 Set the system to spool results to a log file for later verification of success:
SQL> SPOOL upgrade.log
Step 6 Run the upgrade scripts.
SQL>@catupgrd.sql
The catupgrd.sql script determines which scripts need to be run and then runs
each necessary scripts.

Step 7 Run the result of the upgrade display report.

SQL>@utlu102s.sql
The Post-upgrade status Tool display the status of the database components in
the upgrade database and time required to complete each component upgrade.
Step 8 Turn off the spooling of script result to the log file
SQL>spool off;
Step 9 Shutdown the instance and restart.
SQL> STHTDOWN IMMEDIATE
SQL> STARTUP
Step 10 Check Invalid objects in database by using following Query:
SQL> select count(*) from dba_objects where status=INVALID;
Step 11 Run utlrp.sql scripts to recompile any remaining stored Pl/SQL and java
codes.
SQL > @utlro.sql
Step 12 Update init.ora with upgrade parameters (required)
Initialization parameters required at each stage of an upgrade may vary
depending on when you upgrade your database. Set the appropriate parameters
now.
The upgrade requires Oracle10g Release 2 (10.2.0) database. If you have not done
so already, upgrade or migrate your database now. Follow the instructions in
Oracle 10gR2 Database Preparation Guidelines for Oracle E-Business Suite
Release 12 Upgrade (Doc ID: 403339.1).
After the Database Upgrade:
1.
Fix Korean lexers
Use SQL*Plus to connect to the database as SYSDBA, and run drkorean.sql using the
following command:
2.
$ sqlplus "/ as sysdba"
@$ORACLE_HOME/ctx/sample/script/drkorean.sql
1.
Grant create procedure privilege on CTXSYS
Copy $AD_TOP/patch/115/sql/adctxprv.sql from the administration server node to the

database server node. If you are upgrading to R12, use the R12 version of the file. Use
SQL*Plus to connect to the database as APPS and run the script using the following
command:
2.
$ sqlplus apps/[APPS password] @adctxprv.sql \
3.
[SYSTEM password] CTXSYS

Apply Some Patches for R12

Step 1 Apply AD 12.0.4 upgrade driver (required)
Download and unzip the AD Upgrade Driver for 12.0.4 (6604842). Use
AutoPatch to run it on all application tier server notes on your Release 12.0.4
APPL_TOP.
Step 2 Run the American English upgrade patch driver (required)
To bring your database to the full Oracle Applications Release 12.0.4 level, use
AutoPatch to run the (American English) unified driver (u6394500.drv). It is
located in $AU_TOP/patch/115/driver. Run the driver on the administration
server node on your Release 12.0.4 APPL_TOP using the following commands:
$ adpatch options=nocopyportion,nogenerateportion
Step 3 Reset init.ora parameters (required)
Follow the instructions in Database Initialization Parameters for Oracle
Applications Release 12 (Doc ID: 396009.1) and reset the init.ora parameters as
needed.
Step 4 Back up Oracle Applications (recommended)
Have the system administrator back up the Oracle Applications product files. On
a server or stand-alone machine, have the database administrator back up the
Oracle Applications database.
Finish the Upgrade
Step 1 Configure and start server processes (required)
When you ran Rapid Install in the Prepare for the Upgrade, it created and stored
an instance-specific context by replacing system variables you entered on the
wizard screens with the specific values you saved in the configuration file
(config.txt). At this point in the upgrade, you point Rapid Install to the
Applications context file. Rapid Install (using AutoConfig) updates your system
configuration using the values it finds in the context file.

Rapid Install creates the appropriate server process control scripts and starts all
server processes, including the concurrent managers. Any concurrent programs
created during the upgrade run automatically at this point.
We can also execute adautoconfig.sh scripts for configuring and start server
process.
Step 2 Apply patch 6636108 on the application tier. Customers who are on
12.0.x need to apply this patch.
This patch required to CONVERT TO AUTOCONFIG ON AN ORACLE_HOME
NOT INSTALLED WITH RAPID INSTALL
Step 3 Apply patch 4585869 on the application tier. Customers who are on
12.0.x and have not upgraded to 10.1.3.3 AS patchset need to apply this patch.
Step 4 Update the RDBMS ORACLE_HOME file system with AutoConfig files.
On the application tier (as the APPLMGR user), log on to the APPL_TOP
environment (source the environment file) and run this Perl script to create
appsutil.zip in <INST_TOP>/admin/out.
perl <AD_TOP>/bin/admkappsutil.pl
On the database tier (as the ORACLE user), copy or FTP the appsutil.zip file to
the <RDBMS ORACLE_HOME> with this command:
cd <RDBMS ORACLE_HOME>
unzip -o appsutil.zip.
Step 5 Install JRE on the database tier to ensure that the application tier and the
database tier match:
If you are using a fully certified platform, refer to OracleMetalink (Doc ID:
418664.1) to install JRE under the <RDBMS_ORACLE_HOME>/appsutil
directory.
If you are using a database tier only platform, refer to OracleMetalink (Doc ID:
456197.1) to install JRE under the <RDBMS_ORACLE_HOME>/appsutil
directory.
Step 6 If you are using the 10.2.0 ORACLE_HOME from Release 11i, generate a
new context file as follows:
UNIX:
cd <RDBMS ORACLE_HOME/appsutil/bin
perl adbldxml.pl
WINDOWS:
cd /d <RDBMS ORACLE_HOME\appsutil\bin

perl adbldxml.pl
Step 7 Run AutoConfig on the database tier nodes.
UNIX:
<RDBMS ORACLE_HOME>/appsutil/bin/adconfig.sh \
contextfile=<context file created in Step 7>
WINDOWS:
<RDBMS ORACLE_HOME>\appsutil\bin\adconfig.cmd \
contextfile=<context file created in Step 7>
Step 8 Configure Applications client software for forms applet (required)
Applies to 11i release level: AllTUMS step key: N/A
The connection between the client and the Applications forms is provided
through an applet in the client Web browser. Instead of using the browsers own
JVM, Oracle Applications uses the Sun Java (J2SE) native plug-in. You can find
download instructions in Upgrading Sun J2SE (Native Plug-in) with Oracle
Applications 12.0 Windows Clients (Doc ID: 393931.1).
Step 9 Reapply customizations (conditional)
Applies to 11i release level: AllTUMS step key: N/A
If you customized Applications environment files (APPLSYS.env or devenv), reintegrate them in devenv.env, or in the adovars.env file ($APPL_TOP/admin for
UNIX or %APPL_TOP%\admin for Windows). Restart the application server
processes so that the changes take affect.
If your system includes customized forms, reports, programs, libraries, or other
Applications files, reapply all changes that you need for this release.
Step 10 Integrate custom objects and schemas (conditional)
Applies to 11i release level: AllTUMS step key: N/A
If you previously created custom objects or have custom schemas that must be
tightly integrated with Oracle Applications, follow the steps in Oracle
Applications Developers Guide to re-integrate these customizations with the
APPS schema.
This release uses Invoker Rights for most PL/SQL packages. Executing these
packages from custom schemas may require additional grants from, and
synonyms to, APPS schema objects. Oracle recommends you explicitly declare
Invoker Rights or Definer Rights for custom PL/SQL packages. See the PL/SQL
Users Guide and Reference for more information.
Custom database objects must follow the naming standards for custom object
names to avoid conflict with Oracle Applications.
Step 11 Re-enable custom triggers, constraints, and indexes (conditional)
Applies to 11i release level: AllTUMS step key: N/A
During the upgrade, custom triggers or constraints may have been modified. If
you disabled these triggers and constraints, identify any data updates that must
be made before you re-enable them.

If you dropped any custom indexes, review the new data model to determine if
the index is necessary before you redefine it.