Thursday Jul 22, 2010

EBS Sysadmin Primer: Oracle Identity Management 11gR1

[Editor: This is the third in a multi-part series from Nirzari Raichura, a senior member of our ATG Certification team, on essential Fusion Middleware concepts and tools for the EBS sysadmin]

Oracle Identity Management (OIM) 11gR1 is part of Fusion Middleware 11gR1.   Oracle Identity Management 11gR1 provides the following components as part of its default installation:
Oracle Directory Services Components
  • OID - Oracle Internet Directory
  • DIP -  Oracle Directory Integration Platform
  • OVD - Oracle Virtual Directory
Oracle Identity Federation Components
  • OIF - Oracle Identity Federation
Management Components
  • EM - Enterprise Manager
  • ODSM - Oracle Directory Service Manager

oim_architecture.png
In order to use Oracle Identity Management 11gR1 with E-Business suite, you need OID and DIP products at a minimum.  Oracle Identity Management 11gR1 doesn't contain Oracle Single Sign-on.  You have the choice of either of the following two tools for for authentication: 
  • Oracle Single Sign-On 10gR3
  • Oracle Access Manager 10gR3

Oracle Access Manager 10gR3 is the preferred authentication solution going forward.  However, if you have plans to integrate any other products like Oracle Portal, Forms, Reports or Discoverer with E-Business Suite, you must select the Oracle Single Sign-On 10gR3 option. These products have hard dependencies on Oracle Single Sign-On 10gR3 and cannot be authenticated directly by Oracle Access Manager (you can do so indirectly, but that's a topic for a future article).

If you have already integrated your E-Business Suite environment with Oracle Single Sign-On and Oracle Internet Director 10gR3, you can upgrade Oracle Internet Directory 10gR3 to Oracle Internet Directory 11gR1 (which is part of Oracle Identity Management 11gR1). Your existing integration remains intact after the upgrade.


Oracle Identity Management 11gR1 Integration with E-Business Suite using OSSO 10gR3

Unlike Oracle Internet Directory 10g, which is tightly integrated with with Oracle Application Server 10g and and the Oracle database (to store its metadata repository), Oracle Identity Management 11gR1 provides various integration options. 

There is an option to manage it through the Oracle Fusion Middleware management framework by registering it with a local or a remote WebLogic Server administration domain.  You can do this during installation or via the command-line after installation. As I mentioned in my previous blog article, you can also install and configure it without WebLogic Server. In that case, you can manage Oracle Internet Directory using command-line tools and ODSM.

This table describes the components required for Oracle Identity management 11gR1 installation:

fmw_table.png
Useful Tools to administer and manage OIM 11gR1

OIM11gR1

Tool

Default Value

Oracle Enterprise Manager Fusion Middleware Control

http://host:port/em

Oracle Directory Services Manager (ODSM)

http://host:port/odsm

Oracle WebLogic Server Administrative Console

http://host:port/console/

Command-Line Utilities

OPMN

$ORACLE_INSTANCE/bin/opmnctl

Standard LDAP utilities

ORACLE_HOME/ldap

OIDPASSWD

WebLogic Scripting Tool (wlst)

ORACLE_HOME/common/bin/wlst.sh

OIDCTL For backward compatibility

References

Related Articles

Tuesday Jun 29, 2010

An Oracle Fusion Middleware 11g Primer for EBS Sysadmins

Oracle E-Business Suite Release 11i runs Oracle9i Application Server 1.0.2.2.2 as its internal application tier.  Oracle E-Business Suite Release 12 runs Oracle Application Server 10g.  Both EBS 11i and 12 can optionally be integrated with externally-deployed Fusion Middleware 11g components such as Oracle Internet Directory, Discoverer, Portal, Oracle Business Intelligence Enterprise Edition, and others.

Oracle Fusion Middleware 11g is Oracle's latest suite of related and interoperable application tier server products.  Some Fusion Middleware products have dependencies on other Fusion Middleware products.  As an E-Business Suite DBA or systems administrator, it is essential that you have a good conceptual understanding of Fusion Middleware 11g concepts before jumping into administration or installation tasks. 


Fusion Middleware 11g overview diagram showing development tools identity management oem bi and other components

This information is covered in the Fusion Middleware 11g guides themselves, of course, but it's spread across many different documents.  This is the first in a series of articles in which I'll cover the essential concepts that E-Business Suite sysadmins need to know about Oracle WebLogic Server, Webcenter, Oracle Internet Directory, Portal, and Discoverer.  These concepts are important for Fusion Middleware architectural design, installation, administration, integration, configuration and troubleshooting.

Key Fusion Middleware 11g Concepts

Oracle WebLogic server (WLS) is the application server for Oracle Fusion Middleware 11g.  Most Fusion Middleware components require WLS, with notable exceptions being Oracle Internet Directory (OID) and Oracle Virtual Directory (OVD). Oracle Internet Directory and Oracle Virtual Directory can be configured with or without a WebLogic domain.

Fusion Middleware components are divided into two types:

  • Java Components:  Deployed as one or more Java applications and a set of resources.  Examples: Oracle SOA Suite, Oracle WebCenter. 
  • System Components:  A manageable process that is not deployed as a Java application.  System components are managed by Oracle Process Manager and Notification (OPMN).  Examples: Oracle Internet Directory, Oracle Virtual Directory, Oracle HTTP Server, Discoverer, Forms & Reports.

What's in a typical Fusion Middleware environment?

A typical Fusion Middleware environment includes the following:

  1. Fusion Middleware Home (MW_HOME)
  2. Oracle WebLogic Server Home (WLS_HOME)
  3. ORACLE_HOME 
  4. ORACLE_INSTANCE

1.  Fusion Middleware Home (MW_HOME)

  • A top level directory for all Fusion Middleware products installed on same machine, including WebLogic Server..
  • Created at time of WebLogic Server installation.
  • Serves as a repository for common files used by multiple Fusion Middleware products installed on the same machine.

TIP:  Do not include spaces in the name of your Middleware home directory. If the name of this directory contains spaces, the CLASSPATH may not be resolved properly. 

2.  WebLogic Server Home (WLS_HOME)

  • A WebLogic Server home containing binary files necessary to host a WebLogic Server.
  • Created under Fusion Middleware Home at time of WebLogic Server installation.
  • Contains mostly 'read only' files until either patched or upgraded

TIP:  You can install only one instance of each version of a WebLogic Server product in a single Middleware Home directory.

3.  ORACLE_HOME

  • Contains installed files necessary to host a specific product. For example, the WebCenter Oracle home contains a directory that contains binary and library
    files for Oracle WebCenter.
  • Can be created before product install, but if not, will be automatically created by the installer. It must reside under Middleware Home directory.
  • Contains mostly 'read only' files until either patched or upgraded
  • Each ORACLE_HOME can be associated with multiple Oracle instances or Oracle WebLogic Server domains 

4.  ORACLE_INSTANCE

  • Contains modifiable files such as configuration files, log files, and temporary files for one or more system components.
  • System components in an Oracle instance must reside on the same server.
TIP:  You can install this anywhere on the same server; it need not be within the Middleware home directory.

Key Oracle WebLogic Server Concepts

To manage an Oracle WebLogic Server instance, you need to understand the following concepts:

  1. WLS Domains
  2. Administration Server
  3. Managed Server
  4. Default Domain Directory
  5. Farm

WLS Domain

  • A group of logically related Oracle WebLogic Server resources and services.
  • You can use a single Oracle WebLogic Server installation to create and run multiple domains, or you can use multiple installations to run a single domain.

Administration Server

  • A special Oracle WebLogic Server instance which is the central point from which configuration and management of all resources in the domain occur.
  • Each Oracle WebLogic Server domain must have one server instance that acts as the Administration Server.
  • Can be used to deploy other components, but it is not recommended 

Managed Server

  • To deploy additional Fusion Middleware products such as SOA Suite, WebCenter, or Oracle Internet Directory, you usually should configure an additional domain instance: a Managed Server
  • You can configure this domain either during or after product install.
  • You can configure separate domains for different Fusion Middleware components.  Example: one domain for SOA Suite, one for WebCenter, and one for Oracle Internet Directory.  Alternately, you can have a single domain for multiple components; depending on your requirements
  • You can configure managed servers as clustered and non-clustered
  • In a cluster, most resources and services are deployed identically on each Managed Server instance and are running simultaneously and working together
  • All Managed Servers in a cluster must reside in the same domain; you cannot split a cluster over multiple domains
  • The key difference between clustered and non-clustered Managed Servers is support for failover and load balancing

Default Domain Directory

  • By default, Oracle WebLogic Server creates domain directories under the MW_HOME/WLS_HOME/user_projects/domains directory
  • It can reside anywhere; it need not be within the Middleware home directory.
  • A domain is a peer of an Oracle instance. Both contain specific configurations outside of their Oracle homes 

Farm

  • A collection of components managed by Fusion Middleware Control.
  • Can contain Oracle WebLogic Server domains, one Administration Server, one or more Managed Servers, and the Oracle Fusion Middleware components that are installed, configured, and running in the domain.

Coming up next in this series:  EBS Sysadmin Primer: Oracle Fusion Middleware 11g Management Tools.

References

Related Articles


Friday May 28, 2010

New Whitepaper: Advanced Compression 11gR1 Benchmarks with EBS 12

[June 23, 2010 Update:  Our Server Technologies team has just released Note 1061366.1 that lists recommended Advanced Compression patches applicable to all customers, including E-Business Suite environments]

In my opinion, if there's any reason to upgrade an E-Business Suite environment to the 11gR1 or 11gR2 database, it's the Advanced Compression database option.  Oracle Advanced Compression was introduced in Oracle Database 11g, and allows you to compress structured data (numbers, characters) as well as unstructured data (documents, spreadsheets, XML and other files).  It provides enhanced compression for database backups and also includes network compression for faster synchronization with standby databases.

advanced-compression-tables.png
In other words, the promise of Advanced Compression is that it can make your E-Business Suite database smaller and faster.  But how well does it actually deliver on that promise?

Apps 12 + Advanced Compression Benchmarks now available


Three of my colleagues, Uday Moogala, Lester Gutierrez, and Andy Tremayne, have been benchmarking Oracle E-Business Suite Release 12 with Advanced Compression 11gR1.  They've just released a detailed whitepaper with their benchmarking results and recommendations.

This whitepaper is available in two locations:
Vision Database:  Up to 68% compression and up to 36% improved performance

The results, even with our EBS Vision demonstration database, were impressive:
  • Reduced 21.9 GB of tables down to 6.9 GB (68% reduction, average 3:1 compression ratio)
  • Self-service performance improved up to 36%
  • Purchasing performance improved up to 10%
  • Order-to-Cash batch flow performance improved up to 33%
  • Payroll performance improved up to 25%
They also found some other interesting effects:
  • Some SQL execution plans changed, reducing performance
  • Performance was improved at the cost of up to 6% increased CPU usage, with the variance depending upon how much DML is performed
  • In the case of the Order-to-Cash batch flow, the average CPU consumption actually decreased by 7%
Line chart showing order to cash batch flow cpu usage for Oracle 
E-Business Suite Release 12 and advanced compression

Oracle using this in production with EBS 12 today

We can now share the news that we've been using Advanced Compression in our Oracle Global Single Instance (GSI) production environment since 2009.  This same team has been working to analyse the results of using Advanced Compression with our Oracle E-Business Suite Release 12 global single instance that we use to run Oracle's own business. 

The results there are very impressive:
  • Reduced EBS 12 database size from 17 Terabytes to 13 Terabytes
  • Compressed ~260 tables and over 700 associated indices and LOBs after migrating to SecureFiles
  • Total space saved: 68 TB across our primary, standby, and associated testbeds
Other E-Business Suite-specific observations about Advanced Compression

This whitepaper makes detailed E-Business Suite-specific observations in the following areas:
  1. Index compression
  2. Recommended patches
  3. SQL Plan regression analysis
  4. DML intensive operations
  5. Row chaining on UPDATE transactions
  6. ITL contention
  7. High transaction tables
  8. SecureFiles LOB compression
The whitepaper concludes with specific recommendations on planning your Advanced Compression conversion in your E-Business Suite environment, and then lists all of the tables compressed in the Vision testbed as well as Oracle's own EBS 12 production instance.

Have you used Advanced Compression with EBS?

Naturally, compression ratios and performance impacts or benefits will vary for every Apps environment.  If you've used this technology, we're very interested in hearing about your experiences with Advanced Compression in your environment.  You're invited to share your experiences here or drop me an email directly.

Related Articles

Tuesday May 11, 2010

EBS + 11g Database Upgrade Best Practices Whitepaper Available

O_Database11g_clr.gif
I returned from OAUG/Collaborate with a cold and multiple overlapping development crises.  Fun.  Now that those are (mostly) out of the way, it's time to get back to clearing out my article backlog. 

Premier Support for the 10gR2 database ends in July 2010.  If you haven't already started planning your 11g database upgrade, we recommend that you start soon.  We have certified both the 11gR1 (11.1.0.7) and 11gR2 (11.2.0.1) databases with Oracle E-Business Suite; see this blog's Certification summary to links to articles with the details.

Our Applications Performance Group has reminded me that they have a whitepaper loaded with practical tips intended to make your 11g database upgrade easier.  No vacuous marketing rhetoric here -- this is strictly written for DBAs.  A must-read if you haven't already upgraded to either 11gR1 or 11gR2, and highly recommended even if you have. 

You can download this whitepaper here:
This whitepaper covers:
  • Pre-upgrade tips
    • Gather dictionary statistics
    • Manage CBO statistics
    • Gather performance metrics
    • Save execution plans
    • Test (including capturing and replaying workloads)
  • Post-upgrade tips
    • init.ora parameters
    • Gather statistics
    • Disable automatic optimizer statistics collection
    • Plan stability using SQL Plan Management (SPM)
    • Detect and tune performance changes using SQL Performance Analyzer (SPA)
    • Real-time SQL monitoring
    • Incident packaging service
  • New 11g Performance-related features
    • Optimizer enhancements
    • Partitioning enhancements
    • Advanced Compression
  • Fixes and workarounds for known issues
    • Mandatory patches
    • Options fixes and workarounds
E-Business Suite Benchmarks Also Available

The Applications Performance Group is also responsible for our Oracle Applications Standard Benchmark (OASB), a standard workload that tests the performance and scalability of Oracle Applications and provides metrics for the comparison of Oracle Applications performance on different system configurations.  Copies of independently-audited E-Business Suite benchmarks for both Oracle E-Business Suite Release 11i and 12 are available here:
Related Articles

Friday Apr 16, 2010

The Scoop: Oracle E-Business Suite Support on 64-bit Linux

Linux tux-large.jpg
This article addresses frequently asked questions about Oracle E-Business Suite (EBS) 64-bit Linux support.

Q:  Which 64-bit Linux OSs are supported for EBS?

A: Beginning with Release 12, we support the following 64-bit operating systems for both application and database tiers on x86-64 servers:

  • Oracle Enterprise Linux
  • Red Hat Enterprise Linux
  • SUSE Linux Enterprise Server
For EBS Release 11i (and again in Release 12), when the application tier is installed on a certified platform, additional platforms (including the above) may be used for a 64-bit database tier on x86-64 servers. This is an example of a mixed platform architecture (Release 12), or a Split Configuration (Release 11i).

Q:  I understand that the EBS application tier code is 32-bit, even for the 64-bit Linux OS -- is this the case?
A: It is true that the majority of executables provided as part of our release media on the application tier are 32-bit (as are the Fusion Middleware libraries and objects they depend on).  However, the 'Planning' products have large memory requirements and therefore are 64-bit compiled to take advantage of the larger memory space afforded by the 64-bit OS'es.

Q:  How do I install EBS on 64-bit Linux?
A:  For new installations of EBS Release 12 on supported 64-bit Linux operating systems, you can use Rapid Install as directed in "Oracle Applications Installation Guide: Using Rapid Install" to install the database and application tiers.

For Database Tier Only platforms in a mixed platform architecture, you can use Rapid Install as directed in "Oracle Applications Installation Guide: Using Rapid Install" to install the database and application tiers on supported platforms, and then migrate the database tier to a certified 64-bit operating system.

Q:  How do I migrate EBS Release 12 from 32-bit Linux to 64-bit Linux?

A:  Please refer to Migrating Oracle E-Business Suite R12 from Linux 32-bit to Linux 64-bit (Note 471566.1) for instructions on how to migrate EBS from 32-bit to 64-bit Linux.

Q:  How do I migrate an existing EBS database to 64-bit Linux?

A:  To migrate an EBS database to a certified 64-bit Linux operating system on x86-64, refer to one of the following documents:

For EBS Release 11i:

For EBS Release 12:
Q:  How do I migrate EBS Release 12 on a non-Linux platform to 64-bit Linux?
A:  There is no documentation that covers the direct migration from a Windows or UNIX application tier directly to 64-bit Linux.  However, the document Application Tier Platform Migration with Oracle E-Business Suite Release 12 (Note 438086.1) contains instructions for migrating to 32-bit Linux, and Migrating Oracle E-Business Suite R12 from Linux 32-bit to Linux 64-bit (Note 471566.1) contains the additional steps to configure your environment for 64-bit Linux.  Pondering this question just now gave me the idea to write a new white paper, which will presumably eliminate several steps from either document and insure a smooth migration process.  Stay tuned to this space for more information on this upcoming paper.

Q:  How do I patch EBS on Linux 64-bit?

A: The EBS 32-bit Linux application tier patches are applicable for 64-bit Linux OSes as well.  From the Oracle support portal, you can do a search by patch number to bring up the 32-bit patch.  Note that if you click on the informational icon to the left of the Platform pulldown menu for this patch, it brings up a page stating:

For Oracle Applications Release 12 on Linux x86-64, queries will return a Linux x86 patch. This patch may be applied to both 32-bit and 64-bit operating systems.

Q:  What are the benefits of running EBS Release 12 on 64-bit Linux?

A: Theoretically, 64 bit architectures allow for "2 to the 64th power" bytes or 16 exabytes of RAM, and while individual operating systems and hardware architectures impose constraints (for instance, the maximum RAM is 1 terabyte on x86-64), you are unlikely to hit this memory limit with today's applications. 

For 32-bit compiled code, even though the process address space is limited to approximately 3 GB (even on the 64-bit OS), with overall addressable space up to 1 terabyte you'll be able to run many more processes.  This is an excellent model all around for larger customers wanting to consolidate their hardware or scale up.

Q:  Can we (or why can't we) run EBS Release 11i on 64-bit Linux?

A:   We support the use of 64-bit Linux OS'es in the EBS database tier in a 'split configuration' or 'database tier only' configuration for 11i, wherein the application tier can be on any certified EBS platform and the database tier can run additional database certified platforms (like 64-bit Linux).  Customers wanting headroom for the RAM-intensive DB processes can run their database tier on Linux 64-bit (in a split tier configuration), and if needed spread the application tiers (CM, Forms, Web) across multiple middle tier machines to distribute the load amongst the 32-bit OS'es.

As to why we do not support EBS Release 11i on 64-bit Linux, there are several reasons:  a)  it doesn't "just run";  b) there is no third party support; c) given the costs, we chose to chose to focus our resources on EBS Release 12 and beyond.  Let me explain.

Contrary to what you might think, you cannot necessarily run 32-bit code on 64-bit Linux without a bit of tweaking.  On the technical front, you would need to install the 32-bit OS libraries and deal with potential conflicts between 32-bit and 64-bit OS packages, including file overwrites.  Note that when we introduced 64-bit OS support in EBS Release 12 we made changes to all of the product makefiles, carefully analyzed and laid out both the 32-bit and 64-bit package dependencies, modified installation, configuration and cloning software for OS recognition and proper file locations, and conducted extensive testing.  Each new release requires this process to be repeated, and each new release package requires an independent packaging effort.

In addition, for 64-bit Linux support we've established a 64-bit infrastructure across Oracle teams (in support, engineering, release, QA and certification teams).  This infrastructure investment was made for EBS Release 12 and higher.

Also note that EBS Release 11i has an aging technology infrastructure, and neither Oracle nor third party tool versions used in EBS Release 11i are explicitly supported on the 64-bit operating system in 32-bit mode.

Call us old-fashioned if you will, but given these limitations, because of our support commitment to you and what's behind that commitment we will only support EBS Release 12 forward on 64-bit Linux.

References
Related Articles

Tuesday Apr 06, 2010

How Does AutoPatch Handle Shared E-Business Suite Products?

Space... is big. Really big. You just won't believe how vastly hugely mindbogglingly big it is.
~ Douglas Adams

Douglas Adams could have been talking about the E-Business Suite.  Depending upon whom you ask (and how you count them), there are between 200 to 240 products in Oracle E-Business Suite. 

The products that make up Oracle E-Business Suite are tightly integrated. Some of these products are known as shared or dependent products. Installed and registered automatically by Rapid Install, such products depend on components from other products for full functionality.

For example:
  • General Ledger (GL) depends on Application Object Library (FND) and Oracle Receivables (AR)
  • Inventory (INV) depends on FND and GL
  • Receivables (AR) depends on FND, INV, and GL
It can sometimes be challenging to craft a patching strategy for these types of product dependencies.  To help you with that, our Applications Database (AD) team has recently published a new document that describes the actions AutoPatch takes with shared Oracle E-Business Suite products:
screenshot-adpatch-timing.png
This document complements the respective Oracle Applications Maintenance Utilities guides for both Apps 11i and 12 with additional information about:
  • Product dependencies and AutoPatch actions
  • File driver files
  • Installed products
  • Shared products
References
Related Articles

Friday Mar 12, 2010

New Whitepaper: Planning Your E-Business Suite Upgrade from Release 11i to 12.1 (Second Edition)

[Editor:  This guest article has been contributed by Anne Carlson]

Premier Support for Oracle E-Business Suite Release 11i ends in November 2010.  At Oracle OpenWorld last fall, it was standing room only at several EBS upgrade sessions.  Responding to the increased interest in upgrades, I set to work on a new Release 12.1 version of our popular whitepaper, Best Practices for Adopting E-Business Suite, Release 12 (Note 580299.1).

Here is that new whitepaper, which features the latest Release 12.1 upgrade planning advice from Oracle's Support, Consulting, Development and IT organizations:
The paper is directed at IT professionals who are planning, managing, or running a Release 12.1 upgrade project.  After briefly reviewing the Release 12.1 value proposition, the 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
  • Leverage all of the Oracle Support resources 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
To suggest other upgrade planning topics that you would like to see addressed, please leave a comment or send an email to:

anne_carlson_email.png


Related Articles

Thursday Mar 11, 2010

A Primer on Migrating Oracle Applications to a New Platform

maapaper.png
In Support we field a lot of questions about the migration of Oracle Applications to different platforms.  This article describes the techniques available for migrating an Oracle Applications environment to a new platform and discusses some of the common questions that arise during migration.  This subject has been frequently discussed in previous blog articles but there still seems to be a gap regarding the type of questions we are frequently asked in Service Requests.

Some of the questions we see are quite abstract. Customers simply want to get a grip on understanding how they approach a migration. Others want to know if a particular architecture is viable. Other customers ask about mixing different platforms within a single Oracle Applications environment.   

Just to clarify, throughout this article, the term 'platform' refers specifically to operating systems and not to the underlying hardware. For a clear definition of 'platform' in the context of Oracle Applications Support then Terri's very timely article:
The migration process is very similar for both 11i and R12 so this article only mentions specific differences where relevant.

1. Why Have a Migration Process at All?

Some customers have asked why there is a migration process at all. Surely they say it would be easier just to perform a fresh install of the E-Business Suite on the target environment and then perform an export/import of the database.

The above process is reliant on the fresh install you perform exactly matching the patching levels and technology stack levels of the environment you are migrating from. The database contains tables with information regarding files in your APPL_TOP. If you mix a fresh application tier install with an already established database, there will be a mismatch between these tables and the objects they describe. This will cause problems during later patching. The same issue applies regarding Java objects in the database and the files contained in the JAVA_TOP. For these reasons, you should never consider mixing an application tier with an unmatched database tier.

Although the migration process may appear quite time consuming and linear, much of it can be done in advance. With careful planning, your production environment downtime can be limited to little more than the time it takes to export and import the database and the time taken to apply several key patches. The majority of the application tier migration can be done in advance whilst your production environment is still up and available for updating by users.

2. Migrating the Database Tier to a New Platform

If you plan to migrate both the application and database tier to a new platform, the flow of the documentation will follow more logically if you migrate the database tier before the application tier however there's no particular reason why you should not migrate the application tier first.
Tip:  If migrating the database tier first, make sure the source application tier is updated to connect to the migrated database tier before migrating the application tier. This is because the application tier migration process is only updating the application tier configuration, and assumes the database connection values are the same as source. 
There are several different ways to migrate the database tier. Using the basic export/import tool was the only way up until the release of 10g. With 10gR1 came the introduction of the datapump utility which looks similar to export/import but with useful enhancements and improved performance.

With 10gR2 came the introduction of cross-platform transportable tablespaces and transportable databases. At time of writing, transportable database functionality is certified for use with Oracle Applications for Release 11i and for Release 12Cross-platform transportable tablespace (XTTS) is still currently part of an Early Adopter Program (EAP). Version 11g of the database supports both datapump and transportable database migrations.

Using transportable database as a means to migrate your database is dependent on both platforms having the same "endian" format. The following SQL query run on your source database will tell you if your target platform is compatible.
SQL> select platform_name from v$db_transportable_platform;
Transportable database uses the Recovery Manager (RMAN) Convert Database functionality to migrate the database to the new platform. It's not supported to use RMAN outside documentation written specifically for Oracle Applications to perform your database migration.

One rule that applies to all the above migration methods is that only complete database migrations are supported. It is not supported to perform partial database migrations or complete migrations by using a "schema by schema" approach.

If using export/import, there are some parameters that are not used in the default parameter file supplied such as named pipes and direct=y. This generally means they are untested in the Oracle Applications environment and, although they may work, you should generally be wary of using parameters that are not specifically documented as being Oracle Applications friendly.

If migrating from a 32-bit platform/database to-64 bit, then assuming you install a 64 bit Oracle home on your target environment, the conversion to a 64 bit database is done automatically. No additional conversion is required to enable 64 bit functionality. Similarly, if you are migrating a 64 bit database to a 32 bit platform the downward conversion is performed implicitly.

You should also remember that it is generally only possible to migrate Oracle Applications databases of the same versions. There are only very limited circumstances where you can upgrade the database as part of the migration. Version compatibilities are discussed at the start of each database migration Note. 

It's inevitable with Applications databases that export files are going to be large. Datapump supports the ESTIMATE_ONLY parameter that can be used at the command line to estimate the size of the datapump export files that will be generated.

3. Migrating the Application Tier to a New Platform

The main notes to follow are:
These notes explain how to migrate the Apps application tier to a new platform. The 11i note can be used to migrate to all supported Unix and Linux platforms, not just Linux. However, these Notes cannot be used to migrate the application tier to a Windows platform.

The first section of the Notes covers the prerequisite requirements of the migration. This migration method requires AutoConfig and Rapid Clone.

The final step in Section 1 requires you to run Maintain Snapshot in adadmin. This must be run, and it must run successfully. Snapshot information is stored in the following tables:
  • AD_SNAPSHOTS
  • AD_SNAPSHOT_FILES
  • AD_SNAPSHOT_BUGFIXES
The migration requires you to create a manifest of your application tier file system based on the Snapshot taken in the preceding step. This manifest is then uploaded to My Oracle Support and is used to generate a custom migration patch. The custom migration patch created is specific to your upgrade only and contains all the files contained in the APPL_TOP that are binary specific to your new target platform. This patch is therefore applied in your new environment.

When performing the application tier migration, you are required to install a new application tier technology stack. These are the Developer and Application Server Oracle homes. This is a good opportunity to install the latest version. For example, if you are migrating an 11.5.9 environment, you can still install an 11.5.10.2 application tier technology stack.

The same rule applies with the R12.0 and the R12.1 technology stack. There is no requirement to upgrade to 12.1 if you wish to use a 12.0 technology stack. Remember, even if you are maintaining your existing technology stack versions you will still need to download and build a new installation staging area for your new target platform.

Remember to check all the patches you have applied to the source technology stack previously as it is conceivable you have applied patches on your old technology stack that have not been applied to the newly built technology stack. 

4. Partial Migration to a New Platform

There's no particular reason not to migrate the database or application tier in isolation to a new platform. It may be, for example, that you are currently running the E Business Suite on a single node and you're encountering resource or performance problems. You therefore decide to migrate Forms and web application tier processing to a new node which is running on a different platform to your current environment. This is generally described as a split configuration. You should be able to just follow the same Notes to perform this migration.
Tip:  Remember, if you only migrate Forms and Web services to the new platform, in your new environment you will now have to download and apply each E-Business Suite patch twice (once for each platform) as you will  still have concurrent processing being handled on the database tier.
For the above reason, if you're planning to run a split configuration, I would always tend to advise running all application tier services (including admin and concurrent processing) on one platform and using the other platform exclusively as a database tier. This means E-Business Suite patches only need to be applied once at the new application tier level.
In the early days of 11i there was a perceived performance advantage to having the database and concurrent processing on the same node. This is no longer an architectural requirement, given the vast improvements in network bandwidth.  You are free to locate your batch processing services on a different physical server than your database tier.

There is an additional maintenance overhead of running multiple application tiers on different platforms, so you should take that incremental cost into consideration when planning your architecture. In all cases, you should always locate all nodes in the same data centre and ensure the fastest available network connection between nodes. This configuration should also be more scalable allowing easier introduction of additional nodes at both application and database tier levels.

The above conditions regarding concurrent processing and the database tier apply equally to Apps 11i and 12.

5. Sharing the Application Tier

If you're contemplating a migration and are using multiple application tiers then this is often a good opportunity to implement a shared application tier architecture. A shared application tier means storing a single application tier filesystem on a shared disk accessible to all application  tier nodes. Each application tier node continues to run all or a subset of application tier services however all application tiers access the same single disk subsystem. This reduces maintenance as application tier patches only need to be applied once and therefore may reduce future upgrade or patching downtime.

If you are running multiple application tiers in your source environment (on the same platform) and plan to use a shared application tier on your target environment then you should merge your application tiers on the source environment before migrating. This means only having to migrate a single application tier. The merge process is described in Note 233428.1 for 11i.

In R12 all applications tiers have a full application tier file system installed, even if the application tier is only configured to run a subset of application tier services. This means there is no need to merge application tiers in the same way as was required with 11i.   

A shared application tier can be configured in conjunction with third party software and hardware load balancers.

Top Five Migration Tips

So to conclude, here's a top five list of things to consider when migration Oracle Applications to a new platform:
  • Perform as much of the migration as possible outside of the production system downtime
  • Consider a shared application tier configuration if you plan to use multiple application tiers
  • Place all nodes in your E-Business Suite environment in the same data centre regardless of the location of your users
  • If using a split configuration, do not feel compelled to retain concurrent processing on the database tier
  • Use transportable database functionality to migrate the database tier if your source and target platforms have the same endian format
References

Related Articles


Saturday Mar 06, 2010

E-Business Suite Release 12.1.1 Consolidated Upgrade Patch 1 Now Available

Oracle E-Business Suite Release 12.1.1 Consolidated Upgrade Patch (CUP1) is now available in My Oracle Support.  This patch is now mandatory for customers who are upgrading to Release 12.1.1 from the following releases:
  • Oracle E-Business Suite Release 11i version 11.5.9 (base, CU1, CU2)
  • Oracle E-Business Suite Release 11i version 11.5.10 (base, CU1, CU2)
You can download it here:
Patch-7303029-screenshot.png

What is Oracle E-Business Suite Consolidated Upgrade Patch 1 for Release 12.1.1?

The Consolidated Upgrade Patch 1 (CUP1) for Release 12.1.1 combines critical upgrade error corrections and upgrade performance improvements from Release 11i into a consolidated suite-wide patch.

Who should use it?

Customers who are upgrading to Release 12.1.1 from Release 11.5.9 (base, CU1, CU2) or Release 11.5.10 (base, CU1, CU2) should apply Release 12.1.1 CUP1.

How does it differ from the Family Consolidated Upgrade Patch (FCUP) in Release 11i?

In Release 11i, Family Consolidated Upgrade Patches (FCUP) were the release vehicles used to ship consolidated upgrade-related patches from all products within a product family.  In R12, the term Consolidated Upgrade Patch (CUP) has been coined to ship critical upgrade error corrections and upgrade performance improvements across all the product families in Oracle E-Business suite.

How do you apply Release 12.1.1 CUP1?

For instructions on applying this patch, see the "Notes for Upgrade Customers" section in:
Can this patch be applied by customers who are upgrading to Release 12.1.1 from an earlier version of Release 12?

No.  Release 12.1.1 CUP1 is applicable only if you are upgrading your E-Business Suite Release 11i instance to Release 12.1.1.  If your Oracle E-Business Suite instance is already at Release 12 or higher (e.g. Release 12.0.4), you should not apply Release 12.1.1 CUP1.

Can I apply Release 12.1.1 CUP1 to Release 12.1.1?

No.  If your environment is already at the Release 12.1.1 level, you do not need this patchset.  You should apply Release 12.1.1 CUP1 only while upgrading a Release 11i Oracle E-Business Suite instance to Release 12.1.1

Is Release 12.1.1 CUP1 mandatory for upgrading to Release 12.1.1 if I have done multiple test upgrades and am close to "Go-Live"?

If you have already performed multiple test upgrades without Release 12.1.1 CUP1 and are close to completing User Acceptance Testing prior to your actual production upgrade, it is not mandatory to apply the patch.

Oracle will continue to provide patches for Oracle E-Business Suite Release 12.1.1 environments that do not have the Release 12.1.1 CUP1 patchset.

How is the Consolidated Upgrade Patch (CUP) different from other release vehicles?

With the introduction of this patchset, there are now five types of release vehicles for the E-Business Suite:
  1. Rapid Install
  2. Maintenance Pack
  3. Product Family Release Update Pack
  4. E-Business Suite Release Update Pack
  5. Consolidated Upgrade Patch
Rapid Install

With Rapid Install (RI), you can install a fully configured Oracle E-Business suite system, lay down the file system and configure server processes for an upgraded system, or install a new database tier or application tier technology stack.

Release 12 Rapid Install versions are
  • Release 12.0.0
  • Release 12.0.4
  • Release 12.1.1
Maintenance Pack

A Maintenance Pack (MP) is an aggregation of patches for all products in Oracle E-Business Suite. It is a feature-rich release which combines new functionalities along with error corrections, statutory/regulatory updates, and functionality enhancements, etc.

The Release 12.1.1 Maintenance Pack can be used to upgrade an existing Oracle E-Business Suite Release 12.0.x environment to Release 12.1.1

Product Family Release Update Pack

Product Family Release Update Pack (RUP) is an aggregation of patches on a given codeline created for all products in a specific product family for a specific point release. RUPs are generally cumulative in nature.

Examples of Product Family Release Update Packs released in Release 12.0:
  • R12.ATG_PF.A.Delta.4
  • R12.FIN_PF.A.Delta.5
  • R12.ATG_PF.A.Delta.6
  • R12.HR_PF.A.Delta.7
Examples of Product Family Release Update Packs released in Release 12.1:
  • R12.AD_PF.B.Delta.2
  • R12.ATG_PF.B.Delta.2
  • R12.CC_PF.B.Delta.2
  • R12.SCM_PF.B.Delta.2
E-Business Suite Release Update Pack

An E-Business Suite Release Update Pack (RUP) is an aggregation of product or product family RUPs on a given codeline created across Oracle E-Business Suite after the initial release. Like product family Release Update Pack, E-Business suite Release Update Pack is cumulative in nature.

Examples of E-Business Suite Release Update Packs
  • Release 12.0.4
  • Release 12.0.6
  • Release 12.1.2
Consolidated Upgrade Patch

A Consolidated Upgrade Patch is a collection of critical fixes that improve the performance and stability of the upgrade process from Release 11i to Release 12.1.1.
References
Related Articles

Tuesday Jan 05, 2010

New Whitepaper: Symmetrical Network Acceleration with EBS 12

Andy Tremayne, my esteemed colleague and fellow blogger, has published a new whitepaper that discusses the effects of network acceleration appliances on traffic optimization for E-Business Suite environments: 
From Andy's crisp prologue:
Network appliances can be used to reduce bandwidth and latency effects through the use of data stream compression and object caching. The focus of this whitepaper is the deployment of Oracle E-Business Suite across an enterprise wide area network (WAN). Internet-facing applications may benefit from other specialized technologies such as Internet based Content Delivery Networks (CDN) and Internet-based network optimization strategies such as caching, route optimization, and protocol optimization.

The two main types of acceleration appliances are classed as Asymmetric and Symmetric. Asymmetric acceleration uses a centrally-located single appliance whereas Symmetric acceleration requires an appliance at either end of a network link, or in some cases, a single central appliance and corresponding software client on each remote computer.

Architecture diagram showing network appliances linking geographically dispersed locations to the E-Business Suite

As is Andy's wont, this whitepaper is packed with thoughtful analysis, architectural insights, recommendations, diagrams, in-depth quantitative benchmarks, and detailed charts that compare:
  • Traffic reduction improvements for different transaction types
  • Socket to servlet data transfer rates
  • Response times in optimized and unoptimized testbeds
  • Traffic reduction for low network bandwidth activities
  • Optimization results for high network bandwith activities
This whitepaper is critical reading for network architects grappling with the challenges of providing E-Business Suite access to geographically-diverse locations.

Related Articles

Monday Dec 07, 2009

Oracle E-Business Suite Install and Cloning Best Practices (OpenWorld 2009 Recap)

Experienced E-Business Suite systems administrators know that there never seem to be enough EBS testbeds for everyone.  It doesn't take long for an Apps sysadmin to realize that having a solid understanding of the various options for building and cloning EBS environments is an essential part of his or her toolkit.  

Flow diagram showing adpreclone process and what it does on the EBS database tier
If you've been wondering about the different options for building EBS environments, look no further.  Max Arderius is a member of our Applications Technology Group.  His OpenWorld session covered the E-Business Suite's Rapid Install and cloning techniques in detail:
Max drilled into the following topics in his presentation:
  • Installing the E-Business Suite
    • Rapid Install overview
    • Standard vs. Express Install
    • Filesystem implications of upgrading and existing system
    • Upgrade considerations
    • Installation of the latest Applications technology stack
  • Cloning techniques
    • Overview of cloning tools: Rapid Clone vs Application Management Pack
    • Details of Rapid Clone process
      • What adpreclone.pl does on the database and applications tiers
      • What happens during the cloning process
      • What adcfgclone.pl does on the database and applications tiers
      • Comparison of adcfgclone.pl command line options
      • adclonectx.pl configuration command
    • Application Management Pack cloning process
      • Comparison of Application Management Pack cloning options
      • Source-to-image, image-to-target cloning
      • Hot cloning
      • Real Application Clusters (RAC) cloning
      • Data scrambling during the cloning process
    • Custom cloning techniques
      • Source-to-target direct synchronization
      • Cloning using rsync
      • Maximum Availability techniques using Oracle DataGuard and rsync to a standby database
      • OracleVM cloning using functional technical VM templates
  • Best practices
    • Pointers to useful resources
    • Comparison of using media vs. staged images
    • Remote installation best practices and considerations
    • Fully qualified hosts and file permissions
    • Resource limits and kernal parameters
    • Temp directories and swap spaces
    • Techstack registration
    • Global inventory and multiple inventories
Listening to the Session

If you registered for OpenWorld, here's a link to the OpenWorld On Demand page where you can download the presentation or listen to the live recording of this session.

Related Articles

Wednesday Nov 18, 2009

Critical Data Protection + Security in EBS (OpenWorld 2009 Recap)

Everyone gives lip service to the importance of security, but it's often relegated to the back-burner in actual practice.  For example, my anecdotal experience is that when conference attendees are polled about Critical Patch Updates, usually fewer than 50% of the respondents state that they're up-to-date on the latest CPU.

One potentially complicating factor is that there are many things that one can do to secure the E-Business Suite, and it may be hard to know where to start.  At minimum, all Apps DBAs should be intimately familiar with these documents:
There are many other security-related Oracle products that you can use with your E-Business Suite environment, too.  Eric Bing and Robert Armstrong profiled all of the latest security-related tools and options that are relevant to E-Business Suite users in their recent OpenWorld 2009 session:

defense_in_depth.png

Eric and Robert cover the following topics in their presentation:
  • Business drivers and security challenges
    • Database Defense-in-Depth
    • Options for monitoring, access control, and encryption & masking
    • End-to-end security strategies
  • Building a secure E-Business Suite configuration
    • Password policies for Apps and DB accounts (and reference notes)
    • Security profile option settings and recommendations
    • FND Validation Level feature
    • Fixed Key profiles
    • Non-reversible password hashing
  • Externalizing EBS security from the apps tier
    • Apps schema access via SOA Suite Apps Adapter
    • Application Data Source implementation
    • Java Authentication & Authorization Service (JAAS) for E-Business Suite
    • Using Oracle Access Manager
  • Other EBS security integrations and technologies
    • Oracle Audit Vault and client identifiers
    • Oracle Database Vault and segregation of duties
    • Oracle Transparent Data Encryption (TDE) for columns and tablespaces
    • Oracle Label Security (OLS) and Virtual Private Database (VPD)
  • Future directions for E-Business Suite security
Listening to the Session

If you registered for OpenWorld, here's a link to the OpenWorld On Demand page where you can download the presentation or listen to the live recording of this session.

Related Articles

Tuesday Nov 17, 2009

E-Business Suite Technology Essentials (OpenWorld 2009 Recap)

I'm part of the Applications Technology Integration group within the E-Business Suite Development division.  One of this team's responsibilities is to ensure that new Oracle technologies are integrated into -- or work with -- the E-Business Suite. 

Lisa Parekh leads our team, and every year she manages to pack a survey of the increasingly-broad EBS technology stack landscape at OpenWorld into her session.  If you're interested in getting a quick overview of everything that we consider important about the latest EBS technology stack capabilities, download her presentation here:
EBS-R12-architecture-diagram2.png
Lisa covers the following topics in her presentation:
  • E-Business Suite technology stack priorities
  • Oracle E-Business Suite Release 12's three-tier architecture
  • Supported R12 browsers
  • Application Server Tier components and layout
  • Standard and optional 10gR2 and 11g Database features
    • Partitioning, compression, tablespace encryption
  • Exadata V2 
  • External optional Fusion Middleware certifications
  • R12 User Interface improvements 
  • Secure Enterprise Search
  • WebCenter integration
  • Single Sign-On and Oracle Internet Directory integration
  • Third-party authentication and LDAP integration
  • SOA enablement and integration
  • Application Integration Architecture
  • Business Intelligence
    • Oracle Business Intelligence Enterprise Edition (OBIEE)
    • Oracle Business Intelligence Applications (OBIA)
  • BI Publisher
  • Systems management capabilities via Oracle Enterprise Manager
    • Application Management Pack
    • Application Change Management Pack for Oracle E-Business Suite
    • Wizards and AutoConfig 
  • Virtualization and Oracle VM
    • Coming soon: Oracle VM templates for the E-Business Suite 12.1.1
  • Technology Uptake Guidance
    • Upgrading to R12.1
    • Database upgrade options
    • New certifications coming
Listening to the Session

If you registered for OpenWorld, here's a link to the OpenWorld On Demand page where you can download the presentation or listen to the live recording of this session.

Related Articles

Tuesday Nov 10, 2009

To Customize or Not to Customize?

Any customer can have a car painted any colour that he wants so long as it is black.
~ Henry Ford

Ford's now-famous words seem a little quaint today.  We live in the Golden Age of the Consumer, where virtually everything can be customized or personalized in some way.  If you can customize mass-produced consumer goods, it seems reasonable to expect that you should be able to customize something as strategic and mission-critical as an enterprise resource planning system, too.  But just because you can, does this mean that you should?

Personalizations are Persistent

The E-Business Suite has acquired increasingly-powerful personalization features over the years.  These features allow you to personalize existing EBS screens with your own branding, corporate logos, colour schemes, field names, explanatory messages, and more.  My fellow blog authors have previously written about personalization options here (for Forms personalization) and here (for OA Framework personalization). 

These types of personalizations are metadata-driven, which means that they are preserved and work even when the underlying screens are updated by EBS product teams via new patches.  This is the primary benefit of using the standard Apps personalization features: your changes are persistent and will continue to work even if the underlying screens are patched at a later date. 

Going Beyond Personalizations

You might have a unique service offering, product, or business process.  You might need to capture or manage information about your business, products, or customers in a way that differs markedly from the way the E-Business Suite's designers originally intended. 

From a system administrator's perspective, you might need to deploy the E-Business Suite in an architecture, topology, or system configuration that aren't supported via AutoConfig yet. 

The E-Business Suite's personalization features, while useful, may not be sufficient to meet these types of specialized requirements.  At this point of your analysis, it will be useful to consider the advantages, disadvantages, and implications of customizing your the E-Business Suite in an invasive way.

There are many ways of customizing or extending your EBS environment.  These include:
  • New business rules or data transformations
  • New or custom screens
  • Integrations with external systems
  • Use of third-party utilities or extensions
  • Creation of new reports
  • Creation of new workflows
  • Integrations with standalone APEX applications
All of these customizations need to be considered in terms of their invasiveness.  The more invasive the change, the greater the long-term implications.

Advantages of Customizations
  1. Functionality meets your requirements more closely
Disadvantages of Customizations
  1. More costly than deploying a "plain vanilla" solution
  2. Requires specialized development skills
  3. May require updates, testing, and maintenance whenever:
    • New EBS patches are released
    • New architectures are deployed
    • New technology certifications are released
  4. Increases support complexity and overhead
  5. Can potentially complicate upgrades to new EBS releases
Understanding the Implications of Customizations

As regular readers of this blog know, we frequently release new technology stack patches, certifications, architectures, and systems management features.  Apps product families (e.g. Financials, Supply Chain, Human Resources, etc.) aren't standing still, either.  They're constantly updating their products with new features and enhancements, too.

Let's assume that you have the resources to address the first two potential issues of increased cost and skills.  What remains are the implications of keeping up with your friendly developers at Oracle:

Testing Implications

I've spoken with a number of customers who tell me that their customizations have prevented them from applying the latest ATG Rollup or upgrading to the latest database release.  They might have had staff to perform the original customizations years ago, but they no longer have the capacity to regression test their environments with new patches or technology stack components.  In some cases, formal development records detailing the customizations have been lost, making it extremely difficult to perform any impact analyses or tests.  These customers can't go forward, and they can't undo their customizations, either.  These customers are stuck.

If you've customized your E-Business Suite environment in some way, you need to ensure that every new certification, patch, or newly-supported architectures work in your customized environment.  Depending upon what you're considering introducing into your environment, you may need to perform functional tests, performance benchmarks, scalability testing, and even security reviews.  If you're thinking of customizations, it is extremely important not to underestimate the costs of maintaining and testing them.

Support Implications

If I were an IT manager considering customizing the E-Business Suite, the primary factor affecting my decision would be the support implications.  Oracle certifies and supports generic E-Business Suite environments.  If you invasively customize your system in some way, you should understand and plan for the fact that Oracle can only provide patches for issues that can be reproduced in uncustomized, "plain vanilla" E-Business Suite environments.

Customers who can succinctly describe their customizations when logging Service Requests with Oracle Support will have a distinct advantage over those customers who wait for Oracle Support to stumble over a customization. 

Upgrade Implications

Premier Support for E-Business Suite Release 11i ends in November, 2010.  At OpenWorld this year, it was abundantly clear that many of you are planning your upgrades to E-Business Suite Release 12 now. 

If you've customized your Apps 11i environment in some way, your Apps 12 upgrade plan needs to consider whether those customizations are still needed.  Given the many new features in EBS 12, it's entirely possible that your customizations may now be redundant or obsolete.  One major Apps 11i customer with several thousand customizations observed that at least half of those were already built directly into R12, obviating the need for forward-porting.
Tipping the Scales

I've had the pleasure of working with countless EBS customers over the years.  My impressions are that systems administrators with uncustomized Apps environments are generally more-receptive to keeping up with the latest patches, are more willing to consider upgrades and trying new technologies.  This makes a lot of intuitive sense.

As a battle-scarred Oracle developer, I would venture that very few customers can justify the extremely-high costs and long-term systems management implications that come along with invasive customizations. 

That said, every customer has their own business case for customizations.  Your mileage will vary.  Everyone going through this analysis will have their own factor weightings, costs, and benefits of customizing their EBS environments.

I'd be interested in hearing your war stories about customizations, both good and bad.  Feel free to share them in a comment or by dropping me a line. 

Related Articles

Wednesday Sep 23, 2009

Field-Tested Advice for Smooth EBS 11.5.10.2 Upgrades

Premier Support for Oracle E-Business Suite Release 11.5.9 ended in June, 2008.  If you are currently running 11.5.9 or earlier and your immediate plans do not involve an upgrade to Release 12, then it's a good idea to move up to the terminal release of Apps 11i:  11.5.10.2. This will ensure you remain supported and can make the most of any technology stack and functional upgrades. 

A lot of what you do as part of an upgrade to 11.5.10.2 will also ease your transition to Release 12, so this upgrade can be considered as a Release 12 prerequisite exercise, too. Critical patch updates, roll-up patchsets (RUPs) and new technology stack certifications are still being released for Apps 11.5.10.2, and the more up-to-date your system is, the easier it will be to apply these when they come along.  This article takes you through some of the best tips from Oracle Support to ensure a successful upgrade to EBS 11.5.10.2.

Screenshot patch 3480000.png
Tip #1: Give Yourself Enough Time

The first and most important piece of advice is to give yourself enough time. If you have not done an upgrade like this, then don't create a project plan with fixed dates and times until you have a good feel for what the upgrade will involve and how long it will actually take. Your current E-Business Suite release and database version will dictate how much work you have to do. Not surprisingly, if you are running Apps 11.5.2 on the 8.1.7.4 Database, you will have your work cut out for you.  If you are on 11.5.9 and 9.2.0.8, then your job will be much easier.

We talk to a few customers who have decided how long they have to complete the entire project before even contemplating what work is required. Don't fall into this trap. Nobody likes working with a gun to their head, least of all, one that they're holding themselves.

Remember this is not just a technical upgrade. The 11.5.10.2 Maintenance Pack has functional and technical implications.  Even if the upgrade is not motivated by functional requirements, it will certainly require User Acceptance Testing.

Tip #2: Read the Documentation Beforehand

Engineers in Oracle Support would be the first to admit that navigating through a combination of Oracle manuals, Notes from My Oracle Support and adpatch readme files and then corralling all that information into a coherent upgrade strategy can be an intimidating task. The temptation to use documentation that is not specifically written for the E-Business Suite or to devise an upgrade strategy of your own can sometimes look very appealing.

It's not difficult to find a document that appears to apply to your circumstances but then have Oracle Support tell you that you need to be following a different document.  Documentation that is specific to Oracle Applications exists for upgrading just about every component of the technology stack. If, for example, you can't find the Note that talks about upgrading or patching Developer 6i (Note 125767.1) then raise a Service Request (SR) with Oracle Support.

Tip #3: Don't Take Any Undocumented Shortcuts

We're sometimes asked, "What if I ignore Step X of my upgrade? Will it still work?" This is an almost-impossible question to answer.  In Oracle Support, we're not insensitive to questions such as this, but the reality is that we will probably not be able to give you a clear and unambiguous answer.

Our published documentation is designed to achieve a successful upgrade. It is not tested by trying to perform the upgrade steps in a different order or by deliberately omitting steps to see how the upgrade will turn out.  You should perform all steps in the upgrade documentation unless you have a clear reason not to, or clear guidance from Oracle Support that a step can be omitted.

Given the above, it's also no surprise that a common question we get from customers is "Here is my upgrade plan. Can you go through it and tell me if it's OK?"  This is a perfectly understandable question to ask but sometimes a tough one to answer, especially if the upgrade includes platform migrations, technology stack updates, and Oracle Applications upgrades. 

We'll try to do out best, but it's difficult for us to give an unconditional endorsement of an upgrade plan that greatly varies from our documentation. Circumstances may sometimes force you to perform upgrade steps in a non-standard order. We're always happy to discuss variations, but it is unlikely we will be able to give you a carte blanche endorsement of an entirely bespoke upgrade, since we are unlikely to have ever attempted an upgrade in the way you might describe.

Tip #4: Get the Latest Patches and Maintenance Tools

Start by reading Note 316365.1: the 11.5.10.2 Maintenance Pack documentation. This has all the major steps you may or may not need.  The Upgrade Manual Script for the Maintenance Pack (TUMS-MP) will also create a report listing the steps which are required -- specific to your system -- therefore telling you what steps can be omitted.

Apply the latest AD patchset as early as possible in the upgrade.

Whenever you see a patch specified in documentation do not assume this is the latest incarnation of this patch. Check on My Oracle Support to see if it has been superseded. If it has, apply the latest version whenever possible.

Implement AutoConfig if you have not done so already.  If AutoConfig is only implemented on the application tier, then implement it on the database tier without delay.

Install and run the Technology Stack Validation Utility. If this reports any errors then, instead of trying to address each issue individually, I'd encourage you to just go to Note 146468.1 and build new 8.0.6 and iAS ORACLE_HOMEs using the 11.5.10.2 install media. This will save you time.

Tip #5: Switch to the Oracle Applications Tablespace Model (OATM)

OATM is the latest Oracle Applications tablespace model. Instead of having separate tablespaces for each product, it converts your system to use a greatly reduced number of tablespaces. This is installed by default in fresh installations from 11.5.10 onwards. It will almost certainly reduce the overall footprint of the database, will simplify administration, may improve performance, and is mandatory for Release 12.

It will take some time to migrate all your database objects to the new tablespaces, but the benefits are worthwhile. The opportunity to optimise a database that may have been running for several years should not be underestimated.

Tip #6: Configure database for new products and new tablespace requirements

With each Maintenance Pack release there tend to be some new products introduced.  These products have to be "spliced" into your existing database and APPL_TOP.  Pay particular attention to the patch readme and complete all steps.  You cannot avoid adding these new products simply because you do not anticipate licensing or using these products.  This is a mandatory step. 

Tip #7: Upgrade the database (conditional) 

Releases 10gR2 and 11gR1 are currently supported for the E-Business Suite.  If you're running an earlier database release, you need to upgrade to at least 10gR2, and preferably 11gR1.  You can currently upgrade to E-Business Suite Release 12 only if you are already running Database Version 10gR2 or 11gR1.

There are specific Notes for Oracle Applications users when upgrading the database:
The default method is to use the Database Upgrade Assistant (DBUA) to upgrade Oracle Applications databases.  The upgrade will invalidate a large number of objects in the database.  You need to decide whether you want DBUA to compile these automatically or whether you want to compile them manually later.  You can configure DBUA accordingly before starting the upgrade.  If you're currently on 10gR1 or an early release of 10gR2 then take the opportunity to upgrade to 10.2.0.4 or 11gR1.

Install the Data Mining and OLAP options as instructed. This is a mandatory step, even if you're not using products that require those options.

Tip #9:  Monitor the Upgrade Driver

The main part of the upgrade to EBS 11.5.10.2 is performed by the upgrade driver supplied in patch 3480000. This should complete without error -- no jobs should be skipped or ignored. If you find yourself having to skip jobs without a very good reason, this suggests something that should have been performed earlier has been omitted or has failed.  Skipping a job may have consequences for subsequent jobs as data or objects may be accessed by several workers during the upgrade driver.

Accept the default number of workers unless you have a good reason not to. Substantially increasing or decreasing the number of workers you use may affect the performance of the upgrade driver.  While it may be a worthwhile exercise to experiment with the number of workers you use, you should always use the default number as your benchmark for performance.

Tip #10: Rehearse Your Upgrade Process Thoroughly

As Support engineers, we generally advise performing a minimum of three test upgrades prior to performing a production upgrade. This means three complete upgrades from start to a successful conclusion. This iterative process allows you to find possible pitfalls during the production upgrade and have workarounds ready.  If you encounter issues during your production upgrade that were not encountered in testing then -- and I apologise for being blunt here -- you probably have not done enough testing. The production upgrade should mostly be a formality, not the most stressful phase of the whole project. 

We often talk to customers who encounter a series of errors during one of their test upgrades. For each error, a workaround is found and the test upgrade proceeds. The workaround may involve applying a patch that should have been applied earlier in the upgrade, perhaps resizing a tablespace during a patch, or changing a value in an initialisation file or something similar. These errors should be noted and then another test upgrade performed with these workarounds in place so the error no longer appears. There can come a point during a test upgrade where an error is encountered and several things are tried before the successful workaround is found.  If you find yourself in this position at several times within the same test upgrade, it is often advisable to start a new test upgrade and not continue with this test upgrade. This is because this particular test upgrade (usually very early in the project) is no longer representative of what you would actually do in your production upgrade, therefore invalidating your initial testing conditions.  As Oracle Support engineers, we don't advise this lightly. Sometimes the best advice is to give up and start again.

Because of the above, it's advisable that during each test upgrade, you backup the system at each major step in the upgrade.  If you then encounter a problem during an upgrade that results in your abandoning that particular step, you only need to revert back to the latest backup rather than rewinding to the start of the upgrade.

Rehearsing your upgrade also allows you to fine tune the process. Testing should give you the chance to record the whole upgrade with each step documented and timed. With this upgrade documentation you may see stages where, for example, you can merge patches into a single step. You can use adpatch command line parameters to avoid generating forms or reports in the middle of an upgrade that are perhaps going to be updated and compiled again further along in the same upgrade by another patch. Refinements like this will reduce the time of the overall upgrade. This refinement process is how you manage to turn your first test upgrade that might take two weeks into a production upgrade that you have to complete in 36 hours for example.   

All test upgrades should be performed on a very recent clone of your production environment.

Tip #11: Be Aware of Database Tuning Opportunities

We're sometimes asked whether fine tuning of database parameters or other components of the technology stack can enhance the performance of the upgrade. There are some pointers within the documentation suggesting when you can do this. I personally find that careful refinement and optimising of all the steps that you perform during the upgrade as a whole will reveal more opportunities to reduce the time the upgrade takes than specific database tuning. That said, it never hurts to look out for opportunities to optimise database performance.

Wrapping Up:  Upgrade Myths

So finally, here are the top 5 myths (from an Oracle Support perspective) about upgrading to E-Business Suite 11.5.10.2:
Myth #1:  Shortcuts are safe

There are no safe shortcuts.  This upgrade can't be done by performing a fresh install of 11.5.10.2, linking this installation to your 11.5.x database and then applying the database portion of the 11.5.10.2 Maintenance Pack. It's a nice idea, but it is a flawed strategy

Myth #2:  You can safely ignore adpatch worker failures

No, this is very dangerous.  It is not acceptable to skip worker failures in adpatch because the errors are in products you do not intend to use.

Myth #3:  You can export from an old database version to a higher one

It is (generally) not supported to upgrade an Applications database by exporting from one database version (8i for example) and importing into a fresh empty database of a later version.

Myth #4:  You can ignore unused products

It is not acceptable to ignore the installation of new products just because you do not intend to use those products. 

Myth #5: You can live without AutoConfig

AutoConfig must be implemented on the database tier -- this is mandatory and will improve your quality of life
Good luck with your upgrade!

Related Articles

Tuesday Sep 22, 2009

Six Options for Getting Help for E-Business Suite Issues

[Sept 24, 2009 Update: Removed references to the Oracle Critical Accounts program.]

Some E-Business Suite implementations go smoothly.  Some don't.  Even battle-scarred veteran Apps sysadmins have to call upon Oracle for help at some point.  One of the most-surprising things I hear from customers is that many of you don't know what options exist for you to get help when you need it.  Depending on your circumstances, there's a wide range of alternatives that may work for your needs.

Taking the wrong approach can waste a lot of time and efforts on all sides.  If you need help, here's a list of the best options for ensuring that you get the help that you need:
  1. Do your homework
  2. Log a Service Request (SR)
  3. Escalate your Service Request with Support
  4. Escalate with your Oracle account manager
  5. Get a Service Delivery Manager assigned
  6. Register with the Applications Development Customer Program
Oracle Advanced Customer Services.png

Option 1: Do Your Homework

A good way of wasting time is to log a Service Request before you've searched for the answer yourself.  Google is your friend, of course, so running searches should always be your first step.

As an aside: I am repeatedly bemused by the emails I receive from people who haven't done even the most-rudimentary web searches.  Interestingly, this includes questions from Oracle staff who should (presumably) know better. 

Oracle resources that you should search before logging an EBS Service Request:
The Knowledge tab on My Oracle Support is your entry-point into the collective published body of knowledge from Oracle Development, Support, and Consulting.  It almost goes without saying that you should search for your issue here.  The only caveat is that the Knowledge repository is extremely wide-ranging and deep, and can potentially be intimidating to explore for new users.  Stick with it, though; this is the definitive resource for all Oracle product issues.

It's important to remember that all Oracle bloggers are doing this in their spare time.  If they're brave enough to reach out to customers, you should remember that Oracle bloggers have varying amounts of bandwidth available to answer your questions.  My fellow bloggers on my E-Business Suite Technology Stack blog are always happy to help with your Apps techstack questions, but we hope that you've searched our site for answers before you post your question.

Forums are a different matter.  Remember that these public forums are monitored by your customer peers and occasionally someone from Oracle.  These forums yield answers that may vary in quality.  Some of these -- like the impressive Apps R12 Upgrade and OA Framework forums -- have a dedicated and superb group of volunteers who provide crisp and accurate answers to all questions posted.  Others, not so much.

If these sources solve your problem, great.  If not, then your next step is to get an answer from an authoritative source:  Oracle Support.  If you have a time-sensitive issue for which you need a guaranteed and authoritative response, your best bet is to log a formal Service Request with Oracle Support.

Option 2: Log a Service Request

Logging Service Requests (formerly Technical Assistance Requests or TARs) is a necessary first step for any conversation with anyone within Oracle about a particular technical issue.  You log Service Requests via My Oracle Support.  Service Requests are always the starting point for all technical issues. 

Many of you post conceptual or architectural questions here.  This blog's panel of authors are always happy to answer those questions.  However, this blog isn't really set up to handle diagnostics and investigate technical issues; that's Oracle Support's job. 

If you email us directly or post a question about a specific technical issue that you're encountering, our first follow-up question will inevitably be, "What's your Service Request number?"  If necessary, we can help the Oracle Support engineer get to the bottom of your issue -- but only if you've logged a Service Request first. 

The key thing to remember about Service Requests is that the quality of Oracle's assistance depends upon the quality of information that you provide.  Garbage in, garbage out.  Make sure that you provide a good description of the problem, detailed error messages, logs, information about your environment, screen captures, results of your own investigations and tests, and reproducible test cases. 

Option 3: Escalate Your Service Request with Support

If your Service Request is getting bogged down for some reason, or is going off in a direction that doesn't seem quite right, it may be time to escalate your case.

Chris Warticki, a fellow Oracle blogger from Support, has written an excellent article on the Support Escalation process.  I strongly recommend that you check out his article; he makes many insightful comments about how to escalate your issue effectively.  To summarize his key points:
  • Speak with the Oracle Support Escalation Manager (formerly the Duty Manager).
  • Review your concerns.
  • Work up an action plan.
  • Follow up on the agreed-upon actions.
  • Ask the Escalation Manager to follow up with Development on associated bugs.
Option 4: Escalate with Your Oracle Account Manager

Escalating through the regular Support channel doesn't always work as well as it might.  If you still find yourself struggling after doing that, then there are other options.

Some customers may think of Oracle account teams as being useful only when negotiating licencing contracts.  From my vantage in Apps Development, I see Oracle account teams quite differently.  I consider your Oracle account manager to be your advocate and your ombudsman within Oracle.  If you're having difficulty getting any issues resolved through the official channels (e.g. via escalating Service Requests), then your Oracle account manager is your next call.  Your Oracle account manager can escalate a Service Request with management teams in Oracle Support and Development.
 
That's the theory, at least.  The reality is that some Oracle account managers may be relatively new to their jobs, so you may need to encourage them to seek help via internal Oracle channels on this.  Oracle account managers should be motivated to help you resolve issues, since happy customers tend to be more willing to do repeat business than unhappy ones.

Option 5: Get a Service Delivery Manager Assigned

This option isn't for everyone, but you should at least know that it exists.  It is possible for you to work with your Oracle account manager and Oracle Advanced Customer Services to get a Service Delivery Manager assigned to your organization.  A Service Delivery Manager can act as your primary contact within Oracle Support, and can help escalate Service Requests, engage Development teams, and coordinate responses from multiple groups for complex issues.

My experience is that this option is very useful for large, complex organizations who have equally large, complex, and time-sensitive E-Business Suite projects underway.  In situations where you're logging a large number of interrelated or overlapping Service Requests against many different Oracle products, having a Service Delivery Manager can be useful in keeping track of everything.  Service Delivery Managers can also hold regular status calls to review your open issues, and can escalate open Service Requests directly to Oracle Development teams.

It's also important to note that Oracle Advanced Customer Services offers the option of technical teams that can be engaged proactively to provide guidance and hands-on services that may help avoid Service Requests entirely. 

Option 6: Register with the Applications Development Customer Program

Another customer support program within the E-Business Suite division exists:  the Applications Development Customer Program. 

The Applications Development Customer Program is primarily responsible for managing the Applications development portion of key customer projects and customer escalations. This involves engaging development resources across the Applications Suite Development Division, coordinating with Oracle Support and Oracle Consulting, and keeping Oracle executive management up to date on the most strategic customer projects and most critical escalations.

Your Oracle account manager can help get your organization registered with this program.  If your Oracle account manager is unfamiliar with this program, he or she can find out more at this internal Oracle Applications Development Customer Program website (also no external customer access).

Be Proactive, Be Assertive, Be Persistent

My experience is that large, complex organizations benefit from registering with both the Critical Accounts Program and the Applications Development Customer Program before embarking upon major upgrades.  For example, if you're planning on upgrading from Oracle E-Business Suite Release 11i to 12, it would be worth considering getting registered before you start your project.

The advantages of being proactive are legion:  you get a predetermined escalation path, Development organizations become familiar with your requirements and environment before you start logging Service Requests, and you effectively prime the pump in case you run into issues.

And lastly: be assertive, and don't give up.  I see Service Requests where customers have only just begun to investigate an issue with Support and/or Development... only to have the customer disappear.  Some customers just stop responding to requests for more information in their Service Requests. 

I find this a bit mystifying.  As you can see, if you're not getting what you need to resolve your issues, there are many options for getting help.  Be persistent and escalate up the channels as needed.

Related Articles

Tuesday Sep 15, 2009

Recommended Database Parameters Updated for EBS 12

Close on the heels of our recent updates to the recommended EBS 11i Database parameters, our database and applications performance architects have published updates for EBS Release 12. The updated note is now available here:

Our architects have refreshed a large number of recommended settings based upon customer feedback and their ongoing performance and scalability tests.

ShowParam.png

New updates

  • Removal of Application Upgrade Considerations section.
  • Addition of Advanced Queuing (AQ) note to common parameters.
  • Addition of note to the job_queue_processes
  • Addition of diagnostic_dest to 11gR1-specific parameters.
  • Addition of background_dump_dest, user_dump_dest, core_dump_dest to 11gR1 removal list.
  • Addition of plsql_native_library_dir, plsql_native_library_subdir_count, plsql_optimize_level to 11gR1 removal list.
  • Addition of #MP to _optimizer_autostats_job=false.
  • Updates to undo_retention section.
  • Addition of Timed_Statistics.
  • Addition of nls_language, nls_length_semantics, _sqlexec_progression_cost.
  • Removal of nls_length_semantics.
  • Removal of SGA_TARGET from Sections 2, 3, and 4, as this is in the common parameters.
  • Removal of db_block_buffers row from sizing table.
  • Updates to "Specific Notes on Table."
  • Updates to common parameters introduction.

As we've noted before, these changes are extremely important and can have profound impact on the performance of your Apps database.  All Apps DBAs should spend some quality time comparing your current database settings with the latest recommendations in this document.

Related Articles

Thursday Aug 27, 2009

Turbocharging Your EBS 12.0 Techstack Upgrade

[Oct 4, 2010 Update:  Since this article was published last year, there have been several updates to the patches list for the respective Oracle Homes (10.1.2, 10.1.3 and 11.1.0.7) based on customer issues and internal testing. The Rapid Install content for those Oracle Homes has not been updated with the same updates.  Hence, the patches delivered by the EBS 12.1.1 Rapid Install will not be the latest baselines available for those technology stack components.  If you use this Rapid Install method, you still will need to refer to the respective documents to apply the latest patches added after the EBS 12.1.1 Rapid Install was released.  For pointers to those documents, see the individual listings for the respective techstack components in this certification summary.]

All three of the major new technology stack components included in Oracle E-Business Suite Release 12.1.1 are also certified with Release 12.0.  You could manually upgrade each of these R12.0 techstack components yourself.  But now that Release 12.1.1 is out, why bother with that time-consuming approach when there's an easier and faster way?

You can use the EBS 12.1.1 Rapid Install to upgrade just the application and database tier technology stack components in your existing EBS 12.0 instance. Your technology stack components are upgraded to the same versions delivered with EBS 12.1.1 while leaving your EBS 12.0 product code (e.g. Financials, Supply Chain) untouched.

rapidwiz-txk.png

Running the Rapid Install with the -techstack option

Using the rapidwiz -techstack option with the EBS 12.1.1 Rapid Install provides options to upgrade the applications and database tier components for the following ORACLE_HOMEs:
  1. Application Server 10g OC4J to 10.1.3.4 (Applications tier)
  2. Application Server10g Forms and Reports to 10.1.2.3 (Applications tier)
  3. Database Release 10gR2 to 11gR1 version 11.1.0.7 (software and configuration files only on the DB tier. DB upgrade and post install steps to be performed separately)
From the first screen below, you can select the respective tier and proceed with the upgrade.

rapidwiz-txk.png


1. Upgrading the Database Technology Stack

Before selecting the database tier technology stack upgrade, make sure that your environment meets the minimum operating system prerequisites for running the 11gR1 Database.

If you choose the database tier upgrade, the wizard takes inputs for the Database host, Oracle SID, ORACLE_HOME and OS user related inputs.

rapidwiztxk-DB.png


It creates the new ORACLE_HOME with the associated Release 12.1.1 patches for the 11gR1 11.1.0.7 Database.  The installation then proceeds with installing the 11gR1 database software and the required configuration files for the E-Business Suite.

DB11upg.png


After the installation and configuration is complete, you need to complete the remaining DB upgrade steps using Section 1 and Section 2 of Interoperability Notes for 11gR1 with EBS R12.

2. Upgrading the Applications tier Technology Stack


If you choose to upgrade your applications tier, the Rapid Install wizard requires the CONTEXT file for your existing configuration. Point the wizard to the Application tier context file for your applications tier, e.g. $INST_TOP/appl/admin/<context name>.xml.

rapidwiztxk-AT.png


The wizard identifies the respective ORACLE_HOMEs from the context file and proceeds to upgrade these components.

OracleHomes.png


After validating and confirming the information, the installer proceeds to upgrade the components in the two Oracle Application Server 10g 10.1.3 and 10.1.2 ORACLE_HOMEs.

ATUpg.png


After all of the new Oracle Application Server 10g files are laid down in your filesystem, the Rapid Install wizard validates the installation. A green tick on the Validation window means the installation passed the post-install checks.

ValidationAT.png


Once you've run this upgrade on all of the Application tier nodes in your EBS instance, you're done!  Automated, validated, and fast.

References
Related Articles

Tuesday Aug 25, 2009

Distinguishing Between E-Business Suite 12.1 and 12.0 Patches

Sometimes our release processes get ahead of our internal infrastructure.  This happened when we released Oracle E-Business Suite Release 12.1.1.  We discovered post hoc that it was not possible to distinguish between patches intended for Apps 12.1 and those intended for Apps 12.0 in the "Patches & Updates" function in My Oracle Support and Metalink.  Whoops -- clearly suboptimal.

This issue was resolved in mid-July, when the Patches & Updates function got a brand-new "Compatible With" column:

aru-codeline-screenshot.png
The new "Compatible With" column clearly distinguishes between the patches for each Release 12 codeline now.

Don't Mix and Match R12.0 and R12.1 Patches

This distinction is important.  You shouldn't attempt to apply an R12.1 patch against your R12.0 instance, or vice versa.  If you tried to do that, you'd see a somewhat-cryptic error message like this:
AutoPatch error:

This patch is not compatible with your current codelines.

This patch is compatible with: entity 'gl' - codeline 'R12.GL.A'.
Your current on-site codeline for the entity 'gl' is: 'R12.GL.B'.

You should not apply this patch.

Apply an equivalent patch that is compatible with your
current codelines instead.
Sorting Patches Out After They've Been Downloaded

It's now easy to tell patches apart on the "Patches & Updates" download screen, but how can you tell them apart after they've been downloaded?  It's pretty simple. You can identify the codeline for a given patch by the letter in the third-digit:
  • Patches for EBS 12.0 will show an 'A' (e.g. "8414069.R12.AR.A")
  • Patches for EBS 12.1 will show a 'B' (e.g. "8414069.R12.AR.B")
For more tips about telling these patches apart, see:

Monday Aug 24, 2009

OPatch Essentials for Apps Sysadmins

All EBS administrators must become very familiar with the OPatch utility.  OPatch is used to patch the ORACLE_HOMEs in EBS Application and Database tiers.  Security fixes delivered for these ORACLE_HOMEs through Critical Patch Updates are also applied using OPatch.  It updates the central and per-product inventories with the details of each patch applied.  Apart from the Oracle Universal Installer (which internally also uses OPatch), this is the only tool authorized to patch ORACLE_HOMEs. 

Although it once had a reputation for being somewhat arcane, OPatch has evolved over the years into a more user-friendly and better-documented tool.  I'll cover the essentials of using OPatch in this article.

opatch.png


Prerequisites for Running OPatch

OPatch is a set of perl scripts that allow the application and rollback of interim patches to the ORACLE_HOMEs. It requires the Perl language interpreter and requires, at minimum, Perl version 5.005_03 or higher.  Version 5.6 or higher is recommended.

OPatch expects jar, java, ar, cp, and make commands (depending on the platform) to be available in the current PATH. EBS users have these available as part of the current PATH once the respective tier environment file is sourced.

What Does OPatch Do?

In Oracle E-Business Suite releases where a Rapid Install option is available, the installation process installs and maintains the OUI inventory for each of the ORACLE_HOMEs using OPatch. A query of each of the ORACLE_HOMEs created by a Rapid Install lists the patches installed.

OPatch can be used to:
  • Apply an interim patch

  • Roll back the application of an interim patch

  • Detect a conflict when applying an interim patch after previous interim patches have been applied. It also suggests the best options to resolve a conflict.

  • Report on installed products and interim patches.
Key OPatch Concepts
Oracle Universal Installer
When an installation is performed using the Oracle Universal Installer, the OUI inventory records the ORACLE_HOME, SID, location, products and technology versions installed.  The E-Business Suite Rapid Install maintains a global inventory of all its Oracle products. The location on Linux is specified in the /etc/oraInst.loc file.

[Editor:  Also see: Oracle Universal Installer Inventory Essentials for Apps Sysadmins]

OraInst.loc

The file on Unix where the inventory location and the OS group of the install user.

patch_storage directory

This directory stores information about the patches applied.
Important OPatch Runtime Options and Arguments
OPatch is located in the <Path_to_Oracle_Home>/OPatch directory.  You can run it with various commands and options. The following string shows the syntax for the OPatch utility:
<Path_to_OPatch>/opatch [-help] [-r[eport]] [command] [-option]

opatchhelp.png

The most commonly-used commands running OPatch are:
1. opatch apply ...

This command applies a patch from the patch directory.  The OUI inventory is updated with the patch's information.

2. opatch rollback ....

This is the command to rollback or undo a patch installation. The respective patch information is removed from the inventory.

3. opatch lsinventory

lsinventory lists all the patches installed on the Oracle Home.

4. opatch lsinventory -detail

lsinventory -detail gives list of patches and products installed in the ORACLE_HOME.

5. opatch version

version option displays the version of OPatch installed.

6. opatch napply

napply applies the patches in a directory. This is used in EBS environments while applying a patch that is a bundle of individual patches. napply eliminates the overhead of running opatch multiple times by the administrator. The napply option skips subsets or duplicates if they are already installed.

7. opatch nrollback

nrollback rolls back the patches using the IDs specified.

8. opatch  apply -minimize_downtime

This is specific to Real Application Clusters (RAC) enabled instances (DB tier patches).  The -minimize_downtime option allows you to apply a patch by bringing down one database server instance at a time.  OPatch applies the patch to the quiesced server instance, the instance is brought back up, and then OPatch moves on to the next database server  in a Real Application Clusters pool.

9. opatch apply -force

-force overrides conflicts with an existing patch by removing the conflicting patch from the system.

Caution: This option should be only used when explicitly it is said safe to be used in the README of the patch.

10. opatch apply -invPtrLoc <...>

The option -invPtrLoc can be used to specify the oraInst.loc file in case it's not in the default location e.g., /etc/oraInst.loc in Linux.  The argument to this option is the location of this file.

11. opatch query

The query command can be used to find out useful information about the patch

Syntax to be used:

opatch query  [-all] [-jre <LOC> ] [-oh <LOC> ] \ 
[-get_component] [-get_os] [-get_date] [-get_base_bug] \
[-is_rolling_patch] [-is_online_patch] \
[-has_sql] [ <Patch Location> ]

all

Retrieves all information about a patch. This is equivalent to setting all available options.

get_base_bug

Retrieves bugs fixed by the patch.

get_component

Retrieves components the patch affects.

get_date

Retrieves the patch creation date and time.

is_online_patch

Indicates true if the patch is an online patch. Otherwise, the option is false.

is_rolling_patch

Indicates true if the patch is a rolling patch. Otherwise, the option is false.

oh

Specifies the Oracle home directory to use instead of the default directory. This takes precedence over the ORACLE_HOME environment variable.

Patch Location

Indicates the path to the patch location. If you do not specify the location, OPatch assumes the current directory is the patch location.

Where's the Official OPatch Documentation?

A well written User Guide and FAQ are shipped with every OPatch version and are available under the OPatch/doc directory of the ORACLE_HOME. These documents list all the arguments and options available with OPatch.

I strongly recommend the administrators who are in charge of applying the patches to carefully read the above documents as well as the ORACLE_HOME version-specific OPatch documentation on Metalink. Latest OPatch versions for 10.1, 10.2 and 11.1 are available for download via Patch 6880880

A New Option For Critical Patch Updates (CPU)

Oracle introduced the napply option in July 2007 with Critical Patch Updates for its DB tier patches on Unix platforms for 10gR2 version 10.2.0.3 and higher. This provides conflict resolution and the ability to merge patches for CPU fixes.  This eliminates the CPU merge patch.  It also reduces downtime by eliminating the need to rollback and reinstall patches that are already installed. Customers can continue to partial apply and get other security fixes in place while waiting for a merge conflict resolution from Oracle's Database Support team.

Common OPatch Issues
Conflicts Between Patches
Conflicts occur when you try to apply a patch whose fix already been applied through another patch.  DBAs are advised NOT to use the -force option with apply as this removes the conflicting fix from the system. All conflicts need to be resolved by contacting Customer Support.

Errors due to Java locations


Make sure that the Java JDK and JRE prerequisites are available in the PATH or provided in command line option. The -jre and -jdk options allow you to specify these explicitly instead of using the ones from ORACLE_HOME.  EBS customers generally do not need to specify -jre or -jdk options because sourcing the respective ORACLE_HOME .env file will include the correct jre/jdk locations in the PATH.
References
Related Articles

Friday Aug 21, 2009

Configuring SSL with a Configuration Wizard in EBS R12

E-Business Suite R12.1.1 provides Advanced Configuration wizards that make it easier to deploy features such as SSL and load-balancing.  Apps administrators can use these wizards to make configuration changes online through Oracle Applications Manager (OAM) and then run AutoConfig on the applications tier to make the changes effective.

SSL (Secure Sockets Layer) is one of the most commonly used configurations in EBS. I'll walk through the SSL Advanced Configuration Wizard in this article.

Accessing the Advanced Configuration Wizards

Launch the Oracle Applications Manager Site Map using the System Administrator responsibility, then select the AutoConfig link from the Administration tab.

Wizards_Welcome.png

Click on Launch Wizards. It brings up the launch pad for five wizards:

  1. Forms Socket Mode
  2. SSL
  3. SSL Accelerator
  4. HTTP Load Balancing
  5. OC4J Load Balancing

Wizards_Home.png

Start the SSL Configuration Wizard

The OAM General Collection Service must be activated before running any configuration wizards.  From the Administration tab of the Site Map, click on the 'Generic Services' link under the Application Services. Select 'OAM Generic Collect Services' and start it for the target instance. OAM submits a concurrent request for the same. Click on Verify to see if the service starts up fine. Once the service starts, you are ready to use the wizard.

From the Configuration Wizards launch pad, click on the 'Enable' button for SSL.

Select Nodes to be SSL-Enabled

Select the nodes on which you would like to enable SSL and click 'Next.'

SSL1.PNG

2. Set Context variables for SSL

Notice the tip at the bottom of the Parameters screen:  you should make sure that your digital certificates are properly imported into the Wallet of your EBS instance. For details about importing SSL certificates, see:

SSLParam.png

The wizard sets the following context variables to 'https':

  • URL protocol
  • Local URL protocol

It also sets values for the 'Web SSL directory' and the 'Active HTTP SSL port.' The subsequent screen gives the current and new values for these variables.

3. Validation

The wizard validates all settings when you click 'Next' after the user comparison of context values screen.  It checks that the Wallet and the required directory structures exist.

SSLValidation.png

Make sure that the Status is 'Success.' Check the log file in the 'View' link for any errors.

4. Confirmation Page

Clicking 'Next' will take you to the Confirmation Page in the train cart. Click on the link below to check the confirmation page.

View image


5. Submit the changes and run AutoConfig

Clicking the 'Submit' button on the Confirmation page displays the next action to be taken. You can review the context file on the applications tier for the changes that have been made.

The next step is to run AutoConfig to propagate the changes. You need to restart all application services to make the changes effective.

Once the service have been restarted, the EBS instance is ready to be used in SSL mode.

References

Related Articles

Wednesday Aug 19, 2009

Creating an EBS R12 Instance Using the Express Install Option

The Oracle E-Business Suite Rapid Install provides an easy-to-use Express Install option. This option sets default values for several of the customizable inputs that the Apps DBA must enter in subsequent screens. Express Install is convenient for test instance setup as well as for training purposes. Note that this option is valid only for new installations and cannot be used for upgrades.

 

WelcomeRI.png

How to Use Express Install?

Assuming that you have met all the prerequisites to perform a Rapid Install on your machine based on the platform specific installation guides, Express Install can be performed using rapidwiz. The inputs required to use Express install are:

1. Oracle Configuration Manager

    • Email ID and the My Oracle Support password
    • Check box indicating if you would like to receive Security Updates via My Oracle Support.

OCM.PNG

2. Configuration choice

Here you specify whether you would like to create a new configuration or use an existing configuration file that has been saved from a previous run of rapidwiz.

RIConfig.png


3. Node information (if you have chosen to create new configuration above)

Specify the following parameters:

  • Database Type (Fresh database or Vision)
  • Database SID
  • Domain name
  • Base directory for the installation (by default, entire install including APPL_TOP and DB is placed in this directory)
  • Instance directory (default value is <base directory>/inst )
  • Port pool

Express1.png

That's it!  After making sure that the System Checks all pass in the Preinstall Checks window that follows, you are ready to perform an Express Install.  After this, the installation proceeds requiring no human intervention.  Upon completion of the install, you are ready to use the EBS instance.

Can it get any easier?

References

Related Articles

Thursday Aug 13, 2009

Recommended Database Parameters Updated for EBS 11i

Experienced Apps DBAs know that there are often compelling reasons to tweak the E-Business Suite's database initialization parameters from the defaults.  The master source-of-truth for whether certain parameter settings will help or hurt your EBS environment performance is published here:

Our EBS database architects have just released an updated version of that Note.  Recent updates over the last month include a number of important changes and additions to our recommendations for:

  • Database parameters that should be removed for 10gR2 (10.2.x) databases
  • Database parameters that should be removed for 11gR1 (11.1.x) databases
  • Advanced Queuing (AQ) additions to 10gR1, 10gR2, and 11gR1 recommendations
  • Database initialization parameter sizing recommendations for processes, sessions, db_block_buffers, db_cache_size, sga_target, undo_retention, shared_pool_*, pga_aggregate_target, and total memory required for different numbers of concurrent users
  • New links to related documents

One of our architects wryly observed that this relatively-short list of changes belies the actual importance and impact of the changes to our recommendations. 

Don't be fooled -- these changes are extremely important and can have profound impact on the performance of your Apps database.  All Apps DBAs should spend some quality time comparing your current database settings with the latest recommendations in this document.

Related Articles

 

Wednesday Aug 12, 2009

Confused About E-Business Server vs. Desktop Operating System Certifications?

The E-Business Suite is designed to support a three-tier architecture, with functions running on a client tier, an application server tier (also called a middle tier), and a database tier.  I handled a customer question on an internal Oracle mailing list today that suggested that there was confusion about our certification policies for these tiers.  I then realized that I've answered variants of this question many times lately, so it's clearly of broader interest. 

These two questions are mirror images of each other:
  • Can I install the E-Business Suite on a desktop operating system like Windows Vista?
  • Can I run end-user E-Business Suite functions on a server operating system like Oracle Enterprise Linux?
EBS-R12-architecture-diagram2.png
Certifying End-User Functions on Desktop Operating Systems

The first guiding principle is that we certify E-Business Suite end-user client functions on end-user desktop operating systems.  Examples of EBS end-user client functions include:
  • Accessing web-based Self-Service applications from browsers
  • Running Forms-based applications under the native Sun JRE plug-in.
The certified end-user desktop operating systems are:
  • Windows XP
  • Windows Vista
  • Mac OS X
We intend to certify Microsoft Windows 7 and Apple Mac OS X Snow Leopard (10.6) desktop operating systems to run EBS end-user client functions in the future.  I can't discuss schedules for these certifications, but you're welcome to monitor or subscribe to this blog for updates.  

We have no current plans to certify Linux desktop operating systems (e.g. Ubuntu, Fedora, Debian, CentOS, etc) to run E-Business Suite end-user client functions.

Certifying Server-Based Components on Server Operating Systems
 
The second guiding principle is that we certify E-Business Suite's server-based components on server-based operating systems.  Server-based components are designed to run on application tier servers and database tier servers.  Server-based components include the Oracle Database, Oracle Forms, JServ, OC4J, and so on.

Server-based operating systems include:
  • Microsoft Windows Server
  • Red Hat Enterprise Linux
  • Oracle Enterprise Linux
  • Sun Solaris
  • IBM AIX
  • IBM Linux on System z
  • IBM Linux on POWER
  • HP-UX
  • SUSE Linux Enterprise Server (SLES)
Mixing and Matching Server vs. Desktop Certifications

We have no plans to certify E-Business Suite end-user client-based functions on server operating systems. 
 
Likewise, we also have no plans to certify E-Business Suite database or application-tier server components on end-user desktop operating systems. 

Security Implications of Running Something on the Wrong Platform
 
The security implications of running the wrong thing on the wrong platform must be considered.  Today's question from a customer asked whether it's possible to run the E-Business Suite's end-user functions from geographically-distributed machines running Windows Server. 

Now, I'm assuming that those distributed machines are acting as real servers running mission-critical multi-user applications.  If I were a security administrator, I wouldn't want an end-user to use that server to do email, surf the web, or run other end-user applications.  Given the propensity of end-users to click on suspicious email attachments, hit questionable websites, and install dodgy P2P apps, that's a good way of contaminating the server and breaching security.  I can't think of any scenario where this would be a good idea.

Support Implications of Running Something on the Wrong Platform

We can't prevent customers from doing dangerous things with machines connecting to the E-Business Suite.  I'm reminded of Robin Williams' piece on unarmed bobbies in the UK: "Stop, or I'll yell, 'Stop' again!"  [No, no, I'm not making any statements about gun control either way, I'm just underlining Oracle's lack of omnipotence.]

What we can do is ensure that you get fixes for issues that occur on the tiers on which EBS components were designed to run. 

From a support perspective, we can produce E-Business Suite patches only for end-user client issues that can be reproduced on a certified desktop operating system configuration.

Likewise, we can produce E-Business Suite patches only for server-based component issues that can be reproduced on a certified server operating system.

Related Articles

Friday Aug 07, 2009

Oracle Universal Installer Inventory Essentials for Apps Sysadmins

We see quite a few Service Requests (SRs) where E-Business Suite customers have gotten into difficulty with the Oracle Universal Installer (OUI) Inventory.  It's important to note the Oracle Universal Installer Inventory has nothing to do with the Oracle E-Business Suite Inventory product (product code INV).

Screenshot of generic Oracle Universal Installer dialog box

The Oracle Universal Installer Inventory is a component of the OUI and creates a record of the Oracle homes, products and patches you have installed on a node. Whilst it's not part of the E-Business Suite, as an Applications DBA it's inevitable that sooner or later you will have to look after the Inventory. This article will focus on issues relating to the OUI Inventory specifically within the context of Oracle Applications.

An Overview of the OUI Inventory

The Oracle Universal Installer Inventory comprises three main components:

  • The Pointer File
  • The Central (Global) Inventory
  • The Home (Local) Inventory

Central Inventory and Home Inventory are the official names, however, almost everybody talks about the Global and Local Inventory so it's useful to mention this now as the terms are often used interchangeably.

The Pointer File, created or referenced when running the OUI or rapidwiz, is called oraInst.loc and is used to either locate an existing Central Inventory or tell OUI where to create a new Central Inventory. It's a simple text file, stored, by default, in a system directory. In the Microsoft Windows environment it is stored in the registry key \\HKLM\Software\Oracle\INST_LOC.

The Central Inventory records details of Oracle homes installed on a node. A single node might contain one Central Inventory with details of all Oracle homes on that node, or a single node might contain multiple Central Inventories each one containing details of a single Oracle home.

The Home Inventory is specific to, and contained within each Oracle home, and contains details of patches or updates applied to that specific Oracle home.

This article will concentrate on the Central Inventory as, generally speaking, the Home Inventory looks after itself.

Central Inventory Differences Between Apps 11i and R12

In Apps 11i, the default action was to use a single Central Inventory -- that is, one Central Inventory per node -- which recorded all Oracle homes installed on that node. The Central Inventory Pointer File was stored in a system directory to which you had to have write access. This was why during an EBS 11i installation, or when cloning to a new node, you would be prompted to run scripts as the root user before you could complete your installation or clone. If you had multiple 11i installations on a node, these would generally all be recorded in the same Central Inventory.

In Apps R12, things have changed. If rapidwiz is not able to automatically create a Pointer File in the default system directory, it will create multiple Central Inventories and multiple Pointer Files. Instead of prompting to run a script as the root user, a separate Central Inventory and Pointer File will be created in each Oracle home created on the node.

Things have the potential to get complicated when you have multiple Oracle Applications installations on a single node, or where 11i and R12 installations are both installed on the same node. Start cloning to and from this same node and soon you may be forced to pay attention to the Inventory.

How EBS Creates and Updates the OUI Inventory

Here are a couple of typical examples of how the OUI Inventory is configured during an Oracle Applications installation.

Scenario 1: Upgrading Apps 11i to 12 creates multiple Pointer Files and Central Inventories

A typical scenario might be that you have an 11i test environment installed on your node. You plan to upgrade sometime soon and wish to install a simple R12 test environment on the same node.

By default, the operating system user installing R12 will probably not have permission to update the Central Inventory created by the previous 11i installation. In this case, multiple additional Pointer Files and Central Inventories are created within the new R12 Oracle homes. This in itself is not a problem but it is important that you understand that this may be what is happening.

Scenario 2: Upgrading Apps 11i to 12 updates the Global Inventory

Using the same starting scenario as above, if your R12 operating system user has write access to the Global Inventory created by 11i, then rapidwiz will update that Global Inventory with details of the new Oracle homes installed. Again, this is not a problem, but it is important that you are aware of what is happening.

When multiple Central Inventories exist, you must to be aware of this, as the correct Pointer File will need to be specified when maintaining the Oracle homes to maintain the correct Central Inventory.

Updating the Inventory When Removing an 11i or R12 environment

With the potential for single or multiple Global Inventories being created or updated, it’s important that when you delete an Oracle Applications environment from a machine, you make sure its corresponding Global Inventory entry is also updated correctly.

If your node is using a single Global Inventory and you wish to delete an Oracle Applications environment, it is not enough to just shut down the database and all the services and delete the software. This will leave a record of the installation in the Global Inventory.

To completely remove an installation, you must run OUI and use the graphical interface or the OUI command line to update the Global Inventory to record that the installation has been removed. If this is not done, then the Global Inventory retains a record of an environment that no longer exists on the node.

If you were to then perform a new installation or clone to that node at the same location as the previously removed installation, there would be a failure to correctly register the new installation. This could easily create an Oracle Applications installation which does not work correctly, or has links to non-existent locations. You might also have problems upgrading the technology stack or applying patches to this environment at a later date.

Tools for Managing the Inventory

Fortunately, there are various tools that allow you to check the condition of the Global Inventory on a node:

  • The Opatch utility has some useful command line parameters which allow you to interrogate and report on the condition of the inventory.
     
  • OUI and OPatch also support the “invPtrLoc” parameter which allows you to specify the inventory Pointer File you wish to use when you install or patch a product.

If you encounter a situation where your Oracle home is not correctly recorded in a Global Inventory, it is also possible to create or update the Central Inventory. There are several notes (see links in the Reference section below), which explain how to create or update the Central Inventory. There is also a note on how to consolidate multiple Central Inventories on a node into a single Central Inventory.

There is sometimes the temptation to manually edit the XML files that make up the Central or Home Inventory. Don't give in to temptation. The OUI Inventory should only be updated via Oracle tools such as the Oracle Universal Installer itself, the Rapid Install (rapidwiz), Opatch, and RapidClone.

Checking the OUI Inventory Log Files

During an installation or clone of Oracle Applications, the inventory creation or updating process is recorded in the log file called ohclone.log. The ohclone.log file will tell you if any aspect of the registration process has failed. You should always check this (and other log files) as part of your installation or cloning process.

Four Tips for Maintaining a Healthy Inventory

If you spend a lot of time installing and removing Oracle Applications environments and and have not really thought about the inventory in the past, you should keep the following in mind:

  1. Always deinstall the Oracle Applications technology stack using the OUI before deleting the software.
  2. Always check the ohclone.log after an installation or clone.
  3. If you know how your OUI Inventory is currently arranged, you should be fine. If you don’t, you should take a little time to familiarise yourself with the setup.
  4. Do not try to manually edit files that make up the Global or Local Inventory.

References

Tuesday Aug 04, 2009

Is It Safe to Use SANs for EBS R12 Instance Tops?

Our documentation about sharing filesystems between multiple Oracle E-Business Suite Release 12 application servers recommends that you install the Instance Top (INST_TOP) on a local filesystem. This has prompted an interesting discussion about whether this is really mandatory, or whether it's technically feasible to put the Instance Top on, say, a dedicated fibre-attached SAN. 

Release 12 shared filesystem:

Our guidance on the INST_TOP being installed on a local file system is based on three major considerations:

  1. Separation of duties and security implications
  2. Impact of SAN performance on Apache
  3. Additional troubleshooting complexity

1. Separation of Duties & Security Implications

Our recommended configuration allows for different file system privileges and ownership between the Instance Top (INST_TOP) and the Code Top (ORACLE_HOMEs & APPL_TOP). This allows for the segregation of duties between administrators for the respective servers. Patching can be done on the Code Top by central system administrators who own the central shared portion of the file system. Instance Tops can be owned by instance sysadmins, who usually already own the CPU box with local storage.

Some instance-specific, run-time-generated files (e.g. reports, temp files) can include unencrypted data. Contrast those with database files (DBFs), which can be self-encrypted or contain encrypted data. Even with encrypted file system solution in place, there is less depth in defenses around some of the INST_TOP files.

2. Impact of SAN Performance on Apache

Apache performance is highly sensitive to mutex file access latency, and at higher loads is also sensitive to I/Os per second.  We tried using a central SAN for INST_TOPs in our internal EBS development environments but found the performance to be unacceptable.  However, not all SANs are created equal, and depending on the SAN, it might be good for even production use.

A very good article on this point is available from the SQLTeam web site:

3. Additional Troubleshooting Complexity

A network storage access problem can have a spectrum of symptoms, including performance slow downs and even as intermittent end-user session failures. Some of the affected code paths were made more resilient over the years, but we still prefer to err on the side of prudence and not potentially cause these (hard to diagnose) problems.

Your Mileage May Vary

All that said, you might decide that your testing of SAN performance demonstrates that its latency and I/O transaction throughput are good enough for your requirements. 

Our Support and Development teams will attempt to reproduce any reported issues in a multinode environment where the INST_TOPs are stored on a local filesystem.  If the issues are isolated to the external placement of the Instance Tops, our recommendations would be to either revert back to local storage, or to work with your SAN vendor to optimize the SAN's performance.

References

Related Articles

Wednesday Jul 08, 2009

Choosing a Shared File System for Oracle E-Business Suite

[March 18, 2013 Update: Added ACFS information captured in the comments to the article body]

[March 10, 2010 Update:  OCFS2 for Linux is now certified for EBS 12 application tier servers; see this article for details.]

It's possible to scale up your E-Business Suite environment with multiple application tier servers to improve fault tolerance and performance.  It's also possible to share a single filesystem between them: all application tier files are installed on a single shared disk resource that's mounted from each application tier node.  In Release 12, that would look like this:

Release 12 shared filesystem:

This allows you to apply patches once to the central filesystem, rather than maintaining each application tier server node individually.  We recommend this approach; it reduces maintenance overheads for those multiple servers and shortens your patching downtimes. 

Beginning with Oracle E-Business Suite Release 12, we also allow you to share an applications tier file system between multiple E-Business Suite database instances, too. For more details about this advanced option, see this article.

Customers embarking upon this path inevitably ask, "Which shared filesystem do you recommend?"  The short answer is that we don't recommend any specific filesystem, but there's more to it than just that.

Does Oracle Certify Storage Systems?

Not any more.  Our Server Technologies division used to run an Oracle Storage Compatibility Program (OSCP) to validate specialized storage products.  At one time, Oracle and its partners worked together to validate specialized storage technology including NFS file servers, remote mirroring, and snapshot products.  The storage industry matured over time, and this program was ended in January, 2007. 

The successor to this program is the Oracle Certification Environment (OCE) group.  This group provides resources for third-party vendors to certify their own products with Oracle technology.  The OCE team works with Oracle Partner Management and third party vendors for approving support statements published by third party vendors with respect to certification projects with Oracle.

It's important to note that these certifications are performed by the third-party vendors themselves and not the E-Business Suite Development division.  Certification statements made by third-party vendors partnering with the Oracle Certification Environment group are not reviewed or endorsed by the E-Business Suite division.  

Does the E-Business Suite Division Certify Storage Systems?

No, I'm afraid not.  EBS Development doesn't have the resources to certify or compare even a subset of the leading filesystems.  Since we don't have hands-on experience with different filesystems in a controlled test environment, we can't make any informed recommendations for a given product.  We generally suggest that customers either perform their own product testing or consult a trusted consultancy that compares the relative merits of each product against a consistent set of criteria.

What are the EBS Requirements for a Shared Filesystem?

Shared filesystems must be transparent to the calling application, in this case, the E-Business Suite.  In other words, no modifications to the E-Business Suite should be necessary to ensure compatibility with the shared filesystem.

Our Frequently Asked Questions: Sharing the Application Tier File System in Oracle Applications 11i (Note 243880.1) states:

... your shared application tier file system can reside on any type of shared disk resource. Examples of shared disk resources include an NFS mounted disk or a disk array. The shared disk resource does not have to be local to the machine, and it can also be a standalone disk array. Usual tuning considerations apply.

The same thing applies to Oracle E-Business Suite Release 12, too.

What About OCFS2 or GFS?

There are many different shared filesystems out there, too many to list here.  The general statements about EBS requirements for a shared filesystem above apply to all third-party file system products.

However, we get a lot of questions about three specific products due to their close relationship and packaging with Oracle's own operating system releases:

Here's the E-Business Suite position on these three shared file systems:

Oracle Clustered File System (OCFS2)

The E-Business Suite's database tier is built on the Oracle Database.  The Oracle Database is certified with OCFS2.   Therefore, OCFS2 is supported for the E-Business Suite database tier, too. 

The E-Business Suite's application tier is built on Oracle Application Server.  Oracle Application Server is not yet certified to run on OCFS2. 

If our Fusion Middleware group ever certifies Oracle9i Application Server 1.0.2.2.2 (used by Apps 11i) or Oracle Application Server 10g (used by Apps 12) to run on OCFS2, then the E-Business Suite's application tier will be certified on that file system. 

Red Hat Global File System (GFS)

Specific versions of the Oracle Database are certified with GFS running on specific Red Hat and Oracle Enterprise Linux releases.   Therefore, those GFS combinations are supported for the E-Business Suite database tier, too.

Sadly, I haven't been able to locate any externally-published statements about Oracle Application Server compatibility with GFS.  This usually means that these two products haven't been tested together.  If you want an explicit statement of support for GFS for Fusion Middleware products, your best bet would be to log a Service Request against the Oracle Application Server product in question.

Back to the database and GFS:  there are some special support provisions for this database configuration.  See the "Support Process for GFS 6.0 and 6.1" section of Using Redhat Global File System (GFS) as shared storage for RAC (Note 329530.1), which states:

Oracle's product support teams will not take support calls on Red Hat GFS. All issues known to be related to Red Hat GFS must be opened with Red Hat directly. When an Oracle SR is opened for an Oracle product or a Red Hat Enterprise Linux issue in a configuration that includes GFS, Oracle Support will do their best effort to determine if the issue is GFS software related. In that case, Oracle will hand-off the GFS related issue to Red Hat Support.

It's important to note that the E-Business Suite division does not test the E-Business Suite with GFS. We haven't performed any certification or compatibility tests with that filesystem and don't have any empirical data about how well this particular combination will work.

Oracle ASM Clustered File System (ACFS)

  1. The E-Business Suite database tier is certified on ACFS.
  2. The E-Business Suite application tier is not certified on ACFS.

Most Oracle Database releases are certified to run on ACFS.  You can refer to the Certify database on My Oracle Support for the latest supported certifications. You can run EBS database servers for those certified combinations on ACFS.  

Amongst other things, EBS 11i uses Forms 6i, Oracle9i Application Server 1.0.2.2.2, and JServ on the application tier.  EBS 12.0, and 12.1 use Forms 10g, Oracle Application Server 10g, and OC4J on the application tier. on ACFS.  These Fusion Middleware product versions are not certified on ACFS.  There are no plans for those certifications.  Since the E-Business Suite depends on those products, EBS 11i, 12.0, and 12.1 application tiers cannot run on ACFS.

What Does EBS Development Use Internally?

We're in Development, not marketing, and we're expressly not able to endorse third-party products.  What we can do is give you a glimpse of what we use internally within Oracle for the E-Business Suite Development division.

At any given time we have hundreds of E-Business Suite environments running simultaneously within the EBS Development division.  These are centrally managed by our terrific EBS/Fusion Operations group.  This internal Oracle group has has created some really interesting infrastructure over the years.  One of the most useful custom solutions allows developers to get a new EBS environment on demand.  Shortly after their request, an automated process instantiates a new Apps environment and the developer is off to the races.

The underpinnings of this are Network File System (NFS) mounted filesystems running on NetApp.  Our Operations group has tested ZFS-based filers, which are also NFS-mounted filesystems.

In practical terms, this means that nearly all of our development, testing, and certification environments for the E-Business Suite are all running on NFS mounts.  We explicitly assume that our use of NFS generalizes to all shared file systems. 

What Does Oracle Use Internally for its Production Global Single Instance?

Our EBS development use of NFS is paralleled by Oracle's own global single instance deployment of Apps 12.  Our production EBS instance connects via Gigabit Ethernet to a shared NFS (NAS) NetApp FAS960 clustered storage system running NetApp 7.2.4. 

Our four production Sun F25K database servers are equipped with 44 dual core CPUs and over 176 GB RAM, Sun Solaris 9, Sun Cluster 3.1, and Veritas VxVM/VxFS 4.0* mp02.  Each of these database nodes has three GigE cards connecting them to the backend database storage, an EMC Symmetrix DMX3000 storage system.

Architecture diagram of Oracle's own global single instance EBS 12 deployment

Remember, this isn't an endorsement or a recommendation; it's merely a peek into what we use here internally at Oracle.

References

Related Articles

Friday Jul 03, 2009

Comparisons of E-Business Suite Release 12 Rapid Install Techstacks

[Jul 6, 2009 Update: Database version for 12.0.4 Rapid install was 10.2.0.3, not 10.2.0.4. Table corrected now.

A reader recently asked where she could find a summary of the E-Business Suite Release 12 technology stack components for different R12 releases.  As it turns out, there's a long answer to this deceptively-simple question.  This level of information is spread in a variety of release-specific Notes, making it tricky to compare which components were delivered as part of each Apps 12 Rapid Install. 

Here's a high-level architectural diagram showing an overview of the major techstack components in R12:

Oracle E-Business Suite Release 12 architecture diagram showing three tier database application server client and major techstack components

It's possible to add on additional database options not shown above, including 11g Advanced Compression, 11g Advanced Security, and others. 

Here's a summary of the versions for the important major techstack components that were included in the Rapid Install footprints for Oracle E-Business Suite Release 12:

EBS Release 12 Rapid Install Version
12.0.0 12.0.4 12.1.1
Database 10.2.0.2 10.2.0.3 11.1.0.7
OracleAS 10.1.2 Forms & Reports 10.1.2.0.2 10.1.2.2 10.1.2.3
OracleAS 10.1.3 OC4J 10.1.3.0.0 10.1.3.0.0 10.1.3.4
App Tier Java (JDK) 1.5.0_10 1.5.0_13 1.6.0_10
Desktop Client Java (JRE) 1.5.0_10-erdist 1.5.0_13 1.6.0_u10

The Case Against Finer-Grained Listings for Internal Components

The table above shows only the major internal components that Apps DBAs can upgrade themselves.  Individual upgrades for finer-grained components aren't required or recommended unless you're experiencing a particularly severe bug.  There are approximately 120 technology stack components in the E-Business Suite.  The fine-grained listings of these components are important to us in EBS Development, since we build the E-Business Suite on them, but they're mostly irrelevant to EBS sysadmins whose goal is maintaining their systems. 

For example, we track the versioning of individual application tier components like OJSP, Servlet, and SOAP separately from the overall Oracle Containers for Java (OC4J) component.  That doesn't affect your configuration management and operational plans, though.  An Apps sysadmin would simply install the latest certified Oracle Application Server 10g 10.1.3 update to get all of the latest 10.1.3 components bundled with that release.

Integrating EBS with External Oracle Products

Naturally, it's possible to integrate your EBS environment with a variety of other Oracle products.  These products can be running on external -- i.e. physically standalone -- servers or in a separate ORACLE_HOME on the same server where the E-Business Suite instance is installed. 

Commonly used external integrations are Single Sign-On and Oracle Internet Directory, used respectively for integrating with existing corporate authentication systems like Windows Kerberos, and with existing LDAP directories like Microsoft Active Directory.  External certified product integrations for the E-Business Suite are summarized here.

Updating Individual EBS Components After a Rapid Install

Using Rapid Install to create your initial E-Business Suite environment is convenient, but new Apps DBAs should understand that this is a starting point.  Your journey doesn't end here -- it begins.  If you haven't already seen these two articles, they're mandatory reading for Apps DBAs:

We regularly release new certifications for EBS technology stack components.  Our certification announcements archive tells the tale.  Including incremental announcements for specific operating system platforms and special architectures, we released almost 40 new certifications for Apps 12 in 2008.  We're already up to 20 new certifications for 2009. 

You can keep up with the news about the latest certifications by monitoring or subscribing to this blog.  If you're looking for a one-page summary of all of the latest technology stack components certified with the E-Business Suite, bookmark this Certification Summary.

Related Articles

Friday Jun 26, 2009

Roundup: Oracle JInitiator 1.3 Desupported for EBS Customers in July 2009

[June 29, 2009 Update: The July 2009 desupport date for JInitiator 1.3 applies to E-Business Suite customers only. Generic Oracle Forms customers should see Note 761159.1 for generic JInitiator desupport dates.]

We've covered the impending demise of JInitiator and the certification of the native Sun Java client in many articles already.  With the sun setting on Oracle Jinitiator next month, this is a good time to summarize the essentials about running Windows-based Java clients with the E-Business Suite:

  1. Sun's Java Runtime Engine (JRE) is certified with both EBS 11i and 12
  2. JInitiator 1.3 will be desupported for E-Business Suite customers at the end of July 2009
  3. JInitiator 1.1.8 was desupported at the end of December, 2008
  4. JInitiator cannot be run on Vista Desktops

If you haven't already started migrating your E-Business Suite end-users to the native Sun JRE plug-in, I'd strongly recommend that you begin this process immediately.

Sun Java Website screenshot Screencap of Sun's Java SE website

1. Sun's Java Runtime Engine (JRE) is Certified with EBS 11i & 12

Oracle JInitiator was originally released as a licenced version of Sun's Java client back when specific features were required to support Oracle Forms. This was particularly necessary for E-Business Suite Forms-based functionality, since the E-Business Suite pushed the envelope of what Forms and Java could do collectively from a user interface perspective.

Sun has since incorporated all of the enhancements needed to support Oracle Forms into their native Sun Java Runtime Engine plug-in. This eliminates the need for Oracle to package its own Java client just for running Oracle Forms-based applications. 

To convert your E-Business Suite environment from JInitiator to the native Sun Java plug-in, see:

Benefits of Switching to the Sun Java Client

The elimination of Oracle JInitiator simplifies your desktop administration environment.  Apps DBAs who have migrated their users to the native Sun JRE no longer have to struggle with compatibility and coexistence problems between JInitiator and other Java runtime clients on the same desktop.

Minimizing Risks of Switching from JInitiator to Sun Java Clients

The majority of customers switching from Oracle JInitiator to the Sun Java Runtime Engine have experienced minimal issues with this conversion.  However, some customers have reported problems, some rather painful.  Problems typically fall into the following categories:

  1. Missing prerequisite E-Business Suite patches or configuration steps
  2. Known issues, e.g. focus-related problems
  3. Conflicts with legacy Java-based application requirements

I strongly recommend a careful review of the Notes above, to ensure that you don't miss any prerequisites or configuration steps.  We document all of the known issues in the respective Notes for Oracle E-Business Suite Release 11i and 12.  We also update our Notes regularly whenever we find new JRE-related compatibility issues with the E-Business Suite.

Some of you might have legacy Java-based applications that require earlier Java clients.  Those legacy applications might only be certified with an old Java release like 1.4.x, and will not work with later JRE releases such as 1.5 or 1.6.  Oracle doesn't have much guidance on third-party Java application compatibility, naturally, so your best option in those situations would be to lobby your legacy application vendor to upgrade their certifications to include the latest Java clients. 

Sun has changed the options for handling multiple Java plug-ins through their "Classic Java Plug-in" and "Next-generation Java Plug-in" technologies.  Handling your requirements for multiple Java plug-ins will vary based upon the JRE versions installed and your default corporate browsers.  If you have multiple Java clients installed on the same Windows desktop, I would strongly recommend that you review the "Static vs. Non-Static Versioning and Set-Up Options" appendices in either Note 290807.1 or 393931.1. 

If you're encountering issues with your EBS conversion to use the Sun Java client, you might find the following document useful:

Minimum JRE Versions Required for E-Business Suite

Apps 11i was originally certified with Oracle JInitiator to run Oracle Forms-based content.  Apps 11i is now certified with the native Sun Java Runtime Engine plug-in.  Apps 11i end-users can use JRE releases on either of the following version levels:

  • JRE 1.5.0_13 and higher
  • JRE 1.6.0_03 and higher

Apps 12 was certified only with the native Sun Java Runtime Engine.  Oracle JInitiator is not certified or supported with Apps 12.

EBS Compatibility and Support for Future JRE Releases

E-Business Suite end-users can upgrade their JRE clients whenever Sun releases a new JRE release on either the 1.5 or 1.6 versions.  EBS users do not need to wait for Oracle to certify new JRE 1.5 or 1.6 plug-in updates with the E-Business Suite.

2.  JInitiator 1.3 will be Desupported for E-Business Suite customers at the end of July 2009

JInitiator 1.3.1.30 was the final certified version for Apps 11i.

Oracle JInitiator 1.3 was built on Sun's JDK 1.3.  Sun has long-since desupported JDK 1.3, so JInitiator 1.3 must be desupported, as well.  Oracle Forms Development has no plans to port JInitiator to JDK 1.4 or higher.

Support Implications for JInitiator Users

Here's what you can expect if you log an Oracle E-Business Suite Release 11i Service Request against JInitiator after the respective dates shown above:

  1. Oracle Support will help you diagnose and isolate the root cause of any compatibility issues between JInitiator and the E-Business Suite.

  2. If there's a workaround or an existing Forms or JInitiator patch, Oracle Support will help you obtain the fix.

  3. If the issue requires a new Forms patch and can be reproduced using the native Sun JRE plug-in, a new bug will be logged against Oracle Forms.

  4. If the issue cannot be reproduced with the native Sun JRE client, no new Forms or JInitiator bugs will be logged.

3.  JInitiator 1.1.8 was desupported at the end of December, 2008

JInitiator 1.1.8.27 was the final certified version for Apps 11i.

I know that some of you continue to run JInitiator 1.1.8 with your E-Business Suite Release 11i environments for legacy compatibility reasons.  I'm afraid that the time has come for you to retire JInitiator 1.1.8.  Error Correction Support for JInitiator 1.1.8 ended on December 31, 2008.  In other words, the Oracle Forms group will no longer issue bug fixes via new versions of JInitiator 1.1.8.x as of December 31, 2008.

The "Support Implications for JInitiator Users" section, above, applies equally to JInitiator 1.1.8, also.

By the way, Oracle Forms Development has (somewhat inexplicably) published Metalink Note 789049.1 indicating that JInitiator will be generically supported until March 29, 2010.  I can't say that I understand this, myself, but the December 2008 desupport notice for JInitiator 1.1.8 for Apps 11i clients is published in Note 472154.1.

4.  JInitiator cannot be run on Vista Desktops

It's not possible to run Oracle JInitiator 1.3 on Microsoft Vista.  Here's why:

  • Oracle JInitiator 1.3 is based on Sun's JDK 1.3
  • Sun's JDK 1.3 is incompatible with Vista.
  • Sun has desupported JDK 1.3, so they have no plans to make it Vista compatible
  • Therefore, JInitiator is fundamentally incompatible with Vista due to its JDK 1.3 dependencies

On Hacking Up JInitiator

Various creative individuals have discovered that it's possible to replace a certain DLL in Oracle JInitiator 1.3 with a JVM from, say, JDK 1.6.  I can't personally testify that these hacks work.  I can say that this kind of surgery makes me intensely uncomfortable.

While it's nice to see creative initiative, I have to remind you that Oracle would regard this as a customization.  We don't recommend customizing Oracle JInitiator for production environments.

What Happens When Something Goes Wrong?

If you do choose to customize Oracle JInitiator 1.3, you should consider the support implications for your users.  If you encounter any issues specific to your customized version of JInitiator, Oracle's default recommendation will be to use the native Sun JRE plug-in.

What Does Oracle Recommend for Vista?

We recommend using the native Sun Java plug-in for Vista client desktops connecting to either Oracle E-Business Suite Release 11i or 12.  The native JRE client is the only certified and supported Java client for E-Business Suite desktops end-users running on Microsoft Windows Vista.

Getting Support from Oracle for Your Conversion

Naturally, we're very interested in helping you get through this upgrade process with a minimum of pain.  If you hit any problems with your conversion to the native Sun JRE plug-in, please log a formal Service Request via Metalink.  Our Support engineers will work with you on this, and also track the underlying issues to see whether changes to our documentation or patches are warranted.  If necessary, we'll work with Sun to get fixes prioritized for future JRE releases, too.

Given my position in Oracle Development and the visibility of this blog, I sometimes think that my perspective on customer deployments might be a little skewed.  This blog's readers tend to be seasoned and highly-skilled Apps sysadmins and Oracle DBAs.  

I'd appreciate your help in getting an accurate view of how these conversions are going for you. I'd be very interested in hearing about your experiences, good or bad.  What went well?  What went sideways?  Please feel free to sound off in the comments or drop me a private email with more details about your migration.

Related Articles

About

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
4
5
6
7
8
9
10
11
12
13
14
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today