Tuesday Aug 06, 2013

You're Closer to EBS 12.1.3 Than You Think

Congratulations -- you're running EBS 12.1.1 or 12.1.2 in production.  Our standing recommendation is to apply the EBS 12.1.3 suite-wide Release Update Pack (RUP), despite the relaxed requirements in the recent changes to our Error Correction Support Policy.

If you can't apply the suite-wide 12.1.3 Release Update Pack, you should apply the individual 12.1.3 Family Packs for the EBS products that you've deployed.

Here's our best-kept secret:  this will change your environment less than you think.  If you've applied any patches to your 12.1.1 or 12.1.2 environment, you probably already have much of 12.1.3 already in production today.  

A glimpse behind the curtain

This is due to the way that our EBS source code control system works: we deliver patches based upon the latest versions of code in our source control system.  Developers sometimes refer to this as "delivering code on the tip of the codeline."

If "source control systems" are unknown territory to you, here's an example to illustrate this:

Let's imagine that you're running 12.1.1 and report an issue with a Financials screen. 

That Financials screen was first released in 12.1.1, updated in 12.1.2, and updated again in 12.1.3.

Whatever patch you apply will deliver the latest version of the 12.1.3 code and all of the related dependencies in other screens or packages

In this particular case, you might think you're on 12.1.1, but applying that patch has raised your code level for the updated files to the 12.1.3 level or even later.

Apps DBA Tip: Check which files a patch changes

Here's how to check this out yourself.  The Oracle Applications Manager contains a tool that all Apps DBAs should use:

The Patch Wizard has an "Analyze Specific Patches" function that tells you how a specific patch will affect your system.

Patch Wizard Analyse Specific Patches screenshot

The resulting "Patch Impact Analysis" report provides you with a summary of:

  • Applications patched
  • New files introduced
  • Existing files changed
  • Existing files unchanged

Screenshot of Patch Wizard Impact Analysis Report

Power users tip:  identify affected customizations

Patch Wizard Register Flagged Files screenshotIf you've flagged your customized files using the Oracle Applications Manager "Register Flagged Files" function, the Patch Wizard will also identify which of your customizations are affected by a given patch.

This allows you to reassure your developers and end-users that you have very-granular control over the impact of a given patch on critical customized functionality.

A case study: Financials and Procurement 12.1.3 vs. 12.1.1

A major steel manufacturer running EBS 12.1.1 approached us with their concerns about applying the suite-wide EBS 12.1.3 Release Update Pack to their environment.  Like many manufacturers, every hour of EBS downtime meant lost productivity so they wanted to minimize the amount of retesting triggered by 12.1.3.

They had been running 12.1.1 Financials and Procurement in production for quite some time.  They had stabilized their environment with a number of one-off patches on top of 12.1.1.  

We used the Patch Wizard's "Patch Impact Analysis" report to assess the number of files that would be affected by the 12.1.3 Family Packs for Financials and Procurement.  Here's what we found:

  • They already had applied 81% of the 12.1.3 Procurement Family Pack.  The 12.1.3 Procurement Family Pack has ~3,800 files, which means that over 3,100 files were unchanged.  Only 3 of the files that they'd customized needed review.

  • The 12.1.3 Financials Family Pack contains ~12,000 files.  They had already applied 72% of the 12.1.3 Financials Family Pack, leaving over 8,600 files unchanged.  Only one of their customized files needed review.

Do your own 12.1.3 impact analysis

Your mileage will vary.  Run the Patch Wizard comparing the 12.1.3 Family Packs to see how close you are.

I'd be interested in hearing your reports.  Feel free to post a comment here or drop me an email with your results.

References

Related Articles


Friday Jul 26, 2013

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

Oracle E-Business Suite Release 12.1.1 Consolidated Upgrade Patch 2 (CUP2) is now available in My Oracle Support. This patch includes fixes and performance improvements for the scripts used to upgrade an EBS 11i environment to 12.1.1.

This patch is mandatory for customers who are upgrading to Release 12.1.1 from the following releases:

  • Oracle E-Business Suite Release 11i version 11.5.9 (base, CU1, CU2)
  • Oracle E-Business Suite Release 11i version 11.5.10 (base, CU1, CU2)

This patch includes all of the upgrade-related fixes released previously in the Consolidated Upgrade Patch 1 (CUP1, Patch 7303029) and many additional upgrade related fixes released since March 2010. 

You can download it here:



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

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

Who should use it?

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

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

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

How do you apply Release 12.1.1 CUP2?

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

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

Can I apply Release 12.1.1 CUP2 to Release 12.1.1?

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

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

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

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

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

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

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

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

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

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

Product Family Release Update Pack

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

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

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

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

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

Monday Apr 29, 2013

How to Obtain Media Packs for Older Versions of Oracle Products

Installation media for all Oracle products can be downloaded from the Oracle Software Delivery Cloud (SDC, formerly called Oracle eDelivery). You can use this site to obtain Media Packs for the latest versions of all licensable Oracle products.  Media Packs are available in zip and ISO formats, which you can unzip or burn to DVDs, respectively.  All of the download links on the Oracle Technology Network (OTN) point to the Software Delivery Cloud, making the latter the authoritative source for all Oracle downloads.

Screenshot of Oracle Software Delivery Cloud

For more information about SDC, see:

Need to download older versions?

The Oracle Software Delivery Cloud hosts the latest released versions.  There may be times when you need a media pack for an older release.  

For example:

As of today, the latest version of Oracle Access Manager available for download is Oracle Access Manager 11.1.2.1.0.

We're certifying Oracle Access Manager 11.1.2.1.0 with the E-Business Suite right now.  In the interim, E-Business Suite customers should use only the 11.1.2.0.0 version.

If you need a Media Pack for an older release, you can log a Service Request requesting the specific release.  Oracle Support has a team that's dedicated to handling these types of shipping requests and other non-technical issues.  Also see:

Monday Apr 01, 2013

New Whitepaper: Function Security + Role-Based Access Control in Oracle EBS

There are two main ways to implement security in Oracle E-Business Suite: “traditional” Oracle E-Business Suite responsibility-based security (usually referred to as “function security”) and Role-Based Access Control (RBAC).   Since they overlap in functionality, and RBAC incorporates and builds upon responsibility-based security, there is often confusion about how the two security models coexist and interact.

I am pleased to announce the availability of a new whitepaper to help eliminate that confusion:

RBAC vs. Grants

This heavily-illustrated whitepaper discusses the main similarities and differences between the two types of security setups, as well as the objects involved.  It includes the following topics:

  1. Responsibility-based security (Function Security)
  2. Role-Based Access Control
  3. Functions and Permissions
  4. Roles and Grants
  5. Role Hierarchy and Role Inheritance
  6. Using Role Hierarchies to Simplify User Administration
  7. Best Practices for Implementing RBAC and Function Security

This whitepaper is written for Oracle E-Business Suite system administrators, super-users, and implementers.  It applies to Oracle E-Business Suite Release 11i, 12.0, and 12.1.

Happy reading!


Thursday Feb 21, 2013

Getting Started as an E-Business Suite DBA

The other day, a reader asked, "How does one become an EBS DBA?" He'd worked on an ERP environment in the past but seemed to be overwhelmed. This is understandable; there's lots to learn.  The good news is that there are many options to becoming an Apps DBA.

If you have limited funds

1. Start with the official documentation

There is a vast trove of information contained within the online E-Business Suite Documentation Library. Our documentation writers are devoted to capturing everything that you need to know to manage the E-Business Suite, and the organization of the documentation is top-notch.  All aspiring DBAs should start here:

Screenshot of new EBS documentation library

2. Build your own sandbox environment

The only way to learn is to work with a real environment. You can download Oracle VM templates for the E-Business Suite and have an environment running within a few hours:

3. Get the latest information

EBS technology is constantly being refreshed.  You can learn about specific EBS topics from the developers themselves in these free one-hour webcasts:

We release over 150 new certifications a year, so it's vital to monitor or subscribe to this blog to stay current:

4. Talk with your peers

There are dozens of Oracle EBS discussion forums. The best DBAs in the world congregate here and are generous with their expertise.  Some recommendations for DBAs:

If you prefer formal classroom-style training

Oracle University has some excellent courses: Oracle Applications - E-Business Suite Training

Here are some great ways get started in E-Business Suite Tools and Technologies:

If you want to get certified

You can get certified through the Oracle Certified Professional (OCP) program. Here is the learning track to becoming an EBS DBA:

