UDN-企业互联网技术人气社区

板块导航

浏览  : 732
回复  : 3

[讨论交流] 循序渐进:Oracle 11.2 RAC集群进程的初始化与启动过程

[复制链接]
胭脂粉的头像 楼主
发表于 2016-6-14 22:27:49 | 显示全部楼层 |阅读模式
 
1.png

  张大朋(Lunar)Oracle资深技术专家

  Lunar拥有超过十年的ORACLESUPPORT从业经验,曾经服务于ORACLEACS部门,现就职于ORACLESalesConsultant部门,负责的产品主要是Exadata,GoldenGate,Database等。

  从11.2GI(GridInfrastructure)开始,OracleRAC的结构跟10.2有翻天覆地的变化,深入了解集群的初始化过程,有助于我们理解RAC的工作原理,本文为大家阐释RAC集群的引导过程。

  在MOS的经典文档“11gR2ClusterwareandGridHome–WhatYouNeedtoKnow(DocID1053147.1)”中有一副经典大图,可以一目了然的告诉我们RAC集群中大量d.bin进程之间的依赖关系(也就是启动和关闭,谁启动重启谁等等)(点击文末原文链接,直达大图):

2.png



  从CRS的启动过程,我们也可以清晰的看到进程的启动顺序。

  下面是一个11.2.0.3环境的CRS启动过程:

  [root@dm01db01~]#ps-ef|grepd.bin

  root42961420:37?00:00:00/u01/app/11.2.0.3/grid/bin/ohasd.binreboot

  grid43381120:37?00:00:00/u01/app/11.2.0.3/grid/bin/oraagent.bin

  root43421220:37?00:00:00/u01/app/11.2.0.3/grid/bin/orarootagent.bin

  root43481120:37?00:00:00/u01/app/11.2.0.3/grid/bin/cssdagent

  root43701020:37?00:00:00/u01/app/11.2.0.3/grid/bin/cssdmonitor

  root44283507020:37pts/200:00:00grepd.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的示范信息):

  Jan1120:36:18lunarlibclsecho:/etc/init.d/init.ohasd:

  ohasdisrestarting1/10.

  Jan1120:36:18lunarliblogger:exec/u01/app/11.2.0.4/grid/perl/bin/perl

  -I/u01/app/11.2.0.4/grid/perl/lib/u01/app/11.2.0.4/grid/bin/crswrapexece.pl

  /u01/app/11.2.0.4/grid/crs/install/s_crsconfig_lunarlib_env.txt

  /u01/app/11.2.0.4/grid/bin/ohasd.bin"restart"

  这个重启的过程在空闲系统大概需要不到2分钟,$GRID_HOME/`hostname-s`/alert`hostname-s`.log中会ohasd.bin被kill和重启后执行检查(check)和恢复(recovery)各种资源的日志如下:

  2016-01-1120:36:18.500:

  [/u01/app/11.2.0.4/grid/bin/cssdagent(16784)]

  CRS-5822:Agent'/u01/app/11.2.0.4/grid/bin/cssdagent_grid'

  disconnectedfromserver.Detailsat(:CRSAGF00117:){0:5:31}

  in/u01/app/11.2.0.4/grid/log/lunarlib/agent/ohasd/oracssdagent_grid/

  oracssdagent_grid.log.

  2016-01-1120:36:18.504:

  [/u01/app/11.2.0.4/grid/bin/oraagent.bin(16852)]

  CRS-5822:Agent'/u01/app/11.2.0.4/grid/bin/oraagent_grid'

  disconnectedfromserver.Detailsat(:CRSAGF00117:){0:7:7}

  inoraagent_grid.log.

  2016-01-1120:36:18.789:

  [ohasd(17048)]CRS-2112:TheOLRservicestartedonnodelunarlib.

  2016-01-1120:36:18.796:

  [ohasd(17048)]CRS-1301:OracleHighAvailabilityServicestarted

  onnodelunarlib.

  2016-01-1120:36:49.574:

  [/u01/app/11.2.0.4/grid/bin/oraagent.bin(17083)]

  CRS-5818:Abortedcommand'check'forresource'ora.CRSDG.dg'.

  Detailsat(:CRSAGF00113:){0:0:2}inoraagent_grid.log.

  2016-01-1120:36:49.583:

  [/u01/app/11.2.0.4/grid/bin/oraagent.bin(17083)]

  CRS-5818:Abortedcommand'check'forresource'ora.DATADG1.dg'.

  Detailsat(:CRSAGF00113:){0:0:2}inoraagent_grid.log.

  2016-01-1120:36:49.594:

  [/u01/app/11.2.0.4/grid/bin/oraagent.bin(17083)]

  CRS-5818:Abortedcommand'check'forresource'ora.DATADG2.dg'.

  Detailsat(:CRSAGF00113:){0:0:2}inoraagent_grid.log.

  2016-01-1120:36:51.608:

  [/u01/app/11.2.0.4/grid/bin/oraagent.bin(17083)]

  CRS-5818:Abortedcommand'check'forresource'ora.asm'.

  Detailsat(:CRSAGF00113:){0:0:2}inoraagent_grid.log.

  2016-01-1120:37:52.943:

  [ohasd(17048)]CRS-2767:Resourcestaterecoverynotattempted

  for'ora.diskmon'asitstargetstateisOFFLINE

  2016-01-1120:37:52.943:

  [ohasd(17048)]CRS-2769:Unabletofailoverresource'ora.diskmon'.

  好了,继续回到我们刚才的启动过程的讨论。接下来,启动了mdnsd.bin进程:

  [root@dm01db01~]#ps-ef|grepd.bin

  root42961420:37?00:00:00/u01/app/11.2.0.3/grid/bin/ohasd.binreboot

  grid443011020:37?00:00:00/u01/app/11.2.0.3/grid/bin/oraagent.bin

  grid44441220:37?00:00:00/u01/app/11.2.0.3/grid/bin/mdnsd.bin

  root44523507020:37pts/200:00:00grepd.bin

  [root@dm01db01~]#

  然后是增加了ocssd.bin、gpnpd.bin、orarootagent.bin、gipcd.bin、osysmond.bin、cssdmonitor、cssdagent、diskmon.bin一系列的进程:

