张大朋(Lunar)Oracle 资深技术专家
Lunar 拥有超过十年的 ORACLE SUPPORT 从业经验,曾经服务于ORACLE ACS部门,现就职于 ORACLE Sales Consultant 部门,负责的产品主要是 Exadata,Golden Gate,Database 等。
从11.2 GI(Grid Infrastructure)开始,Oracle RAC的结构跟10.2有翻天覆地的变化,深入了解集群的初始化过程,有助于我们理解RAC的工作原理,本文为大家阐释RAC集群的引导过程。
在MOS的经典文档“11gR2 Clusterware and Grid Home – What You Need to Know (Doc ID 1053147.1)”中有一副经典大图,可以一目了然的告诉我们RAC集群中大量 d.bin 进程之间的依赖关系(也就是启动和关闭,谁启动重启谁等等)(点击文末原文链接,直达大图):
从CRS的启动过程,我们也可以清晰的看到进程的启动顺序。
下面是一个11.2.0.3环境的CRS启动过程:
[root@dm01db01 ~] # ps -ef|grep d.bin root 4296 1 4 20:37 ? 00:00:00 /u01/app/11 .2.0.3 /grid/bin/ohasd .bin reboot grid 4338 1 1 20:37 ? 00:00:00 /u01/app/11 .2.0.3 /grid/bin/oraagent .bin root 4342 1 2 20:37 ? 00:00:00 /u01/app/11 .2.0.3 /grid/bin/orarootagent .bin root 4348 1 1 20:37 ? 00:00:00 /u01/app/11 .2.0.3 /grid/bin/cssdagent root 4370 1 0 20:37 ? 00:00:00 /u01/app/11 .2.0.3 /grid/bin/cssdmonitor root 4428 3507 0 20:37 pts /2 00:00:00 grep d.bin |
最先启动的是:
/u01/app/11.2.0.3/grid/bin/ohasd.bin
这个进程后面跟着reboot,表示它被kill后会被自动reboot。
/etc/init.d/init.ohasd 进程就是重启 /u01/app/11.2.0.3/grid/bin/ohasd.bin 进程的守护进程。他们都来源于$GRID_HOME/crs/init/init.ohasd ,会自动启动这个进程,并在/var/log/message中记录下这个过程。
/u01/app/11.2.0.3/grid/bin/ohasd.bin被kill 后,系统会有几分钟的重启服务的时间,/var/log/message中记录下这个启动过程(以下是11.2.0.4的示范信息):
|
这个重启的过程在空闲系统大概需要不到2分钟,$GRID_HOME/`hostname -s`/alert`hostname -s`.log中会ohasd.bin被kill和重启后执行检查(check)和恢复(recovery)各种资源的日志如下:
2016-01-11 20:36:18.500:
2016-01-11 20:36:18.504:
2016-01-11 20:36:18.789: [ohasd(17048)]CRS-2112:The OLR service started on node lunarlib. 2016-01-11 20:36:18.796:
2016-01-11 20:36:49.574:
2016-01-11 20:36:49.583:
2016-01-11 20:36:49.594:
2016-01-11 20:36:51.608:
2016-01-11 20:37:52.943:
2016-01-11 20:37:52.943: [ohasd(17048)]CRS-2769:Unable to failover resource 'ora.diskmon' . |
好了,继续回到我们刚才的启动过程的讨论。接下来,启动了 mdnsd.bin进程:
[root@dm01db01 ~] # ps -ef|grep d.bin root 4296 1 4 20:37 ? 00:00:00 /u01/app/11 .2.0.3 /grid/bin/ohasd .bin reboot grid 4430 1 10 20:37 ? 00:00:00 /u01/app/11 .2.0.3 /grid/bin/oraagent .bin grid 4444 1 2 20:37 ? 00:00:00 /u01/app/11 .2.0.3 /grid/bin/mdnsd .bin root 4452 3507 0 20:37 pts /2 00:00:00 grep d.bin [root@dm01db01 ~] # |
然后是增加了 ocssd.bin 、gpnpd.bin、 orarootagent.bin、 gipcd.bin、 osysmond.bin、 cssdmonitor、 cssdagent、 diskmon.bin 一系列的进程:
再然后是增加了 :
ologgerd -M -d /u01/app/11.2.0.3/grid/crf/db/dm01db01
ologgerd(Cluster Logger Service)进程是随着11.2.0.2安装过程自动安装的(11.2.0.2的新特性,以前的版本需要单独下载和安装),属于Cluster Health Monitor(以下简称CHM)组件。
CHM主要用来自动收集操作系统的资源(CPU、内存、SWAP、进程、I/O以及网络等)的使用情况。CHM会每秒收集一次数据。
CHM会随以下软件自动安装:
11.2.0.2 及更高版本的 Oracle Grid Infrastructure for Linux (不包括Linux Itanium) 、Solaris (Sparc 64 和 x86-64)
11.2.0.3 及更高版本 Oracle Grid Infrastructure for AIX 、 Windows (不包括Windows Itanium)
注意上面的osysmond.bin进程跟这里的ologgerd(Cluster Logger Service)进程进程是CHM的主要工作进程。
osysmond会将每个节点的资源使用情况发送给ologgerd(Cluster Logger Service),然后ologgerd将会把所有节点的信息都接收并保存到CHM的资料库。
CHM的资料库在11.2是缺省保存在$GRID_HOME/crf/db/`hostname -s`目录下,大概需要1G的空间。在12c中,CHM的配置又在不断发生变化:
在12.1.0.1,CHM的资料库是单独保存在GI的数据库中,在安装时可以选择是否安装GIMR(Grid Infrastructure Management Repository )。
在12.1.0.2,CHM的资料库还是单独保存在GI的数据库中,但是GIMR(Grid Infrastructure Management Repository )已经是必选项了。
在12.2,GIMR(Grid Infrastructure Management Repository )使用的数据库MGMTDB可以选择是否跟CRS放在一个磁盘组,还是单独放在一个磁盘组中。
继续看下面的启动过程。在启动ocssd.bin以后,就会启动 octssd.bin :
接下来,启动evmd.bin:
然后是crsd.bin 和 tnslsnr:
当crsd.bin启动后,就可以使用crsctl status res -t来查看CRS状态了。
如果crsd.bin没启动,那么需要使用crsctl status res -t -init查看。
最后启动了lsnrctl 和 oc4jctl ,至此,CRS启动完毕。
搜索 盖国强(Eygle)微信号:eeygle,或者扫描下面二维码,备注:云和恩墨大讲堂,即可入群。每周与千人共享免费技术分享,与讲师在线讨论。
关注本微信(OraNews)回复关键字获取 2016DTCC, 2016数据库大会PPT; DBALife,"DBA的一天"精品海报大图; 12cArch,“Oracle 12c体系结构”精品海报; DBA01,《Oracle DBA手记》第一本下载; YunHe,“云和恩墨大讲堂”案例文档下载;