Oracle CRS 启动问题诊断
#工程师培训# #CRS# 从10g开始,Oracle使用自己的CRS管理RAC集群,到了11g、12c,voting disk,ocr,共享存储等等都由Oracle自己的集群软件管理(从11g开始,名称由CRS调整为GI——Grid Infrastructure)。 对外提供服务的数据库集群,依赖于底层GI。而GI要求共享存储、网络通讯、节点间进程通讯都准备就绪,才能正常运行。GI本就是由许多组件构成的集群(复杂)管理系统,雪上加霜的是,由于GI的日志输出中,有过多的Info级别的信息,且各个组件都有自己的日志,这些都造成了如果GI启动不成功,定位故障点比较困难。 本文结合MOS 《Troubleshoot Grid Infrastructure Startup Issues》一文对GI启动问题进行梳理。 首先还是来说日志,先要能确定其存储位置: Oracle 10g, 存储于$GRID HOME/log/name>/… ,当然在10g中其实还没有明确定义GRID HOME。 Oracle 11g, $GRID HOME/log/name>/ , 好像跟10g的没有区别 Oracle 12c,发生了改变,不加注意,容易在出问题时找不到日志 3.1 Standard cluster: $ORACLE_BASE/diag/crs/… 位置发生了改变,并且彻底使用ADR来管理日志。 3.2 Flex cluster: $ORACLE HOME/log/name> 因为Grid Infrastructure组件较多(CRSD,CSSD,EVENTD…),所以日志也就很多,总体来说,应该先查看alert.log ,再查看各组件的日志。 即使你已经对于去哪里能找到Grid Infrastructure的日志很清楚,真正面对目录中那么多日志、trace,以及日志中不知道什么意思的各种输出,很容易迷失。我的经验是,在“陷入”日志之前,先从操作系统角度查找一下,有没有什么明显的问题,导致Grid Infra不能启动。 OS级别的检查: 网络PING,将/etc/hosts中定义的,集群内的各个IP都ping一下 共享存储,以及其权限 文件系统空间使用、inode使用(Grid Infra经常因为产生日志太多,用尽inode,把自己撑死) … 总觉得还有别的,以后想到再补充 GI 启动顺序 操作系统启动ohasd —》