ecs_policy_v26

8/7/2019 ecs_policy_v26

1/25

Oracle Corporation

Server Technology Products

Software Error Correction Support

Version 2.6

Revised: 27 October 2009

Status: Published

Applies to:

Collaboration Suite

DatabaseEnterprise Manager Grid Control and DB ControlFusion Middleware (including products acquired fromBEA)

Error Correction Policy Oracle Corporation 28-Oct-09 Page 1


2/25

Table of Contents

1 About This Document 3

1.1 Scope Of This Document 3

1.2 Whats New 3

1.3 Summary 4

1.4 Products And Options This Policy Applies To 4

2 Terminology 6

3 Patch Sets 8

3.1 Definition 8

3.2 Policies 8

4 Quarterly Patch Updates 10

4.1 Definitions 10

4.2 Policies Critical Patch Updates 13

4.3 Policies Patch Set Updates 13

5 Interim Patches 15

5.1 Definition 15

5.2 Policies 15

6 Diagnostic Patches 19

6.1 Definition 19

6.2 Policies 19Appendix A -- Product Specific Details 20

A.1 Database 20

A.2 Fusion Middleware 20

A.3 BEA Products 21

A.4 Oracle Enterprise Manager Grid Control and DB Control 22

A.5 All other products 23

Appendix B -- Patch Request Process Flow 24

Appendix C Document Control 25



3/25

1 About This Document

1.1 Scope OfThis Document

Oracle provides bug fixes for its Server Technology products as part of

Premier and Extended Support (but not Sustaining Support). This

document explains the methods that are used to deliver bug fixes and

some of the rules regarding those methods.

Relationship to Lifetime Support Policy: The Lifetime Support

Policy describes for all Oracle products the duration of support formajor releases and what support is delivered in each phase of a

products life. This Error Correction Policy document describes, for theproducts listed on the title page, details about how we deliver error

corrections. This includes policies on how long we will create new

fixes for older forms of patch delivery such as patch sets and patchbundles.

1.2 Whats New Version 2.6 adds BEA products to this policy. See Appendix A3 fordetails.

Version 2.5 includes policy regarding Patch Set Updates. Our direction

is to begin consolidating various bundle patches into single quarterly

bundle patches. With the first product to release a Patch Set Update(Oracle Database) we present the policies for them in this document.

Version 2.4 includes an important change to the grace period policy: the

grace period does NOT automatically end when Extended Support

begins. This means that the previous patch set will continue to bemaintained for one year after the first release of the new patch set. Formore details see Appendix A. We also introduce the concept ofsupported for error correction with respect to patch sets for which we

will create new fixes (vs supported patch sets which we will no longerpatch). See Section 3.1 for a more detailed discussion

Version 2.3 introduces no policy changes all changes attempt to

clarify the grace period policy. There is now a link in Appendix A to a

Metalink note, which contains the schedule and grace period dates for

all current Database patch sets.

In version 2.2 Enterprise Manager Grid Control is now included andconforms to the 12 month grace period. See specifics in Appendix A.

In version 2.1 of this document, the 12-month grace period for Fusion

Middleware is detailed.

Highlights of what is new in version 2.0 of this document:

http://www.oracle.com/support/library/brochure/lifetime-support-technology.pdfhttp://www.oracle.com/support/library/brochure/lifetime-support-technology.pdfhttp://www.oracle.com/support/library/brochure/lifetime-support-technology.pdfhttp://www.oracle.com/support/library/brochure/lifetime-support-technology.pdf


4/25

Oracle announces a new longer (up to 12 months, minimum 3months) grace period to install a new Database patch set. Also,

this grace period is now the same with respect to generating both

interim patches and Critical Patch Updates. See section 3.2.1.

Windows patch bundles for Database are now explained. Expanded details around Critical Patch Updates

1.3 Summary The main way in which Oracle provides bug fixes to customers inbetween releases of our products is by means of the patch set (where we

bundle a number of fixes, test them thoroughly together, and package

for easy download and installation). In between patch sets bug fixes aredelivered in one of three forms:

1. A quarterly Critical Patch Update (security fixes),

2. A patch bundle, or3. An interim patch for non-Windows platforms (sometimes called

a one-off).

In general, these three forms are created only on the most current patch

