分类目录归档：系统层级

系统层级、经验闲谈

ORA-20100 文件 通过 FND_FILE 创建失败解决方案

留下评论
克隆了一个EBS 11i的环境，提交客户同步请求的时候出现了错误提示是：
原因：由于 ORA-20100: 为 FND_FILE 创建文件 10034190.tmp 失败。
我的服务器中有2个ERP环境，参数APPSLPTMP指定为默认的/usr/tmp。然后， 在网上找了一些相关资料，说不同的环境APPSLPTMP和数据库的utl_file_dir参数不能指定相同的目录，于是做了修改，修改命令如下：
# mkdir -p /usr/opt/tmp       创建目录
# chmod -R a+rw /usr/opt  赋予该目录读写权限
# su – orauat                               切换致数据库用户
$ export APPSLPTMP=/usr/opt/tmp   修改环境变量
$ cd $ORACLE_HOME/dbs
$ vi init<SID>.ora                   编辑数据库初始化文件，修改参数：utl_file_dir
utl_file_dir = /usr/opt/tmp,……..<SID>_prod
并且重新启动的环境。在数据库执行函数：FND_FILE_OUT_LINE()提示成功。
这个错误很常见：

1.查看$APPLPTMP系统环境变量的值，一般是/usr/tmp，需要保证该文件夹是存在的;

2.查看utl_file_dir数据库参数，其第一个值也应该为/usr/tmp;
select* from v$parameter t whee t.name=’utl_file_dir’
3.查看该文件夹的权限，该文件夹必须为应用用户和数据库用户都具有读写权限;
4.通过exec FND_FILE.PUT_LINE(FND_FILE.LOG, ‘THIS IS A TEST’);进行测试;
5.如果仍然还有问题,请查看你的服务器上面是不是有多套ERP环境,如果有多个的话两个$APPLPTMP文件同时写会冲突当一台服务器上运行了多套环境时，不能使用/usr/tmp作为$APPLPTMP，须定义成各自的目录。且该目录须在数据库参数utl_file_dir中。
系统层级、经验闲谈

AUM 常用分析/诊断脚本 (文档 ID 1526122.1)

留下评论

AUM 常用分析/诊断脚本 (文档 ID 1526122.1)

Oracle Database – Enterprise Edition – 版本 10.1.0.5 到 11.1.0.6 [发行版 10.1 到 11.1]

本文档所含信息适用于所有平台

用途

本文旨在规范对用以诊断和分析 ORA-1555 错误的脚本的使用。本文适用于所有数据库管理员及 Oracle Support 分析人员。

要求

以下脚本可在 SQL*Plus 或 iSQL*Plus 中运行。很多脚本都要求拥有数据库的 DBA 权限。

单击 此处 [修订时间：2011 年 5 月 12 日] 下载本文中讨论的脚本。

配置

查看每个脚本的备注以判定对于特定配置/应用程序环境是否提示有所更改。

说明

对于以下脚本，需要使用能够访问 DBA* 和 V$ 表的数据库管理用户。默认情况下，这些脚本登录形式为：

$ sqlplus /nolog

connect / as sysdba

这些脚本应该不会影响数据库性能，可以多次运行。

警告

此示例代码只为教育目的，Oracle Support不提供技术支持。它已经过内部测试，然而我们无法确保它在任何环境中都能成功使用。请您在使用之前先在测试环境中运行。

示例代码

Oracle 发布的用于调查 ORA-1555 错误的脚本每一版本都有所不同。这些脚本只适用于自动 UNDO 管理 (AUM) 配置的环境。

脚本文件以本文档附件的形式提供。注意：在本文档中执行剪切粘贴操作时，这些脚本可能出现格式问题。因此，脚本都附在文档中，可下载使用。本文将讨论每个脚本的优势/作用，并提供示例输出。

AUM 配置和 ORA-1555 全面分析

  1. 配置：

UndoDatafiles.sql — spool 输出到位于默认目录位置的文件 undodatafiles.out 中。

UndoParameters.sql — spool 输出到位于默认目录位置的文件 undoparameters.out 中。

UndoUsage.sql — spool 输出到位于默认目录位置的文件 undousage.out 中。

  1. 当前未提交的事务：

CurrentActivity.sql — spool 输出到位于默认目录位置的文件 undoactivity.out 中。

  1. 历史 UNDO 信息：

UndoHistoryInfo.sql — spool 输出到位于默认目录位置的 undohistory.out 中。

UndoStatistics.sql — spool 输出到位于默认目录位置的 undostatistics.out 中。您可修改此报告以显示适当的分析时间范围。默认情况下，查看最后两天的 V$UNDOSTAT 数据。在 V$UNDOSTAT 视图中，数据会保留七天。

  1. 等待/锁定分析：

UndoPressure.sql — spool 输出到位于默认目录位置的 undopressure.out 中。

  1. 调查 LOB 问题：

