PSU Vs CPU

The Benefits of Database Server Patch Set Updates (PSUs)By Eric P. Maurice onSep 14, 2010TheCritical Patch Update program(CPU) is Oracle's primary mechanism for the release of security fixes for all Oracle products. Introduced in January 2005, Critical Patch Updates are released on dates announced a year in advance. Critical Patch Update patches correct security vulnerabilities and may, when required, include fixes that are prerequisites for the security fixes.In July 2009, Oracle introduced a new patch offering specific to Oracle Database Server: the Patch Set Update (PSU). More recently, Patch Set Updates for Oracle Enterprise Manager 10.2.0.5 and later were introduced, but for the purpose of this blog, we will only discuss Database Server PSUs.Patch Set Updates are available under the Critical Patch Update program, but unlike traditional CPU patches, PSUs provide a means to deliver security and non-security (i.e. critical bug fixes) fixes bundled together in a tested package. As a result, Database Server customers have a choice when each Critical Patch Update is released: they can opt to receive security fixes only (using the traditional N-apply CPU patches) or they can opt to receive a more comprehensive set of security and non-security fixes (using the Patch Set Update patches). Please note, that for each given Critical Patch Update, customers receive the same security fixes whether they choose to apply a PSU patch or a traditional N-apply CPU patch (in that sense, the traditional CPU patch contains a subset of the fixes available in the PSU patch).Note that Patch Set Updates are available only for Oracle Database Server 10.2.0.4 and later on platforms other than Windows. Windows Database bundles do however include the same fixes as the Patch Set Updates when they are released.The below table provides a summary comparison of the PSU patches and traditional N-apply patches available under the Critical Patch Update program.Top of Form

Bottom of FormThe application of the Patch Set Update results in the introduction of a new baseline version for the Database Server with consequences in regards to how future patches will be applied on the system when a PSU has previously been installed. Once a PSU has been applied on the system, the recommended method to apply all future CPU program security content is to apply future PSUs. In other words, once a PSU has been applied, it is not recommended to switch back to traditional N-apply patches. While such a switch is possible with assistance from Oracle technical support, it is a complex procedure and therefore is not recommended. However, if previously only traditional N-apply CPU patches have been applied, customers can elect to apply the most current Patch Set Update at any time.The primary benefit of the Patch Set Updates to customers is that they can receive, in a streamlined fashion, many recommended patches needed to keep their environment secure and operating at top efficiency. This is because the non-security fixes included in each Patch Set Update are designed to address issues related to system or instance-wide outages, severe functionality issues, etc. Non-security fixes that would require application or configuration changes, cause optimizer plan changes or dictionary changes, or contain architectural changes cannot be candidates for inclusion in PSUs.Another benefit of the Patch Set Updates is the safety they provide to customers. Since the bundle of fixes included in each Patch Set Update is tested together; the risk of regression issues that could be introduced when each fix is applied separately by customers is greatly reduced.For More Information: The Independent Oracle User Group (IOUG) recently posted areplay of a webcast on Database Server security patching with Bruce Lowenthal, Director for Security Alerts for Oracle, and Lois Price, Director for Product Lifecycle Services for Oracle. A significant portion of this webcast was dedicated to exploring the differences between PSUs and traditional CPU patches. The Critical Patch Updates and Security Alerts page is located athttp://www.oracle.com/technetwork/topics/security/alerts-086861.html Note 854428.1 "Patch Set Updates for Oracle Products" is located athttps://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=854428.1

According to Oracle Support article ID 1446582.1: Frequently Asked Questions (FAQ) Patching Oracle Database Server:

A PSU is a collection of proactive, stabilizing cumulative patches for a particular product version (base release or patch set). PSUs are cumulative and include all of the security fixes from CPU patches, plus additional fixes. Critical Patch Updates are the primary means of releasing security fixes for Oracle products. CPUs are cumulative with respect to prior CPUs and generally contain only security fixes.

So, there you have it. CPUs are smaller and more focused than PSU and mostly deal with security issues. PSUs contain bug fixes AND they contain the security fixes from the CPU. When you download a PSU, it will tell you which CPU it contains. PSUs are on the same quarterly schedule as the Critical Patch Updates (CPU), specifically the Tuesday closest to the 17th of January, April, July, and October. One thing to keep in mind, however, is that once a PSU has been installed, the recommended way to get future security content is to apply subsequent PSUs. Reverting from PSU back to CPU, while possible, would require significant effort and so is not advised. So with this in mind, why would someone choose to apply a CPU rather than a PSU? I suppose for folks who are concerned only with security fixes and not functionality fixes, a CPU-only approach may be best. It does seem to be the more conservative approach as a CPU is (in theory) less like to cause trouble than a PSU, simply because it has less code changes in it.

Note:CPU patches are meant to be applied only for the Database Home& Not the Grid Infrastructure Home

