Blog | Aug 8, 2013

Few Tips For Oracle EBS R12 Upgrade With Minimum Downtime

For business organizations time is money. Organizations avoid upgrading their applications for the complexity, costs and the effort involved. Many conglomerates in the global market are operating at a lower code level (11.5.10.2) than to upgrade to R12 for the fear of interruption to their production environment, which may impact their business and revenues.
Worried are you? Don’t be. Upgrading to R12 is no longer a nightmare. A fully functional R12 EB-suite upgrade is taking much less time and enhancing user experience. Let’s read below, to see how we can leverage the best practices available and reduce the downtime significantly.

Code Enhancement
Oracle has enhanced its code level to ensure upgrading is done quickly and effortlessly. 
i. The adpatch has been replaced by the autoupgrade tool. Autoupgrade tool has been incorporated with the parallel infrastructure mechanism, for the distribution of the large table updates. It divides large tables into chunks  and uses separate processes in parallel to update each chunk of data.
ii. R12 upgrade driver is now bundled with Gather Auto Stats job, to keep statistics up-to-date during and after upgrade.
iii. AD is supplied with sqlplus parallel directive, which eliminates contention between jobs executing the parallel queries.
iv. Table monitoring feature enables Gather Stats programs to gather only new or changed statistics.
v. Autoupgrade tool converts non-critical jobs as concurrent manager requests that run in concurrent queue, irrespective of the downtime window.

Best Practices ~ Project Planning

i. Resource staffing: Engage the right people at the right place to ensure you accurately project the cost and effort required for the upgrade as well as estimating the impact of any customizations that
may exist in your environment. The list below depicts how different people are needed during different phases of the upgrade.
Project Manager: Project owner, decision maker, task and staff coordinator
Functional Resource: Functional impact, review new features and functionality, process and upgrade testing
DBA: Database administrative tasks, technology stack, upgrade tasks, AD utilities
Technical Resource:  Functional impact, customization impact, customization development tasks

ii. Review appropriate documentation: You want to make sure you and your team review proper Oracle documentation to gather information on upgrade process, tools required, number and types
of tasks involved in the overall maintenance window.

iii. Plan to run multiple test upgrades:
A baseline for upgrade execution time: During several test upgrades, you get the opportunity to observe the execution time for each of the subtasks. This will allow you to implement fixes if
available to reduce execution time, and re-calculate the timing. This helps in forecasting exactly how much time is required during Prod cutover and eliminate any upgrade issues.

iv. Plan to test key features: You might want to leverage the Online Upgrade of the Historical Data feature. The historical data can be upgraded at a later date, allowing the system to get up & run faster for the following:
Financials & Procurement
• Supply Chain management
• CRM


v. Hardware Planning:  During the upgrade testing you should select the same hardware as what you will be using for your upgraded production environment. This illustrates a clear picture
of performance of the actual Prod upgrade beforehand.

Best Practices ~ Pre Upgrade
i. Make sure you review your project plan to eliminate the tasks that are not relevant for your system.
ii. Use shared file system for Multi-Node application tier.
iii. Use distributed-AD during patching for multi-node. As it runs in parallel, it helps in reducing patching time significantly, rather than applying patches in one node at a time.
iv. Estimate tablespace size during upgrade testing. This will help you plan to avoid space issues during production upgrade.
v. There are initialization parameters that can be modified during the upgrade process. You can refer to appropriate Oracle reference material that will help identify what is appropriate for your environment.
vi. Check for appropriate steps that may be required based on your OS.  This will help you be proactive in resolving potential issues that could occur during the upgrade process.
vii. Disable ARCHIVELOG mode and auditing.
viii. Check the latest Oracle R12 upgrade guide for specific steps for upgrading module data.
ix. Complete following steps in advance to reduce downtime
Convert to Multi Org
• Convert to OATM

x. Gather statistics of all schema using the GSS concurrent program.
xi. Record the timing for each of the steps during the test upgrade.
xii. Research for the appropriate lines that should be added to your R12 upgrade driver. This will help save time.

Best Practices ~ Upgrade Run
i. Opt for a proper batchsize and number of workers for AutoPatch during upgrade.
ii. Select the optimum number of workers such that, the below holds true:
• Number of worker should be between 1*No. of CPU and 1.5*No. of CPU
• Average IO response times below 10-15 milliseconds
• Average CPU usage below 100%
iii. Use Oracle Applications Manager (OAM) for patch analysis, download & merging of patches.
iv. For post upgrade patches use Staged Applications System to Reduce Patching Downtime in Oracle E-Business Suite Release 12.
v.  Apply multiple patches in a non-interactive mode.
vi.  Defer database operation of patches and execute once all the patches are applied.
For example, use adpatch options=nocompildb, nocompilejsp

Best Practices ~ Post Upgrade
i. Ensure to reset the following init.ora parameters after completion of R12 upgrade driver:
• recyclebin
• parallel_max_servers
• job_queue_processes
ii. Merge all the NLS patches and apply them as a single merged patch.
iii. Isolate post upgrade concurrent programs in a separate manager queue.