LobData.sql — spool 输出到位于默认目录位置的 lobdata.out 中。

示例输出

  1. 配置

示例 undodatafiles.out

############## RUNTIME ##############

Run Time

—————–

05-Aug-2009 08:53

############## DATAFILES ##############

Aut

TBSP Name                   File #   Bytes Alloc (MB) Max Bytes Used (MB) (MB)     Ext

—————————— —— ————————- ———————————— ——

SMALLUNDO                  3                              200                                     200     YES

查看配置数据。AUTOEXTEND 是否打开？如果 UNDO 表空间配置为随着空间需求自动增长，这会对数据库造成影响，数据库可能不会重新使用超过Retention设置的过期 Undo extent，以减少发生 ORA-1555 的几率。表空间进而会随着新的需求增长。

示例 undoparameters.out

############## RUNTIME ##############Run Time

—————–

05-Aug-2009 08:56

############## PARAMETERS ##############

Instance #  Parameter                              Session Value          Instance Value

————– ———————————– ————————- ————————-

1                 _smu_debug_mode                              33554432                  33554432

1                _undo_autotune                                         TRUE                        TRUE

1                undo_management                                    AUTO                       AUTO

1                undo_retention                                                900                             900

1                undo_tablespace                        SMALLUNDO          SMALLUNDO

查看影响 Undo Retention规则的参数设置。

‘_smu_debug_mode’=33554432 会强制让自动优化程序基于系统中运行时间最长的 SQL 的执行时间来计算自动的 undo retention。在默认情况下，自动调整后的保留时间会增长到很长的时间段，空间压力将成为 Undo 表空间中的重大问题。

‘_undo_autotune’=false 是一些 AUM bug 的权宜方法，但这会对分析产生重大影响。V$UNDOSTAT 中不会再进一步跟踪其他数据，显式指定的的 UNDO_RETENTION 设置是影响 undo Retention处理的关键。

示例 undousage.out

############## RUNTIME ##############

Run Time

————————–

05-Aug-2009 08:58

############## IN USE Undo Data ##############

PCT_INUSE

—————-

23.625

TABLESPACE_NAME    EXTENT_MAN    ALLOCATIO      SEGMEN      RETENTION

——————————— ———————— ———————- —————- —————–

SMALLUNDO                  LOCAL                    SYSTEM             MANUAL    NOGUARANTEE

Sum of Free

—————-

65,536

Total Bytes

—————-

209,715,200

############## UNDO SEGMENTS ##############

Status              Total Extents

—————— —————–

UNEXPIRED                    21

EXPIRED                        807

ACTIVE                          195

————-

sum                               1,023

 

Status               Total Segments

——————– ——————-

ONLINE                                  11

————-

sum                                          11

  1. 当前未提交的事务

示例 undoactivity.out

############## RUNTIME ##############

Run Time

—————–

19-Aug-2009 09:43

############## Current Uncommitted Transactions ##############

Started    User     Undo Segment Name            File #       Block #       Status         KBytes     Rows

———— ——— ————————————- ———— ————– ————– ————- ———-

08/19/09 KEN      _SYSSMU8_1245875459$                  3            9735     ACTIVE       48,664   614,178

09:43:02

查看未提交的事务。该事务有多大？什么用户在处理该事务？随着时间的推移，其是否显示为未提交？这在预期之内吗？在此事务之前开始的任何长时间运行的查询、或在此事务之前使用闪回功能都必须创建此数据的旧“副本”。

  1. 历史 UNDO 信息

示例 – undohistory.out

############## RUNTIME ##############

Run Time

—————–

05-Aug-2009 09:08

############## HISTORICAL DATA ##############

Max Concurrent

Last 7 Days

——————–

5

Max Concurrent

Since Startup

———————–

5

1555 Errors

—————

0

Undo Space Errors

————————-

0

############## CURRENT STATUS OF SEGMENTS ##############

############## SNAPSHOT IN TIME INFO ##############

##############(SHOWS CURRENT UNDO ACTIVITY)##############

Segment Name                      Active Bytes     Unexpired Bytes Expired Bytes

———————————– ——————— ———————- ——————–

_SYSSMU10_1245875459$                           0             1,114,112                 65,536

_SYSSMU1_1245875459$                             0             3,211,264          75,497,472

_SYSSMU2_1245875459$                             0                196,608                 65,536

_SYSSMU3_1245875459$                             0             1,507,328          55,115,776

_SYSSMU4_1245875459$             43,253,760                           0                          0

_SYSSMU5_1245875459$                             0             1,048,576          19,922,944

_SYSSMU6_1245875459$                             0                327,680                          0

_SYSSMU7_1245875459$                             0             1,114,112                 65,536

_SYSSMU8_1245875459$                             0                458,752            4,849,664

_SYSSMU9_1245875459$                             0             1,179,648                 65,536

10 rows selected.

