E-Business Suite Release 12

E-Business Suite Release 12
E-Business Suite Release 12.1 Upgrade Best Practices - Technical Insight Udayan Parvate, Director, EBS Release Engineering Uday Moogala, Senior Principle Engineer, Applications Performance

The following is intended to outline our general product direction
The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

Agenda R12.1 Upgrade Overview R12.1 Supported Upgrade Paths
R12.1 Upgrade Resources R12.1 Upgrade Best Practices to Minimize Downtime Reference (Customer Upgrade Snapshots and more) Q&A

R12.1 Upgrade Overview

R12.1 Rapid Install (RI) R12.1 Maintenance Pack (MP)
R12.1 was generally available (GA) in May 2009 Via Oracle Software Delivery Cloud (formerly known as Electronic Product Delivery (EPD)) and Oracle Stores Can be used by new and upgrading customers ( and above) to go directly to R12.1 If you are on R11i, use R12.1 RI from the software delivery cloud. Follow instructions from the “Upgrade Guide: 11i to 12.1” and “ Release notes” If you are on R12.0.X, use R12.1 MP ( ) from My Oracle Support (MOS). Follow instructions from “R12.1 Maintenance Pack Install Instructions ( )” 5

EBS R12.1 Release Update Pack (RUP) 3 (12.1.3) Release
EBS was released in Jul 2010 and delivers bugfixes and targeted functionality enhancements Available from My Oracle Support (MOS) as a patch Can ONLY be applied after upgrade to R12.1 Currently, EBS is the latest RUP available for R12.1 EBS Installation instructions : 6

VERSION CERTIFIED WITH MINIMUM REQUIRED VERSION
R12.1 Technology Stack TECHNOLOGY COMPONENT VERSION INCLUDED 11i10CU2 RI 12.1 RI VERSION CERTIFIED WITH MINIMUM REQUIRED VERSION Apps Mid tier- Forms/Reports - Apps Mid tier- Java Oracle Home/ Apps Mid tier- JDK /1.4.2 /1.5 /1.6.0 /1.6 Database 10gr2: 11gr2: , , 10gr2 : 11gr1 : 11gr2 : For details “Oracle E-Business Suite Release 12.1 Maintenance Pack Installation Instructions” ( )

R12.1 Key Facts 11i10CU2 R RI R12.1 RI RUP #of Product Schemas 209 195 (25 removed,11 added) 201 (25 removed,17 added) No changes #file calls in DB portion of the U driver 104242 144940 156622 23408 PROD db size File system size 31 GB 26 GB 45 GB 28 GB 50 GB NA #files shipped in RI 268359 357778 385755 #of Changed + New files in DB portion of the U driver ~95488 ( Vs ) ~ ( Vs ) ~31843 ( Vs ) ~23474 ( Vs )

R12.1 Supported Upgrade Paths

R12.1 Upgrade Paths Minimum EBS suite level for direct upgrade to R12.1 11i9, 11i9CU1, 11i9CU2 or above 11i10, 11i10CU1, 11i10CU2 or above R12.0 and above Minimum EBS suite level required for database versions requires 11i9CU2 / / / / require 11i10CU2/R12.0.4 Based on R12.1 DB preparation guide ( ), certified upgrade path options can be categorized into : Upgrade database and EBS level in a single downtime Upgrade database and EBS level in separate downtimes Apply upgrade interoperability DB patches and then upgrade EBS 10

R12.1 Upgrade Paths Continued.. 11.0/11i.X => 12.1
TARGET SOURCE 12.1 / < = B ,C 11i10cu2 B ,C 11.0 12.1 B ,C B ,C 11i9cu2 12.1 11.5.9/cu1 /cu1 B ,C A 12.1 A. Upgrade database and EBS level in a single downtime B. Upgrade database and EBS level in separate downtimes C. Apply upgrade interoperability DB patches and then upgrade EBS

R12.1 Upgrade Paths Continued.. 12.0.X => 12.1
TARGET 12.1 SOURCE B ,C B ,C 12.1 / < = A A B ,C > = 12.1 B ,C B ,C 12.1 A. Upgrade database and EBS level in a single downtime B. Upgrade database and EBS level in separate downtimes C. Apply upgrade interoperability DB patches and then upgrade EBS

R12.1 Upgrade Resources