Thank youOsama MustafaPosted byOsama Mustafaat6:53:00 PMEmail ThisBlogThis!Share to TwitterShare to FacebookShare to PinterestLabels:CPU Patch,Critical Patch Updates,Oracle Osama,Osama,Osama blog,Osama mustafa,Osama mustafa blog,osama oracle2 comments:1. MESLI AbdelhadiJanuary 14, 2013 at 11:32 PMThank you osama i want test this but i dont have Critical Patch Updates where can I find cpu for testing propose?ReplyReplies1. Osama MustafaJanuary 15, 2013 at 8:21 AMyour welcome , you can install Any CPU patch Fromhttp://www.oracle.com/technetwork/topics/security/alerts-086861.html

Choose Your Patch and also its useful to check and read what this patch fix , And don't forget to be similar as your database version .ReplyNewer PostOlder PostHomeSubscribe to:Post Comments (Atom)Oracle ACE

This is Google's cache ofhttp://shivanandarao-oracle.com/2012/09/20/applying-psu-patch-in-a-dataguard-physical-standby-environment/. It is a snapshot of the page as it appeared on 2 Jun 2014 16:37:37 GMT. Thecurrent pagecould have changed in the meantime.Learn moreTip: To quickly find your search term on this page, pressCtrl+For-F(Mac) and use the find bar.Text-only versionShivananda RaoOracle Database issues & solutions

Skip to content Home About MeDataguard FailoverResizing Redo Logs in a Dataguard Envrionment (Physical Standby inplace)Applying PSU Patch in a dataguard (Physical Standby)environmentPosted onSeptember 20, 2012byShivananda Rao P7 Votes

Here is a brief explanation on how to apply PSU (Patch Set Update) in a dataguard environmentIn this demo, I am applying PSU 11.2.0.2.4 on the Primary and standby databases.Primary database Server :devStandby database Server :uatPrimary database :srprimStandby database :srpsPrimary Server:

[oracle@dev ~]$ sqlplus sys/oracle@srprim as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Tue Sep 18 10:43:50 2012

Copyright (c) 1982, 2010, Oracle. All rights reserved.

Connected to:Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit ProductionWith the Partitioning, Automatic Storage Management, OLAP, DataMining and Real Application Testing options

SQL> select status,instance_name,database_role from v$database,v$instance;

STATUS INSTANCE_NAME DATABASE_ROLE------ ------------- ---------------OPEN srprim PRIMARY

SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)--------------10Standby Server:[oracle@uat ~]$ sqlplus sys/oracle@srps as sysdba




SQL> select status,instance_name,database_role from v$database,v$instance;

STATUS INSTANCE_NAME DATABASE_ROLE-------- -------------- ----------------------MOUNTED srps PHYSICAL STANDBY