############## UNDO SPACE USAGE ##############

Segment#      Shrinks     Avg Shrink Size

—————– ————- ———————–

0                0                              0

1                5                2,424,832

2                5                1,402,470

3                6                2,457,600

4                2                  425,984

5                4                1,638,400

6                4                1,523,712

7                2                1,048,576

8                5                2,031,616

9                1                2,621,440

10                2                1,114,112

11 rows selected.

了解并发性信息。有多少并发性事务相互重叠？如果您不断看到高并发的未提交事务，是否自动调整的 retention 正在正确处理工作负载?对于当前未提交的工作，您还可以检查运行时的段活动情况。同时查看 UNDO 改动的信息。这些段的工作负载是否平衡？收缩是否均匀地分布在段中？是否有任何段承受的压力大于其他段？

示例 undostatistics.out

############## RUNTIME ##############

Run Time

—————–

05-09:08

############## Historical V$UNDOSTAT (Last 2 Days) ##############

Query

Maximum                                               Undo     # of                                                     Tuned Ret

Date/Time Minutes   SqlID                 TBS        Blocks    Trans   # of Unexpired    # of Expired Minutes

————- ————- ——————– ———– ——— ———- ——————— —————- —————

03-09:15                 14 0rc4km05kgzb9           14          39       160                        312           25,024                  29

03-09:25                   4 0rc4km05kgzb9           14          36       220                        312           25,024                  43

03-09:35                 14 0rc4km05kgzb9           14         327      200                            8           25,024                  43

03-09:45                   4 0rc4km05kgzb9           14           20      202                        464           24,896                  29

. . .

05-08:37                   1 0rc4km05kgzb9           14           22      195                           80          25,344                  15

05-08:47                12 0rc4km05kgzb9            14           35      216                           48          25,376                  15

05-08:57                  2 0rc4km05kgzb9            14           33      183                           56          25,368                  15

 

284 rows selected.

############## RECENT MISSES FOR UNDO (Last 2 Days) ##############

no rows selected

no rows selected

############## AUTO-TUNING TUNE-DOWN DATA ##############

######## ROLLBACK DATA (Since Startup) ##############

Name                                                                                                        Counters

————————————————————————————- ————

user rollbacks                                                                                                 4,959

transaction tables consistent reads – undo records applied                          3

transaction tables consistent read rollbacks                                                    0

data blocks consistent reads – undo records applied                          300,730

rollbacks only – consistent read gets                                                       11,384

cleanouts and rollbacks – consistent read gets                                             39

rollback changes – undo records applied                                                18,529

transaction rollbacks                                                                                       190

total number of undo segments dropped                                                         0

tune down retentions in space pressure                                                           0

global undo segment hints helped                                                                     1

global undo segment hints were stale                                                               0

local undo segment hints helped                                                                       0

local undo segment hints were stale                                                                  0

undo segment header was pinned                                                             90,532

IMU CR rollbacks                                                                                           6,183

SMON posted for undo segment recovery                                                       0

SMON posted for undo segment shrink                                                            0

18 rows selected.

############## Long Running Query History ##############

 

Date                    SQL ID                Runaway SQL ID                          Space Issues

——————– ———————- —————————————– ————————————————

02-19:05              0rc4km05kgzb9                                                          Max Tuned Down – Not Auto-Tuning

02-19:15              0rc4km05kgzb9                                                          Reached Best Retention

02-19:25              0rc4km05kgzb9                                                          Reached Best Retention

02-19:35              0rc4km05kgzb9                                                          Reached Best Retention

02-19:45              0rc4km05kgzb9                                                          Reached Best Retention

############## Details on Long Run Queries ##############

SQL ID                 SQL Text                                                                                             Last Load                  Elapsed Days

———————- ——————————————————————————— ————————– ——————

0rc4km05kgzb9    select 1 from obj$ where name=’DBA_QUEUE_SCHEDULES’  2009-08-04/13:30:06                     19

查看报告中在设定时间内收集的关于 undo 活动的数据（默认为 2 天）。

第二部分将显示在 V$UNDOSTAT 中的七天或在实例生命周期中，查询持续时间大于调整后的Retention时间的情况。

是否有大量的“调低”相关活动？“调低”是自动调整 AUM 的一种功能，将会收缩保留时间以减少 UNDO 空间压力。这可指向尚未引发 ORA-30036 错误的空间问题。

最后调查长时运行查询数据。这些可能是我们预期内的，但也有助于指出意外的查询活动。

  1. 等待/锁定分析

示例 undopressure.out

############## RUNTIME ##############

Run Time

—————–

05-08:58

############## WAITS FOR UNDO (Since Startup) ##############

Cummalitve

Instance# Enq Total Requests   Total Waits       Successes           Failures             Time

————- —— ——————– —————- ———————— ————— ——————

1                 HW                  2,104                     0                       2,104                    0                       0

1                  US                        58                     0                            58                    0                       0

