日归档:2016 年 1 月 26 日

11.2和12c RAC的ohasd守护进程在不同Linux版本的演变

前面我们已经讲解过11.2 RAC的启动过程,可以注意到,RAC的根守护进程是/etc/init.d/init.ohasd,那么不同版本的Linux中/etc/init.d/init.ohasd是如何启动的呢? 注意:12.1的非Flex Cluster启动过程跟11.2 RAC一致。但是从12.2beta版 RAC的测试结果来看,从12.2开始OUI安装很可能只有Flex Cluster了,没有了11.2的那种普通RAC了。 . Linux4和Linux5中,在完成核内引导(内核被载入内存并运行,初始化所有的设备驱动程序和数据结构等)之后,就通过启动一个用户级程序/sbin/init的方式来启动其他用户级的进程或服务。 所以,init始终是第一个进程,其PID始终为1(ps -aux | less),它是系统所有进程的父进程. 我们看一下这三个文件哪里不同: 可以看出,/etc/inittab.no_crs的内容就是在没安装GI以前的/etc/inittab备份文件,而/etc/inittab.crs的内容就是安装GI以后/etc/inittab 备份文件 也就是说,在Linux 5中,安装完RAC(10.2或者11.2)后,该脚本就会增加上面一行启动ohasd守护进程的脚本,如果要在系统启动时启动crs,那么就需要让/etc/inittab中包含下面的一行启动命令: h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 /dev/null 2>&1

发表在 Database, Linux, RAC | 标签为 , , | 留下评论

etc目录下的init.ohasd和ohasd文件丢失后如何启动GI

上一遍我们已经知道11.2和12c RAC中的/etc/init.d/init.ohasd是启动RAC所有其他进程的守护进程。 那么如果有人误删除了这个文件或者错误修改了,怎么办呢? 这个解决不难,因为在Standalone环境中,/etc/init.d/init.ohasd来自于$GRID_HOME/crs/init/init.ohasd,而/etc/init.d/ohasd来自于$GRID_HOME/crs/init/ohasd。 我们对比一下$GRID_HOME/crs/init/和/etc/init.d/下的ohasd和init.ohasd,看看文件内容是否一致: [/shell] 可以看到,$GRID_HOME/crs/init/和/etc/init.d/目录下的文件内容是一致的,只是权限不同。/etc/init.d/目录下的文件权限是750,$GRID_HOME/crs/init下的权限是644。 好了,解决方法有了,如果/etc/init.d/init.ohasd或者/etc/init.d/ohasd丢失了,手工创建/etc/init.d/init.ohasd 就可以了: 如果再细心一点,我们会发现$GRID_HOME/crs/init目录下除了这两个文件外,还有一个名称为ohasd.sles的文件。 熟悉SLES Linux的朋友可能猜到了,是的,这个是在SLES Linux上使用的ohasd版本。 检查当前版本是否为SLES: 现在,我们删除/etc/init.d/init.ohasd文件来模拟init.ohasd文件丢失或者损坏: 然后我们使用$GRID_HOME/crs/init/下面的文件复制过来,手工启动试试看: 下面的显示删除/etc/init.d/init.ohasd后reboot系统的结果(也可以使用kill进程的方式,不重启主机): 可以看到,当前没有任何RAC的进程被启动。 我们尝试恢复这个丢失的ohasd守护进程配置文件: 然后reboot系统后,该进程已经启动了:

发表在 Database, Linux, RAC | 标签为 , , | 留下评论