Critical Patch Update July 2011 Released

2011年7月的CPU在19日发布了,Database相关的PSU/CPU包括:

11.2.0.2:CPU Patch 12419321, or DB PSU Patch 12419331, or GI PSU Patch 12419353, or Exadata BP9 Patch 12681774

11.2.0.1:CPU Patch 12419278, or DB PSU Patch 12419378, or Exadata BP11 Patch 12608545

11.1.0.7: CPU Patch 12419265, or PSU Patch 12419384

10.2.0.5:CPU Patch 12419258, or PSU Patch 12419392

10.2.0.4:CPU Patch 12419249, or PSU Patch 12419397

Oracle Database Patch Set Update (PSU)

Oracle Database UNIX Advisory Number Comments
11.2.0.2.3 Database PSU Patch 12419331 See Section 3.1.3.2, “Oracle Database 11.2.0.2”
11.2.0.2.3 Grid Infrastructure PSU Patch 12419353 See Section 3.1.3.2, “Oracle Database 11.2.0.2” Includes CPUJul2011 and 11.2.0.2.3 Database PSU
11.2.0.2 BP9 for Exadata Patch 12681774 See Section 3.1.3.2, “Oracle Database 11.2.0.2” Includes CPUJul2011 and 11.2.0.2.3 Database and Grid Infrastructure PSU fixes for Exadata
11.2.0.1.6 Database PSU Patch 12419378 See Section 3.1.3.3, “Oracle Database 11.2.0.1”
11.2.0.1 BP11 for Exadata Patch 12608545 See Section 3.1.3.3, “Oracle Database 11.2.0.1” Includes CPUJul2011 and 11.2.0.1.6 PSU fixes for Exadata
11.2.0.1.2 Grid Infrastructure Patch 9655006 Released July 2010
11.1.0.7.8 Database PSU Patch 12419384 See Section 3.1.3.4, “Oracle Database 11.1.0.7”
11.1.0.7.7 CRS PSU Patch 11724953 Released April 2011
10.2.0.5.4 Database PSU Patch 12419392 See Section 3.1.3.5, “Oracle Database 10.2.0.5”
10.2.0.5.2 CRS PSU Patch 9952245 Released January 2011
10.2.0.4.9 Database PSU Patch 12419397 See Section 3.1.3.6, “Oracle Database 10.2.0.4” Overlay PSU
10.2.0.4.4 Database PSU Patch 9352164 Released April 2010 Base PSU for 10.2.0.4.9
10.2.0.4.4 CRS PSU Patch 9294403 Released April 2010

具体见<Patch Set Update and Critical Patch Update July 2011 Availability Document [ID 1323616.1]>

了解Oracle数据库的版本号

Oracle数据库的发行版本号(release number)一般由五位数字组成,那么这些数字分别代表什么含义呢?
oracle_release_number

Major Database Release Number

第一位阿拉伯数字是我们最常提到的一个大版本标识,它代表了数据库主要发行版本号;譬如我们说的10g不管是R1还是R2,其版本号的第一位总是10;不同Major release Number之间预示着存在功能上的巨大差别,例如在11g中加入了许多10g上永远不会有的新特性。新的major release number表明这是崭新一代的产品。

Database Maintenance Release Number

第二位阿拉伯数字代表数据库维护版本发行号,也就是我们常说的R1或者R2。已有的Maintenance Release Number包括:8.1(比较特殊)、9.1、9.2、10.1、10.2和11.1、11.2。从9i开始每一个大版本都有2个release,一般来说R1总是显得不那么稳定(至少11g之前是这样),通过在R1中引入大量特性后发行并根据用户实际使用情况不断修正Bug,到R2发行时R1中引入的新特性已经日渐成熟,当然按照Oracle的风格在R2中还会引入部分特性,一些特性甚至可能是颠覆性的(例如10.2.0.2中引入mutex保护的Cursor pin)。另外值得一提的是R1极不稳定这个铁律似乎在11g中被打破了,11gR1的使用率非常之高,这是9.1或10.1所不能想象的。

Application Server Release Number

第三位阿拉伯数字代表了Oracle Application Server (OracleAS)的发行版本号;对于Oracle database软件而言这一位总是为0

Component-Specific Release Number