R12.1.3 EBS Data Model Comparison Report
Per product database object comparison between two releases for the following object types ( ) Regular tables, Partitioned tables, Index organized tables, Global temporary tables, Queued tables Views, Materialized views, Materialized view logs Indexes, Sequences, Advanced queues, Packages, Triggers Available for R Vs (11i9,11i10cu2,12.0.4,12.0.6,12.1.1,12.1.2) Benefits Customers can focus on what has changed Easier to analyze impact on customizations, planned test coverage Differences viewable for all products in the same report via simple UI 14

R12.1.3 EBS ATG Seed Data Comparison Report
Per product EBS ATG Seed data type comparison between two releases ( ) BIP-Defns-Temps, RSG-Metadata, Components, Concurrent Programs, Contents Descriptive Flexes, Diagnostics, Functions, Integrators, Key Flexes, Security Rules Layouts, Lookups, Mappings, Menus, Messages, Sequences, Value Sets Parameter Lists, Printer Styles, Profiles, Request Groups, Request Sets, Responsibilities Available for R Vs (11i10cu2,12.0.4,12.0.6, 2.1.1) Benefits Meant for Advanced user with prior knowledge about EBS Seed data delivery Easier for developers/consultants/testing team to analyze impact on customizations, planned/desired test coverage Post Go-live, to answer end-user questions 16

R12.1 Upgrade Best Practices

Upgrade Best Practices
Identification of required patches Prepare a complete list of pre and post patches and recommended code levels Keep the system current on AD/ATG/OAM code e.g. latest AD/ATG RUPs on 11i/R12.0 and once on R12.1 High priority patches from MOS. Consolidated Upgrade Patches (CUP) and required one-offs that need to be applied in pre-install mode. e.g. EBS R12.1 CUP1 ( :12.1.0), FIN upgrade patches from Review “Known-issues” sections from key documents to determine additional pre or post upgrade patches: Release notes, MP Install Instructions Get to the latest code of AD/ATG/OAM as there could have been functional and performance related fixes (take full advantage of new features designed to reduce downtime and simplify maintenance.) . Along with them, identify any critical patches, and consolidated upgrade patches to apply in pre-install mode.

Upgrade Best Practices Continued..
Patch merging, sequencing and adpatch options Use non-interactive patching Merge patches ( ). Merge NLS patches per language. Perform uptime maintenance when possible hot patching of iHelp Install on test system and point production it. Switch back once online help is upgraded online. Saves lot of time NLS patches, upload patch history and HRGLOBAL ( ) Use adpatch options such as nomaintainmrc, phtofile, nolink, nogenform, nogenrep, nocompile jsp, noautoconfig, novalidate ( ) Take advantage of patch merge, hot patching and apply patches in the correct sequence Instead of applying each patch one at time needs interaction with the tool to input driver file name and is time consuming – Merging patches would reduce this time considerably. Eliminates generic processes that are common to all patch applications. Apply multiple patches during one session of ADPATCH using ADMRGPCH. Run AD patch in non-interactive mode. Automatic detection of all driver files in a patch. No need input driver file for a specific patch. Merge multiple applications patches into one or two large patches which can then be run to completion with one command. Don’t merge online help patches and translation patches, and code patches and AD patches. NLS: various options - A single, merged patch that contains all languages (including US) -- requires the longest system downtime . - One merged patch for US and a second merged patch for all other languages -- bring US users back online while you apply the patch for non-US languages. . A separate merged patch for each language -- bring users for various non-US languages back online in a phased approach, which could be useful for multi-national corporations in some situations. . HRGLOBAL legislative data updates. Upload patch history: AutoPatch uploads patch history information to the database automatically each time it successfully applies a patch. The time required for the upload may be substantial depending on the size of the patch. You can defer this task during the AutoPatch session and upload the patch history information while the Oracle E-Business Suite system is in use. adpatch options=phtofile -- AutoPatch writes it to the patch information files: adpatch uploadph=y -- uploads the patch history information to the database and exits.

Downtime reduction procedures Run autoconfig in parallel on a multi-node system ( ) AutoConfig is a tool that supports automated configuration of an Oracle E-Business Suite Release 12 instance. All the information required for configuring an Applications instance is collected into two local repositories, called the Applications context file and the database context file. Applications context file includes: - Name and location of the database - Port numbers for Forms and Web services - Product-specific port numbers - Information about application tier services controlled by AutoConfig etc database context file includes: $ORACLE_HOME/appsutil/template/adxdbctx.tmp DB parameters env variables Driver: fndtmpl.drv - list the names and locations of the files that need to have context variables replaced. When AutoConfig runs on the application tier, it uses information from the Applications context file to generate all configuration files and update database profiles. When AutoConfig runs on the database tier, it uses information from the database context file to generate all configuration files used on the database tier. AutoConfig provides several major benefits, including:

