weblogic连接池配置_weblogic连接scan ip_weblogic长连接(14)

以上一段代码的主要意思是：如果存在/opt/nmapi/nmapi2/libnmapi2.so文件，那么表示系统使用了Vendor Clusterware，也就是使用了第三方集群软件。如果存在/opt/nmapi/nmapi2/bin/clsinfo文件，则表示系统使用了其他的第三方集群软件，并且该文件可以执行用于判断是否已经启动Vendor Clusterware，即VC_UP=/opt/nmapi/nmapi2/bin/clsinfo。如果不存在该文件，表示系统使用的是HP ServiceGuard，那么VC_UP="$PSEF | $GREP '/usr/lbin/cm[g]msd' 1>$NULL 2>$NULL" ,即判断cm开头的一些进程是否在运行，用来判断Service Guard是否在运行。从sh -x执行结果来看，脚本认为系统用的是Service Guard，很显然，这个是错误的，一直在等待Service Guard启动，那这样很明显就会一直等待而挂起。

那么到目前为止，可以知道是由于错误地判断了Vendor Clusterware引起了问题，那么用于判断Vendor Clusterware的文件/opt/nmapi/nmapi2/bin/clsinfo应该不存在于系统中。/opt/nmapi/nmapi2/bin目录下的确没有clsinfo这个文件。而/opt/nmapi/nmapi2/lib目录下存在相应的库文件：

cwxndb01:[/opt/nmapi/nmapi2/lib/hpux64]#ll
total 0
lr-xr-xr-x   1 bin        bin             27 Jul 18 13:33 libnmapi2.so -> /usr/lib/hpux64/libvcsmm.so

可以看到库文件用的是symantec sfrac的库文件。

而bin目录下没有任意文件，看起来应该是symantec sfrac安装的BUG。

那怎么样来解决这个问题呢，知道了原因，解决就很简单了：

cwxndb01:[/opt/nmapi/nmapi2]#cd /opt/nmapi/nmapi2/bin
cwxndb01:[/opt/nmapi/nmapi2/bin]#ln -s /opt/VRTSvcs/ops/bin/clsinfo

只需要在这个目录下建一个链接即可。做完上述操作后，再清理掉环境，重新运行root.sh，一切顺利。

这个问题引起的根本原因，看起来是Symantec SFRAC安装的一个bug。不过总的来说，新版本的SFRAC环境下安装RAC已经方便很多，跟普通方式安装CRS没有任何区别，而早期版本的SFRAC环境下安装RAC，需要使用SFRAC提供的专用界面进行安装。

--The End---

crs, install

客户的一套重要生产系统，出现了性能问题。这个问题涉及的信息如下：

主机的CPU利用率长期在100%左右。

应用系统在晚上进行调整后，开始出现了问题。

中出现大量的latch: shared pool、latch: library cache、cursor: pin S、latch: cache buffers chains和latch: cache buffers lru chain等各种等待。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-30053-14.html