Re: Identify CPU/PSU patch

From: Sanjay Mishra <smishra_97_at_yahoo.com>
Date: Mon, 5 Sep 2011 08:42:51 -0700 (PDT)
Message-ID: <1315237371.37211.YahooMailNeo_at_web161214.mail.bf1.yahoo.com>

Thanks Niall. That is good explanation and very good point.

---

From: Niall Litchfield <niall.litchfield_at_gmail.com> To: frits.hoogland_at_gmail.com
Cc: "oratune_at_yahoo.com" <oratune_at_yahoo.com>; "pete_at_petefinnigan.com" <pete_at_petefinnigan.com>; "smishra_97_at_yahoo.com" <smishra_97_at_yahoo.com>; "oracle-l_at_freelists.org" <oracle-l_at_freelists.org> Sent: Friday, September 2, 2011 4:03 AM
Subject: Re: Identify CPU/PSU patch

There are 2 different things going on here. When Oracle releases a PSU/CPU patch (or a patch Bundle on Windows) then it provides fixes for 2 different sets of code. One set is the installed binary software - I believe this is what Sanjay is referring to - and as Fritz says  below the utility for manually determining this is OPatch. In addition I'd sort of hope that most large organisations that are savvy enough to actually apply security patches would have a configuration management system that got updated as patches are applied. In addition to the manual check for what security patches *are* applied, Grid Control provides an automated method to determine which security patches *have not* been applied to the software homes (as well as a method for applying those patches). The manual method needs to be collated to give an  enterprise wide view, the Grid Control or configuration management approach doesn't. 

Secondary to this however, Oracle also releases fixes for code contained *in* the database. It is these fixes that get recorded in the DBA_REGISTRY_XXX views, prior to 11.2.0.2 by catbundle.sql, post 11.2.0.2 the information is also recorded on database creation - I believe the call to catbundle got added to one of the create scripts in this release. Whether you need to patch database created *after* a PSU/CPU is applied to the binaries depends upon how you create the database.  If you use as your source a DBCA template containing database files (either a sample database or one of your own) that was created before the patch was applied then you will need to apply the post upgrade scripts again (and DBA_REGISTRY_XXXX will be correct). Similarly if you clone from another unpatched database (which is essentially what dbca does for you) then you will need to patch. If, however, you run old-fashioned database creation scripts (which are rather slow these  days) then the code created by running these scripts will already contain the bugfixes and so the post install scripts won't *need* to be run (but DBA_REGISTRY_XXXX may now be misleading). For relatively recent versions (say > 10.2.0.3 or so) then I *believe* there is no harm in rerunning catcpu/catpsu (but obviously I haven't run this against every database no matter what it's history on every platform) and getting a correct registry history as a side effect. 

In summary: 

• for an audit of the binaries use OPatch.
• for a vulnerability scan use Grid Control or some other Configuration Management tool
• for an audit of databases use dba_registry_history but
• user created databases may give incorrect information 

On Thu, Sep 1, 2011 at 7:47 PM, Frits Hoogland <frits.hoogland_at_gmail.com> wrote:

Please mind database views like DBA_REGISTRY_HISTORY are not filled
>when databases are created after the CPU/psu patches are applied to
>the oracle home, AFAIK. Or when the database part of the patch is
>forgotten.
>
>So, the most reliable way is to use the opatch information.
>
>I encountered above situation when auditing exadata db's (fairly new
>db's), and I assume psu/CPU patches work the same way.
>
>Frits Hoogland
>Principal Consultant
>
>VX Company IT Services B.V.
>T +31 6 5356 9942
>F +31 35 539 0908
>E fhoogland_at_vxcompany.com
>I http://www.vxcompany.com
>
>(Sent from my iPhone, typo's are expected)
>
>
>Op 1 sep. 2011 om 20:17 heeft David Fitzjarrell <oratune_at_yahoo.com>
>het volgende geschreven:
>
>
>> Thanks, Pete, I was searching for my script that populated a reporting table with that information and found another using registry$history.  Looking further into the mountain of scripts I have I finally found it, and you are correct.
>>
>> David Fitzjarrell
>>
>>
>> From: Pete Finnigan <pete_at_petefinnigan.com>
>
>> To: smishra_97_at_yahoo.com
>
>> Cc: David Fitzjarrell <oratune_at_yahoo.com>; "oracle-l_at_freelists.org" <oracle-l_at_freelists.org>
>> Sent: Thursday, September 1, 2011 11:09 AM
>
>> Subject: Re: Identify CPU/PSU patch
>>
>> Both,
>>
>> DBA_REGISTRY_HISTORY is the proper interface..:-)
>>
>> cheers
>>
>> Pete
>>
>> Sanjay Mishra wrote:
>>> Thanks David
>>>
>>>
>>>
>>> ________________________________
>>> From: David Fitzjarrell <oratune_at_yahoo.com>
>>> To: "smishra_97_at_yahoo.com" <smishra_97_at_yahoo.com>; "oracle-l_at_freelists.org" <oracle-l_at_freelists.org>
>>> Sent: Wednesday, August 31, 2011 12:48 PM
>>> Subject: Re: Identify CPU/PSU patch
>>>
>>>
>>> Query REGISTRY$HISTORY for CPU/PSU information for an instance.
>>>
>>>
>>> David Fitzjarrell
>>>
>>>
>>> From: Sanjay Mishra <smishra_97_at_yahoo.com>
>>> To: "oracle-l_at_freelists.org" <oracle-l_at_freelists.org>
>>> Sent: Wednesday, August 31, 2011 9:09 AM
>>> Subject: Identify CPU/PSU patch
>>>
>>>
>>> Hi
>>>
>>>
>>> Does anyone know what is best way to identify as what CPU/PSU patch is applied to the existing Oracle Software. We have 100's of database servers and some new are added on regular basis. In order to make sure that new database got the CPU or PSU Patch applied and so what is best way to get this details.
>>>
>>>
>>> One way is to get this from Opatch and then take the latest patch number and search with metalink to get idea if this is part of which CPU.PSU patch. This is surely cumbersome or not efficient approach. Also cannot use existing database with existing software as it might be missed to apply the patch in the database.
>>>
>>> TIA
>>> Sanjay
>>
>> --
>>
>> Pete Finnigan
>> CEO and Founder
>> PeteFinnigan.com Limited
>>
>> Specialists in database security.
>>
>> Makers of PFCLScan the database security auditing tool.
>> Makers of PFCLObfuscate the tool to protect IPR in your PL/SQL
>>
>> If you need help to audit or secure an Oracle database, please ask for
>> details of our training courses and consulting services
>>
>> Phone: +44 (0)1904 791188
>> Fax  : +44 (0)1904 791188
>> Mob  : +44 (0)7759 277220
>> email: pete_at_petefinnigan.com
>> site : http://www.petefinnigan.com
>>
>> Registered Office: 9 Beech Grove, Acomb, York, YO26 5LD, United Kingdom
>> Company No      : 4664901
>> VAT No.          : 940668114
>>
>> Please note that this email communication is intended only for the
>> addressee and may contain confidential or privileged information. The
>> contents of this email may be circulated internally within your
>> organisation only and may not be communicated to third parties without
>> the prior written permission of PeteFinnigan.com Limited.  This email is
>> not intended nor should it be taken to create any legal relations,
>> contractual or otherwise.
>> --
>> http://www.freelists.org/webpage/oracle-l
>>
>>
>--
>http://www.freelists.org/webpage/oracle-l
>
>
>

-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info
--
http://www.freelists.org/webpage/oracle-l

Received on Mon Sep 05 2011 - 10:42:51 CDT