There's no free lunch

As I was getting ready to fire off an email to the gentleman, I sat back and thought about the context of the gentleman’s inquiry. We have a diversified selection of education offerings that are fee-based and free. Oracle University courses are outstanding. Self study classes can be performed from anywhere. Our documentation resources are extensive as well as comprehensive. We have software to download and try. Everything is in place to achieve all the goals you might ever want to achieve dealing with Oracle Application Technologies. 

There is just one catch: whatever route the gentleman chooses to take, there will have to be a substantial investment in time and resources. Technology continually advances, so this will be an ongoing investment.

Often, individuals who embark on the path of learning our technologies miss that. I wish I could convey to those that start the journey, that even for those of us who are Oracle professionals, we never stop learning our own technologies.

There is no easy way to become an expert.  but it's worth it


Friday Feb 01, 2013

Grace Period Increased for Applying (some) Database Patchsets

It's crucial to maintain the database in your E-Business Suite environments by applying the latest database patchsets.  Database patchsets contain important security, performance, and stability updates. As of today, the latest database patchset certified with EBS is 11.2.0.3. We strongly recommend that all EBS customers should be running this patchset now.

Oracle Database release roadmap

Until now, whenever a new database patchset was released, you had up to 12 months to apply it.  This is called the grace period.  No new patches for the previous patchset would be released after that 12 month grace period.

Oracle's Server Technologies group has just increased the grace period for the second and later patchsets to two years.

This is easier to understand with an example:

  • 11.2.0.1 was the major release for the 11gR2 codeline.
  • 11.2.0.2 was the first patchset.  You had 12 months to apply that patchset once it was released.
  • 11.2.0.3 was the second patchset.  You now have 24 months to apply that patchset after its release.

For more information about these database support policies, see:

Related Articles

Monday Dec 31, 2012

Updated Whitepaper: Extending EBS 12.1.3 using Oracle Application Express

I'm pleased to announce an update to the whitepaper:

  • Extending Oracle E-Business Suite Release 12 using Oracle Application Express (APEX), Revision 1 (Note 1306563.1)
Oracle Application Express APEX screenshot

It's possible to personalize the E-Business Suite, but there may be situations where personalizations aren't sufficient to meet your requirements. In these scenarios, Oracle Application Express, also known as Oracle APEX, is an option for creating supplemental applications that can be integrated with your Oracle E-Business Suite instance.

This whitepaper outlines how to extend Oracle E-Business Suite 12.1.3 (and higher) functionality using Oracle Application Express. Recommended architecture and security considerations are discussed in detail. This new version has been updated to reflect the latest versions of the documentation and technologies, including the use of Oracle Access Manager (OAM) for authentication.

You can also find the whitepaper on the APEX OTN Site > Learn More > Technical Information and White Papers > Extending Oracle E-Business Suite Release 12 using Oracle Application Express (PDF).

Related Articles


Friday Aug 17, 2012

Top Five Errors Customers Make When Maintaining E-Business Suite 12 (Part 6)

This is the last in a series of articles that list a few of the technical myths or misunderstandings about the E-Business Suite. Previous articles have covered installations, cloning, patching, migrations, and upgrades. This article discusses general maintenance.

Each article is absolutely not definitive and I’d be interested in comments from readers who think there are other misconceptions about the day to day maintenance and upgrade of a typical E-Business Suite environment.


COMMON ERROR #1: Manually editing files that are maintained by AutoConfig.

ORACLE’S RECOMMENDATION: When you run AutoConfig, in most circumstances any manual changes to AutoConfig controlled files will be overwritten. There is a process for adding custom entries to AutoConfig maintained files; you should use this process if you need to make manual changes to files maintained by AutoConfig. Refer to Section 4 of the AutoConfig Note for information on how to customise AutoConfig.


COMMON ERROR #2: Maintaining local file systems for multiple application tier servers instead of shared file systems.

ORACLE’S RECOMMENDATION: An environment with, for example, four standalone web/forms nodes on Linux and four standalone Concurrent Processing / RAC nodes on Solaris each using a local file system is a very inefficient architecture that you will very quickly get bored of patching.  Each E-Business Suite patch will need to be applied eight times. This can be reduced to one patch session if Concurrent Processing is placed on the same node(s) as web/forms and a shared application tier file system is introduced. If you cannot achieve acceptable performance from your shared disk subsystem then you should investigate the performance issue on your disk subsystem rather than compromising with an E-Business Suite architecture that has such expensive maintenance requirements.


COMMON ERROR #3:  Sizing everything in the init.ora as large as possible.

ORACLE’S RECOMMENDATION: Database tuning is a delicate exercise. Indiscriminately increasing values in the hopes that doing so will automatically improve performance is a dangerous approach. Use the performance tools in Oracle Enterprise Manager (OEM) and other tools to establish performance bottlenecks. Do not change init.ora parameters indiscriminately; all changes should be supported by your own empirical evidence that candidate changes result in performance improvements. Thoroughly stress-test all changes before implementing in production.


COMMON ERROR #4:  Ignoring invalid objects for products you do not use.

ORACLE’S RECOMMENDATION:  All products are installed in an E-Business Suite installation in the database.  All products must be patched and maintained. Invalid objects, even in products you do not use, indicate an underlying problem in your system that should always be investigated and resolved.


COMMON ERROR #5:  Performing a complete database export/import to improve performance.

ORACLE’S RECOMMENDATION: Well possibly, but there is certainly a lot of unnecessary exporting and importing of databases in an attempt to improve performance.  This brings us nicely back to the introduction of our first article in this series. A significant amount of the data in your database is static. Tables may become fragmented but this is not automatically a performance problem. If this was the case, many databases would have performance problems.

An Oracle database is built to cope with a reasonable amount of fragmentation and will not suffer because of it. Analyse performance problems before assuming the issue will be solved by an export/import. Most performance problems are due to poor indexing of tables and inefficient SQL. Few are caused by table fragmentation.

References

Related Articles

Wednesday Aug 15, 2012

Five Errors Customers Make When Upgrading E-Business Suite 12 (Part 5)

This is the fifth in a series of articles about common technical myths or misunderstandings about the E-Business Suite. Other articles have covered installations, cloning, patching, migrations, and maintenance. This article discusses upgrading. 

Each article is absolutely not definitive and I’d be interested in comments from readers who think there are other misconceptions about the day to day maintenance and upgrade of a typical E-Business Suite environment.


COMMON ERROR #1: Believing that DBUA does not work for Apps databases.

ORACLE’S RECOMMENDATION: Many DBAs still like to perform database upgrades manually using Oracle-provided scripts as they feel it gives them more control of the upgrade process. For the rest of us, DBUA is an excellent tool that greatly simplifies the upgrade process and which should reduce your upgrade time. E-Business Suite database upgrade documentation now assumes (but does not mandate) that you will use DBUA and documentation will be written accordingly. Raise a Service Request if you believe you have an issue where DBUA fails and the manual process is required instead.


COMMON ERROR #2: Assuming that only one test upgrade is needed before the production upgrade.

ORACLE’S RECOMMENDATION: Oracle advise a minimum of three completely successful tests of any upgrade or maintenance downtime before your production upgrade.


COMMON ERROR #3: Using generic documentation instead of the E-Business Suite versions.

ORACLE’S RECOMMENDATION: As an example, if you need to upgrade your database do not just refer to the standard database upgrade manuals. The E-Business Suite Development Team have created documentation specifically for upgrading the E-Business Suite technology stack to supplement generic documentation. Follow these supplemental documents. They are well written, thoroughly tested and will make your upgrade a success.


COMMON ERROR #4: Skipping new products included in Release Update Packs (RUPs) because there are no plans to use that product.

ORACLE’S RECOMMENDATION: When instructed to add new products to your database as part of a RUP you must always add those products. These products will later be patched and updated by this or later RUPs and if the products are not present then the patches will fail.


COMMON ERROR #5: Manually copying files between different E-Business Suite environments.

ORACLE’S RECOMMENDATION: New or replacement files should only be introduced to your system by patching, scheduled upgrades or other documented methods. Manually copying files between systems can cause mismatches between files in the APPL_TOP and their corresponding entries in database AD tables. This could cause patching issues later.

Related Articles


Friday Jul 27, 2012

Five Errors Customers Make When Migrating E-Business Suite 12 (Part 4)

This is the fourth in a series of articles about common technical myths or misunderstandings about the E-Business Suite. Other articles have covered installations, cloning, patching, upgrades, and maintenance. This article discusses migrations.

