GI upgrade 从11.2.0.2.0到11.2.0.2.5失败

2^#

发表于 2012-5-3 15:09:52

action plan:

贴出以下命令的输出

cat /etc/oraInst.loc
ls -ld $ORACLE_HOME/.patch_storage
ls -ld $ORACLE_HOME

3^#

发表于 2012-5-3 15:13:58

$cat /etc/oraInst.loc
inventory_loc=/home/grid/oraInventory
inst_group=oinstall

ls -ld $ORACLE_HOME/.parch_storage
/grid/product/11.2/.parch_storage not found

ls -ld $ORACLE_HOME
drwxr-xr-x 68 root oinstall 4096 May 2 23:03 /grid/product/11.2

4^#

发表于 2012-5-3 15:15:15

action plan:

su - grid -- GI 的拥有者用户

touch $ORACLE_HOME/testfile

贴出以上输出

5^#

发表于 2012-5-3 15:16:28

$ORACLE_HOME/.patch_storage
/grid/product/11.2/.patch_storage not found

6^#

发表于 2012-5-3 15:18:57

$id
uid=1100(grid) gid=1000(oinstall) groups=1001(dba)
$touch $ORACLE_HOME/testfile
touch: /grid/product/11.2/testfile cannot create

7^#

发表于 2012-5-3 15:21:24

第一种：No read or write permission to ORACLE_HOME/.patch_storage

你的 grid 用户对 $ORACLE_HOME 没有写的权限，所以当然无法创建 ORACLE_HOME/.patch_storage 目录，这导致安装 PSU失败

8^#

发表于 2012-5-3 15:25:09

安装GI 在执行root.sh的时候GI_HOME不是已经变成root:oinstall的权限了吗。这个应该没有问题的啊。

9^#

发表于 2012-5-3 18:49:00

把你 opatch 安装GI psu的命令列出来

10^#

发表于 2012-5-4 13:56:52

谢谢刘大，问题已经找到了，像你所说的是权限的问题。

首先：GI在安装的时候执行完root.sh后GI_HOME的权限被改成了755，并且是root用户权限。

GI从11.2.0.2.0到11.2.0.2.5升级过程回顾：
1、$opatch auto /soft -oh $GI_HOME
一开始我是auto模式升的，查看日志的时候，进行到

rootcrs.pl -unlock步骤的时候，只有停crs的过程，

然后就停止不动了，

但是DB升级已经success。

所以我退出再进行

manual模式升级。

2、<GI_HOME>/crs/install/rootcrs.pl -unlock

在执行

rootcrs.pl -unlock的时候很长时间都没有反应。（为什么没有反应现在还不明白）

3、<GI_HOME>/crs/install/rootcrs.pl -patch

4、$opatch napply -oh $ORACLE_HOME -local /soft/13653086
操作过程中就发现不能创建 ORACLE_HOME/.patch_storage目录了。

在你的提示后，我检查GI_HOME的权限为755.
而组属为root:oinstall，所以grid用户没有权限对GI_HOME写操作。
现在的理解为：

rootcrs.pl -unlock 应该有修改目录权限

过程，但是这个步骤没有正常完成，权限没有被修改。
而在opatch napply -oh $ORACLE_HOME -local /soft/13653086手动升级之前没有修改GI_HOME的权限至775，导致grid用户无法对GI_HOME进行写操作。
No read or write permission to ORACLE_HOME/.patch_storage 。

11^#

发表于 2012-5-5 21:57:06

测试确认

$CRS_HOME/crs/install/rootcrs.pl -unlock  会让$CRS_HOME的owner从 root 变成实际的 GI owner 如grid 用户：

