11gr2 集群新增组件 - baiduimages.china-pub.com/ebook4880001-4885000/4881963/ch03.pdf · 2015....

第 3 章

11gR2 集群新增组件

在本章中作者会详细介绍 11gR2 版本 GI 中新增的重要组件 OHAS（Oracle High Availability Service）和其他相关的组件、资源。同时，作者也会对 10gR2 版本的集群架构进

行说明。首先，大家可以通过下图了解 11gR2 版本中 GI 组件之间的启动关系。

上图是基于 11.2.0.3 版本绘制的。

本章只介绍由 ohasd 对应的代理进程启动的资源，由 crsd 启动的资源，会在第 6 章进行

详细的介绍。

Chapter 3

注意

第 3 章　11gR2 集群新增组件　　31

3.1　OHAS

OHAS 是 11gR2 版本新推出的一个重要的组件，随着这个组件的产生，Oracle 集群管理

软件的很多方面都发生了改变。这些改变主要体现在集群启动方式和资源管理方式方面。

3.1.1　集群启动方式

1. 10g 版本首先，回顾一下 10g 版本的集群管理软件（CRS）。从集群的启动角度来讲，10g 版本的

集群是通过 /etc/inittable 文件中的以下三行代码来启动的。

h1:35:respawn:/etc/init.d/init.evmd run >/dev/null 2>&1 </dev/nullh2:35:respawn:/etc/init.d/init.cssd fatal >/dev/null 2>&1 </dev/nullh3:35:respawn:/etc/init.d/init.crsd run >/dev/null 2>&1 </dev/null

其中，

T init.cssd 负责启动 ocssd.bin 守护进程和其他 CSS 层面的守护进程，从而完成对集群的

构建工作。

T Init.crsd 负责启动 crsd.bin 守护进程并调用相应的 racg 模块来启动相应的资源，从而

完成集群应用程序资源的启动。

T Init.evmd 负责启动 evmd.bin 守护进程，从而实现集群节点的事件发布。

虽然以上 3 个脚本是被同时调用的，但是守护进程之间是有依存关系的。首先，需要启

动 cssd.bin 并确保其能够正常工作，之后才能够启动 crsd.bin 并确保其正常工作，最后启动

evmd.bin 并确保其正常工作。

接下来，看一下每个脚本的内容。当然，作者只会以脚本的一部分为例，说明它们的主

要功能。

（1） init.cssd 脚本

……ORA_CRS_HOME=/u01/app/crsORACLE_USER=oracleORACLE_HOME=$ORA_CRS_HOMEexport ORACLE_HOMEexport ORA_CRS_HOMEexport ORACLE_USER……# Default Location for commands on most platformsPS='/bin/ps'# ps -e is expected to search for all processes on the box and provide# terse binary name output so that column count does not truncate binary# names and confuse grep.PSE='/bin/ps -e'PSEF='/bin/ps -ef'

32　　第一部分　集群管理软件

HEAD='/bin/head'GREP='/bin/grep'KILL='/bin/kill'KILLTERM='/bin/kill -TERM'KILLDIE='/bin/kill -9'KILLCHECK="/bin/kill -0 $$"SLEEP='/bin/sleep'NULL='/dev/null'……

可以能看到，首先定义了集群使用的一些环境变量和需要使用的操作系统命令。

……PLATFORM=`$UNAME`MAXFILE=65536case $PLATFORM inLinux)…… LD_LIBRARY_PATH=$ORA_CRS_HOME/lib export LD_LIBRARY_PATH FAST_REBOOT="/sbin/reboot -n -f & $SLEEP 1 ; $ECHO b > /proc/sysrq-trigger" HEAD='/usr/bin/head'……HP-UX) MACH_HARDWARE=`/bin/uname -m`…… LD_LIBRARY_PATH=$ORA_CRS_HOME/lib:$NMAPIDIR_64:/usr/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH # Presence of this file indicates that vendor clusterware is installed SKGXNLIB=${NMAPIDIR_64}/libnmapi2.${SO_EXT} if [ -f $SKGXNLIB ]; then USING_VC=1 Fi……SunOS) MACH_HARDWARE=`/bin/uname -i` ARCH=`/usr/bin/isainfo -b` CLUSTERDIR=/opt/ORCLcluster

LD_L IBRARY_PATH=$ORA_CRS_HOME/lib:$CLUSTERDIR/lib:/usr/lib:/usr/ucblib:$LD_LIBRARY_PATH

LD_L IBRARY_PATH_64=$ORA_CRS_HOME/lib:$CLUSTERDIR/lib:/usr/lib:/usr/ucblib:$LD_LIBRARY_PATH_64

if [ "${MACH_HARDWARE}${ARCH}" = "i86pc64" ]; then

LD_L IBRARY_PATH=$ORA_CRS_HOME/lib:$CLUSTERDIR/lib:/usr/lib/amd64:/usr/ucblib/amd64:$LD_LIBRARY_PATH

LD_L IBRARY_PATH_64=$ORA_CRS_HOME/lib:$CLUSTERDIR/lib:/usr/lib/amd64:/usr/ucblib/amd64:$ LD_LIBRARY_PATH_64

fi export LD_LIBRARY_PATH


export LD_LIBRARY_PATH_64 …… AIX) CLUSTERDIR=/opt/ORCLcluster

LIBP ATH=$ORA_CRS_HOME/lib:$CLUSTERDIR/lib:$ORA_CRS_HOME/lib32:$CLUSTERDIR/lib32:/usr/lib:$LIBPATH

LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH export LIBPATH export LD_LIBRARY_PATH RENICE="/usr/sbin/renice" FAST_REBOOT="/usr/bin/sysdumpstart -p" SLOW _REBOOT="/bin/kill -HUP `$CAT /etc/syslog.pid`; /bin/sync & $SLEEP 2;

/usr/sbin/fastboot -n -q" # Presence of this file indicates that vendor clusterware is installed SKGXNLIB=/usr/sbin/cluster/utilities/cldomain if [ -f $SKGXNLIB ]; then USING_VC=1 Fi……OSF1) LD_LIBRARY_PATH=$ORA_CRS_HOME/lib:/usr/lib export LD_LIBRARY_PATH FAST_REBOOT="/usr/sbin/reboot -n -q" SLOW _REBOOT="/bin/kill -HUP `$CAT /var/run/syslog.pid`; /bin/sync & $SLEEP

2 ; /usr/sbin/reboot -n -q" # No need for OPROCD on Tru64. We don't support a configuration # without Tru64 clusterware, AND, Tru64 clusterware is responsible # for I/O Fencing. DISABLE_OPROCD=true # Presence of this file indicates that vendor clusterware is installed SKGXNLIB=/usr/ccs/lib/libdlm.a if [ -f $SKGXNLIB ]; then USING_VC=1 Fi……*) /bin/echo "ERROR: Unknown Operating System" exit -1 ;;

为不同的操作系统设置对应的环境变量。

case $1 in'home') $ECHO $ORA_CRS_HOME exit 0; ;;'user') $ECHO $ORACLE_USER exit 0; ;;'diag') $ECHO CRS init script diagnostics.


......'bootid')......'disable')......'enable')......'norun')......'start') CMD=`$BASENAME $0`

# If we are being invoked by the user, perform manual startup. # If we are being invoked as an RC script, check for autostart. if [ "$CMD" = "init.cssd" ]; then $LOGMSG "Oracle Cluster Synchronization Service starting by user request." $ID/init.cssd manualstart else $ID/init.cssd autostart fi ;;'manualstart') # Queue a startup to the CRS scripts invoked by inittab. BOOTID=`$ID/init.cssd bootid` $ECHO "$BOOTID" > $RUNFILE

