<![CDATA[ORAERP.COM - The Knowledge Center for Oracle ERP Professionals - Looking Beyond the Possibilities - EBS R12.1 Upgrade Center]]> http://www.oraerp.com/ Wed, 19 Jun 2013 09:57:40 +0000 MyBB <![CDATA[R12.1.3 Upgrade from 11.5.10]]> http://www.oraerp.com/Thread-R12-1-3-Upgrade-from-11-5-10 Mon, 25 Feb 2013 08:42:40 -0600 http://www.oraerp.com/Thread-R12-1-3-Upgrade-from-11-5-10 We are in the process of upgrading the 11.5.10 Instance to R12.1.3.
The current Architecture is Dual Node with the Application Tier on one node and the CM and the DB Tier on another node.
On Future R12 the Application Tier is going to be on two nodes and the the DB on RAC.

What I will be doing is R12.1.1 Installation with Upgrade Option.

What should be the procedure to have multiple application servers?

Finish the upgrade on one Application Node and then clone the other Application Tiers?
Please suggest.]]> We are in the process of upgrading the 11.5.10 Instance to R12.1.3.
The current Architecture is Dual Node with the Application Tier on one node and the CM and the DB Tier on another node.
On Future R12 the Application Tier is going to be on two nodes and the the DB on RAC.

What I will be doing is R12.1.1 Installation with Upgrade Option.

What should be the procedure to have multiple application servers?

Finish the upgrade on one Application Node and then clone the other Application Tiers?
Please suggest.]]> <![CDATA[Migrating Oracle E-Business Suite R12 from Linux 32-bit to Linux 64-bit]]> http://www.oraerp.com/Thread-Migrating-Oracle-E-Business-Suite-R12-from-Linux-32-bit-to-Linux-64-bit Sat, 23 Feb 2013 12:08:42 -0600 http://www.oraerp.com/Thread-Migrating-Oracle-E-Business-Suite-R12-from-Linux-32-bit-to-Linux-64-bit want to Migrating Oracle E-Business Suite R12 from Linux 64-bit
require suggestions]]> want to Migrating Oracle E-Business Suite R12 from Linux 64-bit
require suggestions]]> <![CDATA[Pre upgrade - range of periods]]> http://www.oraerp.com/Thread-Pre-upgrade-range-of-periods Wed, 20 Feb 2013 11:42:30 -0600 http://www.oraerp.com/Thread-Pre-upgrade-range-of-periods Step 1: Set range of periods (optional)
We are in the process of upgrading our complete data and not to go with only upgrading the current fiscal year data. So, I was told that even If I select to upgrade all the data during upgrade, I have to still run this program with year starting with min(period_name) from gl_period_statuses and ending as max(period_name) from gl_period_statuses.

Is this need to be done this way and moreover, how to select max and min period as am getting many values like adj-yy (i.e. adj-78,adj-79)....etc..
Please advise]]> Step 1: Set range of periods (optional)
We are in the process of upgrading our complete data and not to go with only upgrading the current fiscal year data. So, I was told that even If I select to upgrade all the data during upgrade, I have to still run this program with year starting with min(period_name) from gl_period_statuses and ending as max(period_name) from gl_period_statuses.

Is this need to be done this way and moreover, how to select max and min period as am getting many values like adj-yy (i.e. adj-78,adj-79)....etc..
Please advise]]> <![CDATA[When does your company plan to upgrade to Oracle EBS Release 12?]]> http://www.oraerp.com/Thread-When-does-your-company-plan-to-upgrade-to-Oracle-EBS-Release-12 Fri, 07 Dec 2012 15:29:32 -0600 http://www.oraerp.com/Thread-When-does-your-company-plan-to-upgrade-to-Oracle-EBS-Release-12 <![CDATA[Oracle Apps upgrade 11.5.10.2 from 12.1.1]]> http://www.oraerp.com/Thread-Oracle-Apps-upgrade-11-5-10-2-from-12-1-1 Thu, 25 Oct 2012 04:27:58 -0500 http://www.oraerp.com/Thread-Oracle-Apps-upgrade-11-5-10-2-from-12-1-1
.docx  OracleAppsUpgradeFrom11.5.10.2to12.1.1DBA_Tasks.docx (Size: 807.52 KB / Downloads: 198) ]]>
.docx  OracleAppsUpgradeFrom11.5.10.2to12.1.1DBA_Tasks.docx (Size: 807.52 KB / Downloads: 198) ]]> <![CDATA[Oracle EBS R12 Post Installation Issues]]> http://www.oraerp.com/Thread-Oracle-EBS-R12-Post-Installation-Issues Fri, 14 Sep 2012 10:29:17 -0500 http://www.oraerp.com/Thread-Oracle-EBS-R12-Post-Installation-Issues I have just installed Oracle Apps R12.1.1 - fresh install- on windows xp but getting this error when I try to go into forms. I still get the error even after installing a higher version:
1) FRM-92095 :Oracle JInitiator version too low. Please install version 1.1:8.2 or higher
2) Again, I can't log onto Sqlplus due to this error:
Enter user-name:
apps/apps
ERROR:
ORA-12560: TNS:protocol adapter error
3) I get only dos prompt for sqlplus logon and not the usual sqlplus white background
screen.
4) from Programme, Start menu, I can't see the Forms and report developer menus.

