AIX Oracle 11g RAC自动打GI PSU5补丁(11.2.0.3.5)
【PSU】AIX Oracle 11g RAC自动打GI PSU5补丁(11.2.0.3.5)
前言部分
导读和注意事项
各位技术爱好者，看完本文后，你可以掌握如下的技能，也可以学到一些其它你所不知道的知识，~O(∩_∩)O~：
① 升级PSU的一般性方法（重点）
② PSU/CPU/PATCHSET等的一些相关概念
③ 如何查看oracle的PSU，如何在MOS上找到想要的patch号
相关知识点扫盲
每个数据库版本都有自己的PSU，PSU版本号体现在数据库版本的最后一位，MOS站点中Oracle Recommended Patches — Oracle Database [ID 756671.1] 文档中查到各个产品版本最新的PSU。
PSU (Patch Set Updates)
PSU(补丁集更新)是累积型补丁--即某个特定的补丁集，它先前所有的PSU被包含于最近的PSU中，例如：11.2.0.3.11的所有bug修复被包含于11.2.0.3.12中。PSU包含推荐的bug修复，及最近的CPU，PSU每个季度发布一次。
Oracle对于其产品每个季度发行一次的补丁包，包含了bug的修复。Oracle选取被用户下载数量多的，并且被验证过具有较低风险的补丁放入到每个季度的PSU中。在每个PSU中不但包含Bug的修复而且还包含了最新的CPU。
CPU: Critical Patch Update （SPU: Security Patch Update）
Oracle对于其产品每个季度发行一次的安全补丁包，通常是为了修复产品中的安全隐患。
Upgrade与Update
首先，我们针对所使用的数据库可能会进行如下措施，版本升级或补丁包升级，那何为版本升级、何为补丁包升级呢？
比如我的当前数据库是10GR2版本，但公司最近有个升级计划，把这套数据库升级到当下最新的11GR2，这种大版本间升级动作即为Upgrade。根据公司计划在原厂工程师和DBA共同努力下，数据库已升级到11GR2，当下版本为11.2.0.3.0。这时候原厂工程师推荐把最新的PSU给打上，获得老板的批准之后，我们又把数据库进行补丁包的升级，应用了PSU Patch14727310之后，数据库版本现在成为11.2.0.3.5，这个过程即是Update。
不得不再次提醒，Upgrade和Update都希望在获得原厂的支持下进行，尤其是Upgrade，这对于企业来说是个非常大的动作！
MOS对概念的解释
Generally patches for Clusterware, Grid Infrastructure and/or the Database are catagorized into the following:
- Patchsets
- Patchset Updates (PSUs)
- Critical Patch Updates (CPUs)
- Bundle Patches
- Interim (one-off) Patches
Patchsets Q&A
What's a Patchset?
Compared to all other patch types, a Patchset is released the least frequently. It contains fixes for most known issues for the release and potentially also introduces new features. A patchset is cumulative and when applied it changes the fourth digit of the product release banner - for example, 10.2.0.5 is 4th patch set for 10.2, and 11.2.0.2 is the 1st patch set for 11.2.
A patchset must be installed via the Oracle Universal Installer (OUI) and is generally considered an "upgrade".
Prior to 11gR2, a base release had to be installed before a patchset could be applied. For example, to install 10.2.0.5 on Linux, the 10.2.0.1 base release has to be installed first and then upgraded to 10.2.0.5.
Prior to 11gR2, the same patchset download is used to patch the Clusterware, ASM and Database homes. For example, Patch 8202632 is the 10.2.0.5 patchset, this same patch (Patch 8202632) will be used to patch the 10.2.0.x Clusterware, 10.2.0.x ASM and 10.2.0.x Database to 10.2.0.5.
Starting with 11gR2, patchset releases are now full releases and no longer require a "base" release, e.g. 11.2.0.2 can be installed directly without having to install 11.2.0.1 first.
Prior to 11gR2 - even though the CRS and RDBMS base releases were provided on separate media (downloadable zip file or separate DVD/CD) - the patchsets for both products were delivered as one i.e. the same patchset could be applied to the CRS as well as the RDBMS home.
Starting with 11gR2 the patchsets for Grid Infrastructure and RDBMS are delivered separately (as they are full releases).
Clusterware patchsets can be applied in a rolling fashion, while database patchsets cannot. For example, you can rolling upgrade clusterware to 11.2.0.2, but you have to shutdown database on all nodes to upgrade to database 11.2.0.2.
Patch Set Updates (PSUs) Q&A
What's a Patch Set Update (PSU)?
As the name implies PSUs are patches that are applied on top of a given patchset release. They are released on a quarterly basis and contain fixes for known critical issues for the patchset. PSUs are subject to thorough testing and do not include changes that would alter the functionality of the software. With this in mind, PSUs are designed to provide "low risk" and "high value" allowing for customers to more easily adopt proactive patching strategies. Consider the following PSU facts:
- All PSUs are installed via "opatch" and are not considered an "upgrade".
- Database PSUs always contain the CPU for the respective quarter that the PSU is released in. PSUs and CPUs are NOT compatible meaning if you apply the 11.2.0.2.2 Database PSU and then want to apply the 11.2.0.2 July CPU this would result in the rollback of the 11.2.0.2.2 Database PSU. That said, once a PSU patching strategy is adopted it must be maintained.
- Independent PSUs are released for both the Database and Clusterware or Grid Infrastructure installations.
- Clusterware PSUs (pre-11.2) are refered to as CRS PSUs
- Grid Infrastructure PSUs are refered to as GI PSUs
- GI PSUs do contain the Database PSU for the corresponding release, e.g. 11.2.0.2.3 GI PSU contains the 11.2.0.2.3 Database PSU
- Database PSUs hold true to their name
- Both Clusterware/Grid Infrastructure and Database PSU patches are cumulative. Clusterware PSU refers to CRS PSU for pre-11gR2 and GI PSU for 11gR2.
- GI PSUs are always cumulative meaning that you can apply higher version GI PSU directly without having to apply a lower version one first. For example, the 11.2.0.2.2 GI PSU can be applied to a 11.2.0.2 home without having to apply GI PSU 11.2.0.2.1 first.
- Database PSUs can be subject to overlay PSU packaging. In these cases, the PSUs are still cumulative, but a higher PSU may require a lower PSU to be applied first; for example, to apply database PSU 10.2.0.4.7, you must apply database PSU 10.2.0.4.4 first. If a previous PSU is a prerequisite to a later PSU the requirement will be clearly documented in the PSU readme.
- For more information on PSUs please review Document 854428.1.
What's the PSU release schedule?
Generally speaking PSU are released on quarterly basis for both Clusterware/Grid Infrastructure and Database. There's cases where a Clusterware PSUs is not released for corresponding Database PSU. For example, there's database PSU 10.2.0.5.4 but no CRS PSU 10.2.0.5.4.
Will the 5th digit of the version be changed after PSU is applied?
A PSU will not physically update the 5th-digit of the release information, the updates to the 5th digit in the release are for Documentation purposes only. So the third GI PSU that was released for 11.2.0.2 will have a documentation version of 11.2.0.2.3. You will NOT see this change reflected in the actual software version if you query it from the inventory, clusterware or database.
What's included in a GI PSU ?
Unlike other Grid Infrastructure patches (discussed later), 11gR2 GI PSUs contains both GI PSU and Database PSU (YES, both GI and DB PSU) for a particular quarter. For example, 11.2.0.2.2 GI PSU contains both the 11.2.0.2.2 GI PSU and the 11.2.0.2.2 Database PSU.
You are able to take note of this when you extract a GI PSU, you will see 2 directories (named with the Patch number) one for the GI PSU and one for the RDBMS PSU.
How do I find out whether a bug is fixed in a Clusterware or Grid Infrastructure PSU ? To find out, check the patch readme and the following notes:
Document 405820.1 - 10.2 CRS PSU Known issues
Document 810663.1 - 11.1 CRS PSU Known issues
Document 1082394.1 - 11.2.0.1 GI PSU Known issues
Document 1272288.1 - 11.2.0.2 GI PSU Known Issues
Document 1508641.1 - 11.2.0.3.x Grid Infrastructure Bundle/PSU Known Issues
Once the GI PSU is applied, "opatch lsinventory" will show that both GI PSU and DB PSU are applied, i.e.:
Interim patches (2) :
Patch 9654983 : applied on Thu Feb 02 20:36:47 PST 2012
Patch 9655006 : applied on Thu Feb 02 20:35:53 PST 2012
And "opatch lsinventory -bugs_fixed" will list each individual bugs that have been fixed by all installed patches, i.e.:
List of Bugs fixed by Installed Patches:
Bug Fixed by Installed at Description
Patch
--- -------- ------------ -----------
7519406 9654983 Thu Feb 02 20:36:47 PST 2012 'J000' TRACE FILE REGARDING GATHER_STATS_JOB INTER
..
9783609 9655006 Thu Feb 02 20:35:53 PST 2012 CRS 11.2.0.1.0 Bundle
Can a Database PSU be applied to a clusterware home?
No, only CRS PSUs, GI PSUs or other Clusterware/GI patches can be applied to a Clusterware/GI home.
Critical Patch Updates (CPUs) Q&A
What are Critical Patch Updates (CPUs)?
CPU Patches are collection of high-priority fixes for security related issues and are only applicable to the Database Home (and pre-11.2 ASM Home(s)) . CPUs are released quarterly on the same cycle as PSUs and are cumulative with respect to prior security fixes but may contain other fixes in order to address patch conflicts with non-security patches. PSUs always contain the CPU for that respective quarter. PSUs and CPUs are NOT compatible meaning if you apply the 11.2.0.2.2 Database PSU and then want to apply the 11.2.0.2 July CPU this would result in the rollback of the 11.2.0.2.2 Database PSU. That said, once a PSU patching strategy is adopted it must be maintained. PSU patching is preferred over CPU Patching.
Bundle Patches Q&A
What's the difference between a Clusterware/Grid Infrastructure bundle patch and a PSU?
A Clusterware or Grid Infrastructure (GI) patch can be in the form of bundle or Patchset Update (PSU). The biggest difference between a GI/Clusterware bundle and a PSU is that PSUs are bound to a quarterly release schedule while a bundle may be released at any time throughout the course of a given quarter. If a GI/Clusterware bundle is released in a given quarter, the fixes in that bundle will be included in the PSU that will be released for that quarter. This concept allows for development to provide critical bug fixes in a more granular timeline if necessary.
Interim (one-off) Patch Q&A
What's an interim patch (one-off patch)?
An interim patch contains fixes for one or in some cases several bugs (merge patch).
Clusterware interim patches are rare, they usually are build on top of the latest PSU (at the time) and include the entire PSU they were built on.
The same does not hold true for database interim patches, they usually do not include a PSU.
An interim clusterware patch on top of a PSU includes the PSU, for example, 11.2.0.2.2 patch 12647618 includes 11.2.0.2 GI PSU2 (11.2.0.2.2). But the same is not true for database interim patch, for example, 11.2.0.2.2 databasepatch 11890804 can only be applied on top of a 11.2.0.2.2 database home.
General Patch Q&A
What's the difference between Clusterware/Grid Infrastructure patches and Database patches?
Generally speaking Clusterware/Grid Infrastructure patches modify files that belong to the Clusterware or Grid Infrastructure product, while Database patches change files that belong to the database product. As they apply to different sets of files, they do not conflict with each other.
