Oracle 11.2.0.4.3 PSU For 11.2.0.4 RAC LINUX X86-64 installation

本文详细介绍了Oracle补丁安装流程,包括使用opatch工具进行安装,生成ocm.rsp文件,以及在安装前后的操作步骤。同时,文章解决了在安装过程中遇到的空间不足和文件不可写问题,提供了有效的解决方法。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

安装文件 p18706472_112040_Linux-x86-64.zip 大小居然已经500M+了.

需要的opatch版本是最新的11.2.0.3.6,所以需要到Oracle MOS上下载,docid是6880880

unzip <OPATCH-ZIP> -d <ORACLE_HOME>

 

安装的话非常简单,安装readme去做。

我的环境是grid跟oracle用户的软件都分开的,下面就按照这种情况来做。

安装需要OCM.rsp文件,生成是参照If you do not have the OCM response file (ocm.rsp), see the following My Oracle Support Document966023.1How To Create An OCM Response File For Opatch Silent Installation.

 

 

 

我以GI用户登录,执行

cd /tmp

$GRID_HOME/OPatch/ocm/bin/emocmrsp

这样执行了之后,会在当前目录/tmp下生成一个OCM.rsp文件

 

在升级之前将oracle crs起来,数据库跟dbconsole down下去

srvctl stop instance -d orcl -i orcl1

emctl stop dbconsole


下面的列表是我安装的时候oracle执行的步骤,实际安装的时候可以按照这个列表的check的步骤先执行一下看看。

 1-10,13-14是check语句,可以先手工运行检查一下。