第四位阿拉伯数字代表了某个组件的发行版本号。这里说的组件是指我们在使用DBCA创建数据库是选择安装的Component,例如Oracle OLAP、Label Security等(如果是手动创建数据库,那么必然运行了安装组件的脚本,一般位于$ORACLE_HOME/rdbms/admin目录下)取决于数据库上所打过的Component Patch set补丁集或interim release临时版本,同一个数据库中不同组件可能存在不同的组件版本号。实际使用中该组件发行版本号一般被我们用来指代数据库软件或者某个数据库所打过的Patch set补丁集,Patch set补丁集一般都是些大家伙(1-2GB不稀奇)。在给数据库软件打上Patch set后我们需要给已经存在的数据库升级组件版本,通俗地说是给数据库升级数据字典,这样数据库内的组件版本一般是一致的,如我将一个10.2.0.1的数据库升级到10.2.0.4,那么这个数据库里的组件版本也会是10.2.0.4(不排除说你为某个组件打了特殊的Patch后造成这个组件的版本独树一帜,当然这很少见,也不推荐)。我们可以通过查询DBA_SERVER_REGISTRY视图来了解数据库中的组件版本情况:

desc dba_server_registry;
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 COMP_ID                                   NOT NULL VARCHAR2(30)
 COMP_NAME                                          VARCHAR2(255)
 VERSION                                            VARCHAR2(30)
 STATUS                                             VARCHAR2(11)
 MODIFIED                                           VARCHAR2(20)
 CONTROL                                   NOT NULL VARCHAR2(30)
 SCHEMA                                    NOT NULL VARCHAR2(30)
 PROCEDURE                                          VARCHAR2(61)
 STARTUP                                            VARCHAR2(8)
 PARENT_ID                                          VARCHAR2(30)
 OTHER_SCHEMAS                                      VARCHAR2(4000)

col comp_name for a60

select comp_name,version from dba_server_registry

COMP_NAME                                                    VERSION
------------------------------------------------------------ ------------------------------
Spatial                                                      10.2.0.4.0
Oracle interMedia                                            10.2.0.4.0
OLAP Catalog                                                 10.2.0.4.0
Oracle Enterprise Manager                                    10.2.0.4.0
Oracle XML Database                                          10.2.0.4.0
Oracle Text                                                  10.2.0.4.0
Oracle Expression Filter                                     10.2.0.4.0
Oracle Rules Manager                                         10.2.0.4.0
Oracle Workspace Manager                                     10.2.0.4.3
Oracle Data Mining                                           10.2.0.4.0
Oracle Database Catalog Views                                10.2.0.4.0
Oracle Database Packages and Types                           10.2.0.4.0
JServer JAVA Virtual Machine                                 10.2.0.4.0
Oracle XDK                                                   10.2.0.4.0
Oracle Database Java Packages                                10.2.0.4.0
OLAP Analytic Workspace                                      10.2.0.4.0
Oracle OLAP API                                              10.2.0.4.0

Platform-Specific Release Number

第五位阿拉伯数字代表了平台相关发行版本号。通常意义上该位数字受到另一种补丁(不是Patch set)的影响。在10g以后Oracle引入了在某个特定的补丁集的基础上发行的补丁集的更新(PSU-patch set update),用中文说起来十分拗口;通过PSU的发行,Oracle可以针对某个特定的补丁集版本上发生的Bug集中性地修复,例如10.2.0.4是一个10g使用十分广泛的版本,如果在10.2.0.4上发现了Bug那么就可以将fix合并到PSU中。一般来说PSU会每年的1、4、7、10月份release,最近的一次PSU释放是在2011年的4月,包含了10.2.0.4的第8个PSU也就是10.2.0.4.8。注意Oracle只会为某个大版本上的几个final release制作PSU补丁,目前在10g上保持PSU发布的版本是10.2.0.4和10.2.0.5,而对于10.2.0.3则不再有PSU的支持。可以通过查询registry$history表了解数据库(DB ,not Database Software)的PSU信息:


SQL> desc registry$history;
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 ACTION_TIME                                        TIMESTAMP(6)
 ACTION                                             VARCHAR2(30)
 NAMESPACE                                          VARCHAR2(30)
 VERSION                                            VARCHAR2(30)
 ID                                                 NUMBER
 COMMENTS                                           VARCHAR2(255)
 BUNDLE_SERIES                                      VARCHAR2(30)


SQL> select * from registry$history;