Each article is absolutely not definitive and I’d be interested in comments from readers who think there are other misconceptions about the day to day maintenance and upgrade of a typical E-Business Suite environment.


COMMON ERROR #1: Exporting from a 9i database and importing into a fresh 10g/11g database.

ORACLE’S RECOMMENDATION: When working with 10g onwards you must use datapump. Refer to the opening section of the relevant import/export Note to establish database version compatibility for exports/imports (including datapump). When importing into a 10g or 11g database the source database must be 10g or later.

COMMON ERROR #2: Assuming that Linux x86_64 is a certified application tier platform for 11i.

ORACLE’S RECOMMENDATION: Linux x86_64 is only certified for the 11i database tier of the E-Business Suite. Linux x86_64 can be used as both an application and database tier platform with Release 12 onwards. There are no plans to certify Linux x86_64 as a platform for the 11i application tier. Linux x86_64 using any form of 32 bit emulation is also not a certified 11i application tier platform.

COMMON ERROR #3: Migrating the E-Business Suite environment to a new platform by performing a fresh install of the E-Business Suite using Rapidwiz on the new platform and then performing an export/import of the database.

ORACLE’S RECOMMENDATION: You must use the migration tools documented in the link below to migrate the application tier to the new platform. Only use Rapidwiz to create the new application tier technology stack.

COMMON ERROR #4: Migrating EBS 11i application tier servers to Exalogic servers.

ORACLE’S RECOMMENDATION: The Exadata platform is certified for use as a database tier for both 11i and R12. Both 11i and R12 require Oracle Database 11gR2. The Exalogic platform can be used as an application tier for R12 but not for 11i.

COMMON ERROR #5: Installing or upgrading your E-Business Suite technology stack components requires downloading the entire R12 installation media.

ORACLE’S RECOMMENDATION: It is possible to build a staging area that only contains the components you require. Refer to the E-Business Suite Installation Guide for instructions on how to build a partial staging area that contains only the technology stack or E-Business Suite components that you require.

References

Related Articles


Friday Jul 20, 2012

Five Errors Customers Make When Patching E-Business Suite 12 (Part 3)

This is the third in a series of short articles about common technical myths or misunderstandings about the E-Business Suite. Other articles have covered installations, cloning, migrations, upgrades, and maintenance. This article discusses patching. Subsequent articles will cover migrating, upgrading, and general maintenance. Each article is absolutely not definitive and I’d be interested in comments from readers who think there are other misconceptions about the day to day maintenance and upgrade of a typical E-Business Suite environment.


COMMON ERROR #1: Assuming that all patches can be applied using the hotpatch and nocheckfile parameters.

ORACLE’S RECOMMENDATION: The adpatch ‘hotpatch’ parameter should be used very sparingly and is not intended to be an easy way of applying patches to your system without shutting down the application tier services. Most patches should only be applied during scheduled downtimes when all users are logged off the system, application tier services have been shut down and Maintenance Mode enabled. From the adpatch documentation:

“If an emergency patch can be applied without shutting down services, the customized instructions generated by PAA will explicitly state so. If the customized instructions do not explicitly state this, assume that you need to shut down services and enable Maintenance mode before applying the patch.”

Similarly, the ‘nocheckfile’ parameter should not be used on all patches. Nocheckfile forces the patch to run all jobs in a patch regardless of whether the jobs have been run before. It degrades patch performance and should only be used in specific circumstances where it is genuinely needed. It should not be used as the default option for applying all patches. There are very few cases in which you would want to run with nocheckfile.


COMMON ERROR #2: Assuming that patches can be applied “manually” or backed out of “manually”.

ORACLE’S RECOMMENDATION: There is no manual alternative to using adpatch to apply a patch. It is not supported to selectively choose only certain files from a patch and manually copy or execute these files in your E-Business Suite environment. Similarly, there is no simple method of reversing a patch.

COMMON ERROR #3: Increasing the number of patch workers in an attempt to make patches run faster.

ORACLE’S RECOMMENDATION: Do not assume more workers automatically improves patch performance. When you first test a patch, accept the default number of workers. Use this as the performance benchmark. If you think a different number of workers will improve patch performance then try this once you have your default benchmark, but do not exceed the default number of workers without good justification for doing so. Once a patch is started, the number of workers cannot be changed mid-patch.


COMMON ERROR #4: Ignoring or skipping patch workers that fail on products that are not used or needed.

ORACLE’S RECOMMENDATION: You should aim to have zero errors when applying a patch. All E-Business Suite products are installed in the E-Business Suite database whether you are licenced to use them or not. Patches will update all products in the database whether they are licenced or not. If you find yourself having to skip jobs or ignore errors during patching then this indicates an underlying problem in your system that should always be investigated and addressed. Review the patch prerequisites and ensure all steps have been completed successfully.


COMMON ERROR #5: Using adpatch default log file names during patching.