############## LOCKS FOR UNDO ##############

no rows selected

############## TUNED RETENTION HISTORY (Last 2 Days) ##############

############## LOWEST AND HIGHEST DATA ##############

END_TIME TUNED_UNDORETENTION

—————– ————————————–

05-08:58                                                      900

05-08:57                                                      900

05-08:37                                                      900

05-07:17                                                      900

05-04:17                                                      900

05-03:57                                                      900

05-03:37                                                      900

05-02:57                                                      900

05-02:37                                                      900

05-02:17                                                      900

05-01:17                                                      900

11 rows selected.

END_TIME TUNED_UNDORETENTION

—————– ————————————-

04-17:57                                                   2227

############## CURRENT TRANSACTIONS ##############

START_DATE  START_SCN   STATUS            SQL Code

——————— —————— —————- —————————————-

05-08:58               53717782         ACTIVE       update abc_tmp set edition_name=”

CURRENT_SCN

———————

53734654

############## WHO’S STEALING WHAT? (Last 2 Days) ##############

UnexStolen ExStolen UnexReuse ExReuse

————— ———— ————— ———–

0              22                   0              0

0              12                   0              0

查看等待和锁定信息。高等待和性能问题可能与已知的 UNDO 性能 bug 匹配。同时查看高、低调整后的Retention信息。在此报告中，您是否发现被盗 extent 的证据？未过期 extent 是否被盗？

  1. 调查 LOB 问题

示例 lobdata.out

Table               Column                                                Tablespace       PCTVersion %   Retention

—————— ———————————————- ——————– ——————– ————-

CTEST             DATA_OBJECT                                TB1                                                          900

PAA_TEST    RESPONDER_COMMENT              TB1                                                          900

EMP_O           PICTURE                                             USERS                                      10

EMP_O           RESUME                                             USERS                                      10

TEST               COMMENTS                                      TB1                                                          900

5 rows selected.

如果定期更新 LOB 数据，LOB 对象上发生 ORA-1555 就可能是预期内的。PCTVersion 默认为 10%，如果您持续对 LOB 数据进行了更改，那么这个此值通常需要调高很多。有时 100%（保留所有更改）还不足以适应工作负载。常规的 ORA-1555 诊断/分析对与 LOB 相关的 ORA-1555 错误是没有用的。LOB 产生的 UNDO 不是使用 UNDO 表空间中的 extent，而是保留在 LOB 表空间中。

其他参考：
https://wenku.baidu.com/view/47b01e6ab84ae45c3b358ca8.html

https://docs.oracle.com/cd/B19306_01/server.102/b14237/initparams222.htm#REFRN10225

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=341463354078393&parent=DOCUMENT&sourceId=1307334.1&id=1555.1&_afrWindowMode=0&_adf.ctrl-state=wgqt71fpl_126

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=341423607535564&id=1307334.1&_afrWindowMode=0&_adf.ctrl-state=wgqt71fpl_77

Oracle 标准服务 – 数据库技术支持通讯 – 2015年11月版，57期 (文档 ID 2088997.1)

https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=wgqt71fpl_299&_afrLoop=344990618186201#title1

系统层级、经验闲谈

Oracle EBS 取消“是否提交另一项请求”

留下评论

配置文件

中文：并发：提交每个请求后显示请求摘要

英文：Concurrent: ShowRequests Summary After Each Request Submission

说明：设置为“是”以使 SRS 表单 (FNDRSRUN) 在每次提交新请求时显示当前提交请求的摘要。

使用场景：

    在使用EBS提交请求后，总要弹出“是否提交另一项请求”的提示，而我们往往选择“否”，这个提示就显得多余。  

    为了减轻这“多一步”的负担，取消“是否提交另一项请求”的提示，设置方法如下：默认：否(No)，修改为是(Yes)，可以在User Level上修改。

系统层级

Oracle 官方给出声明DB版本对于dblink连接产生影响

留下评论

在 Oracle 官方支持站点 MOS 上，最近发布了两篇告警文章

  • Oracle Databases Need to be Patched to a Minimum Patchset/PSU/RU level before April 2019 (Doc ID 2361478.1)
  • Mandatory Patching Requirement for Database Versions 11.2.0.3 or Earlier, Using DB Links (Doc ID 2335265.1)

官方给出了如下声明

对于database link带来影响的原因如下



官方给出的建议如下：



关于两篇文档内容总结如下
1、 通过 DB Link 的查询会同步数据库的 SCN，也就是这个原理会导致很多 SCN 耗尽的 Headroom 问题
2、 如果都是未应用补丁的低版本数据库互访，不会出现问题；但是如果是未应用补丁的低版本和应用了补丁的高版本之间互访，就可能出问题。
3、 如果低版本和高版本互访，在2019年4月之后，跨 DB Link 的访问不一定会出现问题，尤其是 SCN 的增长率维持低位的数据库；但是由于算法的改变，很可能会出现问题，而且概率很高；
4、 引入这样的修改和补丁，是因为 SCN 是 Oracle 的核心机制，过去遇到的 Headroom问题必须获得彻底消除，所以算法需要调整，这是非常核心的改变。
5、 如果数据库全部维持在低版本，或者不通过 DB Link 互访，则无所谓; Oracle 也提供禁用该特性的功能，但是不保证之后不改变。