ACTION_TIME
---------------------------------------------------------------------------
ACTION                         NAMESPACE
------------------------------ ------------------------------
VERSION                                ID
------------------------------ ----------
COMMENTS
--------------------------------------------------------------------------------
BUNDLE_SERIES
------------------------------
17-MAY-11 10.42.32.533510 PM
APPLY                          SERVER
10.2.0.4                                4
PSU 10.2.0.4.4
PSU

以上可以看到示例数据库打过PSU 10.2.0.4.4,还可以通过opatch lsinventory找出数据库软件(Database Software,not DB)打过的Patch Number,一般包含大量Bug修复的Interim patches可能是PSU(也可能是CPU),如Patch 9352164即对应为PSU 10.2.0.4.4。

我们还可以通过查询V$VERSION来了解当前数据库软件(注意是Database Software,而不是DB)的版本,该视图中还包含PL/SQL引擎和TNS协议的版本:

SQL> startup nomount;

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production

Oracle Patch Set Update and Critical Patch Update April 2011 Released

2011 April的Oracle Patch set Update与Critical Patch Update发布了,本次发布包括了对Oracle Database Server, Oracle Fusion Middleware, Oracle Enterprise Manager Grid Control, Oracle E-Business Suite and Supply Chain Products Suite, Oracle PeopleSoft Enterprise, and Oracle JDEdwards EntepriseOne, Oracle Siebel CRM, Oracle Industry Applications, Oracle Sun products suite, and Oracle OpenOffice Suite等多个产品的补丁更新。

其中与数据库相关的主要有补丁集更新和紧急补丁更新如下:

  1. Database 11.2.0.2上的CPU Patch 11724984, or PSU Patch 11724916
  2. Database 11.2.0.1上的CPU Patch 11724991, or PSU Patch 11724930
  3. Database 11.1.0.7上的CPU Patch 11724999, or PSU Patch 11724936
  4. Database 10.2.0.5上的CPU Patch 11725006, or PSU Patch 11724962
  5. Database 10.2.0.4上的CPU Patch 11725015, or PSU Patch 11724977

January 2011 Patch set Update发布

January 2011补丁集更新在大约2周前发布了,与Oracle Database相关的psu分别为10.2.0.5.2,10.2.0.4.7(REQUIRES PRE-REQUISITE 10.2.0.4.4),11.2.0.1.4,11.2.0.2.1.

Patch your 10g Oracle database to PSU 10.2.0.4.5

有人会问不是10.2.0.5已经release了吗?为什么还要装10.2.0.4版本的PSU(Patch set Update)呢?做出这样的决定很大程度上是处于无奈的,毕竟Oracle的Bug有那么多,百年大计安全第一;10.2.0.4的稳定性在10g的范畴内可说是有目共睹的,而多达5个版本的PSU也进一步保证了能在10.2.0.4基础上不做大的变更,只修复合并一些小的bug。继10.2.0.4.4后(10.2.0.4.4有CRS和DB 2个版本)在July 13.2010推出了10.2.0.4.5 PSU,该PSU只有1.3MB大小,合并了:9714832, 9713537, 9678695, 9655017, 9173248, 8309642, 9678697, 9678690,9573054, 9654991等多个patch;因为10.2.0.4.5 PSU需要在10.2.0.4.4的基础上才能apply,所以我们需要首先应用10.2.0.4.4 PSU补丁。

PSU 10.2.0.4.5 的安装步骤:

1.如果你是全新的fresh安装的话,需要安装数据库Server软件10.2.0.1,之后升级到10.2.0.4;此外因为是fresh installation,还不存在数据库,所以只要是以custom database形式创建的新库都可以skip Post installation的步骤(也就是说不用执行脚本),而以DBCA中General, Data Warehouse, Transaction Processing形式创建新库需要执行catbundle.sql升级脚本(Loading Modified SQL Files into the Database)。
2.安装Oracle Opatch软件版本11.2.0.0,对应的patch号为6880880,使用10.2.0.4默认的Opatch软件在prereq和apply阶段会遇到Bug,并出现以下问题:

Invoking prereq "checkconflictagainstohwithdetail"
Prereq "checkConflictAgainstOHWithDetail" not executed
Unable to create Patch Object.
Exception occured : Patch ID is null.