ORACLE’S RECOMMENDATION: Identify each new patch log file with a unique patch log file name. If you always choose the default log file name in adpatch, your adpatch.log quickly becomes enormous. This makes it very difficult to identify individual patch information in the log file and makes it difficult to keep an accurate record of your patch history. Use a simple naming convention, e.g. choose a unique adpatch log name for each patch (<patchnumber>.log. Archive and then delete your main patch log and worker files after each patch so each patch has new log and worker files.

References

Related Articles


Monday Jul 16, 2012

Five Errors Customers Make When Cloning E-Business Suite 12 (Part 2)

This is the second in a series of articles about common technical myths or misunderstandings about the E-Business Suite. Other articles have covered installations, patching, migrations, upgrades, and maintenance. This article discusses cloning. Subsequent articles will cover patching, migrating, upgrading, and general maintenance.

Each article is absolutely not definitive and I’d be interested in comments from readers who think there are other misconceptions about the day-to-day maintenance and upgrade of a typical E-Business Suite environment.


COMMON ERROR #1
: Assuming that use of the Rapid Clone utility is optional when cloning your Apps environment.

ORACLE’S RECOMMENDATION: Rapid Clone greatly simplifies the process of cloning your E-Business Suite environment. Simply copying your E-Business Suite environment to new host machines, editing the context files to reflect the new environment and then running AutoConfig is not a supported cloning method. Devising your own cloning methodology that bypasses Rapid Clone is a dangerous strategy. If Rapid Clone does not work for you, then raise a Service Request and ask for help in fixing the issue. Do not create an alternative cloning method that you hope will sidestep whatever issue you are seeing.


COMMON ERROR #2
: Assuming that the preclone scripts only need to be run once on an environment.

ORACLE’S RECOMMENDATION: You must run the preclone scripts immediately before each clone, prior to shutting down the application and database tiers in order to copy the files for cloning (or RMAN backup). It’s also good practice to remove or rename the database tier $ORACLE_HOME/appsutil/clone and application tier $COMMON_TOP/clone before running the preclone script. Always check the cloning documentation for the latest patches before each clone.


COMMON ERROR #3
: Mistakenly using Rapid Clone to migrate from 32 bit Linux to 64 bit Linux.

ORACLE’S RECOMMENDATION: Although these platforms are binary compatible, cloning your E-Business Suite from 32 bit Linux to 64 bit Linux will only produce a 32 bit E-Business Suite environment on your 64 bit operating system. In order to fully exploit your 64 bit operating system you should follow specific migration documentation for your E-Business Suite environment. The same applies to other certified operating systems available as both 32 and 64 bit.


COMMON ERROR #4
:  Mistakingly forgetting to update the central inventory when overwriting a previous clone with a new clone in the same location.

ORACLE’S RECOMMENDATION: If you regularly repeat a clone to the same location on a target node, you must ensure the central inventory entries for the previous clone are removed before configuring the new clone. As with a repeated installation, when deleting an E-Business Suite environment prior to cloning to the same location, in addition to shutting down and deleting files, you must also remove its entries from the central inventory. The central inventory is a file based repository of all Oracle homes installed on a node. This central inventory may exist outside the E-Business Suite file system and is not always removed when you remove the E-Business Suite file system. If the central inventory contains entries for previously deleted E-Business Suite environments then subsequent new clones may fail.


COMMON ERROR #5: Assuming that the clone is not a completely accurate copy.

ORACLE’S RECOMMENDATION: A system created using Rapid Clone is the most genuine and supported copy you can create. It has an identical database, application tier and technology stack as the source environment it was created from. The only significant difference between a source and target clone environment is the data specific to the new hardware (node names, directory locations etc.). It is supported to clone your production environment, apply patches to the clone and then clone the patched system back to become your new production environment. Assuming the cloning documentation is followed correctly, an E-Business Suite environment does not degrade through being repeatedly cloned.

References

Related Articles

Friday Jul 13, 2012

Five Errors Customers Make When Installing E-Business Suite 12 (Part 1)

One customer recently asked if we could supply documentation and scripts to remove all the E-Business Suite objects from their database leaving them with an empty database. After a few questions, it became apparent they were concerned about performance and a third party consulting organisation had advised the best solution to performance problems was to export and then import the whole database.

Whilst it’s true an export/import might solve performance problems, there are many other things you can do before you conclude the best solution is an export/import; it’s certainly not the default solution. That’s a pretty extreme example but there are quite a few myths and misunderstandings which seem to crop up regularly in Service Requests.

This is the first in a series of short articles that lists a few of the technical myths or misunderstandings about Oracle E-Business Suite. Other articles have covered cloning, patching, migrations, upgrades, and maintenance. This first article discusses installations.

Each article is absolutely not definitive and I’d be particularly interested in comments from readers who think there are other misconceptions about the day to day maintenance and upgrade of a typical E-Business Suite environment.


COMMON ERROR #1: In a global implementation, putting your database tier host in your global data centre and putting local application tier hosts in each country.

ORACLE’S RECOMMENDATION: You must put all host nodes of your E-Business Suite environment in one data centre with the fastest possible network connection between nodes. This applies regardless of the location of your users.


COMMON ERROR #2: Placing concurrent processing services and the database tier on the same node to improve performance.

ORACLE’S RECOMMENDATION: There is no significant performance benefit to placing concurrent processing and the database tier on the same node. Your system will be more scalable if your database tier hardware is dedicated solely to serving the needs of the database. Patching, cloning and E-Business Suite administration will also be much easier as you will have at least one less APPL_TOP and application tier technology stack to maintain. Placing concurrent processing on the database tier node to distribute load might suggest that your application tier hardware is already undersized. You should place concurrent processing on the same nodes as your web/forms services or create a dedicated concurrent processing tier in exceptionally busy environments.


COMMON ERROR #3: Installing only the default database character set although you know that you will need a different character set later.

ORACLE’S RECOMMENDATION: Failing to consider national language support (NLS) and database character set requirements when installing a new environment is a critical mistake. You should normally have a very good idea of language requirements before you start your installation. Implement the correct languages and database character set when you perform your installation. Characters sets can be changed later and languages can also be added but if you think you are going to need them then implement them early in your project. Realising that you have forgotten the purchasing team in Denmark the day before you go live will not make you a popular DBA.

You cannot specify a different character set when upgrading to R12. The R12 upgrade process cannot do a character set conversion.


COMMON ERROR #4: Separating Oracle database and application tier ownership by different operating system users/groups.

ORACLE’S RECOMMENDATION: In simple single node installations the whole E-Business Suite file system (including the database) can be owned by a single user/group. This can simplify installation and maintenance. Oracle documentation and Oracle Support engineers sometimes refer to the ‘applmgr’ user and the ‘oracle’ user. These are generic terms used loosely to describe the operating system owner of the application and database tier file systems respectively – they are not mandatory user names. It is also not mandatory to perform E-Business Suite installations as the root user.


COMMON ERROR #5: Before retrying a failed installation, forgetting to remove its entries from the central inventory.

ORACLE’S RECOMMENDATION: When deleting an E-Business Suite environment, in addition to shutting down and deleting files, you must also remove its entries from the central inventory. The central inventory is a file based repository of all Oracle homes installed on a node. This central inventory may exist outside the E-Business Suite file system and is not always removed when you remove the E-Business Suite file system. If the central inventory contains entries for previously deleted E-Business Suite environments then subsequent new installations may fail.

References

Related Articles

Tuesday May 08, 2012

Understanding Options for Integrating Oracle Access Manager with E-Business Suite

Integrating Oracle Access Manager with the E-Business Suite can be tricky.  This is especially true if you're upgrading from EBS 11i to 12, or perhaps also switching from the older Oracle Single Sign-On technology to Oracle Access Manager.  Thing can get even more complicated if you're interested in integrating the E-Business Suite with a third-party authentication system such Windows Kerberos, or managing your users in a third-party LDAP directory like Microsoft Active Directory.

Understanding your options for integrating EBS with Oracle Access Manager and Oracle Internet Directory has just gotten a bit easier.  First, we've just published a new document that lays out the options and our recommendations:

OAM Oracle Access Manager architecture diagram and flow

This new document discusses:

  • Single sign-on concepts
  • Options for integrating single sign-on solutions for Oracle E-Business Suite including the following:
    • How the Oracle Access Manager Integration Works
    • How the Oracle Single Sign-On (OSSO) Integration Works
    • Integration with Third-Party Access Management Systems and LDAP
  • Considerations to take into account when choosing a single sign-on solution
  • Documentation roadmap specifying which document to follow dependent upon your integration goal
  • Reference architecture diagrams depicting example components by Oracle E-Business Suite release

Reworked instructions for integrating Oracle Access Manager + E-Business Suite 

In addition to the new overview document above, we've also made extensive revisions and updates to this previously-published document:

The updated Note is the result of your emails, Service Requests, and feedback to us on how we can improve our documentation. This is still an admittedly-complex implementation, with many detailed and exacting steps.  We're examining ways of streamlining and possibly automating some of the implementation steps in a future update to this certification.

Your feedback is welcome

We've tried hard to make this complex area just a little bit more-accessible.  We would love to hear about your experiences with these components.  Your feedback regarding the new note and updated note is welcome.  Please either post a comment here or log a bug request against the note in My Oracle Support.

References

Related Articles

(Special thanks to Allison Sparshott  and Hubert Ferst for their combined efforts in crafting these updates.)

Tuesday May 01, 2012

EBS File Comparison Report Now Available

If your Oracle E-Business Suite customizations are still making you hesitate about upgrading from Release 11i to Release 12, we have another useful tool to help you along: the brand new EBS File Comparison Report. This new report joins the related EBS Seed Data Comparison Report and the EBS Data Model Comparison Report in our collection of handy upgrade comparison reports.

You can download the new file comparison report here:

You can download its companion reports here:

File Comparison Report Contents

The new report provides detailed information about what files were added, removed, or stubbed (made inactive) during changes between Releases 11.5.10.2 and 12.1.3 of Oracle E-Business Suite. For text-based files such as .xml files, you can drill down into the files to see the actual changes between the file versions. The File Comparison Report includes the following file types:

  • Forms (.fmb files)
  • Libraries (.pll files)
  • Reports (.rdf files)
  • Java (.class files)
  • Java Server Pages (.jsp files)
  • Oracle Application Framework (OAF) Pages (.xml files)
  • Oracle Application Framework (OAF) Personalizations (.xml files)
  • Workflow Definition (.wft files)
  • Workflow Business Event System Object Definitions (.wfx files)
  • BI Publisher (XML Publisher) Reports - Layout template formats
  • BI Publisher (XML Publisher) Reports - Data Definition formats

Using the File Comparison Report

One example of how you might use the File Comparison Report is for assessing upgrade impacts on your personalizations. Start by getting a list of your personalizations as described in “Upgrading Form Personalizations and OA Framework Personalizations from Oracle E-Business Suite Release 11i to 12.1” (Note 1292611.1).

Three categories of personalizations might be affected by upgrades. Here is how the File Comparison Report can help you with those:

  1. Personalizations shipped by product teams that you might have modified further: look at “Oracle Application Framework (OAF) Personalizations (.xml files)” to see which shipped personalizations have changed. You can drill in to see exactly what has changed for each affected personalization.
  2. OA Framework Personalizations where the shipped base page may have changed: look at “Oracle Application Framework (OAF) Pages (.xml files)” to see which shipped pages have changed. You can drill in to see exactly what has changed for each affected personalization. If a page you have personalized hasn’t changed between releases, you probably do not need to change your personalizations for the page in the new release.
  3. Oracle Forms Personalizations where the shipped form may have been removed: look at “Forms (.fmb files)”. Because these are binary files, you cannot see exactly what has changed for each form, but knowing what forms have been removed will still save you time in assessing what form personalizations can be retired.

Personalization assessment is just one example of how you can use the File Comparison Report. We expect you will find many ways to use it!

Your feedback is welcome

This new tool was produced by our hard-working EBS Release Management team, and they are actively seeking your feedback. Please feel free to share your experiences with it by posting a comment here. You can also request enhancements to this tool via the My Oracle Support Community mentioned in Note 1446430.1.

Related Articles

Friday Mar 16, 2012

New Whitepaper: Upgrading your Customizations to Oracle E-Business Suite Release 12

Cover page for upgrading customizations whitepaperThe prospect of upgrading from Oracle E-Business Suite Release 11i to Release 12 might seem intimidating if you have customized your EBS 11i environment. When considering this upgrade, one of the first things you need to do is review your customizations systematically.

I am pleased to announce the availability of a new white paper that will help you do that:

This white paper provides an overview of how you can manage and upgrade existing Release 11i customizations to Release 12.1. It covers identifying the various types of customizations you might have--such as personalizations, Oracle Forms, Web ADI, and mod_plsql--and how to handle them during your upgrade.

The document discusses upgrading Oracle E-Business Suite customizations in the context of the following cycle:

  1. Creating an inventory of your existing customizations
  2. Comparing customizations to standard Release 12 functionality
  3. Upgrading customizations
  4. Reimplementing customizations
  5. Creating future customizations

The paper also provides recommendations on customization technologies such as Oracle Application Framework (OAF), Oracle Application Express (APEX), and Oracle Application Development Framework (ADF).

This white paper is written for Oracle E-Business Suite system administrators, DBAs, developers, and implementers.

Related Webcast

Related Articles

Thursday Mar 15, 2012

Identifying the Latest Family Packs for Oracle E-Business Suite

It's important to ensure that your E-Business Suite environment is kept current, but it can be tricky to identify the latest product-level Family Packs that have been released.  You might need to identify the latest Family Pack updates available for an Oracle E-Business Suite R12 or R11i environment when performing one of the following tasks:

  • Researching the latest functionality available
  • Implementing a new module
  • Planning an upgrade to your Oracle E-Business Suite environment
Two useful links are available on My Oracle Support that provide a listing of packs  for an Oracle E-Business Suite R12 or R11i environment.  To navigate to a listing of packs, first login to My Oracle Support.  Once logged in, navigate to the Patches & Updates tab:


Once on the Patches & Updates section, navigate to the Patching Quick Links region.  This region contains links to Latest R12 Packs and Latest R11i Packs:



After clicking one of the links for either R12 or R11i packs, you will be directed to a new screen that displays all available packs for the selected version.  Here's an example of the screen displayed upon clicking the Latest R12 Packs link (naturally, the actual Family Pack references may change over time):



Note that for R12, the listing displayed is the latest packs available for the most current release of R12.  Currently, this is Release 12.1.3.  For Release 11i, the listing displayed is for the most current release of R11i., 11.5.10.  

Related Articles

Tuesday Feb 21, 2012

ATG Live Webcast: E-Business Suite Data Protection

How do you address the security challenges within an E-Business Suite database? How should you make the best use of auditing, separation of duties, and other Oracle technologies with Oracle E-Business Suite? Join us for this week's ATG Live Webcast on Feb. 23, 2012:

E-Business Suite Data Protection

Join Robert Armstrong, Product Strategy Security Architect and Eric Bing, Senior Director, as they discuss the best practices and recommendations for securing your E-Business Suite data. The agenda for the E-Business Suite Data Protection webcast includes the following topics:

  • E-Business Suite Security Challenges
  • Auditing in E-Business Suite
  • Separation of Duties
  • Other Oracle Technologies for Data Security

Screenshot of E-Business Suite Data Access auditing

Date:               Thursday, February 23, 2012

Time:              8:00 AM - 9:00 AM Pacific Standard Time
Presenters:  Robert Armstrong, Product Strategy Security Architect
                        Eric Bing, Senior Director

Webcast Registration Link (Preregistration is optional but encouraged)

To hear the audio feed:
    Domestic Participant Dial-In Number:           1-877-697-8128
    International Participant Dial-In Number:      1-706-634-9568
    Dial-In Passcode:                                              99336

To see the presentation:
    The Direct Access Web Conference details are:
    Website URL: https://ouweb.webex.com
    Meeting Number:  593089134

If you miss the webcast, or you have missed any webcast, don't worry -- we'll post links to the recording as soon as it's available from Oracle University.  You can monitor this blog for pointers to the replay. And, you can find our archive of our past webcasts and training here.

If you have any questions or comments, feel free to email Bill Sawyer (Senior Manager, Applications Technology Curriculum) at BilldotSawyer-AT-Oracle-DOT-com.

Wednesday Aug 03, 2011

Why Does EBS Integration with Oracle Access Manager Require Oracle Internet Directory?

The E-Business Suite has its own security and user-management capabilities.  You can use the E-Business Suite's native features to authenticate users, authorize users (i.e. assign responsibilities to them), and manage your EBS user repository.  The majority of E-Business Suite system administrators simply use these built-in capabilities for enabling access to the E-Business Suite.

When EBS built-in capabilities aren't enough

Some organisations have third-party user authentication systems in place.  These include CA Netegrity SiteMinder, Windows Kerberos, and others.  These organisations frequently use third-party LDAP directory solutions such as Microsoft Active Directory, OpenLDAP, and others. 

We don't certify the E-Business Suite with those third-party products directly, and we don't have any plans to do so.  This article is intended to explain why Oracle Internet Directory (OID) is required when integrating with Oracle Access Manager (OAM), but you can safely infer that the same requirements prevent the use of third-party authentication products directly with the E-Business Suite.

It's possible to integrate the E-Business Suite with those third-party solutions via Oracle Access Manager and Oracle Internet Directory.  See these articles:

Before going on, I'd recommend reading one of those two third-party integration articles.  If you don't have those concepts under your belt, the rest of this article isn't going to make much sense.

Architecture diagram showing Oracle Access Manager Oracle Internet Directory E-Business Suite AccessGate WebGate

Why does EBS require OID with OAM?

Oracle Access Manager itself doesn't require Oracle Internet Directory.  However, Oracle Internet Directory is a mandatory requirement when Oracle Access Manager is integrated with the E-Business Suite.

Why?  The short answer is that the E-Business Suite has hardcoded dependencies on Oracle Internet Directory for this configuration. These dependencies mean that you cannot replace Oracle Internet Directory with any third-party LDAP directory for this particular configuration. 

There are two cases of hardcoded dependencies on Oracle Internet Directory:

1. Reliance on Oracle GUIDs

From the articles linked above, you know that user authentication is handled by Oracle Access Manager, and user authorization is handled by the E-Business Suite itself.  This means that there are two different user namespaces. 

These namespaces must be linked and coordinated somehow, to ensure that a particular user logging in via Oracle Access Manager is the same user represented within the E-Business Suite's own internal FNDUSER repository.

We associate externally-managed Oracle Access Manager users with internally-managed E-Business Suite users via a Global Unique Identifier (GUID).  These Global Unique Identifiers are generated exclusively by Oracle Internet Directory. 

The E-Business Suite has hardcoded functions to handle the mapping of these Global Unique Identifiers between Oracle Access Manager and the E-Business Suite.  These mapping functions are specific to Oracle Internet Directory; it isn't possible to replace Oracle Internet Directory with a generic third-party LDAP directory and still preserve this functionality.

2. Synchronous user account creation

The E-Business Suite is predominantly used internally within an organisation.  Certain E-Business Suite application modules can be made visible to users outside of an organisation.  These include iStore, iRecruitment, iSupplier, and other application modules where the users aren't necessarily restricted to an organisation's own employees.

Users of some of those application modules expect to be able to register for a new account and use it immediately.  This makes sense.  If you're posting job openings via iRecruitment, potential applicants shouldn't need to hold off on submitting their resumes while your E-Business Suite sysadmin creates an account manually, assigns EBS responsibilities, and emails them the account login details. They'll be long gone before that happens.

This means that EBS application modules that support self-registration must create user accounts synchronously.  A new account must be created within the E-Business Suite and the externalized directory at the same time, on demand.

The E-Business Suite has hardcoded dependencies upon Oracle Internet Directory function calls that handle these synchronous account creation tasks.  These function calls are specific to Oracle Internet Directory; it isn't possible to replace Oracle Internet Directory with a generic third-party LDAP directory and still preserve this functionality.

Sun is setting for Oracle Single Sign-On

The older articles linked above refer to Oracle Single Sign-On.  All conceptual references to Oracle Single Sign-On apply equally to Oracle Access Manager.  Oracle Access Manager offers the same capabilities as Oracle Single Sign-On when integrated with the E-Business Suite.

You may have noticed that I have specifically been referring to Oracle Access Manager rather than Oracle Single Sign-On in this article.  There's a very good reason for this.

The Fusion Middleware Lifetime Support Policy shows that Premier Support for Oracle Single Sign-On 10gR2 ends on December 2011.  If you're using Portal 11gR1, Forms & Reports 11gR1, or Discoverer 11gR1, Premier Support for Oracle Single Sign-On 10gR2 is extended to December 2012. 

Extended Support is not available for Oracle Single Sign-On 10gR2.  This is true regardless of whether you're using those other Fusion Middleware 11gR1 products or not.  These support policy timelines for Oracle Single Sign-On are not affected by the E-Business Suite's own support timelines.  There are no special exceptions from these Fusion Middleware support timelines for E-Business Suite customers. 

Given that the Oracle Single Sign-On is nearing its end-of-life, anyone considering a new external authentication solution for the E-Business Suite should use Oracle Access Manager at this point.  If you're currently using Oracle Single Sign-On, I would recommend evaluating your plans for migrating to Oracle Access Manager as soon as possible.

Related Articles


Thursday Jul 28, 2011

EBS Support Information Center + Patching & Maintenance Advisor Available on My Oracle Support

The Knowledge Base in My Oracle Support is a sprawling database.  It can be very difficult to find the right needle in that haystack.  My Oracle Support colleagues have recently published two new resources on My Oracle Support that highlight some documents that Apps DBAs might find useful.

Screenshot of EBS Support Information Center Noe 1322667.1

1. EBS Support Information Center (Note 1322667.1) contains pointers to:

  • EBS Diagnostics
  • EBS Upgrade related resources
  • EBS Electronic Technical Reference Manual (e-TRM)
  • EBS Release Content Documents (RCD)
  • Oracle Support webcast series
  • Oracle Support newsletters

2. Patching & Maintenance Advisor: E-Business Suite 11i and R12 (Note 313.1) contains pointers to:

  • EBS 11i and 12 Patching Frequently Asked Questions (FAQ)
  • Patching best practices
  • Methods for reducing patching downtimes
  • Patch Wizard

Related Articles


Wednesday Jul 27, 2011

Reminder: ATG Live Webcast July 28: Upgrading EBS 11i Customizations to Release 12

Reminder: Our next ATG Live Webcast is happening tomorrow, Thursday, July 28th:

This one-hour webcast provides an overview of how Oracle E-Business Suite system administrators, DBAs, developers, and implementers can manage and upgrade existing EBS R11i customizations to R12.x.

Topics will include:

  • Your Customization Inventory
  • Comparing Customizations - Release 11i to Release 12.x
  • Managing Common Customization Types
  • Managing Deprecated Technologies
  • Anticipating Future Customizations
Upgrading your Customizations to Oracle E-Business Suite 12.x

Date: Thursday, July 28, 2011
Time: 8:00 AM - 9:00 AM Pacific Standard Time (4.00 PM - 5.00 PM GMT)
Presenter: Sara Woodhull, Principal Product Manager, ATG Development

Direct link to the webcast:

https://ouweb.webex.com/ouweb/j.php?ED=164995277&UID=1269704602&RT=MiM0

The dial-in numbers are:

https://ouweb.webex.com/ouweb/j.php?ED=164995277&UID=1269704602&RT=MiM0

The dial-in numbers are:
Domestic Participant Dial-In Number: 877-697-8128
International Participant Dial-In Number: 706-634-9568
Additional International Dial-In Numbers Link: http://www.intercall.com/national/oracleuniversity/gdnam.html
Dial-In Passcode: 95668

You may optionally preregister for the webcast here.

If you have any questions or comments, feel free to email Bill Sawyer (Senior Manager, Applications Technology Curriculum) at BilldotSawyer-AT-Oracle-DOT-com. 

Related Articles

Tuesday Jul 26, 2011

What's the Best Way to Patch an E-Business Suite Environment?

One of our senior Oracle Support engineers recently asked, "What's the best strategy for applying patches to E-Business Suite environments?"  Applying updates and patches is such a major part of an Apps DBA's responsibilities that I assumed that this was already covered in our existing documentation. In looking through our systems administration guides, I was surprised to find that this isn't discussed anywhere.

Here's a general best practices patching strategy for all EBS environments.  In order of priority, you should:

  1. Apply the latest EBS Release Update Pack.
    For example: 12.1.3 for Release 12.1, 12.0.6 for Release 12.0, 11.5.10.2 for Release 11i.

  2. Apply the latest EBS Family Packs and all patches on the Recommended Patch List.
    This includes ATG Release Update Packs and AutoConfig updates.

  3. Upgrade all technology stack components to the latest certified levels.
    For example, as of today, the latest certified levels for EBS 12 are Database 11.2.0.2, Forms 10.1.2.3, OC4J 10.1.3.5, Oracle Internet Directory 11.1.1.3.  Check the Certifications database on My Oracle Support or this blog's one page summary of EBS certifications for a snapshot of the latest certified patchsets for technology stack components.

  4. Apply the latest Critical Patch Updates (CPU)
    You should always apply the latest security patches.  Always.  These are released quarterly.

  5. <Optional> Apply the latest Database Patch Set Updates (PSU) and the required EBS prerequisites
    It's safe to apply Database PSUs to your EBS environment.  Some customers like the convenience of PSUs.  Some don't.  It's up to you.

  6. Apply specific one-off and interim patches...
    ... but only if they're really required for your environment.  This applies to both EBS and technology stack component patches.  You're generally better-off waiting for patches to be rolled into the bigger release vehicles listed in #1 to #4, above.  Those consolidated release vehicles are tested more comprehensively with all Apps modules and configurations than one-off or interim patches. 

Pay attention to the ranking

The order of priority is important.  Most customers have difficulties in keeping up with the first four sets of updates.  If you do keep current with those first four categories of patches, the amount of incremental work associated with the remaining two categories is minimal and can generally be avoided entirely.

Why bother patching?

Because it's cheaper and safer in the long run.  I'm always surprised by customers who pay more attention to maintaining their car than a mission-critical enterprise resource planning system.

The E-Business Suite is a large, complex system.  The further you fall behind in maintaining your system:

  • The more work it requires to isolate and resolve issues.
  • The greater the likelihood of encountering an avoidable known issue.
  • The greater the risk of upgrading from an untested configuration to a new version.
  • The greater the effort required to upgrade to new versions.
  • The greater the risk that you will not be able to get patches for your existing configuration.

Use tools to automate your updates

The savvy DBA takes advantage of as many tools as possible to automate these updates.  If you are still applying patches manually to every EBS environment, you're wasting a lot of time.  Check out the Application Change Management Pack for Oracle E-Business Suite (part of the Application Management Suite).  This Enterprise Manager plug-in automates the process of checking for required patches, staging those patches, then applying those patches to multiple EBS environments. 

Yes, it requires additional licencing, but I think that most organisations can recoup those costs very, very quickly.  Patching manually is time-consuming, error-prone, and tricky to keep organized when you have multiple development, staging, QA, and preproduction environments.  In my eyes, automation is really the only solution.

Formal documentation updates are coming

Future versions of our formal EBS documentation will include this advice.  Our Oracle Support team is also working on a set of Life Cycle Advisor documents for the E-Business Suite.  They tell me that this will cover everything a DBA should know if you've never applied patches to EBS before.  I'll profile those new Advisor guides as soon as they're published.

Related Articles

Saturday Jul 16, 2011

E-Business Suite Technology Frequently Asked Questions (FAQ)

Last updated: February 21, 2013

Given changes to our blogging platform this year, it's gotten much harder to browse and locate previously-published articles on certain topics.  As a workaround, here's a FAQ to act as an index to our most-commonly referenced articles.


1. EBS Technology Stack Basics

Q: I'm completely new to Oracle E-Business Suite.  Where do I start?

A: There's a lot to learn, but don't get intimidated.  This article is a good starting point to understand key terms.  The latest EBS 12.1 documentation is hereThis article has pointers to good resources for beginners, including formal training from Oracle University.

Three tier architecture for EBS 12.0 and 12.1

Q: How can I keep current on EBS technology stack news?

A: We announce over 120 new certifications a year.  Stay current by monitoring or subscribing to this blog.  We publish roadmaps for upcoming certifications few times a year.  The latest is available here.

Q: Where can I find documentation for EBS technology stack components?

A:  Documentation for the EBS 12.1 is here; documentation for older releases is here.  Technology stack components that must be updated regularly are cross-referenced in these Note roadmaps:

Q: What are the latest E-Business Suite releases?

A: There are two types of EBS releases:  Rapid Installs and Release Update Packs.  Rapid Installs can be used to create a brand-new E-Business Suite environment.  Release Update Packs can only be applied on top of an existing environment.  The releases are:

Q:  What technology stack versions were included in the latest EBS releases?

A:  Here's a summary of the bundled technology stack components in the three EBS 12 Rapid Install releases that you can (and should) upgrade yourself as new versions become available.


2. Support Policies

Q: I'm having a problem.  How can I get help?

A: Sadly, this blog isn't the best place to get technical support.  For technical support resources and tips on logging Service Requests with Oracle Support, see this article.

Q: Is my third-party product supported with Oracle E-Business Suite?

A: We test specific Oracle products with the Oracle E-Business Suite.  This is called certification. We don't certify the E-Business Suite with third-party products, but you can certainly use them.  We distinguish between certification and support.  For details, see this article.

Q: What do I need to know about support for EBS 11i?

A: Premier Support ended on Nov. 30, 2010.  Extended Support began on Dec. 1, 2010.  New EBS 11i patches will be created for a minimum baseline environment.

Q: What do I need to know about EBS 12 Support dates and patching baselines?

A:  They're governed by two interlocking policy documents.  If you're running EBS 12, you must ensure that you're on these minimum patching baselines.

EBS Premier and Extended Support timelines


Q: How do Server Technologies (Database) support policies affect EBS environments?

A: Database support dates for Premier, Extended, and Sustaining support apply to E-Business Suite, too.  EBS users do not get any special exemptions from Oracle Database support dates.

Q: How do Fusion Middleware support policies affect EBS environments?

A:  Support policies for Fusion Middleware components used by EBS are a bit more complicated.  See this article for details.



3. Upgrades and Migrations

Q: I want to upgrade from EBS 11i to 12.  Where do I start?

    Q: I need to migrate my server to a different platform.  Where do I start?

    A: Verify that your target platforms are certified.  Plan your migration carefully.  Evaluate available tools for the job, including the Transportable Database process or Transportable Tablespaces.

    Q: I plan to upgrade EBS and migrate my server platforms.   Which do I do first, and what tools can I use?

    A: In general, migrating your database server to faster hardware will make your EBS upgrades faster.  There are more considerations for different endian platforms.  For more details, see this whitepaper on best practices.



    4. EBS System Maintenance

    Q: My E-Business Suite environment has slowed down.  What can I do?
    A: Start here.  Power users will love the additional tweaks and tips referenced in this article.

    Q: How can I reduce my maintenance downtimes?
    A: There are seven ways to reduce your patching downtimes.  EBS 12 users can also optimize AutoConfig execution and run AutoConfig in parallel.

    Q: What resources are available to help me test my environment?

    A: Testing is vital; your EBS environment is unique.  You can use testing tools like the Oracle Application Testing Suite.  We provide Test Starter Kits for older tools such as WinRunner and QuickTest Professional, too.

    Q: What's the best strategy for maintaining my environment?

    A: Apply EBS and technology stack updates to your environment in this order of priority.



    5. General Certifications

    Q: Is <version X> of <component Y> certified with the E-Business Suite?

    A: Check this one-page summary.  If what you're looking for isn't listed, check the official certification database on My Oracle Support.

    Q: When will the next version of <something> be released or certified with EBS?

    A:  Oracle's Revenue Recognition rules prohibit us from discussing certification and release dates.  And, besides, it's just unwise for us to speculate about dates.  This is why.

    Q: Is my third-party product supported with Oracle E-Business Suite?

    A: We test specific Oracle products with the Oracle E-Business Suite.  This is called certification. We don't certify the E-Business Suite with third-party products, but you can certainly use them


    Wednesday Jun 15, 2011

    OAUG/Collaborate Recap: Best Practices for E-Business Suite Performance Tuning

    [June 24, 2011 Update: Added link to PDF version]

    We have an Applications Performance Group whose raison-d'etre is to ensure that the E-Business Suite runs at peak performance in all circumstances.  This team has helped tune the E-Business Suite environments of world's largest companies to handle staggering amounts of transactional volume in multi-terabyte databases.  This group also publishes our official Oracle Apps benchmarks, white papers, and performance metrics.

    Isam Alyousfi and Lester Gutierrez are key members of our Applications Performance Group.  They recently presented their popular session covering performance tuning tips for all layers of the E-Business Suite at OAUG/Collaborate earlier this year.  It's available for download here:

    EBS Architecture diagram from a performance perspective

    This sprawling presentation covers:

    • Performance-oriented architectural overview of the E-Business Suite, with drilldowns to key techstack modules
    • Methodology for approaching performance issues, including isolation of performance problems within a particular area (e.g. database vs. application tier)
    • Comprehensive list of performance-related data to gather, including SQL tuning, PL/SQL Tuning, Reports Tracing, Database tuning, Forms tuning, Middle tier tuning
    • Methods for conducting root-cause analysis for performance issues
    • Methods for selecting the right diagnostics for particular classes of performance issues
    • Tuning the Applications tier:  Forms, OC4J/JVM, CPU and response time issues, garbage collection tuning, handling OutOfMemoryErrors and memory leaks, client process CPU drains
    • Tuning the Concurrent Manager: cache size, dedicated concurrent managers, FND table purging, workload management tips, transaction managers for synchronous online processing
    • Tuning the Client and Network: minimizing browser footprints, network routing issues, packet loss
    • Tuning the Database: mandatory init.ora settings, required performance patches, use of key database features like Auto Memory Management, conversion to the Oracle Applications Tablespace Model (OATM), I/O optimization, statistics gathering, establishing baselines for different workloads, using SQL Performance Analyzer and SQL Plan Management, AWR reviews, DB Console, TKPROF, 11g performance-related enhancements
    • Tuning EBS products: Release Update Pack recommendations, performance-related product patches, Workflow best practices, purging and archiving, runtime performance testing 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.

    Related Articles


    Friday May 13, 2011

    New Whitepaper: Extending E-Business Suite 12.1.3 using Oracle Application Express

    I'm pleased to announce the availability of a new whitepaper:

    • Extending Oracle E-Business Suite Release 12 using Oracle Application Express (APEX) (Note 1306563.1)
    Oracle Application Express APEX screenshot

    It's possible to personalize the E-Business Suite, but there may be situations where personalizations aren't sufficient to meet your requirements. In these scenarios, Oracle Application Express, also known as Oracle APEX, is an option for creating supplemental applications that can be integrated with your Oracle E-Business Suite instance.

    This new whitepaper outlines how to extend Oracle E-Business Suite 12.1.3 (and higher) functionality using Oracle Application Express. Recommended architecture and security considerations are discussed in detail.

    You can also find the whitepaper on the APEX OTN Site > Learn More > Technical Information and White Papers > Extending Oracle E-Business Suite Release 12 using Oracle Application Express (PDF).

    Related Articles


    Wednesday Feb 09, 2011

    New Whitepaper: Upgrading EBS 11i Forms + OA Framework Personalizations to EBS 12

    Personalizations are -- and have always been -- one of the safest and most upgradable ways to "customize" your Oracle E-Business Suite screens, both for Oracle Forms-based screens and for Oracle Application Framework-based pages. However, the upgrade from Release 11i to Release 12.1 spans many years of EBS evolution, during which time Oracle has actively been building many new features and modules. A lot has changed in Oracle E-Business Suite that may affect upgrading your personalizations from 11i to 12.1. 

    We have published a new note on My Oracle Support that discusses ways to evaluate your existing personalizations:

    Two distinct types of personalizations

    There are two distinct types of personalizations:

    1. Form Personalization
    2. OA Framework Personalization.

    Both types of personalization are completely metadata-based. The personalizations are stored as data in database tables. However, because the underlying technologies (Oracle Forms and OA Framework) are very different, Forms personalizations and OA Framework personalizations are not equivalent and cannot be converted or migrated from one to the other.

    Diagram showing how personalizations can be transported for like-to-like functionality from EBS 11i to 12 Like-to-Like.gif

    Critical factors when affecting upgradeability

    Upgradability of personalizations is based on the premise that you are upgrading "from like to like." That is, a personalization based on a certain form, affecting certain fields, will be upgradable to the next version of the same form assuming that the underlying structure of the form is the same (that is, the blocks and fields touched by the personalization are still in the form and have the same names). In other words:

    • For an upgrade from one minor release to another minor release, personalizations are generally likely to be upgradable.
    • For an upgrade from one major release (11i) to another major release (12.1), personalizations are much less likely to be upgradable.

    Personalizations that need to be reimplemented manually

    A personalization is not upgradable if you are not upgrading "from like to like." This can happen for a number of reasons:

    1. A screen or page has been sufficiently modified in the new version of the product such that the old objects that were personalized no longer exist in the new version. For the 11i to 12 upgrade, however, forms are more likely to have been rebuilt in OA Framework than to have been modified using Oracle Forms.
    2. An Oracle Forms-based screen has been replaced by an OA Framework-based page. This is very common across the 11i to 12.1 upgrade, because many products have rebuilt a lot of their Oracle Forms-based functionality into OA Framework while adding or redesigning other features. For example, the user interface for item instance functionality in Oracle Install Base has been rewritten in OA Framework.
    3. A screen or page has been moved into a different product, so the personalization metadata no longer applies (because each product has its own namespace). For example, between 11i and 12.1, some payments forms were removed from Oracle Payables (AP) and their functionality was consolidated with other payments functionality into a new Oracle Payments (IBY) module. Personalizations made to those original AP payments forms would no longer apply.

    Comparing EBS 11i screens to EBS 12 equivalents

    For the most part, when you upgrade an OA Framework-based page from Release 11i to 12.1.3, that OA Framework page will still exist in 12.1.3 unless the specific Oracle E-Business Suite product has been heavily redesigned. So in general, OA Framework personalizations are likely to upgrade smoothly ("like to like") to 12.1.3, though of course it depends on the specific products you have.

    There are various ways to tell if a particular form or page no longer exists in 12.0 or 12.1. Generally, you should start with the upgrade manuals for your installed products and determine if there has been a major redesign of any of the modules you have. In those cases, most of your form personalizations will no longer apply, and in fact, you will probably no longer need them anyhow. For example, as mentioned above, payments functionality has been moved into a separate Oracle Payments module (IBY). Many customizations you might have had for that functionality can be retired instead of re-implemented because the new product offers significant configurability, and features were added as standard that previously may have required customization to achieve.

    For further information, see Note 1292611.1.  Happy reading and upgrading!

    References

    Related Articles


    Thursday Oct 14, 2010

    Understanding Support Windows for E-Business Suite Releases

    [December 9, 2010 Update:  Your feedback led us to review this policy.  In response to your comments, we've made a number of important changes to relax these support policies.  These changes are published in Version 2 of the E-Business Suite Error Correction Support Policy released earlier this month.  For a summary of these changes, see this blog article.]

    E-Business Suite support is governed by two interlocking support policies:   
    1. Oracle's Lifetime Support Policy
      Specifies support dates for major EBS release codelines (e.g. EBS 11.5.10.2, 12.0, 12.1) -- and by implication, the latest EBS patchset for a given codeline. The Lifetime Support Policy presents support definitions and dates for three different levels of support:  Premier, Extended, and Sustaining. 

    2. E-Business Suite Error Correction Support Policy (Note 1195034.1)
      Specifies support dates for EBS release update packs for a given EBS releases codeline covered by Premier Support.  Examples of EBS release update packs (RUPs) include EBS 12.0.2, 12.0.3, 12.0.4, 12.0.5, 12.0.6, 12.1.2, 12.1.3.  
    Together, these two documents present actual support dates or formulas by which you can derive support dates.  The second document is new and introduces a new policy:  
    Oracle Development provides bug fixes for the current EBS release update pack for 18 months after the next release update pack is released.  
    This is called the grace period.  The grace period is designed to give you adequate time to upgrade to the latest EBS release update pack.

    A RUP is supported for the duration of its 18 month grace period even if multiple new RUPs come out during that period.  The 18 month grace period will always be honoured for its full duration.
    Translating support policies to support windows for specific EBS releases

    If you read both documents and parse things out carefully, you can derive the following snapshot of current support dates for the following releases:
    • EBS 11.5.10.2
      This is the latest patchset on this EBS codeline, so the Lifetime Support Policy applies.
      Premier Support runs to November 30, 2010; Extended Support to November 30, 2013.
      Also remember that your EBS 11.5.10.2 environment must have a certain minimum level of patches to be eligible for Extended Support.

    • EBS 12.0.6
      This is the latest release update pack on the EBS 12.0 codeline, so the Lifetime Support Policy applies.
      Premier Support runs to January 30, 2012; Extended Support to January 30, 2015.

    • EBS 12.1.1
      This isn't the latest release update pack on the EBS 12.1 codeline, so the Error Correction Support Policy applies.  The grace period runs 18 months after the release date of EBS 12.1.2 in December 2009.  The grace period for EBS 12.1.1 is January 2010 to June 2011.  New bug fixes for EBS 12.1.1 are provided until June 2011.

    • EBS 12.1.2
      This isn't the latest release update pack on EBS 12.1 codeline, so the Error Correction Support Policy applies.  The grace period runs 18 months after the release date of EBS 12.1.3 in August 2010.  The grace period for EBS 12.1.2 is September 2010 to February 2012.  New bug fixes for EBS 12.1.2 are provided until February 2012.

    • EBS 12.1.3
      This is the latest release update pack on the EBS 12.1 codeline, so the Lifetime Support Policy applies.
      Premier Support runs to May 30, 2014; Extended Support to May 30, 2017.
    Note that EBS 12.0.4 isn't listed above.  EBS 12.0.4 was supported for 18 months after EBS 12.0.6 was released in November 2008.  The grace period for 12.0.4 ran from December 2008 to May 2010 and is now concluded.  No new bug fixes for 12.0.4 are available now.

    What about E-Business Suite technology stack components?

    Things get more complicated when one considers individual techstack components such as Oracle Forms or the Oracle Database.  If you're interested in learning more about the interlocking EBS+techstack component support windows, see these two articles:
    Related Articles

    Monday Oct 04, 2010

    New Video Primers on EBS Patch Wizard Now Available

    Patching is a perennially hot-topic for E-Business Suite system administrators.  For those of you still running Oracle E-Business Suite Release 11i, patching is especially important as we near the transition between Premier and Extended Support at the end of November 2010

    Patch_wizard_screenshot2.png
    If you're new to EBS system administration, and even if you're a veteran DBA, you might find two new short training videos useful:
    These two videos were produced by Oracle Support.  The first provides a great introduction and review of EBS Patch Wizard basics in just over nine minutes.  The second provides a three-minute demonstration of the new capabilities for reporting on the minimum baseline patch requirements required to be eligible for 11i Extended Support. 
    What's notable about both of these videos is that they actually show you the Patch Wizard in action, and they're really short and sweet.  Highly recommended.

    Related Articles

    Sunday Aug 08, 2010

    EBS Sysadmin Primer: Oracle BI Discoverer 11gR1

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

    Oracle Business Intelligence Discoverer is an ad-hoc query, reporting, analysis, and Web-publishing tool that allows end-users to work directly with Oracle E-Business Suite OLTP data.  We certified Discoverer 11g version 11.1.1.3 (a.k.a. Patchset 2) with the E-Business Suite a few weeks ago.

    discoverer-screenshot-graphs.png
    With that recent certification, I think it's time to cover the installation and configuration of Discoverer 11g with E-Business Suite.  Discoverer 11g's integration with the E-Business Suite works identically to Discoverer 10g, and all of the business intelligence functionality continues to work as in previous Discoverer releases.  The major changes in this release come from Discoverer's installation dependencies on Oracle Application Server components.

    As with other Fusion Middleware components, Oracle Weblogic Server is the required application server for Discoverer 11g.  Like Oracle Identity Management 11g, Discoverer is loosely-coupled with Fusion Middleware's database and application server components. 

    Discoverer 11g Install comes bundled with Oracle Portal, Oracle Forms, and Oracle Reports, as in previous releases like Discoverer 10g.  Since it is loosely coupled with other Fusion Middleware components, you need to install a number of prerequisites prior to discoverer 11g install.

    All of these middleware components have to be at the same version level to work together.  I have summarized these dependencies in the following table:

    Table summarizing Discoverer 11g prerequisites
    References
    Related Articles


    About

    Search

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