set, and during Premier Support for some period of time (the grace

period) on the previous patch set. Once a product release enters theExtended Support phase, fixes are only created on the last patch set.

Interim patches are only created for severe problems with no

workaround. A request for one must meet certain criteria for customer

business and operational impact before being accepted, and the fix must

be technically feasible for Oracle to create in a way that will not belikely to cause further bugs.

If you need a bug fix that is already in a patch set, we will ask you to

apply the patch set rather than create a separate interim patch or patchbundle.

1.4 ProductsAnd Options ThisPolicy Applies To

This document applies to all products and options in the product bundles

listed below. Not all products and options are included in Databasepatch sets. Please check the README in each patch set to determine

which products and options are included, as these change periodically.

Product bundles covered: Oracle Database

Oracle Fusion Middleware (including BEA products)

Oracle Collaboration Suite

Oracle Enterprise Manager Grid Control and DB Control

top



5/25



6/25

2 Terminology

Bundle patch A collection of patches that is issued between patch sets. A patch bundle

is usually cumulative. Windows bug fixes for the Database are generally

issued in a patch bundle (as opposed to an interim patch). Fusion

Middleware also produces patch bundles for some components.

Conflicting patch Conflicting patches are two or more patches that have some files in

common, but contain independent fixes.

Critical Patch

Update (CPU)

A collection of high-priority fixes (usually for security issues) once a

quarter. CPUs are cumulative with respect to prior security fixes butmay contain other fixes in order to address patch conflicts with non-

security patches (i.e. reduce the need for merge requests).

Cumulative patch A patch that includes all fixes for any included source module since the

previous baseline (initial release or previous patch set or bundle).

Diagnostic patch A patch created specifically to diagnose a problem and not to fix a bug.

Grace period The period of time following the release of a patch set where we create

new fixes for both the new and previous patch set, allowing customers

time to plan for and install the new patch set. Grace periods vary byproduct please see Appendix A for details by product.

Interim patchA single patch created to provide a specific fix between the release ofpatch sets.

Merged patch For products and platforms where Oracle delivers non-cumulativeinterim patches, a merged patch is one where multiple conflicting

patches are combined into one integrated patch.

Non-cumulative

patch

A patch that includes a subset (usually only one) of all fixes made to thesource modules that had to be modified to fix that bug (as opposed to acumulative patch).

One-off patch SeeInterim Patch.

Patch set An integrated, cumulative, fully tested collection of fixes issued in

between product releases (usually once or twice a year).

Patch Set Exception

(PSE)

A formal request for the creation of a patch in between patch sets, made

by Oracle Support on behalf of a customer.

Patch Set Update A quarterly patch that contains the most critical fixes for the applicable

product (including security fixes), allowing customers to apply one patch

to avoid many problems.



7/25

Regression A new bug introduced as part of a patch, patch bundle, or patch set (real

regression) or an existing bug that was revealed in the process of fixing

another bug (apparent regression).

Request for

inclusion (RFI)

A formal request to include a bug fix in the next patch set (rather than

receiving it as an interim patch), made by Oracle Support on behalf of acustomer.

top



8/25

3 Patch Sets

3.1 Definition Periodically during the Premier Support phase of a productreleases life, Oracle gathers all the bug fixes made to that

release, tests them thoroughly together, and packages them to

be installed using the Oracle Universal Installer (OUI). Thisform is called apatch set.

Patch sets are the safest and most reliable way for you to get

bug fixes for a supported release, and are the cornerstone of

preventive maintenance strategy. By proactively applyingpatch sets as they are released, you can avoid encountering

many bugs that might otherwise affect the smooth operation of

your systems, and avoid having to install a patch set at aninconvenient time if you do encounter a bug. Also, because a

patch set gathers together all previously made bug fixes for a

release, a patch set provides a stable, well-known base onwhich to apply new interim patches, patch bundles, or Critical

Patch Updates.

Patch sets are identified by a change in the 4th digit of the

version number. They are not stand-alone releases and must be

applied on top of an existing product installation. Becausethey are cumulative, it is possible to skip a patch set and still

get all the fixes once the customer installs the latest.

3.2 Policies 3.2.1 Which Patch Sets Will Oracle Create New FixesOn?

While all patch sets of a supported product release are