<p>crs_home=/u01/app/11.2.0.4/grid version=11.2.0.4.0      owner=oracle      opatch_ver=11.2.0.3.6
rac_home=/u01/app/oracle/product/11.2.0.4/db_1  version=11.2.0.4.0      owner=oracle      opatch_ver=11.2.0.3.6</p><p>*********** Steps to be executed as owner unless specified as root ***********</p><p>
1: /u01/app/oracle/product/11.2.0.4/db_1/OPatch/opatch prereq CheckComponents -ph /tmp/orasoft/18706472/18522509 -oh /u01/app/oracle/product/11.2.0.4/db_1</p><p>2: /u01/app/oracle/product/11.2.0.4/db_1/OPatch/opatch prereq CheckComponents -ph /tmp/orasoft/18706472/18522515/custom/server/18522515 -oh /u01/app/oracle/product/11.2.0.4/db_1</p><p>3: /u01/app/oracle/product/11.2.0.4/db_1/OPatch/opatch prereq CheckConflictAgainstOH -ph /tmp/orasoft/18706472/18522509 -oh /u01/app/oracle/product/11.2.0.4/db_1</p><p>4: /u01/app/oracle/product/11.2.0.4/db_1/OPatch/opatch prereq CheckConflictAgainstOH -ph /tmp/orasoft/18706472/18522515/custom/server/18522515 -oh /u01/app/oracle/product/11.2.0.4/db_1</p><p>5: /u01/app/11.2.0.4/grid/OPatch/opatch prereq CheckComponents -ph /tmp/orasoft/18706472/18522509 -oh /u01/app/11.2.0.4/grid</p><p>6: /u01/app/11.2.0.4/grid/OPatch/opatch prereq CheckComponents -ph /tmp/orasoft/18706472/18522515 -oh /u01/app/11.2.0.4/grid</p><p>7: /u01/app/11.2.0.4/grid/OPatch/opatch prereq CheckComponents -ph /tmp/orasoft/18706472/18522514 -oh /u01/app/11.2.0.4/grid</p><p>8: /u01/app/11.2.0.4/grid/OPatch/opatch prereq CheckConflictAgainstOH -ph /tmp/orasoft/18706472/18522509 -oh /u01/app/11.2.0.4/grid</p><p>9: /u01/app/11.2.0.4/grid/OPatch/opatch prereq CheckConflictAgainstOH -ph /tmp/orasoft/18706472/18522515 -oh /u01/app/11.2.0.4/grid</p><p>10: /u01/app/11.2.0.4/grid/OPatch/opatch prereq CheckConflictAgainstOH -ph /tmp/orasoft/18706472/18522514 -oh /u01/app/11.2.0.4/grid</p><p>11: /u01/app/oracle/product/11.2.0.4/db_1/bin/emctl stop dbconsole</p><p>12: /u01/app/oracle/product/11.2.0.4/db_1/bin/emctl stop agent</p><p>13: /u01/app/oracle/product/11.2.0.4/db_1/OPatch/opatch prereq CheckApplicable -ph /tmp/orasoft/18706472/18522509 -oh /u01/app/oracle/product/11.2.0.4/db_1</p><p>14: /u01/app/oracle/product/11.2.0.4/db_1/OPatch/opatch prereq CheckApplicable -ph /tmp/orasoft/18706472/18522515/custom/server/18522515 -oh /u01/app/oracle/product/11.2.0.4/db_1</p><p>15: /u01/app/oracle/product/11.2.0.4/db_1/bin/srvctl stop home -o /u01/app/oracle/product/11.2.0.4/db_1 -s /u01/app/oracle/product/11.2.0.4/db_1/srvm/admin/stophome.txt -n rac0402</p><p>16: /tmp/orasoft/18706472/18522515/custom/server/18522515/custom/scripts/prepatch.sh -dbhome /u01/app/oracle/product/11.2.0.4/db_1</p><p>17: /u01/app/oracle/product/11.2.0.4/db_1/OPatch/opatch napply /tmp/orasoft/18706472/18522509 -local -silent -ocmrf /tmp/ocm.rsp -oh /u01/app/oracle/product/11.2.0.4/db_1 -invPtrLoc /u01/app/oracle/product/11.2.0.4/db_1/oraInst.loc</p><p>18: /u01/app/oracle/product/11.2.0.4/db_1/OPatch/opatch napply /tmp/orasoft/18706472/18522515/custom/server/18522515 -local -silent -ocmrf /tmp/ocm.rsp -oh /u01/app/oracle/product/11.2.0.4/db_1 -invPtrLoc /u01/app/oracle/product/11.2.0.4/db_1/oraInst.loc</p><p>19: /tmp/orasoft/18706472/18522515/custom/server/18522515/custom/scripts/postpatch.sh -dbhome /u01/app/oracle/product/11.2.0.4/db_1</p><p>20: /u01/app/11.2.0.4/grid/crs/install/rootcrs.pl -unlock : run as root</p><p>21: /sbin/fuser -k /u01/app/11.2.0.4/grid/bin/crsctl.bin : run as root</p><p>22: /u01/app/11.2.0.4/grid/OPatch/opatch prereq CheckApplicable -ph /tmp/orasoft/18706472/18522509 -oh /u01/app/11.2.0.4/grid</p><p>23: /u01/app/11.2.0.4/grid/OPatch/opatch prereq CheckApplicable -ph /tmp/orasoft/18706472/18522515 -oh /u01/app/11.2.0.4/grid</p><p>24: /u01/app/11.2.0.4/grid/OPatch/opatch prereq CheckApplicable -ph /tmp/orasoft/18706472/18522514 -oh /u01/app/11.2.0.4/grid</p><p>25: /u01/app/11.2.0.4/grid/OPatch/opatch napply /tmp/orasoft/18706472/18522509 -local -silent -ocmrf /tmp/ocm.rsp -oh /u01/app/11.2.0.4/grid -invPtrLoc /u01/app/11.2.0.4/grid/oraInst.loc</p><p>26: /u01/app/11.2.0.4/grid/OPatch/opatch napply /tmp/orasoft/18706472/18522515 -local -silent -ocmrf /tmp/ocm.rsp -oh /u01/app/11.2.0.4/grid -invPtrLoc /u01/app/11.2.0.4/grid/oraInst.loc</p><p>27: /u01/app/11.2.0.4/grid/OPatch/opatch napply /tmp/orasoft/18706472/18522514 -local -silent -ocmrf /tmp/ocm.rsp -oh /u01/app/11.2.0.4/grid -invPtrLoc /u01/app/11.2.0.4/grid/oraInst.loc</p><p>28: /u01/app/11.2.0.4/grid/bin/emctl start dbconsole</p><p>29: /u01/app/11.2.0.4/grid/rdbms/install/rootadd_rdbms.sh : run as root</p><p>30: /u01/app/11.2.0.4/grid/crs/install/rootcrs.pl -patch : run as root</p><p>31: /u01/app/oracle/product/11.2.0.4/db_1/bin/emctl start dbconsole</p><p>32: /u01/app/oracle/product/11.2.0.4/db_1/bin/emctl start agent</p><p>33: /u01/app/oracle/product/11.2.0.4/db_1/bin/srvctl start home -o /u01/app/oracle/product/11.2.0.4/db_1 -s /u01/app/oracle/product/11.2.0.4/db_1/srvm/admin/stophome.txt -n rac0402</p>