Invoking prereq "checkconflictagainstohwithdetail"
The location ".//README.html" is not a directory or a valid patch zip file.
Prereq "checkConflictAgainstOHWithDetail" not executed
PrereqSession failed: Invalid patch location.

可以从MOS下载到p6880880_112000_$PLATFORM.zip的介质,解压后将OPatch部分的内容覆盖到原$ORACLE_HOME/OPatch目录:
[Read more…]

Applying Database PSU 10.2.0.4.6

Last week Patch set update 10.2.0.4.6 has been released, this psu includes “All fixes in the 10.2.0.4.5 overlay patch” and “New fixes which are included in the Critical Patch Update for October 2010 (CPUOCT2010)”.
Now I am trying to apply it on my 10.2.0.4.5 instance!
[Read more…]

Oct 12: Patch Set Update Released

一周不关注MOS就变得落伍了!在上周的Oct 12,Oracle分别发布了10.2.0.4 Patch Set的PSU 6(10.2.0.4.6)和10.2.0.5的第一个PSU。
10.2.0.4.6补丁更新集包含了所有10.2.0.4.5中的fix,此外添加了CPU(Critical Patch Update) For October 2010 (CPUOCT2010);而10.2.0.5.1则包含了Critical Patch Update for October 2010 (CPUOCT2010),并修复了以下bug:

Bug:6402302  Streams table and schema rules not consistently applied for DDL on view/synonym
Bug:7519406  Larger trace than needed for ORA-8103 under kteincnt1
Bug:8544696  Table segment growth (blocks are not reused) with ASSM
Bug:8546356  ORA-8102/ORA-1499/OERI[kdsgrp1] Composite Partitioned Index corruption after rebuild ONLINE in RAC
Bug:8664189  OERI [kdiss_uncompress: buffer length] on key compressed index
Bug:9711859  ORA-600 [ktsptrn_fix-extmap] during extent allocation caused by bug 8198906
Bug:9713537  Message file change for ORA-600
Bug:9714832  Message file change for ORA-7445
  • 10.2.0.4.6 PSU Note:https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=9952234.8
  • 10.2.0.4.6 Known Issues:https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1230884.1
  • 10.2.0.5.1 PSU Note:https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=9952230.8
  • 10.2.0.5.1 Known Issues:https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1230855.1

同时10.2.0.5已经被confirm成为10g release 2的Final Patch Set:

10.2.0.5.0 – Patch Set #4, List of fixes: Note 1088172.1 ==> Last Patch Set
10.2.0.5.1 – Patch Set Update (PSU 1): Note 9952230.8

记以录之。

7月最新发布10.2.0.4.5 Patch Set Update

同11.2.0.1.2 psu同时发布的还有10.2.0.4.5 psu,值得注意的是这2个psu都包括了针对ora-600/7445错误出现时信息显示的原因和调用(cause/action)。

附该psu的readme note:

Released: July 13, 2010