STARTTIME=`$EXPRN $RUNRECHECKTIME + $STARTCHECKSLEEP` $ECHO "Startup will be queued to init within $STARTTIME seconds." ;;'autostart')......# Runcheck is intended to check the run status for any of the# run or fatal scripts (evm/crs/css) as initialized by the automatic startup# or manual startup routines.# Runcheck is supposed to be a very fast check, and be silent since it# will get invoked regularly while the system is up.# Exit codes should match the requirements of startcheck.'runcheck')......# Startcheck is intended to check the run status for any of the# run or fatal scripts (evm/crs/css) (see runcheck), and additionally # check on vendor clusterware and filesystem dependencies.# Startcheck is supposed to block for a long time waiting on dependencies.'startcheck') # Returns 0 if we should start # Returns 1 on a non-cluster boot # Returns 2 if disabled by admin # Returns 3 on error......'oclsomon') # This action is expected to start and monitor the clsomon daemon. # Its purpose is to assist the CSS daemon by monitoring it for hangs.


# In the event of a CSS daemon hang, the remote nodes may evict the # current node and so it is necessary to terminate the local node.......'oclsvmon') # This action is expected to start and monitor the clsvmon daemon. # Its purpose is to assist the CSS daemon in monitoring vendor clusterware # and allow additional diagnostics to be obtained in the case of system # failures.......'oprocd') # Runs the oprocd daemon. This script is supposed to exit 0 # if it decides that it should not be respawned, and exit 1 if it # wants to be respawned. The purpose of oprocd is to detect system # hangs, which often occur due to faulty drivers or hardware. ......

'stop') $LOGMSG "Oracle CSSD being stopped"......'run') # Foreground run, for single instance or single-node installs only. # If this is used in a cluster install, RDBMS datafile corruption is # likely.......'fatal') # This action is invoked to start the CSS daemon in cluster mode, # and one or more of its accompanying daemons oprocd or clsvmon or clsomon # This respawn wrapper is done in lieu of adding new entries to inittab.......*) $ECHO "See documentation at the top of $0 about supported commands." exit 1; ;;esac

init.cssd 根据输入的参数决定需要执行的操作，如果输入启动参数 fatal，则表示正常启动 cssd守护进程和其他相关的守护进程。

（2）init.crsd

ORA_CRS_HOME=/u01/app/crsORACLE_HOME=$ORA_CRS_HOMEexport ORA_CRS_HOMEexport ORACLE_HOMEORACLE_USER=oracleUMASK=/bin/umaskSED=/bin/sedCAT=/bin/catLOGMSG="/bin/logger -puser.err"ECHO=/bin/echoKILL=/bin/kill……


定义 crsd 需要使用的环境变量和操作系统命令。

......case $PLATFORM inLinux) ……HP-UX) ID=/sbin/init.d ;;SunOS) ……AIX) ……OSF1) ……*) /bin/echo "ERROR: Unknown Operating System" exit -1 ;;esac

根据不同的操作系统平台设置相应的环境变量。

......case $1 in 'home')......'stop')......'run') # foreground run out of init......'tz')......*)......esac

根据输入的参数值决定相应的操作。如果输入参数为 run，则表示启动 crsd.bin 守护进程。

在第 6 章会详细介绍关于 CRSD 层面的内容。

（3）init.evmd

ORA_CRS_HOME=/u01/app/crsORACLE_USER=oracleORACLE_HOME=$ORA_CRS_HOMEexport ORACLE_HOMEexport ORA_CRS_HOMECAT=/bin/catRMF="/bin/rm -f"LOGMSG="/bin/logger -puser.err"ECHO=/bin/echoKILL=/bin/kill......


定义 evmd 需要使用的环境变量和操作系统命令。

case $PLATFORM inLinux) ......HP-UX) ......SunOS) .....AIX) ......OSF1) ......*) /bin/echo "ERROR: Unknown Operating System"......esac

根据不同的操作系统平台设置相应的环境变量。

......case $1 in 'home')......'user')......'stop')......'run') # foreground run out of init......*)......esac

根据输入的参数值决定相应的操作。如果输入参数为 start，则启动 evmd.bin 守护进程。

（4）小结

看了 init.cssd、init.crsd 和 init.evmd 三个脚本的内容后，可以发现这三个脚本的基本结构

是：首先定义变量和操作系统命令，之后根据不同的操作系统平台设置对应的环境变量，最

后根据输入的参数来决定对应的操作。但是这样做也为集群管理软件带来了问题：如果由于

某种原因脚本的内容或者权限被修改，很可能导致集群无法被启动，并且很难进行诊断，而

且所有的操作都保存在脚本中也会存在安全性的问题，所以，从 11.2 版本开始，集群的启动

方式发生了改变。

2. 11gR2 版本再来看看 11gR2（即 11.2 版本）版本集群的 /etc/inittab 文件。

# Run xdm in runlevel 5x:5:respawn:/etc/X11/prefdm -nodaemonh1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null


只有脚本 /etc/init.d/init.ohasd 被调用，之前版本的三个脚本已经不存在了。接下来，看一

下这个脚本的一些内容。

######### Instantiated Variables #########ORA_CRS_HOME=/u01/app/11.2.0export ORA_CRS_HOMEHAS_USER=rootSCRBASE=/etc/oracle/scls_scr#limitsCRS_LIMIT_CORE=unlimitedCRS_LIMIT_MEMLOCK=unlimitedCRS_LIMIT_OPENFILE=65536##########################################……### CLI toolsBASENAME=/bin/basenameHOSTN=/bin/hostnameSU=/bin/suCHOWN=/bin/chownECHO=/bin/echoSLEEP=/bin/sleepEXPRN=/usr/bin/exprCUT=/usr/bin/cutCAT=/bin/catGREP=/bin/grep

ohasd 所需要的环境变量和命令被定义。

### Main ###case $PLATFORM inLinux) LOGGER="/usr/bin/logger"......HP-UX)......AIX)............OSF1)......*) /bin/echo "ERROR: Unknown Operating System" exit -1 ;;esac

根据不同平台设置对应的环境变量。

case $1 in'run')......esac


看起来，输入的参数只有唯一的值 run，它用于启动 ohasd.bin 守护进程。

3. 小结根据 10g 和 11gR2 版本的集群管理软件的启动脚本之间的不同，能看到从 11gR2 版本开

始，GI 启动脚本变成了只有一个，而且脚本的长度也大大地减少，10g 版本存在的问题得到

了解决。换句话说，ohasd.bin 成为了集群启动的根（root）守护进程。下面是一个查看 ohasd.bin 守护进程的 ps 命令：

[grid@test1 ~]$ ps -elf | grep has4 S root 2473 1 1 75 0 - 40103 stext Nov07 ? 00:56:54 /u01/

app/11.2.0/bin/ohasd.bin reboot4 S root 2713 1 0 80 0 - 615 pipe_w Nov07 ? 00:00:00 /bin/

sh /etc/init.d/init.ohasd run

3.1.2　资源管理方式

1. 10g 版本对于 10gR2 版本的集群，资源管理的工作是由 CRS（Cluster Ready Service）组件来实现的，

也就是说由 crsd 守护进程负责管理资源，包括资源的启动、停止、监控等。所谓资源，实际

上就是集群管理软件所需要管理的应用程序实体。

首先，需要了解 10gR2 版本的集群有哪些资源需要被管理。可以通过 crs_stat 命令来查看

资源的列表。

[oracle@test1 ~]$ crs_stat -tName Type Target State Host------------------------------------------------------------ora....SM1.asm application ONLINE ONLINE test1ora....t1.lsnr application ONLINE ONLINE test1ora....st1.gsd application ONLINE ONLINE test1ora....st1.ons application ONLINE ONLINE test1ora....st1.vip application ONLINE ONLINE test1ora....SM2.asm application ONLINE ONLINE test2ora....t2.lsnr application ONLINE ONLINE test2ora....st2.gsd application ONLINE ONLINE test2ora....st2.ons application ONLINE ONLINE test2ora....st2.vip application ONLINE ONLINE test2ora.testdb.db application ONLINE ONLINE test2ora....g1.inst application ONLINE ONLINE test1ora....g2.inst application ONLINE ONLINE test2ora...._TAF.cs application ONLINE ONLINE test2ora....0g1.srv application ONLINE ONLINE test1ora....0g2.srv application ONLINE ONLINE test2

本书内容只包含 CRS 管理的标准资源。对于用户自定义的资源，本书并不会讨论。注意


根据上面的输出，可以看到 CRSD 会管理以下资源：