supported(i.e. we will investigate bugs and provide assistance,and are still certified with the same Oracle products and

versions), not all are supported for error correction. While

we will investigate a potential bug in all supported patch sets,

new bug fixes (including patch bundles and Critical PatchUpdates) are created for the:

Current patch set, and

Previous patch set, for the duration of the Grace

Period.

The grace period is intended to provide customers adequate

time to plan the installation of a new patch set. During this

time Oracle will continue to create new fixes for the previouspatch set.

Figure 1 below is an illustration of the grace period for a



9/25

Database patch set, showing the release dates and overlap of

maintenance for the previous patch set.

Please see Appendix A for details about the grace period foreach specific product. Also, see section Criteria For

Considering Interim Patch Requests for other information

about requesting an interim patch.

22-Feb-08 - 22-Feb-09

Grace Period to Install 10.2.0.4

29-Nov-06 - 22-Feb-09

Patching for 10.2.0.3

29-Nov-06

10.2.0.3 Released

22-Feb-09

Grace Period toInstall 10.2.0.4 Ends

22-Feb-08

10.2.0.4 Released

Figure 1 - Example of Database grace period

3.2.2 Patch Sets Only For Supported Releases

Patch sets are only created for releases in the Premier Support

period. Patch sets are not created for releases which haveentered Extended Support.

3.2.3 Regressions Due To Patch SetsOracles goal is to produce patch sets of the highest quality,

because we know that customers need them to be trouble-free

if they are to be a successful part of a preventive maintenanceprogram. Because of this, if a patch setdoes introduce a new

bug, Oracle will give extra priority to any P1 or P2 regression

until fixed but you must identify the issue as a regression and

request the higher priority. If necessary, Oracle may create aninterim patch to correct the problem.

3.2.4 Not All Patch Sets Ported

Oracle may not port every patch set to every platform. Oraclewill always port the last patch set for a release to all platforms

that the release was originally ported to.

top



10/25

4 Quarterly Patch Updates

4.1 Definitions Oracles direction is to streamline patching by providing customerswith quarterly tested bundles of critical. This allows you to plan for

and install the fewest number of patches with the highest expectation of

success. At this time Oracle Server Technology has two principalquarter updates: the Critical Patch Update (CPU), and the Patch Set

Update (PSU).

Critical Patch UpdatesA Critical Patch Update (CPU) is a collection of high priority securityfixes issued quarterly on the Tuesday closest to the 15 th of the month.

CPUs are built on top of specific patch sets for all supported versions of

applicable Oracle products. For example, for a given platform a CPUmight be issued for Database 9.2.0.8 (in the Extended Support period),

10.1.0.5, 10.2.0.3 etc. No matter what patch set level the customer is

running at, installing the CPU brings all to the same level of securitybug fixes. The number of bug fixes is relatively small (an order of

magnitude less) compared to patch sets.

TestingCPUs are tested extensively including install and functional regressiontests, and in some cases are tested with application stacks (such as

Oracle E-Business Suite, Audit Vault, or Secure Enterprise Search).

Oracle recommends as a best practice that customers install each CPUon a test system that mirrors their production systems environment

before installing in a production system.

ScopeCPUs contain new security fixes, plus all fixes from previous CPUs

issued on any given patch set (including any fixes introduced to resolve

customer-reported conflicts with previously installed patches, iemerges). Thus each new CPU on a particular patch set is cumulative.

For example, the second CPU issued against DB 10.1.0.5 will contain

all the fixes from the first CPU for 10.1.0.5 plus the new fixes merged

into the first CPU Merge Patch.

Starting with Database patch set 10.2.0.3, CPUs have security fixes and

any pre-requisite non-security fixes, but no longer contain non-security

fixes introduced to resolve patch conflicts.

Even though Oracle intends to include mainly security fixes in CPUs,we may decide to include high-priority non-security fixes. We will

always identify them in the CPU documentation.

Patch Set UpdatesPatch Set Updates are proactive cumulative patches comprised of

recommended bug fixes that are released on the same quarterlyschedule as the Critical Patch Updates. Patch Set Updates may replace



11/25

several other bundle patches and will establish a new baseline version

number, thus eliminating the need to install and track several bundles or

