Sunday Nov 28, 2010

Using Two New Oracle Database 11gR2 Features With EBS

With the recent announcement of Oracle Database 11gR2 ( certification with Oracle E-Business Suite, we've also certified two new features with the E-Business Suite to make your life a little easier.

These two new features are:

  1. The Single Client Access Name (SCAN) feature that was introduced with the Oracle Database 11g Release 2 Grid Infrastructure to simplify client access to database services.

  2. No need to disable Fast Validation before performing Applications maintenance or upgrade operations.

Single Client Access Name support for EBS environments

Single Client Access Name (SCAN) is an Oracle Real Application Clusters (RAC) 11gR2 feature that provides a single name for clients to access Oracle databases running in a cluster. This means that the client's connect information can remain the same if cluster nodes are added or removed.

The SCAN feature is now certified for use with the EBS AutoConfig configuration management tool, and can be deployed with EBS by following the steps below.

  1. Meet the configuration prerequisites for using the SCAN listener, as per My Oracle Support Knowledge Document Using Oracle 11g Release 2 Real Application Clusters with Oracle E-Business Suite Release 12 (Doc ID  823587.1).

  2. Set the following AutoConfig parameters as shown below:
    • s_scan_name = <SCAN Name>
    • s_scan_port = <SCAN Port>
    • s_update_scan = <TRUE>
  3. Run AutoConfig on the EBS database tier to create SCAN configuration files on that tier.

  4. Run AutoConfig on the application tier to create SCAN configuration files on that tier.

No Need to Disable Fast Validation

With database versions prior to Oracle 11gR2 (, you needed to disable Fast Validation in the database when performing Applications upgrades or maintenance operations.

To disable Fast Validation, you needed to add the following parameter to the database initialization parameter file:


Failing to set this in Oracle Database 11gR1 ( or 11gR2 ( could lead to invalid objects and forms or reports compilation failures, potentially causing problems with product functional flows.

Starting with 11gR2 (, this parameter no longer needs to be set for upgrade or maintenance operations (and then unset again for normal operations).  This is one less thing for you to have to remember.


Related Articles

Wednesday Nov 17, 2010

EBS R12 Sparse Mid-Tier Template for Oracle VM Now Available

Yes, it's true: the title is not a typo. We have an Oracle VM (OVM) template that works against any E-Business Suite Release 12 version.  It works against your current E-Business Suite Release 12 installs, whether physical or virtual.

Instructions for downloading these new templates are here:

Screenshot of edelivery page for sparse Oracle VM downloads for ebs R12 application tier images sparseOVM.jpg
We listened to you: you wanted a small OVM template, and this one is small at around ~600MB.

How does this work?

On first boot, OracleVM machines based on this template will prompt for an exported Linux EBS shared file system location. They will mount it and create an Apps middle tier node which you can use to scale up your existing EBS instance or to start a new instance.

If you have development or testbed environments where you can re-use the database, this template is an easy way to create new Linux middle tiers.

Your Feedback is Welcome

We're extremely interested in hearing about your use cases and your experiences with our new templates and virtualization kit.  Tell us what you think via our new OVM Templates discussion forum.

Related Articles

Thursday Nov 11, 2010

Using Physical Standby for EBS 12 Environments on 11g Databases

Database disaster recovery, sometimes also lumped into the broader category of business continuity planning, is a topic that many EBS sysadmins seem to struggle with.  Oracle Data Guard is a set of services that create, manage, and monitor one or more standby databases to enable a primary database to survive disasters and data corruption. If the primary database becomes unavailable because of a planned or an unplanned outage, Oracle Data Guard can switch a standby database to the primary role, minimizing the downtime. 

Physical architecture diagram showing target architecture for an E-Business Suite Release 12 disaster recovery deployment

We've previously published EBS-specific documentation covering this for 10gR2 databases:
Our EBS database architects have recently updated that documentation to cover physical standby for both the 11gR1 and 11gR2 databases for E-Business Suite 12 environments.  This updated documentation has been streamlined and updated with our latest recommendations for disaster recovery environments using physical standby.  It's published here:
Related Articles

Wednesday Sep 15, 2010

Upgrading From EBS R11i to R12 Using a Staged System

Upgrades are always time-consuming and complex, so anything that makes the task easier and reduces the downtime needed is worth investigating.

A newly-supported technique for upgrading from Oracle E-Business Suite Release 11i to Release 12.1.1 involves use of a staged Applications system, in an extension to the already proven usefulness of this approach to patching within an EBS version.

We've recently expanded the following note to provide full details of the steps needed:
How does this work?

Traditionally, a staged Applications system represents an exact physical copy of a production system,including all APPL_TOPs and the production database. You can apply patches to a staged system while the production system remains in operation. After that, you connect the staged system to the production system, update the database, and synchronise the APPL_TOPs. This means that the downtime for the production system only needs to begin after all patches have been successfully applied to the staged system.

After the patches have been applied to the staged system, and the production system updated, you must export applied patches information from the staged system and import it into the production system. This ensures that the production patch history database is up-to-date.

Now certified for production upgrades from EBS 11i to 12

Having been used unofficially by some upgrade customers for a while, this strategy is now fully supported for use in performing an upgrade from Release 11i to Release 12.1.1. Although your mileage will vary, you should find that using the staged approach is significantly faster than the traditional upgrade route. 

The principles of using the staged approach for upgrading are simple: after meeting the applicable AutoConfig and Rapid Clone patch rerequisites, you create the R11i staged system. You then upgrade the staged system to R12.1.1 by updating the production APPL_TOP and database. Finally, you synchronise the patch histories of the production and staged systems.

Your feedback is welcome

One early adopter found that this shaved 12 hours off their total upgrade time.   We're extremely interested in hearing about your use cases and your experiences with this newly-supported upgrade technique. Please post a comment here or drop us a line with your thoughts.

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.

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

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 ( and 11gR2 ( 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

Saturday Apr 17, 2010

10gR2 Transportable Tablespaces Certified for EBS 11i

Database migration across platforms of different "endian" (byte ordering) formats using the Cross Platform Transportable Tablespaces (XTTS) process is now certified for Oracle E-Business Suite Release 11i ( with Oracle Database 10g Release 2.  This process is sometimes also referred to as transportable tablespaces (TTS).

What is the Cross-Platform Transportable Tablespace Feature?

XTTS_Supported_Platforms2 comparison of endian-ness of operating system platforms
The Cross-Platform Transportable Tablespace feature allows users to move a user tablespace across Oracle databases. It's an efficient way to move bulk data between databases. If the source platform and the target platform are of different endianness, then an additional conversion step must be done on either the source or target platform to convert the tablespace being transported to the target format. If they are of the same endianness, then no conversion is necessary and tablespaces can be transported as if they were on the same platform.

Moving data using transportable tablespaces can be much faster than performing either an export/import or unload/load of the same data. This is because transporting a tablespace only requires the copying of datafiles from source to the destination and then integrating the tablespace structural information. You can also use transportable tablespaces to move both table and index data, thereby avoiding the index rebuilds you would have to perform when importing or loading table data.

Obtaining the Required EBS Patch

This EBS database migration process was previously only available to participants of a TTS Early Adopter Program. This migration process currently requires a patch delivered by our EBS Platform Engineering team that is 'Controlled', i.e. it requires a password that you can obtain by logging a formal Service Request with Oracle Support. We are distributing the required patch in this manner to monitor potential customer issues due to the nature of this technology, gather feedback, and assess the technology's adoption rate.

Does it meet your requirements?

Users migrating large databases across platforms of the same "endian" format are advised to use the Transportable Database (TDB) migration process instead of Transportable Tablespaces. The "endian-ness" target platforms can be verified by querying the view V$DB_TRANSPORTABLE_PLATFORM using sqlplus (connected as sysdba) on the source platform:
SQL> select platform_name from v$db_transportable_platform;
If the intended target platform does not appear in the output, it means that it is of a different endian format from the source and Transportable Tablespaces (for large databases) or export/import should be used for database migration.

Other Certifications Still Underway

Transportable Tablespaces for other Database and EBS versions (such as 10gR2+R12, 11g+R12 and 11g+11i) are still under evaluation.  Oracle's Revenue Recognition rules prohibit us from discussing certification and release dates, but you're welcome to monitor or subscribe to this blog for updates, which I'll post as soon as soon as they're available.

Documents in My Oracle Support referred to in the Certifications section of My Oracle Support pertaining to general information on EBS 11i (such as Document 986762.1) are in the process of being updated to reflect this certification.

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:
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
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:


Related Articles

Thursday Mar 11, 2010

A Primer on Migrating Oracle Applications to a New Platform

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:
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 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

Related Articles

Wednesday Mar 10, 2010

OCFS2 for Linux Certified for E-Business Suite Release 12 Application Tiers

[May 7, 2015 update: This article applies only to EBS 12.1.  OCFS2 is not certified with EBS 12.2 yet.]

Oracle E-Business Suite environments can be scaled up to handle large numbers of concurrent users by load-balancing across multiple application mid-tier servers.  At Oracle, we run Oracle E-Business Suite Release 12 internally with a pool of approximately forty application tier servers.

The novelty of applying the same patch to every one of those servers individually wears off pretty quickly.  There's a easier way: you can share a single file system between all of your E-Business Suite application tier servers.  This allows you to apply patches once to the central filesystem, rather than maintaining each application tier server node individually.  This approach reduces maintenance overheads and shortens your patching downtimes. 

Starting with Release 12, you can even share the same file system between multiple E-Business Suite instances (although for obvious reasons, you should do this only for non-production instances).

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.  I've discussed the nuances of choosing a shared file system in this article.

That article explicitly stated that we do not certify specific file systems with the E-Business Suite.  That was true at the time that article was published, and is still generally true for most file systems.  However, your requests made it clear that we needed to take a closer look at Oracle Cluster File System (OCFS2) for Linux, so we did.

What's new?

Oracle Cluster File System (OCFS2) for Linux OCFS2 1.4 and higher is now certified and supported for Oracle E-Business Suite Release 12 application tier file systems. System administrators may deploy both the APPL_TOP and INST_TOP on Linux-based OCFS2 shared-disk cluster file systems.

Oracle E-Business Suite Release 12 certification tests with OCFS2-based application tier shared file systems used the following configuration:
  • Oracle Enterprise Linux Version 5 Update 4 (OEL5U4 64-bit) running OCFS2 1.4.4
  • Separate volumes for APPL_TOP and INST_TOP storage (INST_TOP was also tested and is certified with local storage)
  • Oracle E-Business Suite application tier mount options used: rw, _netdev, nointr
  • Mount option datavolume was not used in the application tier mounts
For detailed instructions on configuring OCFS2, see OCFS2: A Cluster File System for Linux: User's Guide for Release 1.4 on the Project: OCFS2 website.

What about EBS database tiers?

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.  This applies to both Oracle E-Business Suite Release 11i and 12.

What's not certified or supported?

Oracle Cluster File System (OCFS2) for Linux is not certified with Oracle E-Business Suite Release 11i application tier file systems.

Oracle Cluster File System for Windows is not certified with application tier file systems for either Oracle E-Business Suite Release 11i or Oracle E-Business Suite Release 12.

How well does this work for you?

As with all new certifications, we're very interested in hearing about your experiences with this.  If you've experimented with OCFS2 for Linux for your Apps mid-tiers, please post a comment here or drop me a private email with your feedback.  I'll make sure that your comments get back to the OCFS2 team directly.

Related Articles

Monday Feb 01, 2010

Migrating E-Business Suite Application Tier Servers to Linux

If your E-Business Suite environment is hitting the ceiling for performance, you should first tune and optimize it to squeeze the most of your existing hardware.  At some point, you may decide to scale up your application tier with multiple nodes behind a load-balancer.  As part of that process, you might begin considering replacing large SMP servers on your application tier with a pool of servers running Linux on commodity hardware. 

Indeed, this is the architecture that we use to run Oracle's own global E-Business Suite Release 12 implementation.  We have four large Sun database servers fronted by almost 40 application tier servers running Oracle Enterprise Linux (OEL):


If you're considering a move to Linux for your Apps middle tier servers, you will find the following two Notes invaluable:
You can use these Notes to migrate an Oracle application (middle) tier to any platform that is supported with the Rapid Installs for both Oracle E-Business Suite Release 11i and 12.

The processes described in those Notes provides a certified way to quickly and easily move an existing Oracle application tier system to a different platform, allowing you to utilize different hardware for the Oracle application tier. The migration utility retains the exact Oracle E-Business Suite patch level so that no APPL_TOP/Database synchronization is necessary; this also allows you to retain many customizations.

Related Articles

Wednesday Jan 27, 2010

Live Migration of EBS Services Using Oracle VM

[Editor: This is the fifth of a five-part series on virtualization and cloud topics from Ivo Dujmovic, an architect in our Applications Technology Integration group.]

Breaking news: you can now achieve live migration of E-Business Suite instances on Oracle VM (OVM).  This is the High Availability and Fault Tolerance Holy Grail.  In an environment configured to support live migration, end-user sessions running on one node in a virtual machine server can be migrated transparently to a different node on a different virtual machine server.  You have asked for this functionality for more than a dozen years and many Oracle partners offer solutions to achieve this.  After all these years, Oracle can provide you a solution for E-Business Suite environments using Oracle VM.

Why was this so hard for Oracle E-Business Suite?  Well, the short answer is that we have hundreds of products using many different technologies as part of the E-Business Suite, and many of them had complicated session state handling (some in the database, some on the middle-tier), caches that needed to be kept synchronized, and so on.  While all technical problems are soluble, this one was just not feasible to solve within E-Business Suite itself. 

Architecture diagram showing failover of virtual server in an HA-enabled server pool

Virtualization Changes Things

In an conventional (non-virtualized) architecture, the failure of a specific application tier node would force a logout of all end-users with sessions on that particular node.  Any transactions that were mid-stream on that application tier node would have been lost.  On a virtualized platform, end-user sessions can be migrated from one machine to another without the end-user noticing. 

OVM's live migration feature has some requirements, including the need to have look-alike machines on same subnet.  These requirements are discussed in detail in:
Oracle VM also currently restarts the VM if the Virtual Machine Server fails, which would mean the end-user session does need to be restarted. We expect that these behaviors should improve over time.

In addition to the great live migration feature, OVM also has cloning functionality, which work seamlessly work if you use our EBS templates or virtualization kit.

Your Feedback is Welcome

This concludes my mini-series on virtualization and the E-Business Suite.  We're extremely interested in hearing about your use cases and your experiences with our new templates and virtualization kit.  Tell us what you think via our new OVM Templates discussion forum.

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

Sunday Dec 20, 2009

Using Oracle VM with Oracle E-Business Suite Virtualization Kit

[Editor: This the second of a five-part series from Ivo Dujmovic, an architect in our Applications Technology Integration group, on virtualization and cloud topics]

As I've mentioned in the first article of this series, I do want to delve more deeply into topics from my OOW'09 E-Business Suite Virtualization Update presentation. Before I do that, I wanted to spend some time on our latest EBS 12.1.1 Oracle VM (OVM) Templates.

Rolling Your Own Apps Templates using Oracle VM

In addition to using our templates, customers might want to build their own templates. As most of you know, virtualization platforms like Oracle VM are just that -- platforms. They do not help you with anything inside the template, or if they do, it is a starting point template with OS e.g. OVM templates for Oracle Enterprise Linux, or a process/tool to create that OS starting point (JEOS = Just Enough Operating System, pronounce "juice").
Architecture diagram showing Oracle VM Manager + Oracle VM servers + server pool + storage devices
In any case, you proceed with your bare bones template to start a virtual machine (VM), mount your disk, install your E-Business Suite, and save your VM template. The end result is an image of machine with a set host name, IP,  E-Business Suite instance. As long as it is self-contained, i.e. both your database and middle tiers are installed and you have no external integration, you are OK, right?  It's not quite that simple, I'm afraid.

Multiple VMs May Have Naming and IP Collisions

If you want to bring up a number of these VMs from the same template, they will all think they are host x with IP y and EBS instance z. That might cause some problems with your network, or at least for the browser which needs to figure out how to connect to the right one of these instances...

If you want to do external integrations, e.g. break apart your EBS VM's into a database VM and middle tier VM, or add an external identity management system, portal, business intelligence, or whatever you fancy, well that is doable the first time for the first VM. For the next VM of that template, it might appear like that integration is already done. Hmmm....

When I brought down the first VM, did I want to keep it and its integrations around, or not?  Is my middle tier X supposed to work only with one database VM Y or some another database VM?

Initializing New Virtual Machines Upon First Startup

As you can see, virtualization platforms only provided the magic to create more "virtual" machines from one template. But you still need more magic: for starters, you want the to tell the VM its name and IP to initialize it when it boots from a template for the first time.  Luckily for both of us, the Oracle VM/Linux team supplies scripts for this magic.  Now, you realize that you really don't care about virtual machines, but virtual E-Business Suite instances. You need more magic to get the E-Business Suite instance to initialize on first boot.

We have created this magic (OK, it's just a couple of scripts), for our E-Business Suite templates, and are eager to share it with you via our E-Business Suite Virtualization Kit. The Virtualization Kit consists of documentation and scripts that help automate the desired behavior of OVM templates with E-Business Suite:
The Knowledge Document will give you a cookbook approach to building your own E-Business Suite template, and the patch delivers the magic sauce, I mean scripts.

Your Feedback is Welcome

We're extremely interested in hearing about your use cases and your experiences with our new E-Business Suite Virtualization Kit.  Tell us what you think via our new OVM Templates discussion forum.

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 does on the database and applications tiers
      • What happens during the cloning process
      • What does on the database and applications tiers
      • Comparison of command line options
      • 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

Tuesday Nov 24, 2009

Tuning the Oracle E-Business Suite Environment (OpenWorld 2009 Recap)

In addition to their benchmarking efforts, our Applications Performance Group works with some of our largest E-Business Suite customers in the world.  These customers have thousands of concurrent end-users, sprawling multi-terabyte databases, enormous clusters of application-tier servers, and massive RAC architectures.  The Applications Performance Group is called in whenever a customer experiences severe performance issues. 

Every year, our performance architects take all of their hard-won experience with these customers and distill it into a single OpenWorld presentation.  Wondering how many JVMs to use per CPU?  Curious about tuning the garbage collection parameters on your app tier?  Want some tips for optimizing your Concurrent manager setup?

Isam Alyousfi and Lester Gutierrez cover these topics, and much, much more, in their densely-packed presentation:


It's difficult to convey the depth and range of the performance-tuning tips that they capture, but here's an outline of the topics that they cover:
  • Tuning the applications tier
    • Pointers to resources and performance-related patches
    • Tips for tuning and debugging Forms
    • OC4J and JVM sizing guidelines (e.g. number of JVMs per CPU, number of users per JVM)
    • Tools for tuning the application tier
    • Diagnostic framework for investigating response time / CPU issues
    • Garbage collection (GC) tuning tips
    • Common causes of OutOfMemoryError conditions
    • Symptoms of memory leaks
    • Using JDBC connection identification to map JDBC sessions to a JVM process
    • Performance implications of end-user training on web application resource consumption
    • Using the Pool Monitor to check Framework applications and JVM utilization
    • Using EM Monitoring and Application Diagnostics for Java (AD4J) to monitor JVMs on different hosts
    • Using JConsole to analyze heap dump issues
    • Performance-related patches to consider
  • Tuning the Concurrent Manager
    • General tips for maximizing job throughput
    • Tips for workload management, including the number of target processes per CPU
    • Tips for Transaction Managers (TMs)
    • Tips for tracing and speeding up Concurrent Reports
    • Using Parallel Concurrent Processing (PCP) in RAC deployments
  • Tuning the client tier and network
    • Pointers to a new whitepaper, and tips for optimizing desktop client configurations
    • Tips for reducing browser memory footprints
    • Guidance on network latency and co-locating database and application tier servers
    • Network profiling and packet analysis techniques
    • Use of caching tools to reduce network traffic between client and middle-tiers
  • Tuning the database tier
    • init.ora recommended settings
    • Consequences of undersized buffer caches or shared pools
    • I/O optimization techniques
    • Recommended performance features
    • Using Automatic Workload Repository (AWR) data and baselines
    • Linking AWR with ASH data
    • Tips for using DB Console
    • Techniques for gathering statistics
    • Recommendations for OATM Tablespace Model conversions
    • SQL issue triage notes, and common problems
    • Benefits of upgrading to 11g Database
    • Notable performance-related features in the 11g Database
    • Advanced Compression performance benchmarks
    • 11g Automatic SQL monitoring and tuning
    • SQL tracing enhancements in 11g DB
    • 11g Optimizer improvements
  • Tuning the applications
    • Pointers to application module tuning resources
    • Recommended performance-related patches and configuration guidance for specific products: Create Accounting XLA, Accounts Receivables AR, Accounts Payables AP, iPayment IBY, Incentive Compensation CN, Time & Labor, Workflow, Order Management OM, Payroll
    • Logging, purging, and archiving
    • Accessing the Purge Portal
  • Upgrade performance tips
This presentation is chock full of tips, pointers, and hard-won knowledge. It represents the distillation of countless performance-related Service Requests and customer escalations. If you're grappling with performance issues in your environment, or simply trying to squeeze more performance out of existing hardware, I'd strongly recommend downloading this presentation.

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 Sep 23, 2009

Field-Tested Advice for Smooth EBS 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: 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 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, 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

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 Database, you will have your work cut out for you.  If you are on 11.5.9 and, 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 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 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 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 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 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
Myth #1:  Shortcuts are safe

There are no safe shortcuts.  This upgrade can't be done by performing a fresh install of, linking this installation to your 11.5.x database and then applying the database portion of the 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.


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 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.


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 (Applications tier)
  2. Application Server10g Forms and Reports to (Applications tier)
  3. Database Release 10gR2 to 11gR1 version (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.


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.


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


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.


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


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.


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.


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

Related Articles

Monday Aug 17, 2009

Evolutionary Steps for Automated Testing for E-Business Suite

My, how time flies.  It's been over two years since I last covered automated regression testing for the E-Business Suite. Our strategy for this area continues to evolve, so it's high time for an update.

The E-Business Suite Test Starter Kits consist of sample test scripts from our own E-Business Suite QA group, along with a Starter Guide, Best Practices Guide, and Installation instructions.  The test scripts were created against an EBS Vision Demo database displaying American English.  You can use these kits as a model for building out your own automated regression tests for your Apps environment.

Back in 2006, you could download our Quality Assurance teams' automated WinRunner QA scripts for Oracle E-Business Suite Release 11i via a Test Starter Kit.  A few things have changed since then:

Test Starter Kits for WinRunner are Still Available

If you're still using WinRunner, you'll be pleased to learn that you can still download:

  • WinRunner Test Starter Kit for Release 12.0.4 - Patch 6799654
  • WinRunner Test Starter Kit for Release 12.0 - Patch 5845794
  • WinRunner Test Starter Kit for Release - Patch 4520701
  • WinRunner Test Starter Kit for Release 11.5.10 - Patch 4064542
  • WinRunner Test Starter Kit for Release 11.5.9 - Patch 2983563
  • WinRunner Test Starter Kit for Release 11.5.8 - Patch 2739616
  • WinRunner Test Starter Kit for Release 11.5.7 - Patch 2471695

New Test Starter Kits for QTP are Available

If you've switched over to HP's QuickTest Professional (QTP) testing set of tools, you can now download the following new Test Starter Kits:

  • QTP Test Starter Kit for Release 12.1.1 - Patch 8408886
  • QTP Test Starter Kit for Release 12.0.4 - Patch 6845309
  • QTP Test Starter Kit for Release 12.0 - Patch 5845799
  • QTP Test Starter Kit for Release - Patch 4611398
  • QTP Test Starter Kit for Release 11.5.10 - Patch 4355248
  • QTP Test Starter Kit for Release 11.5.9 - Patch 3313315

Only a subset of the E-Business Suite products with automated WinRunner scripts have QTP equivalents; the READMEs for the respective kits have more details about their contents.

The master list of Test Starter Kits available for Apps is published in:

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


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.


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.


Related Articles

Tuesday Jul 21, 2009

Updated Tips for Debugging Sun JRE + Forms Focus Issues for EBS 11i and 12

Oracle Jinitiator 1.3 will be desupported for Oracle E-Business Suite Release 11i users at the end of this month, July 31, 2009.  If you haven't already begun your conversion from JInitiator to the native Sun Java Runtime Engine (JRE) plug-in, now is the time to start. 

The end of this month marks the end of the JInitiator era for Apps 11i.  After this point, we will only support the Sun JRE for Forms users connecting to the E-Business Suite.  I've summarized everything you need to know about the EBS switch from JInit to the Sun JRE in this roundup article.

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

Clusters of Common Focus-Related Issues

As more of you make the cutover, we've seen that your reported issues are clustering around some common themes.  Based on your feedback and reported issues, we've updated our internal training for all Support engineers who cover Applications Technology topics.  Our latest diagnostic and debugging techniques for EBS Forms focus-related issues have been refreshed. 

Our Support and Development teams published notes for diagnosing Forms focus-related issues with Apps 11i earlier this year.  That troubleshooting guide's scope has been broadened to include additional guidance and tips for Oracle E-Business Suite Release 12 environments, too:

The latest topics covered in this Note include:

  • What is a focus issue?
  • Why are Focus Issues Experienced?
  • Symptoms Indicating a Loss in Focus
  • Strategy for Investigating and Resolving Focus Issues
  • The Right Checks to Ensure it's a Focus Issue
  • Fixing Known Focus Issues
  • Determining the Current Forms Version and MLR Patch (Release 11i)
  • Determining the Current Forms Version and MLR Patch (Release 12)
  • Gathering the Right Information
  • Debugging Steps for Focus Issues
  • Reporting a Focus Loss to Oracle Support Services

Getting Support from Oracle for Your Conversion

I've noted this before, but it's worth repeating. We're very interested in helping you get through this conversion with a minimum of pain. If you hit any problems with your Apps 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.  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

Wednesday Jun 17, 2009

Which is Better: Forms Servlet or Socket Mode?

Many products within the Oracle E-Business Suite have screens that are built with Oracle Forms.  Oracle Forms can be run in either servlet mode or socket mode.  Apps 11i is based on Forms 6i and is configured to run in socket mode by default.  Apps 12 is based on Forms 10g and is configured to run in servlet mode by default. What are these modes, and which is better?

What is Forms Servlet Mode?

The Forms Listener Servlet is a Java servlet that delivers the ability to run Oracle Forms applications over HTTP and HTTPS connections. It manages the creation of a Forms Server Runtime process for each client, as well as network communications between the client and its associated Forms Server Runtime process.

The desktop client sends HTTP requests and receives HTTP responses from the web server. The HTTP Listener on the web server acts as the network endpoint for the client, keeping other servers and ports from being exposed at the firewall.

Forms listener servlet diagram showing firewalls desktop client and oc4j container on application tier

What is Forms Socket Mode?

Initial releases of the Oracle Forms Server product used a simple method for connecting the client to the server. The connection from the desktop client to the Forms Listener process was accomplished using a direct socket connection.  The direct socket connection mode was suitable for companies providing thin client access to Forms applications within their corporate local area networks. For the direct socket connection mode, the client had to be able to see the server and had to have permission to establish a direct network connection.

Although the direct socket connection mode is perfectly suited for deployments within a company’s internal network, it's not the best choice for application deployment via unsecured network paths via the Internet. A company connected to the Internet typically employs a strict policy defining the types of network connections that can be made by Internet clients to secure corporate networks. Permitting a direct socket connection from an external client exposes the company to potential risk because the true identity of the client can be hard to determine.

Servlet Mode Advantages

  1. HTTP and HTTPS traffic is easily recognizable by routers, while socket mode communications is generally considered suspect and treated on an exception basis. 
  2. Existing networking hardware can be used to support basic functions such as load-balancing and packet encryption for network transit.
  3. More resilient to network and firewall reconfigurations.
  4. More robust: servlet connections can be reestablished if network connections drop unexpectedly for Forms, Framework, and JSP-based pages.
  5. Is the only supported method for generic Oracle Forms customers, and therefore is more thoroughly tested by the Forms and E-Business Suite product groups.
  6. Performance traffic can be monitored via tools like Oracle Real User Experience Insight (RUEI).
  7. Socket mode is not supported on Windows-based server platforms.

Socket Mode Advantages

  1. Uses up to 40% less bandwidth than Forms servlet mode.  This may be perceived by Wide Area Network (WAN) users as causing slower responsiveness, depending upon network latency.
  2. Uses fewer application-tier JVM resources than servlet mode, due to fewer TCP turns and lack of overhead associated with HTTP POST handling.

Switching Apps Deployments Between Modes

Due to its numerous advantages, Forms servlet mode is the preferred and recommended deployment model for Forms on the web. 

There may be circumstances where you need to switch between the default Forms modes.  You might wish to switch your Oracle E-Business Suite Release 12 environment to socket mode to improve performance or reduce network load.  You might wish to switch your Apps 11i environment to servlet mode as part of your rollout to external web-based end-users outside of your organization.

If you're running Apps 11i and would like to switch to servlet mode, see:

If you're running Apps 12 and would like to switch to socket mode, see:

Related Articles

Tuesday May 26, 2009

15 New Technology Stack Enhancements in EBS 12.1.1

Now that our latest Applications Release 12.1.1 is available, here's a list of new technology stack configuration features you might be interested in learning about.  While you're reviewing new R12.1.1 content, please do not miss our newly revamped and user-friendly AutoConfig guide:

This updated AutoConfig guide has been restructured to present you more in-depth and practical information to get you get started quickly with AutoConfig and all its related utilities. Please check it out and let us know what you think about it!

Diagram showing the process by which the AutoConfig Build Context Utility consolidates data from the EBS database environment variables and context template to generate a context file

What's New in 12.1.1's Techstack Utilities?

Here's what's new in our Apps 12.1.1 technology stack tools and utilities:

Enhanced Support for Sharing Application Tier File System

  • Enables the sharing of the application tier file system amongst two or more Oracle E-Business Suite instances.
  • More information in My Oracle Support Knowledge Document 384248.1

Enhanced Support for Application Tier Load Balancing

  • Provides configuration support for major load balancing categories: DNS, OC4J Native, HTTP layer (hardware/software).
  • More information in My Oracle Support Knowledge Document 380489.1

Enhanced Support for DMZ Deployments

  • New demilitarized zone (DMZ) deployment options added, including support for forward proxies, reverse proxies with no external web tiers, and the use of hardware load-balancers without an external web tier.
  • More information in My Oracle Support Knowledge Document 380490.1

Network Traffic Encryption Capability

  • Provides AutoConfig support for securing the major communication routes with SSL.
  • More information in My Oracle Support Knowledge Document 376700.1

Advanced Configuration Wizards

  • Examples of such advanced configurations include DNS load balancing, HTTP load balancing, SSL setup on web server, SSL Accelerator setup, and others.

Oracle Connection Manager Technology Integration

  • Reverse proxy support for the database using Oracle Connection Manager
  • Oracle Connection Manager (CMAN) is a lightweight, highly-scalable program that works as a proxy server, forwarding connection requests to database servers or to the next proxy server. Oracle Connection Manager listener receives connection requests, evaluates them against a set of rules, and determines whether to deny or allow access.
  • More information in My Oracle Support Knowledge Document 558959.1

Support for Integrated SOA Gateway

  • More improvements and automation around integrating with Service Oriented Architectures (SOA) and web services.
  • More information in My Oracle Support Knowledge Document 556540.1

Technology Stack Inventory Validation Report

  • Allows administrators to review the versions of various installed technology components, patchsets and interim ("one-off") patches.

AutoConfig Profiler

AutoConfig Parallelization

  • AutoConfig can be run in parallel on different nodes of an Oracle E-Business Suite system, reducing the overall time needed to run AutoConfig.

AutoConfig Service Control Dependency Management :

  • Now it is possible to enable and disable specific OC4J instances on the Application Tier Servers.

AutoConfig Check Config Utility

AutoConfig Support for Oracle Database 11g

  • Support to run on and configure an Oracle 11g database using AutoConfig.

Build Context XML Utility

AutoConfig Search Utility

  • A new search utility that can be used to obtain detailed information about context variables and the templates that use them.
Note: The enhanced functionality above is not available as standalone downloads or for previous Apps releases.  They can only be obtained via Oracle E-Business Suite Release 12.1.1.

Other References

Related Articles

Monday Apr 20, 2009

New Whitepaper: Manually Cloning Apps 11i Databases Running 10g or 11g RAC

Our Applications Technology Group recently published a matrix showing certified cloning scenarios for E-Business Suite databases running in Real Application Cluster (RAC) configurations.  Since then, some concerns have been raised about the lack of Rapid Clone support for EBS environments running on the 10g and 11g databases.

In response to those concerns, our Applications Technology Group has published a new whitepaper:

This new whitepaper describes a certified and supported method for manually cloning Apps 11i environments running 10g or 11g RAC.  The Note assumes a high degree of familiarity with Oracle Applications AD Utilities, RapidClone, AutoConfig, Recovery Manager, and SQL*Plus.

Related Articles



« July 2016