T VIP 资源（ora. < 节点名 >.vip）。 T ONS 资源（ora. < 节点名 >.ons）。 T GSD 资源（ora. < 节点名 >.gsd）。 T ASM 实例资源（ora..ASM< 节点编号 >.asm）。

T 监听程序资源（ora. < 节点名 >.< 监听程序名 >.lsnr）。 T 数据库资源（ora.< 数据库名 >.db）。 T 数据库实例资源（ora.< 数据库名 >.< 实例名 >.inst）。 T 数据库服务资源（ora. < 数据库名 >.< 服务名 >.cs 和 ora. < 数据库名 >.< 服务名 >.< 实

例名 >.srv）。关于以上资源的详细信息会在第 6 章进行介绍。

介绍了 CRSD 需要管理的资源列表之后，来看一下 CRSD 是如何实现资源管理的。首先

介绍一些资源相关的术语。

T 动作（Action）：动作定义了 CRSD 对资源进行启动、停止、检查和清除操作时所需要

运行的步骤，它可以是一段 shell 脚本、一段应用程序、数据库命令等。

T 资源概要文件（profile）：概要文件定义了资源的很多属性，以便 CRSD 能够根据概要

文件定义的属性来创建资源。例如：检查间隔、动作脚本等。

T 依赖关系（Dependency）：资源之间并不是独立的，有些资源之间是存在互相依赖

关系的。例如：数据库实例启动的前提是 ASM 实例先要被启动，这表示数据库实

例资源需要依赖于 ASM 实例资源，而这种依赖关系是通过资源属性 REQUIRED_RESOURCES 来实现的。

T 权限：由于不同的资源需要执行的操作也是不同的，这意味着执行操作的用户也会不

同（主要是 root 和 Oracle 用户），所以，每个资源都会针对不同的用户指定不同的权

限。这也是为什么 crsd.bin 守护进程需要以 root 用户运行的原因之一。

T OCR（Oracle Cluster Register）：OCR 实际上是包含了以上所有信息的一个注册表，

CRSD 通过访问 OCR 来获得集群资源的列表（当然，还包括其他很重要的信息）以及

每个资源的各个属性。关于 OCR 的更多内容会在第 6 章进行介绍。

Oracle 集群管理软件（CRS）还定义了一些 racg 模块，不同的 racg 模块负责管理不同的

资源，例如： racgvip 负责管理 VIP，这些模块负责定义对资源操作的动作。看到这里，读者

对 CRSD 管理资源的方法应该有了比较清晰的认识，基本上可以将这些方法总结为以下的

两点：

第一点：CRSD 通过 OCR 定义资源。当 crsd.bin 守护进程启动时，通过读取 OCR 中的信

息来获得资源定义。而当资源属性发生改变时，crsd.bin 守护进程也会修改 OCR 中的信息。

第二点：CRSD 通过调用 racg 模块来实现对资源的各种动作。

最后，通过一段 CRSD 的日志文件来简单回顾一下这一节介绍的内容。


Orac le Database 10g CRS Release 10.2.0.5.0 Production Copyright 1996, 2004, Oracle. All rights reserved

2014-11-11 13:29:56.433: [default][1521344]0CRS Daemon Starting2014-11-11 13:29:56.435: [CRSMAIN][1521344]0Checking the OCR device2014-11-11 13:29:56.638: [CRSMAIN][1521344]0Connecting to the CSS Daemon2014-11-11 13:29:57.056: [COMMCRS][64297872]clsc_connect: (0x88e8f50) no listener at (ADDRESS=(PROTOCOL=ipc)(KEY=OCSSD_LL_test1_))2014 -11-11 13:29:57.057: [CSSCLNT][1521344]clsssInitNative: connect failed, rc 92014 -11-11 13:29:57.058: [CRSRTI][1521344]0CSS is not ready. Received status 3

from CSS. Waiting for good status ..2014 -11-11 13:29:58.425: [COMMCRS][64297872]clsc_connect: (0x88e8f58) no listener

at (ADDRESS=(PROTOCOL=ipc)(KEY=OCSSD_LL_test1_))

CRSD 守护进程被启动，之后尝试联系 CRSD 守护进程，但是由于 ocssd.bin 还没有完全被启

动，所以 CRSD 守护进程还不能继续向下运行。在 ocssd.bin 完全启动后，CRSD 才能继续启动。

2014-11-11 13:30:10.492: [CLSVER][1521344]0Active Version from OCR:10.2.0.5.02014 -11-11 13:30:10.493: [CLSVER][1521344]0Active Version and Software Version

are same2014-11-11 13:30:10.493: [CRSMAIN][1521344]0Initializing OCR2014 -11-11 13:30:10.754: [OCRRAW][1521344]proprioo: for disk 0 (/dev/raw/raw1),

id match (1), my id set (1669906634,1028247821) total id sets (1), 1st set (1669906634,1028247821), 2nd set (0,0) my votes (2), total votes (2)

2014 -11-11 13:30:10.910: [CRSD][1521344]0ENV Logging level for Module: allcomp 02014-11-11 13:30:10.936: [CRSD][1521344]0ENV Logging level for Module: default 0

CRSD 守护进程发现了 OCR 对应的设备（/dev/raw/raw1）。……2014 -11-11 13:30:11.028: [CRSMAIN][1521344]0Filename is /u01/app/crs/crs/init/

test1.pid2014 -11-11 13:30:11.064: [CRSMAIN][1521344]0Using Authorizer location: /u01/app/

crs/crs/auth/[ clsdmt][2865847184]Listening to (ADDRESS=(PROTOCOL=ipc)(KEY=test1DBG_CRSD))

CRSD 守护进程的 pid 文件被创建，之后对应的套接字地址被创建。

……2014-11-11 13:30:12.623: [CRSMAIN][1521344]0CRS Daemon Started.

CRSD 守护进程启动完成。

……014- 11-11 13:30:14.258: [CRSRES][2739968912]0Attempting to start òra.test1.vip`

on member `test1`2014 -11-11 13:30:18.313: [CRSRES][2739968912]0Start of òra.test1.vip` on member

`test1` succeeded.2014 -11-11 13:30:18.735: [CRSRES][2739968912]0startRunnable: setting CLI values2014 -11-11 13:30:18.775: [CRSRES][2739968912]0Attempting to start òra.test1.

LISTENER_TEST1.lsnr` on member `test1`2014 -11-11 13:30:19.328: [CRSRES][2677029776]0startRunnable: setting CLI values2014 -11-11 13:30:19.374: [CRSRES][2677029776]0Attempting to start òra.test1.ons`


on member `test1`2014 -11-11 13:30:21.038: [ CRSRES][2677029776]0Start of `ora.test1.ons` on

member `test1` succeeded.2014 -11-11 13:30:21.247: [ CRSRES][2729479056]0Start of `ora.test1.ASM1.asm` on

member `test1` succeeded.

crsd 开始启动资源。

2. 11gR2 版本从版本 11gR2 版本开始，ohasd 变成了集群启动的唯一始点，而所有的其他守护进程和集

群管理的资源统统被定义为资源，例如：cssd 守护进程就以初始化资源 ora.cssd 的形式存在，

而 ohasd 守护进程负责管理集群所有的守护进程对应的资源。同时，集群管理软件（GI）不再

使用 racg 模块来管理资源，而是用代理进程（agent）统一实现对所有资源的管理。这种改变

使得 11gR2 版本的集群变得更加标准化、更加安全和便于管理。既然一切都变成了资源，那

么和 10g 版本类似，就需要有一个注册表来保存资源的属性。OCR 是用于保存 CRSD 所管理

的资源的注册表，但是在 CRSD 启动之前集群还有很多初始化资源（例如 asm 实例）需要启

动，所以只有 OCR 是不够的。Oracle 在 11gR2 版本中推出了另一个集群注册表 OLR（Oracle Local Registry）。接下来，详细介绍 OLR 和代理进程这两个 11gR2 的新特性。

（1）OLR顾名思义，OLR 是保存在本地的集群注册表，也就是说 OLR 是保存在每个节点本地的，

而且其中的信息大部分是针对每个节点的。OLR 的主要作用就是为 ohasd 守护进程提供集群