Downtime reduction procedures Use “Shared APPL_TOP” ( ) with “Distributed AD” for ( ) upgrades and regular maintenance for multi-node instances No need to apply the same patch on multiple tiers Distributed AD adds to the degree of parallelism by distributing AD workers across application tier nodes and improves timing for D/G portion of the patch driver. With multiple MT machines/nodes, we run adpatch on every single node, run copy and database drive on one, and for other ones we have to run copy and generate driver. Lot of duplicate effort in copy and generate on each node. In Shared appl_top, APPL_TOP is one machines, and NFS amounted on others or any network storage device…with this we can run adpatch only on one and do copy and generate only once. We can allocate different work to different nodes or same on all (ad_parallel job). In a shared application tier file system, the APPL_TOP, COMMON_TOP, OracleAS Oracle home, and OracleAS Oracle home file systems are installed on a shared disk resource that is mounted on each node in the system. Any changes made to a shared file system environment are immediately available on all nodes. On one of your shared application tier nodes, you start your AutoPatch or AD Administration session, specifying the number of local workers and the total number of workers.

Upgrade Best Practices Continued.. Shared APPL_TOP and Distributed AD
Admin/CM Server Shared APPL_TOP adpatch workers 1-10 adpatch workers 1-10 Forms Server adpatch workers 1-10 adpatch workers 11-20 Web Server adpatch workers 1-10 adpatch workers 21-30 Database Server adpatch workers 31-40 Web Server adpatch workers 1-10 The above reflects Oracle’s current development plans which are subject to change at any time

Upgrade Best Practices Continued.. Staged APPL_TOP
Production 3. Sync APPL_TOP 3. Update DB 1. Clone 4. Sync Patch History 2. Upgrade to R12 Stage 2. Upgrade DB The above reflects Oracle’s current development plans which are subject to change at any time

Downtime reduction procedures Use “Staged APPL_TOP” ( ) for regular maintenance and upgrade Saves time to patch the file system (C/G portion) by using a patched up copy of production instance file system Use in 11i => R12.1 upgrade to avoid applying NLS C/G portion Can use for R12.0.X => R12.1 upgrade and once on R12.1 Staged appl_top: Create R11i staged system - a clone of your Production database and of each APPL_TOP of your Production Applications system. Upgrade the Staged system from Release 11i system to Release R12 Update the Production APPL_TOP - Copy APPL_TOP and application tier files from the Staged system to Production - generate a new context file for the Production instance ($COMMON_TOP/clone/bin/adclonectx.pl) - Regenerate the environment files by running AutoConfig, using the new context file on the new Production system - Update the Production Database Apply DB portion of all the patches Synchronize the Patch Histories

Downtime reduction procedures continued.. Use TUMS (“The Upgrade Manual Script”) To avoid running tasks not relevant to your system Import statistics Export statistics gathered during test runs, and import during final run Automate as much as possible Time every activity and deal with bottlenecks

Downtime reduction procedures continued.. For the duration of the upgrade, consider… Disabling custom triggers and business events Disabling auditing if enabled If possible run in noarchivelog mode Disabling flashback DB Removing TDE from volume tables

Pre-upgrade activities Identify and execute tasks that could be completed in a separate downtime period, prior to the production upgrade Use applicable steps mentioned in the "Downtime reduction" and “Upgrade By Request” appendices E and G of the R12.1 upgrade guide Upgrade RDBMS version to latest certified for the current APPS level ( / / ) Convert to Oracle Applications Tablespace Model (OATM) Compacts data, optimizes storage settings and I/O Other planned HW or OS upgrades There are several actions you can take to reduce this downtime period. For example, - performing certain product-specific tasks before an upgrade can substantially reduce the downtime, - can using the Oracle cloning methodology, - and a test file system to upgrade your production system.