SQL> select max(sequence#) from v$archived_log where applied='YES';

MAX(SEQUENCE#)--------------10Step 1:Disable the log shipping from primary database to the standby database by setting the log_archive_dest_state_2 to deferon the primary database. Here log_archive_dest_state_2 is deferred because parameter log_archive_dest_2 is set on my primary database to point to the Standby Database.SQL> alter system set log_archive_dest_state_2=defer;

System altered.Step 2:On the standby databasecancel the Managed Recovery Process.SQL> alter database recover managed standby database cancel;

Database altered.Step 3:PSU (Patch Set Update)/CPU (Critical Patch Update)/ Patch Set patches always needs to be applied first on the standby database and then on the primary database. In order to apply it on the standby database,shutdown the standby database and also the listener running on the standby server.SQL> shutdown immediateORA-01109: database not open

Database dismounted.ORACLE instance shut down.

[oracle@uat ~]$ lsnrctl stop

[oracle@uat ~]$ ps -ef | grep tnsoracle 6958 5107 0 10:52 pts/1 00:00:00 grep tns[oracle@uat ~]$[oracle@uat ~]$ ps -ef | grep pmonoracle 4788 1 0 09:56 ? 00:00:00 asm_pmon_+ASMoracle 6960 5107 0 10:52 pts/1 00:00:00 grep pmonStep 4:Nowapply the PSU on the standby database.[oracle@uat ~]$ export PATH=$PATH:/u01/app/oracle/product/11.2.0.2/db_1/OPatch[oracle@uat ~]$ opatch versionOPatch Version: 11.2.0.3.0

OPatch succeeded.

[oracle@uat ~]$ opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /opt/12827726Oracle Interim Patch Installer version 11.2.0.3.0Copyright (c) 2012, Oracle Corporation. All rights reserved.

PREREQ session

Oracle Home : /u01/app/oracle/product/11.2.0.2/db_1Central Inventory : /u01/home/oraInventoryfrom : /u01/app/oracle/product/11.2.0.2/db_1/oraInst.locOPatch version : 11.2.0.3.0OUI version : 11.2.0.2.0Log file location : /u01/app/oracle/product/11.2.0.2/db_1/cfgtoollogs/opatch/opatch2012-09-18_11-11-40AM_1.log

Invoking prereq "checkconflictagainstohwithdetail"

Prereq "checkConflictAgainstOHWithDetail" passed.

OPatch succeeded.

[oracle@uat ~]$ opatch apply /opt/12827726/Oracle Interim Patch Installer version 11.2.0.3.0Copyright (c) 2012, Oracle Corporation. All rights reserved.

Oracle Home : /u01/app/oracle/product/11.2.0.2/db_1Central Inventory : /u01/home/oraInventoryfrom : /u01/app/oracle/product/11.2.0.2/db_1/oraInst.locOPatch version : 11.2.0.3.0OUI version : 11.2.0.2.0Log file location : /u01/app/oracle/product/11.2.0.2/db_1/cfgtoollogs/opatch/12827726_Sep_18_2012_11_12_36/apply2012-09-18_11-12-35AM_1.log

Applying interim patch '12827726' to OH '/u01/app/oracle/product/11.2.0.2/db_1'Verifying environment and performing prerequisite checks...All checks passed.Provide your email address to be informed of security issues, install and initiate Oracle Configuration Manager. Easier for you if you use your My Oracle Support Email address/User Name.Visit http://www.oracle.com/support/policies.html for details.Email address/User Name:

You have not provided an email address for notification of security issues.

Do you wish to remain uninformed of security issues ([Y]es, [N]o) [N]: Y

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.(Oracle Home = '/u01/app/oracle/product/11.2.0.2/db_1')

Is the local system ready for patching? [y|n]yUser Responded with: YBacking up files...

Patching component oracle.rdbms.rsf, 11.2.0.2.0...

Patching component oracle.rdbms, 11.2.0.2.0...

Patching component oracle.sysman.console.db, 11.2.0.2.0...

Patching component oracle.sysman.oms.core, 10.2.0.4.3...

Patching component oracle.ldap.rsf, 11.2.0.2.0...

Patching component oracle.rdbms.dv, 11.2.0.2.0...

Patching component oracle.rdbms.dbscripts, 11.2.0.2.0...

Patching component oracle.sysman.plugin.db.main.repository, 11.2.0.2.0...

Patching component oracle.rdbms.rman, 11.2.0.2.0...

Patching component oracle.sdo.locator, 11.2.0.2.0...

Verifying the update...Patch 12827726 successfully appliedLog file location: /u01/app/oracle/product/11.2.0.2/db_1/cfgtoollogs/opatch/12827726_Sep_18_2012_11_12_36/apply2012-09-18_11-12-35AM_1.log

OPatch succeeded.Step 5:Once the patch has been applied on the standby database,start the listener and the standby database.

[oracle@uat ~]$ lsnrctl start

[oracle@uat ~]$ sqlplus sys/oracle@srps as sysdba



Connected to an idle instance.

SQL> startup mountORACLE instance started.

Total System Global Area 684785664 bytesFixed Size 2229640 bytesVariable Size 197134968 bytesDatabase Buffers 482344960 bytesRedo Buffers 3076096 bytesDatabase mounted.Note: Do not run any patching scripts on the standby database (Example: catbundle.sql).We are done with the patching on the standby database. Now lets move to the primary database.Step 6:Shutdown the Primary database and stop the listener running on the primary database server.





SQL> shutdown immediateDatabase closed.Database dismounted.ORACLE instance shut down.SQL> exitDisconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit ProductionWith the Partitioning, Automatic Storage Management, OLAP, DataMining and Real Application Testing options

[oracle@dev ~]$ lsnrctl stop

[oracle@dev ~]$ ps -ef | grep pmonoracle 4618 1 0 09:53 ? 00:00:00 asm_pmon_+ASMoracle 10233 4998 0 11:50 pts/1 00:00:00 grep pmon[oracle@dev ~]$[oracle@dev ~]$ ps -ef | grep tnsoracle 10237 4998 0 11:50 pts/1 00:00:00 grep tnsStep 7:Nowapply the PSU patch on the Primary database.[oracle@dev ~]$ export PATH=$PATH:/u01/app/oracle/product/11.2.0.2/db1/OPatch[oracle@dev ~]$ opatch versionOPatch Version: 11.2.0.3.0

OPatch succeeded.

[oracle@dev ~]$ opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /opt/12827726/Oracle Interim Patch Installer version 11.2.0.3.0Copyright (c) 2012, Oracle Corporation. All rights reserved.

PREREQ session

Oracle Home : /u01/app/oracle/product/11.2.0.2/db1Central Inventory : /u01/home/oraInventoryfrom : /u01/app/oracle/product/11.2.0.2/db1/oraInst.locOPatch version : 11.2.0.3.0OUI version : 11.2.0.2.0Log file location : /u01/app/oracle/product/11.2.0.2/db1/cfgtoollogs/opatch/opatch2012-09-18_11-56-11AM_1.log

Invoking prereq "checkconflictagainstohwithdetail"

Prereq "checkConflictAgainstOHWithDetail" passed.

OPatch succeeded.

[oracle@dev ~]$ export PATH=$PATH:/u01/app/oracle/product/11.2.0.2/db1/OPatch[oracle@dev ~]$ opatch apply /opt/12827726/Oracle Interim Patch Installer version 11.2.0.3.0Copyright (c) 2012, Oracle Corporation. All rights reserved.

Oracle Home : /u01/app/oracle/product/11.2.0.2/db1Central Inventory : /u01/home/oraInventoryfrom : /u01/app/oracle/product/11.2.0.2/db1/oraInst.locOPatch version : 11.2.0.3.0OUI version : 11.2.0.2.0Log file location : /u01/app/oracle/product/11.2.0.2/db1/cfgtoollogs/opatch/12827726_Sep_18_2012_12_17_40/apply2012-09-18_12-17-39PM_1.log

Applying interim patch '12827726' to OH '/u01/app/oracle/product/11.2.0.2/db1'Verifying environment and performing prerequisite checks...All checks passed.Provide your email address to be informed of security issues, install and initiate Oracle Configuration Manager. Easier for you if you use your My Oracle Support Email address/User Name.Visit http://www.oracle.com/support/policies.html for details.Email address/User Name:

You have not provided an email address for notification of security issues.Do you wish to remain uninformed of security issues ([Y]es, [N]o) [N]: Y

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.(Oracle Home = '/u01/app/oracle/product/11.2.0.2/db1')

Is the local system ready for patching? [y|n]yUser Responded with: YBacking up files...

Patching component oracle.rdbms.rsf, 11.2.0.2.0...

Patching component oracle.rdbms, 11.2.0.2.0...

Patching component oracle.sysman.console.db, 11.2.0.2.0...

Patching component oracle.sysman.oms.core, 10.2.0.4.3...

Patching component oracle.ldap.rsf, 11.2.0.2.0...

Patching component oracle.rdbms.dv, 11.2.0.2.0...

Patching component oracle.rdbms.dbscripts, 11.2.0.2.0...

Patching component oracle.sysman.plugin.db.main.repository, 11.2.0.2.0...

Patching component oracle.rdbms.rman, 11.2.0.2.0...

Patching component oracle.sdo.locator, 11.2.0.2.0...

Verifying the update...Patch 12827726 successfully appliedLog file location: /u01/app/oracle/product/11.2.0.2/db1/cfgtoollogs/opatch/12827726_Sep_18_2012_12_17_40/apply2012-09-18_12-17-39PM_1.log

OPatch succeeded.Step 8:Start the listener on the primary database server and also start the Primary database.

[oracle@dev ~]$ lsnrctl start




Connected to an idle instance.

SQL> startupORACLE instance started.

Total System Global Area 684785664 bytesFixed Size 2229640 bytesVariable Size 222300792 bytesDatabase Buffers 457179136 bytesRedo Buffers 3076096 bytesDatabase mounted.Database opened.SQL>Step 9:Nowenable log shipping on the primary database by setting the log_archive_dest_state_2 to enable. As I said earlier, parameter log_archive_dest_2 on my primary database is set to point to the standby database.SQL> alter system set log_archive_dest_state_2=enable;

System altered.Step 10:Start the Managed Recovery Process (MRP) on the standby database.[oracle@uat ~]$ sqlplus sys/oracle@srps as sysdba




SQL> alter database recover managed standby database disconnect;

Database altered.

SQL> select process,status,sequence# from v$managed_standby;

PROCESS STATUS SEQUENCE#------- ------------- -----------ARCH CONNECTED 0ARCH CONNECTED 0ARCH CONNECTED 0ARCH CONNECTED 0RFS IDLE 0RFS IDLE 13RFS IDLE 0RFS IDLE 0MRP0 WAIT_FOR_LOG 13

9 rows selected.

Step 11:On the primary database, run the patching scripts like catbundle.sql in this case.The script run generates archives and these archives would be shipped and applied to the standby database. So, there is no requriement to run the patching scripts on the standby database.





SQL> @?/rdbms/admin/catbundle.sql psu apply

SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)--------------14Step 12:Check if the PSU applied shows up in the primary database by querying the registry$history or dba_registry_history view.

SQL> select * from registry$history order by action_time desc;

ACTION_TIME ACTION NAMESPACE VERSION ID COMMENTS BUNDLE_SER------------------------------ ---------- ---------- --------------- ---------- ------------------------- ----------18-SEP-12 12.32.44.728562 PM APPLY SERVER 11.2.0.2 4 PSU 11.2.0.2.4 PSUStep 13:Make sure that the latest archive applied on the standby database is the latest archive generated on the primary database. You can see below that the latest archive sequence applied on the standby database is sequence 14 and the latest sequence generated on the primary database too is 14. Now, check if the PSU applied shows up in the standby database by querying the registry$history or dba_registry_history view.

[oracle@uat ~]$ sqlplus sys/oracle@srps as sysdba




SQL> select max(sequence#) from v$archived_log where applied='YES';

MAX(SEQUENCE#)--------------14

SQL> select * from registry$history order by action_time desc;

ACTION_TIME ACTION NAMESPACE VERSION ID COMMENTS BUNDLE_SER----------------------------------- ---------- ---------- ---------- ---------- ------------------------- ----------18-SEP-12 12.32.44.728562 PM APPLY SERVER 11.2.0.2 4 PSU 11.2.0.2.4 PSUWe can see that the PSU is applied successfully on both Primary and standby databases.Here we go !!Share this: Email Twitter Facebook LinkedIn This entry was posted inDataguard. Bookmark thepermalink.Dataguard FailoverResizing Redo Logs in a Dataguard Envrionment (Physical Standby inplace)12 Responses toApplying PSU Patch in a dataguard (Physical Standby)environment1. Syedsays:October 3, 2012 at 11:16 amthis is a very quick reference!! easy to understand ,,Reply2. gouthamk10says:October 5, 2012 at 10:51 amHigood doc.nice step by step process.thanks for the doc.Reply3. pavansays:November 25, 2012 at 11:39 amyes its verys understandable way thanksReply Shivananda Rao Psays:November 25, 2012 at 4:26 pmThank you !Reply4. Jamshersays:April 25, 2013 at 5:18 amHi Shiva,I just read the below post which says thathttp://oracleinaction.blogspot.in/2012/12/DGFBRESETLOGS.htmlIf primary database is opened with resetlogs option following an incomplete recovery, redo apply service might halt on standby database when it encounters open resetlogs command in redo. But if physical standby databases SCN is far enough behind the primary databases SCN, then redo apply service can interpret open resetlogs command without stopping.Hence , after primary has been opened with resetlogs option, if we flashback standby database to an SCN which is earlier than reset logs SCN# of primary, we wont have to recreate the standby database.RegardsJamsherReply Shivananda Rao Psays:April 25, 2013 at 5:34 amYes, if flashback is enabled, then you can use this feature. Please refer my document on failover under the dataguard section.Regards,Shivananda.Reply5. Leahsays:August 7, 2013 at 4:33 amSaved my life during the production upgrade thank you so much.Reply6. srinivasa reddy bijjamsays:March 18, 2014 at 11:56 amexcellent .. mind blowing . superb UN-believable .this article makes me good understand of applying patches on data-guard environmentnice procedure you are following in every article and is understandable to everybody..thank u verymuchReply Shivananda Rao Psays:March 21, 2014 at 5:18 amThanks Srinivasa.Reply7. Munavversays:May 9, 2014 at 2:54 amHi Shiva,Thanks for your guidence.Very good and easy doc.Good goingReply8. Jamshersays:April 24, 2013 at 5:58 amHi Shiva,Can you please post an article on how we can recover standby database after incomplete recovery of primary.. Thanks & RegardsReply9. Shivananda Rao Psays:April 24, 2013 at 2:31 pmHello Jamsher,Once you do an incomplete recovery of the primary database and open it with the resetlogs, the archive sequence would start from 1 and the standby would be out of sync. Youll have to rebuild the standby database in this case.Regards,ShivanandaReplyLeave a ReplyTop of Form

Bottom of Form Top of FormBottom of Form Recent Posts Recovering a corrupted/lost datafile on Primary database from the Standbydatabase Recovering a Dropped Table using RMAN and DatapumpOptions RAC database upgrade from 11.2.0.1 to11.2.0.3 CRS upgrade from 11.2.0.1 to11.2.0.3 2013 in review Archives May 2014(1) April 2014(1) March 2014(1) January 2014(1) December 2013(2) November 2013(1) October 2013(1) July 2013(1) June 2013(1) May 2013(1) March 2013(2) February 2013(2) January 2013(1) December 2012(2) November 2012(1) October 2012(2) September 2012(1) August 2012(1) July 2012(1) June 2012(1) May 2012(1) April 2012(4) March 2012(5) Categories Database Dataguard RMAN Uncategorized Event CalendarMTWTFSS

AugOct

12

3456789

10111213141516

17181920212223

24252627282930

September 2012

Follow Blog via EmailTop of FormEnter your email address to follow this blog and receive notifications of new posts by email.Join 57 other followers

Bottom of Form Blog Stats 136,753 hitsShivananda RaoThe Twenty Ten Theme. Blog at WordPress.com.FollowFollow Shivananda RaoTop of FormGet every new post delivered to your Inbox.Join 57 other followers

Bottom of FormPowered by WordPress.com

Before applying PSU 11.2.0.2.3 be sure you understand clearly whatpatching and a patch set updateis.

Prerequisites

*You need Opatch utility version 11.2.0.1.5 or higher to apply this PSU. Check yourOpatch version and upgradeit if necessary at both GI (grid infrastructure)home and database home.

*During patching you will be asked for anOCM (Oracle Configuration Manager) response file. Create one before applying PSU 11.2.0.2.3 if you don't already have one.

* Your database software version must be 11.2.0.2.

Download PSU 11.2.0.2.3

There are two patches available for this PSU. Patch 12419331 and Patch 1219353. Patch 12419331 is officially named "database PSU 11.2.0.2.3", while patch 1219353 is named GI (grid infrastructure) PSU 11.2.0.2.3. Patch 1219353 includes Patch 12419331. It means, if you apply patch 1219353, you will also have applied patch 12419331.You must be using GI if you have RAC (Real Application Clusters), ASM (Automatic Storage Management) or Oracle Restart configured. As of version 11.2.0.2, most of the database systems have GI. So, we will be explaining how to apply patch 12419353.

1.Login to metalink.2. Click "Patches & Updates" link on top menu.3.On the patch search section enter 12419353 and select the platform of your database.4. Click search.5.On the search results page, download the zip file.

Verify Current Structure

My server platform is: Linux x86-64.

My GI home is at "/u01/app/grid/11.2.0.2/" and there are 88 products installed at GI home.123456789101112131415161718192021222324252627282930313233$ /u01/app/grid/11.2.0.2/OPatch/opatch lsinventory -detail -oh /u01/app/grid/11.2.0.2/Invoking OPatch 11.2.0.1.6Oracle Interim Patch Installer version 11.2.0.1.6Copyright (c) 2011, Oracle Corporation. All rights reserved.Oracle Home : /u01/app/grid/11.2.0.2Central Inventory : /u01/oraInventoryfrom : /etc/oraInst.locOPatch version : 11.2.0.1.6OUI version : 11.2.0.2.0Log file location : /u01/app/grid/11.2.0.2/cfgtoollogs/opatch/opatch2011-09-07_10-25-00AM.logLsinventory Output file location : /u01/app/grid/11.2.0.2/cfgtoollogs/opatch/lsinv/lsinventory2011-09-07_10-25-00AM.txt--------------------------------------------------------------------------------Installed Top-level Products (1):Oracle Grid Infrastructure 11.2.0.2.0There are 1 products installed in this Oracle Home.Installed Products (88):Agent Required Support Files 10.2.0.4.3Assistant Common Files 11.2.0.2.0Automatic Storage Management Assistant 11.2.0.2.0Bali Share 1.1.18.0.0Buildtools Common Files 11.2.0.2.0Character Set Migration Utility 11.2.0.2.0Cluster Ready Services Files 11.2.0.2.0Cluster Verification Utility Common Files 11.2.0.2.0****************** Output Truncated **********************

My database home is at "/u01/app/oracle/11.2.0.2/" and there are 136 products installed at this home.1234567891011121314151617181920212223242526272829303132333435363738394041$ /u01/app/grid/11.2.0.2/OPatch/opatch lsinventory -detail -oh /u01/app/oracle/11.2.0.2/Invoking OPatch 11.2.0.1.6Oracle Interim Patch Installer version 11.2.0.1.6Copyright (c) 2011, Oracle Corporation. All rights reserved.Oracle Home : /u01/app/oracle/11.2.0.2Central Inventory : /u01/oraInventoryfrom : /etc/oraInst.locOPatch version : 11.2.0.1.6OUI version : 11.2.0.2.0Log file location : /u01/app/oracle/11.2.0.2/cfgtoollogs/opatch/opatch2011-09-07_10-34-45AM.logLsinventory Output file location : /u01/app/oracle/11.2.0.2/cfgtoollogs/opatch/lsinv/lsinventory2011-09-07_10-34-45AM.txt--------------------------------------------------------------------------------Installed Top-level Products (1):Oracle Database 11g 11.2.0.2.0There are 1 products installed in this Oracle Home.Installed Products (136):Agent Required Support Files 10.2.0.4.3Assistant Common Files 11.2.0.2.0Bali Share 1.1.18.0.0Buildtools Common Files 11.2.0.2.0Character Set Migration Utility 11.2.0.2.0Cluster Verification Utility Common Files 11.2.0.2.0Database Configuration and Upgrade Assistants 11.2.0.2.0Database SQL Scripts 11.2.0.2.0Database Workspace Manager 11.2.0.2.0Deinstallation Tool 11.2.0.2.0Enterprise Edition Options 11.2.0.2.0Enterprise Manager Agent 10.2.0.4.3Enterprise Manager Agent Core Files 10.2.0.4.3Enterprise Manager Common Core Files 10.2.0.4.3Enterprise Manager Common Files 10.2.0.4.3****************** Output Truncated **********************

When you install Oracle database software, thousands of files (object files, archive libraries, shared libraries etc.) will be created on your server. In fact, Oracle database software is not one undivided product. It is composed of several sub products and each of these sub products has its own version. As seen in the output above at line 18, "Oracle Database 11g" is shown as a "Top-level Product" with version 11.2.0.2.0, while "Enterprise Manager Agent" is shown as a "product" with version 10.2.0.4.3. Oracle may announce a patch or an upgrade for an individual product while the main database software version remains the same.

opatch lsinventory -detail -oh

"-detail" parameter will show all the products installed at the home specified (). If you omit "-detail" parameter, only patches that are installed at that home will be listed. You won't be able to see the products installed.

If the "opatch lsinventory -detail" command does not return an output, it is probable that your inventory is corrupted. Do not install the psu and contact Oracle support in such situation.Unzip PSU 11.2.0.2.3

As oracle user, create a folder. Copy the zip file to that folder and unzip it.12345[root]# su - oracle[oracle]$ mkdir my_psu[oracle]$ cp p12419353_112020_Linux-x86-64.zip my_psu/[oracle]$ cd my_psu/[oracle]$ unzip p12419353_112020_Linux-x86-64.zip

Apply PSU 11.2.0.2.3Switch to root user. Add the OPatch directory under GI Home to $PATH environment variable.1# export PATH=$PATH:/u01/app/grid/11.2.0.2/OPatch/

Verify that root user can find the opatch script.123# which opatch/u01/app/grid/11.2.0.2/OPatch/opatch

Enter the directory that you've created above and execute the " opatch auto . " command.123456789101112131415161718192021222324252627# cd my_psu/# opatch auto .Executing /usr/bin/perl /u01/app/grid/11.2.0.2/OPatch/crs/patch112.pl -patchdir . -patchn . -paramfile /u01/app/grid/11.2.0.2/crs/install/crsconfig_paramsopatch auto log file location is /u01/app/grid/11.2.0.2/OPatch/crs/../../cfgtoollogs/opatchauto2011-09-07_11-26-37.logDetected Oracle Restart installUsing configuration parameter file: /u01/app/grid/11.2.0.2/crs/install/crsconfig_paramsOPatch is bundled with OCM, Enter the absolute OCM response file path:/u01/app/grid/11.2.0.2/OPatch/ocm/bin/ocm.rsppatch ././12419353/custom/server/12419353 apply successful for home /u01/app/oracle/11.2.0.2patch ././12419331 apply successful for home /u01/app/oracle/11.2.0.2Successfully unlock /u01/app/grid/11.2.0.2patch ././12419353 apply successful for home /u01/app/grid/11.2.0.2patch ././12419331 apply successful for home /u01/app/grid/11.2.0.2ACFS-9300: ADVM/ACFS distribution files found.ACFS-9312: Existing ADVM/ACFS installation detected.ACFS-9314: Removing previous ADVM/ACFS installation.ACFS-9315: Previous ADVM/ACFS components successfully removed.ACFS-9307: Installing requested ADVM/ACFS software.ACFS-9308: Loading installed ADVM/ACFS drivers.ACFS-9321: Creating udev for ADVM/ACFS.ACFS-9323: Creating module dependencies - this may take some time.ACFS-9327: Verifying ADVM/ACFS devices.ACFS-9309: ADVM/ACFS installation correctness verified.CRS-4123: Oracle High Availability Services has been started.

"Opatch auto" command willfirst patch your database home with patch 12419353 and 12419331 respectively. Then it will patch your GI home, again with patch 12419353 and 12419331 respectively.

"Opatch auto" command requires you to specify the folder where unzipped patch file resides. As I was already in that folder I entered "." (dot). In linux, "." points the directory that you are currently in.

In this example we've patched a single server with GI home and database home. But the same command will also work in a RAC environment. Execute this script oneach node separately. Do not patch nodes in parallel. Patch one node at a time.If your GI or database home is shared (software files reside in a shared location) you need to take a few extra steps before executing the "opatch auto" command but it is enough to install this only at one node. Refer to metalink for more information.

Executecatbundle.sql Script -- to modify the database catalog

Opatch tool replaces software files but does not modify database catalog. Applying a patch set update requires modifying the catalog. There is an sql script file named "catbundle.sql" under "$ORACLE_HOME/rdbms/admin" directory. Execute that script as sysdba to make necessary modification to the catalog.12345$ cd $ORACLE_HOME/rdbms/admin$ sqlplus / as sysdbasql>@catbundle.sql psu apply

That's all. Database is fully patched now.

Verify that the patches have been applied successfully

The patches we've installed must be reflected in inventory.12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182$ ./opatch lsinventory -oh /u01/app/grid/11.2.0.2/Invoking OPatch 11.2.0.1.6Oracle Interim Patch Installer version 11.2.0.1.6Copyright (c) 2011, Oracle Corporation. All rights reserved.Oracle Home : /u01/app/grid/11.2.0.2Central Inventory : /u01/oraInventoryfrom : /etc/oraInst.locOPatch version : 11.2.0.1.6OUI version : 11.2.0.2.0Log file location : /u01/app/grid/11.2.0.2/cfgtoollogs/opatch/opatch2011-09-07_13-52-18PM.logLsinventory Output file location : /u01/app/grid/11.2.0.2/cfgtoollogs/opatch/lsinv/lsinventory2011-09-07_13-52-18PM.txt--------------------------------------------------------------------------------Installed Top-level Products (1):Oracle Grid Infrastructure 11.2.0.2.0There are 1 products installed in this Oracle Home.Interim patches (2) :Patch 12419331 : applied on Wed Sep 07 11:35:22 EEST 2011Unique Patch ID: 13846303Created on 11 Jul 2011, 07:34:02 hrs PST8PDTBugs fixed:10151017, 10158965, 11724916, 10190642, 12586486, 12586487, 1012964312586488, 12586489, 10018789, 9744252, 10248523, 9956713, 103565139715581, 9770451, 10378005, 10170431, 10425676, 10222719, 101260949591812, 10127360, 10132870, 10094201, 9443361, 10193846, 1166404611069199, 10324294, 10245086, 12586490, 10205230, 12586491, 1005214112586492, 12586493, 12586494, 10142788, 11818335, 11830776, 125864959905049, 11830777, 12586496, 11830778, 6892311, 10040921, 1007719110358019, 12431716, 10219576, 10258337, 11707699, 10264680, 1020923211651810, 10102506, 11067567, 9881076, 10278372, 10040531, 1062116910155605, 10082277, 10356782, 10218814, 9078442, 9788588, 101572499735237, 10317487, 12326246, 11707302, 10310299, 10636231, 1023057111065646, 12419321, 10368698, 10079168, 10013431, 10228151, 1023373210324526, 8223165, 10238786, 10217802, 10061015, 9953542, 957278710052956, 10080579, 11699057, 12620422, 10332111, 10227288, 1032914610332589, 10110863, 10073683, 9869401, 10019218, 10229719, 116647199539440, 10373381, 9735282, 9748749, 11724984, 10022980, 1041161811800854, 12419331, 11674485, 10187168, 6523037, 10648873, 972497010053725, 10084145, 10367188, 11800170, 11695285, 10157402, 9651350, 10299224Patch 12419353 : applied on Wed Sep 07 11:34:37 EEST 2011Unique Patch ID: 13846303Created on 17 Jul 2011, 08:05:53 hrs PST8PDTBugs fixed:12419353, 10157506, 10178670, 10425672, 12311357, 9959110, 1027261510314123, 10014392, 10089120, 10057296, 9864003, 11775080, 991614510044622, 12399977, 12421404, 12340700, 10056713, 10637741, 99393069902536, 10007185, 10376847, 10038791, 11741224, 11655840, 1004848710322157, 10260251, 10052721, 10028235, 10027079, 10357258, 1004543610231906, 10622973, 9891341, 10072474, 10036834, 10029900, 997422310016083, 9918485, 11781515, 10040647, 10069541, 10029119, 1023315912332919, 9812956, 10036193, 10015210, 12340501, 10621175, 118770798906163, 10111010, 10115514, 10104377, 10057680, 10280665, 100780869944948, 10146768, 10052529, 10011084, 10012319, 10073075, 1023381110299006, 10248739, 10236074, 10128191, 11071429, 10019726, 997583710253630, 9949676, 11936945, 10637483, 10157622, 11698552, 1038583810053985, 10425674, 9812970, 11828633, 11899801, 10083789, 987620110073372, 9963327, 11077756, 10375649, 9336825, 11682409, 1006230110018215, 10105195, 10419987, 10071992, 10634513, 9926027, 1010395410028343, 11866171, 10065216, 9907089, 9897335, 10190153, 1174431310175855, 10284828, 10028637, 10361177, 9979706, 10324594, 100154609971646, 11782423, 11654726, 9978765, 10398810, 11904778, 103976529915329, 10107380, 10110969, 10305361, 10331452, 10083009, 1063169310008467, 10048027, 10040109, 9944978, 10033106, 9978195, 1184062910042143, 10284693, 10638381, 9679401, 11663339, 10075643, 1020529010124517, 11069614, 9593552, 10168006, 12677816, 11807012, 118466869867867, 10228079, 10015603, 10241696, 9942881, 10252497, 1028305810157625, 10283167, 9906432, 10216878, 10045316, 10425675, 1006153411789566, 10283549, 10311856, 10150020, 12421420, 12378675, 1011389910069698, 9861790, 10087118, 10056808, 10146744, 10326548, 100197969975343, 9936659, 10244210, 10029794, 10266447, 10193581, 1231856011804097, 10070563, 10268642, 10283596--------------------------------------------------------------------------------OPatch succeeded.

As seen in the output, Patch 12419331 and Patch 12419353 have been applied to my GI home. I can also query my database home in the same way. If I do, I'll see a similar output.

The PSU must also be reflected in database catalog.1sql> SELECT * FROM dba_registry_history ORDER BY action_time DESC ;

ACTION_TIMEACTIONNAMESPACEVERSIONIDBUNDLE_SERIESCOMMENTS

08.26.2011 19:23:20APPLYSERVER11.2.0.23PSUPSU 11.2.0.2.3

08.10.2011 16:30:42APPLYSERVER11.2.0.20PSUPatchset 11.2.0.2.0

09.05.2010 06:22:14APPLYSERVER11.2.0.20PSUPatchset 11.2.0.2.0

On the first line you can seethat PSU 11.2.0.2.3 was applied at 08.26.2011 19:23:20.

Important Notes:

1. Applying patch set on a single instance database requires down time. Your database will bedownduring operation. The time it takes to apply this patch set depends on your hardware configuration. In a server with a good hardware, it shouldn't take more than 15 minutes. At the time you enter "opatch auto" command, your database will be shutdown. After the patch is applied, it will automatically be opened.

2. If you apply this patch set update on a RAC, execute this command on only one node at a time so that only one instance will be down during patching process.Opatch will shutdown and restart the instances when necessary. No manual intervention is required. During operation, your database will always be reachable at least via one instance. (More information oninstance and database concepts) This is one of the benefits of using RAC. It provides you high availability.

3. Always test this patch set update on a test database before applying it on your production database. You should have a test database, which has an identical configuration with the production database. These test procedures are extra work for you but there is no guarantee that everything will go as expected. It is better to face surprises on a test database than facing them on the production database.

Documents

PSU Vs CPU