3.png



  再然后是增加了:

  ologgerd-M-d/u01/app/11.2.0.3/grid/crf/db/dm01db01

  ologgerd(ClusterLoggerService)进程是随着11.2.0.2安装过程自动安装的(11.2.0.2的新特性,以前的版本需要单独下载和安装),属于ClusterHealthMonitor(以下简称CHM)组件。

  CHM主要用来自动收集操作系统的资源(CPU、内存、SWAP、进程、I/O以及网络等)的使用情况。CHM会每秒收集一次数据。

4.png



  CHM会随以下软件自动安装:

  11.2.0.2及更高版本的OracleGridInfrastructureforLinux(不包括LinuxItanium)、Solaris(Sparc64和x86-64)

  11.2.0.3及更高版本OracleGridInfrastructureforAIX、Windows(不包括WindowsItanium)

  注意上面的osysmond.bin进程跟这里的ologgerd(ClusterLoggerService)进程进程是CHM的主要工作进程。

  osysmond会将每个节点的资源使用情况发送给ologgerd(ClusterLoggerService),然后ologgerd将会把所有节点的信息都接收并保存到CHM的资料库。

  CHM的资料库在11.2是缺省保存在$GRID_HOME/crf/db/`hostname-s`目录下,大概需要1G的空间。在12c中,CHM的配置又在不断发生变化:

  在12.1.0.1,CHM的资料库是单独保存在GI的数据库中,在安装时可以选择是否安装GIMR(GridInfrastructureManagementRepository)。

  在12.1.0.2,CHM的资料库还是单独保存在GI的数据库中,但是GIMR(GridInfrastructureManagementRepository)已经是必选项了。

  在12.2,GIMR(GridInfrastructureManagementRepository)使用的数据库MGMTDB可以选择是否跟CRS放在一个磁盘组,还是单独放在一个磁盘组中。

  继续看下面的启动过程。在启动ocssd.bin以后,就会启动octssd.bin:

5.png



  接下来,启动evmd.bin:

6.png



  然后是crsd.bin和tnslsnr:

7.png



  当crsd.bin启动后,就可以使用crsctlstatusres-t来查看CRS状态了。

  如果crsd.bin没启动,那么需要使用crsctlstatusres-t-init查看。

8.png



  最后启动了lsnrctl和oc4jctl,至此,CRS启动完毕。

文章来源:张大朋

相关帖子

发表于 2016-6-15 06:28:19 来自手机 | 显示全部楼层
使用道具 举报

回复

发表于 2016-6-15 06:31:21 来自手机 | 显示全部楼层
dd
使用道具 举报

回复

发表于 2016-6-15 06:31:45 来自手机 | 显示全部楼层
使用道具 举报

回复

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部