1.问题现象
在oracle用户下无法使用srvctl,报错信息如下。
RACDB1@rac1 /home/oracle$ srvctl status database -d RACDB
/oracle/app/oracle/product/10.2.0/db_1/jdk/jre/bin/java: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory
2.问题原因
导致该问题的原因是,在部署安装RAC时仅将clusterware软件目录下srvctl命令中的LD_ASSUME_KERNEL环境变量进行了注销处理,数据库软件安装目录下的srvctl未做相应调整。因PATH环境变量设置顺序,数据库软件的srvctl在前,导致未做调整的srvctl被调用。
RACDB1@rac1 /home/oracle$ which srvctl
/oracle/app/oracle/product/10.2.0/db_1/bin/srvctl
此处的srvctl未做调整。
3.问题处理
针对该问题由两种处理方法。
1)第一种处理方法:将数据库软件目录下srvctl中的LD_ASSUME_KERNEL环境变量注销掉。
(1)使用vi对srvctl进行编辑
RACDB1@rac1 /home/oracle$ vi /oracle/app/oracle/product/10.2.0/db_1/bin/srvctl
(2)注销掉文件中的LD_ASSUME_KERNEL环境变量
可以两种方法完成注销。
第一种方法:使用unset完成注销
#Remove this workaround when the bug 3937317 is fixed
LD_ASSUME_KERNEL=2.4.19
export LD_ASSUME_KERNEL
unset LD_ASSUME_KERNEL
第二种方法:直接在有关LD_ASSUME_KERNEL变量的前面添加“#”号注销
#Remove this workaround when the bug 3937317 is fixed
#LD_ASSUME_KERNEL=2.4.19
#export LD_ASSUME_KERNEL
(3)验证srvctl的可用性
RACDB1@rac1 /home/oracle$ which srvctl
/oracle/app/oracle/product/10.2.0/db_1/bin/srvctl
RACDB1@rac1 /home/oracle$ srvctl status database -d RACDB
Instance RACDB1 is running on node rac1
Instance RACDB2 is running on node rac2
此时,srvctl命令可以正常使用。
2)第二种处理方法:调整PATH环境变量的顺序
既然CRS目录下的srvctl工具已经在安装clusterware时做过调整,我们也可以通过调整PATH环境变量顺序,将CRS目录下的srvctl命令置前,这样可以保证最先得到可用的srvctl命令。
(1)调整PATH环境变量
RACDB1@rac1 /home/oracle$ export PATH=/oracle/app/crs/bin:$PATH
(2)验证srvctl的可用性
RACDB1@rac1 /home/oracle$ which srvctl
/oracle/app/crs/bin/srvctl
RACDB1@rac1 /home/oracle$ srvctl status database -d RACDB
Instance RACDB1 is running on node rac1
Instance RACDB2 is running on node rac2
此时,srvctl命令可以正常使用。
建议采用第一种处理方法,保证所有出现srvctl的地方命令都是正确可用。
4.小结
避免发生文中问题的最根本有效的方法就是在部署完成RAC后,及时对srvctl的这个问题进行调整,防止给后期使用过程中带来不必要的麻烦。
Good luck.
secooler
10.10.19
-- The End --
在oracle用户下无法使用srvctl,报错信息如下。
RACDB1@rac1 /home/oracle$ srvctl status database -d RACDB
/oracle/app/oracle/product/10.2.0/db_1/jdk/jre/bin/java: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory
2.问题原因
导致该问题的原因是,在部署安装RAC时仅将clusterware软件目录下srvctl命令中的LD_ASSUME_KERNEL环境变量进行了注销处理,数据库软件安装目录下的srvctl未做相应调整。因PATH环境变量设置顺序,数据库软件的srvctl在前,导致未做调整的srvctl被调用。
RACDB1@rac1 /home/oracle$ which srvctl
/oracle/app/oracle/product/10.2.0/db_1/bin/srvctl
此处的srvctl未做调整。
3.问题处理
针对该问题由两种处理方法。
1)第一种处理方法:将数据库软件目录下srvctl中的LD_ASSUME_KERNEL环境变量注销掉。
(1)使用vi对srvctl进行编辑
RACDB1@rac1 /home/oracle$ vi /oracle/app/oracle/product/10.2.0/db_1/bin/srvctl
(2)注销掉文件中的LD_ASSUME_KERNEL环境变量
可以两种方法完成注销。
第一种方法:使用unset完成注销
#Remove this workaround when the bug 3937317 is fixed
LD_ASSUME_KERNEL=2.4.19
export LD_ASSUME_KERNEL
unset LD_ASSUME_KERNEL
第二种方法:直接在有关LD_ASSUME_KERNEL变量的前面添加“#”号注销
#Remove this workaround when the bug 3937317 is fixed
#LD_ASSUME_KERNEL=2.4.19
#export LD_ASSUME_KERNEL
(3)验证srvctl的可用性
RACDB1@rac1 /home/oracle$ which srvctl
/oracle/app/oracle/product/10.2.0/db_1/bin/srvctl
RACDB1@rac1 /home/oracle$ srvctl status database -d RACDB
Instance RACDB1 is running on node rac1
Instance RACDB2 is running on node rac2
此时,srvctl命令可以正常使用。
2)第二种处理方法:调整PATH环境变量的顺序
既然CRS目录下的srvctl工具已经在安装clusterware时做过调整,我们也可以通过调整PATH环境变量顺序,将CRS目录下的srvctl命令置前,这样可以保证最先得到可用的srvctl命令。
(1)调整PATH环境变量
RACDB1@rac1 /home/oracle$ export PATH=/oracle/app/crs/bin:$PATH
(2)验证srvctl的可用性
RACDB1@rac1 /home/oracle$ which srvctl
/oracle/app/crs/bin/srvctl
RACDB1@rac1 /home/oracle$ srvctl status database -d RACDB
Instance RACDB1 is running on node rac1
Instance RACDB2 is running on node rac2
此时,srvctl命令可以正常使用。
建议采用第一种处理方法,保证所有出现srvctl的地方命令都是正确可用。
4.小结
避免发生文中问题的最根本有效的方法就是在部署完成RAC后,及时对srvctl的这个问题进行调整,防止给后期使用过程中带来不必要的麻烦。
Good luck.
secooler
10.10.19
-- The End --
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/519536/viewspace-676665/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/519536/viewspace-676665/