opatch升级时的非常规操作技巧

点击上方蓝字关注我们

在客户现场进行oracle维护过程中，因为BUG、安全等方面原因进行opatch补丁升级时。但不同现场安装、运行环境的不同、安全加固等原因，导致总是会遇到目录权限、应用补丁后无法启动、opatchapply到一半时窗口中断的各种问题。下面我们介绍一些打补丁过程中的遇到的一些非常规操作技巧。

在AIX操作系统的RAC环境中，你是否遇到过在手动打补丁时一条命令1.5小时不结束的问题？如果是自动补丁更新时，消耗的时间可能会更长。虽然在集群环境中，滚动升级慢不影响数据库对外提供服务，但是面对核心系统时，可操作的时间并不多，如果超时了，剩下的节点会有支撑不住高峰时期的访问的问题。

排除了服务器的CPU、内存、I/O的问题，检查opatch的操作日志，并没有任何报错信息。

如上图所示，可以看出opatch是用java开发的。既然是jdk的环境，就有很大机率是SecureRandom性能问题，SecureRandom的性能问题通常的解决方案是使用

"-Djava.security.egd=file:/dev/./urandom"

加快随机数产生过程。

进入$GI_HOME和$ORACLE_HOME的opatch目录

cdjre/lib/security/

cd$ORACLE_HOME/OPatch

修改java.security文件

把securerandom.source=file:/dev/urandom修改为securerandom.source=file:/dev/./urandom

保存文件。

最终效果：opatchapply的命令时间由1.5小时下降为10分钟。

众所周知，oracle19.3版本的集群环境中，在opatch升级时，因为oraInventory/ContentsXML目录下的oui-patch的权限问题，在打DBpatch时除了第一节点之外，均会有如下报错：

手动打补丁报错信息：

自动打补丁报错信息：

Patch: /tmp/grid_path/30116789/30122149  
Log: /u01/app/oracle/product/19.3.0/db_1/cfgtoollogs/opatchauto/core/opatch/opatch2020-03-09_17-44-51PM_1.log  
Reason: Failed during Patching: oracle.opatch.opatchsdk.OPatchException: ApplySession failed in system modification phase... 'ApplySession::apply failed: java.io.IOException: oracle.sysman.oui.patch.PatchException: java.io.FileNotFoundException: /u01/app/oraInventory/ContentsXML/oui-patch.xml (Permission denied)'  
   
After fixing the cause of failure Run opatchauto resume  
    
]  
OPATCHAUTO-68061: The orchestration engine failed.  
OPATCHAUTO-68061: The orchestration engine failed with return code 1  
OPATCHAUTO-68061: Check the log for more details.  
OPatchAuto failed.  
    
OPatchauto session completed at Mon Mar  9 17:45:31 2020  
Time taken to complete the session 1 minute, 16 seconds  
   
opatchauto failed with error code 42  

当然如果oui-patch.xml文件在执行chmod+w 解决完权限问题之后，opatchautoresume可以自动执行，但是如果你是手动打补丁，权限问题解决之后并不能解决问题，并且不能回退，如下图所示：

上述问题可以通过如下方法可以避免和解决：

a)、在开始打除了第一节点之外的DBpatch之前，就执行chmod+w

b)、安装时加上applyPSU参数

c)、还原备份文件

d)、如果此时你也没有备份，那能做的只有删除再添加节点了。

下面介绍两种非常规操作：

1）修改oui-patch.xml文件

cd $ORACLE_HOME/inventory/ContentsXML

cp oui-patch.xml oui-patch.xmlbak

vioui-patch.xml，搜索报错的补丁号30894985，把下面的内容从<ONEOFFREF_ID…>到</REF_LIST>的内容删除

再次执行打补丁的命令，opatchsuccessfully。

在11.2、12.1.2版本中需要修改的文件是$ORACLE_HOME/inventory/ContentsXML/comps.xml文件

2）如果有超过2个节点以上的集群环境，可以从其它未打补丁的同样目录把oui-patch.xml文件拷贝到故障节点覆盖文件，同样可以解决问题。

上述方法同样适用于打补丁过程中的窗口异常中断问题。

在打补丁的过程中，如果遇到目录和文件的权限问题，如果仅是有限几个目录和文件的权限问题，我们可以直接用chmod修复就可以，但如果遇到误操作使/u01目录下的文件异常，推荐使用oracle官方技术支持网站提议的两篇文件进行修复。

1、Scriptto capture and restore file permission in a directory (for eg.ORACLE_HOME) (Doc ID 1515018.1)

2、Howto check and fix file permissions on Grid Infrastructure environment(Doc ID 1931142.1)

但针对第二个文章中的权限修复中，执行修复前建议先执行如下命令，因为crsconfig_fileperms、crsconfig_dirs文件中记录的目录和文件并不是/u01目录下的全部目录、文件。

chown -R grid:oinstall u01

chown -R oracle:oinstall u01/app/oracle

chmod -R 775 /u01