实际的执行语句是

As root user, execute the following command on each node of the cluster:

# opatch auto <UNZIPPED_PATCH_LOCATION>/18706472 -ocmrf <ocm response file>

 

两个节点上先后做完之后,需要在数据库上执行语句

2.5.2 Loading Modified SQL Files into the Database
The following steps load modified SQL files into the database. For an Oracle RAC environment, perform these steps on only one node.

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

cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> STARTUP
SQL> @catbundle.sql psu apply
SQL> QUIT
The catbundle.sql execution is reflected in the dba_registry_history view by a row associated with bundle series PSU.


 

SQL> column comments format a30
SQL> select comments,version from dba_registry_history where bundle_series='PSU';

COMMENTS                       VERSION
------------------------------ ----------
Patchset 11.2.0.2.0            11.2.0.4
Patchset 11.2.0.2.0            11.2.0.4
PSU 11.2.0.4.3                 11.2.0.4

 

到现在都打好了。

 

下面是中间碰到的问题

1.出现空间不足问题

$ORACLE_HOME/cfgtoollogs/opatchauto2014-08-06_10-26-44.log里面出现下面的信息

 Total space needed for the patches are: 344850774

 Checking if enough space is present on the disk...
 Prerequisite check "CheckSystemSpace" failed.
 The details are:
 Required amount of space(328.875MB) is not available.

 

最终的测试发现4G的free空间是不够的,我最终大概给了7G才行。

2.出现一堆文件不可写问题