的配置信息和初始化资源的定义信息。当集群启动时 ohasd 会从 /etc/oracle/olr.loc 文件（不同

平台，文件位置会不同）中读取 OLR 的位置，OLR 默认保存在 <gi_home>/cdata 下，文件名

为 < 节点名 >.olr。

[grid@test1 cdata]$ cat /etc/oracle/olr.locolrconfig_loc=/u01/app/11.2.0/cdata/test1.olrcrs_home=/u01/app/11.2.0

[grid@test1 cdata]$ ls -l /u01/app/11.2.0/cdata/test1.olr-rw------- 1 root oinstall 272756736 Nov 11 12:37 /u01/app/11.2.0/cdata/test1.olr

接下来，看一下 OLR 中记录的一些信息。通过命令 ocrdump –local 产生了一个 OLR 的转储

文件。

[SYSTEM.ORA_CRS_HOME]ORATEXT : /u01/app/11.2.0SECU RITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ,

OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}

GI home 的信息。

……[SYSTEM.version.activeversion]ORATEXT : 11.2.0.4.0


SECU RITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}

集群版本信息。

……

[SYSTEM.GPnP]

UNDEF :

SECU RITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_NONE,

OTHER_PERMISSION : PROCR_NONE, USER_NAME : grid, GROUP_NAME : oinstall}

[SYSTEM.GPnP.profiles]

BYTESTREAM (16) :



[SYSTEM.GPnP.profiles.peer]

UNDEF :



[SYSTEM.GPnP.profiles.peer.best]

BYTE STREAM (16) : 3c3f786d6c2076657273696f6e3d22312e302220656e636f64696e673d2255

54462d38223f3e3c67……



集群初始化资源 gpnp 的定义信息。

……

[SYSTEM.network]

UNDEF :

SECU RITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ,

OTHER_PERMISSION : PROCR_READ, USER_NAME : grid, GROUP_NAME : oinstall}

[SYSTEM.network.haip]

UNDEF :



[SYS T EM.network.haip.group]

UNDEF :



[SYST EM.network.haip.group.cluster_interconnect]

UNDEF :




[SYSTEM.network.haip.group.cluster_interconnect.interface]UNDEF : SECU RITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ,


[SYSTEM.network.haip.group.cluster_interconnect.interface.status]ORATEXT : eth1:99SECU RITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ,


[SYSTEM.network.haip.group.cluster_interconnect.interface.valid]ORATEXT : 169.254.93.64SECU RITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ,


集群初始化资源 HAIP 的定义。

从上面的 OLR 转储文件可以看到：OLR 的结构仍然沿用了和 OCR 相同的树形结构，

而且其中的信息组织形式和 OCR 也是相同的。另外，OLR 的备份策略和 OCR 的有所不

同，默认情况下 GI 在初始安装时会在路径 <gi_home>/cdata/< 节点 > 下产生一个备份，

例如：

-rw-r--r-- 1 grid oinstall 6799360 Sep 19 11:33 backup_20131003_094829.olr

OLR 不会被自动备份，如果在集群的一些配置信息发生改变后，需要使用下面的命令手动进

行备份：

[root@test1 bin]# ./ocrconfig -local -manualbackuptest1 2014/11/16 13:18:31 /u01/11.2.0/grid/cdata/test1/backup_20141116_131831.olrtest1 2014/11/11 14:29:28 /u01/11.2.0/grid /cdata/test1/backup_20141111_142928.olrtest1 2014/09/19 11:37:52 /u01/11.2.0/grid/cdata/test1/backup_20140919_113752.olr

建议在集群的重要配置信息（例如：集群私网配置）发生改变之后，使用命令 ocrconfig -local -manualbackup 手动备份 OLR。例如：

[root@test1 bin]# ./ocrconfig -local -manualbackuptest1 2014/11/11 14:29:28 /u01/11.2.0/grid /cdata/test1/backup_20141111_142928.olrtest1 2014/09/19 11:37:52 /u01/11.2.0/grid/cdata/test1/backup_20140919_113752.olr

上面的命令除了产生新的 OLR 备份之外，还会把所有的 OLR 备份显示出来。

当 OLR 丢失之后，可以使用命令“ ./ocrconfig -local –restore <OLR 备份文件 >”来恢复，

不能从集群的其他节点复制 OLR 到本地节点，这是因为 OLR 中保存的一些信息是针对本地

节点的。如果需要验证 OLR 的一致性，可以使用 ocrcheck 命令，例如：

[root@test1 bin]# ./ocrcheck -localStatus of Oracle Local Registry is as follows :

注意


Version : 3 Total space (kbytes) : 262120 Used space (kbytes) : 2824 Available space (kbytes) : 259296 ID : 2073657760 Device/File Name : /u01/11.2.0/grid/cdata/test1.olr Device/File integrity check succeeded

Local registry integrity check succeeded

Logical corruption check succeeded

简单地说，所有适用于 OCR 的命令同样适用于 OLR，但是需要增加 -local 选项。

（2）代理进程

随着 Oracle 数据库和集群产品的发展，集群管理软件需要管理越来越多的资源，同时资

源的复杂程度也越来越高，原有的 10g 版本的集群管理方式已经无法完成越来越多、越来越

复杂的资源管理任务。因此，Oracle 在 11gR2 版本的集群管理软件中引入了一个全新的资源

管理框架（framework）—代理进程，使得资源管理变得更加健壮和高效。

本章只会简单介绍代理进程框架，详细的内容会在第 6 章进行介绍。

代理进程框架的核心部分—代理进程会以守护进程的形式存在，完成管理资源的任务。

代理进程是多线程的进程，而且针对不同的资源会启动不同的代理进程。支持的代理进程包

括以下几种。

T oraagent ：这个代理进程会以 Oracle 或者 grid 用户启动，负责管理的用户为 Oracle 或grid 的资源。

T orarootagent: 这个代理进程以 root 用户启动，负责管理的用户为 root 的资源。

T cssdagent: 这个代理进程负责启动 ocssd.bin 守护进程，之后负责监控 ocssd.bin 守护

进程。

T cssdmoniot ：这个代理进程和 cssdagent 代理进程基本一样，但是它只负责监控 ocssd.bin 守护进程。

代理进程可以由 ohasd 和 crsd 守护进程启动，其他的集群守护进程不能启动代理进程。

其中，ohasd 守护进程启动的代理进程负责管理集群的初始化资源和其他守护进程，而 CRSD守护进程启动的代理进程负责管理集群的其他资源（在这一点上与 10g 版本一致的）。

ohasd.bin 守护进程会启动 4 个代理进程，它们分别是 oraagent_grid（如果集群管理

软件和数据库软件都是使用 Oracle 用户安装的，那么这个代理进程的名称就是 oraagent_ oracle）、 orarootagent_root、cssdagent_root、cssdmonitor。每个代理进程负责管理的资源可

以参照下表。

注意


代理进程资源拥有者资源名称

oraagent_grid grid ora.gipcd

oraagent_grid grid ora.gpnpd

oraagent_grid grid ora.mdnsd

cssdagent root ora.cssd

cssdmonitor root ora.cssdmonitor

orarootagent_root root ora.diskmon

orarootagent_root root ora.ctssd

orarootagent_root root ora.crsd

oraagent_grid grid ora.evmd

oraagent_grid grid ora.asm

orarootagent_root root ora.driver.acfs

orarootagent_root root ora.cluster_interconnect.haip

orarootagent_root root ora.crf

如果集群管理软件和数据库软件都是使用 oracle 用户安装的，那么上表中的代理进程

oraagent_grid 会是 oraagent_oracle。

在以上的资源中：

T ora.gipcd、ora.gpnpd 和 ora.mdnsd 会以守护进程的形式存在，它们负责完成集群在

bootstrap 阶段的工作，在第 4 章将详细介绍。

T ora.ctssd 会以守护进程的形式存在，它负责集群的时间管理，在第 4 章将详细介绍。

T ora.cssd 和 ora.cssdmonitor 会以守护进程的形式存在，其中 ocssd.bin 守护进程负责集

群的构建，并维护集群的一致性，而 cssdmonitor 负责监控 ocssd.bin 守护进程的状态，

在第 5 章将详细介绍。