lists of recommended patches. For simplicity's sake all the CriticalPatch Update fixes are included in the Patch Set Update so customers

can choose to install either the Patch Set Update or just the Critical

Patch Update.

Like the Critical Patch Update, Patch Set Updates apply to specific

Patch Sets. Unlike Patch Sets, interim (one-off) patches can berequested for any Patch Set Update, as long as the Patch Set it applies

to is still supported for error correction.

Every Patch Set Update is a new version of the software, changing the5th place of the version number (e.g. 10.2.0.4.1). It also represents a

new baseline of the code, so an interim patch may need to be built

specifally for the PSU you have installed in order to be applied. Thereare two important implications of this:

1. Patches installed prior to applying the PSU may conflict and be

rolled back (e.g. uninstalled). Any patch rolled back due to the

application of a PSU must be re-built for the PSU before youcan reinstall that fix. See Obtaining replacements when a

patch is rolled back after applying a PSU below.

2. Patches for an earlier version level for your current patch set

baseline may be installed regardless of which PSU you haveinstalled as long as they do not conflict. If there is a conflict

you must obtain that fix built for the PSU you have installed.

For example, if your installed patch set is 10.2.0.4 and you

have 10.2.0.4.2 installed, patches built for 10.2.0.4.0 or10.2.0.4.1 may be safely installed as long as no conflicts with

the PSU are reported when attempting to install. Of course, if

the patch has a conflict with a patch other than the PSU, youshould request a merged patch.

TestingPatch Set Updates are generally tested they same way as Critical Patch

Updates: regression, system and performance testing are done to ensurecustomers have the most successful experience using them.

Scope

PSUs contain strictly limited content usually 50 to 100 fixes.Included are:

Fixes for critical technical issues such as wrong results,corruptions, and hangs.

Fixes that have been encountered by a large number ofcustomers.

Fixes that have already been proven in the field.



12/25


13/25

4.2 Policies Critical PatchUpdates

4.2.1 Which Patch Set Versions Will Cpus Be Created For

CPUs follow the same rules for a patch set that other patches do: theyare created for the current patch set and the previous patch set (if any)

for the duration of the grace period (see section 3.2.1 above). For

example, if 10.2.0.4 were the current Database patch set, a CPU would

be created on 10.2.0.4, and on 10.2.0.3 as long as it is within the grace

period to install 10.2.0.4.

Only customers who have contracted for Extended Support are entitled

to download and use CPUs created for a product that is in Extended

Support.

4.2.2 Patch Conflict Resolution For CPUs

It is possible that you may encounter a conflict between the new CPU

and patch that you had installed prior to the CPU. To resolve theconflict, a request for a merge of the CPU with the earlier patch must be

made.

4.3 Policies Patch SetUpdates

4.3.1 Which Patch Set Versions Will A PSU Be Created For?

Patch Set Updates are created for products and patch set versions that in

Oracles judgement are adopted widely enough to benefit from this

approach to delivering an integrated set of fixes. See Appendix A foreach product for more specific information.

4.3.2 Which Patch Set Updates Will New Interim Patches Be

Created For?Interim patches can be created for any PSU as long as the patch set it is

based on is supported for patching. In other words, there is norequirement to install the latest PSU in order to get a new patch built.

4.3.3 Obtaining a PSU overlay (replacement) when a patch isrolled back after applying a PSU

It is very important to check for conflicts as part of the planning

process when applying a PSU so you know what patches will be rolledback and can request that patch to overlay the PSU. You must request

that the fix be built for the PSU you are planning on applying. Unlike a

typical request for a new interim patch, no special approval is requiredto get a replacement patch built. Note that unless the fix is included in

a future PSU, every new PSU will again conflict with, so you should

plan on requesting a new patch for any PSU you plan on installing.

4.3.4 Requested Patches Not Included In Future PSUs

In order to keep them small and focused, new fixes delivered tocustomers on top of a PSU are NOT typically rolled into the new PSU



14/25

built on the same patch set. For example, a new fix for 10.2.0.4.1 willnot be included in 10.2.0.4.2 it would generally be included in the

next patch set instead. This means that if you have requested an interim

patch built on a PSU you may have to request a new patch for that fixwhen installing a later PSU if the interim patch conflicts.

top



15/25