Will appreciate any feedback/comments....
thanks
Pryia]]> I have just installed Oracle Apps R12.1.1 - fresh install- on windows xp but getting this error when I try to go into forms. I still get the error even after installing a higher version:
1) FRM-92095 :Oracle JInitiator version too low. Please install version 1.1:8.2 or higher
2) Again, I can't log onto Sqlplus due to this error:
Enter user-name:
apps/apps
ERROR:
ORA-12560: TNS:protocol adapter error
3) I get only dos prompt for sqlplus logon and not the usual sqlplus white background
screen.
4) from Programme, Start menu, I can't see the Forms and report developer menus.

Will appreciate any feedback/comments....
thanks
Pryia]]> <![CDATA[Upgrading Oracle Application 11i to E-Business Suite R12]]> http://www.oraerp.com/Thread-Upgrading-Oracle-Application-11i-to-E-Business-Suite-R12 Fri, 12 Aug 2011 13:05:25 -0500 http://www.oraerp.com/Thread-Upgrading-Oracle-Application-11i-to-E-Business-Suite-R12 Overview of upgrade to R12
Upgrading an application from 11i to R12 involves, upgrading the database side, upgrading the middleware techstack and upgrading the application side.
Supported upgrade path for application side upgrade is as given below.
[Image: 18.jpg?w=630][/url]
In case of database upgrade, you have to upgrade the database to 10gR2 (10.2.0). Because application R12 can be used only with 10g database.
Upgrade Process
All upgrade functionality has been consolidated into a single unified upgrade driver that performs the upgrade without reliance on the information formerly captured on the AutoUpgrade screens.
Rapid Install provides the most up-to-date, certified version of Oracle Applications products, along with the certified technology stack components. In an upgrade, it creates the new file system for the application (middle) tier components and the new file system for the database. After the upgrade, you run Rapid Install again to configure servers and start services.
An upgrade also includes various manual steps, including those that direct you to run scripts or apply patches. You rely on AutoPatch to apply all patches, including the unified driver that performs the upgrade to Release 12.
Upgrade Steps in brief
Here are the 4 simple steps, briefly presented below for upgrade. These steps are at very high level of abstraction. We will detailed each steps as we move on further.
1) Understand installed components, system sizing information, NLS considerations
2) Prepare for upgrade using Upgrade Manual Script(TUMS).
3) Upgrading to R12. This includes upgrading the database and applying the required patches through AutoPatch.
4) Post-Upgrade process. Complete the upgrade process by applying the latest RUP patches to keep the system most current.
We wont be considering the functional upgrade task here.
Upgrade steps in detail
1) Understanding installed components
Technology Stack Components
Rapid Install automatically installs and configures the required technology stack components for both the database tier and the application tier.
The database tier technology stack for both a new installation and for a system upgrade is based on Oracle10g Release 2.
The technology stack installed on the application tier includes, among other components:
- Oracle 10g Application Server (AS) 10.1.2
- Oracle 10g Application Server (AS) 10.1.3
- Oracle Developer 10g (includes Oracle Forms)
- Java (J2SE) native plug-in 1.5.0_08
- Java Developer Kit (JDK) 5.0
Memory Requirements
To calculate the memory requirements for an upgrade, consider the following:
- Number of concurrent users
- Infrastructure requirements for multi-tiered architecture
For example:
A test upgrade of the largest Oracle production system (oraprod) used the following:
- Database tier machine – 48 GB of memory
- Application tier machine – 12 GB of memory
A test upgrade of the Vision database and application tier machine used 6 GB of memory.
Database Size
To estimate the increase in required disk space for upgrading, consider the products, the number of languages being installed, and changes in the data model.
For example:
In a test upgrade of the largest Oracle production system (oraprod), the database increased 10-20 percent. In a test upgrade, the Vision database increased 5 percent. For guidelines based on an upgrade of the Oracle production system (oraprod), see E-Business Suite Release 12 Upgrade Sizing and Best Practices (Doc ID: 399362.1).
Database Backup
*** We strongly recommend that you back up your entire system before you begin the upgrade. ***
Database Initialization Parameters
Initialization parameters required at each stage of the upgrade may vary depending on when you upgrade your database. Review the requirements for these parameters before you begin. Refer to metalink note ID 396009.1 for initialization parameters.
Change the following initialization parameters as specified below for upgrade process. Once the upgrade process completes, reset the parameters back.
  • db_file_multiblock_read_count – Remove this parameter. (this is not required).
  • _db_file_optimizer_read_count = 8 (default setting is 8. Keep default setting).
  • job_queue_processes (set the value of this parameters equal to number of CPUs).
  • parallel_max_servers (set the value of this parameters equal to twice the number of CPUs).
  • pga_aggregate_target (refer to metalink note ID 396009.1 for recommended value).
Make sure that the temporary tablespace you have is locally managed and not dictionary managed. You can check this information using below query.
select CONTENTS,EXTENT_MANAGEMENT,ALLOCATION_TYPE from dba_tablespaces where tablespace_name=’TEMP’;