T ora.crsd 会以 crsd.bin 守护进程的形式存在，这个守护进程负责管理集群的其他资源，

在第 5 章将详细介绍。

T ora.evmd 负责管理集群事件的发布，会以 evmd.bin 守护进程的形式存在。

T ora.asm 这个资源负责管理 ASM 实例，或者说它负责在集群启动时启动 ASM 实例。

关于更多 ASM 的内容，在第 9 章将详细介绍。

T ora.cluster_interconnect.haip 这个资源负责管理集群的 HAIP（High Availability IP）资

源，在本章稍后部分将详细介绍 HAIP 的内容。

T ora.crf 负责管理 11gR2 版本集群管理软件的新特性 CHM（Cluster Health Monitor），在

本章稍后部分将详细介绍 CHM 的内容。

根据以上的描述，可以看到集群在 ohasd 层面的启动过程是：首先，/etc/inittab 中的 init.ohasd 脚本被调用，之后该脚本启动 ohasd.bin 守护进程；然后 ohasd.bin 启动对应的代理进程，

注意


每个代理进程负责启动自己管理的集群初始化资源，即对应资源的初始化进程被启动。接下

来介绍一下 ohasd 层面都有哪些重要的初始化资源。

3.1.3　ohasd 管理的资源

在此对 ohasd 所管理的集群初始化资源进行介绍，其中，包括 HAIP 和 CHM。

1. HAIP对于 Oracle 集群，私网通信是非常重要的，因为节点和节点之间的通信绝大部分都是要

通过私网来实现的。私网通信基本上可以分为两种：第一种是集群层面之间的通信；第二种

是数据库实例之间的通信。第一种通信（例如：节点间的网络心跳）的主要特点是持续存在、

实时性要求高，但是数据量比较小，所以通过 TCP/IP 协议传递就可以了。而第二种通信，也

就是读者所熟知的内存融合造成的实例之间的数据传输的特点是数据量很大，而且速度要求

非常高，TCP/IP 协议此时已经不能满足 Oracle 的要求了，所以需要使用 UDP 或者 RDS，同

时 Oracle 也一直建议用户对集群的私网进行高可用性和负载均衡的配置。对于 10g 和 11gR1 版本的集群，Oracle 并不提供私网的高可用性和负载均衡特性，而是建议用户在操作系统层

面配置，例如：Linux bonding、AIX etherchannel 等。而从 11.2.0.2 版本开始，Oracle 提供了

私网的高可用性和负载均衡特性—HAIP。首先，用户需要在安装 GI 的过程中为集群的私网指定多块网卡。

上图是使用 OUI 安装集群过程中选择集群网络的页面，作者选择了使用 eth0 和 eth1 作为集群的私网。

HAIP 顾名思义就是一个（或多个）IP 地址。Oracle 会自动在集群的每一块私网网卡上绑

定一个 169.254.*.* 网段的 IP 地址，这个 IP 地址被称为 HAIP，数据库实例（ASM 实例也同样

适用）之间在进行通信时，会通过这个 Oracle 绑定的 IP 地址来完成。当某一块私网网卡出现

问题时，对应网卡上绑定的 IP 地址可以漂移到其他的私网网卡上，这就实现了私网的高可用

性。从另一个角度来讲，如果集群包含了多块私网，也就意味着会有多个 HAIP 被绑定在每一

块私网网卡上，每一块网卡都同时承担实例之间的通信，从而实现了私网通信的负载均衡。因此，能看到 HAIP 的功能要比很多操作系统层面的网卡绑定更加强大，而且管理起来更加

注意


简单，因为用户只需要在安装时选择私网网卡就可以了，Oracle 在启动集群时会自动把 HAIP 绑定到网卡上。此外，HAIP 的负载均衡是以网卡为单位的，不需要额外的 OS 软件和交换机

支持。Oracle 也支持在集群已经创建之后，添加新的私网网卡。下面是一个 Linux 平台上的

ifconfig 命令输出：

#ifconfig -aeth1 Link encap:Ethernet HWaddr 00:0C:29:4B:B7:66 inet addr:192.168.254.11 Bcast:192.168.254.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fe4b:b766/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1......

eth1:1 Link encap:Ethernet HWaddr 00:0C:29:4B:B7:66 inet addr:169.254.31.199 Bcast:169.254.127.255 Mask:255.255.128.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:193 Base address:0x1800

eth2 Link encap:Ethernet HWaddr 00:0C:29:4B:B7:70 inet addr:192.168.234.11 Bcast:192.168.254.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fe4b:b770/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1......


网卡 eth1 上的 HAIP 地址 169.254.31.199 被绑定；网卡 eth2 上的 HAIP 地址 169.254.185.222 被

绑定。到目前为止，Oracle 集群最多支持 4 块私网网卡。网卡数量和 HAIP 数量的关系如下：

T 1 块私网网卡，1 个 HAIP 地址。




接下来，通过以下的测试来说明 HAIP 是如何工作的。

步骤 1：检查 HAIP 资源状态和私网设置。

$ crsctl stat res -t -init NAME TARGET STATE SERVER STATE_DETAILS Cluster Resources---------------------------------------------------------------ora.cluster_interconnect.haip ONLINE ONLINE test2 1

HAIP 资源状态正常。

[grid@test2~]$ oifcfg getif eth0 192.168.56.0 global public eth1 192.168.254.0 global cluster_interconnect


eth2 192.168.234.0 global cluster_interconnect

集群存在两个私网网卡。

步骤 2：检查 HAIP 是否已经绑定到对应的网卡上。

#ifconfig -aeth1 Link encap:Ethernet HWaddr 00:0C:29:4B:B7:66 inet addr:192.168.254.11 Bcast:192.168.254.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fe4b:b766/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1......eth1:1 Link encap:Ethernet HWaddr 00:0C:29:4B:B7:66 inet addr:169.254.31.199 Bcast:169.254.127.255 Mask:255.255.128.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:193 Base address:0x1800eth2 Link encap:Ethernet HWaddr 00:0C:29:4B:B7:70 inet addr:192.168.234.11 Bcast:192.168.254.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fe4b:b770/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1......eth2:1 Link encap:Ethernet HWaddr 00:0C:29:4B:B7:70 inet addr:169.254.185.222 Bcast:169.254.255.255 Mask:255.255.128.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:169 Base address:0x1880

从上面程序可以看到，网卡 eth1 上的 HAIP 地址 169.254.31.199 被绑定；网卡 eth2 上的 HAIP 地址 169.254.185.222 被绑定。

步骤 3：将网卡 eth1 停掉，再看一下 HAIP 的情况。

eth2 Link encap:Ethernet HWaddr 00:0C:29:4B:B7:70 inet addr:192.168.234.11 Bcast:192.168.254.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fe4b:b770/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1......eth2:1 Link encap:Ethernet HWaddr 00:0C:29:4B:B7:70 inet addr:169.254.185.222 Bcast:169.254.255.255 Mask:255.255.128.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:169 Base address:0x1880


HAIP 地址 169.254.31.199 被绑定到了私网网卡 eth2 上。

步骤 4：恢复网卡 eth1，再看一下 HAIP 的情况。

eth1 Link encap:Ethernet HWaddr 00:0C:29:4B:B7:66 inet addr:192.168.254.11 Bcast:192.168.254.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fe4b:b766/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1......



eth2 Link encap:Ethernet HWaddr 00:0C:29:4B:B7:70 inet addr:192.168.234.11 Bcast:192.168.254.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fe4b:b770/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1......eth2:1 Link encap:Ethernet HWaddr 00:0C:29:4B:B7:70 inet addr:169.254.185.222 Bcast:169.254.255.255 Mask:255.255.128.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:169 Base address:0x1880

HAIP 地址 169.254.31.199 被重新绑定到了私网网卡 eth1 上，这说明，集群管理软件在私

网网卡出现问题后仍然会继续监控这块网卡，以便在网卡恢复正常后能够将 HAIP 重新恢复

到原有的网卡上，从而保证 HAIP 能够恢复负载均衡。

需要说明的是，数据库和 ASM 实例是在启动时读取 HAIP 地址的，以下是一小段数据库