Patch 17478514:
Copy Action: Destination File "/u01/app/oracle/product/11.2.0.4/db_1/md/admin/catmd10i.sql" is not writeable.
'oracle.rdbms, 11.2.0.4.0': Cannot copy file from 'catmd10i.sql' to '/u01/app/oracle/product/11.2.0.4/db_1/md/admin/catmd10i.sql'
Copy Action: Destination File "/u01/app/oracle/product/11.2.0.4/db_1/md/admin/sdodbmig.sql" is not writeable.
'oracle.rdbms, 11.2.0.4.0': Cannot copy file from 'sdodbmig.sql' to '/u01/app/oracle/product/11.2.0.4/db_1/md/admin/sdodbmig.sql'
Copy Action: Destination File "/u01/app/oracle/product/11.2.0.4/db_1/rdbms/admin/bundledata_PSU.xml" is not writeable.
'oracle.rdbms, 11.2.0.4.0': Cannot copy file from 'bundledata_PSU.xml' to '/u01/app/oracle/product/11.2.0.4/db_1/rdbms/admin/bundledata_PSU.xml'
onewaycopyAction : Desctination File "/u01/app/oracle/product/11.2.0.4/db_1/psu/11.2.0.4.1/catpsu.sql" is not writeable.
'oracle.rdbms, 11.2.0.4.0': Cannot copy file from 'catpsu.sql' to '/u01/app/oracle/product/11.2.0.4/db_1/psu/11.2.0.4.1/catpsu.sql'
onewaycopyAction : Desctination File "/u01/app/oracle/product/11.2.0.4/db_1/psu/11.2.0.4.1/catpsu_rollback.sql" is not writeable.
'oracle.rdbms, 11.2.0.4.0': Cannot copy file from 'catpsu_rollback.sql' to '/u01/app/oracle/product/11.2.0.4/db_1/psu/11.2.0.4.1/catpsu_rollback.sql'
onewaycopyAction : Desctination File "/u01/app/oracle/product/11.2.0.4/db_1/patch/scripts/bug17088068.sql" is not writeable.
'oracle.rdbms, 11.2.0.4.0': Cannot copy file from 'bug17088068.sql' to '/u01/app/oracle/product/11.2.0.4/db_1/patch/scripts/bug17088068.sql'
Copy Action: Destination File "/u01/app/oracle/product/11.2.0.4/db_1/md/admin/catmd10i.sql" is not writeable.
'oracle.sdo, 11.2.0.4.0': Cannot copy file from 'catmd10i.sql' to '/u01/app/oracle/product/11.2.0.4/db_1/md/admin/catmd10i.sql'


看了一下对应的文件或者目录要么oracle没w权限要么,该文件是root的,oracle所在的组没w权限。

 

这应该是安装rac的时候,zip没在oracle或者grid用户解压导致的

 

至于这个PSU补丁,事实证明是不可以在windows下先解压再上传上去,这样权限会出现一堆问题。

最好是把zip上传上去,解压后安装。


 

 