CONTENTS EXTENT_MANAGEMENT ALLOCATION_TYPE
———— —————– —————
TEMPORARY LOCAL UNIFORM
Else if the extent management is not local, you can drop and recreate temp tablespace using the below command.
NLS Upgrade Considerations
For NLS considerations, please refer to Applications upgrade docs.
Character Sets
You have to be careful while selecting the character set for APPL_TOP. Depending on whether your Applications system connects to the database during the upgrade process, you may be able to select a new character set for the Release 12 APPL_TOP on the Rapid Install wizard upgrade screens. However, if you do, the new set must be either identical to, or compatible with, the existing database character set. If you change the character set in the APPL_TOP to one that is not compatible with the current database character set, the upgraded system will be corrupted.
SQL> create TEMPORARY tablespace TEMP tempfile ’ts_p_temp1.dbf’ size 2048M EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;
2) Prepare for upgrade using Upgrade Manual Script(TUMS) and upgrading database
  • R12 upgrade process involve replacing 11i Tech stack (9iAS & 806) to Fusion Middleware (10g Application Server)
  • Basic upgrade process involves Rapid Install & Autopatch
  • Rapid Install involves installing new R12 tech stack as mentioned in first point
  • Auto patch process involves upgrading E-Business Suite database compatible to R12 (Data Model)
  • Final upgrade process is of updating data model using enhanced version of AutoPatch
  • Minimum version from which you can upgrade to R12 is 11.5.7 and higher
  • Minimum database version from which you can upgrade to R12 is 9i
As per Oracle R12 Upgrade Documentation, Apps 11i Instance is classified in Two Categories based on Apps & DB Version
Category 1 – 11.5.7, 11.5.8, 11.5.9 (CU1), 11.5.10 (CU1)
Category 2 – 11.5.9 (CU2), 11.5.10 (CU2) or 11.5.10.2
Why we cannot upgrade database to 10.2.0.2 before for category 1 ?
This is because there is no Interoperability patch for above release & 10.2.0.2 was supported for 11.5.9 (CU2) & 11.5.10(CU2) only.
What are advantages of Upgrading database to 10.2.0.2 before R12 upgrade ?
Downtime can be broken down to two small downtimes (one for Database upgrade another one for R12 upgrade) and can be achieved during weekends or long weekends (depending on your system & resources)
The following table lists the paths available for each of the E-Business Suite 11i releases supported for an upgrade to R12
[Image: 0.jpg?w=630][/url]
PATH A:
  • Plan Upgrade to R12
    • Follow the standard R12 upgrade path as documented in the Oracle Applications Upgrade Guide: Release 11i to Release 12. Perform all requirements documented in Chapter 1 and all applicable steps in Chapter 2.
  • Install the R12 Technology Stack and 10.2.0.2 Oracle home
  • Upgrade the Database to 10.2.0.3
  • Apply Database Patches
  • Apply the database patches as per the metalink note ID 403339.1. (6319846 for Linux)
  • Apply Oracle Service patch 5880762 (conditional)
  • Complete the R12 upgrade
  • Perform the remaining steps in Chapter 3 and all applicable steps in Chapter 4 to complete the upgrade to R12.
PATH B:
  • Plan Upgrade to R12
  • Apply Database Patches
  • Apply the database patches as per the metalink note ID 403339.1. (6319846 for Linux)
  • Apply Oracle Service patch 5880762 (conditional)
  • Complete the R12 upgrade
PATH C:
  • Plan Upgrade to R12
  • Upgrade Database to 10.2.0
  • Continue with the R12 Upgrade or Use the 11i/10.2.0 System
  • Apply Database Patches
  • Apply the database patches as per the metalink note ID 403339.1. (6319846 for Linux)
  • Apply Oracle Service patch 5880762 (conditional)
  • Complete the R12 upgrade
In our case, we are following path C. We were having 11.5.10 + CU2 application with 9i database. We will upgraded the database to 10GR2.
Then we will apply the database patches as per metalink note ID 403339.1 followed by service pack and then will upgrade the application to R12.
Now preparing the application system is till main step # 2 which includes upgrading the database as well. From main step 3, upgrade process for R12 starts. You may wish to stop after carring out the upgrade for database, run your business for some time (may be few months) and then go for R12 upgrade. This gives a comparatively less downtime for your existing application as you dont have to do all at the same time and can be done in steps.
The Upgrade Manual Script (TUMS) examines your current configuration and creates a report that lists upgrade tasks that do not apply to your system. This report contains information that is unique to your system configuration, so its output is relevant to your individual upgrade. Omitting the steps listed in the TUMS report can significantly reduce upgrade downtime.You create the TUMS report by applying a Release 11i patch, which loads objects into your APPS schema that TUMS uses to examine your Applications configuration. Your current Applications environment is not affected.
Below are the list of steps I am mentioning, which are the required steps. I am skipping the conditional steps here, just to make it brief. You can as well check the oracle documentation for the complete steps.
Step 1) Apply latest AD patch level. The latest AD patch is 11i.AD.I.6 and checkin number is 6502082.
SQL> select patch_level from fnd_product_installations
2 where patch_level like ‘%AD%’;
PATCH_LEVEL
——————————
11i.AD.I.6
Step 2) Run TUMS utility
- Download and apply TUMS patch (5120936). This will supply you one script “adtums.sql”, which you can run to generate the report.
- To generate the report
cd $AD_TOP/patch/115/sql
sqlplus / @adtums.sql
< DIRECTORY> is where the report file will get generated. You need to create directory in database using create directory command. Also the directory path you are mentioning here should exists in UTL_FILE_DIR.
SQL> create directory APPS_DIR as ‘/usr/tmp’;
Directory created.
[applmgr@ocvmrh2081 sql]$ sqlplus apps/apps @adtums.sql APPS_DIR
step 3) Convert to Multiple Organizations architecture