alert.log，基于此，可以看到数据库通过 UDP 协议在 IP 地址 169.254.31.199 和 169.254.185.222 上实现实例数据传输。

Clus ter communication is configured to use the following interface(s) for this instance

169.254.31.199 169.254.185.222cluster interconnect IPC version:Oracle UDP/IP (generic)IPC Vendor 1 proto 2

而在整个过程中，HAIP 地址一直存在，只不过所绑定的网卡发生了漂移，所以数据库实例和

ASM 实例一直保持正常运行，不会有任何实例终止的问题出现，从而实现了实例间通信的高

可用性和负载均衡特性。

2. CHMCHM（Cluster Health Monitor）是 Oracle 提供的一款工具，用来自动收集操作系统资源

（CPU、内存、SWAP、进程、I/O 以及网络等）的统计信息。从 11.2.0.2 版本开始，CHM 会以

初始化资源 ora.crf 的形式存在于集群的每一个节点上。例如：

[grid@test1 ~]$ crsctl stat res -t -init---------------------------------------------------------------------------NAME TARGET STATE SERVER STATE_DETAILS---------------------------------------------------------------------------Cluster Resources……ora.crf 1 ONLINE ONLINE test1……

相对于 OSWatcher，CHM 直接调用 OS 的 API，系统开销更小；CHM 每秒收集一次数据


（在 11.2.0.3 版本中，改为了 5s 一次），具有更强的实时性。而 OSWatcher 的优点是搜集的信

息更加全面（例如：使用 traceroute 命令检测私网间的连通性），而且所生成的数据的保留时间

可以设置得很长，但是数据的实时性没有 CHM 强，产生的信息可能占用很大的磁盘空间。因

此这两个工具并不能互相替代，而是互补的，如果可以的话，最好两个工具都使用。

CHM 搜集的系统资源数据对于诊断集群系统的节点重启、hang、实例驱逐（Eviction）、性能问题等是非常有帮助的。另外，用户可以使用 CHM 来及早发现一些系统负载异常、内存

异常等问题，从而避免产生更严重的问题。另外，CHM 还可作为单独的工具安装在 Linux 和Windows 平台上，本书主要介绍 RAC 系统的 CHM，而不会包含如何独立安装 CHM 的步骤。

CHM 主要由以下的组件构成。

组件 1 ：CHM 档案库（Repository）：它是一个 Berkeley 数据库，作为保存从各个节点搜

集到的操作系统统计信息的档案库。默认情况下，它会存在于 <gi_home>/crf/db/< 节点名 >下，默认占用 1 GB 的磁盘空间，对于绝大多数的系统，每个节点每天搜集的统计信息大约会

占用 500MB 左右的空间。这里要强调的是 CHM 最大允许的信息保留天数为 3 天，这样做的

目的就是为了减少 CHM 档案库所占用的磁盘空间。

组件 2：系统监控服务（System Monitor Service）：它会以 osysmond.bin 守护进程的方式在

所有节点运行，osysmond.bin 负责定期搜集本地节点的操作系统统计信息，并将搜集到的统计

信息发送给主节点上的集群日志服务。

组件 3 ：集群日志服务（Cluster Logger Service）：这个服务会以守护进程 ologgerd 的形

式运行在集群的 CHM 主节点（Master Node）和副节点（Replication Node）上。主节点的

ologgerd 负责接收从所有节点的 osysmond.bin 发送过来的操作系统统计信息，并记录到主节

点的 CHM 档案库中；副节点的 ologgerd 负责接收从主节点的集群日志服务发送过来的操作系

统统计信息，并记录到副节点的 CHM 档案库中，从而实现 CHM 档案库的高可用性。

读者可以通过下图了解 CHM 的工作方式。

CHM 工作步骤如下。

步骤 1 ：各个节点的 osysmond 通过集群私网向主节点的 ologgerd 发送本地节点操作系统


统计信息。

步骤 2 ：主节点的 ologgerd 向本节点的 CHM 档案库中写入收到的统计信息，同时发送给

副节点 ologgerd。步骤 3：副节点的 ologgerd 向本节点的 CHM 档案库中写入收到的统计信息。

如果 CHM 的主节点出现了问题，副节点会接管 CHM 并成为新的主节点，之后新的主节

点会从集群的其他正常节点中再选出新的副节点。需要说明的是 osysmond 和 ologgerd 守护进

程都会以实时（RT）优先级运行，以确保 CHM 能够准时地搜集操作系统的性能信息。

[grid@test1 admin]$ ps -elf | grep osysmond4 S r oot 3025 1 1 -40 - - 19316 stext Nov13 ? 00:34:21 /u01/

app/11.2.0/bin/osysmond.bin0 R grid 24901 17341 0 78 0 - 980 - 06:42 pts/1 00:00:00 grep osysmond [grid@test1 admin]$ ps -elf | grep ologgerd4 Sr oot 20335 1 0 -40 - - 34515 stext Nov13 ? 00:18:50 /u01/

app/11.2.0/bin/ologgerd -m test2 -r -d /u01/app/11.2.0/crf/db/test1

Oracle 提供了 oclumon 和 CHM/OS Graphical User Interface (CHMOSG) 两款工具来访问

CHM 的数据。其中 CHM/OS Graphical User Interface (CHMOSG) 是图形界面工作，可以从

OTN 下载，由于篇幅有限，本书不会介绍 CHMOSG。 oclumon 是命令行工具，本书会介绍一

些简单的 oclumon 命令，帮助大家熟悉这个工具。

（1）命令 1：查看主节点和副节点

[grid@test1 admin]$ oclumon manage -get MASTER REPLICAMaster = test2Replica = test1Done

（2）命令 2：看当前的统计信息的保存时间段

[grid@test1 admin]$ oclumon manage -get repsizeCHM Repository Size = 67923Done

（3）命令 3：搜集一段时间内的各个节点的统计信息

[grid @test1 admin]$ oclumon dumpnodeview -allnodes -v -s "2014-11-15 06:15:00" -e "2014-11-15 07:15:00" > /tmp/chm.log

上面的输出只是例子，请根据具体需要修改。

更多的关于 oclumon 工具的信息，请使用命令 oclumon –h 获得。下面是一小段 CHM 搜

集的统计信息输出。

----------------------------------------Node: test2 Clock: '11-15-14 06.15.00' SerialNo:37718

注意


----------------------------------------SYSTEM:#pcp us: 1 #vcpus: 1 cpuht: N chipname: Intel(R) cpu: 48.80 cpuq: 11 physmemfree:

95344 physmemtotal: 1518712 mcache: 524552 swapfree: 3735008 swaptotal: 4192956 ior: 30 iow: 173 ios: 18 swpin: 0 swpout: 0 pgin: 30 pgout: 173 netr: 8.973 netw: 9.731 procs: 207 rtprocs: 10 #fds: 13632 #sysfdlimit: 6815744 #disks: 3 #nics: 3 nicErrors: 0

系统的基本信息包括 CPU 数量、内存使用情况、磁盘基本信息。

TOP CONSUMERS:topc pu: 'crsd.bin(3643) 2.59' topprivmem: 'ologgerd(3188) 90008' topshm: 'ora_

mmon_ora11g(4599) 100996' topfd: 'crsd.bin(3643) 155' topthread: 'crsd.bin(3643) 46'

使用资源最多的进程包括消耗 CPU 最多的进程、消耗内存最多的进程、使用文件描述符（FD）最多的进程、线程最多的进程。

PROCESSES:name : 'crsd.bin' pid: 3643 #procfdlimit: 65536 cpuusage: 2.59 privmem: 25296 shm:

18204 #fd: 155 #threads: 46 priority: 15 nice: 0name : 'ohasd.bin' pid: 2468 #procfdlimit: 65536 cpuusage: 1.59 privmem: 22760

shm: 12344 #fd: 134 #threads: 32 priority: 15 nice: 0

进程信息包括进程使用的内存状况、CPU 使用情况、打开的文件描述符数量、包含的线程数

量、优先级。

