release 12.1.3 upgrade...integrated financials. subledger accounting. subledger currency views....
TRANSCRIPT
The Big Picture
It is possible to fail in many ways...while to succeed is possible only in one way.
Aristotle (384 BC - 322 BC), Nichomachean Ethics
Release 12.1.3 UpgradeMike [email protected]
Upgrade Overview
1. Follow the steps in the upgrade guide
2. Run patchsets.sh
3. Run Patch Wizard
4. Apply any new patches
5. Iterate back to Step 3 and run Patch Wizard, until there are no new patches
R12.1.3 Technical Upgrade class
UpgradeApps 11.5.10.2 to R12.1.3 Database 10.2.0.3 to 11.2.0.3
“If you are migrating to R12 you must take this class. The hands-on training and knowledge of the instructor is invaluable.” -Roland
The Original
Based on primarily VISION upgrades with base 11.5.10.2 patches. The same basic way Oracle initially tests the upgrade.
Real customer data introduces new combinations of differing patch levels between modules and sometimes this can be data dependent.
1st Pass Upgrades
Plan Prepare Perform
P3 Upgrade Methodology
1st Pass Upgrades115102 Upgrade Client in PA going Live on R1213 – UGI Gas
“I think all of TruTek’s assistance, especially the upgrade class and 1st Pass Upgrade, were key to making this project successful.” Dan 2-15-12
115102 Upgrade Client in CA going live on R1213
“This latest upgrade test on the new production hardware went very well. I don’t see any problem getting the upgrade done over a 3 day weekend. I have you guys to thank for that.” Terry 1-31-12
Prepare
Plan
PerformUpgradeSuccess
P3 Upgrade Methodology
PlanOrganize executive sponsors and superusers into a Steering
CommitteeEstablish the Upgrade TeamIdentify the current issues - AssessmentsUnderstand AS-IS and TO-BE modelsDecision: re-implement or upgradeUnderstand the hardware requirements and the upgrade pathProcure upgrade hardwarePurge unnecessary dataTrain the functional super users in the new features of Release
12.1Create an upgraded instance for gap analysis
Prepare
Train the Super Users and Technical StaffBuy HardwareCreate Upgraded Instance for detailed gap analysisPractice TestingPractice Upgrades
Perform
Execute the PlanReduce DowntimeVerify Upgrade TasksUpgrade by Request
P3 Upgrade Methodology
Plan Prepare Perform
R12.1 Upgrade Categories
1. Plan to Upgrade
2. Prepare to Upgrade
3. Perform the Upgrade
4. Finish the Upgrade
R12.1.3 Functional Upgrade
The R12 Upgrade is not just a technical upgrade
The functional upgrade consists of mapping new business requirements with new functional features in R12.
Key R12 Functionality
Advanced Global Intercom
pany
AME
Key R12 Factors
MOAC
UMX
SLA
GRC
Integrated FinancialsSubLedger AccountingSubLedger Currency ViewsMulti Org Access ControlUser ManagementApproval Management
Strategy• Upgrade Path• Re-implement or
Upgrade• Timeframe -
downtime
Technology• Hardware Platform• Customizations• Reporting• Security
Assessment Topics
Process• Gap Analysis• New Functionality• Testing• Patching
People• Skills Gap - Training• Teamwork
Governance
Week 1: Technical Upgrade AssessmentWeek 2: Finish Technical Assessment and Project PlanWeek 3: Functional Assessment
-Start the First Pass UpgradeWeek 4: Finish the 1st Pass Upgrade
-Finish the Functional AssessmentWeek 5: R12 New Features Training
-Run, Analyze ConfigSnapshot-Begin Analysis on Custom Objects
Week 6: Perform and document Gap Analysis Week 7: Perform and document Gap Analysis, continuedWeek 8: Define Scope and Customizations Week 9: Define Detailed and Customization Schedules
The Ultimate R12.1.3 Jump-Start Assessment
Technical Assessment
Future Capacity RequirementsTech Stack Version Compatibility and Patch
Levels, including CPUsCurrent Issues from Log filesCurrent unresolved service requestsIdentify potential issues with the R12.1
Upgrade
Functional Assessment
Identify AS-IS ProcessesDetermine TO-BE ProcessesEvaluate Potential Data IssuesWhich New Features may replace
customizations?Estimate R12 New Features Training NeedsRecommend “Best Practices”
Country from ap_bank_branches
Rerun upgrade scripts and verify that error is not raised anymore.SQL> select count(*), Country from ap_bank_branches group by country;COUNT(*) COUNTRY
---------- -------------------------1081112 US3 NZ
226 CA1 BB2 GB1 DE
update ap_bank_branches set country='US' where country is null;
Architecture – Hardware Assessment
RAC vs non-RACShared Application Tier with Distributed
ProcessingConcurrent processing vs Parallel
Concurrent ProcessingSAN vs JBOD, poor IO = slow systemRMAN vs Snapshots
Hardware AssessmentIf the plan includes buying new hardware, consider migrating from the current
32-bit platform to a 64-bit platform. The following are reasons to migrate to a 64-bit environment:
Release 11i doesn’t support running the Application Tier on a 64-bit hardware platform, however, Release 12 does support 64-bit architectures for the Application Tier.
Release R12.1, Release 12, and Release 12.1 all support running the database on a 64-bit operating system, in a split or mixed architecture.
There are five hardware platforms supported for Release 12.1 and all of the platforms support a 64 bit version.
There are less memory restrictions on a 64 bit machine because of additional addressable memory.
Because of more addressable memory, more users can be supported on each Application Tier.
MRP and other programs run much more quickly in a 64-bit database.
CustomizationsCEMILIs – Software Framework for
Extensions, Customizations, Extensions, Modifications, Internationalizations, Localizations, and Integration framework.
19 classes of extensions
Oracle’s published guidelines for developing and implementing custom extensions to Oracle Applications.
CEMLI
Configurations, Extensions, Modifications, Localizations, and Integrations CEMLI.
The CEMLI Upgrade includes determining technical impact of Oracle E-Business Suite Release 12.1 on CEMLIs, upgrading CEMLIs to the new technology stack, retrofit of CEMLIs for compatibility and usability on Oracle E-Business Suite Release 12.1.
• Identify all customizations • Check-in all customizations into configuration management• Determine customizations that are replaced by new R12.1
functionality• Re-Code customizations• Prepare Customization Upgrade Implementation Plan• Customization Configuration Management
Customization Assessment
Start by identifying all customizations. In some environments the customizations aren’t well documented and some customizations may have been lost due to previous patching. Check-in all customizations into configuration management. Customizations are easier to customize if you can find them and have some version control.
Determine the customizations that are replaced by new R12.1 functionality. This requires an analyst that knows the new functionality of R12.1 and understands the customizations.
Lastly, determine the customizations that need to be fixed or added to the upgrade to preserve or extend the process alignment.
Extensions
Modifications
Customizations
Customizations• Identify• Document• Eliminate• Migrate to SOA
•Testing is the basis of success for upgrades•Testing requires practice•Testing requires Management•Testing requires the best and most knowledgeable usersExtensions
Modifications
Customizations, Extensions, Modifications
R12.1 Upgrade
Functional Upgrade Responsibilities
• Functional Testing• Understand AS IS Model• Understand TO BE Model• Document the gap between the business process and OA processes• Align the Business and Oracle Applications• Understand existing Customizations• Understand how new requirements affect the customizations• Investigate, Improve and Implement Setups • Train the Users – for example, iProcurement• Reduce downtime• Verify Upgrade
GapAnalysis
Testing
CustomizationsCustomizations• Identify• Document• Eliminate• Migrate to SOA
• Testing is the basis of success for upgrades
• Testing requires practice
• Testing requires Management
• Testing requires the best and most knowledgeable users
UpgradeSuccess
Gap Analysis requires:Superusers that understand the new features of R12.1 & understand the customizations
Functional Upgrade Success
Technical Upgrade ResponsibilitiesDBAs and Developers
• Technical Testing• Improve the Technical Foundation, hardware, software• Understand existing Customizations• Understand how new requirements affect the customizations• Perform the Technical Upgrade• Modify and implement new customizations and extensions• Reduce downtime
Customizations
Patches
Hardware
UpgradeSuccess
Technical Upgrade Success
R12.1 Upgrade Categories
1. Plan to Upgrade
2. Prepare to Upgrade
3. Perform the Upgrade
4. Finish the Upgrade
Technical Upgrade
RecommendedOption to
Upgrade DBTo 11.2.0.3
Start Upgrade to 11.5.10.2
NoPerform steps inChapter 1 and
Chapter 2Except DB migration
11.5.9.2Or
11.5.10.2
Yes
DB at10.2.0.5
11.1.0.7 or11.2.0.3
Yes
No
Perform steps1 and 2In Chapter 3, stop at
Step 3 Migrating the DB
DB at10.2.0.5
11.1.0.7 or11.2.0.3
Recommended Upgrade DB to
11.2.0.3
No
Yes AllDB patchesare applied
No
Apply DB Patches
Yes
Required:Convert to
OATM
Finish Chapter 3 Perform the UpgradeApply 12.1.1 patch Finish the Upgrade
Finish Chapter 4Post Upgrade StepsOn-line Help patch
Apply 12.1.3 patch
UpgradeFinished
Downtime starts here
Downtime ends here
Recommended:Convert to
OATM
OATMEnabled?
No
Yes
OATMEnabled
NoYes
This guide assumeswe start with 11.5.10.2
Overview of Technical Upgrade
Projects to Complete before the R12.1.3 Upgrade
Upgrade Database to 11.2.0.3Complete Migration to 64-bit databaseComplete Migration to OATMPurge unnecessary dataFix “bad data”Compile a list of all Customizations
Release 12.1 Upgrade Paths
Path A DB 9iR2, 10gR2 Apps 11.5.7 or 11.5.8DB Upgrade & Apps Upgrade need to
be completed during the same downtime window.
Path B If the DB already at 11gR1, Apps 11.5.9.2 or 11.5.10.2
Only upgrade the Apps StackPath C Upgrade the DB & Apps in different
phases
Release 12.1 Upgrade PathsIf upgrading from a release prior to 11.5.7, the upgrade
path may require an interim upgrade to Release 11.5.10.2.
Because of the significant downtime required to upgrade from Release 11.0 to Release 12, it may be more feasible to first upgrade to Release 11.5.10.2 and then some time later upgrade to Release 12.
This requires the functional users to learn Release 11.5.10.2, and perform all the testing for another upgrade.
The amount of work necessary to perform two rounds of system acceptance testing may justify another day or two of downtime, so that the upgrade from Release 11.0 to Release 12.1 can be completed in one longer period of downtime.
Upgrade Paths
12.0.4 12.0.612.0
11.5.9.2 11.5.10.2
11.5.7 11.5.8
11.0
12.1.111.5.9.2 11.5.10.2
11.5.111.5.6
11.5.10.2
12.0.412.0.6 12.1.1
12.1.3
Release 12.1 Upgrade PathsInitial Release Interim Release Final Release R12 Patch11.0, 11.5.1 - 11.5.6 Release 11.5.10 CU2 Release 12.0.0 4440000
11.5.7. 11.5.8, 11.5.9* or 11.5.10* Release 12.0.0 4440000
11.5.7, 11.5.8, 11.5.9.2, 11.5.10.2 Release 12.0.4 6394500
11.5.9*, 11.5.10* Release 12.1 6678700
12.1.1 Release 12.1.2 7303033
12.1.1 Release 12.1.3 9239090* includes CU1 and CU2 (consolidated update)Figure 4 indicates that a direct upgrade path exists from Release 11.5.7 to Release
12.0.0.
Database Upgrade Requirements
Release Certified Database Versions on Solaris12.1 10gR2, 11gR2 and the 64 bit versions12.0 10gR2, 11gR2 and the 64 bit versions11.5.10.2 10gR2 or 11gR2 and the 64 bit versions11.5.9.2 10gR2 and the 64 bit versions11.5.7 8.1.7, 9.0.1 9.2, and 9.2-64 bit
We can see that there is no certified database version that is certified with both Release 11.5.7 and Release 12.1. Therefore, we can’t do the database upgrade before the downtime window.
Database Upgrade
• The database installed by the 11.5.10.2 RapidWiz is Version 9.2.0.6. This database version does not support Daylight Savings Time (DST). Therefore, we have two choices:
• Upgrade the database to Version 9.2.0.8, which has support for DST, and then upgrade to Version 11.2.0.3, or
• Upgrade the database to Version 10.2.0.3, using the database Oracle Home provided with the 12.0.4 EBS install.
• Since, we require an interim step, and we already have the 12.0.4 DVDs staged, it is easier to use the 10.2.0.3 Oracle Home than to download the 9.2.0.8 patch and apply all the E-Business Suite-specific database patches.
StartDB
Upgrade
Upgrade Databasedirectly to 11.2.0.3
Include patches:9218789
DB version>= 9.2.0.8 &
DST P4
Yes
No
Post DB Upgrade StepsFor R12.1
Fix Korean lexersRun adgrants.sqlGrant to CTXSYSValidate WorkflowRun AutoConfig
Gather Stats for SYSGrants and SynonymsFix Syn for Trade Mgmt
DB UpgradeFinished
This guide assumeswe start with EBS version 11.5.10.2 and 9.2.0.6 of the database.
Apps Versionat Least
11.5.10.2
DB versionat Least9.2.0.6
YesUpgrade Database to
10.2.0.3Use the OH from
the 12.0.4 RapidWiz
We upgrade to 10.2.0.3 as an interim step to 11.1.0.7, because this home comes with the 1204 install,
The OH that comes with the RapidWiz install has all the necessary database patches already applied.
Fix DaylightSaving Time
Patch 4
Upgrade Database to11.2.0.3
Database Upgrade Steps
TestingProcess
PatchingProcess
ApplyCustomizations
UpgradeSuccess
Upgrade Downtime
Backup &Restore
ApplyPatches
Clone
PatchSuccess
Upgrade Patching Process
Backup &Restore &
Clone
Test
ApplyPatches,
Setups, orCustomizations
TestingSuccess
Upgrade Testing Process
Anytime you change a setup, or perform a clone, apply a patch, or apply a customization to the instance, you should test.
Upgrade Downtime w DB Upgrade
Clone to Upgrade Machine
Thursday Friday Saturday Sunday
8 AM
12 Noon
5 PM
Start Database Upgrade
12 Midnight
920610203
Database Upgrade
1020311203
Database Upgrade
Start R12.1
Upgrade
R12.1 Upgrade
Backup
Destructive Testing
Monday
Go Live!
Restore from the Backup
Apply On-line Help
Patch
Start R12.1.3 Upgrade
Upgrade Timeframe
• Typically, the upgrade to Release 12.1 from 11.5.10.2 will require a 3 to 4 day weekend for downtime, starting at the close of business on Wednesday or Thursday, for a 3 or 4 day downtime window.
• The database upgrade generally takes 8 to 12 hours, If the database upgrade is complete prior to upgrade weekend, it’s possible to do a 2 day applications upgrade from 11.5.10.2.
• The database upgrade can be completed independent of the Release 12.1 applications upgrade and if possible, should be completed weeks or months before the Release 12.1.1 Upgrade.
• The Applications portion of the upgrade will take 14 to 32 hours depending on the speed of the server and the amount of data to upgrade. Testing will take 8-12 hours, after the upgrade is complete.
• Backups can be time consuming and recovery should be tested before the upgrade weekend.
Upgrade Downtime wo DB Upgrade
Clone to Upgrade Machine
Friday Saturday Sunday
8 AM
12 Noon
5 PM
12 Midnight
Start R12.1 Upgrade
R12.1 Upgrade
Backup
Destructive Testing
Monday
Go Live!
Restore from the Backup
Apply On-line Help
Patch
Start R12.1.3 Upgrade
Plan to Upgrade
Procure Upgrade HardwareCreate Upgraded Instance for Gap Analysis
Identify Current IssuesPerform Upgrade Assessments:
Functional Customization ArchitectureCapacity
R12.1 Upgrade Categories
1. Plan to Upgrade
2. Prepare to Upgrade
3. Perform the Upgrade
4. Finish the Upgrade
Are we there yet?We are ready when:
Business processes align with Oracle Applications
Customizations support the business processesUsers are familiar with the new functionality and
have been trainedTesting indicates all processes are functioning
Optimize• Reduce Downtime• Improve Uptime• Improve Reporting• Improve Response• Reduce Costs• Improve Visibility• Increase Productivity
Evolve• Incorporate R12 New Functionality• Replace customizations with R12
New Functionality• Perform Business Process Gap
Analysis• Enable EBS Users
Manage• Align Business Processes with OA R12• Set Process Expectations• Provide Training• Migrate Customizations to SOA• Implement Comprehensive Business
Reporting
Manage Optimize
Evolve
The Evolution of the R12 Upgrade It’s an iterative approach
Upgrade Iterations
Rapid Install 12.1 Apps TierTEST
UpgradeIterations
1st Pass R12.1 Apps Tier
Test and Fix
+ + Fixes
R12.1 Apps Tier + 2nd Pass
Performance
Customizations
+ + New Fixes
R12.1 Apps Tier ++
Customizations
Test
Test
No New Issues
Prepare to UpgradeMaintenance Wizard (215527.1)
Step-by-step, graphical user interface for performing upgrade tasks
Consolidates instructions from multiple sources to present a comprehensive upgrade picture
Reduces upgrade tasks by filtering out those that do not apply to you (using TUMS)
Indicates critical patches that your system requires
Can automatically execute upgrade tasks for you
patchsets.shPatchset
Product Name Bug_number RELEASED_DATE Status DISTRIBUTION --------- ---------------- ---------- ----------------- -------------------- -------------------ad R12.AD.A 4502962 07/01/18 17:08:25 Checkin Released By_Metalinkad R12.AD.A.1 5905728 07/04/13 13:11:10 Checkin Released Not_Distributedad R12.AD.A.2 6014659 07/07/13 05:30:06 Checkin Released Not_Distributedad R12.AD.A.3 6272715 07/10/14 17:33:24 Checkin Released Not_Distributedad R12.AD.A.4 6510214 08/01/13 07:38:00 Checkin Released By_Metalinkad R12.AD.A.5 7305206 08/08/04 09:56:59 Checkin Released Not_Distributedad R12.AD.A.6 7305220 08/11/05 11:14:22 Checkin Released By_Metalinkad R12.AD.B 6665350 08/08/13 12:40:54 Checkin Released Not_Distributedad R12.AD.B.1 7461070 09/04/10 06:51:59 Checkin Released By_Metalinkad R12.AD.B.1 7458155 09/04/08 07:21:21 Checkin Released Not_Distributedad R12.AD.B.2 8502056 09/12/16 06:44:40 Checkin Released By_Metalink
Patch WizardUse Patch Wizard from Oracle Application Manager (OAM). We recommend that when you finish your upgrade to what you
believe is the latest version of 12.1.3, with all the patches and Family Packs identified from patchsets.sh, this book, and your own research, you should run Patch Wizard again to see if additional patches are found. When we ran a Vision upgrade in February, 2011, Patch Wizard identified 78 more patches above and beyond everything we found for 12.1.3.
Note that Patch Wizard may require patches for both Release 11i and Release 12 (9643141, 10629956).
.
Prepare to Upgrade
If possible complete the following prior to the R12.1 upgrade weekend:Upgrade the Database to 11.2.0.3Migrate to OATMInstall the R12.1 softwareRun Downtime Reducing stepsRun pre-upgrade verification steps
RecommendedOption to
Upgrade DBTo 11.2.0.3
Start Upgrade to 11.5.10.2
NoPerform steps inChapter 1 and
Chapter 2Except DB migration
11.5.9Or
11.5.10
Yes
DB at10.2.0.4 or
11.1.0.711.2.0.3
Yes
No
Perform steps1 and 2In Chapter 3, stop at
Step 3 Migrating the DB
DB at10.2.0.4 or11.1.0.7,11.2.0.3
Upgrade DB to11.2.0.3
No
Yes AllDB patchesare applied
No
Apply DB Patches
Yes
Required:Convert to
OATM
Finish Chapter 3 Perform the UpgradeApply 12.1.1 patch Finish the UpgradeApply 12.1.3 patch
Finish Chapter 4Post Upgrade StepsOn-line Help patch
UpgradeFinished
Downtime starts here
Downtime ends here
Recommended:Convert to
OATM
OATMEnabled?
No
Yes
OATMEnabled
NoYes
This guide assumeswe start with 11.5.10.2
Overview of Technical Upgrade
R12.1 Upgrade Categories
1. Plan to Upgrade
2. Prepare to Upgrade
3. Perform the Upgrade
4. Finish the Upgrade
Perform the UpgradePerforming the Upgrade is not iterativeThe production upgrade should work predictably
What happens if it fails?Testing, Upgrade checklistsPlan for a secondary upgrade weekend contingency
If the Upgrade fails, you haven’t practiced enough. Look at failed upgrades as forced practice.
That which we persist in doing becomes easier, not that the task itself has become easier, but that our ability to perform it has improved.
Ralph Waldo Emerson (1803 - 1882)
Understand and Test Upgrade By Request
• Upgrade certain CRM, Financials, Procurement, Projects and Supply Chain Management data during the R12.1.3 upgrade
• Process the rest after the R12.1.3 upgrade is complete, or process all the data as part of the upgrade
• Default is data for the current fiscal year and the periods of the previous fiscal year that are necessary to ensure there are at least six periods in the upgrade
• Technical staff need to understand what the functional staff need, from the very beginning
Understand and Test Upgrade By Request
• As part of your upgrade planning, be sure that your functional users understand Oracle’s default processing ― they may want to process morethan just the default during the upgrade downtime• Read MOS Doc. ID: 980112.1, New Functionality for SLA Upgrade
Process for R12.1.2• Read MOS Doc. ID: 604893.1, R12.0 and R12.1: FAQ for the SLA
Upgrade: SLA Pre-Upgrade, Post-Upgrade, and Hot Patch• Read MOS Doc. ID: 399362.1, Oracle Applications Release 12
Upgrade Sizing and Best Practices to evaluate the potential growth of your SLA tables
• Read Oracle Applications Upgrade Guide: Release 11i to Release 12.1.3 E16342-03
Understand and Test Upgrade By RequestOptions:1. Accept the Default: no patches before applying 12.1.1; upgrade approx 6 periods. After,
apply either Hot Patch 5584908 + SLA Post-Upgrade Concurrent Program, or run SLA: Upgrade Historical Subledger Transaction Accounting Program (XLAONDEUPG).
2. Apply Patches 5233248 so you can change the default number of periods of historic data to be upgraded and 10231107 if you use Oracle Projects and/or Grants Accounting to R11i before applying 12.1.1, submit the SLA Pre-Upgrade Concurrent Program to select what data to upgrade, then apply 12.1.1. After, either apply Hot Patch 5584908 and then the SLA Post-Upgrade Concurrent Program, or run SLA: Upgrade Historical Subledger Transaction Accounting Program (XLAONDEUPG) .
3. Apply Patches 5233248 +/- 10231107 + SLA Pre-Upgrade Concurrent Program for all data as part of the downtime window
NOTE: You can either apply Patch 5584908 or run XLAONDEUPG, but you can’t do both. If you start using XLAONDEUPG, then it will need to be continued to be run for each product, ledger and period.
Understand and Test Upgrade By Request
Patch 5584908 or XLAONDEUPG: What’s the Diff?From MOS Doc. ID: 1376752.1, SLA: Upgrade Historical Subledger Transaction Accounting Program (XLAONDEUPG):• The Subledger (SLA) post upgrade on demand concurrent program called
Upgrade Historical Subledger Transaction Accounting (XLAONDEUPG) allows you to upgrade transactions for a particular Subledger (e.g., AP, AR, FA, Costing), GL ledger, and accounting period.
• Whereas, the SLA Hot Patch (xla5584908.drv) only allows you to specify a period, and all historical transactions for the Subledgers are upgraded at the same time during this post upgrade step.
Understand and Test Upgrade By Request
XLAONDEUPG• Use XLAONDEUPG if you have a ledger in existence and want to create a
secondary ledger with links to appropriate data• Use XLAONDEUPG if you need to add an additional reporting currency or a
secondary ledger• Oracle analyzed how much data they would ever need and concluded 8 years
would do it. The rest of the data is still there, it just hasn’t been processed.• Upgrade as much data as you think you’ll need (ever!)• If you can take it all, do so
• Remember - it’s one or the other – XLAONDEUPG or Patch 5584908
Understand and Test Upgrade By RequestFrom a Geek’s Perspective
• The first time your technical staff tries upgrading to R12.1.3. The purpose is to get through without having to stop and start while dealing with a lot of failures with the 12.1.1 maintenance pack. The purpose is not (generally) to provide a perfect test environment for the functional staff. So (generally) accept the default for Upgrade by Request.
First Pass Upgrade
• Start testing to see how long it takes to process all the data that functional users want processed. Can you do all of it during your downtime window, or do you need to split off part of it and process it later?
Second Pass
Upgrade
R12.1 Upgrade Categories
1. Plan to Upgrade
2. Prepare to Upgrade
3. Perform the Upgrade
4. Finish the Upgrade
Finish the Upgrade
• Perform the Testing
Upgrade Patch Types
Release 12.1 Financials Upgrade Patch Collection (UPC)
The latest Release 12.1 Financials Upgrade Patch Collection (UPC) contains Release 12.1 Upgrade patches for the following products: Payables Receivables Tax Subledger Accounting Intercompany Financials For India
The Release 12.1 Financials Upgrade Patch Collection is created specifically for customers who have yet to upgrade their product environment to Release 12.1. This UPC contains improvements to the upgrade process to Release 12.1.
Release 12.1 Financials Upgrade Patch Collection (UPC)
• These fixes are not required to be applied to environments that have already been upgraded to Release 12.1.
• These patches are critical to the upgrade process and it is essential that they are applied to your Applications Code Tree (APPL_TOP) prior to running the R12.1 Upgrade Driver.
• The latest patch as of November, 2009, is Patch: 8773483:R12 .FIN_PF.B, referenced in My Oracle Support Knowledge Document 880275.1.
• You should look for the latest UPC on My Oracle Support and add it to your upgrade plan.
Critical Patch Updates (CPUs)
A Critical Patch Update (CPU) is a collection of patches for multiple security vulnerabilities. It also includes non-security fixes that are required (because of interdependencies) by those security patches. Critical Patch Updates are cumulative, except as noted, but each advisory describes only the security fixes added since the previous Critical Patch Update. Thus, prior Critical Patch Update Advisories should be reviewed for information regarding earlier accumulated security fixes.
• Critical Patch Upgrades (CPUs) are released quarterly. When you upgrade to Release 12.1.1, you should plan to apply the latest available CPU. The latest as of November, 2009 is the Oct 2009, Rev 1, 20 October 2009. You should look for the latest CPU on My Oracle Support and add it to your upgrade plan. We recommend applying the CPU patches on another weekend following the upgrade. However, if time allows on the R12.1 upgrade weekend, it is possible to apply the latest CPU .
Patch Set Updates (PSUs)
• Patch Set Updates (PSUs) are database patches. The PSU stategy is to deliver low-risk, high value content that has a limited scope and is thoroughly tested.
• According to My Oracle Support Knowledge Document 854428.1, Intro to Patch Set Updates (PSU):
• Patch Set Updates (PSUs) are proactive cumulative patches containing recommended bug fixes that are released on a regular and predictable schedule. PSUs are on the same quarterly schedule as the Critical Patch Updates (CPU), specifically the Tuesday closest to the 15th of January, April, July, and October.
• The Patch Set Updates for Database 10.2.0.4 and Database 11.1.0.7 each include a Cluster Ready Services (CRS) patch. Like the Database server patch, the CRS patch is a well-tested, low-risk patch of recommended fixes.
Database PSUs
Oracle Database PSU Unix Patch Comments11.1.0.7.1 Patch 8833297
11.1.0.7.1 for CRS Patch 8287931 Originally released as CRS bundle #1
10.2.0.4.2 Patch 8833280
10.2.0.4.2 for CRS Patch 8705958
PSUs• The following PSUs are planned for the next Patch
Set Update release (January 2010):– Database 10.2.0.4.3– Database 11.1.0.7.2– CRS 11.1.0.7.2– Enterprise Manager Grid Control - OMS 10.2.0.5.2– Enterprise Manager Grid Control - Agent 10.2.0.5.2
• For the purposes of our Vision instance upgrade, we need to add either Patch 8833297 for RDBMS Version 11.1.0.7.1, or Patch 8833280 for RDBMS Version 10.2.0.4.2 to our upgrade plan.
Tune the Upgrade
Optimal Number of Workers
In our upgrade machines there are 4 CPUs. With timing data from more than 30 upgrades, the times were measured and the number of workers was varied from 2 to 16. The fastest upgrade times were for 3 workers.
Set the number of workers to CPUs – 1
For a machine with 16 CPUs, then, we would use 15 workers.
My reasoning for this rule is as follows:Patches run jobs that are dependent. When too many jobs are running in parallel, it is easier to get the jobs out of order, and more jobs will be deferred. Deferring jobs causes more management overhead.
Therefore, by running one less worker than CPUs, the operating system CPU requirements and other CPU usage attributed to overhead for deferrals are free to run on the available CPU and should not disturb the running workers.
Optimal Number of Workers
Oracle Recommends:
To determine optimal number of workers, test with the following goals:
• Between 1*CPUs and 1.5*CPUs• Average IO response times below 10-15 milliseconds• Average CPU usage below 100%
Optimize adpatch
• Use TUMS to eliminate the tasks that are not relevant for your system
• Use Shared file system for Multi-node• Use Distributed AD for Multi-node• Estimate tablespace sizes for test upgrade using Note:
399362.1Autoextend tablespaces based on previous upgrades
Choose proper batchsize • Batchsize = 1000 to 10000
Tuning the Upgrade
time adpatch defaultsfile=$APPL_TOP/admin/VIS/adalldefaults.txt logfile=adpatch.log patchtop=$AU_TOP/patch/115/driver workers=3 interactive=yes options=novalidate, nocopyportion, nogenerateportion
Other options:
nocompiledb,nocompilejsp,noautoconfig
AutoConfig in Parallel Mode Across Multiple Nodes
The ability to run AutoConfig in parallel across multiple nodes was introduced in the TXK 12.1.1 Consolidated Patch. This feature reduces maintenance downtime.
AutoConfig can be run in 'parallel mode' by issuing the following command:On the Applications tier:
perl <AD_TOP>/bin/adconfig.pl contextfile=<CONTEXT_FILE> [product=<product_top>] –parallel
On the Database tier:perl <ORACLE_HOME>/appsutil/bin/adconfig.pl
contextfile=<CONTEXT_FILE> –parallel
When running AutoConfig simultaneously on multiple nodes, the '-parallel' option must be specified while starting AutoConfig on every node. Otherwise, the execution of AutoConfig processes on individual nodes will not be synchronized, and may result in an inconsistent file system or database.
AD_TASK_TIMINGJOB_NAME PRODUCT PROGRAM PHASE elapsed time -hrsadobjcmp.sql ad AutoPatch 27 5.652222222adobjcmp.sql ad AutoPatch 79 2.133611111adsstats.sql ad AutoPatch 346 1.908888889adstatrp.sql ad AutoPatch 346 1.908888889adpcpcmp.pls ad AutoUpgrade 12 1.842222222adpcpcmp.pls ad AutoUpgrade 12 1.768611111adobjcmp.sql ad AutoPatch 346 1.758055556adpcpcmp.pls ad AutoUpgrade 12 1.656944444invmenu.ldt inv AutoPatch 41 1.288333333ontmenu.ldt ont AutoPatch 41 0.978888889afoamadmmenu.ldt fnd AutoPatch 41 0.870555556ozfmenu.ldt ozf AutoPatch 41 0.806111111akdatsb1.drv ak AutoUpgrade 20 0.802222222oksmenu.ldt oks AutoPatch 41 0.783055556fndwfusermenu.ldt fnd AutoPatch 41 0.598333333iexmenus.ldt iex AutoPatch 41 0.523055556systemadministratormenu.ldt fnd AutoPatch 41 0.4675fem_xdmi.odf fem AutoPatch 25 0.419166667oamdiagbasemenu.ldt fnd AutoPatch 41 0.419166667bermind.sql ben AutoPatch 2 0.412222222
Reducing Downtime
JOB_NAME PRODUCT PROGRAM PHASE elapsed time -hrs
facpupg.sql FA AutoPatch 245 0.005277778
glrsgup2.sql GL AutoPatch 244 0.010833333
Fixed Assets has a potentially long running sql script, facpupg.sql. The script is run by AutoPatch (adpatch) and takes about 19 seconds to run. The script takes so little time to run that it should be run during the downtime window and would not save a significant amount of downtime if run in advance.
Tuning the Upgrade
Make sure you reset the following init.ora parameters after completion of R12 upgrade driver
• recyclebin• parallel_max_servers• job_queue_processes
• Merge all the NLS patches and apply them as single merged patch• Isolate post upgrade concurrent programs to a separate manager queue as
mentioned in the best practices Doc id: 399362.1• Gather statistics before upgrade • Use Gather Auto option at 10g• Record timing for each step during test upgrade• Drop MRC schema before R12 upgrade
Add PL/SQL no compile option in R12 upgrade driver to save time during upgrade– Add “extension plsql_no compile yes” line in upgrade driver file to enable PL/SQL no
compile option
11i patches pre-reqs for 12.1.11st Merge Patch
AD.I.7: 7429271ATG RUP7MERGE1: 3218526, 4206794ATG RUP7: 6241631
11i patches pre-reqs for 12.1.13153717 **,3854941, 3854951, 3865683, 4252634, 4372996, 4583125 ** (upgrade XML parser), 4029076 ** (only necessary for SSL), 4396821, 4507073, 4582937, 4607647, 4699061, 4939444, 4963569, 4969938, 4619025, 5043266 **, 5055050, 5194357, 5230979, 5259121, 5357791, 5368595, 5377946, 5382135 **, 5644722, 5684770, 5880762, 5910548, 5970422, 6024690, 6349338, 6351946, 6408117, 6505416, 6696828, 6741394, 6936696 ** (only necessary for SSO), 7418579, 7446446, 7477784, 7721754, 7828862, 8242248, 8340090, 8487779, 8579398, 8761881, 8798855, 8845395, 8908907, 8990356, 8991381, 9003549, 9053932, 9109247, 9128838, 9149988, 9158621 **, 9187813, 9288021, 9304675, 9383048, 9442701, 9446543, 9476923, 9535311, 9685457, 9725579, 9747572, 9871422, 9889680, 9935935, 10182813, 10258309 **, 11870353, 11876699, 12794415 **, 13466801 **, 13343438 **
R12.1 patches pre-install for 12.1.13rd Merge Patch
7303029, 7648869, 8351855, 8429275, 8509517, 8517880, 8615142, 8712047, 8731432, 8752951, 8764069, 8865466, 8871012, 8942413, 8967918, 9062910, 9257954, 9491856, 9504903, 9586498, 9726737, 9799876, 9868229, 9918101, 9947835, 10029457, 10096115, 10096191, 10144929, 10163753, 10170555, 10221534, 10235226, 10358280, 10359715, 10393730, 11071399, 11071569 **, 11928146, 12332819, 12344218, 12347791, 12360278, 12372035, 12578648, 12648752, 12837833, 12877611, 12944782, 12990345
Patch Search
12.0, 12.1 and 12.2 patches
“C” patches are 12.2 patches
admrgpch -admode
New Feature in R12: admrgpch -admode
By default admrgpch runs in non admode.
-admode specifies that only the ad components of patches will be merged
Special pre-12.1 Merged Patch
9179588 + 9477107 + 7461070
Oracle has changed this step with the introduction of the Consolidated Upgrade Patch 1 (CUP1) for Release 12.1.1. Rather than apply the 12.1.1 AD upgrade driver, Patch 7461070, follow the instructions in MOS Doc. ID: 798258.1, Oracle Applications Release Notes, Release 12.1.1: Instead of applying the AD 12.1.1 upgrade driver, apply Patch 9179588 (R12.AD.B), following the instructions in the patch readme.
“
Special pre-12.1Merged PatchPatch 9179588 README.txt
When directed by the Oracle Upgrade Guide to apply the AD 12.1.1 upgrade driver and run the American English upgrade patch driver in Chapter 3 of the Oracle Applications Upgrade Guide: Release 11i to Release 12.1.1, perform the following steps, instead:
1. Apply Patch 9179588 (9179588:R12.AD.B), following the instructions in the patch readme, which will tell you to merge it with Patch 9477107 and Patch 7461070 using -admode.
Note that it is very important that you follow the instructions for 9179588 and merge using the –admode command. You will receive errors if you do not merge this correctly.
Special pre-12.1 Merged Patch
From the 9179588 READMEWhen directed to apply the AD 12.1.1 upgrade driver in
Chapter 3, Step 3.01.10, of Oracle Applications Upgrade Guide: Release 11i to Release 12.1.1, perform the following steps instead.
Merge Patch 9179588:R12.AD.B with Patch 9477107:R12.AD.B and Patch 7461070: R12.AD.B.1.
Note: This merge should be a full merge using -admode. Do not use -preinstall or –driver only mode.admrgpch–s . –d merged/. –admode
adgrants.sql2. Run AD GrantsPre-install TasksYou must shut down all Application tier services before performing the
tasks in this section.Instructions for Running AD Grants
Run the adgrants.sql script as a user that can connect as SYSDBA to grant privileges to selected SYS objects and create PL/SQL profiler objects.
Usage:Create $ORACLE_HOME/appsutil/admin on the database server.Copy adadmin/adgrants.sql (UNIX) from Patch 7461070 to
ORACLE_HOME/appsutil/admin.
adgrants.sql3. Set the environment to point to ORACLE_HOME on the
database server.4. Use SQL*Plus to run the script:
$ sqlplus /nologSQL> @$ORACLE_HOME/appsutil/admin/adgrants.sql <APPS schema name>
Apply merged Patch 9179588+9477107+7461070Customers who are on R12.AD.A, must apply Critical Patch
6767273:R12.AD.A before applying the AD Mini pack. This patch can not be merged with the AD Mini pack and must be applied separately
Caused by not running Korean lexers
FAILED: file bomprg.ldtIf you see:ATTENTION: All workers either have failed or are waiting: FAILED: file bomprg.ldt on worker 1.FAILED: file pqpzzcncprg00025.ldt on worker 2.FAILED: file jg12acp.ldt on worker 3.FAILED: file payzzcncprg00514.ldt on worker 4.
drkorean.sqlMOS Doc. ID: 452095.1, Ora-24816: Expanded Non Long
Bind Data Supplied After Actual Long Or Lob ColumnSolution: set the Apps Tier NLS_LANG to UTF8Stop adpatch, export
NLS_LANG=American_America.UTF8, start adpatchAt Job 13356
FAILED: file cskbcat.ldt on worker 1.Caused by not running Korean lexers, drkorean.sqlMOS Doc. ID: 415487.1, cskbcat.ldt fails during R12
upgrade with Error loading seed data for CS_KB_SOLN_CATEGORIES_VL
drkorean.sqlIf you upgraded from 10.1.0 or previous releases, use
SQL*Plus to connect to the database as SYSDBA, and run drkorean.sql using the following command:
$ sqlplus "/ as sysdba" @$ORACLE_HOME/ctx/sample/script/drkorean.sql
HR_HOOKSMissing Patches for HR_HOOKS, needed if HR
is fully installed and patched beyond the minimum 11.5.10.2 level.
9685457 - R12 UPGRADE FAILS PER_ZA_USER_HOOK_PKG.VALIDATE_PERSON_ADDRESS, HR_API_USER_H
9889680 - R12 UPGRADE PATCH U6678700 FAILS ON APPS.HR_API_USER_HOOKS_UTILITY
HR_HOOKSAt about 38K jobs left, at the end of phase A145
Worker 1 AutoPatch R120 pl amslmtpd.ldt FAILED Delete the non-custom data
Worker 2 AutoPatch R120 pl peaeiasd.sql FAILED HR_HOOKSWorker 3 AutoPatch R120 pl EDRXDOMigration.class FAILED Caused by:
java.net.SocketException: Connection resetWorker 4 AutoPatch R120 pl hrorgasd.sql FAILED HR_HOOKSWorker 5 AutoPatch R120 pl MSDODPCODE.sql FAILED Analytic
Workspace 'aw create odpcode‘Worker 6 AutoPatch R120 pl hrleiasd.sql FAILED HR_HOOKSWorker 7 AutoPatch R120 pl psadcefc.sql Running
HR_API_USER_HOOKS_UTILITY
R12.1: Upgrade Patch 6678700 Fails on APPS.HR_API_USER_HOOKS_UTILITY [ID 1174964.1]
ERROR at line 1:ORA-06501: PL/SQL: program errorORA-06512: at "APPS.HR_API_USER_HOOKS_UTILITY", line 891ORA-06512: at line 1
STEPS-----------------------The issue can be reproduced at will with the following steps:1. Follow Document 798258.1- Apply patch 9179588 - Apply patch 7303029 - Apply merged patch
VALIDATE_PERSON_ADDRESS
A. Regarding PER_ZA_USER_HOOK_PKG.VALIDATE_PERSON_ADDRESS:
Patch 9114024 was missed in patching plan. Year End patches and legislative update patches for ZAHR need to be applied in specific order. This is explained in the following MOS note: Document 1071124.1
PER_ASG_AGGR.SET_PAYE_AGGR
B. Regarding PER_ASG_AGGR.SET_PAYE_AGGR:An error is raised when upgrading 11iRup5 HRMS installation to 12.1.1. This is because of the API User Hooks which exist in 11iRup5 but are not present in 12.1.1.
This is explained in the following bug:Bug 9943155 - ERROR ON WHEN UPGRADING FROM 11i TO 12.1.1
UPDATE_US_ADDRESS
C. Regarding PER_US_ADD_LEG_HOOK.UPDATE_US_ADDRESS:User should not be able create a non US style address as Primary Address.
This is explained in the following bug:Bug 9889680 - R12 UPGRADE PATCH U6678700 FAILS ON APPS.HR_API_USER_HOOKS_UTILITY
UPDATE_US_ADDRESS"AR"."HZ_PARTIES"."HOME_COUNTRY
Adwork003
sqlplus -s APPS/***** @/u01/oracle/PROD/apps/apps_st/appl/ce/12.0.0/patch/115/sql/cebucopy.sql
DECLARE*ERROR at line 1:ORA-12899: value too large for column "AR"."HZ_PARTIES"."HOME_COUNTRY"
(actual:20, maximum: 2)ORA-06512: at line 918
UPDATE_US_ADDRESS"AR"."HZ_PARTIES"."HOME_COUNTRY
During Upgrade cebucopy.sql Fails with ORA-12899: value too large for column "AR"."HZ_PARTIES"."HOME_COUNTRY" [ID 560504.1]
During R12 upgrade, worker running cebucopy.sql fails with the following error shown in the adworker log:
sqlplus -s APPS/***** @/u01/oracle/apps/apps_st/appl/ce/12.0.0/patch/115/sql/cebucopy.sqlDECLARE*ERROR at line 1:ORA-12899: value too large for column "AR"."HZ_PARTIES"."HOME_COUNTRY" (actual:6, maximum: 2)ORA-06512: at line 918
UPDATE_US_ADDRESS"AR"."HZ_PARTIES"."HOME_COUNTRY
CauseThe cause of the issue is invalid data in ap_bank_branches table in the
11i pre-upgrade instance.
The country code for bank/bank branch should be only two characters. In some instances, there are more than two characters populated in the Country column. Some instances will have NULL values causing the upgrade script to populate with the information from different profile options. These options may populate the full default country name and not the country code, hence the script will fail.
UPDATE_US_ADDRESS"AR"."HZ_PARTIES"."HOME_COUNTRY
Solution1. Run the following select in the 11i pre-upgrade instance:
select Country from ap_bank_branches;
2. Review the output from Step 1 and determine whether any are more than two characters or NULL.
3. If they are just a few rows that are either NULL or more than two characters, then retrieve every bank/bank branch in 11i pre-upgrade instance and define the country. This will populate the two letter code in the table.
UPDATE_US_ADDRESSCountry from ap_bank_branches
4. Rerun upgrade scripts and verify that error is not raised anymore.SQL> select count(*), country from ap_bank_branches group by
country;COUNT(*) COUNTRY
---------- -------------------------1081112 US
3 NZ226 CA
1 BB2 GB1 DE
update ap_bank_branches set country='US' where country is null;
czhist.sql - 11.1.0.7 only issue
SQL> EXECUTE DBMS_STATS.UPGRADE_STAT_TABLE (‘APPLSYS’, ‘FND_STATTAB’);