Pre-upgrade activities continued... Convert to Multiple Organization architecture (Document ) Drop MRC schema ( and above ) Assign post upgrade jobs to specialized CM queue (by request_type, see Document ) The Upgrade Manual Script (TUMS) 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. MRC (Multiple Reporting Currencies) Replaced by Reporting Currencies in Subledger Accounting (XLA) – one central location for ALL EBS products

Pre-upgrade activities continued... Flush all the interfaces, such as Autoinvoice, Journal entry import, order import etc.. Review and disable all debug, logging at site, responsibility, user level Gather stats with GATHER_AUTO option for all schemas close to the start of downtime

Pre-upgrade activities continued... Pre-create new large indexes created by upgrade constrained to indexes on existing columns Minimize historical data to be upgraded as per business requirements – “Upgrade By Request” Post-upgrade “hot-patch” of additional historical data outlined in Purge old and/or transient data before upgrading Over 260 standard purge programs in R12 Use new “Purge Portal” in OAM to administrate Pre-create indexes could be little tricky as they could impact execution plans, but hopefully positively. So, far we did not get –ve feedback

Purging Use OAM to configure, initiate and monitor purge programs Set the execution frequency and view program history Programs tagged with the “Purge” program type System Administrator >Oracle Applications Manager >Purging/Critical Activities

Key recommended fixes Affecting Upgrade Performance AD-Parallel improved scalability: (Part of AD CUP) Forms/reports generation regression with 11g: Optimizer:Dynamic Sampling on indexes ( ) General Review for latest EBS recommended performance fixes

Database tier configuration Maximize SGA and PGA sizing An upgrade only involves 10's of concurrent sessions; starting rules of thumb ... log buffer = 30 to 100 Mb shared pool = 1 to 4 Gb pga target = 3 to 20 Gb buffer cache = multi Gb, be generous without causing excessive paging or swapping Adjust with help from AWR pool advisories

Database tier configuration Other upgrade specific init.ora changes If specified, remove db_file_multiblock_read_count Maximize multiblock I/O sizes Set job_queue_processes = # of CPUS adobjcmp.sql (Phases : plb+90 and last+63) Set parallel_max_servers = 2 X CPUs Helps with large index creation, stats gathering and some large upg+ phase jobs Need to test with production-like DB server and I/O subsystem Shutdown other RAC instances

Batch size and #workers Batch size 10K is suitable for most installs, you can test other values from 1K up to 100K if time allows # Workers Starting rule-of-thumb is between 1 and 1.5 x #COREs It is critical to do multiple rounds of testing, adjusting above settings to maximize server utilization, but constrained by factors such as Memory utilization (no swapping/ excessive paging) CPU utilization (scale down if at 100%) I/O response times (scale down if averages > 20 ms)

Performance testing, monitoring and additional optimizations... Analyze long runners via timing report, ad_task_timing analysis Mine ad_task_timing to identify low worker utilization due to phasing waits and review responsible culprits Review targeted AWR Instance and SQL reports awrrpt.sql and awrsqrpt.sql Use My Oracle Support to check for known issues and workarounds for the longest running jobs

Performance testing, monitoring and additional optimizations continued... Outside-the-box optimizations – Requires Support Approval* Long running index creation and Statistics gathering As these tasks run with little or no concurrent tasks, consider using alter system commands to increase parallel_max_servers and pga_aggregate_target (Need to test so as to not exhaust machine resources) Large indexes: Pre-create, but do not alter column definitions For stats (adsstats.sql ; phase: last+63) : Consider stats import or on RAC using all nodes when gathering stat

Performance testing, monitoring and additional optimizations continued... Outside-the-box optimizations – Requires Support Approval* Long running mv related xdf’s (“en” phases) Cleanup and truncate large MV logs (requires MV complete refresh) Look more closely at long running jobs that you suspect may not be required for your system Thousands of jobs and customer product/data/setup configurations Some of the heavy lifting work may not be required for a specific site Check with Oracle Support to validate A fix maybe available or possible to optimize for your case New AD timing report by module

Appendix Customer Upgrade Snapshots

Customer Upgrade Snapshots Continued... 11i to 12.1.3
Toyota Motor Europe Release: on IBM AIX to R on Oracle Linux 5 Appl tier DB size: 800 GB #Workers: 32 #CPUs on DB server: 8 cores Downtime reduction measures Online NLS patch application #hrs for the D driver: 21 hrs #hrs for the US upgrade: 4 hrs #hrs for the 4 languages NLS patching 11 hrs

