Oracle DBA – A lifelong learning experience

Posts Tagged ‘PSU’

Manage a PSU into a CDB having several PDBS

Posted by John Hallas on October 12, 2015

I thought it would be a good idea to show how to apply PSU into the CDB and PDB that came with 12c. I start off with a quick reminder about how 11g worked and then move into examples of 12c

11G reminder

get the latest version of opatch

check for conflicts

opatch prereq  CheckConflictAgainstOHWithDetail -ph ./

start the downtime

Stop all the databases in the home (one node at a atime for RAC)

apply the patch

opatch apply

start all databases in the home

load SQL into the databases

@catbundle.sql psu apply

end of downtime (but remember to do the standby)

Example of 12c PSU process

Update opatch to latest version

Download and apply patch 6880880 to the oracle home

Check for conflicts with one-offs

Run the prereq check for conflicts: Read the rest of this entry »

Advertisements

Posted in Oracle | Tagged: , , , , | Leave a Comment »

How to identify if a patch is available within a PSU

Posted by John Hallas on January 7, 2013

Within MoS there are a set of notes which list all the patches of each PSU and show in which PSU they came in (PSUs are cumulative). The READme.html file with each PSU does not contain this information

11.1.0.7 Patch Set Updates – List Of Fixes In Each PSU [ID 1337836.1]
11.2.0.1 Patch Set Updates – List Of Fixes In Each PSU [ID 1340010.1]
11.2.0.2 Patch Set Updates – List Of Fixes In Each PSU [ID 1340011.1]
11.2.0.3 Patch Set Updates – List Of Fixes In Each PSU [ID 1449750.1] 

However beware if you are looking for a patch that is called Merged or something similar as you have to search the MoS notes for the included patches, not the merged patch itself

 As an example Patch 12640090 is an ASM fix but it is not found in note 1337836.1

But if you look at patch 12640090 in MoS you find the information about the included patches

 (4) Bugs Fixed by This Patch

———————————

The following are the bugs fixed by this patch:

  9007102: KFNMCLIENTSREGISTER12 WHEN HUNG UFG RECOVERS AND REGS FREED GPN

  9029156: ADDITIONAL TRACING FOR ASMB AND ASMB CONNECTIONS

 From note 1337836.1 I can see that 9007102 was included in PSU 8 but 9029156 is not quite as clear but it suggests it is included in PSU 13

Patch Details

 Patch 9029156: ADDITIONAL TRACING FOR ASMB AND ASMB CONNECTIONS 

Last Updated 21-Oct-2012 21:42 (2+ months ago)
Product Oracle Database Family Release Oracle 11.1.0.7.13

Size 104.5 KB
Download Access Extended Support
Classification General
Patch Tag 

Prerequisite Patches
14275623
DATABASE PATCH SET UPDATE 11.1.0.7.13 (INCLUDES CPUOCT2012)

 I understand Oracle have an easier tool for this but it is not generally available. I am sure there is a good reason for that but it escapes me

Posted in Oracle | Tagged: , , | 2 Comments »

Using OEM reports to show PSU levels across the estate

Posted by John Hallas on March 30, 2011

The reporting capabilities of OEM are very good, although sometimes it is hard to find  which views the data you want is held in. This post is about sharing how to build a report which details how many databases are at each PSU patch. It will also show how to schedule a repeating report and save the history of each run so that trending can be measured. Most ( if not all ) of the work was performed by Sarabjit Lotay (encouraged by superb leadership !!)

First lets look at the end result. I have had to take out specific detail from our estate but the report looks like this

The red blotches don’t help but you can see the general format and it does prove very useful. The next shot shows how the report is made up

Read the rest of this entry »

Posted in Grid control and agents, Oracle | Tagged: , , , , | 3 Comments »

Identifying applied PSU patches

Posted by John Hallas on January 27, 2010

Metalink/My Oracle support note 988624.1 states that PSU 2 for 11GR1 was released on January 12th 2010. When applied, this takes the database version to 11.1.0.7.2. I say this but it is not apparent what version is installed.

The same note states that one of the advantages of the PSU releases is that “the version number is incremented so it is easier to tell what is installed”. Well I beg to differ and I will give you some examples to support my argument.

Firstly there is now obvious way to tell from the database what (database) version is applied. That includes looking at sqlplus, dba_registry, v$version, or the output from traces files. There might be options with taking traces or block dumps but that is hardly ” Read the rest of this entry »

Posted in Oracle | Tagged: , , , , , | 9 Comments »

Applying the 10.2.0.4.1 Patch Set Update (PSU)

Posted by John Hallas on July 28, 2009

Oracle have now provided a Patch Set Update (PSU) policy in conjunction with the existing Critical Patch Updates. Both patches will be delivered quarterly (Jan,Apr,Jul,Oct) and the PSU will contain the CPU so it is a bit of no-brainer to move to PSU patching if you already perform CPU patching.

The core statement around PSU is mentioned in Note 854428.1 is