DEVICES:sda ior: 0.799 iow: 163.798 ios: 12 qlen: 0 wait: 0 type: SWAPsda2 ior: 0.000 iow: 0.000 ios: 0 qlen: 0 wait: 0 type: SWAPsda1 ior: 0.799 iow: 163.798 ios: 12 qlen: 0 wait: 0 type: SYSsdc ior: 29.763 iow: 8.390 ios: 5 qlen: 0 wait: 2 type: SYSsdc1 ior: 29.763 iow: 8.390 ios: 5 qlen: 0 wait: 2 type: SYS

磁盘的 I/O 性能信息包含 I/O 的读写次数、队列长度、等待次数。

NICS:lo n etrr: 3.074 netwr: 3.074 neteff: 6.148 nicerrors: 0 pktsin: 2 pktsout:

2 errsin: 0 errsout: 0 indiscarded: 0 outdiscarded: 0 inunicast: 2 innonunicast: 0 type: PUBLIC

eth0 netrr: 0.350 netwr: 0.000 neteff: 0.350 nicerrors: 0 pktsin: 5 pktsout: 0 errsin: 0 errsout: 0 indiscarded: 0 outdiscarded: 0 inunicast: 5 innonunicast: 0 type: PUBLIC

eth1 netrr: 5.548 netwr: 6.656 neteff: 12.204 nicerrors: 0 pktsin: 14 pktsout: 14 errsin: 0 errsout: 0 indiscarded: 0 outdiscarded: 0 inunicast: 14 innonunicast: 0 type: PRIVATE latency: <1

网卡的统计信息包含网卡的发送和接收性能信息、错误数量等，而且集群的公网和私网信息

都被包含在内。

FILESYSTEMS:


moun t: / type: rootfs total: 36554508 used: 23007512 available: 11660164 used%: 66 ifree%: 96 [ORACLE_HOME ****]

ORACLE_HOME 所在文件系统的空间使用状况。

PROTOCOL ERRORS:IPHd rErr: 0 IPAddrErr: 94543 IPUnkProto: 0 IPReasFail: 0 IPFragFail: 0

TCPFailedConn: 132 TCPEstRst: 5877 TCPRetraSeg: 13 UDPUnkPort: 136 UDPRcvErr: 0

不同的网络协议由于不同原因造成的错误的统计信息。

----------------------------------------Node: test1 Clock: '11-15-14 06.15.01' SerialNo:37719 ----------------------------------------SYSTEM:#pcp us: 1 #vcpus: 1 cpuht: N chipname: Intel(R) cpu: 40.60 cpuq: 19 physmemfree:

49672 physmemtotal: 1518712 mcache: 463864 swapfree: 3914220 swaptotal: 4192956 ior: 30 iow: 60 ios: 7 swpin: 0 swpout: 0 pgin: 30 pgout: 60 netr: 10.313 netw: 7.901 procs: 206 rtprocs: 10 #fds: 13248 #sysfdlimit: 6815744 #disks: 3 #nics: 3 nicErrors: 0

TOP CONSUMERS:topc pu: 'crsd.bin(3750) 2.19' topprivmem: 'java(3097) 129096' topshm: 'ora_smon_

ora11g(5491) 101948' topfd: 'crsd.bin(3750) 138' topthread: 'crsd.bin(3750) 43'

.PROCESSES:

name : 'crsd.bin' pid: 3750 #procfdlimit: 65536 cpuusage: 2.19 privmem: 9016 shm: 18156 #fd: 138 #threads: 43 priority: 15 nice: 0

name : 'ora_lmon_ora11g' pid: 5467 #procfdlimit: 65536 cpuusage: 1.59 privmem: 6816 shm: 21992 #fd: 27 #threads: 1 priority: 15 nice: 0

……DEVICES:sda ior: 0.799 iow: 53.523 ios: 2 qlen: 0 wait: 1 type: SWAP……NICS:lo n etrr: 2.062 netwr: 2.062 neteff: 4.123 nicerrors: 0 pktsin: 2 pktsout:

2 errsin: 0 errsout: 0 indiscarded: 0 outdiscarded: 0 inunicast: 2 innonunicast: 0 type: PUBLIC

……FILESYSTEMS:moun t: / type: rootfs total: 36554508 used: 32076164 available: 2591512 used%:

92;';3;Time=11-15-14 06.15.01, used Too High' ifree%: 96 [ORACLE_HOME ora11g1]

……PROTOCOL ERRORS:IPHd rErr: 0 IPAddrErr: 94555 IPUnkProto: 0 IPReasFail: 0 IPFragFail: 0

TCPFailedConn: 6479 TCPEstRst: 5948 TCPRetraSeg: 17 UDPUnkPort: 116 UDPRcvErr: 0


集群中其他节点的相同信息被输出。

从 CHM 搜集的统计信息的输出项目名称中基本能够看到对应的操作系统命令，所以

上文只是简单介绍了每一类统计信息对应的含义，读者可以参考 Linux 或 Windows 平

台上对应命令的帮助来了解更多信息。

3.2　案例分析

接下来的部分会通过两个简单的案例来实践之前讲解的知识。

3.2.1　由于丢失 OLR 导致的节点无法启动

环境：RHEL 5.5 + 11.2.0.4 GI，双节点。

问题描述：DBA 发现节点 2 的 GI 无法启动。分析过程：由于问题是节点 2 的 GI 无法启动，首先需要确认 GI 启动到了哪一个阶段。

以下是 crsctl stat res –t –init 的输出：

[grid@test1 ohasd]$ crsctl stat res -t -initCRS-4639: Could not contact Oracle High Availability ServicesCRS-4000: Command Status failed, or completed with errors.

从以上程序可以看出 ohasd 层面都没有启动，有可能是 /etc/inittab 中启动集群的 init.ohasd 脚本没有被调用，或者是 ohasd.bin 守护进程没有启动成功。因此需要进一步验证：

[grid@test1 ohasd]$ ps -ef | grep hasroot 2710 1 0 Nov13 ? 00:00:00 /bin/sh /etc/init.d/init.ohasd runroot 6414 1 1 12:36 ? 00:00:00 /**/**/**/**/bin/ohasd.bin reboot

根据上面的输出可推出 init.ohasd 脚本的确被调用了，而且 ohasd.bin 守护进程也已经被启动，

那么问题在于 ohasd 没有被成功启动。因此，需要看一下 ohasd 的日志文件以进行分析：

ohasd.log2014 -11-15 12:29:03.167: [default][3037648592] OHASD Daemon Starting. Command

string :reboot2014-11-15 12:29:03.169: [default][3037648592] Initializing OLR2014 -11-15 12:29:03.172: [OCROSD][3037648592]utopen:6m': failed in stat OCR file/disk

/**/**/**/**/cdata/***.olr, errno=2, os err string=No such file or directory2014 -11-15 12:29:03.172: [OCROSD][3037648592]utopen:7: failed to open any OCR

file/disk, errno=2, os err string=No such file or directory2014 -11-15 12:29:03.172: [OCRRAW][3037648592]proprinit: Could not open raw device2014 -11-15 12:29:03.173: [OCRAPI][3037648592]a_init:16!: Backend init unsuccessful : [26]2014 -11-15 12:29:03.173: [CRSOCR][3037648592] OCR context init failure. Error:

PROCL-26: Error while accessing the physical storage Operating System error [No such file or directory] [2]

2014 -11-15 12:29:03.173: [ default][3037648592] Created alert : (:OHAS00106:)

注意


: OLR initialization failed, error: PROCL-26: Error while accessing the physical storage Operating System error [No such file or directory] [2]

2014 -11-15 12:29:03.173: [ default][3037648592][PANIC] OHASD exiting; Could not init OLR

根据上面的日志信息，看起来问题是由于无法访问 OLR 导致的。此时，需要看一下 OLR 是

否存在：

[grid@test1 cdata]$ ls -ltotal 140drwxr-xr-x 2 grid oinstall 4096 Sep 19 10:45 localhostdrwxr-xr-x 2 grid oinstall 4096 Nov 11 14:29 ***drwxrwxr-x 2 grid oinstall 4096 Nov 4 04:43 ****-cluster-rw------- 1 root root 126370 Sep 19 11:36 ocr11.2.0.3.0

从上段程序看来，OLR 的确不存在，问题的原因是 OLR 丢失了。

结果：由于 OLR 默认会在 GI 安装时产生备份，可以从默认的备份位置进行恢复。

首先检查备份 OLR 是否存在：

[root@test1 test1]# pwd/***/***/**/**/cdata/test1[root@test1 test1]# ls -ltotal 20588-rw-r--r-- 1 grid oinstall 6799360 Sep 19 11:33 backup_20131003_094829.olr-rw------- 1 root root 7024640 Sep 19 11:37 backup_20140919_113752.olr-rw------- 1 root root 7118848 Nov 11 14:29 backup_20141111_142928.olr-rw------- 1 root root 95275 Sep 19 11:33 olr11.2.0.3.0