5 Interim Patches

5.1 Definition AnInterim Patch (also known as a "one-off patch") is a bug fix (or setof fixes) made available to customers who cannot wait until the next

patch set or new product release to get a fix. Interim patches will not be

used to backport features to older releases or implement new features.Interim patches are specific to a particular product version (base release

or patch set). For example, an interim patch created for 10.2.0.3 shouldNOT be installed on 10.2.0.2 or 10.2.0.4. All interim patches are

included in a future (usually next) patch set as well as the next product

release.

TestingAn interim patch is tested by itself but no system regression testing is

done until it is included in the next patch set. Because of this, it is

highly recommended that all customers needing bug fixes wait for apatch set or product release that includes the fix.

Scope Of An Interim PatchBy default, an interim patch does not include any other bug fixes made

since the previous patch set. Because of this, auser installing multipleinterim patches compounds the risk to system stability with each

additional interim patch installed. For long-term reliability customers

should install the next patch set that includes an interim patch as soon

as it becomes available.

5.2 Policies 5.2.1 Criteria For Considering Interim Patch Requests

Any request for a new interim patch should be accompanied by a case

showing that the customer business and operational impact is severe tobe considered. Also, Oracle must believe that it is technically feasible

to create a patch that does not jeopardize the stability of your system.

Below are some of the criteria which should be discussed in the impactcase that must accompany a request:

Customer business impact

Severe system unavailability

Inability to do normal business

Significant risk to development or deployment schedule

Patch required to replace a patch rolled back by a PSU

Operational/technical impact

Permanent data corruption (physical or logical)

System hangs or crashes repeatedly

Failure of critical functionality

Severe performance regression

Bug fix is not implemented in a later patch set for the releaseyou are running, or applying the patch set not feasible due to a



16/25

strong business or technical reason

No workaround available or inability to use workaroundbecause of a strong business / technical reason

Technical Feasibility: if a fix requires too many lines of code tobe changed, Oracle may determine that the bug fix cannot be

safely implemented as an interim patchIf the impact case for the request is strong, Oracle Support will log a

Patch Set Exception (PSE) request on your behalf, which will result in

the patch being created and put on Metalink for you to download. If the

impact of a bug is high but does notmeet the above criteria, OracleSupport will log a Request For Inclusion (RFI) so that the fix can be

included in the next patch set.

5.2.2 Which Patch Sets Are Eligible For Interim Patches?

Oracle will create new interim patches against the currently available

patch set, and for the previous patch set for the duration of the grace

period(see section 3.2.1 above). Oracle considers it a best practiceleading to greater system stability to create new fixes on the latest patch

set. Because of this, even if a previous patch set is still being patched,Oracle Support will always suggest you install the latest patch set.

However, we would only require it if a fix is not technically feasible to

implement in the earlier patch set.

NOTE: You ARE NOT REQUIRE to install any patch set as a

prerequisite for Oracle to investigate a potential bug. Only after

a. diagnosis has determined that a new bug fix must be created,

orb. the bug is fixed in an existing patch set and that it is not

feasible to fix it on the patch set you are now running,

would you be required to install the current patch set. Any new fix

will only be created for a maintained patch set (see3.2.1 above).

5.2.2.1 Some Patches Implemented As Bundle Patches

Oracle releases patches on some platforms and products as

cumulative compiled binaries, so no interim patches are

produced in those cases. Please see Appendix A for specifics.

5.2.3 Resolving Patch Conflicts

Patches for some Oracle products, including most components of theOracle Database are not cumulative on most platforms, especially

UNIX or Linux. The fix in each interim patch does not typically include

other fixes made since the last patch set or bundle. Because of thisinstalling a new interim patch could cancel out a previously installed

interim patch. If you are requesting a patch on a product and platform



17/25

that uses non-cumulative patches and have already installed one ormore interim patches, you must give Oracle Support a complete list of

all interim patches installed in your ORACLE_HOME. This allows

Oracle to create - if necessary - aMerged Patch that includes the fixesfrom the new patch and the previously installed patches. Customers

running Oracle Database release 9.2 or later can use the opatch utility toget the list of patches installed.

If a patch conflicts with a Patch Set Update that you are installing, youwould not request a merged patch instead request the conflicting

