【环境介绍】
系统环境:Solaris + Oracle 11R2 + OGG + 脚本定时任务统计信息收集
【背景描述】
基于集团的安全检查,需要对数据库版本进行漏洞扫描,漏洞扫描中存在RBDMS和JVM类型的漏洞,需要通过升级小版本的PSU和OJVM来修复漏洞。下面大概说明一下升级的注意部分和出现问题的解决。
【问题处理】
升级时一般在晚上操作,在升级数据库前注意的问题(由于脚本较多,这里贴脚本,如果有需要脚本可以留言):
提前进行数据库软件备份(可排除aud小文件,备份小文件多导致备份时间很长,建议可以提前一天备份),数据备份(数据库全备);
数据库参数备份,工程完成后参数对比(历史原因导致启动数据库pfile文件参数不同导致主机资源耗尽或者其他问题);
停止涉及数据库定时任务(防止大事务导致数据库停止有问题);
停止数据库自动统计信息或者手动脚本的统计信息收集(导致升级后编译时不能进行);
停止其他软件对数据库的操作(OGG等,OGG进程卡主);
操作系统空间需要大于35G(如果空间不足可能触发BUG:
10131946 GRID PATCHES REQUIRE 22GB OF FREE SPACE
12791141 PATCH 12311357: WITH 35GB FREE SPACE : ERROR: REQUIRED AMOUNT OF SPACE
1088455.1 opatch CheckSystemSpace Fails With Error Code 73 While Applying GI PSU);
操作系统LANG字符问题(可触发BUG,导致升级报错),建议默认使用英文字符;
补丁冲突(DB,有些针对one of patch冲突需要在升级前回退,GI),平台检测。
操作数据库升级前,再次进行检查数据库补丁冲突,平台检测,但是补丁需要特殊.so文件验证是在停止数据库实例后进行检查,也是经常出现的文件占用的问题。
检查信息:
grid@XXXDB01:/opt/oracle/app/oracle_base/patch/26636028$ $ORACLE_HOME/OPatch/opatch prereq CheckActiveFilesAndExecutables -phBaseDir ./26635745
Oracle Interim Patch Installer version 11.2.0.3.18
Copyright (c) 2018, Oracle Corporation. All rights reserved.
PREREQ session
Oracle Home : /opt/oracle/app/grid_home
Central Inventory : /opt/oracle/app/oraInventory
from : /opt/oracle/app/grid_home/oraInst.loc
OPatch version : 11.2.0.3.18
OUI version : 11.2.0.4.0
Log file location : /opt/oracle/app/grid_home/cfgtoollogs/opatch/opatch2018-04-27_01-50-50AM_1.log
Invoking prereq "checkactivefilesandexecutables"
......
Prereq "checkActiveFilesAndExecutables" for patch 17478514 failed.
The details are:
Following executables are active :
/opt/oracle/app/grid_home/bin/oracle
/opt/oracle/app/grid_home/lib/libclntsh.so.11.1
Prereq "checkActiveFilesAndExecutables" for patch 18031668 passed.
.......
Prereq "checkActiveFilesAndExecutables" for patch 26392168 passed.
OPatch succeeded.
省略部分内容,可以看到对特殊文件检查时发现被占用。查看是哪个进程占用:
grid@xxxxDB01:/opt/oracle/app/oracle_base/patch/26636028$ fuser /opt/oracle/app/grid_home/lib/libclntsh.so.11.1
/opt/oracle/app/grid_home/lib/libclntsh.so.11.1: 9465m 9447m 9331m 9210m 8889m 8750m 8578m 8498m 8496m 8494m 8417m 8416m 8395m 21708m 8361m 8286m 8164m 14225m 14198m 14186m
但是存在一个进程,且是root用户占用,集群不能停止该进程:
root@xxxDB01:/opt/oracle/app/oracle_base/patch/26636028# ps -ef |grep /opt/oracle/app/grid_home/jdk/bin/sparcv9/java
root 21708 4111 0 02:37:17 pts/1 0:00 grep /opt/oracle/app/grid_home/jdk/bin/sparcv9/java
正常情况下,占用该文件的位grid用户,在升级数据库时会停止这些进程。
[grid@xxxx01 ~]$ fuser /u01/app/11.2.0/grid/lib/libclntsh.so.11.1
/u01/app/11.2.0/grid/lib/libclntsh.so.11.1: 2400m 2411m 2422m 2432m 2491m 2623m 2837m 2885m 2887m 2984m 2985m 3029m 3046m
[grid@xxxx01 ~]$ ps -ef |egrep '2400|2411|2422|2432|2491|2623|2837|2885|2887|2984|2985|3029|3046'
grid 2400 1 0 10:48 ? 00:00:00 /u01/app/11.2.0/grid/bin/oraagent.bin
grid 2411 1 0 10:48 ? 00:00:00 /u01/app/11.2.0/grid/bin/mdnsd.bin
grid 2422 1 0 10:48 ? 00:00:00 /u01/app/11.2.0/grid/bin/gpnpd.bin
grid 2432 1 0 10:48 ? 00:00:00 /u01/app/11.2.0/grid/bin/gipcd.bin
grid 2491 1 0 10:48 ? 00:00:00 /u01/app/11.2.0/grid/bin/ocssd.bin
grid 2623 1 0 10:49 ? 00:00:00 /u01/app/11.2.0/grid/bin/evmd.bin
grid 2837 2623 0 10:50 ? 00:00:00 /u01/app/11.2.0/grid/bin/evmlogger.bin -o /u01/app/11.2.0/grid/evm/log/evmlogger.info -l /u01/app/11.2.0/grid/evm/log/evmlogger.log
grid 2885 1 0 10:50 ? 00:00:00 /u01/app/11.2.0/grid/bin/scriptagent.bin
grid 2887 1 0 10:50 ? 00:00:00 /u01/app/11.2.0/grid/bin/oraagent.bin
grid 2984 1 0 10:50 ? 00:00:00 /u01/app/11.2.0/grid/opmn/bin/ons -d
grid 2985 2984 0 10:50 ? 00:00:00 /u01/app/11.2.0/grid/opmn/bin/ons -d
grid 3029 1 0 10:50 ? 00:00:00 /u01/app/11.2.0/grid/bin/tnslsnr LISTENER_SCAN1 -inherit
grid 3046 1 0 10:50 ? 00:00:00 /u01/app/11.2.0/grid/bin/tnslsnr LISTENER -inherit
【解决办法】
关于特殊.so文件验证发现文件被占用时,使用以下方法确认:
若有文件被占用,把占用进程杀掉:
opatch error code 73: Prerequisite check "CheckActiveFilesAndExecutables" failed. (文档 ID 1942237.1)
通过核查为OC4J资源online导致特殊文件被该进程占用,使用crsctl stat res -t查看OC4J资源状态,该资源会导致8888漏洞,建议停止该资源,关于修改OC4J可查看官方文档
Security Vulnerability Scan detects Exposed Port on ora.oc4j Resource (文档 ID 1922349.1)
【总结】
在工程中,一定确保工程前环境已经检查完成,这样才能使过程中遇到更多的问题。
在升级中遇到问题,仔细查看升级日志中的报错信息,才能准确判断产生问题的原因。
方案准备一定要充分,方案审核一定要仔细,遇到问题后一定要在方案中添加内容,防止下次工程遇到同样的问题。