This document is accurate at the time of release. For any changes and additional information regarding PSU 10.2.0.4.5, see these related documents that are available at My Oracle Support (http://support.oracle.com/):

  • Note 854428.1 Patch Set Updates for Oracle Products

  • Note 1089052.1 Oracle Database Patch Set Update 10.2.0.4.5 Known Issues

Patch Set Update 10.2.0.4.5 introduces new overlay PSU packaging. This new packaging reduces, and may eliminate altogether, the number of new overlay patches required to install the PSU. There are changes in both the patch application and patch conflict resolution. Oracle recommends that you read this entire readme before installing the patch.

This document includes the following sections:

1 Patch Information

Patch Set Update PSU 10.2.0.4.5 is an overlay PSU whose base PSU is 10.2.0.4.4. This patch can only be applied in an Oracle home for which PSU 10.2.0.4.4 has already been installed.

PSU 10.2.0.4.5 contains the bug fixes listed in Section 5, “Bugs Fixed by This Patch”.

Table 1 describes installation types and security content. For each installation type, it indicates the most recent PSU patch to include new security fixes that are pertinent to that installation type. If there are no security fixes to be applied to an installation type, then “None” is indicated. If a specific PSU is listed, then apply that or any later PSU patch to be current with security fixes.

Table 1 Installation Types and Security Content

Installation Type Latest PSU with Security Fixes

Server homes

PSU 10.2.0.4.5

Client-Only Installations

None

Instant Client Installations

None

(The Instant Client installation is not the same as the client-only Installation. For additional information about Instant Client installations, see Oracle Database Concepts.)

ASM (Automatic Storage Management) homes

PSU 10.2.0.4.1

CRS (Cluster Ready Services) homes

None


2 Patch Installation and Deinstallation

This section includes the following sections:

2.1 Platforms for PSU 10.2.0.4.5

For a list of platforms that are supported in this Patch Set Update, see My Oracle Support Note 1060989.1 Critical Patch Update July 2010 Patch Availability Document for Oracle Products.


2.2 OPatch Utility Information

You must use the OPatch 10.2 version 10.2.0.4.8 or later to apply this patch. Oracle recommends that you use the latest released OPatch 10.2, which is available for download from My Oracle Support patch 6880880 by selecting the 10.2.0.0.0 release.

For information about OPatch documentation, including any known issues, see My Oracle Support Note 293369.1 OPatch documentation list.


2.3 Patch Installation

These instructions are for both non-RAC environments and RAC environments.

2.3.1 Patch Pre-Installation Instructions

Before you install PSU 10.2.0.4.5, perform the following actions to check the environment and to detect and resolve any one-off patch conflicts.


2.3.1.1 Environment Checks
  1. Ensure that the $PATH definition has the following executables: make, ar, ld, and nm.

    The location of these executables depends on your operating system. On many operating systems, they are located in /usr/ccs/bin, in which case you can set your PATH definition as follows:

    export PATH=$PATH:/usr/ccs/bin  


2.3.1.2 Prerequisite 10.2.0.4.4 Base Patch Set Update Patch

PSU 10.2.0.4.5 is packaged as an overlay patch which requires that the 10.2.0.4.4 Patch Set Update has been installed. Check that PSU 10.2.0.4.4 is installed by ensuring that the OPatch inventory includes the PSU 10.2.0.4.4 tracking bug (9352164).

If the PSU 10.2.0.4.4 tracking bug (9352164) is not present in the OPatch inventory, do the following to minimize your downtime:

  1. Download PSU 10.2.0.4.4 patch 9352164 and review its readme instructions.

  2. Perform the One-off Patch Conflict Detection and Resolution for both PSU 10.2.0.4.4 and PSU 10.2.0.4.5. That is, you do not need to have PSU 10.2.0.4.4 installed to do the conflict detection on PSU 10.2.0.4.5. If there are conflicts, you only need to file one Support Request to get them resolved.

  3. After conflicts are resolved, install PSU 10.2.0.4.4, followed by PSU 10.2.0.4.5.

  4. Install any conflict resolution overlay patches.

  5. Perform the PSU 10.2.0.4.4 Post-Installation Instructions, followed by the PSU 10.2.0.4.5 Post-Installation Instructions.


2.3.1.3 One-off Patch Conflict Detection and Resolution

For an introduction to the PSU one-off patch concepts, see “Patch Set Updates Patch Conflict Resolution” in My Oracle Support Note 854428.1 Patch Set Updates for Oracle Products.

The fastest and easiest way to determine whether you have one-off patches in the Oracle home that conflict with the PSU, and to get the necessary conflict resolution patches, is to use the Patch Recommendations and Patch Plans features on the Patches & Updates tab in My Oracle Support. These features work in conjunction with the My Oracle Support Configuration Manager. Recorded training sessions on these features can be found in Note 603505.1.

However, if you are not using My Oracle Support Patch Plans, follow these steps:

  1. Determine whether any currently installed one-off patches conflict with the PSU patch as follows:

    unzip p9654991_102044_<platform>.zip  opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ./9654991  
  2. The report will indicate the patches that conflict with PSU 10.2.0.4.5. File a service request (SR) requesting a new merge patch that will replace PSU 10.2.0.4.5.


2.3.2 Patch Installation Instructions

Follow these steps:

  1. If you are using a Data Guard Physical Standby database, you must first install this patch on the primary database before installing the patch on the physical standby database. It is not supported to install this patch on the physical standby database before installing the patch on the primary database. For more information, see My Oracle Support Note 278641.1.

  2. If you are patching an ASM instance, shut down all Oracle Database instances that use this ASM instance. (To see which Oracle Database instances are connected to this ASM instance, query the V$ASM_CLIENT view.)

  3. Do one of the following, depending on whether this is a RAC environment:

    • If this is a RAC environment, choose one of the patch installation methods provided by OPatch (rolling, all node, or minimum downtime), and shutdown instances and listeners as appropriate for the installation method selected.

      This PSU patch is rolling RAC installable. Refer to My Oracle Support Note 244241.1 Rolling Patch – OPatch Support for RAC.

    • If this is not a RAC environment, shut down all instances and listeners associated with the Oracle home that you are updating. For more information, see Oracle Database Administrator’s Guide.

  4. Set your current directory to the directory where the patch is located and then run the OPatch utility by entering the following commands:

    unzip p9654991_102044_<platform>.zip  cd 9654991  opatch apply  
  5. If there are errors, refer to Section 3, “Known Issues”.


2.3.3 Post Installation Instructions

Do not perform the operations in this section on ASM instances. However, if you shut down ASM as part of applying the PSU, you must start ASM instances before you can perform any of the actions in this section on any database instances.

After installing the patch, perform the following actions:

  1. Load modified SQL files into the database, as explained in Section 2.3.3.1.

  2. Recompile views in the database, if necessary, as explained in Section 2.3.3.2.

2.3.3.1 Loading Modified SQL Files into the Database

The following steps load modified SQL files into the database. For a RAC environment, perform these steps on only one node.

  1. 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 opsu apply  SQL> QUIT  

    The catbundle.sql execution is reflected in the dba_registry_history view by a row associated with bundle series OPSU.

    For information about the catbundle.sql script, see My Oracle Support Note 605795.1 Introduction to Oracle Database catbundle.sql.

  2. Check the following log files in $ORACLE_HOME/cfgtoollogs/catbundle for any errors:

    catbundle_OPSU_<database SID>_APPLY_<TIMESTAMP>.log  catbundle_OPSU_<database SID>_GENERATE_<TIMESTAMP>.log  

    where TIMESTAMP is of the form YYYYMMMDD_HH_MM_SS. If there are errors, refer to Section 3, “Known Issues”.


2.3.3.2 Recompiling Views in the Database

Recompiling views in the database is a one-time action that is required to complete the installation of CPU fixes that were initially released in January, 2008. It requires that the database be in upgrade mode, so this step is not rolling RAC installable. You may defer this step to a later downtime. If you do this, your system will continue to work; however, the installation of the January 2008 CPU fixes will not be complete until the view recompilation is completed.

Skip this section if you have recompiled views for this database during the installation of a previous PSU or CPU.

The time required to recompile the views and related objects depends on the total number of objects and on your system configuration. In one internal Oracle test with approximately 2000 views and 4000 objects, the total execution time for view_recompile_jan2008cpu.sql and utlrp.sql was about 30 minutes.

If you want to check whether view recompilation has already been performed for the database, execute the following statement:

SELECT * FROM registry$history where ID = '6452863';  

If the view recompilation has been performed, this statement returns one or more rows. If the view recompilation has not been performed, this statement returns no rows.

The following steps recompile the views in the database. For a RAC environment, perform these steps on only one node.

  1. Run the pre-check script (so named because it was initially released in CPUJan2008), which reports the maximum number of views and objects that may be recompiled:

    cd $ORACLE_HOME/cpu/view_recompile  sqlplus /nolog  SQL> CONNECT / AS SYSDBA  SQL> @recompile_precheck_jan2008cpu.sql  SQL> QUIT  

    The purpose of this step is to help you determine whether view recompilation should be done at the same time as the PSU install, or scheduled later.

  2. If the database is not in a RAC environment, perform this step and skip the next step. (If the database is in a RAC environment, go to the next step.)

    Run the view recompilation script. Note that this script is run with the database in upgrade mode, which restricts connections as SYSDBA.

    cd $ORACLE_HOME/cpu/view_recompile  sqlplus /nolog  SQL> CONNECT / AS SYSDBA  SQL> SHUTDOWN IMMEDIATE  SQL> STARTUP UPGRADE  SQL> @view_recompile_jan2008cpu.sql  SQL> SHUTDOWN;  SQL> STARTUP;  SQL> QUIT  
  3. If the database is in a RAC environment, run the view recompilation script as follows. Note that this script is run with the database in upgrade mode, which restricts connections as SYSDBA. Stop all instances except the one where the view recompilation is being executed.

    cd $ORACLE_HOME/cpu/view_recompile  sqlplus /nolog  SQL> CONNECT / AS SYSDBA  SQL> STARTUP NOMOUNT  SQL> ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=spfile;  SQL> SHUTDOWN  SQL> STARTUP UPGRADE  SQL> @view_recompile_jan2008cpu.sql  SQL> SHUTDOWN;  SQL> STARTUP NOMOUNT;    Set the CLUSTER_DATABASE initialization parameter to TRUE:    SQL> ALTER SYSTEM SET CLUSTER_DATABASE=TRUE SCOPE=spfile;    Restart the database:    SQL> QUIT  cd $CRS_HOME/bin  srvctl start database -d <database-name>  
  4. Check the log file for any errors. The log file is in the current directory and is named: vcomp_<sid>_<timestamp>.log

  5. If any invalid objects were reported, run the utlrp.sql script as follows:

    cd $ORACLE_HOME/rdbms/admin  sqlplus /nolog  SQL> CONNECT / AS SYSDBA  SQL> @utlrp.sql  

    Then, manually recompile any invalid objects. For example:

    SQL> alter package schemaname.packagename compile;  


2.3.4 Post Installation Instructions for Databases Created or Upgraded after Installation of PSU 10.2.0.4.5 in the Oracle Home

These instructions are for a database that is created or upgraded after the installation of PSU 10.2.0.4.5.

You must execute the steps in Section 2.3.3.1, “Loading Modified SQL Files into the Database” for any new database only if it was created by any of the following methods:

  • Using DBCA (Database Configuration Assistant) to select a sample database (General, Data Warehouse, Transaction Processing)

  • Using a script that was created by DBCA that creates a database from a sample database

  • Cloning a database that was created by either of the two preceding methods, and if the steps in Section 2.3.3.1, “Loading Modified SQL Files into the Database” were not executed after PSU 10.2.0.4.5 was applied

Upgraded databases require that you perform the steps in Section 2.3.3.2, “Recompiling Views in the Database” if these steps have not previously been performed; otherwise, no post-installation steps need to be performed.


2.4 Patch Deinstallation

These instructions are for both Non-RAC environments and RAC environments.

2.4.1 Patch Deinstallation Instructions for a Non-RAC Environment

Follow these steps:

  1. Verify that an $ORACLE_HOME/rdbms/admin/catbundle_OPSU_<database SID>_ROLLBACK.sql file exists for each database associated with this ORACLE_HOME. If this is not the case, you must execute the steps in Section 2.3.3.1, “Loading Modified SQL Files into the Database” against the database before deinstalling the PSU.

  2. Shut down all instances and listeners associated with the Oracle home that you are updating. For more information, see Oracle Database Administrator’s Guide.

  3. Run the OPatch utility specifying the rollback argument as follows.

    opatch rollback -id 9654991  

    After the rollback command completes, PSU 10.2.0.4.5 is deinstalled, but PSU 10.2.0.4.4 and any of its other overlay patches remain installed in the Oracle home.

  4. If there are errors, refer to Section 3, “Known Issues”.


2.4.2 Post Deinstallation Instructions for a Non-RAC Environment

Follow these steps:

  1. Start all database instances running from the Oracle home. (For more information, see Oracle Database Administrator’s Guide.)

  2. For each database instance running out of the ORACLE_HOME, connect to the database using SQL*Plus as SYSDBA and run the rollback script as follows:

    cd $ORACLE_HOME/rdbms/admin  sqlplus /nolog  SQL> CONNECT / AS SYSDBA  SQL> STARTUP  SQL> @catbundle_OPSU_<database SID>_ROLLBACK.sql  SQL> QUIT  

    In a RAC environment, the name of the rollback script will have the format catbundle_OPSU_<database SID PREFIX>_ROLLBACK.sql.

  3. Check the log file for any errors. The log file is found in $ORACLE_HOME/cfgtoollogs/catbundle and is named catbundle_OPSU_<database SID>_ROLLBACK_<TIMESTAMP>.log where TIMESTAMP is of the form YYYYMMMDD_HH_MM_SS. If there are errors, refer to Section 3, “Known Issues”.


2.4.3 Patch Deinstallation Instructions for a RAC Environment

Follow these steps for each node in the cluster, one node at a time:

  1. Shut down the instance on the node. (Shut down all RDBMS instances before any ASM instances.)

  2. Run the OPatch utility specifying the rollback argument as follows.

    opatch rollback -id 9654991  

    After the rollback command completes, PSU 10.2.0.4.5 is deinstalled, but PSU 10.2.0.4.4 and any of its other overlay patches remain installed in the Oracle home.

    If there are errors, refer to Section 3, “Known Issues”.

  3. Start the instance on the node. Depending on the type of home, enter the following commands or command.

    • For ASM homes:

      srvctl start listener  srvctl start asm  srvctl start instance  
    • For RDBMS (non-ASM) homes:

      srvctl start instance  


2.4.4 Post Deinstallation Instructions for a RAC Environment

Follow the instructions listed in Section Section 2.4.2, “Post Deinstallation Instructions for a Non-RAC Environment” only on the node for which the steps in Section 2.3.3.1, “Loading Modified SQL Files into the Database” were executed during the patch application.

All other instances can be started and accessed as usual while you are executing the deinstallation steps.


3 Known Issues

For information about OPatch issues, see My Oracle Support Note 293369.1 OPatch documentation list.

For issues documented after the release of this PSU, see My Oracle Support Note 1089052.1 Oracle Database Patch Set Update 10.2.0.4.5 Known Issues.

Other known issues are as follows.

Issue 1   

The following ignorable errors may be encountered while running the catbundle.sql script or its rollback script:

ORA-29809: cannot drop an operator with dependent objects  ORA-29931: specified association does not exist  ORA-29830: operator does not exist  ORA-00942: table or view does not exist  ORA-00955: name is already used by an existing object  ORA-01430: column being added already exists in table  ORA-01432: public synonym to be dropped does not exist  ORA-01434: private synonym to be dropped does not exist  ORA-01435: user does not exist  ORA-01917: user or role 'XDB' does not exist  ORA-01920: user name '<user-name>' conflicts with another user or role name  ORA-01921: role name '<role name>' conflicts with another user or role name  ORA-01952: system privileges not granted to 'WKSYS'  ORA-02303: cannot drop or replace a type with type or table dependents  ORA-02443: Cannot drop constraint - nonexistent constraint  ORA-04043: object <object-name> does not exist  ORA-29832: cannot drop or replace an indextype with dependent indexes  ORA-29844: duplicate operator name specified   ORA-14452: attempt to create, alter or drop an index on temporary table already in use  ORA-06512: at line <line number>. If this error follow any of above errors, then can be safely ignored.  ORA-01927: cannot REVOKE privileges you did not grant  
Issue 2   

The view recompilation pre-check script returns different results during subsequent runs (such as after the first time you ran it).

The results (the maximum number of views and objects that may be recompiled) may be more or less than reported in the previous running of the script. This is expected behavior, and is not a problem.

Issue 3   

If the view recompilation script has already been run, a message is displayed indicating that the script has already been applied.

This is not a problem, because as the instructions note, you do not need to run the script if it has already been run.


4 References

The following documents are references for this patch.

Note 293369.1 OPatch documentation list

Note 360870.1 Impact of Java Security Vulnerabilities on Oracle Products

Note 468959.1 Enterprise Manager Grid Control Known Issues

Note 9352164.8 Bug 9352164 – 10.2.0.4.4 Patch Set Update (PSU)


5 Bugs Fixed by This Patch

This patch includes the following bug fixes.


5.1 CPU Molecules

CPU molecules in PSU 10.2.0.4.5:

PSU 10.2.0.4.5 contains the following new PSU 10.2.0.4.5 molecules:

9678690 – DB-10.2.0.4-MOLECULE-043-CPUJUL2010

9678695 – DB-10.2.0.4-MOLECULE-044-CPUJUL2010

9678697 – DB-10.2.0.4-MOLECULE-045-CPUJUL2010


5.2 Bug Fixes

PSU 10.2.0.4.5 contains the following new fixes:

9573054 – ORA-07445 IN TIME MGR PROCESS ON RAC WHILE QUERYING AQ$_QUEUE_TABLE_AFFINITY

9713537 – ENHANCE CAUSE/ACTION FIELDS OF THE INTERNAL ERROR ORA-00600

9714832 – ENHANCE CAUSE/ACTION FIELDS OF THE INTERNAL ERROR ORA-07445

沪ICP备14014813号-2

沪公网安备 31010802001379号