在 MOS 上文档 1393360.1中，就有各种已知的描述，如果低版本的数据库 SCN 不能抬升，那么就可能遭遇：ORA-19706: invalid SCN 的错误（详情见附件）。

对于Oracle官方给出的该声明，整体建议如下：

方案一：对于低版本和高版本互访的dblink链接进行应用改造，如非必要，请尽可能采用客户端连接的方式进行交互
方案二：对dblink的源端以及目标端数据库进行补丁升级，以符合官方要求版本太低的可进行跨版本升级，但需要先对稳定性以及性能进行调整测试，如SPA等。

不建议：关闭scn新特性

因为当前关闭新特性是为了向下兼容，那么今后新数据库部署，就都需要关闭该功能，但是Oracle 虽然现在提供禁用该特性的功能，却不保证之后不改变，以后也会有诸多功能基于此特性开发，越往后进行应用，覆盖面约广，所以建议在过渡期内升级打patch，而不是等该特性运行后，大面积实行。

参考：http://www.sohu.com/a/225739395_505827

http://ju.outofmemory.cn/entry/354015

系统层级

Oracle补丁及opatch工具介绍

留下评论

一． CPU（Critical Patch Update）

    一个CPU内包含了对多个安全漏洞的修复，并且也包括相应必需的非安全漏洞的补丁。CPU是累积型的，只要安装最新发布的CPU即可，其中包括之前发布的所有CPU的内容。事实上，在CPU之前的安全漏洞修改除去个别例外也被包括在CPU中。Oracle公司只对处于标准技术支持和延长支持期间的产品提供CPU更新，对处于维持支持范围的产品不提供新的CPU.（对于9.2以前的版本，只对处于ECS和EMS期间的版本提供CPU更新。）

    一般对当前补丁发行版及前一个版本提供CPU，但也有只限于当前补丁发行版的例外情形。也就是说，一般需要先安装最新PSR后才可能安装CPU.由于是累积型的定期发布，所以对于某一平台的某一版本，如果两次CPU发布期间没有发现新的安全漏洞，则新发布的CPU与前一版本完全相同。

    可以在以下网址中可以找到CPU发布的信息，只要在Oracle 免费注册一个用户，就可以收到这些补丁的信息。但是，只有技术支持签约用户才可以从metalink下载补丁文件。

    http://www.oracle.com/technology/deploy/security/alerts.htm

    Oracle公司制定的CPU的发布日期大约在一月、四月、七月和十月的最接近15的星期二。

    Critical Patch Updates

    Critical Patch Updates are the primary means of releasing security fixes for Oracle products to customers with valid support contracts. They are released on the Tuesday closest to the 15th day of January, April, July and October. Starting 2011, the scheduled dates for the release of Critical Patch Updates will be on the Tuesday closest to the 17th day of January, April, July and October. The next four dates are:

    12 October 2010

    18 January 2011

    19 April 2011

    19 July 2011

    对于每一个CPU，附有相应的说明文档（Critical Patch Update Note），其中介绍安装过程和注意事项，在安装之前应认真阅读此文档。同样也存在文档“Oracle Critical Patch Update MM YYYY Known Issues for Oracle Database”，其中列出了说明文档中没有给出的新信息。

    二．PSR（Patch Set Release） 和 PSU（Patch Set Update）

    8i,9i,10g,11g这是其主要版本号，每一版本会陆续有两至三个发行版，如10.1，10.2,和 11.1，11.2分别是10g和11g的两个发行版。对于每一个发行版软件中发现的BUG，给出相应的修复补丁。每隔一定时期，会将所有补丁集成到软件中，经过集成测试后，进行发布，也称为PSR（Patch Set Release）。以10.2为例，10.2.0.1.0是基础发行版，至今已有三个PSR发布，每个PSR修改5位版本号的第4位，最新10.2的PSR为10.2.0.4.0。(11.1.0.6.0是11.1的基础发行版，11.1.0.7.0是第一次PSR) 。

    在某个PSR之后编写的补丁，在还没有加入到下一个PSR之前，以个别补丁（Interim Patch）的形式提供给客户。某个个别补丁是针对Oracle公司发现的或客户报告的某一个BUG编写的补丁，多个个别补丁之间一同安装时可能会有冲突，即同一个目标模块分别进行了不同的修改。另外，即便在安装时没有发现冲突，由于没有进行严格的集成测试，运行过程中由于相互作用是否会发生意外也不能完全排除。

    除去修改功能和性能BUG的补丁，还有应对安全漏洞的安全补丁。Oracle公司定期（一年四期）发布安全补丁集，称之为CPU（Critical Patch Updates）。

    由于数据库在信息系统的核心地位，对其性能和安全性的要求非常高。理应及时安装所有重要补丁。另外一个方面，基于同样的理由，要求数据库系统必须非常稳定，安装补丁而导致的系统故障和性能下降同样不可接受。DBA经常面临一个非常困难的选择：对于多个修复重要BUG的个别补丁是否安装。不安装，失去预防故障发生的机会，以后故障发生时，自己是无作为；安装，如果这些补丁中存在着倒退BUG，或者相互影响，以后发生由于安装补丁而造成的故障时，自己则是无事生非！而等待下一个PSR，一般又需要一年时间。因此，出现了PSU（Patch Set Update）。

    PSU解决以下几个问题：

    1. 减轻PSR周期长而带来的不能及时更新的影响；

    2. 解决多个个别补丁冲突和相互影响的问题；

    3. 减轻DBA安装补丁的负担：补丁安装次数，不定期检查补丁发布。

    PSU具有如下特点：

    第一、PSU是PSR的补充，在两次PSR发布之间发布多个PSU，加快更新速度。每个PSU修改5位版本号的第5位。例如，安装此次发布的 PSU后，11.1版本“升级”为11.1.0.7.1；10.2版本为10.2.0.4.2。

    第二、每个PSU中包含25至100个重要补丁，作为一个整体进行严格测试，解决冲突问题，保证系统的稳定性。PSU不仅包括对功能、性能修复的一般补丁，也包括安全补丁。

    第三、PSU定期发布，计划一年分布四次，发布日期与CPU发布日期相同。由于PSU包括同期发布的CPU，只要安装PSU即可。（对部分平台，仍提供单独的CPU，供客户选择）

    第四、如同PSR和CPU一样，PSU是累积型的，即只要安装最新的PSU就自动包括以前所有PSU的内容。

    第五、使用DBA已经熟悉的Opatch工具安装/删除PSU，命令仍是apply和rollback。一个PSU可视作一个个别补丁，安装和删除操作都很简便。

    第六、现有的个别补丁与PSU的关系分为三类：完全独立；是PSU的一部分；与PSU冲突。第一类的个别补丁与PSU相互没有影响，可以独立的安装或删除。对于第二类，在安装PSU之后，自然没有必要安装。若在PSU之前已安装，则在安装PSU时会被自动删除。对于第三类个别补丁，如在PSU之前已安装，必须在安装PSU时删除。客户可以向Oracle公司技术支持部门提出申请，由Oracle负责提供与PSU不冲突的，在PSU之上安装的相应的新的版本。

    PSU的限制：必须是在正常技术支持范围之内的版本（11.2、11.1和10.2），并且PSU只能在最新PSR之上安装。

    三．OPatch 命令

    先看一个官网的Oracle OPatch 的说明：

    Oracle Software Patching Using Opatch

    http://download.oracle.com/docs/cd/B19306_01/em.102/b16227/oui8_opatch.htm

    从9.2版开始，Oracle公司实现了个别补丁安装工具opatch. opatch使用一个称为inventory的系统数据结构（严格说是与oui共享inventory），集中管理所有已安装的个别补丁；个别补丁的安装和卸载都使用opatch命令完成，冲突检测也由opatch在安装时自动完成；提供列表命令可以很方便得到已安装个别补丁的信息。

    10g（10.1和10.2）版本中，opatch作为一个标准工具，在安装时自动安装。（安装在$ORACLE_HOME/OPatch下。）而对于9.2版，需要从metalink下载opatch.无论是哪一个版本，系统中是否已经安装opatch，在使用之前，应从metalink下载最新版本的opatch.很遗憾，由于系统实现的问题，10.2使用的opatch与之前版本（10.1和9.2）使用的opatch不兼容，不能混用，这一点必须注意。

    opatch是使用perl编写的脚本程序（其中也使用JAVA API）。使用的perl版本是5.6版，虽然在5.6之前的版本中也可运行，但应尽可能安装5.6或以上的版本的perl. 对于DBA来说一个好消息是，如果安装9.2版软件时保留了HTTP服务器，则在$ORACLE_HOME/Apache下会自动安装perl.（10g会自动安装配置perl和opatch.）

    3.1 opatch命令存放位置

    该命令的存放位置在$ORACLE_HOME下的OPatch目录下。

    -bash-3.2$ pwd

    /u01/oracle/oracle/product/10.2.0/db_1/OPatch

    -bash-3.2$ ls

    docs emdpatch.pl jlib opatch opatch.ini opatch.pl

    -bash-3.2$ ls -lrt

    total 44

    -rw-r–r– 1 oracle oinstall 18107 Apr 18 2005 emdpatch.pl

    -rw-r–r– 1 oracle oinstall 2193 Jun 1 2005 opatch.pl

    -rwxr-xr-x 1 oracle oinstall 5672 Jun 1 2005 opatch

    drwxr-x— 2 oracle oinstall 4096 Apr 21 13:24 jlib

    drwxr-x— 2 oracle oinstall 4096 Apr 21 13:24 docs

    -rw-r–r– 1 oracle oinstall  49 Apr 21 13:24 opatch.ini

    3.2 使用“-help”参数可以获得opatch命令的帮助信息

    -bash-3.2$ ./opatch –help

    Invoking OPatch 10.2.0.1.0

    Oracle interim Patch Installer version 10.2.0.1.0

    Copyright (c) 2005, Oracle Corporation. All rights reserved..

    Oracle Home   : /u01/oracle/oracle/product/10.2.0/db_1

    Central Inventory : /u01/oracle/oraInventory

    from     : /u01/oracle/oracle/product/10.2.0/db_1/oraInst.loc

    OPatch version  : 10.2.0.1.0

    OUI version   : 10.2.0.1.0

    OUI location   : /u01/oracle/oracle/product/10.2.0/db_1//oui

    Log file location : /u01/oracle/oracle/product/10.2.0/db_1/cfgtoollogs/opatch/opatch-2010_Aug_09_03-05-40-CST_Mon.log

    Usage: opatch [ -help ] [ -r[eport] ] [ command ]

    command := apply

    lsinventory

    query

    rollback

    version

    <global_arguments>:= -help   Displays the help message for the command.

    -report  Print the actions without executing (deprecated).

    example:

    'opatch -help'

    'opatch apply -help'

    'opatch lsinventory -help'

    'opatch rollback -help'

    OPatch succeeded.

    这个是10.2.0.1版本的opatch. 在10.2.0.4 版本的opatch命令与之前的又不同，它有添加了几个命令。

    -bash-3.2$ ./opatch –help

    Invoking OPatch 11.1.0.6.6

    Oracle Interim Patch Installer version 11.1.0.6.6

    Copyright (c) 2009, Oracle Corporation. All rights reserved.

    Usage: opatch [ -help ] [ -r[eport] ] [ command ]

    command := apply

    lsinventory

    napply

    nrollback

    rollback

    query

    version

    prereq

    util

    <global_arguments>:= -help   Displays the help message for the command.

    -report  Print the actions without executing.

    example:

    'opatch -help'

    'opatch apply -help'

    'opatch lsinventory -help'

    'opatch napply -help'

    'opatch nrollback -help'

    'opatch rollback -help'

    'opatch prereq -help'

    'opatch util -help'

    OPatch succeeded.

    官网上对命令的一些解释：

    apply

    Installs an interim patch. Refer to "apply Command" for more information.

    napply

    Installs n number of patches (hence napply). Refer to "napply Command" for more information.

    auto

    Applies Oracle Clusterware patches. Refer to "auto Command" for more information.

    lsinventory

    Lists what is currently installed on the system. Refer to "lsinventory Command" for more information.

    query

    Queries a given patch for specific details. Refer to "query Command" for more information.

    rollback

    Removes an interim patch. Refer to "rollback Command" for more information.

    nrollback

    Removes n number of patches (hence nrollback). Refer to "nrollback Command" for more information.

    version

    Prints the current version of the patch tool. Refer to "version Command" for more information.

    在$ORACLE_HOME/OPatch/docs目录下，用指南文件（Users_Guide.txt），其中有详细的命令格式和使用示例，可以参考。

    Opatch执行操作时，除在屏幕输出结果外，还生成日志文件。日志文件的路径和文件名格式如下：

    $ORACLE_HOME/.patch_storage/< patch_id >/< action >-< patch_id >_< mm-dd-yyyy_hh-mi-ss>.log

    其中“patch_id”是Oracle技术支持部门为个别补丁分配的编号。

    3.3 opatch安装个别补丁示例：

    以Patch 5689937 为例。

    3.3.1 patch下载

    从metalink下载补丁的压缩文件p5689937_10201_LINUX.zip.将此文件解压缩至某一目录中。解压缩后，这一补丁的所有文件都在子目录5689937下，目录名就是个别补丁的补丁号，opatch依据目录名获得信息，所以一定不要重命名子目录。

    3.3.2 安装patch

    进入patch文件5689937 目录，在patch的目录下面有一个readme的安装文档，里面有安装步骤和一些问题的处理方法。

    3.3.2.1 关闭数据库和监听

    Shut down all instances and listeners associated with the Oracle home that you are updating.

    3.3.2.2. 进入patch目录，运行opatch apply命令

    -bash-3.2$ cd p5689937_10201_LINUX/

    -bash-3.2$ ls

    5689937 patchmd.xml README.html

    -bash-3.2$ cd 5689937/

    -bash-3.2$ ls

    custom etc files README.txt

    -bash-3.2$ pwd

    /mnt/p5689937_10201_LINUX/5689937

    -bash-3.2$ export PATH=$PATH:/usr/ccs/bin

    -bash-3.2$ $ORACLE_HOME/OPatch/opatch apply

    3.3.2.3 启动实例，运行相关脚本

    -bash-3.2$ cd $ORACLE_HOME/cpu/CPUJan2007/ — 要进入这个目录才能找到脚本

    -bash-3.2$ sqlplus /nolog

    SQL*Plus: Release 10.2.0.1.0 – Production on Mon Aug 9 04:48:19 2010

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

    SQL> conn / as sysdba

    Connected to an idle instance.

    SQL> startup

    ORACLE instance started.

    Total System Global Area 281018368 bytes

    Fixed Size         1218968 bytes

    Variable Size       83887720 bytes

    Database Buffers     192937984 bytes

    Redo Buffers        2973696 bytes

    Database mounted.

    Database opened.

    SQL> @catcpu.sql

    如果catcpu.sql 脚本报任何无效对象，执行如下脚本：

    SQL> @?/rdbms/admin/utlrp.sql

    可以用如下SQL 检查无效对象：

    SQL> SELECT OBJECT_NAME FROM DBA_OBJECTS WHERE STATUS= 'INVALID';

    3.3.3 用inventory 命令查看已经安装的patch

    -bash-3.2$ $ORACLE_HOME/OPatch/opatch lsinventory

    Invoking OPatch 10.2.0.1.0

    Oracle interim Patch Installer version 10.2.0.1.0

    Copyright (c) 2005, Oracle Corporation. All rights reserved..

    Oracle Home   : /u01/oracle/oracle/product/10.2.0/db_1

    Central Inventory : /u01/oracle/oraInventory

    from     : /u01/oracle/oracle/product/10.2.0/db_1/oraInst.loc

    OPatch version  : 10.2.0.1.0

    OUI version   : 10.2.0.1.0

    OUI location   : /u01/oracle/oracle/product/10.2.0/db_1//oui

    Log file location : /u01/oracle/oracle/product/10.2.0/db_1/cfgtoollogs/opatch/opatch-2010_Aug_09_04-55-55-CST_Mon.log

    Lsinventory Output file location : /u01/oracle/oracle/product/10.2.0/db_1/cfgtoollogs/opatch/lsinv/lsinventory-2010_Aug_09_04-55-55-CST_Mon.txt

    ——————————————————————————–

    Installed Top-level Products (1):

    Oracle Database 10g                         10.2.0.1.0

    There are 1 products installed in this Oracle Home.

    Interim patches (1) :

    Patch 5689937   : applied on Mon Aug 09 04:43:27 CST 2010

    Created on 8 Jan 2007, 11:48:31 hrs US/Eastern

    Bugs fixed:

    4671216, 4925103, 4604970, 4616376, 5689937, 4288876, 5225798, 5694720

    4754888, 4750469, 4369235, 4751931, 4966716, 5049080, 5242648, 4348230

    5490846, 4630549, 5490936, 5049088

    ——————————————————————————–

    OPatch succeeded.

    或者用$ORACLE_HOME/OPatch/opatch lsinventory –detail 命令查看详细。

    3.4 卸载 opatch

    3.4.1 关闭实例和监听

    SQL> shutdown immediate

    3.4.2 执行opatch命令

    -bash-3.2$ cd $ORACLE_HOME/OPatch/

    -bash-3.2$ ./opatch rollback -id 5689937

    3.4.3 启动实例，执行catcpu_rollback.sql脚本

    -bash-3.2$ cd $ORACLE_HOME/cpu/CPUJan2007/

    -bash-3.2$ sqlplus /nolog

    SQL*Plus: Release 10.2.0.1.0 – Production on Mon Aug 9 05:04:19 2010

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

    SQL> conn / as sysdba

    Connected to an idle instance.

    SQL> startup

    ORACLE instance started.

    Total System Global Area 281018368 bytes

    Fixed Size         1218968 bytes

    Variable Size      109053544 bytes

    Database Buffers     167772160 bytes

    Redo Buffers        2973696 bytes

    Database mounted.

    Database opened.

    SQL> @catcpu_rollback.sql — 这个脚本在patch的安装目录里也有

    如果在运行中出现无效对象，运行如下脚本：

    SQL> @?/rdbms/admin/utlrp.sql

    检查无效对象：

    SQL> SELECT OBJECT_NAME FROM DBA_OBJECTS WHERE STATUS = 'INVALID';

    关于Patch的说明就到此。 在后说明一点。 有时我们的生产库遇到一个问题，但是又不能十分确定是否是某个bug的时候，可以先考虑打patch看一下，如果解决了更好，如果不能解决，把patch删掉即可。 这样可以把问题控制在可控的范围内，避免把问题扩大化。