PSU patches are intended to be low-risk. This is accomplished by controlling content and thorough testing. Included in the criteria for the bug fixes in the Database PSU are:

  • Critical technical issues with fixes that may affect a large number of customers and that are already proven in the field
  • Critical Patch Update fixes

PSU patches do not include any of the following:

  • Changes that require re-certification (for example, fixes that cause optimizer plan changes)
  • Fixes that require configuration changes

Each PSU has limited new content, typically between 50 and 100 new bug fixes.

PSU patches are guaranteed to be rolling RAC installable.

Available on most platforms (which is nice for those of us not on Linux) except Windows. Patches will be available but as part of the CPU bundles.

The patches are also cumulative so PSU 10.2.0.4.1 is the current one and when 10.2.0.4.2 is available then that can be applied on top.

As I had a clean Oracle 10.2.0.4 with the latest CPU set applied I added the PSU and here are a few notes.

You need to get the latest Opatch installation which is version 10.2.0.4.07 and is patch 680880. Copy it to the OH folder and unzip it from there, updating the existing Opatch binaries.

After ensuring that the correct OH and OPatch folder are in your path then check the opatch version 

/home/oracle $opatch version
Invoking OPatch 10.2.0.4.7

OPatch Version: 10.2.0.4.7

OPatch succeeded.

Unzip the CPU patch 8576156 and run the opatch pre-requisite check

I have shown all my actions here and note that the pre-req command is different from that in the documentation where the -ph parameter is referred to as -phBaseDir

opatch prereq CheckConflictAgainstOHWithDetail -ph ./8576156_Jul2009PSU

It then gives a list of patches to be applied, patches that will be rolled back and no longer required patches (superceded by those in this PSU). Note that you may need to get patches that are required but not available in the PSU patch.  

cd /shared/oracle/rdbms_patches/PSU patches/10.2.0.4/

README.html  README.txt   custom       etc          files        patchmd.xml  psu_root.sh
opatch prereq CheckConflictAgainstOHWithDetail -ph ./8576156_Jul2009PSU
Invoking OPatch 10.2.0.4.7

Oracle Interim Patch Installer version 10.2.0.4.7
Copyright (c) 2009, Oracle Corporation.  All rights reserved.

PREREQ session

Oracle Home       : /app/oracle/product/10.2.0.4/db_1
Central Inventory : /app/oracle/oraInventory
   from           : /var/opt/oracle/oraInst.loc
OPatch version    : 10.2.0.4.7
OUI version       : 10.2.0.4.0
OUI location      : /app/oracle/product/10.2.0.4/db_1/oui
Log file location : /app/oracle/product/10.2.0.4/db_1/cfgtoollogs/opatch/opatch2009-07-28_19-05-21PM.log

Patch history file: /app/oracle/product/10.2.0.4/db_1/cfgtoollogs/opatch/opatch_history.txt

Invoking prereq "checkconflictagainstohwithdetail"

ZOP-40: The patch(es) has conflicts/supersets with other patches installed in the Oracle Home (or) among themselves.

Prereq "checkConflictAgainstOHWithDetail" failed.

Summary of Conflict Analysis:

Patches that can be applied now without any conflicts are :
8576156

Following patches are not required, as they are subset of the patches in Oracle Home or subset of the patches in the given list :
8309642, 8309639, 8309637, 8309632, 8309623, 8309592, 8309587, 8290506, 7609058, 7609057, 7375617, 7375613, 7375611, 7197583, 7155254, 7155253, 7155252, 7155251, 7155250, 7155249, 7155248

Following patches will be rolled back from Oracle Home on application of the patches in the given list :
8309642, 8309639, 8309637, 8309632, 8309623, 8309592, 8309587, 8290506, 7609058, 7609057, 7375617, 7375613, 7375611, 7197583, 7155254, 7155253, 7155252, 7155251, 7155250, 7155249, 7155248

Once all pre-reqs are met then run opatch apply from the PSU patch directory

Afterwards run the psu_root.sh script from the patch installation directory (as root).

If you do not run psu_root.sh script which changes the permissions on the binary extjob, executable jobs can fail with the following error:

ORA-27369: job of type EXECUTABLE failed with exit code: ...

Note that this step has no impact on the implementation of the PSU security fixes; it only affects the successful execution of the Job Scheduling system. That is, if you do not run psu_root.sh when you should, or if you run psu_root.sh but fail to run it as root, the PSU security fixes are still installed; however, the Job Scheduling system will fail. The psu_root.sh needs permission changes and does not work that well so it is easier  to get sys admins to just chmod the permissions detailed in the shell script. 

All in all pretty seamless. Note that I did not have a database to patch but if I did then the two post-installation steps are to run the catbundle scripts and recompile views

For each database instance running on the Oracle home being patched, connect to the database using SQL*Plus. Connect as SYSDBA and run the catbundle.sql script as follows:

cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> STARTUP
SQL> @catbundle.sql psu apply
SQL> QUIT

The README.txt in the install directory details the recompilation of views but it is not  too difficult and only needs to be done once, no matter how many PSU sets are applied.

Posted in Oracle | Tagged: , , , , , | 7 Comments »