使用过Oracle Clusterware 10gR1的朋友应该还记得各个后台进程的log都被散乱地放在各自的目录中，可惜的是，也许你刚刚熟悉了每个log的位置，然后当你将10gR1升级到10gR2，你就发现所有的log你都找不到了，它们不再在原来的位置，Oracle重新整理放在了统一的目录下。 这里记录一下10gR2和11gR1中Oracle Clusterware的log位置。以下$ORACLE_HOME指Oracle RDBMS软件的安装目录，$ORA_CRS_HOME指Oracle Clusterware软件的安装目录。 CRS logs $ORA_CRS_HOME/log/[hostname]/crsd/ CSS logs $ORA_CRS_HOME/log/[hostname]/cssd/ EVM logs $ORA_CRS_HOME/log/[hostname]/evmd $ORA_CRS_HOME/evm/log/ Resource logs $ORA_CRS_HOME/log/[hostname]/racg $ORACLE_HOME/log/[hostname]/racg SRVM logs $ORA_CRS_HOME/log/[hostname]/client $ORACLE_HOME/log/[hostname]/client Cluster Network Communication logs $ORA_CRS_HOME/log OPMN logs $ORA_CRS_HOME/opmn/logs alert logs $ORA_CRS_HOME/log/[hostname]/alert[hostname].log OPROCD logs /var/opt/oracle/[hostname] CLSOMON files $CRS_HOME/log/[hostname]/cssd/oclsomon 当Oracle Clusterware发生问题的时候，需要寻求Oracle Support的帮助，那么这些位置的log都是可能会需要的。 我们也可以使用在10gR2之后Oracle提供的perl脚本来获取诊断信息。 在10gR2版本中，执行： $ORA_CRS_HOME/bin/diagcollection.pl -collect 在11gR1版本中，执行： $ORA_CRS_HOME/bin/diagcollection.pl -crshome=$ORA_CRS_HOME -collect 该脚本执行结束以后，将会产生几个tar.gz文件，包括crsData_[hostname].tar.gz，ocrData_[hostname].tar.gz，oraData_[hostname].tar.gz和basData_[hostname].tar.gz 。…
Tag: Oracle Clusterware
Using Diagwait during Oracle Clusterware Node evictions
什么情况下Oracle Clusterware会重启（Evict，驱逐）节点机器？ 1. 节点机器在interconnect network上无法ping通，没有了network heartbeat，比如网络问题。 2. 节点机器无法存取Voting Disk，没有了disk heartbeat，比如磁盘问题。 3. 由于节点机器过于繁忙，导致没有空闲资源来完成上述的两种动作之一，比如CPU问题，内存问题。 具体的Timeout算法参看Metalink Note：294430.1。 通常，在某个节点被驱逐之后，cssd.log或者crsd.log或者操作系统自身的log中会有具体的信息记载，通过这些log可以知道到底是什么原因导致了节点被驱逐。但是，可能在某些情况下，由于操作系统在被强行reboot之前过于繁忙，根本没有任何空余的CPU时间片来将内存中的log内容写入到磁盘log文件中，这时候，我们在log中看到的就是忽然的一段时间空白之后就是Cluster重新启动的信息了。 在10.2.0.3之后，我们可以设置diagwait，来延迟eviction，让系统在重启之前等待几秒，尽量让log可以写入到磁盘上。该功能目前已经backport到10.1.0.5中，因此在 10.1.0.5 (or higher), 10.2.0.3 (or higher) 和11.1.0.6 (or higher)这些版本中都可以设置diagwait。 注：set diagwait不仅仅会延迟eviction，同时会将oprocd进程的检查margin从默认的500ms（10205中是1500ms）提升到10000ms（也就是10秒），opocd如果发现两次检查的时间间隔超过margin值，就会强制重启服务器，所以实际上set diagwait同样提高了RAC环境的稳定性。 在不支持的版本中设置diagwait将会得到”unrecognized parameter diagwait specified” 错误提示。 设置diagwait的方法，使用root用户执行以下命令： 1. 停止Clusterware #crsctl stop crs #/bin/oprocd stop 2. 确认Clusterware stack已经完全关闭 #ps -ef |egrep “crsd.bin|ocssd.bin|evmd.bin|oprocd” 3. 在集群的任意节点上设置diagwait等待时间13秒 #crsctl set css diagwait 13…
RAC10gR2 on HP-UX IA64
这几天经历了有史以来最痛苦的Oracle 10gR2 RAC的安装体验。 操作系统是HP-UX IA64，原本是两台已经安装过Oracle10gR2 CRS+RAC的系统，在安装完之后做了安全控制，取消了很多服务，然后机器从北京搬到上海，存储换了（意味着OCR和Voting Disk没有了），主机名称换了，网卡ID换了，IP地址换了（意味着重新构建OCR Disk很麻烦），在这样的一台机器上要重新安装RAC。 多次的失败之后，要求HP工程师重新安装了操作系统，从上周五白天一直到今天晚上才完全搞定，在今天晚上22：00才最后发现原来一切一切不可思议的问题都是源自于一个小小的环节，以往几天甚至对CRS在HP-UX上的稳定性都产生了极大的怀疑。 现象是，css/crs/evm这些后台进程用ps看全部都是正常的，但是crs_stat命令始终报无法连接CRS Daemon；重新启动机器之后有时候一个节点正常了，但是另外一个节点不正常，再次重启，不正常的节点可能又正常了；好不容易两个节点都正常了，数据库软件也安装完毕了，数据库也创建了，最后再重启一下两台机器，CRS又不正常了。。。几乎抓狂！ 最后，焦点聚集到网卡的全双工和半双工设置上，网络集成商在屡次确认网络配置确实没有问题之后，在客户的强烈要求下，最后又再次检查了一下交换机，发现交换机上有两个端口设置成了半双工+自适应，而主机上的网卡全部都是全双工+非自适应，而这两个端口恰恰是连接某台数据库服务器上的Public网卡。就是这个网络设置上全双工和半双工的不匹配，让CRS发生了各种古怪的现象。 一切问题都在把交换机端口也设置为全双工+非自适应之后荡然无存。 这篇文章的意思是：CRS不是想象中那么不稳定，如果在安装过程中或者安装完毕有奇怪的现象，那么第一个要找的不是CRS软件本身，而是操作系统以及网络设置。