Step 4) Review sizes of old and new tablespaces

Step 5) Run AD preparation scripts
Download patch 5726010. This will provide 3 scripts adgncons.sql, adgrants_nt.sql, adgrants.sql. Script adgrants_nt.sql is not for Linux and so can be ignored.
- First run the script adgncons.sql. This will create script adcrtbsp.sql. This script (adcrtbsp.sql) 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.
[applmgr@ocvmrh2081 5726010]$ sqlplus apps/apps @adgncons.sql apps apps
Run adcrtbsp.sql with system user ID and password from database side
[applmgr@ocvmrh2081 5726010]$ sqlplus system/manager @adcrtbsp.sql
- adgrants.sql will grants SYS privileges needed by Applications, and creates required views in SYS.
You need to run this command “as sysdba”. This will prompt you for FND_ORACLE_USERID owner. You need to enter “applsys” when it prompts.
Step 6) Gather schema statistics for CBO
You can do this by Submitting “Gather Schema Statistics” concurrent request for “ALL” schemas.
Step 7) Backup Database
Take the backup of database before we go further with upgrade process
Step 8 ) Upgrading the database from 9i to 10g. You can refer to upgrade database in Oracle applications 11i post to have detailed steps. The database version should be 10.2.0.2
Step 9) Prepare the application for upgrade. You need to run the rapid wizard in upgrade mode. This will create the required file system, install the required techstack components. Below are the screen flow for the same.
[Image: 1.jpg?w=630][/url]
[Image: 2.jpg?w=630][/url]
[Image: 3.jpg?w=630][/url]
[Image: 4.jpg?w=630][/url]
[Image: 5.jpg?w=630][/url]
[Image: 6.jpg?w=630][/url]
[Image: 7.jpg?w=630][/url]
[Image: 8.jpg?w=630][/url]
[Image: 9.jpg?w=630][/url]
[Image: 10.jpg?w=630][/url]
[Image: 11.jpg?w=630][/url]
[Image: 12.jpg?w=630][/url]
[Image: 13.jpg?w=630][/url]
[Image: 14.jpg?w=630][/url]
[Image: 15.jpg?w=630][/url]
[Image: 16.jpg?w=630][/url]
[Image: 17.jpg?w=630][/url]
After running this wizard, you will find that your existing application is intact and also a new file system has been created for you.
All your services should be up and running. Your 11i application should be intact. You might face an issue, that services (specially Apache) wont come up and your URL wont open. In this case you can check if the services get started from “inst” directory that got created after you run the wizard.
You can go to location /u01/app/applmgr/inst/apps//admin/scripts and run adstpall.sh script from that location. If the services were started from this location, then it will be stopped. Then you can start the services back from $COMMON_TOP/admin/script/ location.
Also during running of the wizard configuration information will be written to following files. you can check at your prompt and it will list the configuration files.
Configuration file written to: /u01/app/oracle/db/tech_st/10.2.0/appsutil/conf_PROD.txt
Configuration file written to: /u01/app/applmgr/apps/apps_st/appl/admin/ocvmrh2081/conf_PROD.txt
Configuration file written to: /u01/app/applmgr/inst/apps/PROD_ocvmrh2081/conf_PROD.txt
3) Upgrade Process
Below are the steps for upgrade process from 11.5.10.CU2 to 12.0.0. Till now we have just prepared the application for upgrade. Creating the neccessary filesystem layout and database upgrade was part of preparing for upgrade.
Step 1) Shut down application tier listeners and concurrent managers
Step 2) Back up the database – Once again take a backup. I am not crazy asking backup so many times, but in case we face any issue and if we dont have latest stable backup, we will be helpless.
Step 3) Ensure that Maintenance Mode is enabled – Put your application in maintenance mode
Step 4) Apply Release 12 AD minipack (4502962)
For applying this patch, you need to go in R12 APPL_TOP directory and source the env file present in that APPL_TOP. This is becasue you will be applying this patch to your new APPL_TOP and not 11i APPL_TOP. So make sure to source env file present in new APPL_TOP.
Step 5) Run the American English upgrade patch driver (u4440000.drv)
For applying this patch also, you need to go in R12 APPL_TOP directory and source the env file present in that APPL_TOP.
Step 6) Run the NLS upgrade patch driver (conditional)
For other product related steps and NLS synchronization, please check the Oracle Upgrade docs for 11i to R12.
Step 7) Disable Maintenance Mode
Once these step are carried out last step is finishing the upgrade process. Follow the below steps.
1) generate appsutil.zip on appmgr side and copy the same to new ORACLE_HOME. The new ORACLE_HOME directory structure will be created as /u01/app/oracle/db/tech_st/10.2.0
2) unzip appsutil.zip in new ORACLE_HOME
3) run autoconfig in new ORACLE_HOME
Once these steps are done, run rapid install again by provding the config file which was generated before. The file location as we noted down before is /u01/app/applmgr/apps/apps_st/appl/admin/ocvmrh2081/conf_PROD.txt
After these steps are performed, the application system will be configured and ready for use. This completes the upgrade activity from 11i to R12.
References:
Metalink Note ID : 394692.1
Metalink Note ID : 403339.1
Metalink Note ID : 396009.1
Metalink Note ID : 329476.1
Metalink Note ID : 215527.1
Courtesy: Post written by advait ]]> Overview of upgrade to R12
Upgrading an application from 11i to R12 involves, upgrading the database side, upgrading the middleware techstack and upgrading the application side.
Supported upgrade path for application side upgrade is as given below.
[Image: 18.jpg?w=630][/url]
In case of database upgrade, you have to upgrade the database to 10gR2 (10.2.0). Because application R12 can be used only with 10g database.
Upgrade Process
All upgrade functionality has been consolidated into a single unified upgrade driver that performs the upgrade without reliance on the information formerly captured on the AutoUpgrade screens.
Rapid Install provides the most up-to-date, certified version of Oracle Applications products, along with the certified technology stack components. In an upgrade, it creates the new file system for the application (middle) tier components and the new file system for the database. After the upgrade, you run Rapid Install again to configure servers and start services.
An upgrade also includes various manual steps, including those that direct you to run scripts or apply patches. You rely on AutoPatch to apply all patches, including the unified driver that performs the upgrade to Release 12.
Upgrade Steps in brief
Here are the 4 simple steps, briefly presented below for upgrade. These steps are at very high level of abstraction. We will detailed each steps as we move on further.
1) Understand installed components, system sizing information, NLS considerations
2) Prepare for upgrade using Upgrade Manual Script(TUMS).
3) Upgrading to R12. This includes upgrading the database and applying the required patches through AutoPatch.
4) Post-Upgrade process. Complete the upgrade process by applying the latest RUP patches to keep the system most current.
We wont be considering the functional upgrade task here.
Upgrade steps in detail
1) Understanding installed components
Technology Stack Components
Rapid Install automatically installs and configures the required technology stack components for both the database tier and the application tier.
The database tier technology stack for both a new installation and for a system upgrade is based on Oracle10g Release 2.
The technology stack installed on the application tier includes, among other components:
- Oracle 10g Application Server (AS) 10.1.2
- Oracle 10g Application Server (AS) 10.1.3
- Oracle Developer 10g (includes Oracle Forms)
- Java (J2SE) native plug-in 1.5.0_08
- Java Developer Kit (JDK) 5.0
Memory Requirements
To calculate the memory requirements for an upgrade, consider the following:
- Number of concurrent users
- Infrastructure requirements for multi-tiered architecture
For example:
A test upgrade of the largest Oracle production system (oraprod) used the following:
- Database tier machine – 48 GB of memory
- Application tier machine – 12 GB of memory
A test upgrade of the Vision database and application tier machine used 6 GB of memory.
Database Size
To estimate the increase in required disk space for upgrading, consider the products, the number of languages being installed, and changes in the data model.
For example:
In a test upgrade of the largest Oracle production system (oraprod), the database increased 10-20 percent. In a test upgrade, the Vision database increased 5 percent. For guidelines based on an upgrade of the Oracle production system (oraprod), see E-Business Suite Release 12 Upgrade Sizing and Best Practices (Doc ID: 399362.1).
Database Backup
*** We strongly recommend that you back up your entire system before you begin the upgrade. ***
Database Initialization Parameters
Initialization parameters required at each stage of the upgrade may vary depending on when you upgrade your database. Review the requirements for these parameters before you begin. Refer to metalink note ID 396009.1 for initialization parameters.
Change the following initialization parameters as specified below for upgrade process. Once the upgrade process completes, reset the parameters back.
  • db_file_multiblock_read_count – Remove this parameter. (this is not required).
  • _db_file_optimizer_read_count = 8 (default setting is 8. Keep default setting).
  • job_queue_processes (set the value of this parameters equal to number of CPUs).
  • parallel_max_servers (set the value of this parameters equal to twice the number of CPUs).
  • pga_aggregate_target (refer to metalink note ID 396009.1 for recommended value).