[root@vrh1 ~]# $CRS_HOME/crs/install/rootcrs.pl -unlock
Using configuration parameter file: /g01/11.2.0/grid/crs/install/crsconfig_params
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'vrh1'
CRS-2673: Attempting to stop 'ora.crsd' on 'vrh1'
CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on 'vrh1'
CRS-2673: Attempting to stop 'ora.LISTENER.lsnr' on 'vrh1'
CRS-2673: Attempting to stop 'ora.LISTENER_SCAN1.lsnr' on 'vrh1'
CRS-2673: Attempting to stop 'ora.SYSTEMDG.dg' on 'vrh1'
CRS-2673: Attempting to stop 'ora.BACKUPDG.dg' on 'vrh1'
CRS-2673: Attempting to stop 'ora.DATA.dg' on 'vrh1'
CRS-2673: Attempting to stop 'ora.LSN_MACLEAN.lsnr' on 'vrh1'
CRS-2673: Attempting to stop 'ora.vrh2.vip' on 'vrh1'
CRS-2677: Stop of 'ora.vrh2.vip' on 'vrh1' succeeded
CRS-2677: Stop of 'ora.LSN_MACLEAN.lsnr' on 'vrh1' succeeded
CRS-2677: Stop of 'ora.LISTENER.lsnr' on 'vrh1' succeeded
CRS-2673: Attempting to stop 'ora.vrh1.vip' on 'vrh1'
CRS-2677: Stop of 'ora.LISTENER_SCAN1.lsnr' on 'vrh1' succeeded
CRS-2673: Attempting to stop 'ora.scan1.vip' on 'vrh1'
CRS-2677: Stop of 'ora.vrh1.vip' on 'vrh1' succeeded
CRS-2677: Stop of 'ora.scan1.vip' on 'vrh1' succeeded
CRS-2677: Stop of 'ora.BACKUPDG.dg' on 'vrh1' succeeded
CRS-2677: Stop of 'ora.DATA.dg' on 'vrh1' succeeded
CRS-2677: Stop of 'ora.SYSTEMDG.dg' on 'vrh1' succeeded
CRS-2673: Attempting to stop 'ora.asm' on 'vrh1'
CRS-2677: Stop of 'ora.asm' on 'vrh1' succeeded
CRS-2673: Attempting to stop 'ora.ons' on 'vrh1'
CRS-2677: Stop of 'ora.ons' on 'vrh1' succeeded
CRS-2673: Attempting to stop 'ora.net1.network' on 'vrh1'
CRS-2677: Stop of 'ora.net1.network' on 'vrh1' succeeded
CRS-2792: Shutdown of Cluster Ready Services-managed resources on 'vrh1' has completed
CRS-2677: Stop of 'ora.crsd' on 'vrh1' succeeded
CRS-2673: Attempting to stop 'ora.crf' on 'vrh1'
CRS-2673: Attempting to stop 'ora.ctssd' on 'vrh1'
CRS-2673: Attempting to stop 'ora.evmd' on 'vrh1'
CRS-2673: Attempting to stop 'ora.asm' on 'vrh1'
CRS-2673: Attempting to stop 'ora.mdnsd' on 'vrh1'
CRS-2677: Stop of 'ora.crf' on 'vrh1' succeeded
CRS-2677: Stop of 'ora.evmd' on 'vrh1' succeeded
CRS-2677: Stop of 'ora.mdnsd' on 'vrh1' succeeded
CRS-2677: Stop of 'ora.ctssd' on 'vrh1' succeeded
CRS-2677: Stop of 'ora.asm' on 'vrh1' succeeded
CRS-2673: Attempting to stop 'ora.cluster_interconnect.haip' on 'vrh1'
CRS-2677: Stop of 'ora.cluster_interconnect.haip' on 'vrh1' succeeded
CRS-2673: Attempting to stop 'ora.cssd' on 'vrh1'
CRS-2677: Stop of 'ora.cssd' on 'vrh1' succeeded
CRS-2673: Attempting to stop 'ora.gipcd' on 'vrh1'
CRS-2677: Stop of 'ora.gipcd' on 'vrh1' succeeded
CRS-2673: Attempting to stop 'ora.gpnpd' on 'vrh1'
CRS-2677: Stop of 'ora.gpnpd' on 'vrh1' succeeded
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'vrh1' has completed
CRS-4133: Oracle High Availability Services has been stopped.
Successfully unlock /g01/11.2.0/grid

[root@vrh1 ~]# ls -ld $CRS_HOME
drwxr-xr-x 66 grid oinstall 4096 Nov  7 19:46 /g01/11.2.0/grid

[root@vrh1 ~]# ls -ld $CRS_HOME/install
drwxr-xr-x 8 grid oinstall 4096 Nov  7 20:02 /g01/11.2.0/grid/install

如果$CRS_HOME/crs/install/rootcrs.pl -unlock  运行不成功，请手动停止HAS 并手动修改$CRS_HOME的owner:

crsctl stop has
chown  grid:oinstall $CRS_HOME

12^#

发表于 2012-5-6 00:21:21

再次感谢刘大的回复，关于这个问题也开了SR，给我的回复是：

After run root.sh, the related directory will be changed to 755 and root permission, this is expect behavior.

So before apply PSU, if you apply PSU as manual way, then please as the root user execute the following command to change the permission:

<GI_HOME>/crs/install/rootcrs.pl -unlock

after apply the PSU, please as the root user execute, which will change the permission back.

<GI_HOME>/crs/install/rootcrs.pl -patch

So if you apply PSU as auto way, then above steps will be run automaticly.
另外一个关于为什么unlock的时间很长没有反应，SR回复是：

"rootcrs.pl -unlock" or "roothas.pl -unlock" will go through all files in $GRID_HOME/rdbms/audit and change ownership and permission individually, if the list of files is huge, it will take long time which appears like it's hanging.

To workaround the issue, either wait till the script changes all files in audit location, or backup and move the audit files to a backup location outside GRID_HOME.

audit file location is $GRID_HOME/rdbms/audit.

后来也做了几次对比
在RHEL 5.5上测试GI upgrade from 11.2.0.2.0 to 11.2.0.2.5 automaticly 持续时间20分钟左右。
在HP-UX 11iV3上测试GI upgrade from 11.2.0.2.0 to 11.2.0.2.5 automaticly持续时间25~30分钟左右。
在AIX 6上测试GI upgrade from 11.2.0.2.0 to 11.2.0.2.5 automaticly持续时间超过30分钟没有完成。（根据Oracle Support的解释是需要等待，但是具体要多少时间，现在还没测试）
有点不太理解，为什么GI同一个版本，在HP和RHEL server上automaticly升级可以正常unlock，而在AIX上却会有这样的问题。
在升级的过程中有注意到日志中有这样一条：
If this is AIX, please perform solution documented in Note 739963.1 on https://myoraclesupport.oracle.com. 这是不是就是导致GI打PSU时，在AIX上unlock不成功的原因呢？？