看起来备份的确存在，接下来使用下面的步骤恢复：

[root @test1 bin]$ ./ocrconfig -local -restore /***/***/**/**/cdata/test1/ backup_20141111_142928.olr

最后重新启动 GI，问题解决：

[root@test1 ~]# /**/**/**/**/bin/crsctl start crs

3.2.2　由于 HAIP 导致的数据库无法启动

环境：AIX 6.1 + 11.2.0.2 GI，双节点。

问题描述：这是一套新安装的集群，节点 1 在运行 root.sh 时报错，并且数据库无法启动。

分析过程：由于是 root.sh 脚本报错，所以需要看一下 root.sh 脚本的日志：

rootcrs_***.log......2013 -04-25 17:36:54: Executing cmd: /***/***/bin/crsctl start resource ora.

cluster_interconnect.haip -init2013-04-25 17:37:58: Command output:> CRS-2672: Attempting to start 'ora.cluster_interconnect.haip' on '****'> C RS-5017: The resource action "ora.cluster_interconnect.haip start"


encountered the following error: > St art action for HAIP aborted. For details refer to "(:CLSN00107:)" in

"/***/***/log/test1/agent/ohasd/orarootagent_root/orarootagent_root.log".> CRS-2674: Start of 'ora.cluster_interconnect.haip' on '***' failed> CRS-2679: Attempting to clean 'ora.cluster_interconnect.haip' on '***'> CRS-2681: Clean of 'ora.cluster_interconnect.haip' on '***' succeeded> CRS-4000: Command Start failed, or completed with errors.

根据上面的输出，看来在启动 HAIP 时出现了问题，所以需要看一下具体的 agent 日志来

进一步分析：

[CLSFRAME][2314] {0:0:79} [TIMER] New wait delay: 16502013 -04-25 17:33:36.652: [ora.cluster_interconnect.haip][1800] {0:0:79} [start]

(:CLSN00107:) clsn_agent::start { 2013 -04-25 17:33:36.653: [ora.cluster_interconnect.haip][1800] {0:0:79} [start]

NetworkAgent::init enter {2013 -04-25 17:33:36.653: [ora.cluster_interconnect.haip][1800] {0:0:79} [start]

NetworkAgent::init exit }2013 -04-25 17:33:36.653: [ USRTHRD][1800] {0:0:79} Thread:[NetHAMain]start {2013-04-25 17:33:36.653: [ USRTHRD][1800] {0:0:79} Thread:[NetHAMain]start }2013-04-25 17:33:36.653: [ USRTHRD][3343] {0:0:79} [NetHAMain] thread started2013 -04-25 17:33:36.694: [ USRTHRD][3343] {0:0:79} Ocr Context init default level

3197285282013 -04-25 17:33:36.694: [ default][3343]clsvactversion:4: Retrieving Active

Version from local storage.2013 -04-25 17:33:36.825: [ USRTHRD][3343] {0:0:79} HAIP: mbr num is 0.[ CLWAL][3343]clsw_Initialize: OLR initlevel [70000]2013 -04-25 17:33:36.952: [ USRTHRD][3343] {0:0:79} HAIP: initializing to 1

interfaces2013 -04-25 17:33:36.954: [ USRTHRD][3343] {0:0:79} HAIP: configured to use 1

interfaces2013 -04-25 17:33:36.959: [ USRTHRD][3343] {0:0:79} HAIP: Updating member info

HAIP1;*.*.*.*#02013 -04-25 17:33:36.960: [ USRTHRD][3343] {0:0:79} InitializeHaIps[ 0] infList

'inf ib0, ip *.*.*.1, sub *.*.*.*' 2013 -04-25 17:33:36.961: [ USRTHRD][3343] {0:0:79} Error in getting Key SYSTEM.

network.haip.group.cluster_interconnect.interface.valid in OCR2013 -04-25 17:33:36.997: [ CLSINET][3343] failed to open OLR HAIP subtype SYSTEM.

network.haip.group.cluster_interconnect.interface.valid key, rc=42013 -04-25 17:33:36.998: [ USRTHRD][3343] {0:0:79} ipMapsz 0, idxMap sz 0,

restart 0, numHaip 1, infListSz 12013 -04-25 17:33:36.998: [ USRTHRD][3343] {0:0:79} HAIP reset on new modified

startup, ipSize 0 != numInf 12013 -04-25 17:33:36.998: [ USRTHRD][3343] {0:0:79} restart 0, haipSize 0, numHaip

1, numSub 0, ipMsz 02013 -04-25 17:33:36.998: [ USRTHRD][3343] {0:0:79} HAIP: starting inf 'ib0',

suggestedIp '', assignedIp ''2013-04-25 17:33:36.998: [ USRTHRD][3343] {0:0:79} Thread:[NetHAWork]start {2013-04-25 17:33:36.998: [ USRTHRD][3343] {0:0:79} Thread:[NetHAWork]start }2013-04-25 17:33:36.998: [ USRTHRD][3600] {0:0:79} [NetHAWork] thread started


2013-04-25 17:33:36.999: [ USRTHRD][3600] {0:0:79} Arp::sCreateSocket { 2013-04-25 17:33:36.999: [ USRTHRD][3600] {0:0:79} failed to create arp2013 -04-25 17:33:36.999: [ USRTHRD][3600] {0:0:79} (null) category: -2,

operation: ssclsi_aix_get_phys_addr, loc: aixgetpa:4,n, OS error: 2, other: 2013-04-25 17:33:36.999: [ USRTHRD][3600] {0:0:79} Arp::sCreateSocket { 2013-04-25 17:33:36.999: [ USRTHRD][3600] {0:0:79} failed to create arp2013 -04-25 17:33:36.999: [ USRTHRD][3600] {0:0:79} (null) category: -2,

operation: ssclsi_aix_get_phys_addr, loc: aixgetpa:4,n, OS error: 2, other:

看起来问题是在启动 HAIP 时出现了一些和操作系统相关的错误。因此，需要再看一下操作系

统层面私网的状态。不过根据网卡的名称，看起来 Infiniband 似乎被使用了，在和 DBA 确认

之后得到了肯定的答案。

[***][root][/]#ifconfig -aib0: flags=e3a0063<UP,BROADCAST,NOTRAILERS,RUNNING,ALLCAST,MULTICAST,LINK0,LINK1,

GROUPRT,64BIT> inet *.*.*.1 netmask 0xffffff00 broadcast *.*.*.255 inet6 fe80::2:c903:24:4c3b%2/64 tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1

网卡状态一切正常，问题还是出现在 GI 层面上，经过确认后发现，GI 在 11.2.0.2 版本

中，针对 AIX 平台还不支持 Infiniband。因此，暂时只能不使用 HAIP，而需要使用初始化参

数 cluster_interconnects 来指定 ASM 和数据库实例的私网通信 IP 地址。

结果：使用以下的命令修改参数 cluster_interconnects 之后，数据库可以正常启动。

alter system set cluster_interconnects='*.*.*.*' scope=spfile sid='****';

总结

本章介绍了 11gR2 版本新增加的组件 OHAS，并且对集群启动时 ohasd 的工作方式进行

了介绍，还对 11gR2 版本集群管理软件中出现的新特性代理进程框架做了简单的介绍。最后

介绍了 ohasd 管理的各种初始化资源，并详细讲解了 ohasd 管理的资源 HAIP 和 CHM。

11gr2 集群新增组件 - baiduimages.china-pub.com/ebook4880001-4885000/4881963/ch03.pdf · 2015....

Documents