<think>嗯,用户的问题是关于Oracle 11.2.0.4中临时表空间被LOB占用未释放的解决方案。从用户提供的引用来看,ta可能在进行数据库维护或恢复操作时遇到了这个问题,引用内容涉及RMAN备份恢复、参数调整等,说明用户具备一定的DBA基础。 用户的核心痛点是LOB对象在临时表空间无法自动释放,导致空间持续增长。这个问题在Oracle 11.2.0.4中确实比较典型,通常与LOB操作(如CLOB/BLOB处理)后的清理机制有关。需要从多个层面考虑解决方案: 首先想到的是临时表空间组机制(引用2提到undo表空间,但未提临时表空间组)。在11g中引入的这个功能可以动态分配临时文件,比传统单文件管理更灵活。建议用户创建临时表空间组并设为默认,这样当某个临时文件被LOB占用时,系统会自动切换到其他文件。 其次要注意会话级清理问题。很多DBA会忽略ALTER SYSTEM KILL SESSION后未提交事务残留的临时段(引用3的RMAN操作可能产生此类会话)。需要强调在kill session后必须用ALTER SYSTEM DISCONNECT SESSION才能真正释放资源。 另外LOB存储参数也值得关注。用户可能在创建LOB列时使用了不恰当的DISABLE STORAGE IN ROW设置,导致小对象也存储在临时表空间。应该检查相关表的DDL,确保启用STORAGE IN ROW。 诊断方面补充两点:除了监控V$TEMPSEG_USAGE,还要结合DBA_SEGMENTS看OBJECT_NAME=&#39;TEMPORARY&#39;的段类型;事件诊断时建议先设置max_dump_file_size防止trace过大。 考虑到用户环境是11.2.0.4,最后特别提醒要检查补丁。MOS文档#1296652.1记载的这个版本存在LOB临时段泄露的bug,应用PSU 11.2.0.4.3能解决。 用户应该比较专业,所以给出了重启数据库这个终极手段——虽然暴力但有效。不过要提醒ta在业务低峰期操作,避免影响生产环境。</think>针对Oracle 11.2.0.4中临时表空间因LOB占用未释放的问题,以下是系统化的解决方案: --- ### **原因分析** LOB(大对象)操作(如`CLOB`/`BLOB`处理)可能因以下原因导致临时段未释放: 1. **会话异常终止**:会话未正常关闭导致临时段残留。 2. **事务未提交/回滚**:长时间未提交的事务持有临时段。 3. **LOB存储参数不当**:`DISABLE STORAGE IN ROW` 强制LOB使用临时表空间。 4. **Bug或内存泄漏**:Oracle 11.2.0.4 存在已知的临时段管理缺陷(需检查补丁状态)[^1]。 --- ### **解决方案** #### **1. 强制释放临时段** ```sql -- 终止持有临时段的会话 ALTER SYSTEM KILL SESSION &#39;sid,serial#&#39; IMMEDIATE; -- 手动收缩临时表空间 ALTER TABLESPACE temp SHRINK SPACE; ALTER TABLESPACE temp SHRINK TEMPFILE &#39;/path/tempfile.dbf&#39;; ``` #### **2. 优化LOB存储参数** ```sql -- 检查LOB列的存储设置 SELECT table_name, column_name, cache, storage FROM dba_lobs WHERE owner = &#39;YOUR_SCHEMA&#39;; -- 修改为启用行内存储(避免使用临时表空间) ALTER TABLE your_table MODIFY LOB(your_lob_column) (STORAGE IN ROW); ``` #### **3. 使用临时表空间组** ```sql -- 创建临时表空间组 CREATE TEMPORARY TABLESPACE temp1 TEMPFILE &#39;/path/temp1.dbf&#39; SIZE 1G; CREATE TEMPORARY TABLESPACE temp2 TEMPFILE &#39;/path/temp2.dbf&#39; SIZE 1G; CREATE TEMPORARY TABLESPACE GROUP temp_grp; ALTER TABLESPACE temp1 TABLESPACE GROUP temp_grp; ALTER TABLESPACE temp2 TABLESPACE GROUP temp_grp; -- 设置为默认临时表空间 ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp_grp; ``` #### **4. 监控与诊断** ```sql -- 检查占用临时段的会话 SELECT s.sid, s.serial#, s.username, s.sql_id, t.blocks*8/1024 "MB Used" FROM v$session s JOIN v$tempseg_usage t ON s.saddr = t.session_addr; -- 检查LOB操作是否使用临时表空间 SELECT * FROM v$temp_lob; ``` #### **5. 应用补丁** - 检查是否应用以下关键补丁: - **Bug 1296652.1**:修复临时LOB空间未释放问题。 - **PSU 11.2.0.4.3+**:包含多个临时段管理优化[^2]。 - 升级到更高版本(如12c+)可彻底解决部分遗留问题。 #### **6. 重启数据库(终极方案)** 若临时段被锁定无法释放,重启实例会强制清理所有临时段: ```bash sqlplus / as sysdba > shutdown immediate > startup ``` --- ### **预防措施** 1. **代码优化**: - 显式释放LOB资源:执行`DBMS_LOB.FREETEMPORARY(lob_loc)`。 - 避免在循环中创建临时LOB。 2. **定期维护**: ```sql -- 每天检查临时表空间使用 SELECT tablespace_name, bytes_used/1024/1024 "Used (MB)" FROM v$temp_extent_pool; ``` 3. **参数调整**: ```sql -- 增加PGA减少临时表空间压力 ALTER SYSTEM SET pga_aggregate_target=4G; ``` --- ### **关键引用** > **诊断脚本**:`v$tempseg_usage` 和 `dba_lobs` 是定位问题的核心视图[^1]。 > **补丁修复**:MOS文档 #1296652.1 明确记录了11.2.0.4的LOB临时段泄漏缺陷[^2]。 > **重启必要性**:当临时段被标记为损坏时,重启是唯一解(Alert日志会记录`ORA-01578`错误)[^3]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值