Apps Upgradation From 11.5.10.2 to 12.1.3

If your 11i database size is anywhere from 100 to 150 GB then, upgrade downtime won't too long.  We seen in some environments its below 12 hours for 12.1.1 upgrade and 4 hours for 1213 upgrade.

If the transaction data is above 750 GB, then finishing the 12.1.1 upgrade within 24 hours won't be possible. Hence they will go for selected upgrade.

Typically Upgrade Steps will be,

0. OATM Migration

1. Pre-Upgrade Activities (Functional, Technical, DBA) as per Upgrade Document

2. Database Upgrade

3. 12.1.1 Upgrade

4. Configure Applications and Let concurrent programs complete

5. Post Upgrade Tasks (Functional, Technical, DBA) as per Upgrade Document

6. 12.1.3+HRMS RUP4+ASCP RUP3 Upgrade

7. iAS Upgrade, Java Upgrade, JRE Upgrade

8. Customizations Upgrade (Technical)

9. Upgrade Data Verification, Enhancement Setups (Functional)

10. Shared Apps Tier, MultiNode Configuraiton, etc.,

Now, below tips might be useful if your database is anywhere between 150 GB to 750 GB.

Before Upgrade downtime,

1. Purge all possible Run time tables.

Purge Concurrent Request and/or Manager Data

Purge Obsolete Workflow Runtime Data

You can purge Workflow History of Permanant Presistance Type also. Just get confirmation with My Oracle Support.

Purge Debug Log And System Alerts

Purge Obsolete Generic File Manager Data

Purge Signon Audit data

Purge Inactive Sessions

Purge RX Interface Data

PURGE Messages (OE Processing Messages)

Purge ATP Temp Table

Purge Rule Execution

2. Re org all the tables & indexes effected by above concurrent programs

3. Update FND_LOBS not to index binary data

4. Migrate to OATM way before upgrade downtime. It will reduce your upgrade time significantly.

It not only reduces your database size but also reorgs your table which gives better performance.

5. Diable any Debug, Trace, Diagnostics profile options set.

6. In various occasions, you would have taken taken backup of many tables. Verify and delete them.

7. If you have custom tables which stores data just for history, then compress them and keep.

Just before Upgrade,

1. Put your database in noarchivelog mode before starting the upgrade driver.

Because upgrade driver will generate huge amount of archive logs (Say 250 GB) which will fill up archive log location.

It won't possibly use it for recovery. Instead restore will be easier.

You can re enable archivelog mode after finishing 12.1.3 upgrade driver.

2. Increase your online redo size to 2GB minimum and should have minimum 6 Groups, in case of RAC 4 groups each instance

3. Increase your undo tablespace to 20 GB

4. Increase your TEMP tablespace to 20 GB

5. Increase your APPS_TS_TX_DATA and APPS_TS_TX_IDX tablespace.

In the first test upgrade capture tablespace size at each stage,

before 12.1.1 upgrade,

after 12.1.1 upgrade,

after 12.1.3 upgrade,

before releasing the instance.

And then analyze the difference in tabelspace size to get the exact increase in each tablespace.

5. If your SGA is below 5 GB then increase it from 5 GB to 10 GB if your Physical memory permits

6. If your PGA is below 5 GB then increase it to 5 GB if your Physical memory permits

7. Merge AD CUP patches with AD.B and apply in admode

8. Merge and Apply EBS CUP patches in preinstall mode and then merge it with 12.1.1 upgrade driver.

9. You no need to recompile the invalid objects throughout the upgrade. When any object is accessed at runtime automatically it will get compiled.

So, use adpatch options=nocompiledb from 12.1.1 upgrade driver till the last patch.

Allow object compile only at the last patch

Additionally for the 1211 Upgrade driver, you have to below option

Add  "extension plsql_no compile yes"  to u_merged.drv

   extension patch_type software base

   extension plsql_no compile yes

   extension patchinfo maintpack 12.0.0

Also Comment out below lines (same line will appear twice)

      sql ad patch/115/sql adobjcmp.sql

      sql ad patch/115/sql adobjcmp.sql

10. In adpatch when asked for Batch commit size use 10000. Using the default 1000 will have severe performance problem of upg scripts. A script which took 24 hours wiht batch size 1000 has taken 1 hour 45 minutes with batch commit size 10000

11. Use no.of workers equal to no.of actual physical processors in the database server. Don't count cores as processors. If you have given more workers during patch, anytime you can reduce the no.of workers by quitting them using adctrl.

12. Review the timing report of 12.1.1 Upgrade Driver & 12.1.3+ driver,

        Check for files (Jobs) that  has taken more time

        Check for phases that has taken more time

Compare the timing reports of each test upgrades.

13. Document each worker failure and the solutions for them. So that in the next upgrade you can proactively apply the solution.

14. Resolve all the invalid objects and keep the solutions ready with you.

15. Along with 12.1.3 merge HRMS RUP4, Latest ASCP RUP and all Bug fix patches from first test upgrade and apply.