patch be built as an overlay to the Patch Set Update.

5.2.4 Regressions Due To Interim Patch

If an interim patch introduces a new bug when installed on a customersystem, Oracle will work the problem at the level of priority assigned to

the original bug. If necessary, Oracle may create a new interim patch to

correct the problem.

5.2.5 Interim Fixes Included In Future Patch Sets And Releases

Interim patches are automatically included in the next patch set and thenext release of the product. In cases where the interim patch is created

too late in the development cycle of the current patch set, it will be

rolled into the following patch set. Be sure to review the list of bug

fixes included in a new patch set to make certain that all the fixesfrom patches you currently have installed are included. If you find

that a patch you need is missing from the new patch set, contact

Support prior to installing so a new patch can be created for you on thenew patch set.

5.2.6 Customer Considerations

An interim patch is unit tested but not tested with other interimpatches, nor is the product regression tested as a whole with the

interim patch included. If possible you should install andperform basic testing on a test system before installing an

interim patch in a production system.

Please install the requested patch promptly. If you do not plan

to install it promptly, please ask for the fix to be included in the

next patch set or bundle instead of requesting a patch.

Please report back to Oracle Support on the success of the patch,

so that Support can update the bug. As a best practice, install a patch set with this fix as soon as it is

available on your platform.

5.2.7 Interim Patches Available Via Self Service

Once an interim patch has been provided to the requestor, at Oracles

discretion it is made available to other customers for download viaMetalink. IF YOU PLAN TO INSTALL MORE THAN ONE



18/25

INTERIM PATCH to one Oracle Home directory, it is very importantto contact Oracle Support before installing the patch. Oracle Support

will determine, based on the patches already installed, whether a

Merged Patch must be requested. Failure to do so may result in

reoccurrence of problems fixed by an earlier-installed interim

patch. See Section 5.2.3 for the reasons behind this.

5.2.8 High Priority Patches

Some products may designate some patches as High Priority or

Critical. High Priority patches are ones that all customers shouldapply due to the likelihood that the customer may experience the

problem fixed by the patch or the potential severity of the problem.

top



19/25


20/25

Appendix A -- Product Specific Details

A.1 Database

Grace Period: up to 1 year, minimum 3 months.

You have up to one year from the release of a patch set on the first platform (currently Linuxx86) to plan for and install the new patch set. During that year we will create new bug fixes for

the previous patch set. This grace period is effective with the release of 10.2.0.4.

For example, 10.2.0.4 was released first on Linux x86. The release date was 22 February 2008.

Until 22 February 2009 we will create new fixes for both 10.2.0.3 and 10.2.0.4. After that datenew fixes for 10.2.0.3 will cease on all platforms and we will only create new fixes for 10.2.0.4.

Grace period for current patch sets can be found on Metalink in Note 742060.1

Exceptions:

3 Month minimum grace period: Since the release of a patch set on different platformshappens over time, not all platforms will be supported for error correction for the full

year. Because of this, we will always support the previous patch set for error correctionfor at least 3 months. For example, if the initial release of patchset A.x.y.z is on January

1st on Linux x86 and the same patch set is released on Univac on November1, Oracle will

still provide new patches on Univac A.x.y.z-1 until the end of January of the next year.Outside of the specific exceptions listed below, CPUs will NOT be provided beyond the

initial 12-month grace period.

Bundle patches for Windows: Oracle releases patches for Windows via periodic patch

bundles instead of interim patches. Patch bundles are released periodically (at least

quarterly), and include the security fixes from that quarters Critical Patch Update.

CPU Patch Conflict Resolution for customers running:

10.2.0.3 or later, customers should request the merge from Support in the same way as

for any other interim patch. There is no deadline to submit merge requests, but if a

merge request for a CPU is submitted after a subsequent CPU has been released,any fixes to the conflicting module introduced in the new CPU will be included in

the merged patch delivered to the customer.

9.2 and 10.1, Oracle will collect all merge requests from individual customers and releasea CPU Merge Patch which will satisfy all customer merge requests, up to a cut-off

date following the issue of the CPU. The specific cut-off date for each CPU islisted in its Patch Availability document. Requests filed after the cut-off date will

be considered for the merge patch that will be created for the following CPU. Forexample, if a merge request is filed after the cut-off date for the July CPU, it will