Make sure that the temporary tablespace you have is locally managed and not dictionary managed. You can check this information using below query.
select CONTENTS,EXTENT_MANAGEMENT,ALLOCATION_TYPE from dba_tablespaces where tablespace_name=’TEMP’;

CONTENTS EXTENT_MANAGEMENT ALLOCATION_TYPE
———— —————– —————
TEMPORARY LOCAL UNIFORM
Else if the extent management is not local, you can drop and recreate temp tablespace using the below command.
NLS Upgrade Considerations
For NLS considerations, please refer to Applications upgrade docs.
Character Sets
You have to be careful while selecting the character set for APPL_TOP. Depending on whether your Applications system connects to the database during the upgrade process, you may be able to select a new character set for the Release 12 APPL_TOP on the Rapid Install wizard upgrade screens. However, if you do, the new set must be either identical to, or compatible with, the existing database character set. If you change the character set in the APPL_TOP to one that is not compatible with the current database character set, the upgraded system will be corrupted.
SQL> create TEMPORARY tablespace TEMP tempfile ’ts_p_temp1.dbf’ size 2048M EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;
2) Prepare for upgrade using Upgrade Manual Script(TUMS) and upgrading database
  • R12 upgrade process involve replacing 11i Tech stack (9iAS & 806) to Fusion Middleware (10g Application Server)
  • Basic upgrade process involves Rapid Install & Autopatch
  • Rapid Install involves installing new R12 tech stack as mentioned in first point
  • Auto patch process involves upgrading E-Business Suite database compatible to R12 (Data Model)
  • Final upgrade process is of updating data model using enhanced version of AutoPatch
  • Minimum version from which you can upgrade to R12 is 11.5.7 and higher
  • Minimum database version from which you can upgrade to R12 is 9i