Customer Upgrade Snapshots 11i to 12.1
CPS (Chicago Public Schools) Release: to 12.1 DB size: 900GB #Workers and batch size: 32, 10000 #CPUs on DB server: 2 node RAC, 8 CPUs per node Downtime reduction measures Distributed AD Upgrade RDBMS to in a separate downtime # hrs for the D driver: 22 hrs Customer snapshot

Cisco Release: 11i to R12.0.6 DB size: 600GB #Workers and batch size: 32, 20000 #CPUs on DB server: 16 Downtime reduction measures Distributed AD #hrs for the D driver: 5.5 hrs

Dell Release: 11i10 to R12.1.3 DB size: 15TB , 16 node RAC Cluster #Workers and batch size: 32, 10000 #CPUs on DB server: 8 Downtime reduction measures Distributed AD Pre-create large indexes #hrs for the D driver: ~30 hrs

Customer Upgrade Snapshots Continued... 11i to 12.1
GE Large EBS HRMS Implementation (~300K employees,10 Lang) Release: to R12.1.3 DB size: 838 G Hardware: App Tier- 2 SUN T5240’s(64x64), DB Tier - SUN M8000 (12 Dual Cores) #Workers and batch size per App Server: 48, 10000 Downtime reduction measures Distributed AD, Staged APPL_TOP #hrs for D driver:~10 hrs US, ~13 hrs NLS ( > R12.1.1) #hrs for DB Portion:~2.5 hrs US, ~1 hr NLS (R > R12.1.3)

Customer Upgrade Snapshots Continued... 12.0 to 12.1
Zebra Technologies Corporation Release: to 12.1 DB Size: 106GB #Workers and batch size: 32, 10000 #CPUs on DB server: 8 Downtime reduction measures Staged APPL_TOP #hrs for the U driver: 12 hrs Customer snapshot

Customer Upgrade Snapshots Continued... 12.0 to 12.1
Oracle GSI Release: to R12.1 DB size: 17TB #Workers and batch size: 60, 10000 #CPUs on DB server: 88 processors Downtime reduction measures Staged APPL_TOP for US and ten languages Ran data fixes for problems found in test upgrades prior to production upgrade to minimize stoppages Distributed AD (4 servers,15 workers each) Pre-create large indexes (6 hrs savings) #hrs for the D driver: 14 hrs

Customer Upgrade Snapshots Continued... 12.1 to 12.1.3
Oracle GSI Release: to R12.1.3 DB size: 17TB #Workers and batch size: 200, 10000 #CPUs on DB server: 150 processors Downtime reduction measures Staged APPL_TOP for US and ten languages Ran data fixes for problems found in test upgrades prior to production upgrade to minimize stoppages Distributed AD (4 servers, 50 workers each) Pre-create large indexes #hrs for the D driver: 4 hrs

Customer Upgrade Snapshots Continued... 12.0 to 12.1.2
AT&T Release: to R12.1.2 DB size: 10 TB #Workers and batch size: 40, 10000 #CPUs on DB server: 32 Processors Downtime reduction measures Staged APPL_TOP for US and ten languages Distributed AD #hrs for the D driver: 9 hrs

References

References R12.1 documentation roadmap (790942.1)
Oracle E-Business Suite Release 12.1 Info center ( ) Database preparation guidelines for R12.1 upgrade ( ) Patching FAQs ( , ) Using staged or shared APPL_TOP and distributed AD ( , , ) OAM “Patch Wizard” overview and FAQ ( , ) AD Command Line Options for Release R12 ( ) EBS Data Model Comparison Report ( ) EBS ATG Seed Data Comparison Report ( ) Recommended Performance Fixes ( ) R12 Upgrade Sizing & Best Practices ( )

Additional Resources

Additional Resources White papers Have upgrade questions ?
Planning Your Oracle E-Business Suite Upgrade from Release 11i to Release 12.1 ( ) R12 Upgrade considerations by product: Financials ( ) Oracle E-Business Suite Upgrades and Platform Migration ( ) Have upgrade questions ? Post on OTN R12 upgrade forum New!

E-Business Suite Release 12

Similar presentations

Presentation on theme: "E-Business Suite Release 12"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

E-Business Suite Release 12

Similar presentations

Presentation on theme: "E-Business Suite Release 12"— Presentation transcript:

Similar presentations

About project

Feedback