be considered for inclusion in the merge patch for the October CPU.

A.2 Fusion Middleware


https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=742060.1https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=742060.1https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=742060.1


21/25

You have up to one year from the initial release of the patch set to install the new patch set, andcan receive new bug fixes for the previous patch set during that time. This grace period is

effective with the release of patch sets 10.1.2.3 and 10.1.3.4 (e.g.10.1.2.2 is supported for one

year from the initial release of 10.1.2.3, etc.).

Exceptions:

Minimum grace period and Extended Support same as Database in A.1 above

Bundle patches: In Fusion Middleware, new fixes might be delivered as cumulative

bundle patches, similar to the "Windows bundle patches" on the Database. Customers arehighly recommended (and in many cases required) to always move to the latest available

bundle patch. Some of the current Fusion Middleware products that utilize bundle patch

distribution are OAM (Oracle Access Manager), OIM (Oracle Identity Manager),Discoverer, and Integration related products.

A.3 BEA Products


As of November 1, 2010, this Software Error Correction policy governs maintenance of Fusion

Middleware products that were acquired from BEA. Patch bundles, CPUs (Critical Patch

Updates) and interim patches will be provided for the latest patch set. Patch sets are equivalent to

service packs or maintenance packs for BEA products.

You have up to one year from the initial release of a patch set to install the new patch set, and can

receive new bug fixes for the previous patch set during that time.

Notes:

Initial Grace Period: There is a grace period of one year from the announcement (i.e.

until November 1, 2010) of this change to upgrade to the latest patch set. During thistime, you can continue to receive bug fixes for previous patch sets. After the end of this

grace period, maintenance will only be available on the latest patch set, as described by

this policy.


Rolling Patches: Some of these products, such as Tuxedo and JRockit, have been

maintained by rolling patches, that is, comprehensive sets of all available fixes. These

products will continue to be maintained with rolling patches.

Oracle Products Relying On Specific Weblogic Server Versions: Some Oracleproducts have been coupled to WebLogic Server. That is, they have been released withcertification on specific releases of WebLogic Server, or with coordinated installation of

specific releases of WebLogic Server. If customers of these products require maintenance

for WebLogic Server, CPUs and interim patches will be provided for the latest patch setof WebLogic Server. If the coupled product is not available on the latest WebLogic

Server patch set, please contact Customer Support to discuss options.



22/25

A.4 Oracle Enterprise Manager Grid Control and DB Control


You have up to one year from the initial release of the patch set to install the new patch set, and

can receive new bug fixes for the previous patch set during that time. This grace period iseffective with the release of patch sets 10.2.0.4 (e.g.10.2.0.3 is supported for one year from the

initial release of 10.2.0.4, etc.).

Exceptions:


Windows: Windows patches for Oracle Enterprise Manager products are not delivered aspatch bundles but as interim patches, i.e. one off patches.

Critical Patch Updates: Grid Control Critical Patch Updates are only released if thereare specific security fixes required for Grid Control, i.e. there is not always a new CPU

for Grid Control each quarter. DB Control and AS control security fixes will be releasewith the database or application server Critical Patch Update bundle and not as part of a

separate Enterprise Manager Bundle.

Terminal Releases: In general Oracle will port the last Grid Control Agent and

Management Server patch set for a release to all platforms that the release was originallyported to. Where exceptions are made then this will be communicated via Metalink.

Oracle Built Management Plug-ins and Connectors: Patches for Oracle BuiltManagement Plug-ins and Connectors are provided in the next release of the plug-in orconnector and not through interim patches or patch bundles. There are three release cycles

each year, which are planned for the last day of April, August and December. There are

no Grace Periods for Plug-ins and Connectors

If a critical issue is found with a plug-in or a connector, the patch will be provided in a

new release out with the normal release cycle. The patch will also be included in the nextplanned release of the plug-in or connector. Note that off cycle fixes for plug-ins and

connectors will be cumulative. This is different from the one-off patching mechanism

where on request Oracle may provide only one specific fix between patchsets to minimize

changes in the code.

Criteria For Considering Enterprise Manager Interim Patch Requests

The criteria includes but not limited to:

OMS or Agent hangs, unable to start, hangs or crashes repeatedly