As per Oracle R12 Upgrade Documentation, Apps 11i Instance is classified in Two Categories based on Apps & DB Version
Category 1 – 11.5.7, 11.5.8, 11.5.9 (CU1), 11.5.10 (CU1)
Category 2 – 11.5.9 (CU2), 11.5.10 (CU2) or 11.5.10.2
Why we cannot upgrade database to 10.2.0.2 before for category 1 ?
This is because there is no Interoperability patch for above release & 10.2.0.2 was supported for 11.5.9 (CU2) & 11.5.10(CU2) only.
What are advantages of Upgrading database to 10.2.0.2 before R12 upgrade ?
Downtime can be broken down to two small downtimes (one for Database upgrade another one for R12 upgrade) and can be achieved during weekends or long weekends (depending on your system & resources)
The following table lists the paths available for each of the E-Business Suite 11i releases supported for an upgrade to R12
[Image: 0.jpg?w=630][/url]
PATH A:
  • Plan Upgrade to R12
    • Follow the standard R12 upgrade path as documented in the Oracle Applications Upgrade Guide: Release 11i to Release 12. Perform all requirements documented in Chapter 1 and all applicable steps in Chapter 2.
  • Install the R12 Technology Stack and 10.2.0.2 Oracle home
  • Upgrade the Database to 10.2.0.3
  • Apply Database Patches
  • Apply the database patches as per the metalink note ID 403339.1. (6319846 for Linux)
  • Apply Oracle Service patch 5880762 (conditional)
  • Complete the R12 upgrade
  • Perform the remaining steps in Chapter 3 and all applicable steps in Chapter 4 to complete the upgrade to R12.
PATH B:
  • Plan Upgrade to R12
  • Apply Database Patches
  • Apply the database patches as per the metalink note ID 403339.1. (6319846 for Linux)
  • Apply Oracle Service patch 5880762 (conditional)
  • Complete the R12 upgrade
PATH C:
  • Plan Upgrade to R12
  • Upgrade Database to 10.2.0
  • Continue with the R12 Upgrade or Use the 11i/10.2.0 System
  • Apply Database Patches
  • Apply the database patches as per the metalink note ID 403339.1. (6319846 for Linux)
  • Apply Oracle Service patch 5880762 (conditional)
  • Complete the R12 upgrade
In our case, we are following path C. We were having 11.5.10 + CU2 application with 9i database. We will upgraded the database to 10GR2.
Then we will apply the database patches as per metalink note ID 403339.1 followed by service pack and then will upgrade the application to R12.
Now preparing the application system is till main step # 2 which includes upgrading the database as well. From main step 3, upgrade process for R12 starts. You may wish to stop after carring out the upgrade for database, run your business for some time (may be few months) and then go for R12 upgrade. This gives a comparatively less downtime for your existing application as you dont have to do all at the same time and can be done in steps.
The Upgrade Manual Script (TUMS) examines your current configuration and creates a report that lists upgrade tasks that do not apply to your system. This report contains information that is unique to your system configuration, so its output is relevant to your individual upgrade. Omitting the steps listed in the TUMS report can significantly reduce upgrade downtime.You create the TUMS report by applying a Release 11i patch, which loads objects into your APPS schema that TUMS uses to examine your Applications configuration. Your current Applications environment is not affected.
Below are the list of steps I am mentioning, which are the required steps. I am skipping the conditional steps here, just to make it brief. You can as well check the oracle documentation for the complete steps.
Step 1) Apply latest AD patch level. The latest AD patch is 11i.AD.I.6 and checkin number is 6502082.
SQL> select patch_level from fnd_product_installations
2 where patch_level like ‘%AD%’;
PATCH_LEVEL
——————————
11i.AD.I.6
Step 2) Run TUMS utility
- Download and apply TUMS patch (5120936). This will supply you one script “adtums.sql”, which you can run to generate the report.
- To generate the report
cd $AD_TOP/patch/115/sql
sqlplus / @adtums.sql
< DIRECTORY> is where the report file will get generated. You need to create directory in database using create directory command. Also the directory path you are mentioning here should exists in UTL_FILE_DIR.
SQL> create directory APPS_DIR as ‘/usr/tmp’;
Directory created.
[applmgr@ocvmrh2081 sql]$ sqlplus apps/apps @adtums.sql APPS_DIR
step 3) Convert to Multiple Organizations architecture

