Version, Release, Patch, Patchset and Patch Number

[wbarrence]

Friends,

Would anyone know how to explain me easily and clearly what the difference between the items listed below?
Version
Release
Patch
Patchset
Patch Number
Patchset Updates (PSUS)
Critical Patch Updates (CPUs)
Bundle Patches
Interim Patches

It is interesting that ongoing no teaching these practices.

Thanks for help.

-
WABS

[stcoutinho]

WARRAVANCE,

In the My Oracle Support manual (Metalink's successor), you can find a detailed description of these topics:
http://docs.oracle.com/cd/E25290_01/doc ... pdates.htm

Maybe some capers here that usual work with Oracle EBS and other products can give you a personalized explanation of these points.

Hugs,

Sergio Coutinho

[wbarrence]

Speak Sergio Coutinho,

First I want to thank for help.

In the case of this question, it does not need such a formal explanation, can be explained according to your experience.

I need to know how I use these patches on the day-to-day work?
Which regularity does this patch be applied?
In what periods Oracle makes them available?
What types of patches are essential to be applied?

Att,

[adrianoturbo]

Brothers, I'm going to pass an overview about all this, it follows:

11.2.0.4.0
Main version number _____ | | | | __Platform specification of the launch number
| | | _ Specific component of the version number (patchset)
Maintenance launch version number__ | |
| _______ Version number of the application server

Main version number
The first type is the main identifier of the version.

Maintenance release version Number
The second type represents the release level, for example 11gr1 and 11gr2, that is, from level 1 ( 11g) To level 2 (11gr2)


Application server version number
The third type refers to the level number For Oracle application servers.

Specific component of the release version number (PatchSet)
The fourth type identify the level number of the specific component for a component, usually Number refers to the last applied pacthset, but other components can take that position.

Specifies Launch Number Platform
The fifth and last digit identifies the Especia platform, usually this field would represent the patchset number.

From 2005, Critical Patch Updates (CPU)) were created. Soon after the update packet sets (Patch Set Updates (PSU)) were created, where The packages were cumulative were included with security corrections.
In 2012 Oracle decided to change and add different types of patches.
The terminologies that I will describe below can be used in the following products: Oracle Database, Enterprise Manager, Fusion Middleware and WebLogic.
Come on then:
-Critical Patch Update (CPU) -Category Critical Updates refers to the overall launch of security corrections released quarterly cumulately;

-Patch Set Updates (PSU) - Here is the famous set patch that are actually packages of cumulative updates that include both security corrections and priority corrections, example of PatchSets: 11.2.0.2.0.11.2.0.3.0 and 11.2.0.4.0.
It is always good to remember that patchset does not roll downgrade, once applied it was already.

-Security Patch Update (SPU) -We already have the Critical Patch Update (CPU) and the Patch Set Updates (PSU) with security correction option Oracle has solved last year introduce a specific patch for security that is Security Patch Update (SPU).
For databases, Security Patch Update (SPU) may be applied as long as an upgrade from version X to a new version has occurred.
This type of patch is cumulative and is available quarterly by Oracle in Metalink.

-bundle patches : They are packages available quarterly specifically for Windows and Exadata with security fixes and recommended fixes.

-Interim (one-off) patches -is a single and non-cumulative PACTH to solve a specific bug, example if he has installed the 11GR2 torque in the version 11.2.0.1.0 then have applied the patchset 11.2.0.4.0, let's imagine that after all this appears a bug that the patchset has no notion of the existence of it, then it will be necessary to report to Oracle and it will analyze and create an interim (one-off) to solve the specific bug.
For knowledge The current 11G forward patchesets are complete installations, type DBA has no more need to install for example 11.2.0.1.0 and then apply PatchSet 11.2.0.4.0, I say this in an installation Starting from zero, obviously that in upgrade cases with the train running in production it will be necessary to apply from a XYZ version going to XYZW.
Good is, I hope I have helped.

[adrianoturbo]

[IMG http://www.casimages.com.br/i/131216074 ... 2.jpg.html[/img]

[adrianoturbo]

11.2.0.4.0

11 = Main version number
2 = Maintenance release version number
0-Version number of the application server
4-Specific component of the version number (patchset)
0-Specific platform of the release number

[wbarrence]

Adriano,

Thank you very much for your "Overview", well complete and took many doubts.

Let's go to another question, all these types of patch you mentioned, what is the one that is essential to be applied in production (with the train walking)?

Att,

[adrianoturbo]

The answer is depends:
patch application, when is it really necessary? A very controversial subject.
Patches are updates to fix bank failures, suddenly these faults do not apply the reality of your application. Will you need to apply, just by applying?
Do not think patches are bullets of silver, some companies require that the bank is in the last release, it all depends on their needs. Even because the patch when it is released is an unknown we never know if it will work.
I say this by Oracle to be a multiplatform database and the chance to give error is very big, so the common sense and chicken canja are necessary.
Some results that a patch application can generate: solves the problem, it does not solve anything and can screw the bank.Derepent you apply patches for situations that do not even need to apply the same.
Situations that would apply a patchset when the version life cycle is ending and consequently Oracle will no longer support the version, in cases of bugs and security gaps that actually compromise and when the application developer says that This version is not more supported by the application.Nessa history enters the issue of evolution of the system among other things.
Only one crazy leaves applying Patchset directly into production just because she finds beautiful and cool is in the last release.
Before putting the train running in production, the prudence of all methodical DBA says:
- DBA Read the Readme of the Cape Patchset documentation to tail How often are required,
-DBA mount a test and test environment before, be suspicious not believing in everything on what they say or write, before testing and confirming for your account and risk that really in practice it is possible to catch the match and light a fire.
- DBA is not content only with a test environment, but also a homologation environment to make sure that everything that worked on the test environment will also work in the approval, test all possible processes,
If everything happens the thousand and a wonders in the two environments there yes, put the train to rotate in production.
As I said earlier, patchset application has no back (downgrade), once applied: or you solve your problems, it does not solve anything or simply ends your bank and has to do everything from scratch.
Let's imagine that you have a stable environment in the current Abcde version, do you think you would need to change version? Having in view that would have to change the entire application? So I said the answer is depends.

[wbarrence]

Speak Adriano !!!

Face First I want to thank you once again.

I found your point of view perfect in the issue of updating the production database, that's what you said, so we can say that in the team that is winning does not move, or we only move In team that is earning if a bruise problem (bug) ... kkk.

It is then concluded that the Oracle patch's update is only feasible, in case of bug or when you are configuring a new zero database.

[adrianoturbo]

Hello WARRERENCE, we experience the profession danger in the skin every day and the biggest assets of a company are your data, then all care is little.
We are here to help.
Hugs.
Thanks for the words.