Failure of key functionality, (e.g. Blackout, Notifications, Jobs, SLA, etc)

Loss of functionality in the console user interface

Unable to run an automated mass-deployment action (e.g. Deployment Procedure, Agent

Patching)

Severe performance problems: (e.g. Console, OMS, Agent)



23/25

Permanent data corruption to the repository

Bug fix is not implemented in a later patch set for the release you are running

No workaround available or inability to use workaround because of a business / technical

reason

Technical Feasibility: if a fix requires too many lines of code to be changed, Oracle may

determine that the bug fix cannot be safely implemented as an interim patch

A.5 All other products

Grace Period: 6 weeks for patches from the release of each patch set or bundle on each different

platform. CPUs will be released on the previous patch set for one year.

The Grace Period to install new patch sets (and receive bug fixes on the previous patch set) is

different for interim patches and CPUs. Interim patches will be created for the previous patch set

for 6 weeks. CPUs will be created for the previous patch set for 12 months. The Grace Periodfor each platform starts with the release of the new patch set on that platform.

Exceptions: none



24/25

Appendix B -- Patch Request Process Flow

Customerrequests fix for

critical bug

Current patch setinstalled? Bug fixed incurrent PS?No

Customer

installs currentPS

Yes

No

Done

Willing to installcurrent PS?

Customerinstalls current

PSYes

No

No

Yes

Req meetsimpact criteria?

(sec 5.2.1)

Yes

Wait for nextpatch set

Oracle produces

Interim Patch

Interim Patchrolls into next

Patch Set

Log RFI forcustomer

No

Still in GracePeriod for prev

PS?

Figure 2 - Fix delivery flow chart for Database and AS

top



25/25

Appendix C Document Control

Date, Author Version Comments

23-Aug-02 Roger Knopf 1.0 Initial publication.

28-Feb-03 Roger Knopf 1.1 NT patch sets no grace period. Added table showing patch

characteristics by product and platform. Additional clarificationson Tools issues. Added a glossary. Reformatted some sections for

clarity.

6-Mar-03 Roger Knopf 1.2 Clarified no back ports of security patches to non-supported

releases or patch sets.

1-May-03 Roger Knopf 1.3 Reflect changes in overall product lifecycle policy. Added

security patch policy changes incl. Support of previous patch set.

Rewrote some parts for clarification.

19-Jan-05 Roger Knopf 1.4 Add definition of and separate section for Critical Patch Updates.

Remove all references to Oracle E-Business Suite (developing

their own policy document). Clarify language around patch set

support for security patches. Clarified policy for security patches

for EMS releases. Change all references of iAS to AS. General

editing.

19-Oct-07 Roger Knopf 2.0 Major revision. Incorporate new Grace Period policy, changed all

references about EMS to ES, clarified Windows patching, general

editing.

28-Nov-07 Roger Knopf 2.0c Removed Win patch bundles from grace period. Incorporated all

review comments. Will publish as 2.0.

28-Dec-07 2.0d Changed DB grace period to one year, moved product specific

information to Appendix A.

14-Mar-08 Roger Knopf 2.1 Adding 1 year grace period for FMW.

18-Jul-08 Roger Knopf 2.1b Removed Windows exception to the DB grace period because theyare now producing bundles on current+previous patch sets.

27-Aug-08 Roger Knopf 2.2 Adding Grid Control

30-Oct-08 Roger Knopf 2.3 Added clarifications in sections 3.2.1, 5.2.1 and 5.2.2 regarding

business case for requesting an interim patch.

12-Jan-09 Roger Knopf 2.3a Added link to Metalink note containing specific DB Grace Period

dates.

5-Feb-09 Roger Knopf 2.3b Added illustration and text to clarify the concept of Grace Period

27-Apr-09 Roger Knopf 2.3c Added description of how this document relates to the Lifetime

Support Policy. Rewrote Appendix A description ofgrace period

to add clarity (ie policy did not change)

2-Jun-2009 2.4 Changed DB grace period policy so Extended Support no longer

terminates a grace period; added distinction of supported for

error correction patch set.

22-Jul-2009 2.5 Add Patch Set Updates to policy

27-Oct-2009 2.6 Add BEA products, also added a table of contents

top

Documents

ecs_policy_v26