Step 4) Review sizes of old and new tablespaces

Step 5) Run AD preparation scripts
Download patch 5726010. This will provide 3 scripts adgncons.sql, adgrants_nt.sql, adgrants.sql. Script adgrants_nt.sql is not for Linux and so can be ignored.
- First run the script adgncons.sql. This will create script adcrtbsp.sql. This script (adcrtbsp.sql) 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.
[applmgr@ocvmrh2081 5726010]$ sqlplus apps/apps @adgncons.sql apps apps
Run adcrtbsp.sql with system user ID and password from database side
[applmgr@ocvmrh2081 5726010]$ sqlplus system/manager @adcrtbsp.sql
- adgrants.sql will grants SYS privileges needed by Applications, and creates required views in SYS.
You need to run this command “as sysdba”. This will prompt you for FND_ORACLE_USERID owner. You need to enter “applsys” when it prompts.
Step 6) Gather schema statistics for CBO
You can do this by Submitting “Gather Schema Statistics” concurrent request for “ALL” schemas.
Step 7) Backup Database
Take the backup of database before we go further with upgrade process
Step 8 ) Upgrading the database from 9i to 10g. You can refer to upgrade database in Oracle applications 11i post to have detailed steps. The database version should be 10.2.0.2
Step 9) Prepare the application for upgrade. You need to run the rapid wizard in upgrade mode. This will create the required file system, install the required techstack components. Below are the screen flow for the same.
[Image: 1.jpg?w=630][/url]
[Image: 2.jpg?w=630][/url]
[Image: 3.jpg?w=630][/url]
[Image: 4.jpg?w=630][/url]
[Image: 5.jpg?w=630][/url]
[Image: 6.jpg?w=630][/url]
[Image: 7.jpg?w=630][/url]
[Image: 8.jpg?w=630][/url]
[Image: 9.jpg?w=630][/url]
[Image: 10.jpg?w=630][/url]
[Image: 11.jpg?w=630][/url]
[Image: 12.jpg?w=630][/url]
[Image: 13.jpg?w=630][/url]
[Image: 14.jpg?w=630][/url]
[Image: 15.jpg?w=630][/url]
[Image: 16.jpg?w=630][/url]
[Image: 17.jpg?w=630][/url]
After running this wizard, you will find that your existing application is intact and also a new file system has been created for you.
All your services should be up and running. Your 11i application should be intact. You might face an issue, that services (specially Apache) wont come up and your URL wont open. In this case you can check if the services get started from “inst” directory that got created after you run the wizard.
You can go to location /u01/app/applmgr/inst/apps//admin/scripts and run adstpall.sh script from that location. If the services were started from this location, then it will be stopped. Then you can start the services back from $COMMON_TOP/admin/script/ location.
Also during running of the wizard configuration information will be written to following files. you can check at your prompt and it will list the configuration files.
Configuration file written to: /u01/app/oracle/db/tech_st/10.2.0/appsutil/conf_PROD.txt
Configuration file written to: /u01/app/applmgr/apps/apps_st/appl/admin/ocvmrh2081/conf_PROD.txt
Configuration file written to: /u01/app/applmgr/inst/apps/PROD_ocvmrh2081/conf_PROD.txt
3) Upgrade Process
Below are the steps for upgrade process from 11.5.10.CU2 to 12.0.0. Till now we have just prepared the application for upgrade. Creating the neccessary filesystem layout and database upgrade was part of preparing for upgrade.
Step 1) Shut down application tier listeners and concurrent managers
Step 2) Back up the database – Once again take a backup. I am not crazy asking backup so many times, but in case we face any issue and if we dont have latest stable backup, we will be helpless.
Step 3) Ensure that Maintenance Mode is enabled – Put your application in maintenance mode
Step 4) Apply Release 12 AD minipack (4502962)
For applying this patch, you need to go in R12 APPL_TOP directory and source the env file present in that APPL_TOP. This is becasue you will be applying this patch to your new APPL_TOP and not 11i APPL_TOP. So make sure to source env file present in new APPL_TOP.
Step 5) Run the American English upgrade patch driver (u4440000.drv)
For applying this patch also, you need to go in R12 APPL_TOP directory and source the env file present in that APPL_TOP.
Step 6) Run the NLS upgrade patch driver (conditional)
For other product related steps and NLS synchronization, please check the Oracle Upgrade docs for 11i to R12.
Step 7) Disable Maintenance Mode
Once these step are carried out last step is finishing the upgrade process. Follow the below steps.
1) generate appsutil.zip on appmgr side and copy the same to new ORACLE_HOME. The new ORACLE_HOME directory structure will be created as /u01/app/oracle/db/tech_st/10.2.0
2) unzip appsutil.zip in new ORACLE_HOME
3) run autoconfig in new ORACLE_HOME
Once these steps are done, run rapid install again by provding the config file which was generated before. The file location as we noted down before is /u01/app/applmgr/apps/apps_st/appl/admin/ocvmrh2081/conf_PROD.txt
After these steps are performed, the application system will be configured and ready for use. This completes the upgrade activity from 11i to R12.
References:
Metalink Note ID : 394692.1
Metalink Note ID : 403339.1
Metalink Note ID : 396009.1
Metalink Note ID : 329476.1
Metalink Note ID : 215527.1
Courtesy: Post written by advait ]]> <![CDATA[Planning Oracle E-Business Suite Upgrade from Release 11i to Release 12.1]]> http://www.oraerp.com/Thread-Planning-Oracle-E-Business-Suite-Upgrade-from-Release-11i-to-Release-12-1 Tue, 31 May 2011 02:11:45 -0500 http://www.oraerp.com/Thread-Planning-Oracle-E-Business-Suite-Upgrade-from-Release-11i-to-Release-12-1 This attached Oracle white paper contains Oracle E-Business Suite 12.1 upgrade planning tips from Oracle's support, consulting and IT organizations.

