Chapter 30: Working with Oracle Support
This chapter is from the book
This chapter is from the book
This chapter is from the book
Chapter 30: Working with Oracle Support
In this chapter
Patches and Upgrades
Diagnosing the Problem
Creating the Technical Assistance Request
Techniques for Working with the Analyst
Working with an Inexperienced Analyst
Getting Results
The Bug Database
The Bug Process
Your ability to work effectively with Oracle Support is a critical success factor for your implementation project and productive use of the Oracle Applications. Working with Support is an acquired skill, and it is well worth your effort to develop this ability. This chapter shows you how to effectively get the most support for your time and money.
Support for the Oracle Applications is a big business. In 2001, Oracle support logs 25,000 Technical Assistance Requests (TARs) a month and makes more than 1.4 million customer contacts a year. There are approximately 800 application analysts on staff. You are not alone when you contact Oracle support.
All TARs are solved in one of four ways:
-
Providing you with a patch to make a change to your system
-
Explaining the correct functionality for the application
-
Fixing data within the application
-
Fixing something in your environment
Because Oracle software runs on many different hardware platforms and operating system versions, Oracle Development freezes the code periodically for a specific release combination of hardware, operating system, database, and tools. This frozen version is labeled something like Release 11.03 or Release 11.5.4, and that is the code that Oracle ships to you. While your project to implement the Applications progresses, Oracle continues to modify and maintain the unfrozen versions of these programs. The frozen version that you have on your system can be as much as 12 to 14 months older than the current version. For each program, the unfrozen version that Support has might have 20 to 30 changes to it. When you hit a problem with your frozen version, Oracle Support can get you an updated copy via a patch.
Oracle Support has the following services:
-
Provide a searchable, knowledge-base tool, called MetaLink, for problem research and resolution.
-
Provide remote telephone communications that support beta and production code released from Oracle Development.
-
Isolate and verify problems with Oracle released code. Provide solutions for valid problems.
-
Answer product usage questions. (Support is not a substitute for a proper course of education or researching the reference manuals.)
-
Interpret error messages and conditions during installation or usage of the Oracle Applications.
Patches and Upgrades
Patches can be new versions of the executable reports, forms, packages, procedures, triggers, and programs. Patches can also contain code to add or make changes to your data or the structure of the database. Periodically Oracle Support groups many patches to form a bundle of patches. These bundles go by various names, and Oracle Corporation is always changing the names to seemingly minimize the negative connotation as the number of patches in a software release gets distressingly large. For that reason, the mega-patches of Release 10.7 and 11.03 are either called minipacks, or something like Release 11i's Family Pack E. The same amount of instability is still introduced into your system by applying a Family Pack as a mega-patch, but Oracle likes the friendlier sounding name in 11i. The largest bundle of patches is called a Maintenance Pack, and version 11.5.4, released in June 2001, is an example of a Maintenance Pack.
NOTE
Maintenance Packs can perform significant changes to your system well beyond basic maintenance. Oracle often includes new features and functionality in 11i Maintenance Packs. You must consider performing significant testing when you apply a Maintenance Pack to your system.
You must test the results of a patch or upgrade. The law of unintended consequences says that you might cause a new problem when you apply a patch to fix an old problem. The most sophisticated and heavily customized Oracle customers create a suite of scripts of repeatable transactions and reports that can be run against a stable test database before and after the patch or upgrade. If the scripts don't produce identical results before and after the change, there is a business impact, and these customers are able to analyze the change.
The average Oracle customer analyzes the patch to see what might be affected, applies the patch in a test database, and asks the user to verify that results are acceptable. This approach has more risk than a full regression test suite. You must understand the impact of an incorrect patch on your production systems. What is your worst case scenario, and what are your recovery options?