You will get specific cross-product reviews on how to understand the factors that affect your project's duration, decide project's scope and develop a good testing strategy.

The white paper is kept up to date at MOS Doc 987516.1

Following a brief overview of the Release 12.1 upgrade value proposition from Oracle's note, this paper launches into specific upgrade planning tips to help you:
  • Understand the factors that can affect your project's duration
  • Decide your project scope, and avoid missteps that can needlessly increase your scope
  • Assemble the right project team
  • Develop a robust testing strategy
  • Upgrade your custom code
  • Minimize your upgrade downtime
  • Leverage all of the Oracle Support resources that are available to you
  • Identify the Oracle tools that can improve your upgrade and maintenance experience
  • Become familiar with the full range of Oracle's information resources
End notes:
NOTE:580299.1 - Best Practices for Adopting Oracle E-Business Suite, Release 12
Oracle Applications Upgrade Guide : Release 11i to Release 12.1.1
Note 269.1 - 'Upgrade Advisor: E-Business Suite Technology Stack Upgrade from 11.5.10.2 to 12.1.3'
Note 253.1 - 'Upgrade Advisor: E-Business Suite Technology Stack Upgrade from 11.5.10.2 to 12.1.2'
Note 250.1 - 'Oracle Support Upgrade Advisors'
Note 752619.1 - 'Oracle E-Business Suite Release 12.1.1 Maintenance Pack Installation Instructions'
Note 374398.1 - 'Preparing Custom Development for Next Oracle E-Business Suite Release'
Note 461705.1 - 'Oracle E-Business Suite Upgrade Center - Home'
Note 761570.1 - 'Database Preparation Guidelines for an E-Business Suite Release 12.1.1 Upgrade'
Note 807319.1 - 'Oracle E-Business Suite Release 12.1 Transfer of Information (TOI) Online Training'
Note 780989.1 - 'R12: Upgrade vs. Reimplementation (Financials)'
Note 987516.1 - 'Planning Your Oracle E-Business Suite Upgrade from Release 11i to Release 12.


.pdf  UpgradetoR12.1Whitepaper.pdf (Size: 702.84 KB / Downloads: 175) ]]> This attached Oracle white paper contains Oracle E-Business Suite 12.1 upgrade planning tips from Oracle's support, consulting and IT organizations.

You will get specific cross-product reviews on how to understand the factors that affect your project's duration, decide project's scope and develop a good testing strategy.

The white paper is kept up to date at MOS Doc 987516.1

Following a brief overview of the Release 12.1 upgrade value proposition from Oracle's note, this paper launches into specific upgrade planning tips to help you:
  • Understand the factors that can affect your project's duration
  • Decide your project scope, and avoid missteps that can needlessly increase your scope
  • Assemble the right project team
  • Develop a robust testing strategy
  • Upgrade your custom code
  • Minimize your upgrade downtime
  • Leverage all of the Oracle Support resources that are available to you
  • Identify the Oracle tools that can improve your upgrade and maintenance experience
  • Become familiar with the full range of Oracle's information resources
End notes:
NOTE:580299.1 - Best Practices for Adopting Oracle E-Business Suite, Release 12
Oracle Applications Upgrade Guide : Release 11i to Release 12.1.1
Note 269.1 - 'Upgrade Advisor: E-Business Suite Technology Stack Upgrade from 11.5.10.2 to 12.1.3'
Note 253.1 - 'Upgrade Advisor: E-Business Suite Technology Stack Upgrade from 11.5.10.2 to 12.1.2'
Note 250.1 - 'Oracle Support Upgrade Advisors'
Note 752619.1 - 'Oracle E-Business Suite Release 12.1.1 Maintenance Pack Installation Instructions'
Note 374398.1 - 'Preparing Custom Development for Next Oracle E-Business Suite Release'
Note 461705.1 - 'Oracle E-Business Suite Upgrade Center - Home'
Note 761570.1 - 'Database Preparation Guidelines for an E-Business Suite Release 12.1.1 Upgrade'
Note 807319.1 - 'Oracle E-Business Suite Release 12.1 Transfer of Information (TOI) Online Training'
Note 780989.1 - 'R12: Upgrade vs. Reimplementation (Financials)'
Note 987516.1 - 'Planning Your Oracle E-Business Suite Upgrade from Release 11i to Release 12.


.pdf  UpgradetoR12.1Whitepaper.pdf (Size: 702.84 KB / Downloads: 175) ]]>